X-Authentication-Warning: gocho.pm.org: majordomo set sender to
[EMAIL PROTECTED] using -f
Date: Tue, 11 Sep 2001 00:19:44 -0400 (EDT)
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
On Mon, 10 Sep 2001, Kenneth Graves wrote:
> $x is false = 0 is true;
well what is the result of this really? it's not like all attributes have
an opposite. these attributes are not stored in a field either as i would
have guest. you did not say $x is boolean = false. you said $x is
false. for user defined attributes a variable could have many, but perl
wouldn't know they were contradictory. in your above example i'm guessing
that $x would have both the false attribute and true attribute set unless
they either put them in a field to group them or had a special case to say
true is not false.
>From what I've heard so far, I'm expecting a special case for true vs. false.
(Syntactic sugar for something like boolean(1) and boolean(0).)
Making some assumptions about what the syntax will end up being,
you can still do:
my $x is color('green');
$x = 0 is color('red');
print $x.color, "\n"; # greenish-red?
Really, the only point here is that if we get attributes for both
variables and values, there will need to be a decision about
precedence.
The harder part will be learning which attributes "should" be attached
to values, and which to variables. Will there be a difference
between
my $x is integer = 127;
and
my $x = 127 is integer;
in terms of either arithmetic or compiler optimizations?
--kag
