Re: .method == $self.method or $_.method?

12 views
Skip to first unread message

Adam Kennedy

unread,
Mar 17, 2005, 3:00:08 AM3/17/05
to Michael G Schwern, perl6-l...@perl.org, autr...@cpan.org
That is correct. It probably should have read "...our style policies
will be to _always_ use explicit invocants, if .foo ends up meaning
$_.foo in the final release (as it does now)".

(of course, I suspect Darren will keep using them anyways, but then he
likes to be even more explicit than I am) :)

Personally, .foo meaning $self.foo seems more consistent to my mind, and
I'd happily standardise on implicit invocants. The only minor thing I
can see would be that you will end up with a slight asymmetry question
of "if we use $:attribute for a private attribute, do we call :method
for a private method?"

Adam K

Michael G Schwern wrote:
> On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
>
>>I should add that Darren and I, who both have similar tendencies towards
>>larger scale coding where consistency is far preferred to compactness,
>>both ended up concluding that our style policies will be to _always_ use
>>explicit invocants (except of course for one liners).
>
>
> I thought your conclusion was you'd only use an explicit invocant if .foo
> meant $_.foo. And to drop it if .foo means $self.foo as there's no
> ambiguity.

Adam Kennedy

unread,
Mar 17, 2005, 2:04:56 AM3/17/05
to Michael G Schwern, perl6-l...@perl.org, autr...@cpan.org
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit invocants (except of course for one liners).

In the case of the Algorithm::Dependency module that is being ported
over as a test, and given that larger chunks of code have a tendency
towards named iterators in loops anyways, and we've ended up with the
only sane way to be the wordiest of the various ways-to-do-it.

Just for the record, I for one would have much preferred to have .foo be
the same as $.foo and @.foo and %.foo and refer to the invocant method,
at the cost of using C< map { $_.foo } >.

To describe it in emotional terms, the current situation feels
"backwards and inside out".

Adam K

Michael G Schwern wrote:
> There's a discussion going on #perl6/irc.freenode.org right now wondering
> about what .method means. We'd all assumed it meant $self.method (where
> $self is always the method invocant) but then had a look at Synopsis 12
> which states
>
> Dot notation can omit the invocant if it's in $_:
>
> .doit(1,2,3)
>
> This seems to cripple .method's usefulness by coupling it to $_ which
> can change often. Now in order to be safe for anything but trivial methods
> you're back to writing out $self all over the place, something that Perl 6
> was supposed to fix about Perl 5.
>
> It has also been pointed out that .foo, $.foo, @.foo and %.foo are all
> (intentionally) similar and all but one operates on the invocant. Only
> .foo operates on $_. This seems like a newbie trap waiting to happen.
> MOST of the time .foo will work like $self.foo but every once in a while
> they'll get caught in a gotcha.
>
> Thoughts?

Michael G Schwern

unread,
Mar 17, 2005, 2:48:05 AM3/17/05
to Adam Kennedy, perl6-l...@perl.org, autr...@cpan.org
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
> I should add that Darren and I, who both have similar tendencies towards
> larger scale coding where consistency is far preferred to compactness,
> both ended up concluding that our style policies will be to _always_ use
> explicit invocants (except of course for one liners).

I thought your conclusion was you'd only use an explicit invocant if .foo

Michael G Schwern

unread,
Mar 17, 2005, 1:52:36 AM3/17/05
to perl6-l...@perl.org, autr...@cpan.org, ad...@cpan.org

Larry Wall

unread,
Mar 17, 2005, 3:58:28 AM3/17/05
to perl6-l...@perl.org
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote:
: Personally, .foo meaning $self.foo seems more consistent to my mind, and
: I'd happily standardise on implicit invocants.

I'm thinking about it. There are definitely things to be said for both
sides, and maybe we can come up with a solution that's better than what
we have. And after all, I originally came up with the .foo notation
precisely for the purpose of leaving out $self and still having it
self-documenting, as it were. I have a vague feeling that the real
linguistic thing going on here is that you shouldn't change the meaning
of "it" within a method, so one possible solution would just be to
prohibit any rebinding of $_ to anything other than the current object.

In that case we'd have to say that "given" and "for" always require
"-> $x" inside methods, and that $x is never automatically aliased
to $_. But there are other ramifications with switch statements and
exception handlers I have to think through, and I'm a slow thinker,
and unfortunately I'm having to moonlight at a real job to put bread
on the table and pay back all the money I've borrowed over the last
several years in order to devote myself to Perl 6--so you'll all just
have to be patient with me. Well, you don't have to, but it'd be nice...

: The only minor thing I

: can see would be that you will end up with a slight asymmetry question
: of "if we use $:attribute for a private attribute, do we call :method
: for a private method?"

I think those would still be .:method, and we just live with the
asymmetry, unless we decide there's sufficient declarational power
in the class that we can always distinguish :method from :pairkey,
which there might be. But even if there is, most uses of private
methods will probably be from within trusted classes, and access to
my own attributes through $:foo instead. Plus .:method doesn't require
people to remember what's been declared to decide if it's a pair
or a private method.

Larry

Luke Palmer

unread,
Mar 17, 2005, 4:21:09 AM3/17/05
to perl6-l...@perl.org
Larry Wall writes:
> In that case we'd have to say that "given" and "for" always require
> "-> $x" inside methods, and that $x is never automatically aliased to
> $_. But there are other ramifications with switch statements and
> exception handlers I have to think through,

In particular, the fact that `map` rebinds $_. Consider:

method data () {
map { .process($_) } @.array;
}

Is that calling `$_.process($_)` for each `$_` in `@.array`, or is it
calling `$self.process($_)`? It must be the former, which, given the
context, is probably not what was intended (despite the terrible (but
unfortunately, typical) naming, we can still tell what the programmer
was thinking). `.process` means something else everywhere else in the
method, and Perl goes to great lengths to keep it that way, but in this
case it's different.

And it would be a shame to disallow the use of $_ in map.

Disallowing one of the most beautiful areas of Perl, topicalization, in
methods would be irritating at best. "Oh, so I can only program in a
crappy subset of Perl because I'm in a method?" I don't know about the
other programmers here, but just about all my code is in methods.
Actually, scanning over my most recent module, *all* my code is in
methods, except for the tests.

Luke

Autrijus Tang

unread,
Mar 17, 2005, 4:41:02 AM3/17/05
to Luke Palmer, perl6-l...@perl.org
On Thu, Mar 17, 2005 at 02:21:09AM -0700, Luke Palmer wrote:
> In particular, the fact that `map` rebinds $_. Consider:
>
> method data () {
> map { .process($_) } @.array;
> }
>
> Is that calling `$_.process($_)` for each `$_` in `@.array`, or is it
> calling `$self.process($_)`? It must be the former, which, given the
> context, is probably not what was intended (despite the terrible (but
> unfortunately, typical) naming, we can still tell what the programmer
> was thinking). `.process` means something else everywhere else in the
> method, and Perl goes to great lengths to keep it that way, but in this
> case it's different.
>
> And it would be a shame to disallow the use of $_ in map.

Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant. To use $_.foo, write $_.foo.

Thanks,
/Autrijus/

Michael G Schwern

unread,
Mar 17, 2005, 3:26:37 AM3/17/05
to Adam Kennedy, perl6-l...@perl.org, autr...@cpan.org
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote:
> The only minor thing I
> can see would be that you will end up with a slight asymmetry question
> of "if we use $:attribute for a private attribute, do we call :method
> for a private method?"

That occurs no matter if .method means $self.method or $_.method.

Anyhow, I don't see why not. :)

Garrett Goebel

unread,
Mar 17, 2005, 9:37:00 AM3/17/05
to Autrijus Tang, Luke Palmer, perl6-l...@perl.org
Autrijus Tang wrote:

> > Luke Palmer wrote:
> >
> > And it would be a shame to disallow the use of $_ in map.
>
> Err, wait, I don't think we are discussing whether $_ is to
> be outlawed in map {}.

Perhaps we should consider making $_ readonly in map and grep?

--
Garrett Goebel
IS Development Specialist

ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com

Juerd

unread,
Mar 17, 2005, 10:12:38 AM3/17/05
to Garrett Goebel, Autrijus Tang, Luke Palmer, perl6-l...@perl.org
Garrett Goebel skribis 2005-03-17 8:37 (-0600):

> Perhaps we should consider making $_ readonly in map and grep?

That's one way to avoid clever tricks. Please let's not.


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Larry Wall

unread,
Mar 17, 2005, 11:41:26 AM3/17/05
to perl6-l...@perl.org
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for $self. Suppose we pick "o" for that, short
for "object". Then we get self calls of the form:

o.frobme(...)

Now that has some interesting possibilities for variants. We could
have

c.bless(...)

which would presumably give you the class of the invocant. Perhaps
more interestingly, if o and c are functions, then you can provide
arguments, with a default of 0. So the above could really be short
for

o(0).frobme(...)
c(0).bless(...)

Now, we also have this other problem that we're forcing people to
name all the invocants for MMD methods, poor things. But with
the above notation, the first invocant is o(0), the second invocant
is o(1), etc. Not that we would encourage people to code this way,
but it'd be nice to have a way of getting at the actual args in
the same way we used to always get at them using @_. (Such a notation
might well be useful in wrappers that don't know what they're being
wrapped around, such as various debugging wrappers.)

That's what Sleepy Brain says. But Coffee Brain despises Sleepy Brain. :-)

Larry

Larry Wall

unread,
Mar 17, 2005, 11:56:43 AM3/17/05
to perl6-l...@perl.org
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
: Then we get self calls of the form:
:
: o.frobme(...)

Sleep Brain would also like to point out that this lets you use o
standalone when you want to pass the current object as an ordinary
argument to some other class. Likewise for c, if we decide to have
that too.

Coffee Brain perks up and points out that for strategic psychological
reasons it really likes the fact that, Huffmanly speaking, the dynamic
class can be as short as "c" and the static class as long as $?CLASS.

Larry

Larry Wall

unread,
Mar 17, 2005, 11:59:32 AM3/17/05
to perl6-l...@perl.org
On Thu, Mar 17, 2005 at 05:52:15PM +0100, Michele Dondi wrote:
: On Thu, 17 Mar 2005, Larry Wall wrote:
:
: >really short alias for $self. Suppose we pick "o" for that, short

: >for "object". Then we get self calls of the form:
: >
: > o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>?
: (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
:
: How 'bout a single underscore? _.frobme()?!?

Thought about those in the night, but they don't strike me as visually
distinct enough. They just look like someone stepped on the front
of your expression.

Larry

Michele Dondi

unread,
Mar 17, 2005, 11:52:15 AM3/17/05
to Larry Wall, perl6-l...@perl.org
On Thu, 17 Mar 2005, Larry Wall wrote:

> really short alias for $self. Suppose we pick "o" for that, short
> for "object". Then we get self calls of the form:
>
> o.frobme(...)

How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>?


(Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)

How 'bout a single underscore? _.frobme()?!?


Michele
--
L'amava come si ama qualcosa che e' necessario alla vita.
La odiava come si odia chi tradisce.
- Laura Mancinelli, "Gli occhi dell'imperatore"

Autrijus Tang

unread,
Mar 17, 2005, 1:09:59 PM3/17/05
to perl6-l...@perl.org
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
> I've been thinking about this in my sleep, and at the moment I think
> I'd rather keep .foo meaning $_.foo, but break the automatic binding
> of the invocant to $_. Instead of that, I'd like to see a really,
> really short alias for $self. Suppose we pick "o" for that, short
> for "object". Then we get self calls of the form:
>
> o.frobme(...)
>
> Now that has some interesting possibilities for variants. We could
> have
>
> c.bless(...)

Wow. With those single-casting-cost cantrips, the OO color will surely
make a huge comeback in Perl6: The Gathering golfing tournaments! :)

I like them. They look really really good to my eyes after the first
20 minutes or so of mental reconfiguration. For some strange
psychological reasons, they make Pugs 6.2 so much more enjoyable to
work on for me. :-)

Thanks,
/Autrijus/

Michele Dondi

unread,
Mar 17, 2005, 1:42:00 PM3/17/05
to Larry Wall, perl6-l...@perl.org
On Thu, 17 Mar 2005, Larry Wall wrote:

> : > o.frobme(...)
> :
> : How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>?
> : (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
> :
> : How 'bout a single underscore? _.frobme()?!?
>
> Thought about those in the night, but they don't strike me as visually
> distinct enough. They just look like someone stepped on the front
> of your expression.

But then do 'c' and 'o'? They're too identifier-like IMHO to be
psychologically associated with something 'special'. It kind of reminds me
of some fortran code I saw (I don't know fortran) and I could hardly cope
with those 'c'omments...

(However I would be favourable to {one,two} letter(s) long builtin
functions/operators, when they are frequently used (think huffmanization)
and talking about language design in general.


Michele
--
> Your right, I didn't think of that at all, but still, who's gonna go into
> the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, "Re: free source authentication script"

Yuval Kogman

unread,
Mar 17, 2005, 4:46:52 PM3/17/05
to Michael G Schwern, perl6-l...@perl.org, autr...@cpan.org, ad...@cpan.org
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:

method bar ($_:) {
.foo;
}

This keeps $_ unambiguosly the 'it', while 'this' is more specific.

Think:

it puts the lotion on the skin
method blah {
for ($.prisoners) {
.put($lotion, $skin); # is the same as
$_.put($lotion, $skin);
}
}

It is not us, it is not self, it is not here, it is, err, just the
default. For implies it in this case.

Contrary:

this puts the lotion on the skin
self ~~
method cooperate ($self:) { # in class Prisoner
# this method puts lotion on skin, haha
$self.put($lotion, $skin);
}

We are discussing a certain thing, which is the invocant. It's not
default. The default might be something else altogether. It's pretty
obvious that in a method like this the invocant is the default, but
what if it isn't?

Perhaps i'm sort of forcing this distinction.

However, I wouldn't be too happy with having to do this, though:

method data {
map { $OUTER::_.process($_) } .things;
}

or having to name the invocant every time I want to map {}.


Lastly, what is wrong with

$.method?

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!

Michael G Schwern

unread,
Mar 17, 2005, 6:37:44 PM3/17/05
to perl6-l...@perl.org, Yuval Kogman
This drifed off list but I don't think that was intentional.

----- Forwarded message from Yuval Kogman <nothi...@woobling.org> -----

From: Yuval Kogman <nothi...@woobling.org>
Date: Fri, 18 Mar 2005 01:12:42 +0200
To: Michael G Schwern <sch...@pobox.com>
Subject: Re: .method == $self.method or $_.method?
User-Agent: Mutt/1.5.6i

On Thu, Mar 17, 2005 at 14:42:06 -0800, Michael G Schwern wrote:
> Because $_ can change.


>
> method bar ($_:) {
> .foo;

> map { .baz } 1..10; # whoops
> }

I don't see it as a whoops. It's either or, and the user gets to
choose.

I read that as:

method bar ($self:) { for ($self) {
...
}}

BTW, given:

method bar {
# what's $self named in here?
# do you need to name it for it to be accessible?
}

S12 does not specify, as far as I can tell.

Perhaps the desired behavior could be: If the invocant is not
specified it is the default, i.e

method bar {

}

is really

method bar ($_:) {

}

and the user assumes responsibility for not resetting $_ if they
would like to keep it.

> As I understand it, $invocant.method and $.method are different. The first
> is a public attribute the second is a method call, no? And while all
> attributes have an associated method (as I understand, ie. foreach $.foo,
> $invocant.foo should always be the same) the reverse is not true.
> Foreach $invocant.foo there need not be a $.foo.

I think you are right... But here is an idea:

The only conflict I see with the reverse not being true is if you
would like to avoid calling the is rw accessor when you want to set
the attribute from within the class.

This assumes that $.attribute = ... from within an accessor means
the attribute itself, as a special case, and that all accessors are
rw when their caller is eq ::?CLASS.

Again, the problem is that an accessor that is rw and does funny
stuff to it's attribute could not be avoided when a sibling method
wants to just fudge the attribute.

On second thought, this problem seems bigger now. Opinions?

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!


----- End forwarded message -----

--

Adam Kennedy

unread,
Mar 17, 2005, 8:46:18 PM3/17/05
to perl6-l...@perl.org
> Err, wait, I don't think we are discussing whether $_ is to be outlawed
> in map {}. I think the proposal is for .method always mean $invocant.method
> and make it illegal when there is no invocants in sight, mush as $.attr
> would be illegal without an invocant. To use $_.foo, write $_.foo.

Luke is discussing flow-on effects, just as larry was with his 'o' and 'c'.

if ( .process is $_.process ) {
either {
Specify an explicit invocant <--- Larry
} or {
Specify an explicit topical variable <--- Luke's musing
}
} else {
Call methods on $_ using $_.method <--- My preference still :)
}

The only thing that worries me about "The OC" idea (how curious that a
feature is so easily named after a TV show) is that he is talking about
them being functions. I don't know enough about interals, but would that
get optimised to something faster, or do we suffer a second function
call every time we want to call a method?

I also have some worries about there being three different ways to call
a simple invocant method.

.method
$_.method (except in map/grep)
o.method

It has a faintly similar smell to the workaround-hell mod_perl 2 got
into... I'm all for TMTOWDTI, but surely the language should be elegant
enough that something as simple as calling a not-special-in-any-way
method doesn't need to have three different ways to do it?

An interesting exercise for anyone with a minicpan checkout would be to
scan CPAN and see how often the various uses are needed currently.
($self-> compared to $_->).

Granted there are a hell of a lot of caveats in that, but it there's a
10 to 1 ratio of one to the other, surely that would help to make the
prefered preference a little clearer?

Adam K

Michael G Schwern

unread,
Mar 17, 2005, 5:42:06 PM3/17/05
to Yuval Kogman, perl6-l...@perl.org, autr...@cpan.org, ad...@cpan.org
On Thu, Mar 17, 2005 at 11:46:52PM +0200, Yuval Kogman wrote:
> I think this should mean $_, and if the user really really really
> wants to do .foo on the invocant, then why not just say:
>
> method bar ($_:) {
> .foo;
> }

Because $_ can change.

method bar ($_:) {
.foo;

map { .baz } 1..10; # whoops
}

> This keeps $_ unambiguosly the 'it', while 'this' is more specific.

I'm not proposing changing what $_ means, I'm proposing changing what .method
means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
really sure where all that extra stuff about $_ was going, true as it may be.


> Perhaps i'm sort of forcing this distinction.
>
> However, I wouldn't be too happy with having to do this, though:
>
> method data {
> map { $OUTER::_.process($_) } .things;
> }
>
> or having to name the invocant every time I want to map {}.

Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.


> Lastly, what is wrong with
>
> $.method?

As I understand it, $invocant.method and $.method are different. The first


is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.

If this assumption is incorrect then my argument does collapse.

Michael G Schwern

unread,
Mar 17, 2005, 6:59:43 PM3/17/05
to perl6-l...@perl.org
[ Sorry if my replies to this thread have seemed a little disjoint. I just
realized I'd unsubscribed myself from p6l last year when I started a $job$
and never resubscribed. So I'd only been seeing fragments of the
conversation. Catching up from the archives...
]

Larry's idea of making $_ == $self in methods seems to swing the
pendulum the other way. Now its a shame to have to make everything
explicit inside map, grep, and short for loops etc... And yes, what about
given?

My immediate reaction to o.method and c.method was a little bit of the
heebie-jeebies but then I remembered hey, I wrote CLASS.pm so I could do
CLASS->method and its exactly the same thing, a constant function which
returns the name of the class. Then c.method doesn't seem so weird.

And if you want to be crazy I suppose you can define your own c() and o()
functions. :)

Its shorter than $self.method and it solves the $_ ambiguity problem so that's
good. Its a shame to lose the even shorter .method for an extremely common
task but I'm not going to quibble to much over a single character.

What it doesn't solve is the $.method vs .method issue. They look similar
but one works on the invocant and one works on $_. Still a trap.

Juerd

unread,
Mar 18, 2005, 5:37:10 AM3/18/05
to Michael G Schwern, Yuval Kogman, perl6-l...@perl.org, autr...@cpan.org, ad...@cpan.org
Michael G Schwern skribis 2005-03-17 14:42 (-0800):

> Because $_ can change.
> method bar ($_:) {
> .foo;
> map { .baz } 1..10; # whoops
> }

The problem here is not specific to methods.

It is generic to all nested uses $_. We used to see this mostly with
nested foreaches, but now we get methods too.

The solution is also generic for all these situations: either use
$OUTER::_ or give the outer $_ another (second) name.

This is consistent, easy to learn and easy to work around, especially
now that Perl has an easy syntax for aliasing.

> I'm not proposing changing what $_ means, I'm proposing changing what .method
> means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
> really sure where all that extra stuff about $_ was going, true as it may be.

That will be very weird if you still want .<foo> to work on $_. The same
prefix operator will then have two possible implied invocants. I think
of <> as a postfix *method* rather than an operator, and would want this
to be consistent.

> Right. I believe the times one will want to do a method call on $_ when it
> is *not* the invocant will be greatly outnumbered by the times when you
> want to do a method call on the invocant. Thus adding ambiguity to .method
> is not worth it.

I don't believe this, especially because I read subscripting as methods.

Isn't the whole problem solved by using dotless syntax for calling a
method on the current invocant? If calling methods on the invocant is
indeed more common, then Huffman will like this. I haven't looked into
possible clashing with subs/multis yet.

Paul Seamons

unread,
Mar 18, 2005, 11:32:13 AM3/18/05
to perl6-l...@perl.org
> Right. I believe the times one will want to do a method call on $_ when it
> is *not* the invocant will be greatly outnumbered by the times when you
> want to do a method call on the invocant. Thus adding ambiguity to .method
> is not worth it.

I think this boils it all down nicely. It seems more important to have
consistency on what .method does. I think it should stay bound to the
invocant and should die/warn if there is none. There are so many "almost"
short ways to call methods on the current topic of grep or map that it seems
a shame to mess up the consistency of .method just to remove a few
characters.

Consider:

method foo {
.do_one_thing
.and_another_thing
map { $_.do_something_with( .bar ) } .items;
# .bar worked on the invocant - not the items
.and_the_last_thing
}

method foo {
.do_one_thing
.and_another_thing
map { $^item.do_something_with( .bar ) } .items;
.and_the_last_thing
}

Both of those feel clean to me as opposed to

method foo {
o.do_one_thing
o.and_another_thing
map { .do_something_with( o.bar ) } o.items;
o.and_the_last_thing
}

Now granted - that the o. isn't the worst thing to look at. It still seems
harder to follow what is calling which method - you sort of have to deduce
that since the do_something_with call doesn't begin o and because you are in
a map then it must be behaving on the topic $_ even though $_ isn't in sight.
We have added a nother level of details (arguably ambiguity) to try and clear
up some ambiguity.

With the former methods it is clear and consistent which methods are being
called on which variables. The .method doesn't change mid method and I know
what variable is calling do_something_with because it is spelled out.

It seems that the "oc behavior" and the ".method acts on $_" are huffmanized
the wrong direction.

Now with an object in non-method we have with .method only on invocant we
have:

sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { $_.do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}

sub foo {
map { .do_something_with() } get_items();
# dies because there is no invocant
}

and with the .method uses $_ we have

sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { .do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}

We haven't really won anything other than dropping a few characters.

As I was thinking about that I began wondering if it was possible to
dynamically specify what the invocant is. Wouldn't you know it? That is
what $_ does currently - except you only get .methods, not $.properties.

The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:

method foo {
some_sub_bar();
.do_something();
# this now does get_some_other_object.do_something()
}

sub some_sub_bar {
$CALLER::_ = get_some_other_object();
}

That is kind of scary if call to another sub can hijack my method calls (I'm
sure there are other ways to hijack the method calls - but having the
invocant dynamically set offers too many dangers). Maybe it isn't possible
because $_ will be r only - but somehow I think $_ is rw and the invocant is
r only.

To sum up...

If you are in a method then you get .method and it always works even if $_ is
rebound to something else.

I think that the idea of $_ default to the invocant is necessary and good but
the mistake comes in inferring that .method then must work on $_.

.method should work on the invocant period - it just happens to be a
coincidence that $_ is the same as the invocant for most of the time.

Paul Seamons

I'll go back to lurking about now.

Larry Wall

unread,
Mar 18, 2005, 12:45:57 PM3/18/05
to perl6-l...@perl.org
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look similar

: but one works on the invocant and one works on $_. Still a trap.

Yes, and that's probably the killer of the "oc" idea. So much for
Sleep Brain, heh, heh. I think we'll need to figure out how to
shorten $_.foo instead. Either that, or there has to be a way to
explicitly make $_ the invocant of a subblock.

At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically. Also, how
much of this could be solved with functions that merely default to $_
as in Perl 5? Why do ".print" if we can say "print"? (It's not a
rhetorical question, since, .print doesn't look for another argument
in the absence of parens, and print does, which could try to slurp
up a following block. Suppose you are one of those rare people who
actually checks the return value of print to see if you filled up
the disk:

if print {...}

That doesn't parse currently, because the print will treat {...}
as a closure argument and then there's no block for the "if".
(Backtracking the parser is probably not the right answer.)

Larry

Markus Laire

unread,
Mar 19, 2005, 4:27:47 AM3/19/05
to perl6-l...@perl.org
Larry Wall kirjoitti:

> On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
> : What it doesn't solve is the $.method vs .method issue. They look similar
> : but one works on the invocant and one works on $_. Still a trap.
>
> Yes, and that's probably the killer of the "oc" idea. So much for
> Sleep Brain, heh, heh. I think we'll need to figure out how to
> shorten $_.foo instead. Either that, or there has to be a way to
> explicitly make $_ the invocant of a subblock.

What about using the "oc" idea to shorten $_.foo

x.foo

(or some other letter instead of 'x')
Still this only shortens it by one char...
(Not sure if I like this at all - just an idea...)

--
Markus Laire
<Jam. 1:5-6>

Nigel Hamilton

unread,
Mar 19, 2005, 4:13:50 AM3/19/05
to Markus Laire, perl6-l...@perl.org
>> On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
>> : What it doesn't solve is the $.method vs .method issue. They look
>> similar
>> : but one works on the invocant and one works on $_. Still a trap.
>>
>> Yes, and that's probably the killer of the "oc" idea. So much for
>> Sleep Brain, heh, heh. I think we'll need to figure out how to
>> shorten $_.foo instead. Either that, or there has to be a way to
>> explicitly make $_ the invocant of a subblock.
>
> What about using the "oc" idea to shorten $_.foo
>
> x.foo
>

How about t.foo --- t for topic? ;-)


Nige

Peter Haworth

unread,
Mar 21, 2005, 9:18:26 AM3/21/05
to perl6-l...@perl.org
On Fri, 18 Mar 2005 09:45:57 -0800, Larry Wall wrote:
> I think we'll need to figure out how to shorten $_.foo instead.

It looks short enough to me already. More importantly, its meaning
is immediately obvious.

> Either that, or there has to be a way to explicitly make $_ the
> invocant of a subblock.

How about something like this?

method foo{
.bar; # Acts on self
for @stuff {
.bar; # Acts on self
}
for @stuff -> $_ :self {
.bar; # Acts on self, which is currently $_
}
}

Seems like overkill for trivial blocks though:

map -> $_ :self { .bar } 1..10;

but you can still just write $_.bar

Maybe we could allow $_ to be elided?

map -> :self { .bar } 1..10;


> At the moment I'm trying to see if I could get used to ..method
> meaning $_.method, and whether it buys me anything psychologically.

I still prefer $_.method


> Suppose you are one of those rare people who actually checks the
> return value of print to see if you filled up the disk:
>
> if print {...}
>

> That doesn't parse currently ... (Backtracking the parser is


> probably not the right answer.)

If you're going to the trouble to check that (which I do,
sometimes), surely two extra characters [$_ or ()] aren't that
much of a problem? You probably wouldn't be using implicit
variables, anyway.

A backtracking parser seems pretty scary to me. If it takes a lot of
work for the compiler to figure things out, it's going to be even
harder for the programmer.

--
Peter Haworth p...@edison.ioppublishing.com
"I think this is one of those traumatic things eggs have to face
to prepare a good omelette."
-- Jarkko Hietaniemi

Adam Kennedy

unread,
Mar 23, 2005, 2:25:05 AM3/23/05
to perl6-l...@perl.org
> At the moment I'm trying to see if I could get used to ..method meaning
> $_.method, and whether it buys me anything psychologically.

At some point, adding another thing people have to remember in order to
save one character gets a bit self-defeating, surely.

The good thing about $_.method is that it is familiar, quite compact
anyways by virtue of using $_, and nobody is going to be surprised by it.

Personally (and I'm admittedly leaning towards simplicity lately) I'd
even throw a warning for using .method when there is an explicitly named
invocant as well.

# Good
sub foo {
.bar;
}

# Possibly confusing, throw a warning or forbid under strict?
sub foo ($self:) {
.bar;
}

# More obvious
sub foo ($self:) {
$self.bar;
}

of course, since it is still preferable to be symmetrical, if $.attr is
legal (and no warning) with a named invocant, then so should .method be.

Adam K

Piers Cawley

unread,
Mar 29, 2005, 1:04:26 AM3/29/05
to perl6-l...@perl.org
Larry Wall <la...@wall.org> writes:

> I've been thinking about this in my sleep, and at the moment I think
> I'd rather keep .foo meaning $_.foo, but break the automatic binding
> of the invocant to $_. Instead of that, I'd like to see a really,
> really short alias for $self. Suppose we pick "o" for that, short
> for "object". Then we get self calls of the form:
>
> o.frobme(...)


I really, really don't want to see .foo meaning anything but $_.foo, so how
about arranging things so that the invocant becomes $_ iff you don't give it a
name. So:

method whatever {
# $_ is whatever's invocant
}

method whosit ($self:) {
# $_ is unbound, so:
.this # fails
...
}

Note that this would also work for mappy things with pointy subs used to name
arguments.


method whatever {
map { .this } .list_of_contents; # Works, but is weird...
map -> $x { .do_something_with($x.result) } # .do_something uses the
# method's invocant.
}

Same applies to given:

method foo {
given .parent -> $p {
... # $_ is foo's invocant
}

given .parent {
... # $_ is the result of calling .parent
}
}

Luke Palmer

unread,
Mar 29, 2005, 8:14:14 AM3/29/05
to Piers Cawley, perl6-l...@perl.org
Piers Cawley writes:
> Larry Wall <la...@wall.org> writes:
>
> > I've been thinking about this in my sleep, and at the moment I think
> > I'd rather keep .foo meaning $_.foo, but break the automatic binding
> > of the invocant to $_. Instead of that, I'd like to see a really,
> > really short alias for $self. Suppose we pick "o" for that, short
> > for "object". Then we get self calls of the form:
> >
> > o.frobme(...)
>
>
> I really, really don't want to see .foo meaning anything but $_.foo, so how
> about arranging things so that the invocant becomes $_ iff you don't give it a
> name.

The problem with that is that people start learning that .foo means call
foo on the current object, and then they write:

method iterate () {
for (@.objs) {
.process($_); # oops
}
}

And they may even know the rule, but $_ is a hard thing to get used to
in Perl. I think it's best is "call a method on the current object"
looks the same everywhere it is used.

Luke

Juerd

unread,
Mar 29, 2005, 11:38:31 AM3/29/05
to Luke Palmer, perl6-l...@perl.org
Luke Palmer skribis 2005-03-29 6:14 (-0700):

> method iterate () {
> for (@.objs) {
> .process($_); # oops
> }
> }

There is an alarming similarity with

for (@hashes) {
.<process>($_)
}

Which doesn't quite use $self! .<>, .[], .{} are method calls, visually,
and should act on the same thing as their unbracketed dot friends.
Subscripting an object is bad style, so $_ for that really is the better
option, I think.

$_ is the topic, and I think that if we have two topics, Perl gets as
convoluted as Japanese for someone who doesn't understand the language.
With loop constructs, the idiomatic syntax for getting a non-$_ is
"-> $foo", and a similar thing can be done with methods: "($foo:)".

But please, let's have a single topic, and let that always be $_. If you
want to access an outer $_, that's $OUTER::_, or its alias, $foo. Just
like everywhere else in Perl. This consistency makes it easy to learn
and easy to debug when it bites.

Larry Wall

unread,
Mar 29, 2005, 12:27:36 PM3/29/05
to perl6-l...@perl.org
On Tue, Mar 29, 2005 at 06:38:31PM +0200, Juerd wrote:
: Luke Palmer skribis 2005-03-29 6:14 (-0700):

: > method iterate () {
: > for (@.objs) {
: > .process($_); # oops
: > }
: > }
:
: There is an alarming similarity with
:
: for (@hashes) {
: .<process>($_)
: }
:
: Which doesn't quite use $self! .<>, .[], .{} are method calls, visually,
: and should act on the same thing as their unbracketed dot friends.

That only saves one character over this:

for (@hashes) {
$_<process>($_)
}

: Subscripting an object is bad style, so $_ for that really is the better
: option, I think.

The alternative is for .<>, .[], and .() to be illegal on objects
that don't support those roles. Well, okay, there's yet another
alternative, which is that these operators are spelled wrong, and that
we're abusing the idea of . to make it mean too many other things,
like "eat the whitespace before this if it would look like a binary
operator." Maybe these are actually spelled _<>, _[], and _() in
their long form. Have to think about that some. But using _ instead
of . would more naturally lend itself to defaulting to $_, I think.
The main problem is it doesn't help shorten $_.method. But maybe
that's a feature. Doutless someone will define term _ to mean $_
and write _.method, which is of dubious merit. Or we could use `<>,
`[], `(), and `method if we don't use ` for qx. I daresay `method
would probably be used more than qx for many styles of programming.

: $_ is the topic, and I think that if we have two topics, Perl gets as


: convoluted as Japanese for someone who doesn't understand the language.

そう です ね...

: With loop constructs, the idiomatic syntax for getting a non-$_ is

: "-> $foo", and a similar thing can be done with methods: "($foo:)".
:
: But please, let's have a single topic, and let that always be $_. If you
: want to access an outer $_, that's $OUTER::_, or its alias, $foo. Just
: like everywhere else in Perl. This consistency makes it easy to learn
: and easy to debug when it bites.

There will certainly be a single topic. The only question is whether .
will ever default to it. I'm still leaning not.

Larry

Juerd

unread,
Mar 29, 2005, 1:40:49 PM3/29/05
to Larry Wall, perl6-l...@perl.org
Larry Wall skribis 2005-03-29 9:27 (-0800):

> and write _.method, which is of dubious merit. Or we could use `<>,
> `[], `(), and `method if we don't use ` for qx. I daresay `method
> would probably be used more than qx for many styles of programming.

Hey, look at that, backticks again :)

If the community rejected %hash`key because it was "ugly" (I still
disagree), then will it accept `keys to mean $_.keys? And doesn't
consistency want %hash`keys to be as valid as %hash.keys, then? That's
dangerously close to %hash`key, even though it means something else.

> ?$B$=$& ?$B$G$9 ?$B$M...

Hmm... (Someone translate this for me, please :))

> There will certainly be a single topic. The only question is whether .
> will ever default to it.

Any defaulting to a variable that isn't $_ practically introduces a
2nd/Nth topic, even if it isn't officially called topic.

Aaron Sherman

unread,
Mar 29, 2005, 1:04:29 PM3/29/05
to Juerd, Perl6 Language List
On Tue, 2005-03-29 at 11:38, Juerd wrote:
> Luke Palmer skribis 2005-03-29 6:14 (-0700):
> > method iterate () {
> > for (@.objs) {
> > .process($_); # oops
> > }
> > }
[...]

> $_ is the topic, and I think that if we have two topics, Perl gets as
> convoluted as Japanese for someone who doesn't understand the language.

I've put a lot of thought into this one since topics were first
broached. It's been nagging at me, and I think I see a solution.

Use "given" as a statement (not a block control operator):

given :invocant;

This binds $_ to the current invocant.

given 1;

given maintains a stack (which, itself is lexically scoped, so you don't
get to reach into a caller's givens), so here we request the 1th
(zero-indexed, of course) context.

If we call given's stack @_given, then the above statement is just:

$_ := @_given[1];

Any implicit binding of $_ other than through the use of "given" inserts
the new value into the stack, so you can do:

given 1;
given 0;
given 1;

Without changing the given stack (important for maintainable code).

This is distinct from:

given 1 { ... }

In which we bind $_ to the number 1.

This also works with labels:

OUT: for @a {
IN: for @b {
given OUT; say "Outer scope {$_}";
given IN; say "Inner scope {$_}";
}
}

by determining the @_given entry that was active in the given scope (ok,
so @_given actually contains more information than just the value
itself).

It would be potentially interesting to introduce a "give" keyword for
this purpose:

map {map {give 1} 0..1000} @foo;

which simply returns the value of {given 1;$_}

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback


Thomas Sandlaß

unread,
Mar 29, 2005, 3:34:23 PM3/29/05
to perl6-l...@perl.org
Paul Seamons wrote:
> To sum up...
>
> If you are in a method then you get .method and it always works even if $_ is
> rebound to something else.

I also have problems to perceive .method beeing bound to $_ from a
typing point of view: $_ is a dynamic variable in the runtime
environment, while the method is compiled in a class' scope. From
type theory a class should be understood as a type generator with
its $?CLASS as an implicit parameter. That means in subclasses the
invocant has the subclass type even when the method is not redefined.
That's basically a complicated way to say that all methods in Perl6
are virtual in the C++ sense ;)

So every .method would be bound to an invocant of the class type at
compile time! At that time there is no implicit $_ yet. And the set
of methods should be known to the compiler, BTW. I even doubt the
usefullness of $_ in methods: it's way too far away from the
(runtime) context. After all, OOP is about dealing with the class
and parameter environment in methods only, and it's easy to grep
the topic by means of the 'is topic' parameter trait---and call the
variable $_ if wanted.

Only in code that is outside of classes---that is subs and top level
statements (what about rules?)---method calls are compiled such that
they are invoked on $_ and the only question is if this usage might
be written without explicit $_ or if this is too easily mixed with
class coding. But I think that a programmer knows if he's in method
scope or not. OTOH, copy and paste of lines might change meaning
without the compiler having a chance to detect it!
--
TSa (Thomas Sandlaß)