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)
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)
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 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)
Jeremy Howard wrote:
Yes, I change my mind sounds of gears clicking 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)
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)
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)
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)
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)
It shouldn't be a problem. *_ would then be a 'special' reserverd identifier. *_name could be a named placeholder. chaim "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)
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)
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)
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)
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)
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)
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)
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
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
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!).
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)
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)
[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)
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)
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)
$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)
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)
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)
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)
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)
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... ;) Cough, splutter Please, there are children present...
