Re: Separate as keyword? (Re: 'is' and action at a distance)

[Nathan Wiger]

Dammit, I got the example exactly backwards. Try this:

$Foo is true;
$Foo = 0;
print Stuff if $Foo;   # *WOULD* print - is assigns a
 # permanent true property
 
$Foo as true = ;
$Foo = 0;
print Stuff if $Foo;   # *WOULD NOT* print - as is reset by
 # value assignment since is temporary

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Dave Storrs]

On Fri, 18 May 2001, Nathan Wiger wrote:

 
 Maybe there are two different features being conflated here. First, we
 have is, which is really for assigning permanent properties:
my $PI is constant = '3.1415927';
 So, those make sense, and we'd want them to remain through assignment.
 However, the true, error, false, etc, really are *temporary*
 conditions.  Maybe we need a separate keyword - as - for this:
return $zero as true;
 For stuff declared with this as keyword, it would last until next
 assignment or other value change. That is, these are value dependent and
 designed to pass extra information along. By definition, though, when
 the value changes we'll want these properties to change as well.


I think you may be onto something here, but I get nervous about
as and is being the chosen keywords...they are only one letter apart
and the cognitive difference between them is very small(*); I think it
would be very easy to mix them up.

Dave

* For an example of words that are only one letter apart but have a very
large cognitive difference, try now and not.

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Buddha Buck]

At 01:34 PM 05-18-2001 -0700, Nathan Wiger wrote:
Dammit, I got the example exactly backwards. Try this:

 $Foo is true;
 $Foo = 0;
 print Stuff if $Foo;   # *WOULD* print - is assigns a
  # permanent true property
 
 $Foo as true = ;
 $Foo = 0;
 print Stuff if $Foo;   # *WOULD NOT* print - as is reset by
  # value assignment since is temporary

I tend to think of the temporary/permanant distinction being a 
rvalue/lvalue distinction.

Perhaps the rvalue/lvalue context of the property assignment could be used 
to determine whether it's temporary or permanant?

$Foo = 0 is true;   # $Foo has a true value
print $Foo is true if $Foo;   # prints 0 is true

$Foo = 0;   # $Foo has a false value
print $Foo is true if $Foo;  # does not print.

$Foo is true = 0;  #$Foo is true regardless of value
print $Foo is true if $Foo; # prints 0 is true

$Foo = 0; #$Foo is still true, despite false value
print $Foo is true if $Foo; # prints 0 is true

$Foo = 0 is false; # Hmm, lvalue $Foo is true, but assigned -declared- 
false value...  who wins?
print $Foo is true if $Foo; # ??

We'd also need to come up with better syntax for:

$Foo is true = $Foo;

for changing the lvalue properties of $Foo without changing the rvalue 
contexts...

Later,
   Buddha

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Larry Wall]

I've seen uses for compile-time properties on variables, and run-time
properties on values, but I've not yet seen any decent use for run-time
properties on variables.  So I'd be inclined to disallow properties on
lvalues unless they're in a my or our.

Offhand, I do kinda like the notion of distinguishing between
compile-time and run-time properties by means of a different keyword,
whether that's as or something else.  I think it might tend to reduce
some of the confusion.  But I'll have to think about that some more.
It's possible it's a false economy, psychologically speaking.

Larry

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Jarkko Hietaniemi]

Maybe I missed it... but what is the relationship of (Perl 5) attributes
and Perl 6 properties?

my $answer : constant  = 42;
my $answer is constant = 42;

my sub ... dang, no lexical subs, but can we please have them
in Perl6? :-)

sub terfuge : locked  { ... }
sub terfuge is locked { ... }

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Damian Conway]

Bart wrote:

While I understand how 0 but true is a cute hack that is destined to
be replaced by a truth property, I fail to realize how it's useful to
have a value that's true no matter what value you assign to it later.

I thought the truth property was attached to the value, not to the
variable. So if you assign a new value to that variable, the truth
property is overwritten, too.

Yep.

Damian

Re: Separate as keyword? (Re: 'is' and action at a distance)

[Larry Wall]

Jarkko Hietaniemi writes:
: Maybe I missed it... but what is the relationship of (Perl 5) attributes
: and Perl 6 properties?
: 
:   my $answer : constant  = 42;
:   my $answer is constant = 42;
: 
:   my sub ... dang, no lexical subs, but can we please have them
:   in Perl6? :-)

Yes, there will certainly be lexical subs.  We might even go so far as
to rely on my/our to distinguish private methods from public without
actually having to declare methods as public or private.

:   sub terfuge : locked  { ... }
:   sub terfuge is locked { ... }

Perl 6 compile-time properties *are* Perl 5 attributes, give or take an
implementation interface or two.  Perl 6 run-time properties have no
counterpart in Perl 5 (unless you count dual-valued variables like $!,
or some of the other data that can be attached via magic).

We're calling them properties now instead of attributes because we
don't want people to confuse properties with object attributes (except
to the extent that we do).

The switch from : to is is motivated primarily by the fact that
we want the colon for far too many other things as well.  Plus, I just
think that

my $answer is constant = 42;

makes it more visually clear that the assignment is to $answer, since
the textiness tends to clump everything before = together a little
better.  (At least, I think people can learn to read it that way, even
if it strikes them differently on first impression.)

Larry