Front page | perl.perl6.language |
Postings from April 2006
In Perl5, the meaning of the undef value is overloaded. It can mean
either the value an uninitialized variable or it may indeed mean a
genuine undefined value. Perl5 is biased toward the first meaning: in
string context, the value behaves as an empty string; In integer
and float context, it respectively behaves as 0 and 0.0. In
other words, the uninitialized variable is considered initialized with
a nice defaut value.
In Perl6, for typed primitive variables, the problem disappear : the
variables will be explicitely initialized with the appropriate value.
But the behavior does not change for untyped variables.
In JavaScript, using an uninitialized value is considered an error.
Used in string context, it brings "undefined" and in integer and float
context, it brings NAN, not a number. Neither can be considered as a
nice default value.
Unitialized values are probably not a best practice for long programs,
but they are very nice for short ones which Perl6 still want to support.
Now suppose, I want Perl6 to operate nicely with a Parrot based
JavaScript implementation. I want to write short programs with
uninitialized values to call JavaScript libraries. I would like my Perl
uninitialized values to behave in JavaScript like in Perl5 : brings
appropriate defaults values depending on context.
This is possible because the PMC will not change its behavior in the
Parrot based javascript world. In a non Parrot, non Pugs, based
Javascript, I will be out of luck. Good, there has to be some
advantages to choose Parrot over the board.
On the other hand, I also want to be able to initialize a Perl6 scalar
value with a genuine undef value so that it behaves as such in the
JavaScript world.
As far a Perl6 is concerned, we only need a new convention to
distinghish between an unitialized value and a genuine undefined one.
I borrow the convention from the JavaScript world, but I don't mind
another.
defined $a # true still means not undef or not uninitialized
$a == undef # true would mean a genuine undef
At the Parrot level, it would mean using a PerlUndef PMC and a
PerlUninitialized one.
A second related problem: should such PMCs be singletons or not?
Singletons would allow to save memory. But they are objects where we
can shove attributes. Maybe they should be singletons and becomes new
different objects the first time an attribute is shoved in them. This
behavior is different than simply morphing a pmc.
Finally, a third related problem: what about missing slot in arrays?
What sort of undef should they be?
--
cognominal stef
Thread Previous