parsing ok((2+3)==5)

0 views
Skip to first unread message

Abhijit Mahabal

unread,
Feb 27, 2005, 4:14:34 PM2/27/05
to perl6-c...@perl.org
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

Autrijus Tang

unread,
Feb 28, 2005, 11:26:44 AM2/28/05
to Abhijit Mahabal, perl6-c...@perl.org

...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/

Abhijit Mahabal

unread,
Mar 1, 2005, 7:22:08 PM3/1/05
to perl6-c...@perl.org

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


>
> Thanks,
> /Autrijus/

Larry Wall

unread,
Mar 2, 2005, 2:42:51 PM3/2/05
to perl6-c...@perl.org
On Tue, Mar 01, 2005 at 07:22:08PM -0500, Abhijit Mahabal wrote:
: 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

Reply all
Reply to author
Forward
0 new messages