Re: Beefier prototypes (was Re: Multiple for loop variables)
Could the prototype people please report whether Tim Bunce's issues with prototypes have been intentionally/adequately addressed? I'm not a prototype person (in fact RFC 128 makes it a hanging offence to use that confusing word in connection with parameter lists! ;-) Could someone please recapitulate Tim's issues? The long story is here: http://www.perl.com/pub/language/misc/bunce.html The short story includes details that involve how to permit sub fn($$$) to work with fn(@foo) where @foo==3, which won't be known till runtime. --tom
Re: Beefier prototypes (was Re: Multiple for loop variables)
[This somewhat elderly draft was found lying about an edit
buffer, but I do not believe it was ever sent yet.]
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent, that is pretty much the most important
feature of Perl. IMO. Perl would not be Perl without it.
Well, "most important" is an interestingly strong way of phrasing it.
But how to deal with variadicity in an intuitive fashion is hard.
You seem to have to sacrifice compile-time knowledge, or else
programmer-convenience. Tim Bunce had some ideas on this once.
I still almost always end up first using no protos and then employing
extensive run-time comparisons, such as this sequence might illustrate:
confess "need args" unless @_;
confess "need even args" unless @_ % 2 == 0;
confess "keys mustn't be refs"
if grep { ref }, @_[map { 2*$_} 0.. int($#_/2)] }
confess "values must be hashrefs"
if grep { reftype($_) ne 'HASH' }, @_[map {1+2*$_} 0.. int($#_/2)] }
confess "values must be Frobulants"
if grep { $_-isa("Frobulant") }, @_[map {1+2*$_} 0.. int($#_/2)] }
I should like to see the context coercer née prototype that satisfies
criteria such as these. Yes, I cannot imagine that Damian doesn't already have
a syntax for such :-) but what about compile-time versus run-time issues?
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
--tom
Re: Beefier prototypes (was Re: Multiple for loop variables)
Tom asked how we'd deal with variadic subroutines without sacrificing
compile-time information (i.e. parameter lists).
Below I've indicated how RFC 128 would handle the cases he lists.
To recap: RFC 128 proposes that parameters may be given a C:repeat
attribute to make them variadic within a specified range of repetitions.
I still almost always end up first using no protos and then employing
extensive run-time comparisons, such as this sequence might illustrate:
confess "need args" unless @_;
sub foo( $arg: repeat{1,} ) {...}
confess "need even args" unless @_ % 2 == 0;
sub foo( %args ) {...}
confess "keys mustn't be refs"
if grep { ref }, @_[map { 2*$_} 0.. int($#_/2)] }
One can't express negative conditions via parameter list.
I suppose that if user-definable attributes were available one
might be able to write:
sub foo( ( $key:notref, $value) : repeat{1,} ) {...}
confess "values must be hashrefs"
if grep { reftype($_) ne 'HASH' }, @_[map {1+2*$_} 0.. int($#_/2)] }
sub foo ( ($key, \%hash) : repeat{1,} ) {...}
# or:
sub foo ( ($key, HASH $hashref) : repeat{1,} ) {...}
confess "values must be Frobulants"
if grep { $_-isa("Frobulant") }, @_[map {1+2*$_} 0.. int($#_/2)] }
sub foo ( (Frobulant $key, $value) : repeat{1,} ) {...}
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
I'm not a prototype person (in fact RFC 128 makes it a hanging offence
to use that confusing word in connection with parameter lists! ;-)
Could someone please recapitulate Tim's issues?
Damian
Re: Beefier prototypes (was Re: Multiple for loop variables)
"BL" == Bart Lateur [EMAIL PROTECTED] writes:
BL I'll give one example.
BL sub min {
BL my $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
On 16 Sep 2000 22:11:25 -0400, Chaim Frenkel wrote:
BLsub min {
BLmy $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
OK. As long as flattening a list is still easily achievable. That is one
of the things that makes Perl really different from most other
languages.
--
Bart.
Re: Beefier prototypes (was Re: Multiple for loop variables)
"DC" == Damian Conway [EMAIL PROTECTED] writes: How would the parser handle this? Some '}' would need ';' some don't. DC The trailing C parameter specification tells the parser that there DC the last argument will be a raw block and that it need not be a followed DC by a semicolon. It's no harder than parsing an Cif, Cwhile, or Cfor, DC except that parser has to update itself when it sees the parameter DC specification. An excersize left for the student, eh? Sounds messy. That next brace could be one of many things. Does the prototype help guide the decision that it is a block and not an anon-hash? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RE: Beefier prototypes (was Re: Multiple for loop variables)
From: Damian Conway [mailto:[EMAIL PROTECTED]]
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need
';' some don't.
The trailing C parameter specification tells the parser that there
the last argument will be a raw block and that it need not be
a followed by a semicolon.
Do you mean Code block instead of raw block?
I am only aware of 3 kinds of blocks in Perl: Loop, Code, and Bare
I'm under the impression that "" used in a function prototype signifies
that the function takes a code block.
I could be wrong. I often am. Am I?
Garrett
Re: Beefier prototypes (was Re: Multiple for loop variables)
On 11 Sep 2000 13:47:22 -0400, Chaim Frenkel wrote:
Sorry, I don't see list flattening as _fundemental_ to perl. It is
just the way it is currently done. Could you tell me how it could be
_fundemental_?
I'll give one example.
sub min {
my $min = shift;
foreach (@_) {
$min = $_ if $_ $min;
}
return $min;
}
$a = min(12, 45, 7);
@b = (12, 45, 7);
$b = min(@b);
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent, that is pretty much the most important
feature of Perl. IMO. Perl would not be Perl without it.
--
Bart.
Re: Beefier prototypes (was Re: Multiple for loop variables)
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
The trailing C parameter specification tells the parser that there
the last argument will be a raw block and that it need not be a followed
by a semicolon. It's no harder than parsing an Cif, Cwhile, or Cfor,
except that parser has to update itself when it sees the parameter
specification.
Damian
Re: Beefier prototypes (was Re: Multiple for loop variables)
"PS" == Peter Scott [EMAIL PROTECTED] writes:
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
PS Yes, please. I view the flattening of lists as a feature, not a bug, and
PS it has made Perl a lot easier to understand IMHO.
I view it as a mis-feature. One is unable to return multiple arrays,
or to pass through multiple arrays without resorting to messy extra
punctuation characters.
It makes it 'necessary' to explode items onto the stack to operate properly.
(Yes, this can be optomized away, but retrofiting iterators and other
handling is probably a mess.)
The special case where the number of loop variables and the number of
supplied lists are equal should be either made explicit or optomized
if zip/merge/whatever is used.
Or
for ($x,$y,$z) ( (@x,@y,@z) )
an extra set of parenthesis could do the flattening. (only one list
is 'visible' as the argument to the for.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"DC" == Damian Conway [EMAIL PROTECTED] writes:
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
Jonathan Scott Duff wrote:
I'm wondering how we get both
for ($x,$y,$z) (@array) { ... }
and
for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it's all the same. At least if Cfor has the proper prototype.
But as for the semantics... how does perl handle this:
for ($x,$y,$z) (@a1,@a2) { ... }
and
for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
Making the case where the number of iterators == the number of arrays
special may not be so good. Not to mention
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
The square bracket syntax is alluring since it implies referenceness,
but it goes the wrong way; squares enreference rather than dereference.
No; you can dereference on the inside, as you propose, or enreference
on the outside, as I propose.
for [ $a, $b, $c ] ( @things ) {
print "They are: $a, $b, $c\n";
}
The idea is to get pass them en bloc to Cfor(), which will then
set them up as iterators appropriately.
--
John Porter
We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
At 02:57 PM 8/29/00 -0400, John Porter wrote:
But as for the semantics... how does perl handle this:
for ($x,$y,$z) (@a1,@a2) { ... }
and
for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
Making the case where the number of iterators == the number of arrays
special may not be so good. Not to mention
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
Yes, please. I view the flattening of lists as a feature, not a bug, and
it has made Perl a lot easier to understand IMHO.
--
Peter Scott
Pacific Systems Design Technologies
Re: Beefier prototypes (was Re: Multiple for loop variables)
Peter Scott wrote: Yes, please. I view the flattening of lists as a feature, not a bug, and it has made Perl a lot easier to understand IMHO. So... is an RFC forthcoming? Or shall I? -- John Porter We're building the house of the future together.
Beefier prototypes (was Re: Multiple for loop variables)
Peter Scott wrote:
for my($x, $y, $z) (@list) { ... }
...
IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
was could say whether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Well, I think it's likely that the perl6 parser would be made to
handle this; but even if not, it shouldn't be too hard to get it
to allow a ref to such a list:
for [ $x, $y, $z ] ( @list ) { ...
for \@iters ( @list ) { ...
Btw, I hope that operators like Cfor will also be properly prototyped
in perl6. I expect that would mean that prototyping will be sufficiently
beefed up; including optional and alternative cases. Hmm, maybe something
regex-like would be needed: sub my(($|\@)?@); Heh.
You know, I would like to pass code blocks in any arg position;
I want sub foo(\@\@) to be callable as
foo { alpha() } @bravo { charlie() } @delta { echo() };
No Csubs, no commas.
--
John Porter
We're building the house of the future together.
