Re: RFC 23 (v5) Higher order functions
> DC> ^1 means $_[1], NOT $_[0] > > [snip. Last message repeated too many times.] > > If you have to do that, that is a good argument to follow the 'natural' > inclination. Not until $_[0] follows the natural inclination. > Again, why insist on an index when it really is closer to an ordinal when > reading the actual code. Because it's NOT an ordinal, it's an index. It's an alias for $_[0]. You're going to have to appeal to Larry, because I simply don't have time to argue this any more. Damian
Re: RFC 23 (v5) Higher order functions
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> Let me ask you:
>>
>> foo('a','b', 'c')
>>
>> Is 'b' the 1st parameter or the 2nd?
DC> This is the classical mistake of confusing indices and ordinals.
DC> The 1st argument is bound to the parameter whose index is [0],
DC> The 2nd argument is bound to the parameter whose index is [1], etc.
But why make it an index? It just reads better as an ordinal.
DC> Assuming they've read L, they'll know that ^1 is $_[1] is
DC> parameter [1] is the 2nd parameter. They'll know because at the very start
DC> of L I will write:
DC> ^1 means $_[1], NOT $_[0]
[snip. Last message repeated too many times.]
If you have to do that, that is a good argument to follow the 'natural'
inclination.
Again, why insist on an index when it really is closer to an ordinal when
reading the actual code.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
> "AG" == Alan Gutierrez <[EMAIL PROTECTED]> writes: AG> Just like the the regex match placeholders, positional placeholders begin AG> with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is AG> probably because you are new to Perl and are not familiar with regular AG> expressions, but we did things this may to make it easier for AG> you to understand (assuming you read the regex chapter of the Camel AG> before the curry chapter.) Just saying that makes my point. ^0 and $0 ^1 and $1 The ordinal concept onto the arguments matches much better. There is already a break between @foo = /(..) (..) ... / and $foo[0] and $1, ..., $foo[n] and $n I and several other folks made our point. We see this more akin in nomenclature and appearance to the regexp matches, then to a invisible offset into an array. All I ask is the Damian add our comments to the RFC. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
On 19 Sep 2000, Chaim Frenkel wrote:
> > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>
> DC> But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just
> DC> Plain Wrong.
>
> Though I see your point. I'm not sure how many would make the connection
> between ^1 and $_[0].
>
> I see ^1 as the _first_ argument not as the zero-th offset. To my eyes
> a positional rather than an offset is more appropriate. It just reads
> better.
>
> Let me ask you:
>
> foo('a','b', 'c')
>
> Is 'b' the 1st parameter or the 2nd?
>
> sub { ^1 + ^2 }
>
> And when a newbie, not one of the oldtimers whose been part of perl6 since
> Damian's RFC came out. Would they think that the second and third arguments
> were added or the first and second?
>
Speaking as a newbie that has not been around since Damian's RCS came out
I conjure an image in my head that looks something like this:
^0 == $_[0]0 == 0
^1 == $_[1]1 == 1
^1 == $_[0]1 == 0 ?
The first two notions make sense to me, the final one does not.
So sub { ^1 + ^2 } returns the sum of the second and third arguments.
Since when does 1 equal 0? What evil force has been unleashed on this world?
Unless you are confusing array indices with the ordinal regex match
variables. This is quite a leap. The currying positional placeholders
would indeed be similar in the sense that they are both a series of
variables that are automagically generated. Currently the regex match
placeholders are the only ones that vary in number and the positional
placeholders will join them and share this magical property.
For the sake of consistency should the positional placeholders begin at ^1? Of
course not. Consistency would be better served by having the curry
params mimic the array indices they symbolize. The
offset-into-an-array-ness of the positional placeholders has more to do
with the essence their being than their
context-dependent-count-of-variables-generated-ness.
As far a perlcurry goes it will be easier to convey the novice that:
Don't confuse the positional placeholders with regex match placeholders.
^1 is not $_[0].
Than it will be to convey that:
Just like the the regex match placeholders, positional placeholders begin
with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is
probably because you are new to Perl and are not familiar with regular
expressions, but we did things this may to make it easier for
you to understand (assuming you read the regex chapter of the Camel
before the curry chapter.)
Alan Gutierrez
Re: RFC 23 (v5) Higher order functions
> Let me ask you:
>
>foo('a','b', 'c')
>
> Is 'b' the 1st parameter or the 2nd?
This is the classical mistake of confusing indices and ordinals.
The 1st argument is bound to the parameter whose index is [0],
The 2nd argument is bound to the parameter whose index is [1], etc.
So, yes, 'b' is obviously the second argument when we're speaking
in ordinal. But it is accessed as $_[1] (or ^1) when we're writing Perl.
> And when a newbie, not one of the oldtimers whose been part of
> perl6 since Damian's RFC came out. Would they think that the second
> and third arguments were added or the first and second?
Assuming they've read L, they'll know that ^1 is $_[1] is
parameter [1] is the 2nd parameter. They'll know because at the very start
of L I will write:
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
^1 means $_[1], NOT $_[0]
:-)
Damian
Re: RFC 23 (v5) Higher order functions
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just
DC> Plain Wrong.
Though I see your point. I'm not sure how many would make the connection
between ^1 and $_[0].
I see ^1 as the _first_ argument not as the zero-th offset. To my eyes
a positional rather than an offset is more appropriate. It just reads
better.
Let me ask you:
foo('a','b', 'c')
Is 'b' the 1st parameter or the 2nd?
sub { ^1 + ^2 }
And when a newbie, not one of the oldtimers whose been part of perl6 since
Damian's RFC came out. Would they think that the second and third arguments
were added or the first and second?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
Damian Conway wrote: > > That's it! I'm gonna take that whole section out and burn it! ;-) > $1 is the *only* place in Perl where an index starts at 1. *It's* the one > that's inconsistent. Fix *it*. I'd love to. But we're stuck, unless we make a $CMD which holds what $0 currently holds, which I wouldn't particularly mind. Particularly since $ARGV[0] means the first command-line argument, and not C's argv[0], and neither of them are related to $0 at all typing-wise. But then again, $0 has nice sh semantics. But then again, @ARGV doesn't, so it's kinda contradictory. Sigh. "Let Larry figure it out" comes to mind. > In large measure because it has been destruction-tested by so many > clever and committed people such as yourself. :-) Thanks. :-) -Nate
Re: RFC 23 (v5) Higher order functions
Nathan Wiger wrote: > > Either we need to change $1 to $0, or change ^0 to ^1. Considering $0 > has been around a little while longer than HOFN, I strongly suggest we > change ^0 to ^1 to be consistent. > > I realize this RFC has been frozen, but this is an important issue. And > remember, Mike Pastore and I were the ones who suggested this whole ^ > notation, y'know. ;-) *chuckle* I dunno. If $0 isn't being used for anything currently, maybe we should switch 'em the other way around. IIRC, this is the only place in p5 where an index doesn't start at uno. That doesn't make ANY sense! > Other than this issue the RFC is excellent^Wamazing. Here, here. As usual, Damian. :) -- Mike Pastore )#!Perl Monk [EMAIL PROTECTED] ) bilogic.org Sys Admin
Re: RFC 23 (v5) Higher order functions
> > =head2 Choice of notation > > > > The placeholder notation has been chosen to be consistent with the > > eisting Perl scalar notation (but using a ^ prefix rather than a $): > > > > RoleScalar Placeholder > > var analog > > > > named $x, $y^x, ^y > > positional$0, $1, $2^0, ^1, ^2 > > default $_^_ > > As I voiced before, this is incorrect. $0 is not a positional scalar. That's it! I'm gonna take that whole section out and burn it! But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just Plain Wrong. > Either we need to change $1 to $0, or change ^0 to ^1. Considering $0 > has been around a little while longer than HOFN, I strongly suggest we > change ^0 to ^1 to be consistent. $1 is the *only* place in Perl where an index starts at 1. *It's* the one that's inconsistent. Fix *it*. > I realize this RFC has been frozen, but this is an important issue. And > remember, Mike Pastore and I were the ones who suggested this whole ^ > notation, y'know. ;-) A fact I gratefully acknowledge. Doesn't make you correct, though! ;-) > Other than this issue the RFC is excellent^Wamazing. In large measure because it has been destruction-tested by so many clever and committed people such as yourself. :-) Damian
Re: RFC 23 (v5) Higher order functions
> =head2 Choice of notation > > The placeholder notation has been chosen to be consistent with the > eisting Perl scalar notation (but using a ^ prefix rather than a $): > > RoleScalar Placeholder > var analog > > named $x, $y^x, ^y > positional$0, $1, $2^0, ^1, ^2 > default $_^_ As I voiced before, this is incorrect. $0 is not a positional scalar. $1 is the first positional scalar. Either we need to change $1 to $0, or change ^0 to ^1. Considering $0 has been around a little while longer than HOFN, I strongly suggest we change ^0 to ^1 to be consistent. I realize this RFC has been frozen, but this is an important issue. And remember, Mike Pastore and I were the ones who suggested this whole ^ notation, y'know. ;-) Other than this issue the RFC is excellent^Wamazing. -Nate
RFC 23 (v5) Higher order functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Number: 23
Version: 5
Mailing List: [EMAIL PROTECTED]
Status: Frozen
=head1 ABSTRACT
This RFC proposes some syntactic sugar to simplify the creation of
higher-order functions (a.k.a. "currying").
=head1 DESCRIPTION
One situation in which the proposed Perl C statement does not
provide a good substitute for a cascaded C, is where a switch value
needs to be tested against a series of conditions. For example:
sub beverage {
switch (shift) {
case sub{ $_[0] < 10 } { return 'milk' }
case sub{ $_[0] < 20 } { return 'coke' }
case sub{ $_[0] < 30 } { return 'beer' }
case sub{ $_[0] < 40 } { return 'wine' }
case sub{ $_[0] < 50 } { return 'malt' }
case sub{ $_[0] < 60 } { return 'Moet' }
else{ return 'milk' }
}
}
The need to specify each condition as an anonymous subroutine is tiresome.
Each of these small subroutines is really a "higher order" function, which
exists merely to bind the second operand of the
C> operator.
=head2 The anonymous placeholder
It is proposed that Perl reserve the bareword C<^_> (caret-underscore) as
a "placeholder" for generating higher order functions more cleanly.
That is, any expression containing C<^_> anywhere that a value might
appear, will be converted to "deferred expression": a reference to a
subroutine in which the placeholders are replaced by the appropriate
number and sequence of scalar arguments.
That is, the expression:
$check = ^_ == ^_**2 *^_ or die ^_;
is equivalent to:
$check = sub (;) {
$_[0] == $_[1]**2 *$_[2] or die $_[3]
};
This could then be invoked:
$check->(@args);
It would also be possible to interpolate an argument list into a static
expression like so:
(^_ == ^_**2 *^_ or die ^_)->(@args);
=head2 Named placeholders
Those not currently studying or using geometry might not be too sure what
they're dealing with when they see:
$check = ^_ == ^_**2 *^_ or die ^_;
in a program. However, the following is self-documenting:
$check = ^cylinder_vol == ^radius**2 * ^height
or die ^last_words;
This uses the I notation. If two placeholders use the
same identifier, they refer to the same argument. Therefore, the following
is equivalent to the previous line:
$check = ^cylinder_vol == ^radius*^radius * ^height
or die ^last_words;
=head2 Positional placeholders
The order in which the arguments appear in a function may not be
convenient:
# getMeasurements returns ($height, $radius)
@measurements = getMeasurementsFromSomeplace();
$check->($volume, reverse(@measurements), 'Invalid measurements');
A convenient way around this is using I:
$check = ^2 == ^0**2 * ^1 or die ^3;
@measurements = getMeasurementsFromSomeplace();
$check->(@measurements, $volume, 'Invalid measurements');
The numbers after the C<^> prefix correspond directly to the indices
of the correpsonding elements of @_.
Positional placeholders can be used to re-order named placeholders too:
$check = ^cylinder_vol == ^radius**2 * ^height
or die ^last_words;
$check2 = $check->(^2, ^0, ^1, ^3);
=head2 Choice of notation
The placeholder notation has been chosen to be consistent with the
eisting Perl scalar notation (but using a ^ prefix rather than a $):
RoleScalar Placeholder
var analog
named $x, $y^x, ^y
positional$0, $1, $2^0, ^1, ^2
default $_^_
=head2 Combining placeholder types
Although not necessarily a good idea, these can be mixed in a single
higher-order function:
$icky_func = ^test ? ^1 * ^_ : ^2 * ^_;
First the positional placeholders are filled in (a higher numbered
positional placeholder than the number of parameters results in a
compile-time error). The anonymous and named placeholders fill in the
missing places in the order in which they appear, from left to right.
However, for the good of international mental health, users should be
encouraged to consider using a consistent approach within a single
higher-order function definition.
=head2 Examples:
With C<^_>, the previous ugly case statements can be rewritten:
sub beverage {
switch (shift) {
case ^_ < 10 { return 'milk' }
case ^_ < 20 { return 'coke' }
case ^_ < 30 { return 'beer' }
