Hi Stuart,

You (and Carl) are absolutely right... all these things are behaving as
they should. Cool! :-)

I'll fix the tests later on today.

Thanks,

Ade

Stuart Cook wrote:

>On 5/24/05, Adrian Taylor <[EMAIL PROTECTED]> wrote:
>  
>
>>eval_is('undef + 1', undef, 'undef + 1', :todo<bug>); # dies
>>    
>>
>
>In this case, you're expecting
> (undef) + 1
>but you're getting
> undef(+1)
>instead.
>
>This is because 'undef' serves double-duty as both 'undefined value'
>and 'prefix op for undefining variables', and the op form is taking
>precedence in parsing.
>
>It's worth noting that Perl5 seems to have exactly the same parsing behaviour:
>
>$ perl -e 'print undef + 1'
>Warning: Use of "undef" without parentheses is ambiguous at -e line 1.
>Can't modify constant item in undef operator at -e line 1, at EOF
>Execution of -e aborted due to compilation errors.
>
>I'm not sure whether this behaviour is supposed to be changing.
>
>
>  
>
>>eval_is('1 + undef', undef, '1 + undef', :todo<bug>); # gives 1
>>eval_is('2 * undef', undef, '2 * undef', :todo<bug>); # gives 0
>>    
>>
>
>AFAIK, a vanilla (undef) numifies to 0, so these are already correct.
>If you were expecting undef to behave as a 'poisoned' value then I can
>understand the confusion.
>
>
>  
>
>>eval_is('undef xx 2', undef, 'undef xx 2', :todo<bug>); # dies
>>    
>>
>
>Again, you're expecting
> (undef) xx 2
>but you're getting
> undef(xx 2)
>instead.
>
>
>Stuart
>  
>

Reply via email to