This a (hopefully friendly) note regarding cross posting between
perl6-compiler (p6c) and perl6-language (p6l). We're still feeling our
way around regarding "what belongs on p6c vs. p6l", but it seems
pretty clear to me that if the question is one of "perl6/pugs doesn't
properly implement feature X as given by the spec" then the post
belongs strictly on p6c. We only bring p6l into the discussion if
the spec is ambiguous and it's something that can't be easily
decided/discussed within p6c itself. This is just to keep
cross-postings and traffic to a minimum.
Patches to pugs or the perl6 compiler certainly belong *only* on p6c.
This message isn't intended as a rebuke at all -- all of the patches,
questions, and suggestions are very welcome! It's just a
clarification since we're still just gettings underway on p6c.
Pm
> Assuming the spec is correct, here's a patch to add some more tests to
> t/op/string_interpolation.t.
Of course, those should have been todo_is tests... Here's the right patch.
-garrett
That's what I though, but Autrijus suggested I check with p6l first.
-garrett
I should've also mentioned in my previous post that in this case,
the spec is correct. In general, for purposes of the compiler(s)
we always assume that the spec is correct unless it's ambiguous
or it leads to an absurd/contradictory conclusion, in which case
we get the p6l folks to clarify/correct the spec.
Pm
S02 says that container references automatically dereference to the
appropriate (white space separated) string values, which is fine, pugs
does that now, but it also says that to interpolate an entire array you
need to subscript with empty brackets, so if we've got an array @a = (1,
2, 3) then "@a" eq '@a', but "@a[]" eq "1 2 3", at least from my reading
of the synopsis.
So what's right, the spec or the implementation?
Assuming the spec is correct, here's a patch to add some more tests to
t/op/string_interpolation.t.
-garrett
Okay, no problem. We're still learning and establishing where
the fuzzy boundaries are. :-)
Perhaps a useful default will be to always start out by posting
messages and questions only to perl6-compiler. Then if the answers
aren't available through p6c, we can then rephrase the questions
in terms of language design and forward them to p6l.
Pm
Thanks, applied.
Luke
Yup. Now reading S02 again, it is pretty clear that p6l would
not be needed -- Sorry for my out of context suggestion on IRC.
> Perhaps a useful default will be to always start out by posting
> messages and questions only to perl6-compiler. Then if the answers
> aren't available through p6c, we can then rephrase the questions
> in terms of language design and forward them to p6l.
That indeed sounds like a good rule-of-thumb. :)
Thanks,
/Autrijus/
Thanks a lot for applying the patches to svn.perl.org. :-)
This is jsut a heads-up to say that svn.openfoundry.org is back,
so committers, please commit to openfoundry.org as usual.
Cheers,
/Autrijus/
Thanks, implemented as such (r579).
With that change however, these three lines are now the same:
my @x = @a;
my @x = @a[];
my @x[] = @a;
Is that correct?
Thanks,
/Autrijus/
I believe so, since @x[] is an array slice that encludes the entire
contents of the array.
-garrett
Yes, it's taken as a 0-dimensional slice, rather than a 1-dimensional
slice with 0 selected elements.
Larry