at revision: 1b06df80900096dab8a9f74467f504f73a6115dd
and also at release #18.
: bash$ perl6
: > 1 ?? 2 !! 3
: > 1 ?? (1,2) !! (3,4)
: > 1 ?? 1,2 !! 3,4
: Ternary error
: bash$
this is not wrong as infix:<,> has looser precedence than the ternary
operator( ?? !! )
but when ternary error occurs, the program emits the error and dies.
should provide the proper error message and not die.
: It is a syntax error to use an operator in the middle part that binds
looser in precedence, such as =.
: my $x;
: hmm() ?? $x = 1 !! $x = 2; # ERROR
: hmm() ?? ($x = 1) !! ($x = 2); # works
(1 ?? 1),(2 !! 3),4
I agree, however, that this shouldn't die.
I've added a test for this in t/spec/S03-operators/ternary.t
Thanks.
Kyle.
On Mon, Jun 22, 2009 at 1:57 AM, Hojung Yoon
<perl6-bug...@perl.org>wrote:
This seems like something that is eligible for DWIMery. If the
tokenizer were to automatically turn "??" and "!!" into "?? (" and
") !!", it would permit such constructions. This pair of operators
should be acting like a bracketing pair, and not be especially
susceptible to issues of precedence - it is only the expressions
before the ?? and after the !! that should be affected by the
precedence of the ??!! operator, any expression in between them
should be allowed. (Rather than inserting imaginary parens, it
can be done by treating the precedence of ?? as extremely low when
compared to operators to its right, e.g. -1; and the precedence of
!! as even lower (e.g. -2) when compared to operators on its left.
Operators outside of the ?? ... !! area are compared using the
official precedence of the ??!! operators. (Way back in compiler
construction course I did a similar sort of thing to allow assignment
to be put into the middle of an expression without requiring parens
to bind the lvalue. (E.g. i=10*j=l+m was parsed as i=10*(j=l+m)
with assignment being high precedence over operators to its left
and low precedence to operators on its right.)
Now fixed in 5351a33:
$ ./perl6
> 1 ?? 1,2 !! 3,4
Ternary error at offset 6, found ','
in Main (src/gen_setting.pm:3279)
>
I grant that the error message should be a bit more helpful, but I think
I'll postpone that part for the overall refactor of error message
handling and parsing that will be coming up soon. As shown above, the
ternary error no longer forces an exit.
Closing ticket,
Pm