Ignoring parameters

3 views
Skip to first unread message

Gaal Yahas

unread,
Jun 16, 2005, 11:55:52 AM6/16/05
to perl6-l...@perl.org
Say I have a class method in FooClass, callable as FooClass.greet():

method greet(Class $class: ) {
say "Hello, FooClass!";
}

AFAIK, this is the only signature that would work for making &greet a
class method; but note that I'm not using $class, and I'd expect the
compiler to issue a warning in such a case.

The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.

What do you say about this proposed syntax?

method greet(Class undef: ) { ... }

# the interface calls for a "floor" as 1st arg
method bereaucracy(Int undef, Int $office_number) { ... }

I'm not sure how this works for named fields, but for positional ones
it should do well, and is similar to ($a, undef, $c) = LIST syntax.

--
Gaal Yahas <ga...@forum2.org>
http://gaal.livejournal.com/

Luke Palmer

unread,
Jun 16, 2005, 3:26:31 PM6/16/05
to Gaal Yahas, perl6-l...@perl.org
On 6/16/05, Gaal Yahas <ga...@forum2.org> wrote:
> Say I have a class method in FooClass, callable as FooClass.greet():
>
> method greet(Class $class: ) {
> say "Hello, FooClass!";
> }

Aside from the fact that I don't think this is the right way to
specify class methods...

> AFAIK, this is the only signature that would work for making &greet a
> class method; but note that I'm not using $class, and I'd expect the
> compiler to issue a warning in such a case.

I don't think that the compiler should issue a warning in the case of
unused parameters. Since the names of parameters mean something more
than just how the method refers to them--they specify the names of
named parameters--it could be useful to accept a parameter that is not
used, in anticipation of them eventually being used. The "unused
parameter" warning has never caught an error that "undeclared
variable" hasn't for me (as long as I name things well), and usually
is just a cue to bring out my UNUSED fingers.

> The same problem exists with methods in classes fulfilling a role,
> but which want to ignore a parameter in a required method.
>
> What do you say about this proposed syntax?
>
> method greet(Class undef: ) { ... }

Or we could finally take an idea from C++, one that I don't think is
so unreasonable:

method greet(Class:) {...}

Since there is no :: on the front of Class, it can't be mistaken for a
parameter. That does bring up the question of what happens if you
want to specify an indirect type as the type of a parameter. Maybe we
just disallow that...

Luke

Gaal Yahas

unread,
Jun 16, 2005, 4:01:36 PM6/16/05
to Luke Palmer, perl6-l...@perl.org
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
> > Say I have a class method in FooClass, callable as FooClass.greet():
> >
> > method greet(Class $class: ) {
> > say "Hello, FooClass!";
> > }
>
> Aside from the fact that I don't think this is the right way to
> specify class methods...

What do you think is the right way to specify them?

Damian Conway

unread,
Jun 16, 2005, 5:05:11 PM6/16/05
to perl6-l...@perl.org
Gaal Yahas wrote:

> On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
>
>>>Say I have a class method in FooClass, callable as FooClass.greet():
>>>
>>> method greet(Class $class: ) {
>>> say "Hello, FooClass!";
>>> }
>>
>>Aside from the fact that I don't think this is the right way to
>>specify class methods...
>
> What do you think is the right way to specify them?

I certainly can't speak for Luke, but I think the right way to specify class
methods is:

method greet(FooClass ::class:) {
say "Hello, FooClass!";
}

And I think that subs and methods *should* complain about all unused
non-optional parameters *except* invocants.

Damian

John Siracusa

unread,
Jun 16, 2005, 5:18:51 PM6/16/05
to Perl 6 Language
On 6/16/05, Damian Conway <dam...@conway.org> wrote:
> And I think that subs and methods *should* complain about all unused
> non-optional parameters *except* invocants.

This brings up something I've been thinking about. I sometimes write a
method in Perl 5 that does something or other and then calls the superclass
method of the same name, passing all arguments. Or sometimes I pull off an
argument or two that only make sense to my method, leaving the rest for the
superclass method. This is all easy when args are just items in the @_
array.

Here are some Perl 5 examples:

# Do something then proceed with call "as usual"
sub foo
{
$_[0]->do_something_new(123, 'abc');
shift->SUPER::foo(@_);
}

# Pull off some args, do something, then proceed with call "as usual"
sub foo
{
my($self, %args) = @_;
$self->do_something_else(val => delete $args{'xyz'});
$self->SUPER::foo(%args);
}

Note that in both cases my foo() method doesn't know or care what
SUPER::foo()'s arguments are.

Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
want to lose the abilities described above. How would those examples look
in "native" Perl 6 code? (i.e., Without forcing all methods to have a
single slurpy *@args argument, emulating the Perl 5 mechanisms.)

-John


Patrick R. Michaud

unread,
Jun 16, 2005, 5:33:02 PM6/16/05
to Damian Conway, perl6-l...@perl.org
On Fri, Jun 17, 2005 at 07:05:11AM +1000, Damian Conway wrote:
> Gaal Yahas wrote:
> >On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
> >>>Say I have a class method in FooClass, callable as FooClass.greet():
> >>> method greet(Class $class: ) {
> >>> say "Hello, FooClass!";
> >>> }
> >>
> >>Aside from the fact that I don't think this is the right way to
> >>specify class methods...
> >
> >What do you think is the right way to specify them?
>
> I certainly can't speak for Luke, but I think the right way to specify
> class methods is:
>
> method greet(FooClass ::class:) {
> say "Hello, FooClass!";
> }

In the interest of keeping the design documents up-to-date, A12 says:

To declare an ordinary class method, such as a constructor, you say
something like:

method new (Class $class: *@args) { ... }

Such a method may only be called with an invocant that "isa" C<Class>,
that is, an object of type C<Class>, or derived from type C<Class>.


S12 says:

Class methods are just methods that can take a class as their invocant.

Somehow I read these as though the original poster was correct --
i.e., one creates a class method for FooClass as either

method greet(Class $class:) { say "Hello!"; }

or

method greet(FooClass $class:) { say "Hello!"; }

Are the design documents out of date in this regard? If so, can
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)

Pm

Damian Conway

unread,
Jun 16, 2005, 6:13:55 PM6/16/05
to perl6-l...@perl.org
Patrick wrote:

> Somehow I read these as though the original poster was correct --
> i.e., one creates a class method for FooClass as either
>
> method greet(Class $class:) { say "Hello!"; }

Yes. That will work, but it's not the recommended solution.


> or
>
> method greet(FooClass $class:) { say "Hello!"; }

No. That needs to be:

method greet(FooClass ::class:) { say "Hello!"; }

(as implied by "takes a class as its invocant" in S12).
^^^^^


> Are the design documents out of date in this regard? If so, can
> someone provide a patch, if not, can someone confirm that the design
> documents are correct? (I just happened to be looking at class methods
> this past week, which is why I was a little surprised by Luke and
> Damian's answers... :-)

Both documents are correct, but S12 is correcter (as you would expect).

Damian

Patrick R. Michaud

unread,
Jun 17, 2005, 10:03:57 AM6/17/05
to Damian Conway, perl6-l...@perl.org
On Fri, Jun 17, 2005 at 08:13:55AM +1000, Damian Conway wrote:
> Patrick wrote:
> > method greet(FooClass $class:) { say "Hello!"; }
>
> No. That needs to be:
>
> method greet(FooClass ::class:) { say "Hello!"; }
>
> (as implied by "takes a class as its invocant" in S12).

Okay, I'm a bit confused. I understand why the one I wrote above is
incorrect -- silly me. But I'm having trouble with the syntactical
parsing of the parameter list of the second, and I can't find any
references or similar cases in S12/A12/S06/A06. Is '::' acting as a
sigil here?

More to the point, I'm having trouble meshing this with the rules for
parameters listed in A06 (fully recognizing that there may be
"correcter" forms of A06-- I'm just trying to find what the correcter
form is ... :-). From A06, with an updated "rule sigil" for
private attributes and pod....

Here's what an individual parameter looks like:

rule parameter :w {
[ <type>? <zone>? <variable> <trait>* <defval>?
| \[ <signature> \] # treat single array ref as an arg list
]
}

rule zone { <[?*+]> }
rule variable { <sigil> <name> [ \( <siglet> \) ]? }
rule sigil { <[$@%&]> <[*.:?^=]>? }

I'm missing something fundamental in getting

method greet(FooClass ::class:) { say "Hello!"; }

to parse.

Pm

Larry Wall

unread,
Jun 17, 2005, 2:09:28 PM6/17/05
to perl6-l...@perl.org
On Fri, Jun 17, 2005 at 09:19:17AM +0200, "TSa (Thomas Sandlaß)" wrote:
: Ohh, does that mean that ::class can be used as a type
: inside the body? E.g.
:
: method template ( FooClass ::foo :)
: {
: my foo $f;
:
: ... # use $f
: }

Certainly. It's exactly the same situation as a &func formal parameter
allowing you to call func without the &. The :: is a real sigil in that
regard, and function parameters are real declarations.

Larry

Larry Wall

unread,
Jun 17, 2005, 2:56:11 PM6/17/05
to perl6-l...@perl.org
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?

Yes.

: rule variable { <sigil> <name> [ \( <siglet> \) ]? }


: rule sigil { <[$@%&]> <[*.:?^=]>? }

rule sigil { [ <[$@%&]> | <'::'> ] <[*.:?^=]>? }

which would, I suppose, have to parse :::foo as a private :foo package name.

Larry

John Siracusa

unread,
Jun 17, 2005, 3:38:59 PM6/17/05
to Perl 6 Language
On 6/17/05, Larry Wall <la...@wall.org> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't

> : want to lose the abilities described above. How would those examples look
> : in "native" Perl 6 code? (i.e., Without forcing all methods to have a
> : single slurpy *@args argument, emulating the Perl 5 mechanisms.)
>
> Something like:

>
> # Do something then proceed with call "as usual"
> method foo (*@args)
> {
> ./do_something_new(123, 'abc');
> ./SUPER::foo(@args);
> }

Hm, but will that still catch cases where I call foo() with incorrect
arguments? I like the idea of method signatures that help catch incorrect
calls, but I don't quite understand how I can be ignorant of the "super"
method's signature while (essentially) delegating to it after doing my
thing. Looking at the above, I wonder if my overridden foo() would
basically remove the benefit signatures, allowing me to call it any which
way. (Whereas the superclass foo() might have a really strict signature and
catch any bad calls.)

(BTW, I'm not sure where those "./" thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be ".")

> But you probably want to avoid "super" semantics and write that:
>
> method foo ()
> {
> ./do_something_else(val => %_<xyz>);
> next;
> }
>
> I've also taken the liberty of deleting your delete, on the assumption
> that your "next" method might want to see the same argument and do
> something else with it. A set of "next" methods need a consistent
> parameter namespace in any event, so there's no harm in leaving the
> parameter in %_, and some performance benefit in not doing something
> better performed by GC (we hope).

What do you mean by "a consistent parameter namespace"? Surely they don't
need to have the same signature(?) That's kind of the point of my second
example: to override a method, add stuff to the signature, act on the new
params, and then delegate the rest to the superclass, calling it as if the
subclass's added params were never there. That's why I deleted the param
from the hash in the Perl 5 example.

In Perl 6, I'd expect the superclass to puke at runtime if I try to pass it
a parameter that's not in its signature. I thought you had to explicitly
slurp up "any other args" in your signatures, but I guess I misremembered.

Anyway, I guess I'm just trying to have my cake and eat it too. I want Perl
5's ability to transparently pass "any remaining/all args" to a superclass
without having to know what kind of args the superclass expects, but I
*also* want to get all of the benefits of strict method signature checking,
even in my subclass method. So...

class MySubClass; # a subclass of MyClass

method foo(<MyClass::foo's signature>, <custom args, if any>)
{
# do stuff with custom args, removing them when done
# call MyClass::foo with the remaining args
}

...all without ever knowing or caring what MyClass::foo's signature actually
is, of course. Maybe I'm asking for too much? (Or maybe I just have to
wait for Damian to come up with some clever technique to do it... ;)

-John


Patrick R. Michaud

unread,
Jun 17, 2005, 3:01:30 PM6/17/05
to perl6-l...@perl.org

Works for me (for now), thanks!

Pm

Larry Wall

unread,
Jun 17, 2005, 3:16:09 PM6/17/05
to Perl 6 Language
On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
: Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't

: want to lose the abilities described above. How would those examples look
: in "native" Perl 6 code? (i.e., Without forcing all methods to have a
: single slurpy *@args argument, emulating the Perl 5 mechanisms.)

Something like:

# Do something then proceed with call "as usual"

method foo (*@args)
{
./do_something_new(123, 'abc');
./SUPER::foo(@args);
}

# Pull off some args, do something, then proceed with call "as usual"
method foo ()
{
./do_something_else(val => delete %_<xyz>);
./SUPER::foo(%_);
}

All methods get a slurpy %_ unless you declare your own. But you probably


want to avoid "super" semantics and write that:

method foo ()
{
./do_something_else(val => %_<xyz>);
next;
}

I've also taken the liberty of deleting your delete, on the assumption
that your "next" method might want to see the same argument and do
something else with it. A set of "next" methods need a consistent
parameter namespace in any event, so there's no harm in leaving the
parameter in %_, and some performance benefit in not doing something
better performed by GC (we hope).

Larry

Patrick R. Michaud

unread,
Jun 17, 2005, 6:40:24 PM6/17/05
to Damian Conway, Perl 6 Language
On Sat, Jun 18, 2005 at 08:18:17AM +1000, Damian Conway wrote:
> The point being that methods no longer topicalize their invocant.

To update the design docs, A06 currently says:

Methods, submethods, macros, rules, and pointy subs all
bind their first argument to C<$_>; ordinary subs declare a lexical
C<$_> but leave it undefined.

So, methods and submethods no longer bind their
first argument to C<$_>? Then do we need this statement at all?
(I'm suspecting that rules won't need it, leaving just macros and
pointy subs.)

There are other places in A06 that discuss methods, submethods, and
multimethods binding their first arguments to $_ -- I'll see about
putting [Update:...] notes in there for each of those.

I'll also come up with some patches to S12 for the ./ syntax.

Pm

Damian Conway

unread,
Jun 17, 2005, 6:18:17 PM6/17/05
to Perl 6 Language
John Siracusa wrote:

> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
> showed in your message. I'm assuming it should just be ".")

No. There's now also a unary ./ operator in Perl 6.

Unary . calls a specified method on the current topic.
Unary ./ calls a specified method on the current invocant.

The point being that methods no longer topicalize their invocant. So you need
to use ./ instead of . to call methods on an implicit invocant.

Damian

Abhijit Mahabal

unread,
Jun 17, 2005, 6:54:53 PM6/17/05
to Damian Conway, Perl 6 Language

Er, is it true that methods don't topicalize the invocant nowadays? I had
thought that they do and one needs the ./ to still talk about the invocant
if some inner loop stole the $_, and until such stealing occurs .foo() and
./foo() are the same...

--abhijit

>
> Damian
>
>

Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/

John Siracusa

unread,
Jun 17, 2005, 7:38:10 PM6/17/05
to Perl 6 Language

Wow, that..er...how did I miss that? It looks a lot like running an
executable in the current dir instead of letting the shell search its path.
Was that intentional? Was this syntax discussed on a mailing list or
elsewhere? I really liked plain old .foo(), but I guess I'll just use
explicit invocants and look like an old fuddy duddy... :)

(also, at least it's not "/." <shudder> ;)
-John

Damian Conway

unread,
Jun 17, 2005, 8:33:11 PM6/17/05
to Perl 6 Language
Abhijit Mahabal asked:

> Er, is it true that methods don't topicalize the invocant nowadays?

If it's not true, it darn well ought to be!


> I had thought that they do and one needs the ./ to still talk about the
> invocant if some inner loop stole the $_, and until such stealing occurs
> .foo() and ./foo() are the same...

I think that would be a really bad idea. It's a gilt-edged invitation for
errors to creep in as calls to .meth() silently change semantics when code is
refactored.

The whole point of ./ is to have one unambiguous way of calling methods on an
implicit invocant. I'm arguing that that one umambiguous way should be the
*only* way. Having an unambiguous way *and* an ambiguous way seems like poor
design.

Damian

Damian Conway

unread,
Jun 17, 2005, 8:37:15 PM6/17/05
to Perl 6 Language
John Siracusa wrote:

> Wow, that..er...how did I miss that? It looks a lot like running an
> executable in the current dir instead of letting the shell search its path.

That's the mnemonic, yes. Call this functionality relative to the current
"location" (i.e. invocant).


> Was this syntax discussed on a mailing list or
> elsewhere?

Both on the mailing list and within @Larry.


> I really liked plain old .foo(),

We felt the ambiguity and change-of-semantics within topicalizers made it
unacceptable.


> but I guess I'll just use
> explicit invocants and look like an old fuddy duddy... :)

That's fine, Gramps! ;-)


> (also, at least it's not "/." <shudder> ;)

<grin>

Damian

John Siracusa

unread,
Jun 17, 2005, 10:42:21 PM6/17/05
to Perl 6 Language
(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)

On 6/17/05 6:18 PM, Damian Conway wrote:

Someone pointed me to the giant p6l thread on this issue (which I now recall
seeing in my email client months ago but totally ignored at the time for
some reason). As you might guess from my initial identification of this
syntax as some sort of text mangling bug in Gmail, I'm not a fan. I get the
shell connection but that / just screams "file path" to me, not "object" or
"invocant." Forgive me for coming in late, but here's hoping it's better
than never :)

I was all ready to suggest .:method, but then I was reminded of that
syntax's other purpose. I'm not, however, buying Damian's argument here:

On 2005-05-15 20:33:19, dam...@conway.org (Damian Conway) said:
> This missing design rationale here is that the colon acts as part of the unary
> operator:
>
> ./ unary public-method-call-on-invocant
> .: unary private-method-call-on-invocant

It strikes me as more of a "rationalization" than a "rationale"--picking out
patterns after the fact, because that's what our brains like to do. So if
you're willing to give up this nugget of comforting symmetry, I propose
this:

.: unary public-method-call-on-invocant
.:: unary private-method-call-on-invocant

Okay, now maybe it looks like a package separator instead of a file path,
but at least that's in the OO ballpark. I also admit to not fully
understanding any possible parse/lex implications. But assuming it's
possible, I like it a lot better than "./"

All three keys are in a tight little cluster, so the odds of typo-ing a
public method call to a private method call seem about equally likely in
both cases, even allowing for the different uses of shift. One is not much
more difficult to type than the other either.

The .:: also looks "deeper" to me, suggesting "private." See what I mean
about picking out patterns after the fact? ;) But the truth is that /
really does look file-path-y to me, and just plain old ugly. I think at
least two other people had similar reactions (Martin Kuehl and Carl Franks).
Maybe .:: has even more detractors, I dunno. All I know is that I dislike
./ and I'm trying to come up with an alternative. What say you all? Too
many dots in .::? Surely ./ isn't as good as it gets...

Anyway, sorry for the thread necromancy, but I let -> drift away with barely
a whimper and so I think latent guilt may be driving me to fight for this
one at least a little bit... :)

-John


David Storrs

unread,
Jun 17, 2005, 10:56:55 PM6/17/05
to Perl 6 Language

On Jun 17, 2005, at 10:42 PM, John Siracusa wrote:
> But the truth is that /
> really does look file-path-y to me, and just plain old ugly. I
> think at
> least two other people had similar reactions (Martin Kuehl and Carl
> Franks).

David Storrs, reporting to show solidarity, sir(acusa)!

> Maybe .:: has even more detractors, I dunno. All I know is that I
> dislike
> ./ and I'm trying to come up with an alternative. What say you
> all? Too
> many dots in .::? Surely ./ isn't as good as it gets...

I'm not fond of .:: because I don't think it's sufficiently visually
distinct from .:.

I don't have a better suggestion...but that's mostly because I
dislike this entire concept of secondary sigils. I already get to
have the "Perl is line noise!" conversation _way_ too often...I don't
feel that we need to give the trolls more ammunition. For that
matter, I'm a Perl zealot and /I/ think they're ugly and obfuscatory.

For what it's all worth, I suppose.


--Dks

John Siracusa

unread,
Jun 17, 2005, 10:50:02 PM6/17/05
to Perl 6 Language
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:

On 6/17/05 10:42 PM, John Siracusa wrote:
> [...] I'm not, however, buying Damian's argument here:


>
> On 2005-05-15 20:33:19, dam...@conway.org (Damian Conway) said:
>> This missing design rationale here is that the colon acts as part of the
>> unary
>> operator:
>>
>> ./ unary public-method-call-on-invocant
>> .: unary private-method-call-on-invocant
>>

>> So the rule is:
>>
>> One-character operator --> call on $_
>> Two-character operator --> call on $?SELF"


>
> It strikes me as more of a "rationalization" than a "rationale"--picking out

> patterns after the fact, because that's what our brains like to do. [...]

-John


John Siracusa

unread,
Jun 17, 2005, 11:13:07 PM6/17/05
to Perl 6 Language
On 6/17/05 10:56 PM, David Storrs wrote:
> I'm not fond of .:: because I don't think it's sufficiently visually
> distinct from .:.

Hm, let's look at it:

method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}

Maybe lined up?

.::internal_value();
.:public_value();

I don't mind it, dots and all. I also think the .:: is quickly identifiable
as "thicker" than .: even at a glance. YMMV.

> I don't have a better suggestion...but that's mostly because I
> dislike this entire concept of secondary sigils. I already get to
> have the "Perl is line noise!" conversation _way_ too often...I don't
> feel that we need to give the trolls more ammunition.

I think $ is way more objectionable to the lily-white non-Perl heathens, but
I don't really care about them either way. I'm just saying ./ screams "file
path" to me, or maybe even "typo-ed Java/C++ comment" or something.
Certainly not "method invocation" or "implicit invocant." The .: thing,
OTOH, totally works for me and I've always liked it. I'm just trying to
stretch it to cover both public and private. Maybe there's something better
than both.

(You know, if I had a nickel for every minute I've spent staring at my
keyboard's key caps while reading the p6 lists over the years...)

-John


Adam Kennedy

unread,
Jun 18, 2005, 12:23:07 AM6/18/05
to perl6-l...@perl.org
The reason we ended up at ./method was simply because it was the best
suggestion anyone had.

Compared to the previous suggestions it was way ahead.

It's other advantage is that (except for on nordic keyboards) dot and
slash are generally right next to each other, so the expense of using it
is two chars and one fingering position, as they would likely be hit by
fourth and fifth fingers (for touch typist style) and some other two
fingers for the rest of us, and only 1 cm travel for hunt and peck.

It has a very low RSI index :) (something I don't think we take into
account enough as it is when we use the Huffman name to justify
shortening something)

So call it (2ch|2key|1pos|1cm) cost

.::method on the other hand is 2 chars, 4 keystrokes, one of which must
be held down between the two colons, is a strech for touch typists,
requires you to get you hand completely away from the letters for the
rest, and god help the hunt and peckers.

Something like (3ch|4.5key|2pos|5cm) cost.

And I dislike having a THIRD sigil even more than I dislike the second.

Adam K

John Siracusa

unread,
Jun 18, 2005, 7:52:10 AM6/18/05
to Perl 6 Language
On 6/18/05 12:23 AM, Adam Kennedy wrote:
> The reason we ended up at ./method was simply because it was the best
> suggestion anyone had.

That's what I'm trying to remedy :)

> It's other advantage is that (except for on nordic keyboards) dot and
> slash are generally right next to each other, so the expense of using it
> is two chars and one fingering position, as they would likely be hit by
> fourth and fifth fingers (for touch typist style) and some other two
> fingers for the rest of us, and only 1 cm travel for hunt and peck.

As I noted, . and : are also right next to each other. Yes, there's a
modifier (shift) for one of them, but I didn't see anyone crying when .: was
originally proposed, and .:: is just a double-tap on the 2nd key. IMO, the
"RSI index" is basically a wash between .: and ./. The "ugliness" and
"appropriateness" indexes, OTOH, heavily favor .: and .::, IMO.

BTW, I'm still not sure which will be more common, private or public
implicit-invocant method calls. I assigned .:: to private because it simply
looks "more internal" to me.

> And I dislike having a THIRD sigil even more than I dislike the second.

Objective-C has some spare characters if you're feeling adventurous :)

[.method()] # ha, jk
.-method()
.@method()

Hm, that last one actually isn't half bad, the mnemonic being "call this
'at' the current object"...or something. Again, maybe it's not feasible due
to parsing constraints.

How about resurrecting the spirit of the arrow?

.>method()

That actually looks more "private" to me. Let's line 'em up again:

PUBLIC PRIVATE
---------- ----------
./method() .:method()
.@method() .:method()
.>method() .:method()
.:method() .>method()
.:method() .::method()

I'm just trying to get some more suggestions out there "on paper," because
it seemed to me that the old thread jumped from ^ to ./ with less
exploration than I'd like.

-John


Darren Duncan

unread,
Jun 18, 2005, 2:40:29 PM6/18/05
to Perl 6 Language
At 7:52 AM -0400 6/18/05, John Siracusa wrote:
>That actually looks more "private" to me. Let's line 'em up again:
>
> PUBLIC PRIVATE
> ---------- ----------
> ./method() .:method()
> .@method() .:method()
> .>method() .:method()
> .:method() .>method()
> .:method() .::method()
>
>I'm just trying to get some more suggestions out there "on paper," because
>it seemed to me that the old thread jumped from ^ to ./ with less
>exploration than I'd like.

As I recall, it was decided for a broad scope that public and private
item invocation syntax was exactly the same but with the
consideration that all private items have a ':' as the first
character in their otherwise alphanumeric names (the ':' looks like
part of an operator but it isn't).

That seems to be getting ignored in this discussion, and I *like*
that ':' public vs private consistency, so here's an alteration to
your table:

PUBLIC PRIVATE
---------- ----------
./method() ./:method()
.@method() .@:method()
.>method() .>:method()

This looks way more consistent and predictable to me.

-- Darren Duncan

John Siracusa

unread,
Jun 18, 2005, 7:55:20 PM6/18/05
to Perl 6 Language
On 6/18/05 2:40 PM, Darren Duncan wrote:
> As I recall, it was decided for a broad scope that public and private
> item invocation syntax was exactly the same but with the
> consideration that all private items have a ':' as the first
> character in their otherwise alphanumeric names (the ':' looks like
> part of an operator but it isn't).

Doh! If that's the case, then your revised table is indeed the place to
start. I'll throw one more on for good measure.

PUBLIC PRIVATE
---------- ----------
./method() ./:method()
.@method() .@:method()
.>method() .>:method()

.-method() .-:method()

I was also thinking about putting something before the . instead of after
it. That actually makes more sense as a location for a syntax for an
implicit invocant, since the invocant would come before the . too.

Unfortunately, a that syntax is used for member variables and such, so the
usual sigils are out ($ @ % &), and the rest start to look like unary
operators on method calls implicitly made on $_ (e.g., -.method())

So we're back to the table above, I guess. I miss .::method(), but of the
above choices I think I'd rank them this way, from best to worst.

PUBLIC PRIVATE
---------- ----------
.@method() .@:method() # best
.>method() .>:method() # .
.-method() .-:method() # .
./method() ./:method() # worst

It was a tough battle for last place, but in the end I think - even is a
nicer placeholder for an implicit "something." I just can't get over the
path-y-ness of ./ (not to mention the division-y-ness)

-John


Juerd

unread,
Jun 18, 2005, 7:54:54 PM6/18/05
to Darren Duncan, perl6-l...@perl.org
Darren Duncan skribis 2005-06-18 11:40 (-0700):

> item invocation syntax was exactly the same but with the
> consideration that all private items have a ':' as the first
> character in their otherwise alphanumeric names (the ':' looks like
> part of an operator but it isn't).

Except for attributes, which play a different game: the colon comes
*instead* of the dot as the twigil, while the accessor method gets : in
front of its name. If I recall correctly, the syntax is very misleading
in that it is NOT part of the name.

I don't like the inconsistency.

> PUBLIC PRIVATE
> ---------- ----------
> ./method() ./:method()

./:method is what I originally suggested along with my suggestion of
./method itself. I strongly dislike that .:method would work on $?SELF
and I also strongly dislike the contrived and false
two-\W-characters-mean-invocant-otherwise-it's-$_ rule. (It'd be true
(but would still feel artificial) if .+method would also use the
invocant. Which I pray is not the case.)

I do not want there to be any indication of there being two defaults and
that there is a way to select the other default. ./ is an operator by
itself and not the combination of . and /, and it cannot be used infix.
There is only ever one default variable|object in syntax, and that is
$_.

I'd like the colon to be part of the name, like underscore is used in
Perl 5: outside access is discouraged but entirely possible. I don't
think ANY syntax should be special cased for a method, just because it's
private. That doesn't mean there can't be a warning (warnings are not
syntax), and in fact a warning is all there should IMO be.

This means these public-private equivalency pairs exist:

$foo.bar $foo.:bar
.bar .:bar
./bar ./:bar
$.bar $.:bar # I wouldn't mind if $:bar were an *abbreviation*
.+bar .+bar
./+bar ./+:bar

(People could introduce other prefixes (although the number of available
characters is very limited) for other accessability indicators, like
perhaps .@method to allow web access.

> .@method() .@:method()

In Perl, @ has a VERY strong association with arrays, so except for
specialised frameworks, I recommend against using it for other purposes.

> .>method() .>:method()

I think > has just enough purposes, and that it should be left alone
now.

> gt
=> pair
==> pipe
<> qw
<<>> qw
+>, ~> shift
->, <-> sub


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

Juerd

unread,
Jun 18, 2005, 8:46:41 PM6/18/05
to John Siracusa, Perl 6 Language
John Siracusa skribis 2005-06-18 20:35 (-0400):
> On 6/18/05 8:28 PM, Juerd wrote:
> > The unix shell and things resembling it will still be in use much fifteen
> > years after today, Perl 5 will not.
> Ooo, a bold prediction :)

Do you really think so? I think that there is no way that Perl 5 can
survive another 15 years. It used to be the best tool for almost
everything, but for some purposes there are already better tools. Perl 5
had a long life for a dynamic language, but it's fading quickly. Web
monkeys choose PHP now (they wouldn't have if our interpreters were
light weight and mod_perl could be more like mod_php), larger systems
are more and more written in Ruby and Python, and with PCRE, using
regexes for basic string manipulation got easy in dozens of languages.

The only things that really keeps Perl 5 alive (sort of) are CPAN and
the community. The community is a fragile thing, and CPAN is more and
more known as that uncontrolled place where any newbie can upload their
templating engine and DBI wrapper.

While unixish shells probably won't evolve much further. Microsoft is
trying now, but their approach isn't needed in sh-land, because we've
used those techniques for ages. The syntax is somewhat awkward, but if
that's the only thing, you take it for granted because that keeps things
compatible with existing code.

John Siracusa

unread,
Jun 18, 2005, 8:35:23 PM6/18/05
to Perl 6 Language
On 6/18/05 8:28 PM, Juerd wrote:
> The unix shell and things resembling it will still be in use much fifteen
> years after today, Perl 5 will not.

Ooo, a bold prediction :)

-John


John Siracusa

unread,
Jun 18, 2005, 8:16:28 PM6/18/05
to Perl 6 Language
On 6/18/05 7:54 PM, Juerd wrote:
>
>> .@method() .@:method()
>
> In Perl, @ has a VERY strong association with arrays, so except for
> specialised frameworks, I recommend against using it for other purposes.

The / character has very strong associations in nearly every programming
language with division. In Perl it's also strongly associated with regexes,
albeit in pairs. In Unix and URLs, it's associated with file paths. At
least @ is vaguely associated with method calls in one existing programming
language (Objective-C).

>> .>method() .>:method()
>
> I think > has just enough purposes, and that it should be left alone
> now.
> > gt
> => pair
> ==> pipe
> <> qw
> <<>> qw
> +>, ~> shift
> ->, <-> sub

I don't think there's any confusion between .>method() and the other uses.
In fact, I'd say there's less potential ambiguity about the > in .>method()
than in some of other uses of the > character. And that's what's important:
ambiguity, not some arbitrary limit on the number of places that a character
should be used.

Also, in the context of Perl, >'s historic usage in as the method caller
thingie -> in Perl 5 and its Perl 6 usage as the sub thingie -> ties > to
method/function calls much more strongly than /.

-John


Juerd

unread,
Jun 18, 2005, 8:28:02 PM6/18/05
to John Siracusa, perl6-l...@perl.org
John Siracusa skribis 2005-06-18 20:16 (-0400):

> On 6/18/05 7:54 PM, Juerd wrote:
> > In Perl, @ has a VERY strong association with arrays, so except for
> > specialised frameworks, I recommend against using it for other purposes.
> The / character has very strong associations in nearly every programming
> language with division.

That is true. But in nearly every single US household and business, the
dollar sign has to do with money. We create our own uses for existing
characters. Sometimes this is based on something that we can recognise
from inside or outside Perl, but almost never is something avoided
because it has another meaning in another context. Perl would not be
possible if we'd let ourselves be limited by this.

> In Perl it's also strongly associated with regexes, albeit in pairs.

Regexes and other quotelike forms. qw/foo bar/ is very common use. $/
had nothing to do with regexes in Perl5 (in a way, it did have to do
with division), but it will in Perl 6. Even though it's not in pairs.

> In Unix and URLs, it's associated with file paths.

Yes. And . in a file path means current working directory. That's about
as close to current working invocant as one can get :)

> At least @ is vaguely associated with method calls in one existing
> programming language (Objective-C).

I don't know objective C.

> >> .>method() .>:method()
> > I think > has just enough purposes, and that it should be left alone
> > now.
> > > gt
> > => pair
> > ==> pipe
> > <> qw
> > <<>> qw
> > +>, ~> shift
> > ->, <-> sub
> I don't think there's any confusion between .>method() and the other uses.

I think there is. There is little point in further arguing over this.

> Also, in the context of Perl, >'s historic usage in as the method caller
> thingie -> in Perl 5 and its Perl 6 usage as the sub thingie -> ties > to
> method/function calls much more strongly than /.

-> in Perl 6 not being related in any way (except spelling) to what ->
used to do in Perl 5 makes this highly irrelevant. The unix shell and


things resembling it will still be in use much fifteen years after today,

Perl 5 will not. Perl 6 is much about not letting history get in the way
of good things.

John Siracusa

unread,
Jun 18, 2005, 8:33:06 PM6/18/05
to Perl 6 Language
On 6/18/05 8:11 PM, Juerd wrote:
> John Siracusa skribis 2005-06-18 19:55 (-0400):

>> ./method() ./:method()
>> .@method() .@:method()
>> .>method() .>:method()
>> .-method() .-:method()
> [...]

>> ./method() ./:method() # worst
>
> Why exactly is the slash not acceptable for you? Almost everyone has
> said they like it. I personally find ./method prettier and easier to
> type than any of the alternatives.

I think it's jarring. It definitely doesn't look like a method call to me.
It looks out of place, like a typo of some kind. That was my honest initial
reaction, as I posted earlier. I literally didn't even consider that it
could be some sort of new syntax--and that's saying a lot considering I was
reading p6l. I though GMail had mangled the text while trying to interpret
quoting or something.

>> It was a tough battle for last place, but in the end I think - even is a
>> nicer placeholder for an implicit "something." I just can't get over the
>> path-y-ness of ./ (not to mention the division-y-ness)
>

> The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor
> between cwd and $?SELF plays for mnemonic.

I understand that, but I don't think it's a very applicable analogy. First,
I think it's a long bridge from the file/path world to method calls.
Second, even ignoring that, ./ in file/path context is a composition of two
well-defined primitives, rather than the single unit proposed for Perl 6,
the "call this on $?SELF" operator. (That could also be why I was breaking
./ down into . and / earlier, proposing alternatives for the / part alone.)

> The divisioniness is something you'll just have to get over. Do you see
> any division in /\w+/?

No, because it's in pairs there (and because of ~12 years of perl 4-5 :)

> Or any addition in $foo +| $bar? Or any comparison in =>, +>, or <>? Or any
> price in $var? Or any percentage in %hash? Or any conjunction in &sub?

I do see a bit of addition in +|. The > constructs mostly look arrow-y to
me, which is usually the intention (again, except in pairs where it looks
bracket-y). Price in $var, well, years of shell combine there with years of
perl (not to mention BASIC or whatever :) % and & mostly ride on the perl
4-5 wave mentioned above.

Anyway, I'm just giving my opinion. At least three other people agree with
me, although we do seem to be in the minority so far. I'm just hoping
there's an alternative that everyone will like better :)

-John


Juerd

unread,
Jun 18, 2005, 8:11:59 PM6/18/05
to John Siracusa, Perl 6 Language
John Siracusa skribis 2005-06-18 19:55 (-0400):
> ./method() ./:method()
> .@method() .@:method()
> .>method() .>:method()
> .-method() .-:method()
[...]

> ./method() ./:method() # worst

Why exactly is the slash not acceptable for you? Almost everyone has


said they like it. I personally find ./method prettier and easier to
type than any of the alternatives.

> I was also thinking about putting something before the . instead of after


> it. That actually makes more sense as a location for a syntax for an
> implicit invocant, since the invocant would come before the . too.

It's not "implicit invocant". You're not selecting a second default (the
first being $_).

The slash does not represent $?SELF.

And there is no such thing as $object./method.

Instead, see ./ as a whole.

I agree that the dot makes it look like .:, .+, .=, but anything without
the dot is practically impossible because we're out of characters. ^ is
the only single-character possibility. Many people have said to dislike
^method, some have said to like it.

And if you're using two characters, ./ is a good one because it's easy
to type, good looking and looks familiar (and can thus get a mnemonic,
even if the metaphor is far fetched).

> Unfortunately, a that syntax is used for member variables and such, so the
> usual sigils are out ($ @ % &), and the rest start to look like unary
> operators on method calls implicitly made on $_ (e.g., -.method())

-.method should return -5 if .method returns 5. Minus in term position
is already taken. Please refer to the "available operator characters"
thread: we have only ^ we can reliably use without shuffling other
things around or using whitespace.

> It was a tough battle for last place, but in the end I think - even is a
> nicer placeholder for an implicit "something." I just can't get over the
> path-y-ness of ./ (not to mention the division-y-ness)

The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor


between cwd and $?SELF plays for mnemonic.

The divisioniness is something you'll just have to get over. Do you see
any division in /\w+/? Or any addition in $foo +| $bar? Or any


comparison in =>, +>, or <>? Or any price in $var? Or any percentage in
%hash? Or any conjunction in &sub?

Juerd

unread,
Jun 18, 2005, 8:55:07 PM6/18/05
to John Siracusa, perl6-l...@perl.org
John Siracusa skribis 2005-06-18 20:33 (-0400):

> I literally didn't even consider that it could be some sort of new
> syntax--and that's saying a lot considering I was reading p6l.

You missed a 33 message thread that was referred to many times. Such
things happen, I am surprised by new inventions all th