Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-08 Thread Jeremy Howard

> >   > 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)

2000-08-08 Thread Bart Lateur

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)

2000-08-07 Thread Nathan Wiger

> 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)

2000-08-07 Thread Glenn Linderman

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)

2000-08-07 Thread Jeremy Howard

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)

2000-08-07 Thread Damian Conway

   > 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)

2000-08-07 Thread Jeremy Howard

>> 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)

2000-08-07 Thread Damian Conway

   > 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)

2000-08-07 Thread Nathan Wiger

> 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)

2000-08-07 Thread Chaim Frenkel

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)

2000-08-07 Thread Peter Scott

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)

2000-08-07 Thread Jeremy Howard

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)

2000-08-07 Thread John Porter

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)

2000-08-07 Thread 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.  '__' 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)

2000-08-07 Thread John Porter

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)

2000-08-07 Thread Jonathan Scott Duff

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)

2000-08-07 Thread Bart Lateur

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)

2000-08-07 Thread Bart Lateur

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)

2000-08-06 Thread Jeremy Howard

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)

2000-08-06 Thread Mike Pastore

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)

2000-08-06 Thread Ken Fox

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)

2000-08-06 Thread Nathan Wiger

> > 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)

2000-08-06 Thread Nathan Wiger

> 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)

2000-08-06 Thread Jeremy Howard

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)

2000-08-06 Thread Jeremy Howard

> 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)

2000-08-06 Thread Ken Fox

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)

2000-08-06 Thread Nathan Wiger

> $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)

2000-08-06 Thread Damian Conway

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)

2000-08-06 Thread Mike Pastore

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)

2000-08-06 Thread Jeremy Howard

> > 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)

2000-08-06 Thread Ken Fox

[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)

2000-08-06 Thread Ken Fox

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)

2000-08-06 Thread Mike Pastore

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)

2000-08-06 Thread Damian Conway

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)

2000-08-06 Thread Jeremy Howard

> > 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)

2000-08-06 Thread Nathan Wiger

> 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)

2000-08-06 Thread Mike Pastore

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)

2000-08-06 Thread Peter Scott

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)

2000-08-06 Thread Jeremy Howard

> 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)

2000-08-06 Thread Nathan Wiger

> 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