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 <[EMAIL PROTECTED]> 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

Reply via email to