method calls on $self

13 views
Skip to first unread message

Robin Redeker

unread,
Jul 7, 2005, 4:32:37 PM7/7/05
to perl6-l...@perl.org
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

--
el...@x-paste.de / ro...@nethype.de
Robin Redeker

Jonathan Scott Duff

unread,
Jul 7, 2005, 5:08:17 PM7/7/05
to Robin Redeker, perl6-l...@perl.org
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
du...@pobox.com

Robin Redeker

unread,
Jul 7, 2005, 5:44:10 PM7/7/05
to Jonathan Scott Duff, perl6-l...@perl.org
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.

Stuart Cook

unread,
Jul 7, 2005, 10:47:50 PM7/7/05
to perl6-l...@perl.org
On 7/8/05, Robin Redeker <el...@x-paste.de> 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

Uri Guttman

unread,
Jul 7, 2005, 11:23:04 PM7/7/05
to perl6-l...@perl.org
>>>>> "LW" == Larry Wall <la...@wall.org> 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 ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Larry Wall

unread,
Jul 7, 2005, 11:12:17 PM7/7/05
to perl6-l...@perl.org
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

Robin Redeker

unread,
Jul 8, 2005, 2:10:00 AM7/8/05
to perl6-l...@perl.org
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,

Jonathan Scott Duff

unread,
Jul 8, 2005, 9:50:35 AM7/8/05
to Robin Redeker, perl6-l...@perl.org
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 :-)

Stevan Little

unread,
Jul 8, 2005, 10:07:24 AM7/8/05
to Robin Redeker, perl6-l...@perl.org

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

Robin Redeker

unread,
Jul 8, 2005, 2:52:22 PM7/8/05
to perl6-l...@perl.org
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 Redeker

unread,
Jul 8, 2005, 2:28:34 PM7/8/05
to perl6-l...@perl.org
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

Robin Redeker

unread,
Jul 8, 2005, 11:43:01 AM7/8/05
to perl6-l...@perl.org
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.

Larry Wall

unread,
Jul 9, 2005, 10:36:10 AM7/9/05
to perl6-l...@perl.org
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

Larry Wall

unread,
Jul 9, 2005, 10:50:44 AM7/9/05
to perl6-l...@perl.org
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

Robin Redeker

unread,
Jul 9, 2005, 1:55:59 PM7/9/05
to perl6-l...@perl.org
On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> : > 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.

Yes, i would like o. more too. At least it doesn't introduce
a completly meaningless '/' preceded by a '.'.


Robin

Carl Mäsak

unread,
Jul 10, 2005, 3:12:51 PM7/10/05
to perl6-l...@perl.org
On 7/9/05, Robin Redeker <el...@x-paste.de> wrote:
> On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> > : > 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.
>
> Yes, i would like o. more too. At least it doesn't introduce
> a completly meaningless '/' preceded by a '.'.

I think we've established now that there are some people who really
don't like the ./ syntax, and who really feel like saying so,
emphatically.

I, for one, like it.

// Carl

Michele Dondi

unread,
Jul 11, 2005, 5:14:18 AM7/11/05
to Robin Redeker, perl6-l...@perl.org
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)

Larry Wall

unread,
Jul 11, 2005, 4:06:00 PM7/11/05
to perl6-l...@perl.org
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

Matt Fowles

unread,
Jul 11, 2005, 4:50:56 PM7/11/05
to perl6-l...@perl.org
Larry~

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

Larry Wall

unread,
Jul 11, 2005, 9:29:28 PM7/11/05
to perl6-l...@perl.org
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

Juerd

unread,
Jul 12, 2005, 6:59:22 AM7/12/05
to perl6-l...@perl.org
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

unread,
Jul 12, 2005, 7:11:47 AM7/12/05
to Juerd, perl6-l...@perl.org
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.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!

Aankhen

unread,
Jul 12, 2005, 7:13:06 AM7/12/05
to perl6-l...@perl.org
On 7/12/05, Juerd <ju...@convolution.nl> 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

Larry Wall

unread,
Jul 13, 2005, 6:13:02 PM7/13/05
to perl6-l...@perl.org
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

Aankhen

unread,
Jul 14, 2005, 3:09:57 AM7/14/05
to perl6-l...@perl.org
On 7/14/05, Larry Wall <la...@wall.org> 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

Juerd

unread,
Jul 14, 2005, 10:20:43 AM7/14/05
to Aankhen, perl6-l...@perl.org
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.

Carl Mäsak

unread,
Jul 14, 2005, 11:37:38 AM7/14/05
to perl6-l...@perl.org
On 7/14/05, Juerd <ju...@convolution.nl> 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

Autrijus Tang

unread,
Jul 14, 2005, 11:47:48 AM7/14/05
to Juerd, perl6-l...@perl.org
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/

Juerd

unread,
Jul 14, 2005, 3:38:45 PM7/14/05
to Nathan Gray, Carl Mäsak, perl6-l...@perl.org
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?

Nathan Gray

unread,
Jul 14, 2005, 12:55:26 PM7/14/05
to Carl Mäsak, perl6-l...@perl.org

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

Larry Wall

unread,
Jul 14, 2005, 4:39:44 PM7/14/05
to perl6-l...@perl.org
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

Rick Delaney

unread,
Jul 14, 2005, 5:35:47 PM7/14/05
to perl6-l...@perl.org
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
ri...@bort.ca

Juerd

unread,
Jul 14, 2005, 6:41:47 PM7/14/05
to perl6-l...@perl.org
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.

Yuval Kogman

unread,
Jul 14, 2005, 6:09:57 PM7/14/05
to perl6-l...@perl.org
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 <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!

Juerd

unread,
Jul 14, 2005, 6:55:37 PM7/14/05
to Yuval Kogman, perl6-l...@perl.org
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.