Re: Separate "as" keyword? (Re: 'is' and action at a distance)
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
Re: Separate "as" keyword? (Re: 'is' and action at a distance)
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)
On Fri, 18 May 2001 23:26:53 +0200, Trond Michelsen 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. Actually, replace "variable" with "lvalue". It could be, say, a hash element. -- Bart.
Re: Separate "as" keyword? (Re: 'is' and action at a distance)
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)
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)
On Fri, May 18, 2001 at 01:34:55PM -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
Sorry to jump out of lurk-mode like this, it's just that I'm trying real
hard to understand how this can be useful..
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.
In the case of "0 but true", you return failure with undef, but if a
function doesn't signal failure in any way - testing its return-value
isn't going to be very helpful. So, what I'm struggling the most with is
how it's useful to actually test the truth of a variable that is
guaranteed to be true.
To me, this looks almost like an if-test like this:
foreach my $key (keys %hash) {
next unless exists $hash{$key};
...
}
(ok, strictly speaking, that was an unless-test ;)
Anyway - I'm not sure how properties are supposed to work yet. Should
all properties behave in the same way, or can every propery completely
define its own behaviour?
I mean - if you can override the "truth"-property by assigning to the
variable, why shouldn't one be able to override the "constant"-property
by assigning a new value to the constant?
--
// Trond Michelsen
\X/ [EMAIL PROTECTED]
Re: Separate "as" keyword? (Re: 'is' and action at a distance)
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)
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)
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
Separate "as" keyword? (Re: 'is' and action at a distance)
* Michael G Schwern <[EMAIL PROTECTED]> [05/18/2001 12:32]:
> Let me see if I understand this...
>
> $Foo is true;
>
> # Meanwhile, in another part of the city...
>
> $Foo = 0;
> print "My spider sense is tingling" if $Foo;
>
> Does that print or not?
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';
my $int is integer;
$int = 5.4; # error, or something...
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;
return $fh as error("Internal Blah Blah Blah: $!");
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.
So, Schwern's example would be work as follows:
$Foo is true;
$Foo = 0;
print "Stuff" if $Foo; # would not print - "is" assigns a
# permanent "true" property
$Foo as true = "";
$Foo = 0;
print "Stuff" if $Foo; # would print - "as" is reset by
# value assignment since is temporary
-N8
