Unary dot and custom control
I came across this slight annoyance working in Perl 5 today:
sub preserve() {...}
sub foo {
preserve {
$_[0]-bar;
}
}
That didn't call bar on the invocant of foo, but rather on undef,
because preserve's block was a hiding sub.
Perl 6 is making it easier to define custom block constructs like this
one. I worry about:
method foo () {
preserve {
.bar;
}
}
This one's a tad more subtle. Normally preserve's block would be 0-ary.
But in this case it's unary, since it implicitly references $_.
Is there a way to declare preserve so that its block will always be
parsed 0-ary? if is certainly able to do this (consider the above
example with s/preserve/if $baz/).
Luke
Re: Unary dot and custom control
On Mon, Sep 20, 2004 at 07:25:14AM -0600, Luke Palmer wrote:
: Perl 6 is making it easier to define custom block constructs like this
: one. I worry about:
:
: method foo () {
: preserve {
: .bar;
: }
: }
:
: This one's a tad more subtle. Normally preserve's block would be 0-ary.
: But in this case it's unary, since it implicitly references $_.
:
: Is there a way to declare preserve so that its block will always be
: parsed 0-ary? if is certainly able to do this (consider the above
: example with s/preserve/if $baz/).
Such a block is parsed as 1-ary, but with an implicit argument that
defaults to the caller's $_, something like:
preserve sub ($_ = $CALLER::_) {
.bar;
}
Then it effectively becomes a run-time decision by preserve whether
to treat it as 0-ary or 1-ary.
Larry
Re: Unary dot
On Tue, Apr 16, 2002 at 09:29:21AM -0400, Miko O'Sullivan wrote: Wouldn't Know a Tagmemic if it Bit Him on the Parse Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) Allison
Tagmem* (was Unary dot)
Wouldn't Know a Tagmemic if it Bit Him on the Parse Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) You got it! I hope this isn't too off topic, but... is the word tagmeme somehow related to the urban legend concept of a cultural meme? -Miko
Re: Unary dot
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as Do(t) The Right Thing to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing virtual
methods that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of Ckeys %$hash
or C$hash-{keys}.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo-keys()
foo.{keys} $foo.{keys} $foo-{keys} $foo-keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
Have I missed a vital clue?
A
Re: Tagmem* (was Unary dot)
Miko O'Sullivan writes: : Wouldn't Know a Tagmemic if it Bit Him on the Parse : : Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I : like it! :) : : You got it! : : I hope this isn't too off topic, but... is the word tagmeme somehow : related to the urban legend concept of a cultural meme? Not really. Pike predates Dawkins, who I believe made up the term. (Could be wrong about that.) They are similar concepts, however, in that a tagmeme is a psychological linguistic construct that propagates culturally. It's certainly possible that Dawkins read Pike. But it's also quite likely that he didn't, and made up meme as a portmanteau on gene and memory. Doubtless the latest OED could shed some light on that. Larry
Re: Tagmem* (was Unary dot)
On Tue, 16 Apr 2002 09:34:36 -0700 (PDT), Larry Wall [EMAIL PROTECTED] wrote: Pike predates Dawkins, who I believe made up the term. (Could be wrong about that.) They are similar concepts, however, in that a tagmeme is a psychological linguistic construct that propagates culturally. It's certainly possible that Dawkins read Pike. But it's also quite likely that he didn't, and made up meme as a portmanteau on gene and memory. On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more euphonic version of mimeme: http://www.santafe.edu/~shalizi/formerly-hyper-weird/memetics.html /L/e/k/t/u
Re: Unary dot
Andy Wardley [EMAIL PROTECTED] writes:
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as Do(t) The Right Thing to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing virtual
methods that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of Ckeys %$hash
or C$hash-{keys}.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo-keys()
foo.{keys} $foo.{keys} $foo-{keys} $foo-keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
$foo = %hash; # Take a reference to %hash;
$foo.{keys} # get the value keyed by 'keys' in the hash refered
# to by $foo.
$bar = Object.new # Make an object
$bar.{keys} # Get the value of $bar's '$.keys' instance
# variable.
I think that the '.' is optional in this case too...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Piers Cawley writes:
: Andy Wardley [EMAIL PROTECTED] writes:
: Hang on, now I'm a little confused - I thought that hashes were supposed
: to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
: But then that would then violate the uniform access principle because
: hash/key access has a different syntax from object/method?
%foo is just a typed reference varaible. $foo works just about as well.
: $foo = %hash; # Take a reference to %hash;
I'd say Copy a reference, since I think of %hash as a reference already.
: $foo.{keys} # get the value keyed by 'keys' in the hash refered
: # to by $foo.
: $bar = Object.new # Make an object
: $bar.{keys} # Get the value of $bar's '$.keys' instance
: # variable.
Mmm. I think it always calls the virtual method, which might or might
not map directly to $.keys, depending on how fancy the accessors get.
If you want a particular type's method regardless of the actual type of
the object, you have to do as in Perl 5 and say
$bar.This::Type::keys()
: I think that the '.' is optional in this case too...
Yes, as long as there's no whitespace before it. I imagine some style
guides will require the dot for that reason. I can just see some poor
schmuck walking out of a job interview because the company requires
dots on all hash subscripts. :-)
Larry
Re: Tagmem* (was Unary dot)
Juanma Barranquero wrote: On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more euphonic version of mimeme: On quickly scanning that message I read the last word as mini-me, which brought up some *very* unlikely associations! :-) Damian -- So, Mr. Evil... It's Dr. Evil, I didn't spend six years in Evil Medical School to be called 'mister', thank you very much.
Re: Unary dot
On Mon, 15 Apr 2002, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintstone;
Or are class instances limited only to scalars? The former seems a bit
counterintuitive...
Luke
Re: Unary dot
On 4/15/02 1:16 AM, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
How? Perl 5 code doesn't use ., and if Perl 5 code has to be changed
anyway, why not change it all the way?
(not to mention legacy Perl 5 OO coders ;-)
I dunno, the $foo.{bar_attr} calls a method thing seems kind of pointless
(and mildly evil) to me. It seems like a throwback to the bad old days of
tied-hashes-as-oo.
-John
Re: Unary dot
$foo.{bar_attr} = 1;
This would help Perl 6 support legacy Perl 5 OO code
How? Perl 5 code doesn't use ., and if Perl 5 code has to be changed
anyway, why not change it all the way?
Because changing:
$foo-{bar_attr}
to:
$foo.{bar_attr}
is a generic, purely syntactic change and easily automated, whereas changing
it to:
$foo.bar_attr
is a semantic change (why does *this* particular instance change to a method
call, rather than a hash look-up?) and consequently *much* harder to get right.
(not to mention legacy Perl 5 OO coders ;-)
I dunno, the $foo.{bar_attr} calls a method thing seems kind of pointless
(and mildly evil) to me. It seems like a throwback to the bad old days of
tied-hashes-as-oo.
Sure. *You* would never do it. Neither would I. But TMTOWTDI.
And if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Damian
Re: Unary dot
Luke Palmer wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintstone;
No. Not as you envisage it. Perl 6 objects aren't hashes.
Or are class instances limited only to scalars? The former seems a bit
counterintuitive...
Yep. Perl 6 usage in this respect will be like Perl 5 usage. The constructor of
a class will return a reference, which will normally be stored in a scalar.
The difference in Perl 6 is that the object is an opaque type: not a hash,
not an array, not a scalar, sub, regex, glob, but a mysterious, encapsulated,
impenetrable something of type OBJECT.
The Coperator:{} method of which I spoke is the perl 6 equivalent of the
CFETCH method of a tied hash (but without having the overhead of tying anything).
Damian
Re: Unary dot
On 4/15/02 5:16 PM, Damian Conway wrote:
if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Okay, how about making it a pragma that's not enabled by default? So all
those Perl 5 porters can do their mechanical transformation of -{} to .{}
and then add a no strict hashmethods; (or something) to the top of the
file? Leaving auto-method-call-on-{} in Perl 6 enabled by default seems
like a tacit endorsement of that style (albeit a purely visual distinction
in Perl 6, but why even endorse that?)
(stage 2: bargaining ;)
-John
Re: Unary dot
[EMAIL PROTECTED] writes:
: On 4/15/02 5:16 PM, Damian Conway wrote:
: if we don't support this, people will be forever having to create Perl 6
: adapter classes just so that they can make use of legacy Perl 5 code. :-(
:
: Okay, how about making it a pragma that's not enabled by default? So all
: those Perl 5 porters can do their mechanical transformation of -{} to .{}
: and then add a no strict hashmethods; (or something) to the top of the
: file? Leaving auto-method-call-on-{} in Perl 6 enabled by default seems
: like a tacit endorsement of that style (albeit a purely visual distinction
: in Perl 6, but why even endorse that?)
:
: (stage 2: bargaining ;)
Heh. Well. The main point of doing this isn't really the migration
from Perl 5, but a basic underlying philosophy of linguistics known as
tagmemics. The grammars of natural language are a convenient cultural
fiction, but within a particular context, you can often violate the
official grammatical and lexical rules in order to communicate. A
common manifestation of this in English is the verbing of nouns.
Just because something is officially a noun in English doesn't mean it
can't *function* as a verb. (In computer science this concept tends to
show up more under the term polymorphism, but it's a similar idea.)
More violent examples are easy to come up with. For instance, you can
use an entire sentence as an adjective:
I don't like your I-can-use-anything-as-an-adjective attitude.
The point is, natural languages aren't terribly picky about what you
poke into a particular grammatical slot as long as it makes sense.
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that. And the default operator:{} method will let the user access the
existing accessors as if they were keys in a hash. And maybe even use
keys() on the object to get a list of available accessor method names.
If you don't want your objects used this way, it'd be trivial to
override the operator:{} method.
As for avoiding it via a pragma, I'd consider that error prone.
Suppose you call an interface that is defined to return a hash. The
module writer could decide to upgrade the interface to return an object
pretending to be a hash, and your code would break if it had already
decided on its own that only hashes can behave like hashes.
Larry
Re: Unary dot
On 4/15/02 10:24 PM, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
Sure, by why should that be the default?
And the default operator:{} method will let the user access the
existing accessors as if they were keys in a hash. And maybe even use
keys() on the object to get a list of available accessor method names.
I think I liked this idea better when it was called tied hashes, and when it
had to be explicitly enabled by the programmer, rather then explicitly
disabled.
If you don't want your objects used this way, it'd be trivial to
override the operator:{} method.
I'd turn that around and say: if you want your object to behave like a hash,
it'd be trivial to inherit from the HashAccessors class (or whatever). It
just doesn't seem like something that should be in UNIVERSAL (or on by
default, however that's implemented in Perl 6).
IMO, fancy tie-like object-as-another-data-type (tagmemics? ;) features
should need to be explicitly enabled by inheritance and/or operator
overloading (I see your point about the pragma technique).
-John
Re: Unary dot
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote: Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. But now we have endless possibilities for $self.ish $self.less $self.centred $self.obsessed etc. -- But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged. Lady Croom - Arcadia
Re: Unary dot
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle...It sounds as though Perl 6 is heading towards supporting
this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
write:
class Foo { # version 1
my $.bar_attr is public;
}
then you'll get an automagically created lvalue accessor method that will allow
you to write:
my $foo = Foo.new();
$foo.bar_attr = 1;
and then later define a real CFoo::bar_attr method to encapsulate it:
class Foo { # version 2
my $.bar_attr;
method bar_attr is rw($rvalue) () {
if exists $rvalue {
croak Negative value if $rvalue 0;
$.bar_attr = $rvalue;
}
return $.bar_attr;
}
}
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
(not to mention legacy Perl 5 OO coders ;-)
Damian
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 05:34:13PM -0700, Glenn Linderman wrote:
Allison Randal wrote:
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
$_ becomes lexical
Sound logic. And it almost did go that way. But subs that access the
current $_ directly are far too common, and far to useful.
One thing I'm missing is how those common useful subs that access the
current $_ directly will be affected by $_ becoming lexical...
Or perhaps $_ stays global, but gets automatically restored at the end
of blocks in which it is changed, so that it appears lexical in value,
even though it is global in the name space ???
No, it is truly lexical. Absolutely, positively.
And you're right that this should present a problem. The lexical scope
of a subroutine is the lexical scope where it was defined, not the
lexical scope where it was evaluated. So, typical subs can only access
global external variables, while closures and lexical subs access
external variables from the scope in which they were defined.
I suspect I've imperfectly represented the original idea, but I'll
proceed as devil's advocate, for the sake of discussion...
What if $_ were dynamically scoped, but only for subroutines? Dynamic
scoping is not necessarily the same thing as a global $_. It would
merely pretend (only for $_) that the subroutine had been defined in the
scope where it was evaluated. But that could get you into trouble with
recursion. So then you would want some way to explicitly either turn on,
or turn off, dynamic scoping for a specific subroutine. The Cis given
(or Cis topic) property would be an obvious way to turn it off (since
it would create a $_ scoped to the subroutine). But, what if you wanted
it off by default? It could be turned on either as a characteristic of
the sub as a whole, or as a characteristic of an individual parameter:
sub foo is dynamic_topic {
...
}
sub foo ($bar is topic_preserving, $baz) {
...
}
The property Cis topic_preserving would be both binding the value of
the $_ in the calling scope to $bar and making $bar the current topic in
the scope of the sub.
The subroutine property would be basically the same, but wouldn't give
you a named variable, and also wouldn't require you to include an extra
parameter (which could be nice).
Allison
Re: How to default? (was Unary dot)
Allison Randal wrote:
What if $_ were dynamically scoped, but only for subroutines? Dynamic
scoping is not necessarily the same thing as a global $_. It would
merely pretend (only for $_) that the subroutine had been defined in the
scope where it was evaluated. But that could get you into trouble with
recursion. So then you would want some way to explicitly either turn on,
or turn off, dynamic scoping for a specific subroutine. The Cis given
(or Cis topic) property would be an obvious way to turn it off (since
it would create a $_ scoped to the subroutine). But, what if you wanted
it off by default? It could be turned on either as a characteristic of
the sub as a whole, or as a characteristic of an individual parameter:
sub foo is dynamic_topic {
...
}
sub foo ($bar is topic_preserving, $baz) {
...
}
The property Cis topic_preserving would be both binding the value of
the $_ in the calling scope to $bar and making $bar the current topic in
the scope of the sub.
The subroutine property would be basically the same, but wouldn't give
you a named variable, and also wouldn't require you to include an extra
parameter (which could be nice).
OK, I can see how all these things could work. Off hand, it seems like
defaulting to is dynamic_topic would make more of those common useful
$_-dependent subroutines work without change, but I guess if the perl 5
to 6 translator can detect use of $_ before definition of $_ within a
sub accurately, that it could provide the appropriate annotation during
conversion. And personally, I haven't written subs that assume dynamic
$_ usage (I think), so I'm not too concerned about which way the default
goes. I'm not a real heavy user of $_ for everything, as some people
seem to be. It's useful at times, but can also be confusing at times.
Regarding is topic_preserving: I assume that it would not have to be the
first parameter; it would generally be more useful as the last, I
expect, as in split, or the first optional parameter. Of course, there
are cases where first and last are the same, or the other parameters can
also be usefully defaulted when the first one is, etc.
There'd be an interaction between is topic_preserving, default parameter
values, and explicit parameter values which should be clarified. Now I
understand why someone suggested using //= $_ instead of is
topic_preserving, somewhere along the line. Clearly if the user
supplies the parameter, is topic_preserving would limit itself to making
that parameter available as $_ within the sub. If the user supplied
both //= 3 and is topic_preserving, that would either be a bug or a
feature. I guess as a feature, it would use $_, but if $_ were undef,
then it would use 3 ???
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: How to default? (was Unary dot)
There'd be an interaction between is topic_preserving, default parameter values, and explicit parameter values which should be clarified. Now I understand why someone suggested using //= $_ instead of is topic_preserving, somewhere along the line. Clearly if the user supplies the parameter, is topic_preserving would limit itself to making that parameter available as $_ within the sub. If the user supplied both //= 3 and is topic_preserving, that would either be a bug or a feature. I guess as a feature, it would use $_, but if $_ were undef, then it would use 3 ??? Personally, I like //= $_. It's clear, such that a reader would immediately know what it's doing. topic_preserving, despite being more verbose, is not so clear. Plus, if someone didn't know about that feature, that's probably the first thing they would do (provided they knew about defaults) to accomplish that task. Luke
Re: Unary dot
[EMAIL PROTECTED] writes: : Dave Mitchell wrote: : : The top 20 'my $var' declarations in .pm files in the bleedperl : distribution: : : How *dare* you introduce hard data into this discussion! : Next you'll be wanting to deal in actual facts rather than personal : opinion and sheer guesses!! : : ;-) : : Thanks, Dave. Very illuminating. Of course, one of the big reasons we went with $self was the pun: my $self = shift; which we won't have now. Unless we always hide the invocant and force you to say my $self = invocant; or some such mummery. But that seems a bit retro. Larry
Re: How to default? (was Unary dot)
On Sat, Apr 13, 2002 at 08:53:41AM -0700, Glenn Linderman wrote: Off hand, it seems like defaulting to is dynamic_topic would make more of those common useful $_-dependent subroutines work without change, but I guess if the perl 5 to 6 translator can detect use of $_ before definition of $_ within a sub accurately, that it could provide the appropriate annotation during conversion. ... I agree dynamic scoping of $_ in subroutines by default would make for an easier transition between 5 and 6. And at first I preferred it. But I'm gradually leaning in the opposite direction. The lexical scoping of $_ encourages encapsulation (good coding practice), and minimizes unexpected side effects. I'm not a real heavy user of $_ for everything, as some people seem to be. It's useful at times, but can also be confusing at times. I think the two most confusing aspects of $_ in 5 are the fact that it isn't created consistently (only when there isn't a named alias) and how easy it is to accidentally clobber it. Both of which should be eliminated in 6. :) Regarding is topic_preserving: I assume that it would not have to be the first parameter; it would generally be more useful as the last, I expect, as in split, or the first optional parameter. Of course, there are cases where first and last are the same, or the other parameters can also be usefully defaulted when the first one is, etc. Yeah, any of the properties or //= should work on any parameter in the list. There'd be an interaction between is topic_preserving, default parameter values, and explicit parameter values which should be clarified. Now I understand why someone suggested using //= $_ instead of is topic_preserving, somewhere along the line. Well, topic_preserving wasn't intended as a defaulting mechanism, just as a way of keeping the value of $_ across subroutines, even though it's lexically scoped. That's why I prefer the subroutine property, it makes it clearer that we're fundamentally altering the behaviour of subroutines, instead of making it look like we're just monkeying around with the parameters. For defaulting to the current topic, I'd probaly choose a property name topic_default instead. Possibly it would be helpful to be explicit about the options we're discussing: sub foo ($bar //= $_, ... The parameter can be passed a value, but it will default to the outer $_ if not passed a value. It will not set the value of $bar as topic within the subroutine, so the inner $_ will be undefined (unless there was a global $_ defined, which would produce really anti-dwim behaviour). One thing to consider here is that we're already abusing the $_ is lexical concept to make the $_ of the calling scope accessible as a value for the parameter. If you wanted to also make $bar the topic within the sub, you'd have to use the property Cis given: sub foo ($bar //= $_ is given, ... So, the Cis topic_default property would condense the two behaviours into one. I would guess that if you've defaulted to $_ you would expect it to also be $_ within the sub anyway. sub foo ($bar is topic_default, ... It also makes it clearer that this isn't your ordinary //= default happening, but a special lexical scope bending one. The other proposed property, Cis topic_preserving, wouldn't accept a value passed in, it would only and always be the $_ of the calling scope, and make it the topic within the subroutine scope. sub foo ($bar is topic_preserving, ... Okay, looking at the details laid out like this, I would probably ditch the topic_preserving property in favor of topic_default. But topic_default isn't going to give us perl 5 behaviour. Neither would topic_preserving, because both alter the parameter structure of the sub. So, my favorite final solution: Use the subroutine property dynamic_topic for perl 5 behaviour, topic_default to create Cprint type subs. If the user supplied both //= 3 and is topic_preserving, that would either be a bug or a feature. I guess as a feature, it would use $_, but if $_ were undef, then it would use 3 ??? I'd say a bug. I don't know, can you: sub foo ($bar //= $some_value //= 3, ... (Presuming that $some_value is a true global or otherwise accessible in the scope where the sub was defined.) If you can do that, then it should probably work the same for $_ defaulting. Allison
Re: How to default? (was Unary dot)
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
Assuming we *get* multidispatch that is. It would be nice to hope that
the compiler could optimize that...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
Perhaps
sub printRec(-$rec)
I'm just throwing that out, but some way to say that the argument
defaults to getting the topic would seem to be called for.
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
If $_ is lexical by default (did larry say this somewhere?), then I'm
sure we can make it dynamic on request ala:
for $_ is temp {
printRec;
}
I may have the syntax slightly borked but you get the idea.
I read the original posters message the same as Piers though.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Graham.
Re: How to default? (was Unary dot)
On Fri, 2002-04-12 at 09:52, Jonathan Scott Duff wrote:
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is that your first printRec would not have a
$_ available to it (lexically scoped, as I understand it).
You've got a problem here, which I don't think there's a mechanism for.
If $_ is lexical by default (did larry say this somewhere?), then I'm
sure we can make it dynamic on request ala:
Nope, I don't think that works. If the caller of printRec has to do
something special, we're meeting the original request which is to be
able to write print, which scoops up $_ without any special case code.
Now, we can say, you just can't ever write print. I can understand why
we would, but why NOT just allow the subroutine author to indicate that
the subroutine acquires the current topic as a parameter default? It
would seem nice and clean. Either
foo($a=$_){}
as Graham suggests, or
foo(-$a){}
which was mine. Either one works. I guess with the aliasing of $_,
Graham's seems cleaner to me.
Of course, the other conversation pending, we might end up with:
foo($a//=$_){}
which doesn't do the same thing as print, but may be the best we can do
with the syntax we have.
I read the original posters message the same as Piers though.
Ok, what did you get from it that's different?
Re: How to default? (was Unary dot)
- Original Message -
From: Graham Barr [EMAIL PROTECTED]
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Would it would be reasonable to have given default to the caller's topic?
sub printRec {
given {
# $_ is now the caller's topic in this scope
}
}
Perhaps Cgiven caller.topic {} would work as well.
Ashley Winters
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Ashley Winters writes:
Would it would be reasonable to have given default to the caller's topic?
sub printRec {
given {
# $_ is now the caller's topic in this scope
}
}
Perhaps Cgiven caller.topic {} would work as well.
Yes, something like that would be nice. Of course, you could say, Cgiven
caller.MY{'$_'}, but I think there's two separate things going on here:
1) There should probably be something in the syntax to allow for
retopicalization of the up-scope topic
2) It may be useful to have some way to allow single-parameter blocks to
take the up-scope topic as a first parameter.
Trey
Re: How to default? (was Unary dot)
On Fri, 12 Apr 2002, Trey Harris wrote:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
Assuming the input file 1\n2\n3\n, I want to end up with:
:1:
:2:
:3:
:Done!:
I assume I'm missing something in the sub printRec { line. But what?
(I also assume, perhaps incorrectly, that I won't have to resort to
anything so crass as checking whether my first parameter is defined...)
Couldn't you do it with old-style Perl5 subs?
sub printRec {
my $p = chomp(shift // $_);
print :$_:\n
}
Or am _I_ missing something?
Luke
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
Couldn't you do it with old-style Perl5 subs?
sub printRec {
my $p = chomp(shift // $_);
print :$_:\n
}
Or am _I_ missing something?
That definitely won't work (aside from the $p/$_ swap which I assume is
unintentional), because $_ is now lexical. If my understanding is correct
and $_ is always the topic, and the first parameter of any block is always
the topic, that would make your code somewhat equivalent to:
sub printRec {
my $p;
if (defined _[0]) {
$p = shift;
} else {
$p = _[0];
}
print :$p:\n;
}
Or is the topic of a block mutable (i.e., will a shift cause the topic to
shift as well)? If so, I guess your code is actually is equivalent to:
sub printRec {
my $p = chomp(shift // shift);
print :$p:\n;
}
Either way, bizarre, no? What I *think* you meant to say is:
sub printRec {
my $p = chomp(shift // caller.MY{'$_'});
print :$p:\n
}
which should certainly work, it just makes my skin crawl--vestiges of
Perl 4 still coming to bite us, or something.
Trey
Re: How to default? (was Unary dot)
Oops, caught my own mistake...
In a message dated Fri, 12 Apr 2002, Trey Harris writes:
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
sub printRec {
my $p = chomp(shift // $_);
print :$_:\n
}
[Should be equivalent to]
sub printRec {
my $p = chomp(shift // shift);
print :$p:\n;
}
Actually, it should be equivalent to
sub printRec {
my $p = chomp(shift // _[0]);
print :$p:\n;
}
No shifting is happening just by referring to $_.
Because $_ is always the topic, which is always the first parameter to a
block, which in subroutines is _[0], right? So in a sub, $_ == _[0].
The only question I have is if you modify _ with a shift, does $_
continue to point at the old _[0], or does it now point at the new _[0],
the original _[1]?
Trey
Re: Unary dot
On Thu, Apr 11, 2002 at 08:49:40AM -0700, Larry Wall wrote:
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
That is, in fact, calling an accessor function, and if it's not allowed,
it's because the attribute is marked private, not because we're against
people thinking of it as a struct.
: External code should not access instance
: variables. We did discuss the idea that accessors would be created
: automatically, and coincidentally, you're using the correct syntax for
: that above, but certainly there should be the ability to override the
: default accessor and to declare an instance variable as accessor-less.
By default attributes are private, which means the corresponding
accessor name is also private. There's no need to override the
automatic accessor merely to make something accessor-less to the
general public.
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
since I've already said that any object can be used as if it were a
hash. Plus we'll have lvalue methods in some fashion or other. Not by
default, of course. It's up to the class to decide how much it wants
to break encapsulation.
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle, which he describes as All services offered by a module
should be available through a uniform notation, which does not betray
whether they are implemented through storage or through computation.
In other words, the users of my module shouldn't have to worry about
whether they are calling a method or accessing an instance variable, and
when I change my implementation from one to the other they shouldn't
have to change their code.
See http://www.elj.com/elj/v1/n1/bm/urp/ for more details.
Languages like C++ don't support this and you end up writing lots of
accessor functions. Do that in Perl 5 and you pay the price of calling
a subroutine.
It sounds as though Perl 6 is heading towards supporting this. Have we
actually got there?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: How to default? (was Unary dot)
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: $_ becomes lexical $_ gets aliased to the first topic of a given clause (hence changes value more often, but the lexical scoping helps reduce that impact) Okay. But it sounds like you're saying that Cgiven, and Cgiven only, introduces a topic, and that can't be right. From Ex4: This is a fundamental change from Perl 5, where $_ was only aliased to the current topic in a for loop. In Perl 6, the current topic -- whatever its name and however you make it the topic -- is always aliased to $_. And later: In a Perl 6 method, the invocant (i.e. the first argument of the method, which is a reference to the object on which the method was invoked) is always the topic And obviously a CCATCH block introduces a topic (though I guess we can pretend that CCATCH is a special kind of Cgiven). So I had (wrongly, I guess?) extended this logic to: all blocks taking parameters introduce a topic, which is the first parameter. Which made me think that Csub blocks, too, introduce a topic, which would be equivalent to _[0]. So where did I go wrong? Trey
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 02:44:38AM -0400, Trey Harris wrote:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
Assuming the input file 1\n2\n3\n, I want to end up with:
:1:
:2:
:3:
:Done!:
I assume I'm missing something in the sub printRec { line. But what?
(I also assume, perhaps incorrectly, that I won't have to resort to
anything so crass as checking whether my first parameter is defined...)
The first call to printRec, where you simply want to use the same $_
works without changes. Larry decided that ordinary subs don't
topicalize, partly for this very reason.
But you will be able to tell your subs to topicalize, using a property.
It hasn't been decided yet if this property will be is topic or
is given, probably the latter.
sub printRec ($msg is given) {
...
}
So for the second call to printRec, you could do something like:
sub printRec ($msg //= $_ is given) {
...
}
Which would allow you to default to the outer $_ and make the first
argument the topic. It's kind of ugly, though, and wouldn't deal with
subsequent parameters in quite the way you would want. I much prefer
handling the problem with overloading:
sub printRec {
chomp;
print :$_:\n;
}
sub printRec ($msg is given) {
printRec;
}
Allison
Re: How to default? (was Unary dot)
Okay, first thing to keep in mind, this hasn't been finally-finalized yet. Alot was hashed out in the process of proofing E4, but there will be more to come. On Fri, Apr 12, 2002 at 07:39:17PM -0400, Trey Harris wrote: In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: $_ becomes lexical $_ gets aliased to the first topic of a given clause (hence changes value more often, but the lexical scoping helps reduce that impact) Okay. But it sounds like you're saying that Cgiven, and Cgiven only, introduces a topic, and that can't be right. From Ex4: You are correct, Cgiven is not the only topicalizer. Cfor is too, and -, etc... This is a fundamental change from Perl 5, where $_ was only aliased to the current topic in a for loop. In Perl 6, the current topic -- whatever its name and however you make it the topic -- is always aliased to $_. You could really say topic is just another name for $_. In a Perl 6 method, the invocant (i.e. the first argument of the method, which is a reference to the object on which the method was invoked) is always the topic Emphasis on method. And obviously a CCATCH block introduces a topic (though I guess we can pretend that CCATCH is a special kind of Cgiven). Yes. So I had (wrongly, I guess?) extended this logic to: all blocks taking parameters introduce a topic, which is the first parameter. Which made me think that Csub blocks, too, introduce a topic, which would be equivalent to _[0]. Sound logic. And it almost did go that way. But subs that access the current $_ directly are far too common, and far to useful. (Drat! Now I have to leave for several hours, just when it's getting interesting...) Allison
Re: How to default? (was Unary dot)
Allison Randal wrote: In a message dated Fri, 12 Apr 2002, Glenn Linderman writes: $_ becomes lexical Sound logic. And it almost did go that way. But subs that access the current $_ directly are far too common, and far to useful. One thing I'm missing is how those common useful subs that access the current $_ directly will be affected by $_ becoming lexical... Or perhaps $_ stays global, but gets automatically restored at the end of blocks in which it is changed, so that it appears lexical in value, even though it is global in the name space ??? Guess I haven't got all the Apocalypses memorized :) -- Glenn = Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
Dave Mitchell wrote: The top 20 'my $var' declarations in .pm files in the bleedperl distribution: How *dare* you introduce hard data into this discussion! Next you'll be wanting to deal in actual facts rather than personal opinion and sheer guesses!! ;-) Thanks, Dave. Very illuminating. Damian
Re: Unary dot
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
Ah, but I think the mnemonic value of the '.' more than earns its keep
here. Cour $foo is private is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol table (or syte, to use
Damian's oh so clever term from Perl 5+i) and I'm all for things that
are different *looking* different.
Well, I certainly don't like the aesthetic value of them. They are ugly
as Perl 4. But, I have been caught in C++ making all my private variables
_named _like _this, so I suppose it's analogous. But I don't like being
forced to do it that way.
What if you just want a simple struct-like thing? That's when it becomes
really ugly and dislikable. Erm... wait a minute, how would you do that?
$foo = new Foo;
$foo..instancevar = 7;
I doubt that's it.
$foo.instancevar = 7;
This should not be allowed. External code should not access instance
variables. We did discuss the idea that accessors would be created
automatically, and coincidentally, you're using the correct syntax for
that above, but certainly there should be the ability to override the
default accessor and to declare an instance variable as accessor-less.
In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
thought we had agreed that it would flat out be impossible.
Re: Unary dot
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: Ah, but I think the mnemonic value of the '.' more than earns its keep
: here. Cour $foo is private is doing a slightly different job
: anyway. And instance variables are *not* the same as 'normal'
: variables, they hang off a different symbol table (or syte, to use
: Damian's oh so clever term from Perl 5+i) and I'm all for things that
: are different *looking* different.
:
:
: Well, I certainly don't like the aesthetic value of them. They are ugly
: as Perl 4. But, I have been caught in C++ making all my private variables
: _named _like _this, so I suppose it's analogous. But I don't like being
: forced to do it that way.
:
: What if you just want a simple struct-like thing? That's when it becomes
: really ugly and dislikable. Erm... wait a minute, how would you do that?
:
: $foo = new Foo;
: $foo..instancevar = 7;
: I doubt that's it.
:
: $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
That is, in fact, calling an accessor function, and if it's not allowed,
it's because the attribute is marked private, not because we're against
people thinking of it as a struct.
: External code should not access instance
: variables. We did discuss the idea that accessors would be created
: automatically, and coincidentally, you're using the correct syntax for
: that above, but certainly there should be the ability to override the
: default accessor and to declare an instance variable as accessor-less.
By default attributes are private, which means the corresponding
accessor name is also private. There's no need to override the
automatic accessor merely to make something accessor-less to the
general public.
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
since I've already said that any object can be used as if it were a
hash. Plus we'll have lvalue methods in some fashion or other. Not by
default, of course. It's up to the class to decide how much it wants
to break encapsulation.
Larry
Re: Unary dot
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
Aaron Sherman writes:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
[...]
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
Who agreed to that? First of all, it's perfectly possible that (for a
non-hash) that syntax is isomorphic to
$object.instancevar = 7;
We're in violent agreement ;)
What I was saying was that C$.x ne C$obj.x. One is directly
accessing an instance variable and one is an accessor (which may in fact
be optimized by the compiler in some cases, but the control still lies
in the hands of the class author). Further, I was refering to a previous
thread (no ref handy) where it was stated that instance variables would
be private and accessors would be created automatically (which you
reiterate and clarify in your response here).
I agree that there may be code that looks an awful lot like hash access,
and in practice some of those usages may even BE simple hash access
after compiler optimization. The key difference is that that is all
under the control of the class author (or rather the class author has
the right/ability to give up control). When the author wishes for
something that looks like instance variable access to become a remote
procedure call or have some taint checking performed, this too should be
their choice (and hopefully would not have to involve any Ctieing or
the like, but would instead fall neatly out of the way accessors work).
I think you have agreed with the above, but I was stating it too quicky
in my original post, and it came out like a statement that the syntax of
instance variable access would never be allowed again, when I was only
refering to the semantic.
Re: Unary dot
David == David Whipp [EMAIL PROTECTED] writes: David If every object has a Cclass method (Cref?), then you could David always call class-methods as class.m2(). Wouldn't that be .class.m2(), or did I miss something in the flurry? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Unary dot
On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
Larry Wall [EMAIL PROTECTED] writes:
We're talking about how to make .foo mean self.foo regardless of the
current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that topicalizers would still work...
I think we were talking about both.
Okay, now that thith hath had a chanth to thteep in my brain for a day
or tho... Here's a twist to another perspective:
The thing with this invocant is, you're essentially creating another
$_. It's an accessible named thing that acts as a noun and automatically
receives a value in a particular context. It may be implemented as a
macro, but will be perceived as a variable, another named alias to the
value, since it can be used in all the same contexts as a full
variable. Because of this, I'd like to see it keep the sigil, not by
choice, but by requirement:
use invocant self;
...
method ical {
$self.method_call();
...
}
It's similar to the old concept of topic, before topic and $_ were
unified. Maybe we now have invocantalizers? ;)
Some of the issues:
- The .method_call() syntax is not nearly as appealing if you can't use
it consistently,
but,
- It is desirable, from a language learning/use perspective, for
.some_call() to always act the same within a Cgiven when the topic
is an object, whether the construct is within a method or not (or at
least default to acting the same).
- The natural question, once you realize Perl is holding this
automatically generated value for you (which seems almost, but not
quiet, identical to $_), is Why can't I default to it?,
but,
- One of the reasons for merging $_ and topic was to avoid the confusion
of multiple defaults (and to avoid deprecating $_ to the default
default). Invocants might add that complexity back.
I see two directions the solution could go in. Direction 1 is if you
don't like it, lump it. If you're going to need to access an outer
topic within a nested topicalizer, you should define a named
variable/parameter (method icial ($self:...). This is the path we've
taken with other nested topicalizers.
Direction 2 moves into the more exciting but scarier realm of alternate
defaults. I would suggest that if we do add a) the ability to
automatically populate variables (or macro accessed values) other than
$_ and b) the ability to default to these variables (or macro accessed
values), that we separate the two concepts, either by using two separate
pragmas, or by making the invocant as default an option on the
invocant pragma. I don't think defining a blank invocant name, or
leaving off the name is ostentatious enough to do justice to the drastic
change of altering the topic structure within the scope of all methods
in the class (this is related to the linguistic principle of given vs.
new information, new information is typically marked, more
prominent). Here are a few possibilities:
use invocant self;
use method_default self;
use invocant self is method_default;
my $self is invocant is method_default;
None of these is quite satisfying. All have associated problems: the
first because the method_default pragma couldn't quite stand alone,
the second because of the non-standard use of Cis, the third because
you don't quite want to declare a variable, just specify a default.
Hmm... possibly:
use invocant $self is method_default;
Which solves the first problem, by being a single statement, the second
problem by making the is method_default a property of the variable (or
more literally, a property that is pre-defined to be associated to the
variable when it is instantiated in a method), and totally bypasses the
third problem.
The choice of method_default is intended to specify that the unique
behaviour only affects .method_call() defaults, not the hoi polloi,
garden-variety defaulting constructs, but a better name could be found.
Allison
Re: Unary dot
Allison Randal wrote:
On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
Larry Wall [EMAIL PROTECTED] writes:
We're talking about how to make .foo mean self.foo regardless of the
current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that topicalizers would still work...
I think we were talking about both.
I see two directions the solution could go in. Direction 1 is if you
don't like it, lump it. If you're going to need to access an outer
topic within a nested topicalizer, you should define a named
variable/parameter (method icial ($self:...). This is the path we've
taken with other nested topicalizers.
Yes, yes, be explicit. If the current topic is an object, its methods
get invoked by unary dot, be it inside a method or outside a method.
Direction 2 moves into the more exciting but scarier realm of alternate
defaults.
It could, but how about an alternative?
Need there be a unary dot to specify invocation of an alternate method
in the same class as the method being compiled? In other words, the
following rules:
1) A method implicitly defines the default topic to be the object on
which it was invoked.
2) Unary dot uses the default topic as the object on which to invoke
methods. If the default topic is not an object, an exception results.
3) The function call name space within a method is first other methods
of the same class, then other functions. (This is similar to C++, I
believe)
Hence, given a class containing two methods m1 and m2...
method m1
{
m2; # calls method m2 in the same class
m2; # this should do the same, if the is still permitted
.m2; # syntax error
given ( $other_object )
{
when m2 { ... } # invokes method m2 in the same class
when .m2 { ... } # invokes $other_object.m2
when $_.m2 { ... } # invokes $other_object.m2
when $self.m2 { ... } # syntax error, unless some use invocant
self
# directive is included somewhere in the
scope
# If it is, then invokes method m2 in same
class
}
}
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
.m2; # syntax error
Doesn't that violate your stated rule thatthe default topic within a
method be the invocant? Shouldn't .m2 be equivalent to $_.m2?
--
Mark J. REED[EMAIL PROTECTED]
RE: Unary dot
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
I would expect the the m2() call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.
If every object has a Cclass method (Cref?), then you could
always call class-methods as class.m2().
Dave.
Re: Unary dot
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
.m2; # syntax error
Doesn't that violate your stated rule thatthe default topic within a
method be the invocant? Shouldn't .m2 be equivalent to $_.m2?
Oops. Yep, got me there. I should have wrapped a given $non_object
around that one. Thanks.
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
On Wed, Apr 10, 2002 at 10:50:52AM -0700, Glenn Linderman wrote: Yes, but does it call it as an instance method on the current invocant or as a class method with no invocant? If the former, how would you do the latter? Should both be allowed to exist? Do both exist? Why do both exist? (with the same name). If only one exists, then that would be the one that gets called. Making the decision based on existence implies a requirement that Perl6 methods be explicitly declared as either class or instance. Not that there's anything wrong with that; I'm just not aware of that decision having been made. I guess we won't find out for sure until either Apoc6 or Apoc12? -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
David Whipp wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
I would expect the the m2() call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.
If every object has a Cclass method (Cref?), then you could
always call class-methods as class.m2().
Dave.
Thanks, Dave, that's an excellant idea.
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Also there are issues when just assuming if m1() is a class method,
I call m2() as a class method because m2() may access instance
data that wouldn't exist if it were called staticly.
-Melvin
Re: Unary dot
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
Graham.
Re: Unary dot
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
The same way. If there is a name conflict between subroutine and
methods, then you qualify the subroutine name...
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
--
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.
Re: Unary dot
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
And anyone who says You don't will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, block) {
if $is_rhs { $self.new(+ block( $target, $self.value )) }
else { $self.new(+ block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Glenn Linderman [EMAIL PROTECTED] writes:
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
The same way. If there is a name conflict between subroutine and
methods, then you qualify the subroutine name...
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
This is looking more and more horrible Glenn.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. That one extra '.' in front isn't too much, is it? I like the following, assumed to be within method m1: ..m2();# call m2 the same way m1 was called, instance or class $_.m2(); # same thing? Does the class become the topic in a static method? ..class.m2: # call static m2 within m1's class, regardless of how m1 was called m2() # call subroutine m2 with no arguments, implied or otherwise -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
Allison Randal wrote:
Direction 2 moves into the more exciting but scarier realm of alternate
defaults.
It could, but how about an alternative?
Ah-ha, yet a third Direction!
Need there be a unary dot to specify invocation of an alternate method
in the same class as the method being compiled? In other words, the
following rules:
1) A method implicitly defines the default topic to be the object on
which it was invoked.
As has been mentioned, this is already true.
2) Unary dot uses the default topic as the object on which to invoke
methods. If the default topic is not an object, an exception results.
Well, since all the variable types are now objects, which have methods,
this wouldn't happen. But you would get some sort of exception if there
was no method of that name for the current object.
3) The function call name space within a method is first other methods
of the same class, then other functions. (This is similar to C++, I
believe)
Hence, given a class containing two methods m1 and m2...
method m1
{
m2; # calls method m2 in the same class
m2; # this should do the same, if the is still permitted
.m2; # syntax error
given ( $other_object )
{
when m2 { ... } # invokes method m2 in the same class
when .m2 { ... } # invokes $other_object.m2
when $_.m2 { ... } # invokes $other_object.m2
when $self.m2 { ... } # syntax error, unless some use invocant
self
# directive is included somewhere in the
scope
# If it is, then invokes method m2 in same
class
}
}
I kind of like the idea of having both topic and invocant available
at all times. But, I am concerned at having such a huge semantic
difference (which object you're using) relying on the subtle visual
distinction between m2() and .m2(). I can see a large opportunity for
coder error and newbie misunderstanding. You also lose the visual cue
that says this is a method call, not a subroutine or a built-in
function. In the end I think that might be more confusing than it's
worth.
Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. -- Mark J. REED[EMAIL PROTECTED]
RE: Unary dot
Mark J. Reed wrote On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? Dave.
Re: Unary dot
On Wed, Apr 10, 2002 at 12:12:56PM -0700, David Whipp wrote: Mark J. Reed wrote On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? .. . . and not necessarily the class in which m1 was declared. Good point. I was assuming a simpler, inheritance-free case. -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. Yeah. I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. $_.m2(); # same thing? Does the class become the topic in a static method? If ..m2() were the same as $self.m2(), $_.m2() would only be the same until you entered the scope of another topicalizer. m2() # call subroutine m2 with no arguments, implied or otherwise Agreed. Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: I like the following, assumed to be within method m1: ..m2();# call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. MUA/MTA quoting seems to be getting in the way here - someone's prepending a '.' to avoid sending the SMTP end-of-message sentinel and it's not getting stripped off properly. That was supposed to be a single '.' in front of the m2(). In other words, unary . is the same as binary . with $_ as the LHS, so .m2() would be the same as $_.m2(). Which would have the semantics in my comment above, assuming that the class becomes the topic in static methods. -- Mark J. REED[EMAIL PROTECTED]
Re: Unary dot
Mark J. Reed [EMAIL PROTECTED] writes: On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: ::m2; # calls global subroutine main::m2 main::m2; # calls global subroutine main::m2 This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. That one extra '.' in front isn't too much, is it? I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class Can't say I'm keen on that at all. We already have a '..' operator (admittedly it's binary), and this new, unary .. doesn't really do anything remotely similar (cf unary dot, unary _ and unary +, which have behaviours which are obviously related to the binary forms.). And haven't we done this discussion already? -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
RE: Unary dot
Piers Cawley This may be a case of keep up at the back, but if that is a method call, how do I call a subroutine from within a method ? [...] Yes, I know there's several different ways I could do it, but this approach feels right. I think this comes does to huffmann encoding: which things are common, and which are less common. This probably depends on what you are doing (what paradigm you are following), so its really a question about the nature of perl. The things I've heard people wanting to do are: call method on current topic call method on current invocant call class method on invocant's class call private subroutine defined in current class call global subroutine The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() I see 2 partionings: * by scope: topic, self, named package, global * by invocant: instance, class, none My suggested resolutions: By Scope: global/ named package use the existing Foo::bar syntax; Topic uses unary . syntax; self uses nothing By invocant: infer from current invocant/topic; use foo() for no invocant Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ::foo() = ::foo() Bar::bar() = Bar::bar() class.foo() = ref($self)-foo() .class.foo() = ref($_)-foo() foo(self) = foo($self-self) = $self-self-foo() This assumes that Cclass and Cself are defined in UNIVERSAL Dave.
Re: Unary dot
David Whipp [EMAIL PROTECTED] writes: Piers Cawley This may be a case of keep up at the back, but if that is a method call, how do I call a subroutine from within a method ? [...] Yes, I know there's several different ways I could do it, but this approach feels right. I think this comes does to huffmann encoding: which things are common, and which are less common. This probably depends on what you are doing (what paradigm you are following), so its really a question about the nature of perl. The things I've heard people wanting to do are: call method on current topic call method on current invocant call class method on invocant's class call private subroutine defined in current class call global subroutine The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() I see 2 partionings: * by scope: topic, self, named package, global * by invocant: instance, class, none My suggested resolutions: By Scope: global/ named package use the existing Foo::bar syntax; Topic uses unary . syntax; self uses nothing By invocant: infer from current invocant/topic; use foo() for no invocant Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ::foo() = ::foo() Bar::bar() = Bar::bar() class.foo() = ref($self)-foo() .class.foo() = ref($_)-foo() foo(self) = foo($self-self) = $self-self-foo() This assumes that Cclass and Cself are defined in UNIVERSAL For reasons that I can't quite put my finger on at the moment, I really, really don't like that approach. One of the really nice things about perl 4 was that we didn't have to use any more. Making it essential seems like a horribly retrograde step. I suppose you could require the only when calling subroutines from within a method/class definitions, but I still don't like it. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
The following syntaxes have been seen: foo() .foo() ..foo() ## rejected because .. is different binary op class.foo() FooClass.foo() ::foo() Package::foo() $foo() $_.foo() With a nod to Piers, and with apologes if this is silly in the context of Perl 6 syntax, what about: $.foo -- ralph
Re: Unary dot
On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote: On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: I like the following, assumed to be within method m1: ..m2(); # call m2 the same way m1 was called, instance or class This has already been semi-rejected. I agree with the reasoning. Not that it wouldn't be nice to have a way to code the concept, just that the .. symbology isn't right for the job. MUA/MTA quoting seems to be getting in the way here - someone's prepending a '.' to avoid sending the SMTP end-of-message sentinel and it's not getting stripped off properly. That was supposed to be a single '.' in front of the m2(). Then, Agreed. In other words, unary . is the same as binary . with $_ as the LHS, so .m2() would be the same as $_.m2(). Which would have the semantics in my comment above, Yes, until you used a Cgiven or a Cfor, etc. Then .m2() would be the same as $_.m2() (at least it would be if we don't make any of the changes we're talking about), but wouldn't be called the same way m1 was called, it would be called on the current topic. assuming that the class becomes the topic in static methods. Larry Wall wrote in A4: Any method definition is a topicalizer within the body of the method, and will assume a given of its $self object (or whatever you have named it). I would hope that static methods wouldn't be *too* different from instance methods. Allison
Re: Unary dot
On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote: David Whipp [EMAIL PROTECTED] writes: Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ... For reasons that I can't quite put my finger on at the moment, I really, really don't like that approach. One of the really nice things about perl 4 was that we didn't have to use any more. Making it essential seems like a horribly retrograde step. I suppose you could require the only when calling subroutines from within a method/class definitions, but I still don't like it. I agree. It makes an exception where none is needed (foo() required instead of foo()) just to re-use the syntax for a less common construction that could just as easily be represented any number of other ways. Allison
Re: Unary dot
David Whipp [EMAIL PROTECTED] writes: Thus, the perl5 transalations would be: foo() = $self-foo() .foo() = $_-foo() foo() = foo() ... Alternative: $self.foo() = $self-foo() # and can be .foo() when $self is $_ .foo() = $_-foo() # but might be altered by a pragma foo() = foo() Allison
Re: Unary dot
$.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Or is there some reason this wouldn't work? Luke
Re: Unary dot
Allison wrote:
David Whipp [EMAIL PROTECTED] writes:
Thus, the perl5 transalations would be:
foo() = $self-foo()
.foo() = $_-foo()
foo() = foo()
...
Alternative:
$self.foo() = $self-foo() # and can be .foo() when $self is $_
.foo() = $_-foo() # but might be altered by a pragma
foo() = foo()
And welcome back to where we started! ;-)
However, having circumnavigated the alternatives, we now have a better
perspective on the trade-offs and hidden costs.
The original idea of topicalizing the invocant in methods was that it makes
very simple methods even simpler:
method name { .assigned_name // .std_name // ??? }
For anything more complex than very simple (i.e. anything with internal
topicalizers), one names the invocant explicitly:
method rank ($self:) {
given ($.status) {
when covert { return Special operative }
when detached { return Field operative }
default { return $self.actual_rank }
}
}
or, if the class has many such methods, implicitly:
use invocant 'invocant';
method rank () {
given ($.status) {
when covert { return Special operative }
when detached { return Field operative }
default { return invocant.actual_rank }
}
}
The problem that this discussion has highlighted is that using a
bare .foo in a method means the reader/maintainer has to track what
the current topic is in order to know who the current invocant is.
That would seem to be a (potentially expensive) hidden cost of this idiom.
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.
Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.
Of course, the problem is then: what should the name of this topicalizer
variable be? The main options are:
$self
$me
$I
$this
$invocant
$object
$obj
And frankly, that's a very minor issue. Someone (i.e. Larry) should just
pick one and then we can all move on.
Damian
Re: Unary dot
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: Allison wrote: $self.foo() = $self-foo() # and can be .foo() when $self is $_ .foo() = $_-foo() # but might be altered by a pragma foo() = foo() And welcome back to where we started! ;-) Exactly! :) The problem that this discussion has highlighted is that using a bare .foo in a method means the reader/maintainer has to track what the current topic is in order to know who the current invocant is. That would seem to be a (potentially expensive) hidden cost of this idiom. But possibly less expensive than providing a means to default to something other than topic. That is, that as well as aliasing the invocant to $_, they also alias it to some standard variable name. Then one would be guaranteed an invariant name (across all OO Perl!) for the invocant, even under internal topicalizations. I'm in favor of the standardized variable name. It is a restriction, but not an onerous one. I've never used anything but $self, and I'm sure it would be easy to adapt to whatever else was chosen. Are there any statistics availble on current usage of $self vs. $this vs. whatever? It might be easiest to go with what the majority find most comfortable. Allison
Re: Unary dot
At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
(with the same name). If only one exists, then that would be the one
that gets called.
I'd hope it would assume instance method until told otherwise,
since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
Sure I do, but it doesn't comprise more than 5% of the methods I call
on objects. And in C++ or Java, when I need a class method, I
specify it with the keyword 'static'. Along with it comes the restrictions
of not accessing instance data, etc. etc.
I will admit my applied usage of OOP is biased by the C++/Java
lense. :)
While I may be misunderstanding Perl6 syntax, I'm not misunderstanding
OOP, these are basic concepts to C++ and Java and how many
other languages; granted, I'll try to play catchup with reading the Apocs and
Exegeses over, but it appears from the discussion thread that people
are discussing class/instance method mixing as if this were a new
concept to OOP. My feeling is you ask yourself: What makes sense and what
does the compiler and runtime engine have to do based on the given
rules that we choose.
Its clear if invocant of foo() is the class, and not the instance, calling
an instance method from class scope without creating an object to work
with should either be disallowed, or analyzed to check whether it actually uses
instance data. I'd choose former which is what C++ and Java does.
-Melvin
Re: Unary dot
At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
And anyone who says You don't will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, block) {
if $is_rhs { $self.new(+ block( $target, $self.value )) }
else { $self.new(+ block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
I agree, however you passed in the invocant so there is no
ambiguity in your case.
Calling a class method off of an object, I've found use for.
Calling an instance method from a class invocant scope doesn't
make sense to me which is what I _think_ Graham's example
was implying.
I suppose this would be akin to:
if(typeof(self) is 'class') {
...
}
else { # instance
...
}
I think that would be just plain bad design, but I'd be happy if someone
showed me a use for it. :)
-Melvin
Re: Unary dot
At 08:04 AM 4/11/2002 +1000, Damian Conway wrote: And welcome back to where we started! ;-) Wow there is a lot of blood on the ground here. Must have been messy... :) Of course, the problem is then: what should the name of this topicalizer variable be? The main options are: $self $me $I $this $invocant $object $obj And frankly, that's a very minor issue. Someone (i.e. Larry) should just pick one and then we can all move on. I'm waiting for Larry to say, We have decided to use $me, $myself and $i. -Melvin
RE: Unary dot
Melvin Smith wrote
I think that would be just plain bad design, but I'd be happy
if someone showed me a use for it. :)
well, I've been known to do
sub UNIVERSAL::debug
{
my $self = shift;
my $msg = _;
eval {$self=$self-name} if ref($self);
my $timestamp = ...;
my $caller = ...;
print DEBUG [$timestamp] '$self' $caller: $msg\n;
}
sub UNIVERSAL::debugf { shift-debug(sprintf _) }
which can then be called as:
$class-debug(hello);
or
$self-debugf(world, %d, 42);
or even
hello-debug(world);
You are right. This is just plain bad design. But it can be useful.
Dave.
Re: Unary dot
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.
Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.
H... this being the case, is there any reason we should ever need to
name the invocant explicitly? If Perl has already provided a named alias
implicitly, why specify redundant information when other parameters
follow? Leave the parameter lists for parameters that change from method
to method, not for the one that will always be there.
You get short parameter lists, and a truly invariant name for the
invocant.
method foo ($bar, $baz) {
$self.boo; # $self always exists in a method
}
There's no conflict with Perl 5 since Cmethod is a new keyword.
Also, the invocant pragma becomes unnecessary if you can always access
the current object via $self (or $this, or $me, or whatever, as long as
it's not $invocant ;).
My, my, my, I *am* playing the devil's advocate today. :)
Allison
Re: Unary dot
Allison Randal wrote:
H... this being the case, is there any reason we should ever need to
name the invocant explicitly?
Yes. To make it read-writable.
Perl makes that much easier than most other languages, because you can pass
the invocant by (writable) reference, so you don't need to pass a separate
$parent pointer:
method Tree::delete(Tree $self is rw:) {
if $.left_child {
$.left_child.insert($.right_child) if $.right_child;
$self = $.left_child
}
elsif $.right_child {
$self = $.right_child
}
$.right_child = $.left_child = undef;
}
Damian
Re: Unary dot
On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote: Allison Randal wrote: H... this being the case, is there any reason we should ever need to name the invocant explicitly? Yes. To make it read-writable. Curses! Foiled again! :) Perl makes that much easier than most other languages, because you can pass the invocant by (writable) reference, so you don't need to pass a separate $parent pointer: Devil's advocate role aside, that is a very cool feature. Another thing you would lose is the ability to rename the parameter if you wanted (you could use assignment or binding, but it would be infinitely ugly). Allison
Re: Unary dot
At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote: $.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Or is there some reason this wouldn't work? I totally agree here. The common case is going to make code look ugly with $.foo everywhere. Please don't let this come into being. :( I think it is arguable that a closure is a class for a subroutine object, and in subs we will still use my $foo for lexicals. However we must remember in class scope to use $.foo for the default, instance variable, and a normal $foo for the less typical static or class variables. Yucky. Reserve the ugly syntax for the less common case. Plase. -Melvin
Re: Unary dot
Damian Conway [EMAIL PROTECTED] writes: [...] Reflecting on this, it seems that it would be useful if methods implicitly did their default topicalization-of-invocant like so: - $self rather than just: - $_ That is, that as well as aliasing the invocant to $_, they also alias it to some standard variable name. Then one would be guaranteed an invariant name (across all OO Perl!) for the invocant, even under internal topicalizations. Of course, the problem is then: what should the name of this topicalizer variable be? The main options are: $self $me $I $this $invocant $object $obj And frankly, that's a very minor issue. Someone (i.e. Larry) should just pick one and then we can all move on. Nailing my colours to the mast here, I choose '$self'. I will confess to suggesting the Cuse invocant '$whatever' syntax not because I thought it was a desperately good idea, but because I didn't want to get into arguing about what colour to paint the bikeshed before we'd actually decided whether or not to build the bikeshed in the first place. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
Luke Palmer [EMAIL PROTECTED] writes: $.foo It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like Cis private as discussed. That or Cis static. I think the latter makes more sense. Ah, but I think the mnemonic value of the '.' more than earns its keep here. Cour $foo is private is doing a slightly different job anyway. And instance variables are *not* the same as 'normal' variables, they hang off a different symbol table (or syte, to use Damian's oh so clever term from Perl 5+i) and I'm all for things that are different *looking* different. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
Ah, but I think the mnemonic value of the '.' more than earns its keep here. Cour $foo is private is doing a slightly different job anyway. And instance variables are *not* the same as 'normal' variables, they hang off a different symbol table (or syte, to use Damian's oh so clever term from Perl 5+i) and I'm all for things that are different *looking* different. Well, I certainly don't like the aesthetic value of them. They are ugly as Perl 4. But, I have been caught in C++ making all my private variables _named _like _this, so I suppose it's analogous. But I don't like being forced to do it that way. What if you just want a simple struct-like thing? That's when it becomes really ugly and dislikable. Erm... wait a minute, how would you do that? $foo = new Foo; $foo..instancevar = 7; I doubt that's it. $foo.instancevar = 7; And that's unclear, if we refer to it as $.instancevar inside the function. Or, actually, I do think it's clear. Wow, I was arguing my point and I came to like the syntax. Hmm Ok, take your once-ugly syntax and run with it! I understand it now. Luke
Re: Unary dot
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
And use me; instead of use invocant;?
--
me
PS. Please don't flame me, my assistant wrote this.
Re: Unary dot
Me [EMAIL PROTECTED] writes:
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
Keep up at the back.
use invocant 'me';
PS. Please don't flame me, my assistant wrote this.
Whereth hith lithp?
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within. We're talking about how to make .foo
mean self.foo regardless of the current topic.
: Also, what about
:
: use invocant;
:
: resulting in all method bodies in scope getting an implied
: surrounding given (self) { }.
Er, methods already assume that.
: And what about 'me' or 'i' instead of 'self'?
I think me is too close to my.
: And use me; instead of use invocant;?
And here me is referring to something that doesn't even necessarily
exist at the time of the declaration. Who is me at this point?
In any event, I'm inclined to think that this whole selfish notion of
the object is a bit of a misnomer. We are a programmer. We are not an
object. We use my on lexical declarations because it's my piece of
code. Some of that code just happens to deal with objects, but objects
are them more than they're us. C++ probably has the more accurate
idea here with this, but maybe we've finally found a good place for
the occasionally proposed it:
it.foo(1);
or even better:
close it;
On the other hand, it doesn't interpolate too well. And $_ is still
pronounced it...
But think of the commercial possibilities if your program starts out:
just use it;
Though I do wonder what
use it or lose it;
would mean...
Larry
Re: Unary dot
Larry Wall [EMAIL PROTECTED] writes:
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within. We're talking about how to make .foo
mean self.foo regardless of the current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that topicalizers would still work, eg:
use invocant 'it';
method foo($bar) {
given .wibble($bar) {
when .method { it.do_it(.attrib) }
}
}
(I'm assuming here that, in a method, $bar is *not* the same as @_[0],
which one would declare using Cmethod foo($bar:) {...}). In the
above chunk of code it'd be really nice if .method and .attrib were
called on the results of .wibble($bar) (which was called on the
current object), whilst 'it' unambiguously refers to the current
object.
The Cuse invocant 'foo' syntax is just a suggestion (and a way of
dodging arguments about whether to call the object
self/this/that/it/whatever because the programmer can cleave to his
own taste.
: And use me; instead of use invocant;?
And here me is referring to something that doesn't even necessarily
exist at the time of the declaration. Who is me at this point?
Can I propose an 'abuse' builtin? Then one could say: Cuse me; abuse
me;, which has to be good for poetry if nothing else.
In any event, I'm inclined to think that this whole selfish notion
of the object is a bit of a misnomer. We are a programmer. We are
not an object. We use my on lexical declarations because it's my
piece of code. Some of that code just happens to deal with objects,
but objects are them more than they're us. C++ probably has the
more accurate idea here with this, but maybe we've finally found a
good place for the occasionally proposed it:
it.foo(1);
or even better:
close it;
On the other hand, it doesn't interpolate too well. And $_ is
still pronounced it...
Personally, I like the 'self' notation; it encourages the programmer
to think the 'right way around'. 'it' encourages one to think of
objects doing things to objects, 'self' encourages to think of objects
taking responsibility for their own data and asking other objects to
do things for it. Hrm... I think I might need to think about that some
more.
But think of the commercial possibilities if your program starts out:
just use it;
Though I do wonder what
use it or lose it;
would mean...
You are a *bad* man Mister Wall.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
Damian Conway writes:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So you might say something like this:
use invocant ;
Still a bit odd syntactically, however. One is vaguely tempted to make
..foo(1)
mean self.foo(1). But then we'd see methods chock full of *that* even
when it wasn't necessary. Much rather see self.foo(1).
: *Much* better name. You see, that's why you're the mad genius and I'm
: just the lowly lab assistant. Marthter.
:
: And, given that I'm jutht Larry'th lowly lab aththithtant, that would
: theem to make you a meta-Igor!
:
: %-)
As Annie Oakley almost said, Anything you can do, I can do meta.
Fortunately, Igority is transitive...
Larry
Re: Unary dot
Larry wrote:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So you might say something like this:
use invocant ;
Still a bit odd syntactically, however.
Perhaps a bare:
use invocant;
overrides unary dot within the lexical scope, causing it to default to using
each method's _[0], rather than $_.
One is vaguely tempted to make
..foo(1)
mean self.foo(1). But then we'd see methods chock full of *that* even
when it wasn't necessary. Much rather see self.foo(1).
Yep. Besides, since we're working towards having the unary version of operators
vaguely related to the binary version in Perl 6 (e.g. unary C_, unary C+,
unary C.), it would seem counterproductive to have unary C.. utterly
unrelated to binary C...
Fortunately, Igority is transitive...
I thought that was maxim was: Igorance is blithth.
Damian
Re: Unary dot
Damian Conway writes: : Fortunately, Igority is transitive... : : I thought that was maxim was: Igorance is blithth. That's not a maxim, that's a minim. Larry
Re: Unary dot
: I thought that was maxim was: Igorance is blithth. That's not a maxim, that's a minim. No need to get all crotchet-y. Damian
Re: Unary dot
Piers == Piers Cawley [EMAIL PROTECTED] writes:
Piers So, is there any chance that we'll be able to do:
Piers class ical {
Piers use object_name '$self';
Piers method ical {
Piers given $self.ology {
Piers ... { $self.ish }
Piers }
Piers }
Piers }
You could use the Smalltalk way by defining method myself in UNIVERSAL,
which simply returns self. So .myself would always be yourself,
which you could store if needed.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Unary dot
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit parameters, you can always write:
method ical {
given _[0].ology {
... { _[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
use invocant 'self';
method ical {
given self.ology {
... { self.ish }
}
}
and then probably use:
use invocant 'me';
to save those two extra characters!
;-)
Damian
Re: Unary dot
Damian Conway [EMAIL PROTECTED] writes:
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit parameters, you can always write:
method ical {
given @_[0].ology {
... { @_[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
use invocant 'self';
*Much* better name. You see, that's why you're the mad genius and I'm
just the lowly lab assistant. Marthter.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
use invocant 'self'; *Much* better name. You see, that's why you're the mad genius and I'm just the lowly lab assistant. Marthter. And, given that I'm jutht Larry'th lowly lab aththithtant, that would theem to make you a meta-Igor! %-) Damian
Unary dot
Whilst I've been hacking the perl 6 scheme interpreter I've found
myself using code like the following
method get_token( $self: ) {
given $self.get_char {
when !defined { fail IOException: msg= EOF }
when /\s/ { $self.get_token }
when '(' { $the_left_paren }
when ')' { $the_right_paren }
when '' { $self.read_string }
when /\d/ { $self.read_number($_) }
default { $self.read_identifier($_) }
}
}
Initially, that got written as:
method get_token {
given .get_char {
...
default { # Hang on, how do I call a method on myself now?
}
}
}
The issue here is that, if you ever want to use a topicalizer inside a
method definition, and you're going to want to call a method on
yourself from inside the scope of that topicalizer then you can't
really make use of implicit self references.
And because topicalizers are such a powerful tool (believe me; I don't
think I've written a single 'if' statement anywhere in the scheme
interpreter, it's starting to feel clumsy), you're going to end up
with almost all your method declarations looking like:
method foo($self: ... ) {...}
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
(I'm sure we'll be able to write 'object_name', I'm just hoping that
it'll come as part of the core distribution)
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
