Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Undef issues

3 views
Skip to first unread message

Adrian Taylor

unread,
May 24, 2005, 8:26:59 AM5/24/05
to perl6-c...@perl.org
Hi,

Over the weekend I added some tests on 'undef' behaviour
(t/builtins/undef.t):

These behave as expected:

eval_is('undef * 2', undef, 'undef * 2');
eval_is('undef * undef', undef, 'undef * undef');

These don't (at least, according to my expectations...)

eval_is('undef + 1', undef, 'undef + 1', :todo<bug>); # dies
eval_is('1 + undef', undef, '1 + undef', :todo<bug>); # gives 1
eval_is('2 * undef', undef, '2 * undef', :todo<bug>); # gives 0
eval_is('undef xx 2', undef, 'undef xx 2', :todo<bug>); # dies

I was hoping to figure out enough Haskell to think about how to fix
them, but I have given up for the moment :-)

Ade

Carl Franks

unread,
May 24, 2005, 8:38:36 AM5/24/05
to Adrian Taylor, perl6-compiler
> eval_is('undef + 1', undef, 'undef + 1', :todo<bug>); # dies
> eval_is('1 + undef', undef, '1 + undef', :todo<bug>); # gives 1

I would expect these to both equal 1,
see perl5

>perl5 -le "undef $_; ++$_; print"
1

Stuart Cook

unread,
May 24, 2005, 8:53:59 AM5/24/05
to perl6-c...@perl.org
On 5/24/05, Adrian Taylor <a...@hohum.me.uk> 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

Adrian Taylor

unread,
May 24, 2005, 9:34:41 AM5/24/05
to perl6-c...@perl.org
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

Piers Cawley

unread,
May 25, 2005, 6:55:45 AM5/25/05
to Adrian Taylor, perl6-c...@perl.org
Adrian Taylor <a...@hohum.me.uk> writes:

> Hi,
>
> Over the weekend I added some tests on 'undef' behaviour
> (t/builtins/undef.t):
>
> These behave as expected:
>
> eval_is('undef * 2', undef, 'undef * 2');

That's not what I'd expect. I'd expect it to return 0 and throw a warning
about numification.

Larry Wall

unread,
May 31, 2005, 8:24:44 PM5/31/05
to perl6-c...@perl.org
On Tue, May 24, 2005 at 10:53:59PM +1000, Stuart Cook wrote:
: I'm not sure whether this behaviour is supposed to be changing.

It is. I think we decided to make the value undef, and the function
undefine(). (But these days most values of undef really ought to
be constructed and returned (or thrown) using fail().)

Larry

0 new messages