I hunted down the cause of the non-parsing of
   ok((2 + 3) == $five, "== (sum on lhs)");
in 03operator.t, but am not yet up to speed in Haskell to fix it.

Below is the location of the problem.

The error is in Parser.hs, in the blocks for parseApply and
parseParamList. parseApply eats parens using maybeDotParens, and then
calls parseParamList, which is also willing enough to gobble more parens.
Thus the following fails to parse: f((2+3),5), but this succeeds:
f(((2+3), 5)).

--abhijit

...and the solution is to change maybeDotParens into a simple
maybeDot. Much thanks for tracking this down! It's been fixed in 6.0.9.

Thanks,
/Autrijus/

application_pgp-signature_part < 1K Download

Hmm. I wonder if that introduces more bugs itself. Is the following legal?
        f ($x)
I know f($x) is legal, and so is f .($x), and space without dot is
illegal for methods, but I could not find the relevant thing for subs in
S06 or S12.

In any case, consider the following program. It prints "10" in all four
lines in the current version of pugs(svn rev 497):

=====================
use v6;
sub f(*@x){
   @x[0] + @x[1];

say "Expecting 10:     ", f((2+3), 5);
say "Expecting error?  ", f ((2+3), 5);
say "Expecting  10:    ", f 2+3, 5;
say "Expecting  8.2??: ", f .2+3, 5;
=======================

At least getting a 10 on the last line is very surprising for me.

--abhijit

: Hmm. I wonder if that introduces more bugs itself. Is the following legal?
:       f ($x)

It is legal if f has been predeclared, in which case it parses as a list
operator, and ($x) is its first argument.  That is,

    f ($x),2

would pass 2 arguments to f, $x and 2.  However, any of

    f($x),2
    f.($x),2
    f .($x),2

will pass only one argument, since they're all interpreted as function
calls, not list operators.

: I know f($x) is legal, and so is f .($x), and space without dot is
: illegal for methods, but I could not find the relevant thing for subs in
: S06 or S12.
:
: In any case, consider the following program. It prints "10" in all four
: lines in the current version of pugs(svn rev 497):
:
: =====================
: use v6;
: sub f(*@x){
:   @x[0] + @x[1];
: }
:
: say "Expecting 10:     ", f((2+3), 5);

Passes 5,5 as two arguments, as expected.

: say "Expecting error?  ", f ((2+3), 5);

That depends on what we make (,) do in list context.  Arguably, it could
treat the outer parens as forcing scalar context on the comma, and
by Perl 6 rules of lists in scalar context, pass an autoreferenced
[5,5] as first argument.  The addition would then be trying to
add 2 (the number of elements in the list) to undef.  On the other hand,
in Perl 5, a parenthesized list in list context autoflattens, on the
assumption that parens are reserved only for grouping, and not for
enforcing scalar context in the absence of other clues.  So I think
this one also produces 10, not because the outer parens are making it
into a function call, but because the list context is flattening the
expression (5,5) into two arguments for the list.  If the sub had been
declared f($a,$b) this would not happen, and you would get [5,5],undef
as your arguments, or rather, you get an error from not having enough
arguments.

: say "Expecting  10:    ", f 2+3, 5;

Should pass 5,5 as two arguments to list operator f.

: say "Expecting  8.2??: ", f .2+3, 5;

Should pass 3.2, 5 as two arguments to list operator f.

: At least getting a 10 on the last line is very surprising for me.

It would surprise me too.  The space-eating postfix dot is only
good before /<+ <alpha> + [_(\[{:<«$] >/ or some such set derived from
the prefix characters of all known postfix operators.  But .2 should
always be interpreted as 0.2, implying that we should probably disallow
numeric postfix operators.  Such a hardship.

Well, maybe just ASCII numerics.  We could conceivably allow $x² and its
corresponding $x .² in dot form.  Mind you, anyone who tries that should
expect a little push-back from the community...

Larry