A6: Named vs. Variadic Parameters

0 views
Skip to first unread message

Larry Wall

unread,
Apr 4, 2003, 1:40:49 PM4/4/03
to perl6-l...@perl.org
On Fri, Apr 04, 2003 at 07:09:55AM -0800, David Storrs wrote:
: On Wed, Apr 02, 2003 at 12:18:47PM -0800, Paul wrote:
:
: > I think Larry's accomodating everybody, here.
: > Those of us who want to play with the tinkertoys will probably enjoy
: > the whole box, even the little widgets that take us a while to
: > identify.
:
: Agreed. But I'd like to keep the identification time as short as
: possible by clearly labelling everything.

I think people will learn to read

sub foo($x, $y, ?$z, *a);

rapidly, and I also think that most signatures will not be
terribly complicated.

: > David Storrs <dst...@dstorrs.com> wrote:
: > > [re: current sig syntax]
: > > In order to make it worthwhile (IMO), it would need to be very easy
: > > to use, which would imply at least the following:
: > >
: > > 1) There are both long and short forms of the zone markers.
: > > E.g: sub foo($x, $y, ?$z, *a); or
: > > sub foo(pos($x, $y), opt($z), slurp(@a));
:
: Actually, looking back, this should have been two things:
:
: 1a) There are both long and short forms of the zone markers. (E.g.,
: "?" and "optional").

Well, it's likely true that the zones will be indicated internally
by some kind of trait, for metadata purposes if for no other purpose.

: 1b) There should be a way to write it such that you don't have to
: label every parameter individually. Instead, you should be able to
: collect the params in a particular zone together and say "These all
: belong to this zone". The example above does that:
:
: sub foo(pos($u, $v, $w, $x, $y), opt($z, $zz), slurp(@a));

This looks like a really good place for a set of macros if you want
to use that style.

: I believe that the method which is currently proposed for long-form
: declarations use properties:
:
: sub foo(
: $u is positional,
: $v is positional,
: $w is positional,
: $x is positional,
: $y is positional,
: $z is optional,
: $zz is optional,
: @a is slurpy
: );

These trait names will intentionally be left verbose to encourage
their use by former COBOL programmers.

In fact, maybe we should find a meaning for:

my $x is computational;

:-)

: I'd really like to be able to save some typing here (and yes, I could
: just do it with a slurpy array/hash). I don't remember if properties
: are distributive, but if they are not, it would be a great feature to
: add (much like 'my' is distributive in P5). So, if people don't like
: my original proposed syntax, we could just use distributed properties,
: as Paul suggested:
:
: > sub foobar( ($x, $y, $z) is positional,
: > ($a, $b, $c) is optional,
: > ($d, $e, $f) is named,
: > (%h, $s, @a) is slurpificatious
:
:
: (This is something I would propose in general, incidentally, not just
: for signatures. But it's so useful and so obvious that Larry must
: have already thought of it, so I'll shut up now.)

Yes, though it's usually been mentioned with respect to things like:

my ($a,$b,$c) is constant = abc();

However, I would personally go with the prefix zone macros before using
distributed traits, just to get the zone info out front.

But before that, I'd use the single character zone markers, lined up
vertically in complicated sigs... :-)

: > Could [the signature zones] then be reordered [after being
: > explicitly labelled as above]?
:
: Well, it depends on what you're willing to give up. To me, it is
: important to ensure that the declaration of the function is good
: documentation on the correct order in which to specify the
: parameters. Therefore, I would say that no, they cannot be
: reordered. The zones should have a fixed order of occurrence and it
: should not be possible to permute that order (although it is, of
: course, feasible to leave out a portion).

You'd just need to write a macro that slurps all the args if you want
to reorder the zones. Or just override the Perl grammar's signature
rule to parse sigs however you like.

Perl 6 is designed to allow cultural experimentation. You may
reclassify any part of Perl 6 as a bike shed, and try to persuade
other people to accept your taste in color schemes. Survival of the
prettiest, and all that...

This is a playground. Thanks for playing. :-)

Larry

David Storrs

unread,
Apr 4, 2003, 2:47:26 PM4/4/03
to perl6-l...@perl.org
On Fri, Apr 04, 2003 at 10:40:49AM -0800, Larry Wall wrote:

> Yes, though it's usually been mentioned with respect to things like:
>
> my ($a,$b,$c) is constant = abc();
>
> However, I would personally go with the prefix zone macros before using
> distributed traits, just to get the zone info out front.

Ok, cool. As long as I have both of these options, I'm happy.


> Perl 6 is designed to allow cultural experimentation. You may
> reclassify any part of Perl 6 as a bike shed, and try to persuade
> other people to accept your taste in color schemes. Survival of the
> prettiest, and all that...

Well, I admit that this issue is less important than many others
(e.g., the threads thread). However, it all started when MikeL
pointed out that some function signatures mean that the function can't
be called with the params in the same order as they were declared. To
me, this violates the Principle of Least Surprise, which makes it at
least a small step up from a bike shed.


But, as I said, the macros option and the distributed properties
option both exist, so that will solve half the problem. The other
half would be fixed simply by declaring the zone order to be fixed.


--Dks

David Storrs

unread,
Apr 4, 2003, 10:09:55 AM4/4/03
to perl6-l...@perl.org
On Wed, Apr 02, 2003 at 12:18:47PM -0800, Paul wrote:

> I think Larry's accomodating everybody, here.
> Those of us who want to play with the tinkertoys will probably enjoy
> the whole box, even the little widgets that take us a while to
> identify.

Agreed. But I'd like to keep the identification time as short as
possible by clearly labelling everything.

>

> David Storrs <dst...@dstorrs.com> wrote:
> > [re: current sig syntax]
> > In order to make it worthwhile (IMO), it would need to be very easy
> > to use, which would imply at least the following:
> >
> > 1) There are both long and short forms of the zone markers.
> > E.g: sub foo($x, $y, ?$z, *a); or
> > sub foo(pos($x, $y), opt($z), slurp(@a));

Actually, looking back, this should have been two things:

1a) There are both long and short forms of the zone markers. (E.g.,
"?" and "optional").

1b) There should be a way to write it such that you don't have to


label every parameter individually. Instead, you should be able to
collect the params in a particular zone together and say "These all
belong to this zone". The example above does that:

sub foo(pos($u, $v, $w, $x, $y), opt($z, $zz), slurp(@a));

I believe that the method which is currently proposed for long-form
declarations use properties:

sub foo(
$u is positional,
$v is positional,
$w is positional,
$x is positional,
$y is positional,
$z is optional,
$zz is optional,
@a is slurpy
);

I'd really like to be able to save some typing here (and yes, I could


just do it with a slurpy array/hash). I don't remember if properties
are distributive, but if they are not, it would be a great feature to
add (much like 'my' is distributive in P5). So, if people don't like
my original proposed syntax, we could just use distributed properties,
as Paul suggested:

> sub foobar( ($x, $y, $z) is positional,
> ($a, $b, $c) is optional,
> ($d, $e, $f) is named,
> (%h, $s, @a) is slurpificatious


(This is something I would propose in general, incidentally, not just
for signatures. But it's so useful and so obvious that Larry must
have already thought of it, so I'll shut up now.)

> Could [the signature zones] then be reordered [after being
> explicitly labelled as above]?

Well, it depends on what you're willing to give up. To me, it is
important to ensure that the declaration of the function is good
documentation on the correct order in which to specify the
parameters. Therefore, I would say that no, they cannot be
reordered. The zones should have a fixed order of occurrence and it
should not be possible to permute that order (although it is, of
course, feasible to leave out a portion).


> Will it be possible to multi-declare traits like that?

Not sure how you mean multi-declare...are you talking about the
distributing of a property?


> And even once the declared types are clear, what does that say about
> the required order of accepted args?

At a minimum, the order in which they appear in the declaration must
be correct. If there are other, additionally acceptable ways to order
them, that's probably ok. But the order in the declaration must be a
valid way to call the function.


--Dks

Reply all
Reply to author
Forward
0 new messages