Re: WTF? - Re: method calls on $self
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12 says:
class Foo {
# normal instance variables
has $.x;
has $.y is rw;
has $:z;
has @.foo is rw;
has @:bar
has %.baz is rw;
has %:ber
method one { return 1 }
method :two { return 2 }
# some class variables
our $.class_var1;
our $:class_var2;
our $.class_var3 is rw;
my $.class_var1_visible_only_to_class;
my $:class_var2_visible_only_to_class;
# implicit object set in $?SELF
method grr {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = .one; # hmmm - here is the subject of all of our pain
my $b = .:two;
}
# explicit object
method roar ($obj:) {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = $obj.one;
my $b = $obj.:two;
}
}
# external use of object
sub squawk ($obj) {
$obj.x = 1; # fails - no accessors
$obj.y = 2; # ok - lvalue accessor was created for us because of is rw
$obj.:z = 3; # fails - no public accessors - even if is rw
push $obj.foo, 'item'; # ok - lvalue accessor created
push $obj.bar, 'item'; # fails - even if is rw
$obj.bazkey = 'val'; #ok - lvalue
$obj.berkey = 'val'; # fails - even if is rw
my $a = $obj.one;
my $b = $obj.two;
}
Somebody correct me if I had things wrong up above.
So in all of that example, all of the instance variables and methods are
easily accessed and almost all of the rules are clear cut. So under this
final proposal we now have the following:
class Foo {
has @.elems;
method rock {
.wizbang; # called on $?SELF - looks ambiguous (what is $_)
.foo for @.elems; # fails with an error - ambibuous compared to .wizbang
}
method stone ($obj) {
$obj.wizbang;
.foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(
}
}
sub conglomerate_solid ($obj) {
$obj.wizbang;
.foo for $obj.elems; # ok here
}
sub petra ($obj) {
temp $_ = $obj;
.wizbang;
.foo for .elems; # confusing - but ok (called on different objects)
}
I don't think the most recent proposal (er edict) is really all that friendly.
I've been hoping that it is a case of linguist/architect/benevolent president
turned psychologist and that it is a foot in the door approach of getting
both sides of the ./method argument to just give up and be quiet.
This latest proposal seems to add ambiguity all in favor of getting rid of a
slash. Looking at all of the instance variables and method accesses in the
method grr up above, a method call of my $a = ./one really isn't that out
of place. Once the object is explicit, then all method calls change
(including the private ones) while all of the instance variables stay the
same.
I think that .method == $_.method needs to always hold true. I still think it
would be nice - though not as important to have ./method (or whatever
variation you want) work inside methods. I don't think that $_ should ever
default to the invocant ($_ =:= $?SELF) (which should be easy enough with
method a ($_) { ... }).
method concrete {
./wizbang;
.foo for @.elems;
.foo for ./elems; # possibly odd looking - but not confusing
}
Please, lets pick something sane. Here I go speaking for the list, but I
don't think we will find many that think .method syntax breaks in methods if
$_ is rebound as a very sound concept.
Paul
Re: WTF? - Re: method calls on $self
On Thu, July 14, 2005 10:47 am, Autrijus Tang said: If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. I have been watching perl6-language from afar and not really contributing. But I have to say that in this case I do agree with Autrijus Graham.
Re: WTF? - Re: method calls on $self
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote: Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) Aankhen
Re: WTF? - Re: method calls on $self
Aankhen skribis 2005-07-14 12:39 (+0530): Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. // Carl
Re: WTF? - Re: method calls on $self
If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. Thanks, /Autrijus/ pgpyMrTt9ljfK.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote: On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. Yes, let .foo still mean $_.foo, unconditionally, please. The `./` is nice, but I'm willing to give up the syntax in favor of letting .foo always mean $_.foo. Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. So long as .foo (pretty please) means $_.foo all the time (with sugar on top?). -kolibrie
Re: WTF? - Re: method calls on $self
Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
It's a little klunky but does localize the override rather visibly.
Doubtless people will generally put the use dot at the front though.
Larry
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always means $_.method ($_ being the topic) then I don't see how
it is ever ambiguous. Unless I missed where nested loops would also
disallow .method because people might not be able to keep track of the
topic.
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
Why must anything special be done in the given block to allow .method if
it is always $_.method? Since I know $y is the topic in this block I know
to expect $y.abc to be called. There is no ambiguity. An error here
would just be confusing.
Now, for those who want .abc to call $?SELF.abc within the given block
then I think it would be clearer if they spelled out that intention with
something like
given $y { use dot '$?SELF'; # or just 'use dot' with suitable default
when 1 { .abc } # calls $?SELF.abc
}
--
Rick Delaney
[EMAIL PROTECTED]
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK! TOO MANY CHOICES!
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
I don't want to be using a language designed for idiots - I know
what I'm doing, and I like the power that perl 5 has given me.
How many times have you typed
map { chr }
map { lc }
grep { defined }
and then got bummed out that you can't have
grep { .is_moose }
since it's in a method.
That really sucks.
I'd rather have '.foo' not work on $?SELF at all than have that.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpaUXI5Wijpd.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-14 13:39 (-0700): On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. Thus it never means $?SELF.foo without $_ being the same thing, and thus it always means $_.foo, and thus there is no ambiguity about what .foo means, and .foo can mean $_.foo even if $_ isn't $?SELF, as $?SELF is never a factor in the decision what .foo means. Good, glad that's solved. We have normality. It's a little klunky but does localize the override rather visibly. Doubtless people will generally put the use dot at the front though. Doubtless if you really insist on this feature, Perl 6 will see its first fork very shortly after its release... But have no fear, because it will run all standard Perl 6 code too, as the thing that the fork introduces used to be an error. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
Yuval Kogman skribis 2005-07-15 1:09 (+0300): use dot; If we have pragmas for the 99 Perl6's that every wacko wants to have, we won't have any readability. The syntax needs to be consistent and useful, even at the price of some danger. Agreed. I don't want to be using a language designed for idiots - I know what I'm doing, and I like the power that perl 5 has given me. Me too. I'd rather have '.foo' not work on $?SELF at all than have that. .foo never working on $?SELF is consistent with the initial design, the idea that the default variable is always $_ (as explained very well by Damian), and the design until a few days ago. I really do not understand why Larry has changed his mind about .foo, as the meaning of .foo has not been topic of discussion for a long time now. The syntax of ./foo did receive a lot of both negative and positive attention, and I could understand that ./foo, being found ugly by some people, would be pulled out of the language in favour of some yet to invent syntax, or perhaps without replacement. That, however, has nothing to do with .foo. Or at least HAD nothing to do with .foo, until Larry decided that if $_ := $?SELF, .foo would be special all of a sudden. If that is so, then lc without arguments would also need to be special, as that also defaults to $_, which would then be the same thing as $?SELF, which makes things special. lc without arguments would also need to be forbidden, following this way of thinking. We can only hope our dictator turns benevolent again, at least regarding the one thing we all agree about (and have agreed about for quite some time): that .foo must always mean $_.foo. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote: On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote: On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. If you say use dot; I'd rather have '.foo' not work on $?SELF at all than have that. Um, that's what I was hoping for too. Let .foo mean $_.foo, and never $?SELF.foo, unless of course $_ happens to contain $?SELF at that moment. (sugar, anyone?) -kolibrie
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote: Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? The former. But this is strictly a joke in response to nothingmuch's two characters shorthand criteria on #perl6; please don't hold it against me, or invoke the famed joke-turned-into-reality p6l device! :) Thanks, /Autrijus/ pgpiqjSf1TXa2.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote: : I agree with what is being said here. `.method` is a great way to : eliminate a lot of repetitive, tedious typing. Surely there is a : viable alternative that doesn't involve outlawing it? Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Larry
WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even if it's only 1 char apart.
I think a solution to the problem of being able to use those two
well, is not a solution, because there isn't a problem.
On Tue, Jul 12, 2005 at 12:59:22 +0200, Juerd wrote:
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!
pgpL6XkyQ00ZQ.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
On 7/12/05, Juerd [EMAIL PROTECTED] wrote: [snip] Disallowing .method here means a huge step back in time. Back to $_.method or $object.method. [snip] I agree with what is being said here. `.method` is a great way to eliminate a lot of repetitive, tedious typing. Surely there is a viable alternative that doesn't involve outlawing it? Aankhen
Re: How to write a self.pm (Re: method calls on $self)
Autrijus Tang wrote:
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure
I might still not understand topic, $_ or lexical vars in general.
But why does the fact that c is called with a parameter
in the second case and without one in the first example make a
difference? Isn't $_ always coming in out of band? So .bar is always
invoked on the invocant of foo if we think that there is an implicit
$_ := $?SELF before the call to baz in foo. And I hope the binding
of $_ to $?SELF is a read-only binding!
--
TSa (Thomas Sandlaß)
Re: How to write a self.pm (Re: method calls on $self)
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: : The obvious thought is to have yet another magical, $^H like flag, to
: : denote the current dialect. If it is set, then the parser can emit
: : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
:
: The parser always emits .method as $_.method under any dialect, or
: fails. What has changed is whether $_ sometimes means the invocant.
:
: But the compiler needs to trigger ambiguity resolution -- i.e. check
: for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
:
: No need to do that if it sees $_.method. So they need to be different.
Well, another approach is to treat .method as invariably $_.method,
and catch the problem at the attempt to rebind $_. Thomas seems to
think it should already be doing that. Of course, that would make it
impossible to use given or for inside a method at all...
So the other approach is to give up on compile-time checks and say
that $?IMPLICIT_INVOCANT.method in a method's lexical scope (and
in the absence of use self) turns into
($_ =:= $?SELF ?? $_.method :: fail Phooey)
: In any event, SMD methods always have a first argument, so you're never
: in doubt at that point. And since .bar always means $_.bar, I don't
: think you really have a problem here that's any harder than you already
: had with $_.
:
: The problem here is for the compiler to detect whether $_ agrees
: with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
: $?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
:
: Consider this construct:
:
: method foo {
: $_ := $something_else if rand(2)1;
: .bar;
: }
:
: That's one case where it's not possible to detect at compile time,
: so it needs to silently let .bar go thru as $_.bar.
Though Thomas's constant binding notion would presumably catch that.
But then we're getting into the noalias zone that Dennis Ritchie hates.
On the other hand, I can see lots of uses for variables that may
not be rebound, at least in terms of reassuring the optimizer that
Weird Things Can't Happen.
: : Clearly we need a way to statically determine statement:given
: : and statement:for will always assign at least one argument to
: : its block argument. Without that, the compile-time analysis mandated by
: : Larry is infeasible.
:
: I think you can assume that given and for always bind at least one
: argument. In particular, a for that binds 0 arguments will never
: progress, plus you can recognize it:
:
: But what in given and for signify that? I do not want to special
: case based on function names, and statement:given may be rebound
: to something else.
I understand the desire for generality, but that road also leads to
error messages that are completely opaque to naive users, who are
pretty accurate in their view that features like given and for
will Stay Put in the normal course of events. Many of the most useful
diagnostics in Perl 5 are the ones that are guessing based on common
usage patterns. Users can't do much with messages that when deciphered
come out to mean something like you called a function passing as
its first argument another function whose first argument's declared
type allows it to be optionally bound to $_ but if we actually try to
make use of that we'll get some ambiguity further on down the road,
and that's bad. They'd much rather chuck the generality and have
You can't say .foo inside given where the topic could be either $_
or the method's invocant. Or in the absense of that just blow up
at run time.
Of course, I'm just restating your problem here...
: How does that something else signify that it will
: at least bind at least one argument to its code argument? Via the
: signature of the code argument, i.e. the Any in codeAny?
:
: sub statement:given (Any $topic, codeAny) { ... }
Maybe something like:
sub statement:given (Any $topic, *code:(Any is topic)) { ... }
: If so, what is the signature of for? I can't seem to write it down.
Good question. I suppose the signature wants to guarantee minimum arity
of 1 somehow. Maybe
sub statement:for (Lazy [EMAIL PROTECTED], *code:(Any is topic, *)) {
... }
or some such. But whether the outer function is actually functioning
as a topicalizer would still depend on the innards of your function.
Hmm. We might settle for declaring such functions with a special trait
that indicates that they are *intended* to function as topicializers.
And then maybe the compiler could just depend on those declarations
for its static analysis:
sub statement:given (Any $topic, *code:(Any)) is topicalizer { ... }
Other that that we rely on the run-time check. (Which hopefully common
code analysis can factor out multiple copies of.)
: : Then,
Re: method calls on $self
On Sat, 9 Jul 2005, Robin Redeker wrote: I wasn't thinking 'cool', I was thinking 'visually distinctive and mnemonic'. I actually think o. is cooler. Yes, i would like o. more too. At least it doesn't introduce a completly meaningless '/' preceded by a '.'. Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ like it! Thus, how about making '/' less meaningless, i.e. more meaningful, in more general situations?!? Michele -- Bunch of slack-jawed faggots around here! This stuff will make you a god damnned sexual Tyrannosaurus, just like me! - Blain, Predator (1987)
Re: method calls on $self
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote: : Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ : like it! Thus, how about making '/' less meaningless, i.e. more : meaningful, in more general situations?!? Um, do you have a specific proposal? Like maybe / can be applied as a metaoperator to any binary operator to make it into a unary operator with the left side implicitly $?SELF, or some such? Hmm... if ==/ 3# if $?SELF == 3 could even extend it to postfix ops: ++/;# $?SELF++ However, it has several problems. First, . isn't really a binary operator, but the prefix of a postfix operator. Second, the / is potentially ambiguous with a following pattern unless we require space before termish /. Third, the / is psychologically in the wrong place to stand in for something in front. Or to turn these on their head, we've just made three good arguments for something like: if o == 3 and o++; I'm afraid that, while ./ is cute and visually distinctive, I find I'm getting tired of its idiosyncracies. You shouldn't go out and marry someone just because they're cute and visually distinctive. Hooray for long engagements, and occasional disengagements. Larry
Re: method calls on $self
Larry~ On 7/11/05, Larry Wall [EMAIL PROTECTED] wrote: On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote: : Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ : like it! Thus, how about making '/' less meaningless, i.e. more : meaningful, in more general situations?!? Um, do you have a specific proposal? Like maybe / can be applied as a metaoperator to any binary operator to make it into a unary operator with the left side implicitly $?SELF, or some such? Hmm... if ==/ 3# if $?SELF == 3 could even extend it to postfix ops: ++/;# $?SELF++ However, it has several problems. First, . isn't really a binary operator, but the prefix of a postfix operator. Second, the / is potentially ambiguous with a following pattern unless we require space before termish /. Third, the / is psychologically in the wrong place to stand in for something in front. Or to turn these on their head, we've just made three good arguments for something like: if o == 3 and o++; I'm afraid that, while ./ is cute and visually distinctive, I find I'm getting tired of its idiosyncracies. You shouldn't go out and marry someone just because they're cute and visually distinctive. Hooray for long engagements, and occasional disengagements. Yay! I guess I will take this moment to resuggest @^ as a list of invocants and $^ =:= @^[0]. I like how the ^ kinda points you the right way, also visually distinctive and doesn't get in the way of $_... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: method calls on $self
On Mon, Jul 11, 2005 at 04:50:56PM -0400, Matt Fowles wrote:
: Yay! I guess I will take this moment to resuggest @^ as a list of
: invocants and $^ =:= @^[0]. I like how the ^ kinda points you the
: right way, also visually distinctive and doesn't get in the way of
: $_...
I don't see much use for @^ since multis require you to declare all
your invocants anyway. Maybe one could envision a macro that has an
unhealthy interest in innards of an unknown argument list, but that
can probably be better satisified with @?ARGS or some such.
And $^ is just too long to be a standard shortcut.
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a twist. That is, .foo is always
a call on the current topic, but the invocant is (again) always the
topic in the outer scope of a method. The difference from before
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
(If necessary we can also compile .foo inside methods down to code
that checks at runtime whether $_ has diverged from $?SELF and pitch
a run-time fit for those situations we can't detect at compile time.
Or we can just declare it erroneous.) Basically, you can't use .foo
inside a given or a for inside a method.
That's the default, and I'm not changing my mind ever again, at least
till next week. That being said, if you mutate your language with
anything like:
use self this;
use self self;
use self o;
use self ./;
use self ;
...
then the pragma is allowed to warp .foo semantics to make it *always*
refer to $_ everywhere, provided it *also* undoes the default binding
of $_ := $?SELF, so people that people aren't tempted to use .foo to
mean $?SELF.foo in that scope.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
Shame on you. Move the common code to a role, or a base class.
I think the lesson of the last few months is that there are some
things we'll never agree on, and we just need to make it possible
to disagree in the least disagreeable fashion. I've tried hard
to believe everyone's viewpoint on this at one point or another,
so I think I'm qualified to say that they all have their strong
points and their weak points. And that the programmer needs to
have the final say on which viewpoint they find least repulsive.
}
Larry
How to write a self.pm (Re: method calls on $self)
(Cross-posting the new ruling from p6l to p6c to discuss implementation
strategy)
On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a twist. That is, .foo is always
a call on the current topic, but the invocant is (again) always the
topic in the outer scope of a method. The difference from before
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
(If necessary we can also compile .foo inside methods down to code
that checks at runtime whether $_ has diverged from $?SELF and pitch
a run-time fit for those situations we can't detect at compile time.
Or we can just declare it erroneous.) Basically, you can't use .foo
inside a given or a for inside a method.
That's the default, and I'm not changing my mind ever again, at least
till next week. That being said, if you mutate your language with
anything like:
use self this;
use self self;
use self o;
use self ./;
use self ;
...
then the pragma is allowed to warp .foo semantics to make it *always*
refer to $_ everywhere, provided it *also* undoes the default binding
of $_ := $?SELF, so people that people aren't tempted to use .foo to
mean $?SELF.foo in that scope.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
Shame on you. Move the common code to a role, or a base class.
}
Normally, I try to comply with new rulings as soon as they become
available, but the implementation of this is nontrivial, so I'd welcome
more input.
The obvious thought is to have yet another magical, $^H like flag, to
denote the current dialect. If it is set, then the parser can emit
.method as $_.method, instead of $?IMPLICIT_INVOCANT.method. If it is
not set, the parser needs to emit this as the first statement in any
method body:
$_ := $?SELF
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure
Clearly we need a way to statically determine statement:given
and statement:for will always assign at least one argument to
its block argument. Without that, the compile-time analysis mandated by
Larry is infeasible.
Then, we need to figure out the structure for the magic flag set by
self.pm on behalf of its caller. We are not using $^H anymore, so
there needs to be a way to pass lexical settings to the caller.
To use MJD's lexical pragma design:
module self;
use pragma;
sub import ($caller, $dialect) {
install_pragma_value('$?SELF_MAGICAL', $dialect);
}
This will create a lexically scoped hint in the importer's scope;
the parser and compiler will be hard-wired to recognise that magic
and act accordingly.
Does this seem sane? The static detection of $_ is the showstopper
currently, and Pugs will need to separate the compiler with PIL evaluator
to implement the pragma.pm above. Before that happens, I'll still
pretend that:
use self './';
is in scope. If people are uncomfortable with that, maybe we can
retrofit all tests and examples using the ./ syntax to add that dummy
line on top of their code, and ship with a stub self.pm that does
nothing. Will that do as a interim solution?
Thanks,
/Autrijus/
pgpN8udhQ2SUX.pgp
Description: PGP signature
Re: How to write a self.pm (Re: method calls on $self)
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
The parser always emits .method as $_.method under any dialect, or
fails. What has changed is whether $_ sometimes means the invocant.
: If it is
: not set, the parser needs to emit this as the first statement in any
: method body:
:
: $_ := $?SELF
That is the part that has to be conditional on the dialect.
: The compiler, in turn inspect whether there's an bound $_ in scope
: with $?SELF set. It is not trivial, because this should work:
:
: sub baz (c) { c() }
: method foo { baz { .bar } } # $_ is free in inner closure
:
: But this needs to fail:
:
: sub baz (c) { c(1) }
: method foo { baz { .bar } } # $_ is bound in inner closure
The compiler is free to treat any undecidable binding as ambiguous
and die of uncertainty. Though we should probably make some official
rule so that different compilers don't end up with different definitions
of undecidable.
In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.
: Clearly we need a way to statically determine statement:given
: and statement:for will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.
I think you can assume that given and for always bind at least one
argument. In particular, a for that binds 0 arguments will never
progress, plus you can recognize it:
for @foo - {...}
And a given that doesn't bind $_ isn't worth much either.
Or is that what you're asking?
: Then, we need to figure out the structure for the magic flag set by
: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.
Perhaps hints should just be considered lexically scoped $? variables.
You export them lexically just the same way you export any other lexically
scoped things, however that is.
: To use MJD's lexical pragma design:
:
: module self;
: use pragma;
: sub import ($caller, $dialect) {
: install_pragma_value('$?SELF_MAGICAL', $dialect);
: }
:
: This will create a lexically scoped hint in the importer's scope;
: the parser and compiler will be hard-wired to recognise that magic
: and act accordingly.
How will you handle:
use Foo :my$x;
Seems like this is just a kind of
use Foo :my$?MYHINT
thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.
: Does this seem sane? The static detection of $_ is the showstopper
: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.
I suspect you're making it complicateder than it needs to be, but
perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...
: Before that happens, I'll still pretend that:
:
: use self './';
:
: is in scope. If people are uncomfortable with that, maybe we can
: retrofit all tests and examples using the ./ syntax to add that dummy
: line on top of their code, and ship with a stub self.pm that does
: nothing. Will that do as a interim solution?
That's fine for the short term.
Larry
Re: How to write a self.pm (Re: method calls on $self)
On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
The parser always emits .method as $_.method under any dialect, or
fails. What has changed is whether $_ sometimes means the invocant.
But the compiler needs to trigger ambiguity resolution -- i.e. check
for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
No need to do that if it sees $_.method. So they need to be different.
In any event, SMD methods always have a first argument, so you're never
in doubt at that point. And since .bar always means $_.bar, I don't
think you really have a problem here that's any harder than you already
had with $_.
The problem here is for the compiler to detect whether $_ agrees
with $?SELF, when it sees $?IMPLICIT_INVOCANT. If they agree,
$?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
Consider this construct:
method foo {
$_ := $something_else if rand(2)1;
.bar;
}
That's one case where it's not possible to detect at compile time,
so it needs to silently let .bar go thru as $_.bar.
: Clearly we need a way to statically determine statement:given
: and statement:for will always assign at least one argument to
: its block argument. Without that, the compile-time analysis mandated by
: Larry is infeasible.
I think you can assume that given and for always bind at least one
argument. In particular, a for that binds 0 arguments will never
progress, plus you can recognize it:
But what in given and for signify that? I do not want to special
case based on function names, and statement:given may be rebound
to something else. How does that something else signify that it will
at least bind at least one argument to its code argument? Via the
signature of the code argument, i.e. the Any in codeAny?
sub statement:given (Any $topic, codeAny) { ... }
If so, what is the signature of for? I can't seem to write it down.
: Then, we need to figure out the structure for the magic flag set by
: self.pm on behalf of its caller. We are not using $^H anymore, so
: there needs to be a way to pass lexical settings to the caller.
Perhaps hints should just be considered lexically scoped $? variables.
You export them lexically just the same way you export any other lexically
scoped things, however that is.
How will you handle:
use Foo :my$x;
Seems like this is just a kind of
use Foo :my$?MYHINT
thingy, only perhaps you're just setting $?MYHINT rather than aliasing
it back into a Foo variable.
Yes, that's the main difference. How does the :my form of export work
in the exporter's end?
sub foo is exportmy { ... }
Will that work?
: Does this seem sane? The static detection of $_ is the showstopper
: currently, and Pugs will need to separate the compiler with PIL evaluator
: to implement the pragma.pm above.
I suspect you're making it complicateder than it needs to be, but
perhaps I don't understand the problem fully. Of course, the two are
not mutually exclusive...
Indeed I suspect both are true. :)
Thanks,
/Autrijus/
pgpUx78e7n7vf.pgp
Description: PGP signature
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote: On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. If telling my opinion is preventing us to become friends, i'm sorry for that. I heard some people to complain about the ./method() syntax too. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) Maybe per .-file in the home-directory, like .vimrc ... The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. Java-people also invent new tools to ease the pain of writing java-code. But Perl6 isn't as static as Java (of course) and will mutate into a custom language for any dedicated Perl6 programmer. It will be hard/easy to read someones elses Perl6 code regardless of the self-method() syntax. whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) I would be completly fine with $?SELF.method () as default. Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) I wanted to express my fear that perl6 might is pushing me to do that or others to do that. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote: On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. If telling my opinion is preventing us to become friends, i'm sorry for that. I heard some people to complain about the ./method() syntax too. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) Maybe per .-file in the home-directory, like .vimrc ... But i don't think that pushing everyone into his own language is the purpose of designing a new one. Also, i would be VERY curious how that 'self' module looks like. Is there already a spec that describes how to change the parser on the fly in such a module? And how many people, who dislike the ./-syntax will be actually able to write such a module? Or a module that works around another syntax design quirk in perl6? If the majority really wants ./, okay, i am fine with it. My own opinion is, that ./ doesn't fit into the language very much, at least not with a 'but it looks like shell programming'-argument. Perl6 isn't shell programming, and ./ has a completly different meaning (at least for me, and others i heard about this issue) in perl. The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. Java-people also invent new tools to ease the pain of writing java-code. But Perl6 isn't as static as Java (of course) and will mutate into a custom language for any dedicated Perl6 programmer. It will be hard/easy to read someones elses Perl6 code regardless of the self-method() syntax. I don't think that this kind of syntax-translation is so very easy... and what about a perl6 program in a cvs. You probably want to change the code you read... whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) I would be completly fine with $?SELF.method () as default. Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) I wanted to express my fear that perl6 might push me and others to write their own language plugin to work around suboptimal design in perl6. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None at all?
An explicit call, like $?SELF.method () ?
I have never understood what is wrong with this:
method foo ($self: $bar) {
$self.baz()
}
Thats a fine option to have.
But therecomes another question to my mind:
what do i get with writing 'method' instead of
'sub'? is it just for seperating subroutines and methods optically
or is there a deeper reason?
Then you can easily so whatever you like:
## for our Java inclined friends
method foo ($this: $bar) {
$this.baz()
}
or C++
Why does it have to be some sugared syntax when you can just simple
name it in the parameter list?
Yes, but there seem to be quite some people who want
a 'cool' syntax for it. (ie. ./method ()).
No syntax at all, like in C++ just method() would
be the shortest. But larry says no, and everyone seems to
agree.
robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:28:34PM +0200, Robin Redeker wrote:
: On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
: I have never understood what is wrong with this:
:
: method foo ($self: $bar) {
: $self.baz()
: }
:
: Thats a fine option to have.
: But therecomes another question to my mind:
: what do i get with writing 'method' instead of
: 'sub'? is it just for seperating subroutines and methods optically
: or is there a deeper reason?
Several deeper reasons. Though I quibble at characterizing the optical
reason as un-deeper when it might in fact be the deepest reason of all,
or at least closely related to very deep psychological reasons.
Off the top of my head:
Subs are never inherited.
Subs are not candidates for indirect object method calls.
Perl will only call sub new when called as a subroutine.
Subs create list operators, while methods don't.
Method calls are allowed to be argumentless.
Methods have access to instance variables.
Mutating/nonmutating methods can be generated from each other.
Explicit method declaration allows implicit invocant declaration.
Distinguishing multi method from multi sub allows different strategies.
: Why does it have to be some sugared syntax when you can just simple
: name it in the parameter list?
:
: Yes, but there seem to be quite some people who want
: a 'cool' syntax for it. (ie. ./method ()).
I wasn't thinking 'cool', I was thinking 'visually distinctive and
mnemonic'. I actually think o. is cooler.
: No syntax at all, like in C++ just method() would
: be the shortest. But larry says no, and everyone seems to
: agree.
Just to quibble again, I didn't just say 'no'. I also said,
use self ;
And no, everyone doesn't seem to agree. :-)
Larry
Re: method calls on $self
On Fri, Jul 08, 2005 at 05:43:01PM +0200, Robin Redeker wrote: : Maybe per .-file in the home-directory, like .vimrc ... Only if pulled in with a use. I don't want to see Perl programs implicitly starting in a variant language. Dialects must be declared. Otherwise you're in a situation like having a URI that starts at an unknown root. Have you ever noticed how frustrating it can be to sit down at someone else's vim sessions and discovering there are all sorts of implicit keyboard remappings you don't know about? At least with a language we have the possibility of declaring up front for anyone to see which variant of the language we're using. : The only place I can see a problem is when reading other people's code, : but then I expect that the hue and cry would be such that *someone* : would write a tool to make it easy to transmogrify other perl6 dialects : into the one they particularly like to use. And given how well perl6 : will grok perl6, such a tool shouldn't be too difficult to write. : : Java-people also invent new tools to ease the pain of writing java-code. : But Perl6 isn't as static as Java (of course) and will mutate into : a custom language for any dedicated Perl6 programmer. : It will be hard/easy to read someones elses Perl6 code regardless of the : self-method() syntax. That's why it's important not to allow implicit redeclarations of syntax. : whose favorite will be the default? None at all? An explicit call, : like $?SELF.method () ? : : Were I $Larry, that's what I'd do if people kept bringing it up and : carping about the syntax that works--decide there's no default and you : *always* have to be explicit in one way or another. : : Boy am I glad I'm not $Larry ;-) : : I would be completly fine with $?SELF.method () as default. That works by default. ;-) : Will we end in something like : : use : my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; : : If that's your desire, perl ain't stopping you :-) : : I wanted to express my fear that perl6 might is pushing me : to do that or others to do that. As long as that big use declaration is there at the top, we're at least forewarned. But it is my silly hope that Standard Perl 6 will be easy enough that people will be too Lazy to define their own major variants most of the time. Plus I'm hoping there will be some cultural pressure on gratuitous variants. (Though obviously if we provide a self pragma, we're encouraging a particular set of variants as part of the standard language.) Larry
Re: method calls on $self
On Thu, Jul 07, 2005 at 08:12:17PM -0700, Larry Wall wrote: The basic problem is that I always hated looking at C++ and not knowing whether I was looking at a function or a method, so I'm not going to make standard Perl work like that. On the other hand, there's always use self ; to go with everyone else's preferences: [... other use self examples ...] Did I leave anyone out? Larry And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; ? thanks, Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote: And what will be the default syntax to call a method on self? If everyone has completly other preferences about this, for example this horrible ./method() syntax, which completly wont fit into the language, What a way to win friends! Some of us find ./method() to fit just fine into the language and into use. Does the default syntax really matter that much? For your own code, use self ; is a small one-time cost to pay to get the syntax/semantics you want. Well, one-time cost per source file, but I can easily see that someone would build the scaffolding to let that be a one-time cost per site. (e.g. having a site-wide policy for perl6 has been mentioned before) The only place I can see a problem is when reading other people's code, but then I expect that the hue and cry would be such that *someone* would write a tool to make it easy to transmogrify other perl6 dialects into the one they particularly like to use. And given how well perl6 will grok perl6, such a tool shouldn't be too difficult to write. whose favorite will be the default? None at all? An explicit call, like $?SELF.method () ? Were I $Larry, that's what I'd do if people kept bringing it up and carping about the syntax that works--decide there's no default and you *always* have to be explicit in one way or another. Boy am I glad I'm not $Larry ;-) Will we end in something like use my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_perl6_anymore; If that's your desire, perl ain't stopping you :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None at all?
An explicit call, like $?SELF.method () ?
I have never understood what is wrong with this:
method foo ($self: $bar) {
$self.baz()
}
Then you can easily so whatever you like:
## for our Java inclined friends
method foo ($this: $bar) {
$this.baz()
}
method foo
($my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_pe
rl6_anymore: $bar) {
$my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_per
l6_anymore.baz()
}
method foo ($o: $bar) {
$o.baz()
}
Why does it have to be some sugared syntax when you can just simple
name it in the parameter list?
Stevan
Will we end in something like
use
my_completly_custom_syntax_and_grammar_which_has_nothing_to_do_with_per
l6_anymore;
?
thanks,
Robin
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Robin Redeker
method calls on $self
Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) cya, Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: method calls on $self
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote: On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) Because perl can't distinguish between the method foo() and the subroutine foo(). Or are you proposing that methods be added to the search space for name resolution? Yes, why not? I don't see any conflicts for moving the methods into the search space for methods. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
Re: method calls on $self
On 7/8/05, Robin Redeker [EMAIL PROTECTED] wrote: Hi, i just wanted to ask what was about the method calling syntax on $self, and why does method () not work for calling a method on $self? (like in C++) IIRC, Larry wants to be able to distinguish method calls from sub calls, so that when you see 'foo()' inside a method, you know that it's NOT using $?SELF. If you want to call a method, either use an explicit self, or use './method'. (As a side note, putting space between the sub/method name and the call parentheses is now disallowed. If you must have the space, you need to use '.()'.) Stuart
Re: method calls on $self
The basic problem is that I always hated looking at C++ and not knowing whether I was looking at a function or a method, so I'm not going to make standard Perl work like that. On the other hand, there's always use self ; to go with everyone else's preferences: use self . use self ` use self · use self .. use self ^. use self i. use self o. use self ¤. use self me. use self self. use self this. Did I leave anyone out? Larry
Re: method calls on $self
LW == Larry Wall [EMAIL PROTECTED] writes: LW to go with everyone else's preferences: LW use self . LW use self ` LW use self · LW use self .. LW use self ^. LW use self i. LW use self o. LW use self ¤. LW use self me. LW use self self. LW use self this. LW Did I leave anyone out? use self that. use self over_there. use self where_am_i. use self dis. use self dat. use self you. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
