more slots in the glob, 'but', Re: 'is' and action at a distance
I had imagined the way things like $R = 0 but true would work is that the scalar would grow another couple of slots in it, which would be the conversion operators. Everything defaults to how it has worked in the past, but could be overridden. So the boolean value starts as default converter until it gets accessed, then the language figures out what the boolean value is and caches it until an assignment happens and clears the boolean (and other autoconverted) value. That allows booleans to get set to values other than perl 5 truth of the scalar contents. It also meshes well with alternate v-tables, although profusion of what can be done by multiplying the number of vtables and what is better done with a per-access check is a good case for some modeling and some algebra and some benchmarking on various platforms: Maybe we could have a slider in the performance tuning widget. But if the additional slots in the scalar are cleared at assignment, that is a very different sort of assignment to an item than a property such as will only hold integers or will only hold dogs or dog subtypes which does not vary and can be used by the compiler. I propose: use but to override the default intrascalarvalue conversions, such as $line = readline but true; or even better, $line = readline; $line = $line but boolean(is_section_end_markerp($line)); Although this second use begs the question, Why bother with combining types if you're going to override them? Maybe overriding is not such a good idea anyway? Are there really that many situations where having Truth autogenerated from number/text-string isn't confusing and bug-prone already? reserve is for compiler optimization hints: my $line is text; I have not read the earlier discussion in the thread I am adding this posting to, or the essays referred to by them. The above is/but distinction is something that I believe needs to be made, by any names, because without it there will be confusions
Re: 'is' and action at a distance
Larry Wall [EMAIL PROTECTED] writes: That's part of why I named it btw in the first place. The problem with prop is it's not quite obscure enough. In the Netherlands, we have a value added tax named BTW. So it's not unlikely for financial programs to implement a btw property or method... -- Johan
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 11:26:36AM +1000, Damian Conway wrote: Not. The run-time property is set on the *value* in $Foo, not on the variable itself. Change the value, change the properties. Ok, that makes me happy. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
Re: 'is' and action at a distance
LW == Larry Wall [EMAIL PROTECTED] writes: LW I think it would be better if we stilled two curds with one bone. We LW can have a more obscure name, plus differentiate the prop tables at the LW same time. So how 'bout we have two methods, such as: LW $foo.variable_is LW $foo.value_is hmm, in catching up with mail i saw damian's long property exegesis and i replied with a suggestion asking to split the value/permanent (or as above value/variable) props and then i see this. good to know i am on the right wavelength. but can a code ref a set of variable properties? that is why i am using the term permanent (or set at compile time and unmutable). another point: how can you delete properties? obviously this can only be done with value properties. an accessor method has no clean way of separating plain access $foo.bar() from some way to assign a null list to it. you can assign an explict undef but that is not the same as deletion. so a delete_value_prop func/method should be supported in some fashion. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: 'is' and action at a distance
Richard Proctor [EMAIL PROTECTED] writes: On Fri 18 May, Damian Conway wrote: Ed wrote: Can 'undef' valued thingys have properties Yes. and functions? No. Why not? You can always set a property on a function reference. But it seems a little weird that functions can have properties in perl5, but not in perl 6. -- Piers Cawley www.iterative-software.com
Re: 'is' and action at a distance
Graham Barr [EMAIL PROTECTED] writes: On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote: Also, what's the difference between a 'property' and an 'attribute', ie, are: $fh is true; and $fh.true(1); synonyms? No. The former means: Set the true property to 1 and return an alias to $fh The latter means: Attempt to call the Ctrue method of $fh. If there is no such method, set the true property to 1 and return that value This is something that concerns me. There is no real separation between methods and properties. I can see it causing problems due to them sharing namespaces. But I have not thought about it enough to say how much of a concern. There's a part of me that sees this as a bonus. -- Piers Cawley www.iterative-software.com
Re: 'is' and action at a distance
Graham Barr [EMAIL PROTECTED] writes:
On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
It's probably just a matter of coding what you actually mean.
In Perl 5 and 6 your version means if $fh is true in *any*
possible way..., whereas you seem to want if $fh is defined,
which is:
Hmm. I can easily see this producing incomprehensible code when spread
across large systems. To wit, those developers used to 0 means false
Any feature is incomprehensible if one is not used to it. Pointers
in C are incomprehensible if one has never met the concept before.
Right, consider overloading.
As far as I understand one rationale behind the false (in Perl 5 terms)
but true (in Perl 6 terms) is that you can write code like this
if ($retval = func(@args)) {
# it worked ...
Right. Which of course can be done in Perl 5 with either 0 but
true (or 0E0) or if the value is an object, the use of
overloading.
But what you can't do with 0E0 is the else branch of that example,
accessing C$retval.what_went_wrong, which would be really handy...
--
Piers Cawley
www.iterative-software.com
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: print keys $foo.prop; # prints NumberHeard print values $foo.prop; # prints loneliestever This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Graham.
Re: 'is' and action at a distance
Piers wrote: Can 'undef' valued thingys have properties Yes. and functions? No. Why not? You can always set a property on a function reference. But it seems a little weird that functions can have properties in perl5, but not in perl 6. H. I read Ed's original questions as: Can 'undef' valued thingys have properties? and: Can 'undef' valued thingys have functions? That's why I said no to the second. If the second question was actually: Can functions have properties? Then the answer is, of course, yes. Damian
Re: 'is' and action at a distance
Graham wrote: On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: print keys $foo.prop; # prints NumberHeard print values $foo.prop; # prints loneliestever This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? No, we have basically said that there cannot be a method called prop if you want to access the object's properties through its prop property. Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Er...yes...that's rather the point of the exercise: to be able to polymorphically override the behaviour of properties by defining methods. Should we deprecate inheritance because the functionality of a working program can be completely changed/broken by defining a derived method that conflicts with an inherited method? Damian
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote: Graham wrote: On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: print keys $foo.prop; # prints NumberHeard print values $foo.prop; # prints loneliestever This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? No, we have basically said that there cannot be a method called prop if you want to access the object's properties through its prop property. Which mean that any class which defines a method prop, prevents any user from determining the properties of any of its object instances. I am not saying that this is a bad thing, but it will need to be docuemnted that doing this has such consequences. Unless there is another syntax for determining all the properties of a value. Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Er...yes...that's rather the point of the exercise: to be able to polymorphically override the behaviour of properties by defining methods. I am just not conviced that it is a good thing todo. methods and properties are different things. Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote: Also, what's the difference between a 'property' and an 'attribute', ie, are: $fh is true; and $fh.true(1); synonyms? No. The former means: Set the true property to 1 and return an alias to $fh The latter means: Attempt to call the Ctrue method of $fh. If there is no such method, set the true property to 1 and return that value This is something that concerns me. There is no real separation between methods and properties. I can see it causing problems due to them sharing namespaces. But I have not thought about it enough to say how much of a concern. Graham.
Re: 'is' and action at a distance
--- Damian Conway [EMAIL PROTECTED] wrote: It's probably just a matter of coding what you actually mean. In Perl 5 and 6 your version means if $fh is true in *any* possible way..., whereas you seem to want if $fh is defined, which is: Hmm. I can easily see this producing incomprehensible code when spread across large systems. To wit, those developers used to 0 means false semantics seeings a scalar that they just know has a 0 in it and wondering why the branch isn't doing what they know it should. This will have to be addressed using a coding convention of some sort, I suppose. What's the verbose way to query the is true property of a thingy? Can 'undef' valued thingys have properties Yes. and functions? No. Aren't things like memoizability essentially properties? =Austin __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
It's probably just a matter of coding what you actually mean.
In Perl 5 and 6 your version means if $fh is true in *any*
possible way..., whereas you seem to want if $fh is defined,
which is:
Hmm. I can easily see this producing incomprehensible code when spread
across large systems. To wit, those developers used to 0 means false
Any feature is incomprehensible if one is not used to it. Pointers
in C are incomprehensible if one has never met the concept before.
As far as I understand one rationale behind the false (in Perl 5 terms)
but true (in Perl 6 terms) is that you can write code like this
if ($retval = func(@args)) {
# it worked ...
} else {
# it didn't ...
# but we still can dig out more information
# about the result ...
print $retval.what_went_wrong, \n;
}
semantics seeings a scalar that they just know has a 0 in it and
wondering why the branch isn't doing what they know it should.
Free your mind-- detach the truth of a scalar from its '0 or or undef'
nature.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
It's probably just a matter of coding what you actually mean.
In Perl 5 and 6 your version means if $fh is true in *any*
possible way..., whereas you seem to want if $fh is defined,
which is:
Hmm. I can easily see this producing incomprehensible code when spread
across large systems. To wit, those developers used to 0 means false
Any feature is incomprehensible if one is not used to it. Pointers
in C are incomprehensible if one has never met the concept before.
Right, consider overloading.
As far as I understand one rationale behind the false (in Perl 5 terms)
but true (in Perl 6 terms) is that you can write code like this
if ($retval = func(@args)) {
# it worked ...
Right. Which of course can be done in Perl 5 with either 0 but true (or 0E0)
or if the value is an object, the use of overloading.
Graham.
Re: 'is' and action at a distance
[EMAIL PROTECTED] writes: : Also, what's the difference between a 'property' and an : 'attribute', ie, are: : :$fh is true; : : and : :$fh.true(1); : : synonyms? : : No. The former means: : : Set the true property to 1 and return an alias to $fh Or $fh itself, unless properties end up be implemented as delegation. : The latter means: : : Attempt to call the Ctrue method of $fh. If there is no such : method, set the true property to 1 and return that value I'd make an argument that it should return the old value of the property. : Can 'undef' valued thingys have properties : : Yes. Agreed, and I think this is where you'll see properties used the most! : and functions? : : No. Functions can at least have compile-time properties. : And if all of the above is true, what does this do to the size of : the internal representation of a scalar? : : In the worst case, it adds a single pointer to it. But it's entirely : possible that properties would be stored centrally, in which case : there's no impact at all. I don't know if central storage will work out without the connivance of a sympathetic GC, but in any event, it is my hope that no value without properties will be required to store anything extra to support properties (with the possible exception of a bit saying whether there are properties). But as Damian says, worst case is a single pointer. Larry
Re: 'is' and action at a distance
I don't see that at all. We're simply providing one more
way for a value to be true, and one more way for it to be false.
You might as well argue that the following is action-at-a-distance:
undef $fh;
$fh = 0 but true;
... 1200 lines later...
if ($fh) { print HERE!!!\n; }
No, because you can say:
print $fh;
and find out exactly what is going on.
In the case with
undef $fh;
$fh is true.
if ($fh) { print HERE!!!\n; }
print $fh;
you get nada, right?
So... why the *$#$ is it getting into the loop?
There has to be a method to print out the *contents* of $fh, not just the
values.
Ed
Re: 'is' and action at a distance
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? I can see the need for wanting to disassociate truth from value (I've wanted it myself) but if $Foo remains true, even after I've assigned a false value to it, then yes, that does count as action-at-a-distance and is probably a Bad Thing. However, if assigning to $Foo clears the eariler assertion of truth, then there's no problem. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One You see, in this world there's two kinds of people. Those with loaded guns, and those who dig. Dig. -- Blonde, The Good, The Bad And The Ugly
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
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
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)
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)
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)
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)
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)
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: 'is' and action at a distance
Ed said:
No, because you can say:
print $fh;
and find out exactly what is going on.
In the case with
undef $fh;
$fh is true.
if ($fh) { print HERE!!!\n; }
print $fh;
you get nada, right?
Right.
So... why the *$#$ is it getting into the loop?
There has to be a method to print out the *contents* of $fh, not
just the values.
print $fh.true; # Just the truth
print %{(+$fh).prop}; # All the value's properties
Damian
Re: 'is' and action at a distance
Schwern wrote: 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? Not. The run-time property is set on the *value* in $Foo, not on the variable itself. Change the value, change the properties. I can see the need for wanting to disassociate truth from value (I've wanted it myself) but if $Foo remains true, even after I've assigned a false value to it, then yes, that does count as action-at-a-distance and is probably a Bad Thing. Yes. perhaps even a Very Bad Thing. ;-) However, if assigning to $Foo clears the eariler assertion of truth, then there's no problem. Yep. Damian
Re: 'is' and action at a distance
So... why the *$#$ is it getting into the loop?
There has to be a method to print out the *contents* of $fh, not
just the values.
print $fh.true; # Just the truth
print %{(+$fh).prop}; # All the value's properties
um.. I'm not the greatest fan of this syntax.. what's the '+' for? And the
parens? And I'm assuming that $fh.prop is a hash, can the property hash itself
have properties?
Ed
Re: 'is' and action at a distance
Ed asked:
print %{(+$fh).prop};# All the value's properties
um.. I'm not the greatest fan of this syntax.. what's the '+' for?
As I explained at the end of the re: properties message, it's to evaluate
$fh, so we get the hash of properties belonging the value in $fh,
not those belonging to the variable itself.
And the parens?
To make the precedence clear.
And I'm assuming that $fh.prop is a hash, can the property hash itself
have properties?
Almost certainly not, as it's quite possible that the property hash will
only be built on-demand.
Damian
Re: 'is' and action at a distance
Ed wrote:
Any ideas on how to handle this with the 'is' keyword? I was
reading the slashdot comments to Exegesis II, and this seemed to be
the one issue that had merit. A couple of the posters bemoaned the
fact that they were debugging PL/I about 25 years ago, and had code
that depended on some obscure property being set somewhere earlier,
which affected the code 1200 lines later.
I could see that being a problem:
undef $fh;
$fh is true;
... 1200 lines later...
if ($fh) { print HERE!!!\n; }
In other words, 'is' seems to me to be a generous helping of
action at a distance.
I don't see that at all. We're simply providing one more
way for a value to be true, and one more way for it to be false.
You might as well argue that the following is action-at-a-distance:
undef $fh;
$fh = 0 but true;
... 1200 lines later...
if ($fh) { print HERE!!!\n; }
It's probably just a matter of coding what you actually mean. In Perl 5
and 6 your version means if $fh is true in *any* possible way...,
whereas you seem to want if $fh is defined, which is:
if (defined $fh) { print HERE!!!\n; }
in both Perl 5 and Perl 6.
Is dumper going to become a built in keyword to handle this sort
of thing?
Huh? I don't see the connection.
Also, what's the difference between a 'property' and an
'attribute', ie, are:
$fh is true;
and
$fh.true(1);
synonyms?
No. The former means:
Set the true property to 1 and return an alias to $fh
The latter means:
Attempt to call the Ctrue method of $fh. If there is no such
method, set the true property to 1 and return that value
Can 'undef' valued thingys have properties
Yes.
and functions?
No.
And are the traditional data elements of a scalar (like value)
simply attributes of a universal scalar object?
No.
Though the operations on a scalar might well be methods of the SCALAR class.
And if all of the above is true, what does this do to the size of
the internal representation of a scalar?
In the worst case, it adds a single pointer to it. But it's entirely
possible that properties would be stored centrally, in which case
there's no impact at all.
Damian
Re: 'is' and action at a distance
On Fri 18 May, Damian Conway wrote: Ed wrote: Can 'undef' valued thingys have properties Yes. and functions? No. Why not? Richard -- [EMAIL PROTECTED]
