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
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
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
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
Ken Fox wrote:
I think we need a curry context and that all curries must be surrounded
by parens.
.
sub traverse ($_);
my $sum = 0;
$root-traverse(($sum += __));
I think parens may be problematic, since nested lists flatten.
Maybe curlies could be overloaded yet again?
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
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.
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
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 '*'
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
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
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 -
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,
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
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
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
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
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:
$root-traverse( $sum += __ );
There's a syntactic ambiguity here. I assumed that __ "poisons" an
expression so that an entire parse tree gets transformed into a
closure. If you isolate the parse tree based on expression precedence,
then I'm not sure why the
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,
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 -
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
But the expression
__ 2 + __ * sin(__ / 2) or die __
curries to
sub { $_[0] 2 + $_[1] * sin(sub { $_[0] / 2 }) or die $_[2] }
That's very odd.
No. You got it exactly right. :-)
I really hope I'm missing something, but __ the way you use it
Okay. I'll rework the proposal with the consensus syntax.
Damian
[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.
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
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
$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
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
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
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
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
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.
It is proposed that Perl reserve the bareword C__
(underscore-underscore)
as a "placeholder" for generating higher order functions more cleanly.
But what if I want to say:
@n = (0.2, 1, 3.5, 4);
@integersInN = grep __=abs(__) @n; # @intsInN is empty!
Instead I would need:
@integersInN =
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
[Could we get the librarian to cc: the RFC owner and hide
replies from the announcement list?]
Perl6 RFC Librarian wrote:
That is, the expression:
$check = __ 2 + __ * atan($pi/__) or die __;
is equivalent to:
$check = sub (;) {
$_[0] 2 + $_[1] *
$check = sub (;) {
@_==0 ? __ 2 + __ * atan($pi/__) or die __
: @_==1 ? $_[0] 2 + __ * atan($pi/__) or die __
: @_==2 ? $_[0] 2 + $_[1] * atan($pi/__) or die __
: @_==3 ? $_[0] 2 + $_[1] * atan($pi/$_[1]) or die __
: $_[0] 2 +
Jeremy Howard wrote:
Unless I'm missing something here, you're not filling in the args correctly.
I think you mean:
$check = sub (;) {
@_==0 ? __ 2 + __ * atan($pi/__) or die __
: @_==1 ? $_[0] 2 + __ * atan($pi/__) or die __
: @_==2 ? $_[0] 2 + $_[1] *
Thanks for the useful insights and pointers, Ken.
Top stuff (as usual :-)
I particularly liked the currying context and notions of explicitly
marking curries. Obviously I'll need to de-jetlag a little more and run
my brain over it again.
However, implicit currying is so damn handy that I
Unless I'm missing something here, you're not filling in the args correctly.
I think you mean:
$check = sub (;) {
@_==0 ? __ 2 + __ * atan($pi/__) or die __
: @_==1 ? $_[0] 2 + __ * atan($pi/__) or die __
: @_==2 ? $_[0] 2 + $_[1] *
40 matches
Mail list logo
