--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2003 at 12:19:20PM -0800, Michael Lazzaro wrote:
> > I think newbies are going to unquestionably try and put the
> > parameters in the same order as they expect to see the eventual
> > arguments, and be durn confused it doesn't work -- I know I would.
> [...]
> > Dunno. I'm just one datapoint, but I strongly see the difference
> > between (1) and (2) as being a *huge* newbie trap.
>
> Well, I guess I'm another datapoint then.
*sigh* Count me in on that one.
I *love* this sort of thing, but I *really* don't believe the average
guy is going to take the same masochistic pleasure from it as I do.....
> Although I don't consider myself a wizard by any means, I've been
> programming Perl for a long time and I'm very comfortable with it.
> I've read A6 a couple of times and been following the discussions on
> the list. And, despite all those advantages, I _still_ don't really
> grok the proposed signature stuff (it gets a little clearer every
> time I read it, but it's still awfully muddy). I hadn't even
> recognized the trap that we are discussing until this thread came up.
> I think people just coming to Perl are going to be extremely baffled
> and frustrated by the signature syntax and semantics. This is going
> to promote one of two reactions: they will leave and go to
> Python/Ruby/whatever, or they will never use signatures.
Ditto, though I realize that most people aren't going to *need* sigs
for most things.... Perl subs will just be perl subs, and folk will
only use sigs when they need what only sigs can give them. If they need
the speed and precision, they'll use an explicit signature to specify
what's required, though most of the time I think a lot of people will
still just say
sub foo { print @_ } # copied straight from A6, p.1
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. Those who just need blocks can ignore all the little
sockety-holes and connecting rods, and just stack the blocks. Those who
*need* the widgets but don't *want* to use them are a minority, even if
they be among the power users professionally.
The hard part is accomodating both ends.
> I'm still waiting for the Exegesis...I recognize that the Apocalpsi
> are hard simply because they are definitive and must cover every edge
> case. Possibly, with some day-to-day examples and down-to-earth
> tutorial materials available, all of this will become simple; that
> has happened for me before with prior Apocalpsi.
> However, even if it ends up being clarified by the Exegesis, the
> signature syntax/semantics ARE complex. In order to justify that
> complexity, they need to provide a tremendous advantage; I'm simply
> not sure that the advantages they provide are worth the complexity.
> 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));
>
> (I'm pretty sure this is already planned.)
Good! I think this is a great idea. Looks funny to me, but MUCH
clearer!
Could they then be reordered?
> 2) Once the params and their nature have been determined, it should
> be possible to use the function with the arguments in the same
> order as the declaration:
> E.g.: sub bar(pos($a, $b), slurp(@x), named($key));
> bar($a, $b, 1,2,3, key => 'jack');
>
> I understand what I'm asking here...the slurpy array must somehow
> know to "stop", which is somewhat opposed to the idea of
> "slurping". I would be perfectly happy if it were a compile-time
> error to declare the slurpy array anywhere other than last, and to
> declare positional arguments anywhere other than first.
I'm *still* fuzzy on this.
Personally, I'd just be more likely to avoid mixing types.
I'd have positionals and then optional scalars and/or slurpies,
or named pairs with optional named pairs and/or slurpy *hashes*,
but probably wouldn't mix types otherwise if I could avoid it....
But I still want to *understand* how it works, and be *able* to use all
the toys! (Damian, PLEASE find some way to magically make this all
crystal clear in the synopsis. ;o)
> I guess what I'd really like is to see the concept of 'zones' taken
> to its logical extreme; specify the order in which the zones must
> appear, and then have a marker that denotes the transition, as
> opposed to labelling every parameter.
> Therefore (violating the rule about the colon for a moment):
>
> sub foobar(
> $x, $y, $z, # required positionals go here
> o: $a, $b, $c, # optional positionals go here
> n: $d, $e, $f, # named go here
> h: %h, # slurpy hash here
> s: $s, # slurpy scalar here
> a: @a # slurpy array here
> );
>
> mygrep( Block &code, a: @list );
> init_screen( n: $color, $height, $width, h: %control_values);
Ok, cool idea. But wouldn't the long form zone markers do that?
The short ones look like classic Perl line noise. The above *looks*
better, though I might say the explicit demarkation is well enough
Huffman encoded in the long form that I don't care about the short
form. Remember the poor schmuck who's going to be reading your code in
three years, because it might just be you.
Maybe the above should be
sub foobar( $x, $y, $z, # required positionals go here
pos: $a, $b, $c, # optional positionals go here
named: $d, $e, $f, # named go here
hash: %h, # slurpy hash here
scalar: $s, # slurpy scalar here
array: @a # slurpy array here
) {
# code body here
}
or maybe even something like
sub foobar( ($x, $y, $z) is positional,
($a, $b, $c) is optional,
($d, $e, $f) is named,
(%h, $s, @a) is slurpificatious
) {
# code body here
}
though obviously, multiple slurpies at the end are redundant.
I understood that to just be syntactic example, yes?
Will it be possible to multi-declare traits like that?
And even once the declared types are clear, what does that say about
the required order of accepted args?
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
