Re: L2R/R2L syntax
On Sat, 25 Jan 2003, Damian Conway wrote:
> As far as I know Larry is not planning to remove the functional
> forms of C, C, etc.
>
> Those forms may, it's true, become mere wrappers for the OO forms.
> But I confidently expect they will still be available.
Hmmm, so that means that they should be overloadable on a per-arrayish-class
basis, no?
Then what happens to
@A = map { ! $_ } @B, @C;
when @B and @C are different classes?
Does that transmogrify into
@A = ( @B.map { ! $_ }, @C.map { ! $_ } )
or into
@A = [ @B, @C ] .map { ! $_ }
?
-Martin
Re: L2R/R2L syntax
Graham Barr wrote: This is not a for or against, but there is something that has been bugging me about this. Currently in Perl5 it is possible to create a sub that has map/grep-like syntax, take a look at List::Util If the function form of map/grep were to be removed, which has been suggested, and the <~ form maps to methods. How would you go about defining a utility module similar to List::Util that uses the same syntax as map/grep but without making the subs methods on the global ARRAY package ? As far as I know Larry is not planning to remove the functional forms of C, C, etc. Those forms may, it's true, become mere wrappers for the OO forms. But I confidently expect they will still be available. Damian
Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
David Storrs wrote: Correct me if I'm wrong, but isn't the one thing that all those projects have in common...well...Perl? And isn't Larry the guy to whom we owe the existence of Perl? I'm not fortunate enough to be using Perl in my job, but I'm still more than happy to pony up for a donation, purely from gratitude. This is something along the lines of the applied research vs basic research question. What Larry is doing pretty much amounts to basic research that will help all of these other projects in the long run. This is my view as well, but I can understand that it may not be everyone's (including the TPF's). At the moment, TPF is preparing to set up an on-line questionnaire to get feedback from the community on what it's priorities should be. Then we will all have our chance to have our say. Damian
Re: L2R/R2L syntax
Michael Lazzaro wrote: When I come home from work each day, I can see my dog eagerly waiting at the window, just black snout and frenetically wagging tail visible over the sill. I often think Larry and Damian must feel that way about this group. Poor, comical beasts, but so eager and well-meaning. We greet them so enthusiastically when they've arrived, it's hard for them to get too mad at us. Even when they discover we've peed on the carpet while they've been gone, and they have an awful mess to clean up. Whilst I won't speak for Larry in this, *I* certainly don't anything anything like that. (And, in truth, I know Larry well enough to be sure that he doesn't either.) Many of the members of this forum are highly talented and insightful contributers. Many of the ideas expressed here are worthy of serious consideration. For example: Angel Faus had a brilliant suggestion for cleaning up higher order functions, which we instantly adopted. And Luke Palmer's reinterpretation of junction semantics was clearly superior to my original, and will almost certainly be used. I could dig up plenty of other examples of similar contributions. And, with very few exceptions, the rest of the contributers -- though their ideas are not always feasible, elegant, practical, or sometimes even sane ;-) -- do still contribute their time and energies just as generously and with just as deep a desire to make Perl 6 as good as it can possibly be. Yes, there is a lot of tail chasing on this group, and often it only ends when Larry or I propose our own resolution. Yes, I sometimes choose to ignore a thread I see as going nowhere. But without that tail-chasing and dead-ending we mightn't see the underlying problem they're attempting to address in the first place. And we'd have to explore all the non-optimal alternative solutions ourselves. These are all genuine contributions to the design of Perl 6, and command nothing but my highest respect. Damian
Re: Why C needs work (was Re: L2R/R2L syntax)
On Wednesday, January 22, 2003, at 11:42 AM, Kwindla Hultman Kramer wrote: Michael Lazzaro writes: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in -> lex -> parse -> codify -> optimize -> $out; # L2R $out <- optimize <- codify <- parse <- lex <- $in; # R2L It's clear, from looking at either of those, that they represent data pipes. Both are even clearer than the equiv: $out = $in.lex.parse.codify.optimize; One question: How does this approach to building a pipe-lining syntax square with the "alternative spelling of the assignment operator" feature that's been discussed elsewhere in this thread? It's not immediately obvious to me how the post-/pre-invocant operation "becomes" an assignment at the end of the chain. In other words, are the first two code fragments above really equivalent to the third? They're equiv only if make a rule saying they're equiv, like what Damian was proposing for <~ and ~>. (Except this isn't quite the same thing as Damian was proposing, which is why I'm not using <~ and ~> to describe it.) You could for example use: $x <- 5; ...to do assignment (if you're into that sort of thing) if the '<-' was overloaded to do the right thing when it was piping 'to' a simple variable. Even $x <- $y <- 5; could work, since the R2L chain would do the same as $x = $y = 5; So short answer, it squares pretty well with an alternative spelling for assignment, for persons that would like to do that. They'd be equiv iff we defined the operators such that they were. MikeL
Re: Why C needs work (was Re: L2R/R2L syntax)
Thomas A. Boyer writes:
> Michael Lazzaro wrote:
> > *Now*, what to do about the fantastic magic that pointy-sub provides?
> > The _spectacular_ win would be if we could just recognize an optional
> > parameter list as part of a block.
> >
> > map @a : ($a,$b) {...} # params + closure = closure with params?
> > for @a : ($a,$b) {...}
> >
> > So that anywhere you had a closure, you could put a paramlist in front
> > of it. Not likely we could get that to work, since best-case scenario
> > it would probably barf on $a and $b being undefined before it ever got
> > to the closure. But it might be possible, at the expense of some
> > parser complexity.
>
I sertainly can do it like taht :
map @a : {...} is sig($a,$b)
for @a : {...} is sig($a,$b)
or
map @a : sub($a,$b) {...}
for @a : sub($a,$b) {...}
or
@a ~> map sub($a,$b) {...}
It also seems that the difference between map and for may be twisted
as follows : map apply particular closure to several ( possibly one )
array , while for takes particular array ( which may have possibly
passed some pre -zipping/-weaving) and apply pour it to several (
possibly one ) closures.
if we assume that for can accept as its last arguments sequence one or
more closures than with the existing pointy sub meaning of -> we can
have
for @a -> ( $x ){ ... }
-> ( $y ){ ... }
-> ( $z ){ ... } ;
and "," is unnecessary after the curly for the same reason it is
unnecessary after @a.
since grep/map/and_friends are just subroutines this naturally gives
piping behaviour :
for @a -> ( $x ){ ... } #this is map
,grep -> ( $y ){ ... } #this is grep
,sort -> ( $a,$b ){ ... } ; #this is sort
this is similar to the old "then" suggestion of Damian Conway
@a then map -> ( $x ){ ... } #this is map
then grep -> ( $y ){ ... } #this is grep
then sort -> ( $a,$b ){ ... } ; #this is sort
arcadi
Re: Why C needs work (was Re: L2R/R2L syntax)
Michael Lazzaro wrote:
> *Now*, what to do about the fantastic magic that pointy-sub provides?
> The _spectacular_ win would be if we could just recognize an optional
> parameter list as part of a block.
>
> map @a : ($a,$b) {...} # params + closure = closure with params?
> for @a : ($a,$b) {...}
>
> So that anywhere you had a closure, you could put a paramlist in front
> of it. Not likely we could get that to work, since best-case scenario
> it would probably barf on $a and $b being undefined before it ever got
> to the closure. But it might be possible, at the expense of some
> parser complexity.
I agree that it might be difficult to recognize the ($a,$b) as a parameter list rather
than a list expression. Smalltalk marks block parameters this way:
b := [:a :b | a < b]. "Assign a two-paremeter block to b"
^b value: 1 value: 2. "Return the value of invoking b on 1 and 2"
The "[" makes it clear that a block is next; the ":" marks parameters and the "|" ends
the list. A literal translation to Perlish syntax would be
map @a { :$a :$b | $a + $b }
but then we get into discussions about Larry's 2nd law of colons. Besides, we perl
mongers already use "|" for a sufficient multitude of other things.
But my point is: just because C-ish programmers think "(...){ ... }" feels
parameterish doesn't mean that the parameter declaration has to come *before* the
opening curly brace. And no, despite two Smalltalk-related posts in the last three
days, I don't want to turn Perl into Smalltalk; I just think that Smalltalk has a nice
syntactic solution to the problem we're talking about here.
The problem is, I can't think of any syntaxes better than
map @a { $a $b: $a + $b } # hey, buddy, can you lend me a colon?
map @a { args $a, $b; $a + $b }
map @a { -> ($a, $b); $a + $b }
map @a { $a, $b ->$a + $b } # can't coexist with A4-style pointy subs
map @a { my^ $a, $b; $a + $b } # the ^ is reminiscent of "map @a { $^a + $^b }
map @a {{$a, $b} $a + $b } # all other uses of consecutive curlies require
space: "{ {"
map @a { EXPLICIT_ARGUMENTS_TO_FOLLOW $a $b ARGUMENTS_STOP_HERE $a + $b }
and they all look uglier than... well, um, uh... I want.
I have a strong suspicion that this possibility was carefully considered by {LW, DC,
...} (that's set notation, not a code block :) before the Apocalypse 4 "pointy sub"
syntax (and the for-loop syntax using it) was promulgated. And that it was rejected
because it's hard to come up with something that "looks right." Even the Smalltalk
syntax is a tad awkward-looking to me, and the warpage that is necessary to make it
Perlish just compounds the problem.
Hmmm. I guess I didn't really say anything here, did I? Do I post these ruminations,
or should I just hit that cancel button before I "open my mouth and remove all doubt?"
Nah. I'm goin' for it: maybe somebody else will think of a syntax that looks right!
=thom
"Must be a yearning deep in human heart to stop other people from doing as they
please. Rules, laws--always for the other fellow. A murky part of us, something we had
before we came down out of the trees, and failed to shuck when we stood up. Because
not one of those people said: 'Please pass this so I won't be able to do something I
know I should stop.' Nyet, tovarishchee, was always something they hated to see their
neighbors doing. Stop them 'for their own good'--not because the speaker claimed to be
harmed by it."
Manuel Davis O'Kelley
The Moon is a Harsh Mistress
Re: Why C needs work (was Re: L2R/R2L syntax)
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
[[... Massive elision ...]]
> I'm thinking it would be a very good idea to unify C and C
> in their argument style. I still think the distinction between
> C's void and C's list context is a good one; i.e. don't
> make them I synonyms.
>
> But it seems natural to have C a method of C, however
> unnatural that seems. I don't know, my thoughts are quite unclear at
> this point; perhaps I'll write back when I've thought about this a
> bit more.
On a somewhat disjunctive note, if you're going to play games with
unifying C and C, let's undef the operation-order of map.
That is,
for (1,2,3) { print }
# 1 2 3
map { print } (1, 2, 3) # or however you rewrite the syntax
# ? ? ?
@a = map { print } (1, 2, 3)
for @a { print }
# 1 2 3
Note that the order of the results of map would still be guaranteed,
but not the order of operation. This is for threading, obviously, and
we should probably do the same thing everywhere we can, so that if you
want serial operation, you use "for" or some construction that honors
ordering attributes internal to the data.
The point is to warn people that preserving state in map blocks won't
work, although stateless data or statistics will:
map { count++; ... } @array # works fine -- count == array.length
map { %hist{$_}++ } @array # works fine -- hist{} counts occurrences
map { ...$last ...; # I do not think that code
last=$_; ... } @array # means what you think it means...
=Austin
Re: Why C needs work (was Re: L2R/R2L syntax)
Michael Lazzaro writes: > And it provides a very visual way to define any pipe-like algorithm, in > either direction: > > $in -> lex -> parse -> codify -> optimize -> $out; # L2R > > $out <- optimize <- codify <- parse <- lex <- $in; # R2L > > It's clear, from looking at either of those, that they represent data > pipes. Both are even clearer than the equiv: > > $out = $in.lex.parse.codify.optimize; > > Whether you would code a pipeline as L2R or R2L depends on the specific > algorithm you're representing, and is purely a matter of taste... > you'd probably use R2L in the same places as you use C-like > chaining in Perl5. I can't begin to justify why one should be superior > to the other, and would certainly use them both. > This explanation of (and rationale for) a "post-invocant" underpinning for l2r/r2l pipe-lining was wonderfully clear. I've also found that newish perl programmers frequently find C and friends to be confusing, particularly when they are traveling in a pack (not to speak of an C). One question: How does this approach to building a pipe-lining syntax square with the "alternative spelling of the assignment operator" feature that's been discussed elsewhere in this thread? It's not immediately obvious to me how the post-/pre-invocant operation "becomes" an assignment at the end of the chain. In other words, are the first two code fragments above really equivalent to the third? Kwin
Re: Why C needs work (was Re: L2R/R2L syntax)
> Date: Wed, 22 Jan 2003 10:38:23 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
> > But in a for loop:
> >
> > for 1,2,3,4 { ... }
> > for 1,2,3,4 -> ($a,$b) {...}
> >
> > its cuteness works because the brain sees it as a piping operator (even
> > though its not).
>
> *** SPECULATION AHEAD ***
>
> Note that C allows you to name the arguments, using the pointy sub
> rule:
>
> for @a -> ($a,$b) {...}
>
> but note ALSO that it'd be great if C and friends had that
> capability, so you could C two-at-a-time, etc. (C and
> C don't really need it, but I *suppose* you could use it for
> grepping/sorting tuples.)
I'm not sure whether you know that this already is the plan. The
following three are equivalent:
my @a = map { uc } @b;
my @a = map { uc $^a } @b;
my @a = map -> $x { uc $x } @b;
And I believe two-at-a-time would also work.
> So we want the pointy-sub rule for C and friends too:
>
> my @a = map -> ($a,$b) {...}; # pass to {...} 2-at-a-time, as $a
> and $b
>
> Pretty neat.
>
> But ignoring pointy-sub for the moment, and assuming that we in fact
> used -> and <- to mean pre/post-invocant (e.g. "pipes"): if we defined
> C as just another word for C, what we really want is rules
> such that *all* of the following work. Question is, is it possible to
> come up with something consistent. Maybe.
>
> # void context
>
> @a.map {...}
> @a.for {...} # identical
> @a -> map {...} # identical
> @a -> for {...} # identical
>
> @a -> {...} # identical (a cool shorthand when given
> a closure?)
>
> for @a {...} # Doh! This wouldn't work
> for @a : {...}# Hey, but this would (indirect object
> syntax)
> map @a : {...}# identical
>
> for @a,@b,@c : {...} # is this OK?
> for (@a,@b,@c) : {...}# OK, and better looking
>
> # list context
>
> my @a = @b -> for {...}
> my @a = @b -> map {...} # identical
> my @a = map {...} <- @b # identical
> my @a = for {...} <- @b # identical
>
> my @a <- map {...} <- @b# identical
> my @a <- for {...} <- @b# identical
>
> That works. Pretty darn well, too. (Note the critical bit, the
> introduction of indirect object syntax to C.)
Yeah, good point. Why is it that C and C, so similar in
nature, accept such different forms for their arguments?
But, I'll have to admit,
for @a,@b :-> $a, $b { ... }
Doesn't look quite as nice as the older version :->
I'm thinking it would be a very good idea to unify C and C
in their argument style. I still think the distinction between
C's void and C's list context is a good one; i.e. don't make
them I synonyms.
But it seems natural to have C a method of C, however
unnatural that seems. I don't know, my thoughts are quite unclear at
this point; perhaps I'll write back when I've thought about this a bit
more.
Luke
Re: Lexically scoped methods (was: L2R/R2L syntax)
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Cc: [EMAIL PROTECTED]
> Date: Wed, 22 Jan 2003 09:03:13 -0600
> From: "Adam D. Lopresto" <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> The question is, can I create a method on a class with a different scope than
> the class itself has? Put another way, it seems like
>
> module ArrayMath;
>
> sub sum(Array $this){
> $this.reduce(operator::+, 0);
> }
>
> method Array::sum(;){
> .reduce(operator::+, 0);
> }
>
>
> (modulo syntax errors) then both should have the same visibility
> (ie, module level only, unless they're somehow exported (what's that
> in perl6, "is public"?)). So the question of namespace becomes
> moot, because just because it's a method on Array doesn't mean it's
> accessible anywhere a similar sub wouldn't be. Either could be
> exported and made globally available, but I don't see why they
> should have to be. Or am I missing something?
If I was designing the object system (something I have _so_ much
experience with :-P ), I'd say that you can't declare methods outside
of their class definition, but you can define subs that take that
class in the indirect object position.
sub sum(Array $this:) {
$this.reduce( { $^a + $^b }, 0 );
}
It's appealing just because it's so happy :).
The difference between this and:
class Array {
# ...
method sum($self:) {
.reduce( { $^a + $^b }, 0 );
}
# ...
}
Would be that the latter has access to Array's private data, while the
former does not. The calling conventions would not be any different
between the two.
Luke
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 -> ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
That's an excellent observation. I like the 'for' syntax quite a bit,
but never quite could put my finger on why it worked so well. You're
right, that's exactly it.
And this begs the question: what exactly does the C contribute to
the semantics of the pipeline? What would C (in void context)
do differently?
Hmm. Perhaps there doesn't _need_ to be a difference. You currently
use C when you don't care about capturing the results. You use
C when you do. But since we can identify context, perhaps they
could be synonyms, if we tweak things a little.
*** SPECULATION AHEAD ***
Note that C allows you to name the arguments, using the pointy sub
rule:
for @a -> ($a,$b) {...}
but note ALSO that it'd be great if C and friends had that
capability, so you could C two-at-a-time, etc. (C and
C don't really need it, but I *suppose* you could use it for
grepping/sorting tuples.)
So we want the pointy-sub rule for C and friends too:
my @a = map -> ($a,$b) {...}; # pass to {...} 2-at-a-time, as $a
and $b
Pretty neat.
But ignoring pointy-sub for the moment, and assuming that we in fact
used -> and <- to mean pre/post-invocant (e.g. "pipes"): if we defined
C as just another word for C, what we really want is rules
such that *all* of the following work. Question is, is it possible to
come up with something consistent. Maybe.
# void context
@a.map {...}
@a.for {...} # identical
@a -> map {...} # identical
@a -> for {...} # identical
@a -> {...} # identical (a cool shorthand when given
a closure?)
for @a {...} # Doh! This wouldn't work
for @a : {...}# Hey, but this would (indirect object
syntax)
map @a : {...}# identical
for @a,@b,@c : {...} # is this OK?
for (@a,@b,@c) : {...}# OK, and better looking
# list context
my @a = @b -> for {...}
my @a = @b -> map {...} # identical
my @a = map {...} <- @b # identical
my @a = for {...} <- @b # identical
my @a <- map {...} <- @b# identical
my @a <- for {...} <- @b# identical
That works. Pretty darn well, too. (Note the critical bit, the
introduction of indirect object syntax to C.)
*Now*, what to do about the fantastic magic that pointy-sub provides?
The _spectacular_ win would be if we could just recognize an optional
parameter list as part of a block.
map @a : ($a,$b) {...} # params + closure = closure with params?
for @a : ($a,$b) {...}
So that anywhere you had a closure, you could put a paramlist in front
of it. Not likely we could get that to work, since best-case scenario
it would probably barf on $a and $b being undefined before it ever got
to the closure. But it might be possible, at the expense of some
parser complexity.
If we couldn't do that, you would have to say:
for @a : sub ($a,$b) {...} # OK
or
@a -> for sub ($a,$b) {...} # a bit icky
The first of those looks better than the second. I loathed the second
after I first wrote it, but now it's beginning to grow on me a bit
better. The intent is certainly clear, for example.
The pointy-sub syntax doesn't really work in these cases, though. I
can't think of anything you could use in place of 'sub' that would make
either of those look better.
So, the benefits of trying to pursue this: It makes C and C
synonyms, and gives each the magical powers of the other. The fact
even C is now an object method means you could say:
for @obj : {...}
and even overload the C behavior for a Collection-based @obj. It
also gets rid of the perl5 bugaboo:
for (@a) {...}
map {...} @a;# params are reversed. Newbie trap!
So the biggest single trick is, C would have the colon after the
list:
for @a : {...}
If we did that, the rest might just work.
Anyway, just speculation.
MikeL
Re: Why C needs work (was Re: L2R/R2L syntax)
"David Storrs" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > And then we can replace the ~> with ->:
> >
> > for 1,2,3,4
> > -> sub ($a, $b) { $a+$b }
> > -> sub ($a) { $a**2 }
> > -> { $^foo - 1 }
> > -> print;
> >
> > And this begs the question: what exactly does the C contribute to
> > the semantics of the pipeline? What would C (in void context)
> > do differently?
>
> One potential answer: make 'map' be lazy by default and 'for' be
> nonlazy (energetic? active? ADHD?). My logic in suggesting it this
> way around is that, to me, 'for' seems to operate more on a whole
> list, while 'map' is intended to operate on elements one after
> another. Like so:
>
> for (1,2,3) { print } # "I want to call print for this whole list"
> map { print } (1,2,3) # "Map the 'print' function over the elements
># of this list"
I have a feeling its the other way round:
(1,2,3,4) ~> map { print }
Vs
for 1,2,3,4 -> print
The "obj ~> method args" form calls the method on the object. C
is then a method (called on the entire list) that calls its codeblock for
each member
The "for list -> sub" would call the sub for each member of the list. Hence
an equivalence:
for list -> { per-elem code }
eq
list ~> map { per-elem code }
But remember, this is all getting very hypothetical: -> doesn't (currently)
mean "L2R pipe into sub"
Dave.
Lexically scoped methods (was: L2R/R2L syntax)
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both should have the same visibility (ie, module
level only, unless they're somehow exported (what's that in perl6, "is
public"?)). So the question of namespace becomes moot, because just because
it's a method on Array doesn't mean it's accessible anywhere a similar sub
wouldn't be. Either could be exported and made globally available, but I don't
see why they should have to be. Or am I missing something?
> On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote:
> >
> > On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote:
> > > If the function form of map/grep were to be removed, which has been
> > > suggested,
> > > and the <~ form maps to methods. How would you go about defining a
> > > utility
> > > module similar to List::Util that uses the same syntax as map/grep but
> > > without making the subs methods on the global ARRAY package ?
> >
> > If you want the method to be available everywhere,
>
> But I don't
>
> > you probably
> > _should_ make it a method of the global Array class.
>
> Thats like trying to wite a whole perl5 application in main
> without any packages
>
> > More typically,
> > perhaps, you'd only be using your new method to operate on certain
> > arrays that you use, in which case you would make a new class for those
> > particular arrays, so your new method would work only on the specific
> > arrays you intended it to:
>
> Thats not always possible. Those Arrays may be passed to me from
> somewhere else, so I have no control over thier class.
>
> > I don't see any problem (other than maybe a philosophical objection)
> > with making them methods of Array, though, if they're valuable enough.
> > That certainly would seem the common Perl thing to do.
>
> No, namespaces were invented for a reason.
>
> Graham.
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All of our customer service representatives are on vacation. Please hold for
the next available representative.
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
> $a = sub ($a, $b) { ... }
> $x = -> ($y, $z) { ... }
>
> The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for "pointy arrow means sub" that will actually stick in my brain.
Every time I see this construct, I have to stop in my tracks and
mentally flip through the reference manual.
> But in a for loop:
>
> for 1,2,3,4 { ... }
> for 1,2,3,4 -> ($a,$b) {...}
>
> its cuteness works because the brain sees it as a piping operator (even
> though its not).
Agreed.
[snip]
> And then we can replace the ~> with ->:
>
> for 1,2,3,4
> -> sub ($a, $b) { $a+$b }
> -> sub ($a) { $a**2 }
> -> { $^foo - 1 }
> -> print;
>
> And this begs the question: what exactly does the C contribute to
> the semantics of the pipeline? What would C (in void context)
> do differently?
One potential answer: make 'map' be lazy by default and 'for' be
nonlazy (energetic? active? ADHD?). My logic in suggesting it this
way around is that, to me, 'for' seems to operate more on a whole
list, while 'map' is intended to operate on elements one after
another. Like so:
for (1,2,3) { print } # "I want to call print for this whole list"
map { print } (1,2,3) # "Map the 'print' function over the elements
# of this list"
--Dks
Re: Why C needs work (was Re: L2R/R2L syntax)
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Of course, _I'd_ even prefer using <- and -> as the 'piping' operators,
> and having ~> or |> for pointy sub, because then $a->foo and $a.foo
> really _could_ be the same thing, 'cept for precedence. But that's not
> gonna happen, and _I'm_ not gonna press it. :-)
I wouldn't (and don't) give up so easily! The "->" syntax for anonymous
subs is cute: but it seems to be cute only in limited contexts -- those
where it is also being used as a (conceptual) piping operator.
Compare:
$a = sub ($a, $b) { ... }
$x = -> ($y, $z) { ... }
The pointy-arrow doesn't buy anything here.
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 -> ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
Perl6 is still Perl. We're allowed to do a bit of DWIMery in the parser,
if needed, to make the simple (common) cases work. So perhaps we
should define the C in terms of pipelines. With some minor
syntax changes, we can free up the -> operator:
for 1,2,3,4 ~> sub ($a,$b) { ... }
Sure, its not quite so cute. You could rename the C if desired
(for example, perhaps it could be spelt C in this context, though
you'd need to work on the lexical scoping rules). The only remaining
magic would be to retrofit the basic C to work.
And then we can replace the ~> with ->:
for 1,2,3,4
-> sub ($a, $b) { $a+$b }
-> sub ($a) { $a**2 }
-> { $^foo - 1 }
-> print;
And this begs the question: what exactly does the C contribute to
the semantics of the pipeline? What would C (in void context)
do differently?
Dave.
Re: L2R/R2L syntax
Damian Conway writes:
>
> Not equivalent at all. C<$foo~>bar> means "append $foo to the argument list
> of subroutine C". C means "make C<$foo> the invocant for method
> ".
>
> Curiously enough, the confusions I'm hearing over this issue are, to me, the
> strongest argument yet for using Andy's |> and <| symbols instead.
>
> Damian
>
Proposal :( but may be this is just part of the above mentioned
confusion:)
* we probably should distinguish between
+ pseudo-pipes ( I spell them as :> and <: )
+ and right- and left- assignment operators ( I
spell them ... => $var and $var <= ... ) .
these should be aware of distinction between assignment and
binding -- so probably there have to be 2 forms of each ???
* :> and <: should be thought of ( and probably actually are ) just
( special ) __commas__ in the following sense :
@a :> sort { ... }#==> sort { ... } @a:
@a :> join "..." #==> join "..." @a:
sort { ... } <: @a #==> sort { ... } @a:
join "..." <: @a #==> join "..." @a:
so it seems that ( already discussed ) redunduncy of <: can be solved
by saying that
* <: is doing to the _following_ term _the_same_thing_ ( makes it an
adverb ) as what ":" is doing to the _preceding_ term --- so <: is sort
of "prefix" form special comma : .
that means that <: is "prefix" adverbial comma - and the verb is
to be found _before_ the <: comma .
* :> is different . it makes the _preceding_ term an adverb --- but
the corresponding verb have to be searched _after_ the :> comma .
it seems that all the distinction between methods and subroutines is
now handled if methods and subroutines know how to handle adverbial
arguments. ( but this does not allow to place _usual_ arguments
before the subroutine/method -- so probably there have to be another
comma )
It seams that with this in mind and usual precedence rules we can
make multimethods enjoy the l2r notations.
( $square :> init ) :>
( $circle :> init ) :> do_something
do_something <: ($square :> init)
<: ($circle :> init)
arcadi
Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
On Tue, Jan 21, 2003 at 02:21:58PM -0800, Austin Hastings wrote: > > --- David Storrs <[EMAIL PROTECTED]> wrote: > > This is something along the lines of the applied research vs basic > > research question. What Larry is doing pretty much amounts to basic > > research that will help all of these other projects in the long run. > > Sure. But managing the funding budget isn't a business, where basic > research will enable more income. It's the allocation of scarce I'm not convinced that that is correct. Basic research may enable more income. If it works. But at least 90% of basic research won't. Hence you have to do a lot of it, but the odd time you get it right, it can be very lucrative > resources. And from that viewpoint, Larry and P6 is an iceberg, just > cruising along hoping to gash a massive hole in the support/maintenance > schedule, because once P6 rolls all the other stuff has to be sorted, > ported, and supported. I'm not quite following you - this looks like an argument against P6, because its appearance will create a lot more work? > If I was in charge of the TPF funding budget, I'd be yearning to pick > up the phone whenever I saw an episode of "The Sopranos"(*)... And this I don't follow at all, having never seen The Sopranos. So I'm probably completely failing to address the points you are making The problem I see with not funding Larry, is that if as a consequence Larry has to get a job that prevents him from working on Perl 6, Perl 6 won't happen until he retires. Anyone can implement Perl 6 (although I reckon we'd have a setback of many months on parrot if Dan stopped and left, and more if other people dropped out as a result. But it can be picked up by anyone capable). Not just anyone can design Perl 6. The obvious counter argument is that if Perl 6 stops, Perl 5 as is won't go away; Perl 5 is what we have; Perl 5 is what we are using, and Perl 5 is good enough. However eventually everyone volunteering to work on it will drift away. At which point it is stagnant, and no bugs get fixed. For some reason, Perl 6 actually brought a lot of new blood and new momentum to Perl 5. I suspect Perl 5.8 would not have happened, or at least not have happened yet, had Perl 6 not been around. Perl 6 may seem crazy, far fetched and long term. Yet it is bringing morale to Perl 5, suggesting that Perl does have a future, and that maybe Perl 5 is worth working on. If Perl 5 doesn't feel worth working on, then most will go away. I've been involved in development communities before where the future has been pulled out from under our feet. The community dissipates - there is more fun to be had elsewhere. You may think that volunteers on Perl 5 are not important. You may not be using Perl 5.8, and you may see no need to. Ever. But if you're using 5.004, 5.005_03 or 5.6.1, and you have hit a bug in it, how are you going to get it fixed? Currently bugs discovered in 5.8 are actively being fixed (or at least ought to be - nag p5p if they aren't). But a release of 5.6.2 looks unlikely, and 5.005_04 equally improbable. How would you feel if there was never going to be a 5.8.1 either? Would it affect your technology choice? Would it affect your clients'/employers'? Hence I would argue that if Perl 6 halts, Perl 5 stops looking credible long term. Which I don't want to happen. Currently this argument is shaky, because to an external observer, Larry with funding unable to produce apocolypses due to other reasons is indistinguishable from Larry unable to produce apocolypses due to lack of funding. Except that there is visibly less money for anything else worthy. Nicholas Clark
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 02:38 PM, Buddha Buck wrote: Michael Lazzaro wrote: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in -> lex -> parse -> codify -> optimize -> $out; # L2R $out <- optimize <- codify <- parse <- lex <- $in; # R2L It's clear, from looking at either of those, that they represent data pipes. The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal... So the apparant symmetry between <~ and ~> isn't really there. I like <~ and ~>, but I think that it will be a common mistake to think that $a ~> b~>c~>d can be reversed to give d<~c~, at least as currently formulated. Agreed, it could be quite misleading. Personally, I'd be happier if <~ and ~> worked _only_ on objects and methods, instead of arbitrary subs... but I understand the utility of the other way. Of course, _I'd_ even prefer using <- and -> as the 'piping' operators, and having ~> or |> for pointy sub, because then $a->foo and $a.foo really _could_ be the same thing, 'cept for precedence. But that's not gonna happen, and _I'm_ not gonna press it. :-) MikeL
Re: Why C needs work (was Re: L2R/R2L syntax)
Smylers wrote: Michael Lazzaro wrote: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in -> lex -> parse -> codify -> optimize -> $out; # L2R $out <- optimize <- codify <- parse <- lex <- $in; # R2L It's clear, from looking at either of those, that they represent data pipes. Yes; that is nice. I'm just not convinced that it's sufficiently nice to require adding yet another way of passing data around to the language. I'm happy enough with the asymmetry that occurs just having the arrows to indicate 'reverse flow' data. The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal... Perl 5 has two different code calling conventions: object oriented method calls, and procedural subroutine calls. OO method calls are L2R already: $object.method1().method2().method3().method4(); Procedural subroutine calls are R2L already: sub4 sub3 sub2 sub1 $variable; But there is no way to do OO method calls R2L, and there is no way to do procedural subroutine calls L2R. Damian's ~> and <~ proposal fills in this gap: method4 <~ method3 <~ method2 <~ method1 <~ $Xbject; $variable ~> sub1 ~> sub2 ~> sub3 ~> sub4; To the best of my knowledge, the following two WILL NOT WORK: sub4 <~ sub3 <~ sub2 <~ sub1 <~ $variable; $Xbject ~> method1 ~> method2 ~> method3 ~> method4 The first one tries to invoke the sub1 method of $variable, while the second tries to call the method1 function with $object as an argument. If either of these works, it's either coincidence or careful planning. So the apparant symmetry between <~ and ~> isn't really there. I like <~ and ~>, but I think that it will be a common mistake to think that $a ~> b~>c~>d can be reversed to give d<~c~, at least as currently formulated.
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 01:31 PM, Smylers wrote:
Michael Lazzaro wrote:
it's that I _dislike_ the perl5 rule, ...
Oh. That's "dislike" rather than "disliked"? My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?
I still dislike it, but if a variation upon it means we can make things
like C, C, etc. semi-normal functions, instead of cases within
the grammar, then I think everyone agrees that would be a Good Thing.
Keeping one grammar special case in return for not having a dozen
others -- yeah, I'll sign up for that.
I don't loath the old C syntax to the point where I'd just die if
it were there. And I don't expect we'd really get rid of it, it's too
intrinsic to Perl5. At very minimum, we'd have to keep the global
functions around as a module you could load for Perl5-friendliness.
I do think OO & pipelines are the better, more generic way to do the
same thing. So I'd really like to see pipelines, even if they're just
in addition to the old C style. After that, it's just a question
of whether the old style is worth the redundant declarations, which is
purely a matter-of-taste thing.
the most frequent mistake is to reverse the order of the arguments,
saying
map @a, {...}
That happens if you conceptualize C as taking two arguments.
I think you're right about that. And we have both:
for (@a) {...}
and
map {...} @a;
Which stings some newbies repeatedly, poor lads.
Was that an understandable explanation? :-)
Yes. Thanks, again. Please don't take personally my disagreeing with
so much you've written!
On the contrary. I'm just so happy someone understood what I was
trying to say, I think I'm going to burst into tears... Wait, no...
OK, I'm better now.
MikeL
Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
--- David Storrs <[EMAIL PROTECTED]> wrote: > On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > > Paul Johnson wrote: > > > > > Well, I'll be pretty interested to discover what cause is deemed > more > > > deserving than Larry, Perl 6 or Parrot. The P still stands for > Perl, > > > right? > > > > True. But I suspect that TPF's position is that, to many people, > Perl 6 is > > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, > or PDL, or > > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, > or any of > > a hundred other projects on which their job depends on a daily > basis. > > > > Supporting those efforts is important too, and TPF has only limited > resources. > > Correct me if I'm wrong, but isn't the one thing that all those > projects have in common...well...Perl? And isn't Larry the guy to > whom we owe the existence of Perl? I'm not fortunate enough to be > using Perl in my job, but I'm still more than happy to pony up for a > donation, purely from gratitude. > > This is something along the lines of the applied research vs basic > research question. What Larry is doing pretty much amounts to basic > research that will help all of these other projects in the long run. Sure. But managing the funding budget isn't a business, where basic research will enable more income. It's the allocation of scarce resources. And from that viewpoint, Larry and P6 is an iceberg, just cruising along hoping to gash a massive hole in the support/maintenance schedule, because once P6 rolls all the other stuff has to be sorted, ported, and supported. If I was in charge of the TPF funding budget, I'd be yearning to pick up the phone whenever I saw an episode of "The Sopranos"(*)... =Austin
Re: Why C needs work (was Re: L2R/R2L syntax)
Michael Lazzaro wrote:
> On Monday, January 20, 2003, at 12:30 PM, Smylers wrote:
>
> > It was only on reading that (and discovering that you hadn't
> > previously known about the 'optional comma with closure argument'
> > rule) that I understood why you had previously been so in favour of
> > proposed new syntaxes: through a desire to banish the Perl 5 syntax.
>
> Yes. Again, it's not that I never knew about the perl5 rule,
Sorry, I wasn't meaning to suggest that you didn't know Perl 5; I was
specifically referring to your saying that you'd presumed that
conditions and loops were special cases in the grammar, but that
actually they'll be dealt with by the general Perl _6_ rule about commas
and closure arguments.
> it's that I _dislike_ the perl5 rule, ...
Oh. That's "dislike" rather than "disliked"? My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?
> as I dislike most special-case grammar rules.
So do I! I was particularly impressed by the ultraviolet comma rule,
and how it avoids special cases, when Damian paraded it at a talk last
summer.
I also don't reckon it's _that_ special. So long as the rule is that
such commas are optional, as distinct from their absence being
mandatory, then the rule is a very general one: commas may be omitted
where they aren't needed to delimit list items. Obviously with string
and numeric values commas are always required:
$a -1
They are the only way of determining op/term for the minus sign: a
single argument of one less than the value in C<$a>, or two arguments
with the second being minus one?
But closures can be unambiguously determined without commas. Since
whitespace is no longer allowed in hash look-ups, space followed by an
open brace must be the start of a closure, and hence another argument.
Similarly once the closing brace has been reached the closure is ...
ahem, closed, so anything following must be a separate argument.
> If we dropped C, etc., we could drop the inferred-comma rule as
> well (unless we're really successful in making C a simple
> function, in which case we need the rule anyway, so who cares?)
I guess that's the crucial issue. Since it was Damian saying that it is
possible to have C and friends as functions -- and since this was
something that'd already been dealt with before I joined this list, and
so presumably would've had any impossibility pointed out -- I believed
it to be true.
There's another sub-thread casting doubt on -- and trying to resolve --
the issue. I completely agree that whether the infrared comma rule is
needed over there makes a big difference to its use here.
But I think I disagree about the "who cares" part ...
> But the inferred-comma rule is tangential to my dislike of the current
> C syntax. I'd dislike C, and like pipelines, even if the
> inferred-comma rule wasn't there.
As you've not doubt noticed, I'm the opposite: I like C and don't
(yet?) see the point of right-left pipelines. (That means not that I
claim you're in some way 'wrong' to have those preferences, merely that
we think differently to each other.) There's one Perl slogan that'd
suggest having both ways in the language, so both of us get to code in
the way we like.
Countering that is the risk of adding too many ways of doing things and
just causing confusion for everybody with all the different ways of
invoking functions/methods on data. Hence my quibble with "who cares":
I could probably be persuaded that it's 'better' for the language not to
have the Perl 5 syntax, my preference, than to have so many alternative
syntaxes. (I'm not sure.)
> > Mike ... do you still find right-left pipelines as compelling as
> > you've previously argued?
>
> Yes, very much so. ... I've seen quite a few newbies struggle with
> the C syntax;
Me too. The most-strugglable bit for many has been the right-left data
flow, that you start by typing where you want the data to end up, then
the process it goes through last, then the process it goes through
first, and lastly the data that's being processed. Left-right pipelines
should be great at fixing this.
> the most frequent mistake is to reverse the order of the arguments,
> saying
>
> map @a, {...}
That happens if you conceptualize C as taking two arguments. In my
mind C operates on items in a list (and it just so happens that
in Perl an array provides a list):
map { ... } $a, $b, $c;
So C takes _many_ arguments, and one of these arguments is not like
the others. And it makes sense to put the 'special' argument first.
(That's also how I remember which way round things like C are.)
Thinking of it as operating on a list of things also helps to emphasize
that C processes just a single item at a time, that it isn't an
agregate operation on the items as a group.
> (Another common one is to not understa
Re: L2R/R2L syntax
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Tuesday, January 21, 2003, at 12:26 PM, Piers Cawley wrote: >> Though I'm sure Damian will be long eventually to correct my >> syntax. I'm getting this weird feeling of deja vu though... > > When I come home from work each day, I can see my dog eagerly waiting > at the window, just black snout and frenetically wagging tail visible > over the sill. > > I often think Larry and Damian must feel that way about this group. > Poor, comical beasts, but so eager and well-meaning. We greet them so > enthusiastically when they've arrived, it's hard for them to get too > mad at us. Even when they discover we've peed on the carpet while > they've been gone, and they have an awful mess to clean up. Heh. I wouldn't mind, but I'm getting the very strong feeling that this is about the third time we've returned to this particular pile of vomit and spread it around differently. Everyone, please don't take that perjoratively, I just saw the opportunity to extend Mike's metaphor further than it should be expected to go, and I took it. Right, back to the summary. -- Piers
Re: L2R/R2L syntax
On Tuesday, January 21, 2003, at 12:26 PM, Piers Cawley wrote: Though I'm sure Damian will be long eventually to correct my syntax. I'm getting this weird feeling of deja vu though... When I come home from work each day, I can see my dog eagerly waiting at the window, just black snout and frenetically wagging tail visible over the sill. I often think Larry and Damian must feel that way about this group. Poor, comical beasts, but so eager and well-meaning. We greet them so enthusiastically when they've arrived, it's hard for them to get too mad at us. Even when they discover we've peed on the carpet while they've been gone, and they have an awful mess to clean up. MikeL
Re: L2R/R2L syntax
Graham Barr <[EMAIL PROTECTED]> writes:
> On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
>> > What benefit does C<< <~ >> bring to the language?
>>
>> Again, it provides not just a "null operator" between to calls, but
>> rather a rewrite of method call syntax. So:
>>
>> map {...} <~ grep {...} <~ @boing;
>>
>> is not:
>>
>> map {...} grep {...} @boing;
>>
>> But rather:
>>
>> @boing.map({...}).grep({...});
>
> This is not a for or against, but there is something that has been
> bugging me about this.
>
> Currently in Perl5 it is possible to create a sub that has map/grep-like
> syntax, take a look at List::Util
>
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?
Well, I very much hope that the function form won't be going away;
functional style is bloody useful dammit and I don't want to be forced
to add line noise just to make those who have a woody for
orthogonality happy. Anyhoo, if it *does* go away, then it should be
possible to set up an appropriate set of multiply dispatched generic
functions.
sub reduce ( &block, $init, *@array ) is multi {
@array.reduce(&block, $init);
}
sub reduce ( &block, $init, Collection $collection ) is multi {
$collection.reduce(&block, $init);
}
sub reduce ( $expr is qr//,
$init, *@array ) is immediate, is multi {
@array.reduce( $expr, $init);
}
sub reduce ( $expr is qr/Perl::term/,
$init, Collection $collection ) is immediate, is multi
{
$collection.reduce($expr, $init);
}
Though I'm sure Damian will be long eventually to correct my
syntax. I'm getting this weird feeling of deja vu though...
--
Piers
TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > Paul Johnson wrote: > > > Well, I'll be pretty interested to discover what cause is deemed more > > deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, > > right? > > True. But I suspect that TPF's position is that, to many people, Perl 6 is > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of > a hundred other projects on which their job depends on a daily basis. > > Supporting those efforts is important too, and TPF has only limited resources. Correct me if I'm wrong, but isn't the one thing that all those projects have in common...well...Perl? And isn't Larry the guy to whom we owe the existence of Perl? I'm not fortunate enough to be using Perl in my job, but I'm still more than happy to pony up for a donation, purely from gratitude. This is something along the lines of the applied research vs basic research question. What Larry is doing pretty much amounts to basic research that will help all of these other projects in the long run. --Dks
Re: L2R/R2L syntax
On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote: > > On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote: > > If the function form of map/grep were to be removed, which has been > > suggested, > > and the <~ form maps to methods. How would you go about defining a > > utility > > module similar to List::Util that uses the same syntax as map/grep but > > without making the subs methods on the global ARRAY package ? > > If you want the method to be available everywhere, But I don't > you probably > _should_ make it a method of the global Array class. Thats like trying to wite a whole perl5 application in main without any packages > More typically, > perhaps, you'd only be using your new method to operate on certain > arrays that you use, in which case you would make a new class for those > particular arrays, so your new method would work only on the specific > arrays you intended it to: Thats not always possible. Those Arrays may be passed to me from somewhere else, so I have no control over thier class. > I don't see any problem (other than maybe a philosophical objection) > with making them methods of Array, though, if they're valuable enough. > That certainly would seem the common Perl thing to do. No, namespaces were invented for a reason. Graham.
Re: Why C needs work (was Re: L2R/R2L syntax)
On Monday, January 20, 2003, at 04:33 PM, Michael Lazzaro wrote:
But both the OO and pipeline syntaxes do more to point out the noun,
verb, and adjective of the operation.
Adverb. The {...} part is an adverb, not an adjective. Sorry there.
MikeL
Re: L2R/R2L syntax
On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote:
If the function form of map/grep were to be removed, which has been
suggested,
and the <~ form maps to methods. How would you go about defining a
utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
If you want the method to be available everywhere, you probably
_should_ make it a method of the global Array class. More typically,
perhaps, you'd only be using your new method to operate on certain
arrays that you use, in which case you would make a new class for those
particular arrays, so your new method would work only on the specific
arrays you intended it to:
class MyArray is Array {
method foo_grep (Code $test) returns MyArray {
...
}
}
my @a is MyArray = (1..10);
my @b = @a.foo_grep {...};
my @c = foo_grep {...} <~ @a; # identical
I don't see any problem (other than maybe a philosophical objection)
with making them methods of Array, though, if they're valuable enough.
That certainly would seem the common Perl thing to do.
MikeL
Re: L2R/R2L syntax
Damian Conway writes:
> Buddha Buck wrote:
> >
> > Perl 5 allows you to do:
> >
> > $object->meth1->meth2->meth3; # Perl5 chained method, L2R
> >
> > Perl 6 will also allow you to do:
> >
> > $data ~> sub1 ~> sub2 ~> sub3;# Perl6 chained subs, L2R
> >
> > Perl 5 allows you to to:
> >
> > sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
> >
> > Perl 6 will also allow you to do:
> >
> > meth3 <~ meth2 <~ meth1 <~ $Xbject # Perl 6 chained methods, R2L
> >
> > All four syntaxes will be available in Perl 6, modulo the fact that '->'
> > is now spelled '.'
> >
> > The additional functionality that when the last sub or method in the ~>
> > and <~ is a variable an assigment is done is a convenience issue.
>
will something like that work ? and how ~> distinguish between = and
:= ?
@source ~> part [
/foo/,
/bar/,
/zap/ ]
~> (@foo,@bar,@zap)
the issue is : what happens if function returns more than one
variables .
It seems that it is not very bad idea to have some special (lexical )
variable similar to $0 for regexes that is set after
grep/part/sort/or_may_be_something_userdefined have done its work and
then ( here $0 is a placeholder for that variable ) :
@source ~> part [
/foo/ => @foo,
/bar/ => @bar
/zap/ => @zap ] ;
$0{'@foo'} ~> map { ... } ~> @foo;
$0{'@bar'} ~> map { ... } ~> @bar;
$0{'@zap'} ~> map { ... } ~> @zap;
but maybe that may be stilll shortened . the idea ( maybe bad ) is to
have "named" or "numbered" (pseudo)pipes similar to having named or
numbered arguments.
@source |> part [
/foo/ => "foo",
/bar/ => "bar"
/zap/ => "zap" ]
|foo> map { ... } |> @foo,
|bar> map { ... } |> @bar,
|zap> map { ... } |> @zap ;
So |foo> is "undone" by perl arranging temporal variable after the
action of part and then feeding this temporal variable to the rest of
pipeline. that also means that |foo> "remembers" the return values
_only_ from the thing on its _closest_ left .
then something like that can be made to work :
@source |> grep { ... }
|ok> map { ... } |> @foo,
|nok> map { ... } |> @bar ;
I am not sure this is a good solution
but I think that "purge" and L2R-R2L threads of this maillist have to
be more close somehow.
arcadi
Re: L2R/R2L syntax
> Date: Tue, 21 Jan 2003 10:04:58 +
> From: Graham Barr <[EMAIL PROTECTED]>
>
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?
I don't know whether you can use multimethods to do it, but if you
can, it would probably go something like this:
sub wonk (@list: &code) is multi {
grep {!code()} <~ @list
}
So C would be called like a method, but still not have access to
C's private attributes as it's not a part of the class.
I don't know whether I like this or not.
Luke
Re: L2R/R2L syntax
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
> > What benefit does C<< <~ >> bring to the language?
>
> Again, it provides not just a "null operator" between to calls, but
> rather a rewrite of method call syntax. So:
>
> map {...} <~ grep {...} <~ @boing;
>
> is not:
>
> map {...} grep {...} @boing;
>
> But rather:
>
> @boing.map({...}).grep({...});
This is not a for or against, but there is something that has been
bugging me about this.
Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util
If the function form of map/grep were to be removed, which has been suggested,
and the <~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
Graham.
Re: L2R/R2L syntax
> Date: 20 Jan 2003 20:30:07 -
> From: Smylers <[EMAIL PROTECTED]>
>
> It seems that when chaining together functions, omitting C<< <~ >>
> operators gives the same result in the familiar Perl 5 standard
> function-call syntax:
>
> @foo = sort { ... } <~ map { ... } <~ grep { ... } <~ @bar;
> @foo = sort { ... } map { ... } grep { ... } @bar;
>
> Left-right pipelines make sense to me. I'm not yet sure how much I'd
> use them, but there are times when I find it a little odd to have data
> flowing 'upstream' in code, and reversing this could be nifty.
Agreed.
> However right-left pipelines don't seem to add much to the language,
> while becoming something else to have to learn and/or explain.
> (Damian's explanation of what C<< <~ >> does to code seemed
> significantly more involved than that of C<< ~> >>.)
It's simple: it's a backwards dot. The invocant goes on the right
and the method and arguments go on the left.
$foo.bar($baz);
-or-
bar $foo: $baz;
is the same as:
bar $baz <~ $foo;
And you see now what this gives us. It gives us the ability to place
the invocant (almost) anywhere we want: On the left, in between, or
on the right. I think it's fortunate that we can't put it between
arguments...
> And an alternative spelling for the assignment operator[*0] doesn't
> strike me as something Perl is really missing:
>
> $msg <~ 'Hello there';
> $msg = 'Hello there';
Yeah, I didn't see much gain in this bit. But it's an expectable
generalization from ~>.
> I realize that there's a symmetry between the two operators, but that
> isn't a convincing reason for having them both. People are used to data
> flow in one direction; it seems reasonable only to have an operator when
> wanting to change this, to make it go in the opposite direction.
>
> What benefit does C<< <~ >> bring to the language?
Again, it provides not just a "null operator" between to calls, but
rather a rewrite of method call syntax. So:
map {...} <~ grep {...} <~ @boing;
is not:
map {...} grep {...} @boing;
But rather:
@boing.map({...}).grep({...});
Which will be defined to mean the same thing, but in many cases this
won't be true. Another example:
print "Starting server\n"<~ open "> $logfile";
The important thing is that it's starting the server, not that it's
writing that to the logfile.
I personally think that this could add something to readability at
times. Maybe not as much as ~>, but every once in a while.
Luke
Why C needs work (was Re: L2R/R2L syntax)
On Monday, January 20, 2003, at 12:30 PM, Smylers wrote:
Ah. It was only on reading that (and discovering that you hadn't
previously known about the 'optional comma with closure argument' rule)
that I understood why you had previously been so in favour of proposed
new syntaxes: through a desire to banish the Perl 5 syntax.
Yes. Again, it's not that I never knew about the perl5 rule, it's that
I _dislike_ the perl5 rule, as I dislike most special-case grammar
rules. If we dropped C, etc., we could drop the inferred-comma
rule as well (unless we're really successful in making C a simple
function, in which case we need the rule anyway, so who cares?)
But the inferred-comma rule is tangential to my dislike of the current
C syntax. I'd dislike C, and like pipelines, even if the
inferred-comma rule wasn't there.
Mike, now you've come to terms with the Perl 5 syntax, do you still
find
right-left pipelines as compelling as you've previously argued?
Yes, very much so. Here's why...
Over the years, I've seen quite a few newbies struggle with the C
syntax; the most frequent mistake is to reverse the order of the
arguments, saying
map @a, {...}
(Another common one is to not understand what C would
do.) There's a couple of reasons for that, IMO, but the wording I
often get when I'm trying to get people to verbalize "what this
statement does" is that "it takes @a, and does to it".
In other words, when newcomers verbalize the statement, they tend to
think of the C as operating on @a. Which is true. You might also
say "it does to @a", which is also true. For many people, the
brain seems to lock around the C<@a> as the most important part of the
statement, not the "blah" part.
Logically, that makes sense. C, C, etc., is an operation on
@a. It's not an operation on the {...} part -- the {...} is just an
adverb describing the "how", which is of lesser importance.
So is there fix for C that wouldn't trip newbies up quite so much?
The simple fix would seem to be to emphasis the "it operates on @a"
part, so that people more easily remember it from the way they
verbalize it. Obviously, an OO style fixes that easily:
@a.map {...};
That's very intuitive to people, esp. new converts from other
languages. And, happily, it's very easy to implement and extend. But
it works only in one direction, L2R. (And, as Damian stated, chaining:
@a.map {...} .sort {...};
probably wouldn't work at all, unless you tossed some parens around all
your curlies. Yuck.)
So fine, we convert C, etc., to be methods of collections, as is
typical programming practice these days. And, in fact, we _are_ doing
that elsewhere in the language. Things like C will become
C<@a.length> or similar. Even subscripts C<[$n]> can have dotted
syntax, e.g. C<.[$n]>. And, presumably, there will be a C<.map>,
C<.grep>, etc.
But in doing that, we lose a lot of functionality -- mainly, the simple
L2R and R2L chaining that we have now. So people want to keep C
as functions, not methods, and use the old syntax. Well, that's OK,
but we're back to the beginning.
< Is there a pipelike solution? >
People like the current C syntax because it allows R2L chaining.
Saying C< @a.map {...} > isn't so onerous that it should send people
reeling, since it's the exact same syntax as the entire rest of the
language. But losing the chaining would hurt, because it's a very
useful feature.
Here's where the pipeline suggestions come in. Looking at a strawman
syntax using '<-', JUST FOR THE SAKE OF IMPARTIAL EXAMPLE:
@out = map {...} <- @a;
That's two (OK, three) characters longer than the old syntax. It could
be described to newcomers as "using @a, do with it".
Essentially, it's a "post-invocant", a reversed way of saying C< @a.map
{...} >. Note that it doesn't rely on the existence of universal
functions -- C is just a method of @a.
Here's the important part: This same syntax will work on ANY object,
and ANY method of that object. So you're removing the specific global
functions C, C, C, etc., and replacing them with a
generic syntax for right-to-left chaining for any operations object.
You don't have to _build_ functions that can support chaining, because
_any_ method can be chained.
And it provides a very visual way to define any pipe-like algorithm, in
either direction:
$in -> lex -> parse -> codify -> optimize -> $out; # L2R
$out <- optimize <- codify <- parse <- lex <- $in; # R2L
It's clear, from looking at either of those, that they represent data
pipes. Both are even clearer than the equiv:
$out = $in.lex.parse.codify.optimize;
Whether you would code a pipeline as L2R or R2L depends on the specific
algorithm you're representing, and is purely a matter of taste...
you'd probably use R2L in the same places as you use C-like
chaining in Perl5. I can't begin to justify why one should be superior
to the other, and would certainly use them both.
So t
Re: L2R/R2L syntax
Michael Lazzaro wrote:
> Damian Conway wrote:
>
> > "you can leave a comma out either side of a block/closure, no matter
> > where it appears in the argument list"
>
> Hmm. I had been figuring the all conditional/loop stuff would be
> special cases within the grammar, because of their associated cruft...
> but if comma-optional is allowed on *either* side of any block, it
> means that their grammar becomes quite trivial.
>
> That wins the less-special-cases war by a mile, so I emphatically
> withdraw my objection.
Ah. It was only on reading that (and discovering that you hadn't
previously known about the 'optional comma with closure argument' rule)
that I understood why you had previously been so in favour of proposed
new syntaxes: through a desire to banish the Perl 5 syntax.
Mike, now you've come to terms with the Perl 5 syntax, do you still find
right-left pipelines as compelling as you've previously argued?
It seems that when chaining together functions, omitting C<< <~ >>
operators gives the same result in the familiar Perl 5 standard
function-call syntax:
@foo = sort { ... } <~ map { ... } <~ grep { ... } <~ @bar;
@foo = sort { ... } map { ... } grep { ... } @bar;
Left-right pipelines make sense to me. I'm not yet sure how much I'd
use them, but there are times when I find it a little odd to have data
flowing 'upstream' in code, and reversing this could be nifty.
However right-left pipelines don't seem to add much to the language,
while becoming something else to have to learn and/or explain.
(Damian's explanation of what C<< <~ >> does to code seemed
significantly more involved than that of C<< ~> >>.) And an alternative
spelling for the assignment operator[*0] doesn't strike me as something
Perl is really missing:
$msg <~ 'Hello there';
$msg = 'Hello there';
I realize that there's a symmetry between the two operators, but that
isn't a convincing reason for having them both. People are used to data
flow in one direction; it seems reasonable only to have an operator when
wanting to change this, to make it go in the opposite direction.
What benefit does C<< <~ >> bring to the language?
Smylers
Re: L2R/R2L syntax
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
> >> From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> >> On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> >>> So 'if' and friends are just (native) subroutines with prototypes
>
> >>> like:
> >> IIRC it's not that pretty, unfortunately, if you want to support
> this:
> > That is not a problem:
>
>
> Yeah, a three-argument form would easily allow chaining. But of
> course
> it still doesn't do the appropriate syntax checking (C outside
> of
> C, etc.). (It's only speculation on our part, of course, but
> Damian's response was quite intriguing -- he seemed to imply they had
> a
> solution that would work.)
I'm not sure that there *IS* much appropriate syntax checking, but you
could (and, I suspect, MUST) easily implement this by constructing
reference objects. (There has to be some kind of stack...)
But consider:
print "foo" if ($bar);
print "baz" else;
*What about THAT, Mr. Fong?*
This looks to me like an infix operator, or a postfix one for else.
Also, the case of C versus C is generally a
"separable-verb" problem:
log $user onto $system.
log $message to $stderr.
l2x = log 2 * log $x; # Don't check my math, please. :-)
Is it worth handling this?
sub log($n) { ... }
sub log _ onto($user; &_ ; $machine) { ... }
sub log _ to($message; &_ ; $stream) { ... }
=Austin
Re: L2R/R2L syntax
Michael Lazzaro wrote:
On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote:
From: "Sean O'Rourke" <[EMAIL PROTECTED]>
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
So 'if' and friends are just (native) subroutines with prototypes like:
IIRC it's not that pretty, unfortunately, if you want to support this:
That is not a problem:
Yeah, a three-argument form would easily allow chaining. But of course
it still doesn't do the appropriate syntax checking (C outside of
C, etc.). (It's only speculation on our part, of course, but
Damian's response was quite intriguing -- he seemed to imply they had a
solution that would work.)
Would this work?
class True is Bool is singleton {
method isTrue(&block) { &block.apply(); };
method isFalse(&block) { };
}
class False is Bool is singleton {
method isTrue(&block) { };
method isFalse(&block) { &block.apply(); };
}
class ElseCode is Code {};
our True true is builtin;
our False false is builtin;
sub if (Bool $test, Code $block) { $test.isTrue($block); };
sub if (Bool $test, Code $ifblock, ElseCode $elseblock)
{ $test.ifTrue($ifblock); $test.ifFalse($elseblock); };
sub unless (Bool $test, Code $block) {$test.isFalse($block);};
sub unless (Bool $test, Code $ifblock, ElseCode $elseblock)
{ $test.ifFalse($ifblock); $test.ifTrue($elseblock); };
sub else (Code $block) returns ElseBlock { $block };
sub elseif (Bool $test is lazy, Code $block)
{ if $test, $block; };
sub elseif (Bool $test is lazy, Code $block, ElseCode $elseblock)
{if $test, $block, $elseblock;};
etc...
Re: L2R/R2L syntax
On Monday, January 20, 2003, at 09:37 AM, Luke Palmer wrote:
Is this magic, or do coderef args construct closures, or what? How do
you avoid evaluating the argument to elsunless() when feeding it to
the
if() sub?
Oops. Good point. In this case I see no way of doing it except for
specifying magic:
sub elsunless ($test is lazy, â–ˆ &follow) {
!$test ?? block() :: follow()
}
Right, but it's acceptable magic (magic that would be used for any
subs, not just the , C, etc.) Not grammar-level magic
special to conditionals.
MikeL
Re: L2R/R2L syntax
On Sunday, January 19, 2003, at 09:51 PM, Luke Palmer wrote: From: "Sean O'Rourke" <[EMAIL PROTECTED]> On Sat, 18 Jan 2003, Michael Lazzaro wrote: So 'if' and friends are just (native) subroutines with prototypes like: IIRC it's not that pretty, unfortunately, if you want to support this: That is not a problem: Yeah, a three-argument form would easily allow chaining. But of course it still doesn't do the appropriate syntax checking (C outside of C, etc.). (It's only speculation on our part, of course, but Damian's response was quite intriguing -- he seemed to imply they had a solution that would work.) And it still suffers from the semicolon problem, as Sean pointed out. A *big* semicolon problem (sigh). MikeL
Re: L2R/R2L syntax
> Date: Mon, 20 Jan 2003 09:20:45 -0800 (PST)
> From: Austin Hastings <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
>
> --- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > > Date: Sat, 18 Jan 2003 15:07:56 -0800 (PST)
> > > From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> > > Cc: Damian Conway <[EMAIL PROTECTED]>,
> > > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > > X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
> > >
> > > On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> > > > So 'if' and friends are just (native) subroutines with prototypes
> > like:
> > > >
> > > >sub if (bool $c, Code $if_block) {...};
> > >
> > > IIRC it's not that pretty, unfortunately, if you want to support
> > this:
> > >
> > > if $test1 {
> > > # blah
> > > } elsunless $test2 {
> > > # ...
> > > }
> >
> > Ahh, you used the unmentionable _correctly_, unlike so many who
> > misunderstood some six months ago.
> >
> > > since that gets parsed as
> > >
> > > if($test1, { ... }) # aiee: too many arguments to "if"
> >
> > That is not a problem:
> >
> > # We'll just pretend that dereferencing the "undef" sub does
> > nothing
> >
> > sub if ($test, â–ˆ &follow) {
> > # ... er, how do you write "if"? Hmm...
> > $test ?? block() :: follow()
> > }
> >
> > sub elsunless ($test, â–ˆ &follow) {
> > !$test ?? block() :: follow()
> > }
> >
> > So:
> >
> > if $test1 {
> > # stuff
> > }
> > elsunless $test2 {
> > # stuff 2
> > }
> >
> > Becomes (semantically):
> >
> > if($test1, {
> > # stuff
> > }, elsunless($test2, {
> > # stuff 2
> > }));
>
> Is this magic, or do coderef args construct closures, or what? How do
> you avoid evaluating the argument to elsunless() when feeding it to the
> if() sub?
Oops. Good point. In this case I see no way of doing it except for
specifying magic:
sub elsunless ($test is lazy, â–ˆ &follow) {
!$test ?? block() :: follow()
}
Or something like that. Darn.
Luke
Re: L2R/R2L syntax
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Date: Sat, 18 Jan 2003 15:07:56 -0800 (PST)
> > From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> > Cc: Damian Conway <[EMAIL PROTECTED]>,
> > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
> >
> > On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> > > So 'if' and friends are just (native) subroutines with prototypes
> like:
> > >
> > >sub if (bool $c, Code $if_block) {...};
> >
> > IIRC it's not that pretty, unfortunately, if you want to support
> this:
> >
> > if $test1 {
> > # blah
> > } elsunless $test2 {
> > # ...
> > }
>
> Ahh, you used the unmentionable _correctly_, unlike so many who
> misunderstood some six months ago.
>
> > since that gets parsed as
> >
> > if($test1, { ... }) # aiee: too many arguments to "if"
>
> That is not a problem:
>
> # We'll just pretend that dereferencing the "undef" sub does
> nothing
>
> sub if ($test, â–ˆ &follow) {
> # ... er, how do you write "if"? Hmm...
> $test ?? block() :: follow()
> }
>
> sub elsunless ($test, â–ˆ &follow) {
> !$test ?? block() :: follow()
> }
>
> So:
>
> if $test1 {
> # stuff
> }
> elsunless $test2 {
> # stuff 2
> }
>
> Becomes (semantically):
>
> if($test1, {
> # stuff
> }, elsunless($test2, {
> # stuff 2
> }));
Is this magic, or do coderef args construct closures, or what? How do
you avoid evaluating the argument to elsunless() when feeding it to the
if() sub?
=Austin
Re: L2R/R2L syntax
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Sat, 18 Jan 2003 15:07:56 -0800 (PST)
> From: "Sean O'Rourke" <[EMAIL PROTECTED]>
> Cc: Damian Conway <[EMAIL PROTECTED]>,
> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> > So 'if' and friends are just (native) subroutines with prototypes like:
> >
> >sub if (bool $c, Code $if_block) {...};
>
> IIRC it's not that pretty, unfortunately, if you want to support this:
>
> if $test1 {
> # blah
> } elsunless $test2 {
> # ...
> }
Ahh, you used the unmentionable _correctly_, unlike so many who
misunderstood some six months ago.
> since that gets parsed as
>
> if($test1, { ... }) # aiee: too many arguments to "if"
That is not a problem:
# We'll just pretend that dereferencing the "undef" sub does nothing
sub if ($test, â–ˆ &follow) {
# ... er, how do you write "if"? Hmm...
$test ?? block() :: follow()
}
sub elsunless ($test, â–ˆ &follow) {
!$test ?? block() :: follow()
}
So:
if $test1 {
# stuff
}
elsunless $test2 {
# stuff 2
}
Becomes (semantically):
if($test1, {
# stuff
}, elsunless($test2, {
# stuff 2
}));
Luke
Re: L2R/R2L syntax
--- Sean O'Rourke <[EMAIL PROTECTED]> wrote:
> On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> > So 'if' and friends are just (native) subroutines with prototypes like:
> >
> >sub if (bool $c, Code $if_block) {...};
>
> IIRC it's not that pretty, unfortunately, if you want to support this:
>
> if $test1 {
> # blah
> } elsunless $test2 {
> # ...
> }
>
> since that gets parsed as
>
> if($test1, { ... }) # aiee: too many arguments to "if"
>
> One possible solution would be to say that there's an implicit "whatever
> we need" after a closed curly. In that case there are two ways to go:
> (1) we can define things like "if" to be statements rather than
> expressions (a la C), and closed-curlies as the last arguments of
> "statement-like" functions can always have an implicit ";"; or (2) we can
> say that "}" results in an implicit ";" whenever we're at the end of an
> argument list and see a term rather than an operator. I think we turned
> up some nasty ambiguities with (2) last time we discussed this. It would
> certainly wreak havoc with unary minus.
>
> The other way is the "newline after curly" rule, which has a foul taste
> for those of us who cuddle our ifs.
>
> /s
>
Or we could just make if/unless/elsif/else special keywords. Not everything
needs to be a function.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax
On Sat, 18 Jan 2003, Michael Lazzaro wrote:
> So 'if' and friends are just (native) subroutines with prototypes like:
>
>sub if (bool $c, Code $if_block) {...};
IIRC it's not that pretty, unfortunately, if you want to support this:
if $test1 {
# blah
} elsunless $test2 {
# ...
}
since that gets parsed as
if($test1, { ... }) # aiee: too many arguments to "if"
One possible solution would be to say that there's an implicit "whatever
we need" after a closed curly. In that case there are two ways to go:
(1) we can define things like "if" to be statements rather than
expressions (a la C), and closed-curlies as the last arguments of
"statement-like" functions can always have an implicit ";"; or (2) we can
say that "}" results in an implicit ";" whenever we're at the end of an
argument list and see a term rather than an operator. I think we turned
up some nasty ambiguities with (2) last time we discussed this. It would
certainly wreak havoc with unary minus.
The other way is the "newline after curly" rule, which has a foul taste
for those of us who cuddle our ifs.
/s
Re: Civility, please. (was Re: L2R/R2L syntax)
Sam Vilain wrote: On Sat, 18 Jan 2003 15:10, you wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Perhaps in the grand scheme of things; however, anyone that is redesigning a system should not be ignorant of how the old system worked (even in the slightest degree), in order to know of what to keep and what to throw away. Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. Ignorant of what? Surely we shouldn't assume that we're all ignorant of Perl? Joseph F. Ryan [EMAIL PROTECTED]
Re: L2R/R2L syntax
On Friday, January 17, 2003, 6:35:47 PM, you (mailto:[EMAIL PROTECTED]) wrote: > On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: >> [EMAIL PROTECTED] (Mr. Nobody) writes: >> > I have to wonder how many people actually like this syntax, and how many only >> > say they do because it's Damian Conway who proposed it. And map/grep aren't >> > "specialized syntax", you could do the same thing with a sub with a prototype >> > of (&block, *@list). >> >> Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, >> adding syntax for the sake of syntax, doesn't do anything for the readability >> of code, and doesn't really actually gain very much anyway. > That I will agree with to some extent. But mainly because I think > that IF a pipe-like syntax is added then it should do just that, > pipe. What has been proposed is not a pipe, unless each part gets > converted to a co-routine and its arguments are really an interator > that calls the previous stage to get the next argument. Actually I think this is a *very* good idea (and far more important that arrays). If . pretty much all the operations proposed for arrays and/or lists are actually operations on iterators. . arrays and lists convert to iterators freely . lazy lists are just an iterator without an end point then a whole pile of complexity and special cases can be removed. After all, grep (etc.) just keep asking the iterator for more elements until one matches the condition, when it has been asked by the next upstream element to generate the next element. Thus lazy lists become the norm and the only time the whole pipeline is actually processed is when something forces it (like printing it out, or getting the size of the resultant list). The only real exception is that an infinite iterator (as created by 1..inf) would need to generate an error in this case. -- Richard mailto:[EMAIL PROTECTED]
Re: L2R/R2L syntax
Michael Lazzaro wrote:
Suppose I wanted to do something like:
sub draw_triangle( Point $a, Point $b, Point $c );
-and-
sub draw_triangle( int $x1,$y1, int $x2,$y2, int $x3,$y3 );
Err. Why would you only want the X parameters to be explicitly typed?
I suspect you mean:
sub draw_triangle(int $x1, int $y1, int $x2, int $y2, int $x3, int $y3);
-and-
(every conceivable combination of those damn arguments)
Would the currently-pondered multimethod syntax support anything roughly
analogous to the pseudocode:
sub draw_triangle(
( Point $a | int $x1,$y1 -> Point.new($x1,$y1) ),
( Point $b | int $x2,$y2 -> Point.new($x2,$y2) ),
( Point $c | int $x3,$y3 -> Point.new($x3,$y3) )
) {
... stuff using $a, $b, $c ...
}
such that I don't need 2^3 separate damn prototypes of C?
Probably not. To solve this particular problem, I'd specify that pairs
of X/Y coordinates need to be passed as...well...pairs:
sub draw_triangle ( Point|Pair $a is copy,
Point|Pair $b is copy,
Point|Pair $c is copy) {
when Pair {$_ = Point.new(.key,.value)} for $a, $b, $c;
...
}
draw_triangle($p1, 3=>4, $p2)
Sorry for this question, but this is one of the Big Ones that's been
bugging me for quite some time. Frequently (usually?), multimethods are
built such that there is one "true" case, and all other variations are
utterly minor derivations of that case...
That's so. But your proposed solution relies on us being able to define tuple
types, and I'm not sure we're planning a type system strong enough for that.
If we *were* (and I'm not saying we're even considering it!), I imagine your
example would become something like:
class XY is Tuple(int, int);
sub draw_triangle ( Point|XY $a is copy,
Point|XY $b is copy,
Point|XY $c is copy) {
when Pair {$_ = Point.new(@$_)} for $a, $b, $c;
...
}
draw_triangle($p1, (3,4), $p2)
Damian
Re: L2R/R2L syntax
Damian Conway wrote:
> Piers Cawley wrote:
> > I really don't like that fine grained syntax I'm afraid. And I'm not
> > entirely sure you actually gain anything from it do you?
>
> That's one of the questions we're still pondering.
Suppose I wanted to do something like:
sub draw_triangle( Point $a, Point $b, Point $c );
-and-
sub draw_triangle( int $x1,$y1, int $x2,$y2, int $x3,$y3 );
-and-
(every conceivable combination of those damn arguments)
Would the currently-pondered multimethod syntax support anything roughly
analogous to the pseudocode:
sub draw_triangle(
( Point $a | int $x1,$y1 -> Point.new($x1,$y1) ),
( Point $b | int $x2,$y2 -> Point.new($x2,$y2) ),
( Point $c | int $x3,$y3 -> Point.new($x3,$y3) )
) {
... stuff using $a, $b, $c ...
}
such that I don't need 2^3 separate damn prototypes of C?
Sorry for this question, but this is one of the Big Ones that's been
bugging me for quite some time. Frequently (usually?), multimethods are
built such that there is one "true" case, and all other variations are
utterly minor derivations of that case...
MikeL
Re: L2R/R2L syntax
Damian Conway wrote:
> If the rule was, "you can leave a comma out either side of a block/closure,
> no matter where it appears in the argument list", it would also be more
> consistent.
>
> And that's what's being contemplated. Because otherwise, you also have
> to have:
>
> for @list, {...}
> if $condition, {...}
> given $value, {...}
> :-(
Hmm. I had been figuring the all conditional/loop stuff would be
special cases within the grammar, because of their associated cruft...
but if comma-optional is allowed on *either* side of any block, it means
that their grammar becomes quite trivial.
So 'if' and friends are just (native) subroutines with prototypes like:
sub if (bool $c, Code $if_block) {...};
or whatever the heck the syntax turns out to be.
That wins the less-special-cases war by a mile, so I emphatically
withdraw my objection. Thanks.
MikeL
Re: L2R/R2L syntax
Piers Cawley wrote:
I really don't like that fine grained syntax I'm afraid. And I'm not
entirely sure you actually gain anything from it do you?
That's one of the questions we're still pondering. But see below.
I also find myself wondering if functions called with:
$foo.bar($baz)
should be *required* to be singly dispatched on $foo and saying that
mulitply dispatched functions/generics/whatever should look like
normal function calls:
bar($foo, $baz); # May be multiply dispatched
I would say that only Cs can be called with the
$obj.foo($arg)
syntax (or one of its variants) and only subroutines with the:
foo($arg, $arg)
syntax (or its variant).
However, the way in which either call is *dispatched* (i.e. statically,
polymorphically, or multimorphically) is utterly orthogonal to the way it's
*called*. Thus I can readily imagine:
sub foo($param1, $param2) {...} # statically dispatched subroutine
vs:
sub foo($param1: $param2) {...} # polymorphically dispatched sub
vs:
sub foo($param1: $param2:) {...} # multimorphically dispatched sub
and:
method bar($self: $param) {...} # polymorphically dispatched method
vs:
method bar($self: $param:) {...} # multimorphically dispatched method
where C must always called as:
foo( $arg1, $arg2 );
and C must always called as:
$obj.bar($arg);
irrespective of the way in which those calls are ultimately dispatched.
Damian
Re: L2R/R2L syntax
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>>>Multimethods don't belong to classes; they mediate interactions
>>>*between* classes.
>> Will the 'is multi' actually be necessary? Just curious.
>
> That's still being discussed. *Something* is necessary. But it may
> be that, instead of:
>
> sub handle (Window $w, Event $e, Mode $m) is multi {...}
>
> one will write:
>
> sub handle (Window $w: Event $e: Mode $m:) {...}
>
> That is, if it's a C (or a method, for that matter) and
> you specify that it has multiple invocants, then it's a multimethod.
>
> The advantage, of course, is that this potential syntax confers much
> finer control over which parameters participate in the multiple
> dispatch. For example, if that had been:
>
> sub handle (Window $w: Event $e, Mode $m:) {...}
>
> then the dispatch would only be polymorphic with respect to
> $w and $m.
>
> The *disadvantage* of this syntax is that it confers much finer
> control over which parameters participate in the multiple dispatch --
> which may make it harder to achieve predictable dispatch behaviours
> for specific multimethods.
>
> Another disadvantage is that it's easier to miss those trailing colons
> (or confuse them with semicolons), whereas an explicit C is a
> much clearer signal of intent.
I really don't like that fine grained syntax I'm afraid. And I'm not
entirely sure you actually gain anything from it do you?
Another option,
sub handle (Window $w, Event $e, Mode $m) is dispatched($w, $m) {...}
is explicit, but disgusting.
I also find myself wondering if functions called with:
$foo.bar($baz)
should be *required* to be singly dispatched on $foo and saying that
mulitply dispatched functions/generics/whatever should look like
normal function calls:
bar($foo, $baz); # May be multiply dispatched
But I can't begin to offer reasons for this beyond a vague gut
feeling.
Re: L2R/R2L syntax
Piers Cawley wrote:
Multimethods don't belong to classes; they mediate interactions
*between* classes.
Will the 'is multi' actually be necessary? Just curious.
That's still being discussed. *Something* is necessary. But it may
be that, instead of:
sub handle (Window $w, Event $e, Mode $m) is multi {...}
one will write:
sub handle (Window $w: Event $e: Mode $m:) {...}
That is, if it's a C (or a method, for that matter) and
you specify that it has multiple invocants, then it's a multimethod.
The advantage, of course, is that this potential syntax confers much finer
control over which parameters participate in the multiple dispatch. For
example, if that had been:
sub handle (Window $w: Event $e, Mode $m:) {...}
then the dispatch would only be polymorphic with respect to
$w and $m.
The *disadvantage* of this syntax is that it confers much finer control over
which parameters participate in the multiple dispatch -- which may make it
harder to achieve predictable dispatch behaviours for specific multimethods.
Another disadvantage is that it's easier to miss those trailing colons
(or confuse them with semicolons), whereas an explicit C is a
much clearer signal of intent.
So we're still considering the matter.
Damian
Re: L2R/R2L syntax
Dave Whipp wrote: And note that as pretty as -> is, we couldn't have <- for piping because it would conflict rather strongly things like if ($a<-5)# (negative five, or pipelike?) Its resolved by the "longest token" rule, but it would be a common bug. So it would be a potential problem. Worse still, -> is not available at all, being already in use for "pointy sub". Otherwise, using -> and <- would be ideal. Especially since then $foo->bar and $foo.bar are exactly equiv, helping perl5 people. Ah, well. :-/ Not exactly equivalent: C would have a higher precedence than ->: Not equivalent at all. C<$foo~>bar> means "append $foo to the argument list of subroutine C". C means "make C<$foo> the invocant for method ". Curiously enough, the confusions I'm hearing over this issue are, to me, the strongest argument yet for using Andy's |> and <| symbols instead. Damian
Re: L2R/R2L syntax
"Mr. Nobody" <[EMAIL PROTECTED]> writes:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>>
>> On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
>> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
>> >> ...the absence of the commas is what's special. If they were normal
>> >> functions/subroutines/methods/whatever, you would need a comma after
>> >> the first argument
>> >
>> > This is plainly untrue. See the "perlsub" documentation, which talks
>> > about
>> > "creating your own syntax" with the & prototype. You can do all this in
>> > Perl 5, and it saddens me that some of the people redesigning Perl
>> > don't
>> > know what Perl can do.
>>
>> No. I said it was _special_, not _impossible_. You're "creating your
>> own syntax" -- that's exactly my point. C, etc. are using an
>> invocation syntax _slightly_ different from the vast majority of other
>> cases -- one that skips a comma. Yes, it's a special case that exists
>> because of the prototype and the special case caused by '&', which is a
>> special case precisely so that there can be *any* way to emulate the
>> special case C syntax. But whether we like the perl5 C
>> syntax or not, we should at least recognize that it's not regular.
>
> The & syntax is going to be special no matter what. It has the power to turn
> a bare block into a subref:
>
> sub foo ($x) { }
> sub bar (&x) { }
> foo { }; # hash
> bar { }; # sub
Have you been reading the Apocalypses? Both of those are blocks, as
discussed in (I think) Apocalypse 2.
Re: L2R/R2L syntax
Damian Conway <[EMAIL PROTECTED]> writes:
> Brent Dax asked:
>
>> So
>> @a ~> grep { ... } ~> @b
>> Is the same as
>> @b = grep { ... } @a
>
> Yes.
>
>
>
>> As in...
>> class Array {
>> ...
>> method grep (Array $ary: Code $code) returns Array {
>> ...
>> }
>>
>> method grep (Code $code: Array $ary) returns Array {
>> ...
>> }
>> }
>
> No. As in:
>
> sub grep (Code|Hash $selector, *@candidates) is multi {...}
>
> class Array {
> ...
> method grep(Array $self: *@candidates) {...}
> }
>
> Multimethods don't belong to classes; they mediate interactions
> *between* classes.
Will the 'is multi' actually be necessary? Just curious.
Re: Civility, please. (was Re: L2R/R2L syntax)
On Sat, 18 Jan 2003 15:10, you wrote: > [EMAIL PROTECTED] (Michael Lazzaro) writes: > > I don't think any aspect > > of this discussion is hinged on people being 'ignorant' of perl5 > > behaviors, > Oh, I do, and you've dismissed that argument out of hand. This isn't > name-calling; this is a plea for Perl 6 not to become a language > designed by a committee of ignorant amateurs. The Lord knows that > languages designed by committees of professional standards-writers are > pretty bad, and we're still a long way from that. In the very young field of programming, aren't we all ignorant amateurs? Any programmer who doesn't know that they are ignorant are almost certainly instead arrogant. -- Sam Vilain, [EMAIL PROTECTED] You're either part of the solution, or part of the precipitate. - George W. Bouche, renowned chemist.
Re: L2R/R2L syntax
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > And note that as pretty as -> is, we couldn't have <- for piping > because it would conflict rather strongly things like > > if ($a<-5)# (negative five, or pipelike?) Its resolved by the "longest token" rule, but it would be a common bug. So it would be a potential problem. <~ is equally ambiguous, but unary tilde is less common than unary minus. So squiggly-arrows might be better from that point of view. If we used straight arrays, then we might want to prefer the "unary-minus" interpretation in the parser, and thus require whitespace. > Otherwise, using -> and <- would be ideal. Especially since then > > $foo->bar >and > $foo.bar > > are exactly equiv, helping perl5 people. Ah, well. :-/ Not exactly equivalent: C would have a higher precedence than ->: Dave.
Re: L2R/R2L syntax
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Mr. Nobody:
> # I have to wonder how many people actually like this syntax,
> # and how many only say they do because it's Damian Conway who
> # proposed it. And map/grep aren't "specialized syntax", you
>
> IIRC Damian also supports Unicode operators (and may have originated the
> idea), and obviously many people don't like them.
>
> # could do the same thing with a sub with a prototype of
> # (&block, *@list).
>
> Great. That could mean it won't work right for
> MyCustomArrayLikeThing.
Actually, it will, as I have discussed the LAST TIME this bloody
subject came up. Multiple dispatch is your friend.
map (&block, *@list) { @list.map(&block) }
map (&block, @array) { @array.map( &block ) }
etc. Remember most of this will be set up by default anyway, when you
come to implement MyCustomArrayLikeThing you *may* have to add a few
function definitions, or the fact that MyCustomArrayLikeThing inherits
form Array may just fix it for you anyway.
Re: L2R/R2L syntax
Michael Lazzaro wrote:
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it from the next arg.
If the rule was, "you can leave the comma out after any argument, no
matter what type", it would be more consistent. (But a nightmare.)
If the rule was, "you can never leave the comma out", it would be more
consistent. (But cost one more character.)
If the rule was, "you can leave a comma out either side of a block/closure,
no matter where it appears in the argument list", it would also be more
consistent.
And that's what's being contemplated. Because otherwise, you also have
to have:
for @list, {...}
if $condition, {...}
given $value, {...}
:-(
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
Without comma-optionality, their other p6 magic will be much less wonderous.
Damian
Re: L2R/R2L syntax
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it from the next arg.
If the rule was, "you can leave the comma out after any argument, no
matter what type", it would be more consistent. (But a nightmare.)
If the rule was, "you can never leave the comma out", it would be more
consistent. (But cost one more character.)
I'm not saying it's awful, and I'm not saying it's impossible. I'm
*just* saying that p6 does not have that syntax, _UNLESS_ it is given a
similar comma-sucking rule. So, should there be such a rule?
I am contesting the net benefit of the rule for p6. My objections:
1) It's a special case, which is by definition something to be generally avoided.
2) The commaless syntax looks enough like indirect object syntax to
confuse many people. Indirect object syntax (the colon form) is already
creating a lot of confusion, and I'm worried this rule would make
matters worse.
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
4) We have several ways around it: direct object syntax, indirect object
syntax, and pipelike syntax.
This is the sum total of my argument against the perl5 map syntax. May
Larry have mercy on my soul.
:-/
MikeL
Re: L2R/R2L syntax [x-adr][x-bayes]
On Sat, Jan 18, 2003 at 02:11:37AM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Paul Johnson) writes: > > That may well be true, but it seems to me that if people's jobs depend > > on those projects then there is (or could be or should be) a source of > > funding available, should such be required, namely the companies who are > > (hopefully) making a profit on the backs of those projects. Hey! You carefully elided my disclaimer. > And to what organisation do you suggest such companies make a donation in > order to make best use of that funding? It seems to me that TPC would be the perfect vehicle for any company wishing to fund a specific Perl project. Previous disclaimer still applies. But now we are off topic. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Civility, please. (was Re: L2R/R2L syntax)
Simon Cozens wrote: This isn't name-calling; this is a plea for Perl 6 not to become a language > designed by a committee of ignorant amateurs. Fortunately there is absolutely no chance of that. Perl 6 is a language being designed by exactly one person. And he's neither ignorant, nor an amateur. The rest of us are merely offering suggestions, feedback, and advice. It's important to remember that Larry loves Perl more than any of us, and that he's not about to be seduced into butchering it by the wild suggestions of so-called "ignorant amateurs". Though, of course, he would never *dream* of using that term himself (except perhaps as a profound compliment). On the other hand, I know that Larry cherishes all the "ignorant amateur" suggestions he receives. Because they help him explore the design space. Because they spark counter-ideas. And because they so often encode -- albeit sometimes very cyptically -- truly guileless expressions of real problems that real Perl users experience. Larry is well-known for extracting the nutritional value from these encodings (i.e. the underlying needs and desires they highlight) without swallowing the unpalatable packaging they sometimes come in. It's instructive to review the PSA ratings of the RFCs covered by the first six Apocalypses and consider the fact that Larry almost always rates the problem space addressed by an individual RFC much higher than the solution it proposes. And *then* typically goes on to describe an alternate approach that solves the problem better and far more generally. Personally, I think we're in safe hands. Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
[EMAIL PROTECTED] (Paul Johnson) writes: > That may well be true, but it seems to me that if people's jobs depend > on those projects then there is (or could be or should be) a source of > funding available, should such be required, namely the companies who are > (hopefully) making a profit on the backs of those projects. And to what organisation do you suggest such companies make a donation in order to make best use of that funding? -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken
Re: L2R/R2L syntax [x-adr][x-bayes]
[EMAIL PROTECTED] (Damian Conway) writes: > True. But I suspect that TPF's position is that, to many people, Perl 6 is > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or > PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the > Slashcode, or any of a hundred other projects on which their job > depends on a daily basis. Amen to that. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Re: Civility, please. (was Re: L2R/R2L syntax)
[EMAIL PROTECTED] (Michael Lazzaro) writes: > I don't think any aspect > of this discussion is hinged on people being 'ignorant' of perl5 > behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Michael Lazzaro) writes: > No. I said it was _special_, not _impossible_. You said in Perl 5 it was X instead of Y. But it turned out to be Y after all. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: L2R/R2L syntax [x-adr][x-bayes]
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > True. But I suspect that TPF's position is that, to many people, Perl 6 is > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, > or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or > any of a hundred other projects on which their job depends on a daily basis. That may well be true, but it seems to me that if people's jobs depend on those projects then there is (or could be or should be) a source of funding available, should such be required, namely the companies who are (hopefully) making a profit on the backs of those projects. Yes, I know it's not that easy. No one's job depends on Perl 6 or Parrot (yet). Well, hardly anyone's :) Still, I suppose I am preaching to the choir in the wrong chapel. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax [x-adr][x-bayes]
Paul Johnson wrote: Well, I'll be pretty interested to discover what cause is deemed more deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, right? True. But I suspect that TPF's position is that, to many people, Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of a hundred other projects on which their job depends on a daily basis. Supporting those efforts is important too, and TPF has only limited resources. Of course, it's my belief that supporting Larry (and Dan) to create Perl 6 is the single most important thing that TPF could do. Because, ultimately, it will benefit all those other projects enormously too. But I'm clearly biased. :-) Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
On Fri, Jan 17, 2003 at 03:10:48PM -0800, Damian Conway wrote: > It's my understanding that TPF is not intending to offer Larry (or Dan) > another grant for 2003. They feel that too many people have come to see > TPF's role and contribution to have been limited to Perl 6 (though > funding Dan was in fact supporting the much broader benefits of Parrot > development and funding me probably benefitted Perl 5 even more than Perl > 6). Well, I'll be pretty interested to discover what cause is deemed more deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, right? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Civility, please. (was Re: L2R/R2L syntax)
On Friday, January 17, 2003, at 02:17 PM, Joseph F. Ryan wrote: Mark J. Reed wrote: On 2003-01-17 at 19:00:04, Simon Cozens wrote: This is plainly untrue. See the "perlsub" documentation, which talks about "creating your own syntax" with the & prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. Well, if even some of the people redesigning the language are ignorant of some of its capabilities, that is an argument for making those capabilities easier to discover, and maybe even more intuitive to use, in the new design. I see it more as the people who are ignorant of the features of Perl5 should go RTFM (Research The Features that they are Making?) 'kay, let it be noted that I had let that first little zing slide, but I do think we need to be more careful here. I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, unless 'ignorant' is a new synonym for 'disagree with'. Argument by emotion has drawbacks. I could, for example, point out that everyone bitches about how the language needs to be more regular, until you point out an irregularity that they like. Or that people want the language to be cleanly object oriented, unless it means making things act more like objects. And Lord help us if we get into an argument about whether or not putting code on CPAN makes you more of an 'expert' programmer than someone who writes proprietary code for money. Or what 'expert' means, when it comes to Perl, and whether or not such technical prowess is solely proportional to your visibility at Perl-related conferences. Or if Perl5 syntax is truly the pinnacle of language design against no other ideas can hold a candle. So. If people wanted to point out the merits of the old C syntax, _aside_ from the fact that Perl5-did-it-that-way, that would be wonderful. But name-calling needs to go. Let's not light that fuse, OK? :-| MikeL
Re: L2R/R2L syntax
Brent Dax asked:
So
@a ~> grep { ... } ~> @b
Is the same as
@b = grep { ... } @a
Yes.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
No. As in:
sub grep (Code|Hash $selector, *@candidates) is multi {...}
class Array {
...
method grep(Array $self: *@candidates) {...}
}
Multimethods don't belong to classes; they mediate interactions *between* classes.
? And this would automagically get mapped into Array::grep?
No. Both would be explicitly and separately defined.
(Reminds me of C++ operator overloading for e.g. "operator +(int,
MyStringType)"...)
Which is *exactly* why we're doing it slightly differently. ;-)
Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
We should bear in mind that Larry has had some health issues. And that he's currently unemployed with four children to support. Other matters are taking precedence at the moment. Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as soon see a grant set up for Larry again this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. It's my understanding that TPF is not intending to offer Larry (or Dan) another grant for 2003. They feel that too many people have come to see TPF's role and contribution to have been limited to Perl 6 (though funding Dan was in fact supporting the much broader benefits of Parrot development and funding me probably benefitted Perl 5 even more than Perl 6). However, I am sure they would welcome feedback on what the community would actually like to donate towards: http://www.perlfoundation.org/index.cgi?page=contacts If so, I'm pretty sure I'll be able to match last years' contribution. [People may not realize what a very generous offer that is. Garrett has been a *major* contributer in the past. And, unless he's living in a parallel economic dimension, funds must be tighter this year.] Damian
RE: L2R/R2L syntax
Damian Conway:
# What ~> and <~ do is to (respectively) allow arguments and
# invocants to appear in a different position to normal:
# arguments to the left of the subroutine/method name, and
# invocants to the right of the method's argument list.
#
# So, for subroutine arguments, these are exactly equivalent:
#
# ($arg2, $arg3, $arg4) ~> subname $arg1;
# subname ($arg1, $arg2, $arg3, $arg4);
So
@a ~> grep { ... } ~> @b
Is the same as
@b = grep { ... } @a
?
# Notice that, in addition to pipelines, these proposed
# operators give us MTOWTDI with respect to ordering of the
# components of a sub or method call. That is, Perl 6
# subroutines may have prefix and/or postfix argument lists,
# and Perl 6 methods may have invocants that are any(prefix,
# infix, postfix).
...
# Yes. And the inference that most people seem to have drawn
# is that this implies that Perl 6 would still have
# "stand-alone" C and C functions.
#
# However, I suspect the correct inference is that Perl 6 will
# have C and C *multimethods*.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
? And this would automagically get mapped into Array::grep? (Reminds
me of C++ operator overloading for e.g. "operator +(int,
MyStringType)"...)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
RE: L2R/R2L syntax
Damian Conway:
# > Brent Dax wrote:
# >> Incorrect.
# No. Your reading was correct. This is a rare case of Brent
# being mistaken.
Ack, sorry to both you and Buddha, and anyone else I inadvertently
confused. Well, at least I'm good enough for this to be considered a
"rare" case. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
RE: L2R/R2L syntax [x-adr][x-bayes]
From: Damian Conway [mailto:[EMAIL PROTECTED]] > > We should bear in mind that Larry has had some health issues. > And that he's currently unemployed with four children to support. > Other matters are taking precedence at the moment. Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as soon see a grant set up for Larry again this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. If so, I'm pretty sure I'll be able to match last years' contribution. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: L2R/R2L syntax
On 2003-01-17 at 17:17:03, Joseph F. Ryan wrote:
> >But as I see it, the real problem being solved by the new syntax
> >is that grep and map can exist solely as methods on some class
> >in the inheritance tree of @arrays, no global functions required.
> >That is a Good Thing.
> >
>
> In your opinion. I'll still want to be able to write 1-liners and
> short scripts. I'm sure perl6 will still be used for things other
> than large applications. Is it such a sin to want the old syntax?
Of course not. Nor is anybody arguing against the utility of
1-liners and short scripts, or the desirability of maintaining
Perl's usefulness for such.
> Even if the definition for grep lives in a method, why couldn't
> there also exist a global function that looks like:
>
> sub grep(&code,@array) {
>@array.grep(&code);
> }
In that scenario, if you wanted to alter the behavior of grep, you
could probably get away with just modifying the array method, but
some modifications might require changing the function, too. Having
to change something in two places is generally a bad thing.
> Or even if this function does not exist, there's nothing stopping
> the compiler from simply aliasing:
>
> grep {} @array;
Yes, but the goal is to avoid special cases. If these:
grep {expr} @array
map {expr} @array
become these:
@array.grep({expr})
@array.map({expr})
that violates the standard interpretation of such sequences. The
"indirect object" syntax (assuming that were inferred despite the
lack of a colon) would instead interpret them as this:
{expr}.grep(@array)
{expr}.map(@array)
While if we inverted the IO interpretation of the syntax, then this:
print $STDERR foo
would become this:
foo->print($STDERR)
What we're looking for is a way to keep something close to
the old syntax, but in a more generally applicable way.
Why? Because general rules are, in general (:)), better than special
cases, simply because they result in less stuff to remember. It's true
that you often have to violate that principle to get good usability, and
Perl is the archetypical example of willingness to do so, but that doesn't
mean that the principle itself is bad. It just can be overdone
(and TCL would be my candidate for the archetypical example of overdoing
it).
All that said, one other thing for both sides of this argument to remember
is this: if the final syntax is not to our liking, then there's
nothing to stop us from writing our own - as a global function or whatever.
And there's likely to be a module that supplies the alternative syntax
anyway, possibly even bundled with the distribution.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax
Buddha Buck wrote:
Brent Dax wrote:
Incorrect.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~> takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~> grep {...} ~> map {...} ~> sort;
I didn't read that as stating a semi-equivalence between '~>' and '.'.
I guess I live and learn.
No. Your reading was correct. This is a rare case of Brent being mistaken.
Damian
Re: L2R/R2L syntax
Buddha Buck wrote:
My impression was that ~> and <~ were more general than that, and mainly
did syntax-rewriting.
You can certainly think of it as syntax rewriting
(though, personally, I don't).
What ~> and <~ do is to (respectively) allow arguments and invocants to
appear in a different position to normal: arguments to the left of the
subroutine/method name, and invocants to the right of the method's
argument list.
So, for subroutine arguments, these are exactly equivalent:
($arg2, $arg3, $arg4) ~> subname $arg1;
subname ($arg1, $arg2, $arg3, $arg4);
and for method invocants, these are exactly equivalent:
method($arg1, $arg2) <~ $invocant;
$invocant.method($arg1, $arg2);
method $invocant: $arg1, $arg2;
Notice that, in addition to pipelines, these proposed operators give us
MTOWTDI with respect to ordering of the components of a sub or method call.
That is, Perl 6 subroutines may have prefix and/or postfix argument lists,
and Perl 6 methods may have invocants that are any(prefix, infix, postfix).
Any similarity to Lingua::Romana::Perligata is strictly coincidental.
So (4) above was translated in the parsing stage to be exactly identical
to (1), by the following conversions:
# original (4)
@in ~> map { ... } ~> grep { ... } -> @out;
# Fully Parenthesized
(((@in ~> map { ... } ) ~> grep { ... } ) -> @out
# "@a ~> function " becomes " function @a
((map { ... } @in) ~> grep { ... } ) ~> @out
# @a ~> function ===> function @a
(grep { ... } (map { ... } @in)) ~> @out
# @a ~> @b ===> @b = @a
@out = (grep { ... } (map { ... } @in))
# removal of duplicate parenthesis
@out = grep { ... } map { ... } @in
Yes. And the inference that most people seem to have drawn
is that this implies that Perl 6 would still have "stand-alone"
C and C functions.
However, I suspect the correct inference is that Perl 6 will have
C and C *multimethods*.
With (2) and (3), the situation is different, because they get
syntax-converted into a different form:
# Original (3)
@out <~ grep { ... } <~ map { ... } <~ @in;
# fully parenthesized
@out <- ( grep { ... } <~ ( map { ... } <~ @in));
Correct.
# function <~ @a > function :@a
No. method <~ @a > method @a:
@out <- { grep { ... } <- { map { ... } :@in ));
No. That should be either:
@out <~ ( grep { ... } <~ ( map @in: { ... } ));
or:
@out <~ ( grep { ... } <~ ( @in.map({ ... }) ));
# function <~ @a => function :@a
@out <~ grep { ... } :(map { ... } :@in)
That's:
@out <~ grep (map @in: { ... }): { ... };
or:
@out <~ @in.map({ ... }).grep({ ... });
# @a <~ @b => @a = @b
@out = grep { ... } :(map { ... } :@in)
That's:
@out = grep (map @in: { ... }): { ... };
or:
@out = @in.map({ ... }).grep({ ... });
To summarize (and, Piers, you can quote me on this)
Perl 5 allows you to do:
$object->meth1->meth2->meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~> sub1 ~> sub2 ~> sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 <~ meth2 <~ meth1 <~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '->'
is now spelled '.'
The additional functionality that when the last sub or method in the ~>
and <~ is a variable an assigment is done is a convenience issue.
Exactly. Thank-you for summarizing it so well.
(As an aside
I almost wish that calling a method with an incomplete argument list
would return a curried function, because that means that
$data ~> print <~ $filehandle;
would work!)
You'll recall that we did consider those implicit semantics for
currying and decided against them, since they greatly degrade the
compiler's ability to detect accidentally incomplete argument lists.
Besides, since the precedences of ~> and <~ would differ
(<~ binding tighter than ~>), that *would* work:
$data ~> print <~ $filehandle;
===> ($data ~> (print <~ $filehandle));
===> ($data ~> $filehandle.print);
===> ($filehandle.print($data));
Damian
Re: L2R/R2L syntax
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the "perlsub" documentation, which talks about
"creating your own syntax" with the & prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl don't
know what Perl can do.
Well, if even some of the people redesigning the language are
ignorant of some of its capabilities, that is an argument for making
those capabilities easier to discover, and maybe even more intuitive
to use, in the new design.
I see it more as the people who are ignorant of the features of Perl5
should go RTFM (Research The Features that they are Making?)
The fact that a & in a prototype obviates
the following comma is a pretty obscure detail; it's not the sort
of consistent behavior I'd want to build around going forward.
Why not? Its a syntax that everyone (or at least, most people)
seem to like.
But as I see it, the real problem being solved by the new syntax
is that grep and map can exist solely as methods on some class
in the inheritance tree of @arrays, no global functions required.
That is a Good Thing.
In your opinion. I'll still want to be able to write 1-liners and
short scripts. I'm sure perl6 will still be used for things other
than large applications. Is it such a sin to want the old syntax?
Even if the definition for grep lives in a method, why couldn't
there also exist a global function that looks like:
sub grep(&code,@array) {
@array.grep(&code);
}
Or even if this function does not exist, there's nothing stopping
the compiler from simply aliasing:
grep {} @array;
to:
@array.grep({});
Joseph F. Ryan
[EMAIL PROTECTED]
Re: L2R/R2L syntax
--- Damian Conway <[EMAIL PROTECTED]> wrote: > We should bear in mind that Larry has had some health issues. > And that he's currently unemployed with four children to support. Maybe he could find work hacking perl. I've heard he's pretty good... ;-) =Austin
Re: L2R/R2L syntax
Dave Whipp wrote:
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer ("->") which was chosen, I think, because it worked well in
the context of a C loop. Consider the following:
$\ = "|"; $, = ",";
Except, of course, those won't exist in Perl 6.
You want something like:
$*STDOUT.ors("|");
$*STDOUT.ofs(",");
1,2,3 -> { print } # 1,2,3
Err, no. That generates the list: (1, 2, 3, sub(){print})
1,2,3 ~> print;# 1,2,3
Yes. Except it's: 1,2,3|
1,2,3 ~> -> { print } # 1,2,3, but ugly
No. That's an error since you're specifying that the pointy sub
takes no parameters, and then trying to pass it three.
for 1,2,3 -> { print } # 1|2|3
Yes. Though the output is actually 1|2|3|
And the -> is redundant.
for 1,2,3 ~> print;# 1|2|3, but syntax error (*)
Kinda. The C is missing its block. So it won't actually compile.
So the C won't be called. But, if it had been:
for 1,2,3 ~> print {...}
then you get 1|2|3|
for 1,2,3 print; # 1|2|3, but syntax error
Huh? Just a syntax error, I think.
On the other hand:
for (1,2,3), &print;
works, and isn't an error.
all(1,2,3) ~> print # "junction(1,2,3)"
No. You can't print junctions directly. You have to say how
you want them serialized. For example:
all(1,2,3).values ~> print # prints: 1,2,3|
all(1,2,3).dump ~> print # prints: all(1,2,3)
all(1,2,3).pick ~> print # prints on the values at random
all(1,2,3) -> { print } # 1|2|3, but random order
This is the two-element list: ( 1|2|3, sub(){print} )
p.s. has Larry finished with those LoTR DVDs yet?
Probably.
We should bear in mind that Larry has had some health issues.
And that he's currently unemployed with four children to support.
Other matters are taking precedence at the moment.
Damian
Re: L2R/R2L syntax
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> >> ...the absence of the commas is what's special. If they were normal
> >> functions/subroutines/methods/whatever, you would need a comma after
> >> the first argument
> >
> > This is plainly untrue. See the "perlsub" documentation, which talks
> > about
> > "creating your own syntax" with the & prototype. You can do all this in
> > Perl 5, and it saddens me that some of the people redesigning Perl
> > don't
> > know what Perl can do.
>
> No. I said it was _special_, not _impossible_. You're "creating your
> own syntax" -- that's exactly my point. C, etc. are using an
> invocation syntax _slightly_ different from the vast majority of other
> cases -- one that skips a comma. Yes, it's a special case that exists
> because of the prototype and the special case caused by '&', which is a
> special case precisely so that there can be *any* way to emulate the
> special case C syntax. But whether we like the perl5 C
> syntax or not, we should at least recognize that it's not regular.
The & syntax is going to be special no matter what. It has the power to turn
a bare block into a subref:
sub foo ($x) { }
sub bar (&x) { }
foo { }; # hash
bar { }; # sub
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: ...the absence of the commas is what's special. If they were normal functions/subroutines/methods/whatever, you would need a comma after the first argument This is plainly untrue. See the "perlsub" documentation, which talks about "creating your own syntax" with the & prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. No. I said it was _special_, not _impossible_. You're "creating your own syntax" -- that's exactly my point. C, etc. are using an invocation syntax _slightly_ different from the vast majority of other cases -- one that skips a comma. Yes, it's a special case that exists because of the prototype and the special case caused by '&', which is a special case precisely so that there can be *any* way to emulate the special case C syntax. But whether we like the perl5 C syntax or not, we should at least recognize that it's not regular. I'm not saying the <~ version is going to be any easier to learn, I'm just saying that it offers considerably more language-wide bang for the buck, especially if we're going to adopt stronger OO practices. On Friday, January 17, 2003, at 11:15 AM, Mark J. Reed wrote: The fact that a & in a prototype obviates the following comma is a pretty obscure detail; it's not the sort of consistent behavior I'd want to build around going forward. But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. An emphatic yes, on both counts. MikeL
Re: L2R/R2L syntax
Brent Dax wrote:
Incorrect. The translation sequence is:
@in ~> map { ... } ~> grep { ... } ~> @out
((@in ~> map { ... }) ~> grep { ... }) ~> @out
((@in.map({ ... })).grep({ ... })) ~> @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only difference between '~>' and '.' is that '~>' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~> takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~> grep {...} ~> map {...} ~> sort;
I didn't read that as stating a semi-equivalence between '~>' and '.'.
I guess I live and learn.
Re: L2R/R2L syntax
On 2003-01-17 at 14:15:46, I wrote: > But as I see it, the real problem being solved by the new syntax > is that grep and map can exist solely as methods on some class > in the inheritance tree of @arrays, no global functions required. > That is a Good Thing. I realize that such also be true if we just disallowed that direction, requiring e.g. %hash.keys.grep().map(). I would personally be perfectly happy with that restriction, and in fact find the operation much clearer when written that way. But I don't see any harm in providing a mechanism to allow the reversal; TMTOWDI is going to be as true of Perl6 as it is of Perl5. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 11:03:43AM -0800, Michael Lazzaro wrote: > > And note that as pretty as -> is, we couldn't have <- for piping > because it would conflict rather strongly things like > > if ($a<-5)# (negative five, or pipelike?) Pipelike. Longest token rule. --Dks
Re: L2R/R2L syntax
On 2003-01-17 at 19:00:04, Simon Cozens wrote: > This is plainly untrue. See the "perlsub" documentation, which talks about > "creating your own syntax" with the & prototype. You can do all this in > Perl 5, and it saddens me that some of the people redesigning Perl don't > know what Perl can do. Well, if even some of the people redesigning the language are ignorant of some of its capabilities, that is an argument for making those capabilities easier to discover, and maybe even more intuitive to use, in the new design. The fact that a & in a prototype obviates the following comma is a pretty obscure detail; it's not the sort of consistent behavior I'd want to build around going forward. But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
RE: L2R/R2L syntax
Buddha Buck:
# My impression was that ~> and <~ were more general than that,
# and mainly
# did syntax-rewriting.
Correct.
# So (4) above was translated in the parsing stage to be
# exactly identical
# to (1), by the following conversions:
#
## original (4)
#@in ~> map { ... } ~> grep { ... } -> @out;
#
## Fully Parenthesized
#(((@in ~> map { ... } ) ~> grep { ... } ) -> @out
#
## "@a ~> function " becomes " function @a
#((map { ... } @in) ~> grep { ... } ) ~> @out
#
## @a ~> function ===> function @a
#(grep { ... } (map { ... } @in)) ~> @out
#
## @a ~> @b ===> @b = @a
#@out = (grep { ... } (map { ... } @in))
#
## removal of duplicate parenthesis
#@out = grep { ... } map { ... } @in
#
# So the syntax in (1) is still valid.
Incorrect. The translation sequence is:
@in ~> map { ... } ~> grep { ... } ~> @out
((@in ~> map { ... }) ~> grep { ... }) ~> @out
((@in.map({ ... })).grep({ ... })) ~> @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only difference between '~>' and '.' is that '~>' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.
# With (2) and (3), the situation is different, because they get
# syntax-converted into a different form:
#
## Original (3)
#@out <~ grep { ... } <~ map { ... } <~ @in;
#
## fully parenthesized
#@out <- ( grep { ... } <~ ( map { ... } <~ @in));
#
## function <~ @a > function :@a
#@out <- { grep { ... } <- { map { ... } :@in ));
#
## function <~ @a => function :@a
#@out <~ grep { ... } :(map { ... } :@in)
#
## @a <~ @b => @a = @b
#@out = grep { ... } :(map { ... } :@in)
#
# which is horrible, and no one would want to use that directly
# as opposed
# to syntax (1). But I can see beauty in (2) or (3).
#
# Of course, since indirect-object syntax is syntactic sugar
# itself, this
# goes on to be:
#
## function :@a ===> @a.function, applied repeatedly
#@out = @in.map({...}).grep({...});
#
# which is yet another L2R syntax.
Correct.
# But it also implies that map(&block) and grep(&block) are methods on
# arrays (or Arrays).
Correct again.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 10:41 AM, Dave Whipp wrote: But then we shift our perception to think that -> is an L2R pipe into a block: not an anonymous sub composer. Similarly, the C function is a strange thing sends its elements down the pipe, one-by-one -- its not a loop at afterall! (A junction, in contrast, would send its elements down the pipe in random order, or concurrently). And note that as pretty as -> is, we couldn't have <- for piping because it would conflict rather strongly things like if ($a<-5)# (negative five, or pipelike?) Otherwise, using -> and <- would be ideal. Especially since then $foo->bar and $foo.bar are exactly equiv, helping perl5 people. Ah, well. :-/ MikeL
Re: L2R/R2L syntax
Michael Lazzaro wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } <~ map { ... } <~ @in; # (2) (perl6)
@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
@in ~> map { ... } ~> grep { ... } ~> @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
My impression was that ~> and <~ were more general than that, and mainly
did syntax-rewriting.
So (4) above was translated in the parsing stage to be exactly identical
to (1), by the following conversions:
# original (4)
@in ~> map { ... } ~> grep { ... } -> @out;
# Fully Parenthesized
(((@in ~> map { ... } ) ~> grep { ... } ) -> @out
# "@a ~> function " becomes " function @a
((map { ... } @in) ~> grep { ... } ) ~> @out
# @a ~> function ===> function @a
(grep { ... } (map { ... } @in)) ~> @out
# @a ~> @b ===> @b = @a
@out = (grep { ... } (map { ... } @in))
# removal of duplicate parenthesis
@out = grep { ... } map { ... } @in
So the syntax in (1) is still valid.
With (2) and (3), the situation is different, because they get
syntax-converted into a different form:
# Original (3)
@out <~ grep { ... } <~ map { ... } <~ @in;
# fully parenthesized
@out <- ( grep { ... } <~ ( map { ... } <~ @in));
# function <~ @a > function :@a
@out <- { grep { ... } <- { map { ... } :@in ));
# function <~ @a => function :@a
@out <~ grep { ... } :(map { ... } :@in)
# @a <~ @b => @a = @b
@out = grep { ... } :(map { ... } :@in)
which is horrible, and no one would want to use that directly as opposed
to syntax (1). But I can see beauty in (2) or (3).
Of course, since indirect-object syntax is syntactic sugar itself, this
goes on to be:
# function :@a ===> @a.function, applied repeatedly
@out = @in.map({...}).grep({...});
which is yet another L2R syntax.
But it also implies that map(&block) and grep(&block) are methods on
arrays (or Arrays).
The issue, as I see it, is that some people like to follow data flow
from right to left through a chain of actions. Perl 5 supported this
fine when it came to chained function calls:
sub byChar { $a cp $b }
for @words {
my $anagram = sort byChar split //, $_; # R2L flow of data.
push @$anagrams{$anagram}, $_;
}
Other people like to follow data flow from left to right through a chain
of actions. Perl 5 supported this fine when it came to method invocations:
$emplyeeTable->select('unionized')->raiseSalary(0.05);
But if you needed to have a chain of function calls, you couldn't easily
do left to right, and if you needed to have a chain of method
invocations, you couldn't easily to right to left.
The one saving grace for method invocation was the use of "indirect
object" syntax, which says that if the first argument of a
multi-argument function is an object and is not followed by a comma,
then the function should be interpreted as a method on that object:
print $filehandle $text;
is equivalent (in Perl 5) to
$filehandle->print($text);
But that doesn't scale. You can do the "block that evaluates to an
object" trick to do some chaining, which gets you:
raiseSalary {select $employeeTable 'unionized'} 0.05;
But that is ugly as sin and not truely Right to Left; it's more "Middle
to Out".
To summarize (and, Piers, you can quote me on this)
Perl 5 allows you to do:
$object->meth1->meth2->meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~> sub1 ~> sub2 ~> sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 <~ meth2 <~ meth1 <~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '->'
is now spelled '.'
The additional functionality that when the last sub or method in the ~>
and <~ is a variable an assigment is done is a convenience issue.
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
(As an aside
I almost wish that calling a method with an incomplete argument list
would return a curried function, because that means that
$data ~> print <~ $filehandle;
would work!)
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Michael Lazzaro) writes: > ...the absence of the commas is what's special. If they were normal > functions/subroutines/methods/whatever, you would need a comma after > the first argument This is plainly untrue. See the "perlsub" documentation, which talks about "creating your own syntax" with the & prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. -- Look, there are only a few billion people in the world, right? And they can only possibly know a few thousand bits of information not known by someone else, right? So the human race will never have a real need for more than a few terabits of storage, except possibly as cache. - Geraint Jones
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 09:57 AM, Mr. Nobody wrote:
And map/grep aren't "specialized syntax", you could do the same thing
with a sub with a prototype of (&block, *@list).
The specialized part is that, in perl5, it's:
@out = grep { ... } map { ... } @in;
instead of:
@out = grep { ... }, map { ... }, @in;
...the absence of the commas is what's special. If they were normal
functions/subroutines/methods/whatever, you would need a comma after
the first argument, or we need a generic rule saying that a comma is
optional after any closure.
The other, bigger issue is whether map, grep, etc. are methods of
arrays/lists, or as special (universal) functions. Using a pipe-like
syntax allows the following things to happen:
- C, C, etc., all become methods, not universal functions.
That means you can override them for subclasses of Arrays just like you
would any other method, and you can make new methods that act like them
and have the same syntax.
- If you want a customized C or C method for a subclass of
Array, you don't need to worry about _also_ overriding the universal
C and C functions to recognize each of your subclasses using
multimethod variants.
- We don't need special comma-dropping rules for the grep and map
syntax.
- You can use the same piping syntax for indirect-object-style calls on
any methods:
$b = <~ fooify <~ mooify <~ gooify <~ $a;
same as:
$b = $a.gooify.mooify.fooify;
So short answer is, putting an operator in there like <~ and ~> is a
more generic syntax, and especially works better if arrays and lists
are objects. That's why it's being discussed.
MikeL
Re: L2R/R2L syntax
"Mr. Nobody" <[EMAIL PROTECTED]> wrote :
> I have to wonder how many people actually like this syntax, and how many
only
> say they do because it's Damian Conway who proposed it. And map/grep
aren't
> "specialized syntax", you could do the same thing with a sub with a
prototype
> of (&block, *@list).
I 50% like it: I think Damian was on the right track. It will be good to
have a way
for L2R pipes to work (whatever the syntax): but the Perl5 syntax for R2L
works
for me already (I'm neutral about adding extra syntax for it).
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer ("->") which was chosen, I think, because it worked well in
the context of a C loop. Consider the following:
$\ = "|"; $, = ",";
1,2,3 -> { print } # 1,2,3
1,2,3 ~> print;# 1,2,3
1,2,3 ~> -> { print } # 1,2,3, but ugly
for 1,2,3 -> { print } # 1|2|3
for 1,2,3 ~> print;# 1|2|3, but syntax error (*)
for 1,2,3 print; # 1|2|3, but syntax error
all(1,2,3) ~> print # "junction(1,2,3)"
all(1,2,3) -> { print } # 1|2|3, but random order
It seems to me that the difference between the straight and squiggly arrows
is that one works with named subs; and the other with anonymous. If this
distinction is necessary, and ubiquitous, then perhaps we can live with it.
But then we shift our perception to think that -> is an L2R pipe into a
block: not an anonymous sub composer. Similarly, the C function is
a strange thing sends its elements down the pipe, one-by-one -- its not
a loop at afterall! (A junction, in contrast, would send its elements down
the pipe in random order, or concurrently).
Dave.
p.s. has Larry finished with those LoTR DVDs yet?
Re: L2R/R2L syntax
* Mr. Nobody <[EMAIL PROTECTED]> [2003-01-17 19:55:41]:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
> >@in ~> map { ... } ~> grep { ... } ~> @out; # (4)
> I have to wonder how many people actually like this syntax, and how many only
> say they do because it's Damian Conway who proposed it.
Just for statistical purposes I would like to say that I do like this syntax and
this has nothing to do with Damian. I would have liked it if it was proposed
by anyone else anyway.
> > 2) You might be able to combine L2R and R2L piping in one statement.
> > Maybe.
I think this is great. At least it caries the true Perlish philosophy of doing
things in an obfuscated way. However, although I like it because I am a Perl
programmer, these kind of things scare new people away because they think that
Perl is an awful language which is write-only. I thought this was going to
change with Perl6.
> > 3) How pretty you think the above is depends almost entirely on how the
> > tilde is rendered in your font.
> I have a font where ~ is in the center, and I still hate it.
I have a font where ~ is rendered above, and I still like it.
> > 4) Some people like the idea of having Unicode operators in perl6.
> > Some don't. There are issues with it. Larry hasn't come up with a
> > ruling yet. We should wait for his decision.
As long as there is a [alternative] way to input (and read) Perl scripts in
simple ascii, I'm happy. Should there be an approach that Java used to have --
where "\u" escape sequences are parsed first and then the code is parsed?
(I am not terribly familiar with unicode technologies in programming languages,
so you can think of me as an ordinary newbie at this point ;)
Petras Kudaras
--
Just Another Lithuanian Perl Hacker
Re: L2R/R2L syntax
I'd like to point out one thing that I'm not sure of. It seems like the
original proposal only allowed for the operators to change terms around.
So given the same (1)-(4) from the message, (4) is exactly the same as (1), and
(2) and (3) are exactly the same as each other and as
@out = @in.map({ ... }).grep({ ...}); # (5)
I guess what I'm trying to point out is that the user still has to know which
syntax is really natively supported, and can only use ~> and <~ as crutches for
reversing that. IOW, we can't just eliminate the global "map {block} @list"
function, or "@list ~> map {block}" simply won't work (but could be written as
"@list.map({block})". Somehow this feels even more confusing than ever.
> So, to bring this thread back on track *again*, I hopefully offer this
> summary.
>
>
> 1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
>
>@out = grep { ... } map { ... } @in; # (1) (perl5)
>
> becomes any of the following:
>
>@out = grep { ... } <~ map { ... } <~ @in; # (2) (perl6)
>
>@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
>
>@in ~> map { ... } ~> grep { ... } ~> @out; # (4)
>
> My impression was that this was _instead_ of (1), eliminating the
> specialized syntax of the map, grep, etc. functions in favor of this
> more generic piping syntax, but that wasn't explicitly stated. Is that
> correct?
>
> 2) You might be able to combine L2R and R2L piping in one statement.
> Maybe.
>
> 3) How pretty you think the above is depends almost entirely on how the
> tilde is rendered in your font.
Yes, it wasn't until I got on a different computer with ~ centered that I
understood why anyone even conceived of this. But Unicode is worse, since I
have NEVER gotten ANY of those to work. Apparently my gnome-terminal/ssh/less
combination just doesn't like unicode. But this is perl, so who cares if
anyone can read it, right?
>
> 4) Some people like the idea of having Unicode operators in perl6.
> Some don't. There are issues with it. Larry hasn't come up with a
> ruling yet. We should wait for his decision.
>
> 5) Sarcasm is, apparently, dead.
I'm not dead yet! I'm feeling much better, really.
>
> MikeL
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
What exactly do we mean when we use the word "semantics"?
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: > [EMAIL PROTECTED] (Mr. Nobody) writes: > > I have to wonder how many people actually like this syntax, and how > > many only say they do because it's Damian Conway who proposed it. > > And map/grep aren't "specialized syntax", you could do the same > > thing with a sub with a prototype of (&block, *@list). > > Well, I'll go record and say I think it's Bloody Silly. It's > over-cutesy, adding syntax for the sake of syntax, doesn't do anything > for the readability of code, and doesn't really actually gain very > much anyway. It does something for me (at least the ~> version does). I find it annoying that to generate a map + sort + grep pipeline, I have to interrupt my L2R flow and construct it backwards. It mayn't be much, but I'd be happier if I had the option to construct the pipeline in a L2R manner. > But even so I dare say it'll go in because Damian likes it. Was this some of that stealth sarcasm, or do you really believe this? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: L2R/R2L syntax
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Simon Cozens:
> # [EMAIL PROTECTED] (Brent Dax) writes:
> # > # could do the same thing with a sub with a prototype of
> # > # (&block, *@list).
> # >
> # > Great. That could mean it won't work right for
> # > MyCustomArrayLikeThing.
> #
> # Can you explain what you mean by this, because it's not
> # apparent to me that your statement is in any way correct.
>
> OK. Let's say I'm implementing HugeOnDiskArray, and instead of
> slurping
> the array in and grepping over it, I want to grab the elements one at
> a
> time, run them through the grep function's coderef, and stick them in
> another HugeOnDiskArray. Or, if I have RemoteArray (which works with
> an
> array on another computer via a server and a TCP/IP connection), I
> might
> want to try to serialize the code reference given to grep and run the
> grep on the remote computer. (If I can't serialize the coderef due
> to,
> say, nonsense with closures, I'd run the grep locally.)
>
> No, "it won't work efficiently" isn't the same as "it won't work",
> but I
> suspect there are cases I haven't thought of.
I don't follow your example. If you can make
@safe_text = grep { ! /fnord/; } @HugeArrayOnDisk;
work, then why couldn't you make
@HugeArrayOnDisk -> grep { ! /fnord/; } -> @safe_text;
work just as well? I haven't read anything which says that the
different expressions call different incarnations of grep at the
bottom. (That would be the Array are/aren't Objects thread, and its
result STILL shouldn't impact the behavior of grin.)
=Austin
Re: L2R/R2L syntax
> I have to wonder how many people actually like this syntax, and how
> many only say they do because it's Damian Conway who proposed it.
> And map/grep aren't "specialized syntax", you could do the same
> thing with a sub with a prototype of (&block, *@list).
I have to say that I am not specially entusiasthic about the <~
syntax.
I'd feel more confortable with a "plain" OO syntax:
@out = @in.grep({...}).map({.}).grep({...});
But my prefered option would be to ban "map" and "grep" alltogether,
replacing them with a non-void context "for", enhanced with a "where"
clause:
@out = for @in where {...} {
...
}
The simplest cases don't get so horrible:
@out = map { $_* 2 } @in; # P5
@out = for @in { $^a * 2 }; # P6
@out = grep { $_ > 0 } @in; # P5
@out = for @in where { $_ > 0 };# P6
(Notice the implied {$_} in the for body)
And if you are really planning to chain nine different greps/maps/.. I
am afraid no amount of beautiful or ugly syntax will help you much.
Overall, I am worried that we are putting too much effort in creating
"optimal" syntaxes for some very specific cases.
This happens to be also my complain about hyperoperators (sorry for
bringing this again). Too much syntax, for a so small value.
I have always favoured RFC 207[1] syntax instead of hyperoperators
because it, at least, gives you some extra power:
@mat3 = @mat1[|i,|j] * @mat2[|j,|i]
But that's a different story,
-angel
[1] http://dev.perl.org/rfc/207.html
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Paul Johnson) writes: > I trust that we are all sufficiently grown up and devoid of marketing hype > that we can judge suggestions on their own merit. Do you need pointing to the archives at this point? -- DYSFUNCTION: The Only Consistent Feature of All of Your Dissatisfying Relationships is You. http://www.despair.com
