Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> > > 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?
>
> I find this whole "higher order function" thing nothing but butt ugly.
> Perl already has anonymous subs, which look far less confusing. If you
> want shorter syntax for "sub { ... }" and for $_[1] etc, I can
> understand that. But please please please do not make this thing look
> like an ordinary expression, when it is anything but!
>
First of all, it won't look like an ordinary expression. Damian and I have
just finished off v2 of this RFC, which should be in your inbox RSN.
Hopefully you'll agree that the suggestions made there never create a higher
order function when there's ambiguity (you have to use braces to
disambiguate).
Secondly, it's not just shorter syntax for sub{} and $_[1] etc:
$check = ^_ < 2 + ^_ * atan($pi/^_) or die ^_;
is actually equivalent to:
$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/$_[2]) or die ^_
: $_[0] < 2 + $_[1] * atan($pi/$_[2]) or die $_[3]
;
};
to allow for re-currying of deferred expressions.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 regex gonna be turned into an
anonymous sub, or what?
I find this whole "higher order function" thing nothing but butt ugly.
Perl already has anonymous subs, which look far less confusing. If you
want shorter syntax for "sub { ... }" and for $_[1] etc, I can
understand that. But please please please do not make this thing look
like an ordinary expression, when it is anything but!
Obfuscation at its worst.
--
Bart.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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: There's a nice parallel with '$' as used for: - $identifier: named variable - $_: anonymous/default variable - $digit ...: positional variable from last exp With ^ used in the same way, we're giving them the same power with higher-order functions. TMTOWTDI! :-) -Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 willing to be convinced. The below, with positional only, is total gibberish, as Ken points out. > Well I thought Ken Fox's earlier example was a good one: > > > my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale; > > > > has to be called > > > > &$f($x, $max, $scale, $y) > > <...> > > Seems better to just write $f as: > > > > my $f = (^2 < ^1) ? ^2 * ^0 : ^3 * ^0; > > > > Alright, yeah, maybe not. That's total gibberish isn't it. ;) -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 I don't see the need > for named ones too. But I'm willing to be convinced. Well I thought Ken Fox's earlier example was a good one: > my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale; > > has to be called > > &$f($x, $max, $scale, $y) > <...> > Seems better to just write $f as: > > my $f = (^2 < ^1) ? ^2 * ^0 : ^3 * ^0; > > Alright, yeah, maybe not. That's total gibberish isn't it. ;) So how > about taking the *original* $f and rebinding the order of all the > arguments: > > my $f = &$f(^2, ^0, ^1, ^3); And the two live together quite nicely, as I described earlier (sorry Damian, I don't think I cc'd you on the original): <...> - ^identifier: named placeholder - ^_: anonymous placeholder - ^0, ^1, ...: positional placeholder. Although not necessarily a good idea, these can be mixed in a single higher-order function: $icky_func = ^test ? ^2 * ^_ : ^3 * ^_; 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. Penultimately, I think it fits better with what the user expects. There's a nice parallel with '$' as used for: - $identifier: named variable - $_: anonymous/default variable - $digit ...: positional variable from last regexp Finally, when we have named arguments to functions (which I know you're working on, creating higher order functions will look very much like creating normal functions. So, are you convinced yet?
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
>> 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 one could use the {}
anywhere
> necessary or desirable:
>
> my $sin_deg = sin(180*^{_}/$pi);
>
This is looking quite perlish now, isn't it? And this example shows why '*'
can get a bit nasty:
my $sin_deg = sin(180**{_}/$pi); # Pardon?
Of course the same is true for ^:
my $reverse_test = SOME_FLAGS ^ ^_;
but at least ^^ isn't an operator like ** is. Also, you don't see binary '^'
all that often.
Compared to the downside of '_' (__ is hard to read on paper, _identifier
looks like a private method call), the downside of '^' (potential confusion
because '^' is also a binary operator) seems pretty small. As for '*', well
personally I hate it:
- '*' means something else in perl 5
(confusing C programmers is one thing,
confusing perl 5 programmers is another!)
- '* *{_}' will be a common construct, and is very confusing.
So what if Damian's redraft uses '^', but mentions '_' as a fallback option?
And there's no argument about having anonymous, positional, and named
placeholders in the redraft...?
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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}
>
> 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 one could use the {} anywhere
necessary or desirable:
my $sin_deg = sin(180*^{_}/$pi);
Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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 good - great, actually. It's really flexible.
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
/^^foo/;# ok
/^foo/; # ambiguous
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.
-Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 available (right?). >> >> It the "wildcard" mnemonic value is consistent with "placeholder". >> JH> Yes, it's been suggested, but we might be too late on that one--another RFC JH> suggests reserving '*' for reserved perl identifiers. JH> - *: Next best, if not used to signify perl reserved identifiers -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 might be too late on that one--another RFC >suggests reserving '*' for reserved perl identifiers. Lord no - there's nothing wrong with contradictory RFCs. These are just ideas, we're not making the decisions here. -- Peter Scott Pacific Systems Design Technologies
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 '*' for reserved perl identifiers. Maybe we don't have to resolve this in the RFC--since the choice of prefix depends on a number of other design decisions. Could we use one consistant prefix in the examples, and point out in the implementation that other prefixes are possible. eg: - ^: Our preferred option, but need to ensure that ambiguity in regexps is avoided - *: Next best, if not used to signify perl reserved identifiers - _: Next best option Is the regexp issue the only problem for '^'? If so, isn't this an issue for any prefix? Presumably the placeholder identifier should be 'special' under the same conditions as '$', when in a regexp...
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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. '__' is already a valid package name, or sub name, for examples. -- John Porter
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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). > > I don't see why you can't simply use _. From the context, you clearly > see that it's not a filehandle. And if all filehandles will have a '$' > prefix anyway, the filehandle _ won't even exist any more. Except that we still have positional and/or named parameters. I guess _, _1, _2, _foo, _bar could still work though. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 progamming language syntax. (I merely have reservations WRT variable names, using accented characters or something.) -- Bart.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 see that it's not a filehandle. And if all filehandles will have a '$' prefix anyway, the filehandle _ won't even exist any more. -- Bart.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 in. Also, we want to make partial application, > i.e. recurrying, as useful/simple as possible. So it's important to > have the argument order independent of where the placeholders appear > in the expression. > True. That is important. > my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale; > > has to be called > > &$f($x, $max, $scale, $y) > <...> > Seems better to just write $f as: > > my $f = (^2 < ^1) ? ^2 * ^0 : ^3 * ^0; > > Alright, yeah, maybe not. That's total gibberish isn't it. ;) So how > about taking the *original* $f and rebinding the order of all the > arguments: > > my $f = &$f(^2, ^0, ^1, ^3); > Nice. > Anyways, ^_ has my vote. 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. Although not necessarily a good idea, these can be mixed in a single higher-order function: $icky_func = ^test ? ^2 * ^_ : ^3 * ^_; 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, you may want to consider using a consistent approach within a single higher-order function definition. > (Although I really have a soft spot for that > Oracle SQL*Plus variable syntax... ;) Please, there are children present...
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 function:
$f->(max=>$foo::maxval, scale=>$foo::rscale);
Leaving ^x and ^y unallocated, as per the original RFC23 (kinda). If the
placeholders are made flexible enough, we could have some fun:
$a = $f->@{x, y} = (40, 50); # set x and y by hash slice (syntax?)
$b = $f->(0, 100); # fill the remaining placeholders
$c = $f->(y=>-60, x=>-10); # the good ol' indeliable way
The question is, would all these different options work on coderefs? If
yes, that's one heck of an automagically generated subroutine
(especially for the hash slice example).
Also, how does the generated function ($f) know when to return it's
value or yet another coderef?
And can it be ab^H^Hused multiple times, as per the above, to generate
multiple values? (ala DBI::prepare once and sth->execute many)
Should we provide both methods of calling the function?
A) generating a new code ref by calling the original function in
scalar context (ie, $g = &$f('dog', 'cat')), and
B) "building up" a function by calling it in void context (ie,
$f->('dog'))
This smacks of closure and other anonymous-subroutine related issues.
Maybe I'm drifting off topic. Maybe I'm covering ground that's been trod
before. In any case, I'd like to hear what you guys think about this.
Especially Damian, because he's the poor sap writing the RFC. :-P
--
Mike Pastore
[EMAIL PROTECTED]
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 partial application, i.e. recurrying, as useful/simple as possible. So it's important to have the argument order independent of where the placeholders appear in the expression. my $f = (^x < ^max) ? ^x * ^scale : ^y * ^scale; has to be called &$f($x, $max, $scale, $y) First off this might not be the order the caller expects them in and we're sunk. Also, that's a pain to re-curry if we know $max and $scale but want $x and $y free: my $g = &$f(^_, 10, 2, ^_); Seems better to just write $f as: my $f = (^2 < ^1) ? ^2 * ^0 : ^3 * ^0; Alright, yeah, maybe not. That's total gibberish isn't it. ;) So how about taking the *original* $f and rebinding the order of all the arguments: my $f = &$f(^2, ^0, ^1, ^3); And the $g becomes: my $g = &$f(10, 2); Anyways, ^_ has my vote. (Although I really have a soft spot for that Oracle SQL*Plus variable syntax... ;) - Ken
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> > 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! Seems to me that a leading _ is worse for this than ^: $a = _foo; # definitely sub call I write subs all the time with a leading _ to denote they're "private". Main difference is _ is a valid sub/var/etc character. ^ is not. -Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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 fence I'm sitting on here...) and > that '_identifier' is a well understood C idiom meaning something completely > different. I think these are both really important concerns. Remember, we're covering massively new waters with Perl 6, even just with higher-order functions. There's going to be *lots* of articles and courses on this. And we don't want people to accidentally type _ instead of __ or get confused with C _identifiers. Frustrations like this lead people to give up rather than discover how cool this stuff really is! :-) > 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! Naw, I like this. Let's not abandon it. I don't see how using ^ would require this? -Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 far). > I still like &? and &0, &1, ... best though. The common form &? is not > likely to be accidentally typed either. BTW, the number represents the > order of the argument in the function -- the arguments don't have to be > in the order they appear in the expression. The major failure of this > syntax is it doesn't allow named placeholders, only numbered. I think > being able to control the order of the arguments is more important than > naming them. If the function is so big you forget what &1 and &2 > mean, then I think the curry needs a helper function. > Ugh. I think '&' is asking for trouble, whether it's named, numbered, or anonymous. I still get confused the way '&' in C++ is both the address-of operator and the notation for reference parameters. They're similar but completely different, and that's plain confusing. Having '&' in perl as the subroutine prefix and the placeholder prefix would also be confusing, if you ask me (or even if you don't!) And most importantly, having parameters that share syntax with Oracle SQL is just plain demeaning ;-) 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. But I still think the default/anonymous placeholder wants to be ^_, for consistancy with $_.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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 misleading. > > I think if we have $var OP ^plh (eg $foo + ^bar) coders will know what > that means, simply because you can't have a binary operation without a > left-side, and you can't have two operators in a row (typically). IE: > > $foo ^ $bar # obvious binary op > atan2($pi, ^zot) # obvious placeholder (shamlessly ripped) > $foo + ^ $bar# invalid!! (two ops in a row) > $bar = ^ $zot# invalid!! (no left-side) > $zot **= ^foo# "what's that binary op doing there.. > # ..oh, that's a placeholder" > Good examples, thanks. 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 fence I'm sitting on here...) and that '_identifier' is a well understood C idiom meaning something completely different. 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! becomes: $a = &foo; # Ah yes, a subroutine call! or: $a = foo(); # Ah yes, another subroutine call! which mean the same thing in perl 5.6, unless foo() is a constant sub in which case one is inlined while the other isn't (but now I'm getting pedantic...). And of course: $a = ^foo * sin(^foo); # Couldn't be anything but a placeholder.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 with the function foo(). :) Not trying to be a > smartass, but I think you understand what I'm trying to say. Ha ha. ;P Actually I was wrong about ^ not working. The binary operator ^ is XOR. The unary "operator" ^ could be for curries. I still like &? and &0, &1, ... best though. The common form &? is not likely to be accidentally typed either. BTW, the number represents the order of the argument in the function -- the arguments don't have to be in the order they appear in the expression. The major failure of this syntax is it doesn't allow named placeholders, only numbered. I think being able to control the order of the arguments is more important than naming them. If the function is so big you forget what &1 and &2 mean, then I think the curry needs a helper function. I like ^ better than Damian's original though. (And we could add ^0, ^1, etc. to the proposal.) - Ken
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> $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 see any reason why it wouldn't be able to do the same for ^. -Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 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. I think if we have $var OP ^plh (eg $foo + ^bar) coders will know what that means, simply because you can't have a binary operation without a left-side, and you can't have two operators in a row (typically). IE: $foo ^ $bar # obvious binary op atan2($pi, ^zot) # obvious placeholder (shamlessly ripped) $foo + ^ $bar# invalid!! (two ops in a row) $bar = ^ $zot# invalid!! (no left-side) $zot **= ^foo# "what's that binary op doing there.. # ..oh, that's a placeholder" By the same token '&' would work too, but then we run into the placeholder vs. explicit subroutine issue. I hope this clarifies things (if nothing else, the fact that *I* am confused :) Mike
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> > 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). Have a look at 'Algorithms--A Functional Programming Approach' for instance: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201596040 I think that when algorithms are described in this way, it's much more intuitive than when they are described as the sequence of steps that a turing machine has to take to implement them. Hmmm... maybe we shouldn't go there. The phrase "hornet's nest" comes to mind...
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
[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. - Ken
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 people that come from C++ where _foo is often used to differentiate object attributes from methods. C programs often do similar things even though the standard reserves underscore symbols for compiler use. (Or is it double underscore?) The benefit to __ is that it looks weird. People that don't know what __ is might think to look it up before changing the code around. What if we used &? instead of __. It uses & so people suspect that it's related to functions. It uses ? which is obviously mnemonic for "what in the world does this do?" The "named" placeholders could use &0, &1, &2, etc. Not as good as naming, but if you have a curried function taking more than a few arguments, well, all I can say is that I hope all the code you maintain was written by ex-Fortran programmers enamored with goto. > New programmers should easily understand New? You're talking about "new" "easy" and "higher order functions" in the same sentence? ;) - Ken
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 variable down to be filled in at a
later time. Mnemonics galore!
My goodness, what have we done. :)
Henceforth being seen and not heard (at least for a bit),
Mike Pastore
[EMAIL PROTECTED]
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
Okay. I'll rework the proposal with the consensus syntax. Damian
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> > 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, and I think this is a very valid point.
>
> 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.
>
Yes, I change my mind . I like the '^' prefix
too. The difficulty of reading __ would be a pain.
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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, and I think this is a very valid point.
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.
I would avoid *, though, since typeglobs might not go away, and even if
they do it will be quite a shock is *intendedglob works like
*placeholder in 6 vs. 5 (sure, RTFM, but still...).
-Nate
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 function, they know that each is referring to the same thing. > > Your suggested changes to notation don't allow for named placeholders. > Besides, '__' is clearly a blank spot, and therefore a place waiting to be > filled in (a placeholder, in fact!). Just as simply, - $foo is the variable 'foo' - ^foo is the placeholder 'foo' - $_ is the default variable - ^_ is the default placeholder Or any variation, given Nathan Wiger's original list (! ^ &) and others. Although, I suppose '&' would not work. I too am having trouble following the current placeholder syntax. :) Regards, Mike Pastore [EMAIL PROTECTED]
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
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 >any consideration been given to other variable names: > >^_ >&_ # kinda like this - higher-order "&func" >!_ There's another argument for this, which is that __ will be hard to differentiate in print (and for some people, on the screen) from plain _. Not that they won't be able to tell by looking harder and seeing the context, but the potential for a higher casual misunderstanding is there. -- Peter Scott Pacific Systems Design Technologies
Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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 - higher-order "&func" >!_ > I've already suggested an extension to the RFC that I think makes it more powerful and makes the notation follow directly. Do you mind if I repeat it?: 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. 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 function, they know that each is referring to the same thing. Your suggested changes to notation don't allow for named placeholders. Besides, '__' is clearly a blank spot, and therefore a place waiting to be filled in (a placeholder, in fact!).
Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)
> 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 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 - higher-order "&func" !_ Same length, but they stand out more (ala $_, @_, etc) than just __. 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). -Nate
