> > > As for the regexp issue, just to clarify there's only one ambiguous
case
> > > we need to work out that I can see:
> > >
> > >/.*^foo/; # ok
> >
> >But: /.*^foo/m; #ambiguous
>
> Hold it. What does this mean? Is the whole regex gonna be turned into an
> anonymous sub, or what?
On Tue, 8 Aug 2000 13:30:22 +1000 (EST), Damian Conway wrote:
> > As for the regexp issue, just to clarify there's only one ambiguous case
> > we need to work out that I can see:
> >
> >/.*^foo/; # ok
>
>But: /.*^foo/m; #ambiguous
Hold it. What does this mean? Is the whole rege
> I'd agree to the contrapositive: if we have named placeholders, I don't see the
> need for positional ones too. But I'm willing to be convinced. The below, with
> positional only, is total gibberish, as Ken points out.
To most, probably, but I say let the user decide. Like Jeremy points
out:
Jeremy Howard wrote:
> Damian Conway wrote:
> > Personally, if we have positional placeholders I don't see the need
> > for named ones too. But I'm willing to be convinced.
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm will
Damian Conway wrote:
>> And there's no argument about having anonymous, positional, and named
>> placeholders in the redraft...?
>
> There's *always* arguments! ;-)
>
Although arguments from the RFC author are generally more compelling ;-)
> Personally, if we have positional placeholders
> And there's no argument about having anonymous, positional, and named
> placeholders in the redraft...?
There's *always* arguments! ;-)
Personally, if we have positional placeholders I don't see the need
for named ones too. But I'm willing to be convinced.
Damian
>> We could undo the ambiguity like so:
>>
>>/^{foo}/; # like ${foo} and @{foo} and %{foo}
>>
>> In fact, this seems built-in if we follow the same var conventions.
We
>> can make ^ bind to {} as tightly as we need.
>
> That would be the right solution. And of course
> As for the regexp issue, just to clarify there's only one ambiguous case
> we need to work out that I can see:
>
>/.*^foo/; # ok
But:/.*^foo/m; #ambiguous
> We could undo the ambiguity like so:
>
>/^{foo}/; # like ${foo} and @{foo} and %{foo}
>
>
> So is this a consensus?:
>
> It is proposed that Perl introduce a new prefix '^', which indicates a
> placeholder. This can be used in any of the following ways:
> - ^identifier: named placeholder
> - ^_: anonymous placeholder
> - ^0, ^1, ...: positional placeholder.
I think this sounds go
It shouldn't be a problem. *_ would then be a 'special' reserverd identifier.
*_name could be a named placeholder.
> "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes:
JH> John Porter wrote:
>> Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
>> going away, it's avail
At 08:19 AM 8/8/00 +1000, Jeremy Howard wrote:
>John Porter wrote:
> > Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
> > going away, it's available (right?).
> >
> > It the "wildcard" mnemonic value is consistent with "placeholder".
> >
>Yes, it's been suggested, but we mi
John Porter wrote:
> Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
> going away, it's available (right?).
>
> It the "wildcard" mnemonic value is consistent with "placeholder".
>
Yes, it's been suggested, but we might be too late on that one--another RFC
suggests reserving
Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
going away, it's available (right?).
It the "wildcard" mnemonic value is consistent with "placeholder".
--
John Porter
Nathan Wiger wrote:
>
> Yeah, I personally can read this much clearer. Peter also mentions that
> __ is hard to distinguish from _, unless they're right next to each
> other, and I think this is a very valid point.
This biggest problem with '__', imho, is that '_' is a valid identifier
character
Jeremy Howard wrote:
> Yes, I change my mind . I like the '^' prefix
> too. The difficulty of reading __ would be a pain.
But what happens here?
/^__foo/
Or here?
/^{__}foo/
Is the latter sufficiently unambiguous?
--
John Porter
Ken Fox wrote:
>
> I think we need a curry context and that all curries must be surrounded
> by parens.
> .
> sub traverse ($_);
> my $sum = 0;
> $root->traverse(($sum += __));
I think parens may be problematic, since nested lists flatten.
Maybe curlies could be overloaded yet again?
On Mon, Aug 07, 2000 at 02:53:17PM +0200, Bart Lateur wrote:
> On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:
>
> >I
> >think the concept's great, just that the notation is really hard to
> >read, and doesn't necessarily scream "function" to me (especially since
> >_ is from stat already
On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote:
>Seems to me that a leading _ is worse for this than ^
Whatever prefix you choose, it should NEVER EVER be a \w character.
And the general rule, until now at least, is that only characters from
the ASCII repertoire are acceptable for proga
On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:
>I
>think the concept's great, just that the notation is really hard to
>read, and doesn't necessarily scream "function" to me (especially since
>_ is from stat already).
I don't see why you can't simply use _. From the context, you clearly
Ken Fox wrote:
> Jeremy Howard wrote:
> > Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> > allow named placeholders too. Although I don't see what this buys you.
>
> Argument ordering. We might be constrained by the caller as to what order
> the placeholders are passed
Ken Fox wrote:
>
> my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale;
>
> has to be called
>
> &$f($x, $max, $scale, $y)
Hmm, perhaps we can use those named placeholders when calling the
function by a hash. And instead of generating a complete new code
reference, we can simply "build up" our
Jeremy Howard wrote:
> Anyhoo, there's no reason why you can't have ^1, ^2, and so forth, _and_
> allow named placeholders too. Although I don't see what this buys you.
Argument ordering. We might be constrained by the caller as to what order
the placeholders are passed in. Also, we want to make
> > There's two potential solutions here:
> > 1- Use '_'
> > 2- Use '^', but increase the strictness of sub calls
>
> > The second suggestion specifically relies on us deciding that barewords are
> > always evil, so that :
> > $a = foo; # Error! Evil bareword! Return to firey depths of hell!
> There's two potential solutions here:
> 1- Use '_'
> 2- Use '^', but increase the strictness of sub calls
>
> I'd be happy with both. I'm with Damian that '__' looks cool, but I
> understand that people typing in perl from a magazine (do people still do
> that?) might get confused (mmm... comfy
Ken Fox wrote:
> Actually I was wrong about ^ not working. The binary operator ^ is XOR.
> The unary "operator" ^ could be for curries.
>
Right. I though you were just worried about it looking confusing. I don't
think the parser will be bothered (at least, I can't think of anything
ambiguous so fa
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main reason why. Also, '&' already has a perfectly good
> meaning: binary AND with the function foo(). :) Not trying to be a
> smartass, but I think you understand what I'm trying to say.
Yes. '&' is misleadi
Mike Pastore wrote:
> Ken Fox wrote:
> > > Although, I suppose '&' would not work.
> >
> > Why not? I think it would work great.
>
> Well, what's the different between the placeholder &foo and the sub
> &foo? That's the main reason why. Also, '&' already has a perfectly good
> meaning: binary AND
> $zot **= ^foo# "what's that binary op doing there..
> # ..oh, that's a placeholder"
I think this is a valid way of looking at it. If you think about it, *
for typeglobs is the same symbol as * for multiplication. But the parser
can figure it out based on context. I don't se
I concur with Mike. If we *have* to have a prefix (and I *still* prefer
a naked __, gumble, grumble, pout), then I'd certainly rather ^ that &.
What we *really* need are some more types of brackets:
$range = Ç__È < ÇvalÈ && ÇvalÈ < Ç__È;
;-)
Damian
Ken Fox wrote:
>
> > - ^foo is the placeholder 'foo'
>
> That already has perfectly good meaning: XOR with the function foo().
Good point. Back to the drawing board?
> > Although, I suppose '&' would not work.
>
> Why not? I think it would work great.
Well, what's the different between the p
> > New programmers should easily understand
>
> New? You're talking about "new" "easy" and "higher order functions"
> in the same sentence? ;)
>
This was intentional. (Err, yes, it was bait, basically...)
Higher order functions are harder for old [procedural] programmers than new
ones (IMHO). Ha
[Sorry, spent too much time thinking in the editor and did not
see this before my reply.]
Mike Pastore wrote:
> - ^foo is the placeholder 'foo'
That already has perfectly good meaning: XOR with the function foo().
> Although, I suppose '&' would not work.
Why not? I think it would work great.
Jeremy Howard wrote:
> It is proposed that Perl introduce a new prefix '_', which indicates a
> placeholder. This can be used either as '_identifier', which creates a named
> placeholder, or '__', which creates an anonymous placeholder.
This is a good idea, but it has a good chance of tripping up
Nathan Wiger wrote:
>
> I think the principle of a "general purpose placeholder" is a good one.
> But I think _ is already used so much in Perl that something else is
> better. I like ^ since is looks like a carat ("insert your variable
> here"), personally.
Or even a thumbtack, holding the vari
Okay. I'll rework the proposal with the consensus syntax.
Damian
> But the expression
>
> __ < 2 + __ * sin(__ / 2) or die __
>
> curries to
>
> sub { $_[0] < 2 + $_[1] * sin(sub { $_[0] / 2 }) or die $_[2] }
>
> That's very odd.
No. You got it exactly right. :-)
> I really hope I'm missing something, but __ the way yo
> > Just as simply,
> >
> > - $foo is the variable 'foo'
> > - ^foo is the placeholder 'foo'
> > - $_ is the default variable
> > - ^_ is the default placeholder
>
> Yeah, I personally can read this much clearer. Peter also mentions that
> __ is hard to distinguish from _, unless they're right nex
Damian Conway wrote:
> That should of course have been:
>
> __ < 2 + __ * atan2($pi, __) or die __
Oh, yes, of course. Um, wait. Nope, I still don't follow. The
expression above curries to:
sub { $_[0] < 2 + $_[1] * atan2($pi, $_[2]) or die $_[3] }
But the expression
__ < 2 + __ * sin(__
> Just as simply,
>
> - $foo is the variable 'foo'
> - ^foo is the placeholder 'foo'
> - $_ is the default variable
> - ^_ is the default placeholder
Yeah, I personally can read this much clearer. Peter also mentions that
__ is hard to distinguish from _, unless they're right next to each
other,
Jeremy Howard wrote:
>
> New programmers should easily understand that:
> - $foo is the variable 'foo'
> - _foo is the placeholder 'foo'
> - $_ is the default variable
> - __ is the default placeholder.
> Then, when they see the same named placeholder appear twice in the same
> higher-ord
At 05:35 PM 8/6/00 -0700, Nathan Wiger wrote:
>Can I make one observation? Maybe I'm the only one.
>
>I find the __ *really* hard to follow. I've been trying to keep up with
>this discussion, but it's really chewing me up.
>
>Since this is really something different (not a scalar, hash, etc), has
> I find the __ *really* hard to follow. I've been trying to keep up with
> this discussion, but it's really chewing me up.
>
> Since this is really something different (not a scalar, hash, etc), has
> any consideration been given to other variable names:
>
>^_
>&_ # kinda like this
> The error was not here but in:
>
>__ < 2 + __ * atan($pi/__) or die __
>
> That should of course have been:
>
>__ < 2 + __ * atan2($pi, __) or die __
Can I make one observation? Maybe I'm the only one.
I find the __ *really* hard to follow. I've been trying to keep up with
this disc
> > $root->traverse( $sum += __ );
>
> There's a syntactic ambiguity here. I assumed that __ "poisons" an
> expression so that an entire parse tree gets transformed into a
> closure. If you isolate the parse tree based on expression precedence,
> then I'm not sure wh
Jeremy Howard wrote:
> New programmers should easily understand that:
> - $foo is the variable 'foo'
> - _foo is the placeholder 'foo'
> - $_ is the default variable
> - __ is the default placeholder.
> Then, when they see the same named placeholder appear twice in the same
> higher-order
> It is proposed that Perl reserve the bareword C<__>
(underscore-underscore)
> as a "placeholder" for generating higher order functions more cleanly.
>
But what if I want to say:
@n = (0.2, 1, 3.5, 4);
@integersInN = grep __=abs(__) @n; # @intsInN is empty!
Instead I would need:
@integersI
Ken Fox wrote:
> And neither did you... ;) The last line should be:
> > : $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
>
> That's why curried functions should automatically re-curry themselves
> instead of depending upon lazy programmers. ;)
>
But of course I only included thi
> Unless I'm missing something here, you're not filling in the args correctly.
> I think you mean:
>
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2
Thanks for the useful insights and pointers, Ken.
Top stuff (as usual :-)
I particularly liked the currying context and notions of explicitly
marking curries. Obviously I'll need to de-jetlag a little more and run
my brain over it again.
However, implicit currying is so damn handy that I suspect
Jeremy Howard wrote:
> Unless I'm missing something here, you're not filling in the args correctly.
> I think you mean:
>
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2
> $check = sub (;) {
> @_==0 ? __ < 2 + __ * atan($pi/__) or die __
> : @_==1 ? $_[0] < 2 + __ * atan($pi/__) or die __
> : @_==2 ? $_[0] < 2 + $_[1] * atan($pi/__) or die __
> : @_==3 ? $_[0] < 2 + $_[1] * atan($pi/$_[1]) or die __
> : $_
[Could we get the librarian to cc: the RFC owner and hide
replies from the announcement list?]
Perl6 RFC Librarian wrote:
> That is, the expression:
>
> $check = __ < 2 + __ * atan($pi/__) or die __;
>
> is equivalent to:
>
> $check = sub (;) {
> $_[0] < 2
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 August 2000
Version: 1.00
Mailing List: [EMAIL PROTECTED]
Number: 23
=head1 ABSTRACT
This RFC proposes some syntactic sugar to simplify the creation
of higher-order functions (a
53 matches
Mail list logo
