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 Cmap, Cgrep, 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
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: 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
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 Cmap, Cgrep, 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: Why Cmap 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 Cmap 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; snip 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: L2R/R2L syntax
Damian Conway writes:
Not equivalent at all. C$foo~bar means append $foo to the argument list
of subroutine Cbar. Cfoo.bar means make C$foo the invocant for method
bar.
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: Why Cmap 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 Cfor 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 Csub if desired
(for example, perhaps it could be spelt Cmy in this context, though
you'd need to work on the lexical scoping rules). The only remaining
magic would be to retrofit the basic Cfor 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 Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
Dave.
Re: Why Cmap 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 Cfor contribute to
the semantics of the pipeline? What would Cmap (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
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 Cmap 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 Cfor contribute to
the semantics of the pipeline? What would Cmap (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. Cmap
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.
Re: Why Cmap 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 Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
Hmm. Perhaps there doesn't _need_ to be a difference. You currently
use Cfor when you don't care about capturing the results. You use
Cmap when you do. But since we can identify context, perhaps they
could be synonyms, if we tweak things a little.
*** SPECULATION AHEAD ***
Note that Cfor allows you to name the arguments, using the pointy sub
rule:
for @a - ($a,$b) {...}
but note ALSO that it'd be great if Cmap and friends had that
capability, so you could Cmap two-at-a-time, etc. (Cgrep and
Csort don't really need it, but I *suppose* you could use it for
grepping/sorting tuples.)
So we want the pointy-sub rule for Cmap 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
Cfor as just another word for Cmap, 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 Cfor.)
*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 Cfor and Cmap
synonyms, and gives each the magical powers of the other. The fact
even Cfor is now an object method means you could say:
for @obj : {...}
and even overload the Cfor 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, Cfor would have the colon after the
list:
for @a : {...}
If we did that, the rest might just work.
Anyway, just speculation.
MikeL
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 Cmap 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 Cfor allows you to name the arguments, using the pointy sub
rule:
for @a - ($a,$b) {...}
but note ALSO that it'd be great if Cmap and friends had that
capability, so you could Cmap two-at-a-time, etc. (Cgrep and
Csort 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 Cmap 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
Cfor as just another word for Cmap, 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 Cfor.)
Yeah, good point. Why is it that Cfor and Cmap, 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 Cfor and Cmap
in their argument style. I still think the distinction between
Cfor's void and Cmap's list context is a good one; i.e. don't make
them Ientire synonyms.
But it seems natural to have Cfor a method of CArray, 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: Why Cmap 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 Cmap-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 Cmap and friends to be confusing, particularly when they are traveling in a pack (not to speak of an Cunpack). 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 Cmap 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 Cfor and Cmap
in their argument style. I still think the distinction between
Cfor's void and Cmap's list context is a good one; i.e. don't
make them Ientire synonyms.
But it seems natural to have Cfor a method of CArray, 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 Cfor and Cmap, 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 Cmap 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: 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: 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 Cwonk would be called like a method, but still not have access to
CArray'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
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
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: Why Cmap 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 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.
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
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/Perl::term/,
$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
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
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: Why Cmap 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 Cmap, etc., we could drop the inferred-comma rule as
well (unless we're really successful in making Cif 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 Cif 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
Cmap syntax. I'd dislike Cmap, and like pipelines, even if the
inferred-comma rule wasn't there.
As you've not doubt noticed, I'm the opposite: I like Cmap 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 Cmap 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 Cmap as taking two arguments. In my
mind Cmap operates on items in a list (and it just so happens that
in Perl an array provides a list):
map { ... } $a, $b, $c;
So Cmap 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 Cjoin are.)
Thinking of it as operating on a list of things also helps to emphasize
that Cmap 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 understand what
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 Cmap 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 Cfor, Cif, 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 Cmap 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 Cmap 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 Cmap 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: Why Cmap 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~b~$a, when it can't. That, to me, is an argument against ~ and ~, at least as currently formulated.
Re: Why Cmap 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... snip 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~b~$a, when it can't. That, to me, is an argument against ~ and ~, 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: 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: 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, block; follow) {
# ... er, how do you write if? Hmm...
$test ?? block() :: follow()
}
sub elsunless ($test, block; 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
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, block; follow) {
# ... er, how do you write if? Hmm...
$test ?? block() :: follow()
}
sub elsunless ($test, block; 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, block; follow) {
!$test ?? block() :: follow()
}
Or something like that. Darn.
Luke
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: snipped Yeah, a three-argument form would easily allow chaining. But of course it still doesn't do the appropriate syntax checking (Celse outside of Cif, 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
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, block; follow) {
!$test ?? block() :: follow()
}
Right, but it's acceptable magic (magic that would be used for any
subs, not just the if, Celse, etc.) Not grammar-level magic
special to conditionals.
MikeL
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:
snipped
Yeah, a three-argument form would easily allow chaining. But of course
it still doesn't do the appropriate syntax checking (Celse outside of
Cif, 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
--- 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:
snipped
Yeah, a three-argument form would easily allow chaining. But of
course
it still doesn't do the appropriate syntax checking (Celse outside
of
Cif, 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 Cif versus Cif-els... 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:
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
Why Cmap 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 Cmap, etc., we could drop the inferred-comma
rule as well (unless we're really successful in making Cif 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
Cmap syntax. I'd dislike Cmap, 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...
The Problem
Over the years, I've seen quite a few newbies struggle with the Cmap
syntax; the most frequent mistake is to reverse the order of the
arguments, saying
map @a, {...}
(Another common one is to not understand what Cmap {...} @a, @b 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 blah to it.
In other words, when newcomers verbalize the statement, they tend to
think of the Cmap as operating on @a. Which is true. You might also
say it does blah 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. Cmap, Cgrep, 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.
Is there an OO solution?
So is there fix for Cmap 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 Cmap, 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 Clength @a 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 Cmap
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 Cmap 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 blah 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 -- Cmap 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 Cmap, Cgrep, Csort, 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 Cmap-like
chaining in Perl5. I can't begin to justify
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
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: 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
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, block; follow) {
# ... er, how do you write if? Hmm...
$test ?? block() :: follow()
}
sub elsunless ($test, block; 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
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 [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: Cdot would have a higher precedence than -: Dave.
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
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: 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. Cmap, 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 Cmap syntax. But whether we like the perl5 Cmap
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
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: Cdot would have a higher precedence than -: Not equivalent at all. C$foo~bar means append $foo to the argument list of subroutine Cbar. Cfoo.bar means make C$foo the invocant for method bar. 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
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 Csub (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 Cis multi is a
much clearer signal of intent.
So we're still considering the matter.
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 Csub (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 Cis multi 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:
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 Cmethods 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 Cfoo must always called as:
foo( $arg1, $arg2 );
and Cbar 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 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
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 Cdraw_triangle?
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
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 Cdraw_triangle?
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
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: 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 (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote: On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Thus we are back to using uuencode :-) Which, actually, might not be a bad thing. It will give Unicode a boost by forcing people to become more aware of this issue. To a large extent, the software industry as a whole is driven by what makes the lives of programmers easier--as a simple example, programming editors are written by and for programmers, who use them to write other programs. If editors become Unicode by default (both input and output) then the other programs will start to become Unicode by default. Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? I'd like to be able to easily exchange mail and scripts with people in other countries. --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- David Storrs [EMAIL PROTECTED] wrote: On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote: On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Thus we are back to using uuencode :-) Which, actually, might not be a bad thing. It will give Unicode a boost by forcing people to become more aware of this issue. To a large extent, the software industry as a whole is driven by what makes the lives of programmers easier--as a simple example, programming editors are written by and for programmers, who use them to write other programs. If editors become Unicode by default (both input and output) then the other programs will start to become Unicode by default. Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? Not just no, but Hell, no! The people who love Unicode best are those who've never had to work with it. That being said, I'm the guy who wants it, so what gives? Unicode is way more than most people will ever need. I can't think of very many people who really want sizeof(char) = sizeof(int). What we need is the ability to support selective Unicodification -- using a simple character set by default, but automatically transitioning/expanding/recoding as appropriate. For example, take your basic simple editor, and have it parse \u21F6 as (whatever glyph that is) and display it correctly. But it is allowed to store \u21F6 in the output stream. Or, have it convert to and from trigraphs. Instead of \u21F6, it could store ~ (or ??) or whatever) in the stream. This will encourage terminal software to support fonts that contain the code pages we need, and encourage text editor writers to code in a character-width-independent manner, but won't require the whole operating system to suddenly switch to Unicode. The point is that we know there's lots of utilities out there that we want to continue to be able to use, and they're not Unicode. So while we support unicode, and we lead the way in adopting, integrating, and utilizing Unicode, we have to do it in a way that's compatible with the rest of the world so they'll be encouraged to follow us. =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
* David Storrs [EMAIL PROTECTED] [2003-01-17 19:29:25]: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? I'd like to be able to easily exchange mail and scripts with people in other countries. Hi, I am a native Lithuanian, and the issue of different charsets and unicode is very important to me. We used to use iso-8859-4 charset and our current standard is iso-8859-13. Now, when I say standard, it means an official standadrd de jure , not the standard de facto. Desktop systems are dominated by Windows, and Microsoft has a terrible attitude towards this charset issue. Windows still uses iso-8859-4 and a bastardised version of iso-8859-13, which is called windows-1257. Things would be great if everyone used Unicode, but again, this presents a lot of problems. I usually use utf-8 but this means that most windows users will not be able to read my writings in emails (Outlook just scrables the whole thing). So my point would be that the world is not ready for unicode. At least until major companies start to take it seriously. Sure, it would be a nice thing to have everything in unicode, but I am afraid that is not possible yet. Especially when we have a lot of old systems, where the only editor is vi via ssh. And I am telling you this, because I know how hard it is to live in a world where your charset characters are not in ASCII (and I'm talking not 7-bit ascii, but ascii as a whole). So, yes, it would be nice to live in a perfect world, but we are not quite there yet. Petras Kudaras -- Just Another Lithuanian Perl Hacker
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/17/03, David Storrs wrote: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? Because it makes life significantly harder for everyone on the planet who already has a perfectly fine local system. What you're asking for is a massive software, hardware, and data conversion project, with all the work being done by all the world that doesn't use straight ASCII. Given that covers a good 80% of the world, well... seems just the tiniest bit arrogant to me. Very few people need to deal with inter-language data exchange. The vast majority of data is kept in the native language of the operator of the system, with most of the remainder in 7-bit ASCII, which fits in everyone's local character set anyway. Unicode is like XML. It's the least-bad solution we have for general data interchange. We just don't often *need* general data interchange. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 12:19:01PM -0500, Dan Sugalski wrote: At 8:08 AM -0800 1/17/03, David Storrs wrote: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? Because it makes life significantly harder for everyone on the planet who already has a perfectly fine local system. What you're asking for is a massive software, hardware, and data conversion project, with all the work being done by all the world that doesn't use straight ASCII. Given that covers a good 80% of the world, well... seems just the tiniest bit arrogant to me. Actually, that's *not* what I'm asking for. It would appear that either my question was not clearly written, or that people didn't read it very careful before jumping to conclusions. I didn't say Let's start doing the conversion. I didn't say Let's force everyone else to do the conversion. What I said was Do we agree that this would be a good thing? To me it seems like a good thing. All I wanted to know was if there were issues I wasn't thinking of. Very few people need to deal with inter-language data exchange. The vast majority of data is kept in the native language of the operator of the system, with most of the remainder in 7-bit ASCII, which fits in everyone's local character set anyway. Unicode is like XML. It's the least-bad solution we have for general data interchange. We just don't often *need* general data interchange. Even if, for the sake of argument, we grant that this is the case right now (and, given the number of messed-up characters I get in my email every day, I do *not* grant it), it is becoming less and less the case every day. In 10 or 20 years, I believe it will be not just common but expected to have projects (programming and otherwise) that consist of people scattered all over the world, constantly passing their data around. To paraphrase your comment above, Unicode may be a pain, but it is the least bad solution we have. --Dks
Re: L2R/R2L syntax
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.
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.
MikeL
RE: L2R/R2L syntax
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.
# 2) You might be able to combine L2R and R2L piping in one statement.
# Maybe.
#
# Oh goody. I was worrying they might not be confusing enough.
There are a lot of confusing syntaxes in Perl--if you don't believe me,
go look at the Obfuscation section on PerlMonks. :^) That doesn't mean
we try to get rid of them--we just tell people not to use them, and they
don't unless they're trying to be perverse.
--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
[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. But even so I dare say it'll go in because Damian likes it. -- King's Law of Clues : Common sense is inversely proportional to the academic intelligence of the person concerned.
Re: L2R/R2L syntax
[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. There are a lot of confusing syntaxes in Perl--if you don't believe me, go look at the Obfuscation section on PerlMonks. :^) That doesn't mean we try to get rid of them Of course not; it means we need to add more! -- MISTAKES: It Could Be That The Purpose Of Your Life Is Only To Serve As A Warning To Others http://www.despair.com
Re: L2R/R2L syntax
Mr. Nobody said:
--- Michael Lazzaro [EMAIL PROTECTED] 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?
I hope not. Don't forget that despite the caveats, the Perl should stay
Perl RFC was actually accepted.
OK, I could be convinced that there should be a change if it would
simplify and generalise, but I see no point in change for its own sake.
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.
I trust that we are all sufficiently grown up and devoid of marketing hype
that we can judge suggestions on their own merit.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
RE: L2R/R2L syntax
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.
--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 Fri, Jan 17, 2003 at 09:57:47AM -0800, Mr. Nobody wrote:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@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.
I like this syntax because it's the best one proposed so far. As soon
as someone comes up with something better, this syntax would fall into
my mental gutter of good, but not good enough ideas.
I'd like - and - even more, if they were both available.
But we still need to hear from our Language Designer as to what he
thinks. He may decide that the whole concept isn't worth the hassle or
can be accomplished another way and then we don't have to worry about
syntax any more.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: L2R/R2L syntax
--- Thom Boyer [EMAIL PROTECTED] wrote: Mr. Nobody [mailto:[EMAIL PROTECTED]] groused: 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. Some of us like it because we've wanted something like it for years. On the other hand, at least one of us seems to dislike it just because it's Damian Conway who proposed it. =thom I have nothing against Damian himself, he's had some good ideas in the past. I just don't like proposals that make things more complicated for no gain. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax
You've overlooked ~| or ~ or whatever that operates on context by
default.
given @foo {
~ classify ~ @categories;
~ sort - @sorted_foo;
~ improve ~ @bar;
};
Personally, I'd like to see that syntax improved a little.
Anyway, I'd suggest that the order of execution of lines beginning with
a dangling grin or dragon operator by undefined. (So that p6.1 can run
them in separate threads.)
Which makes for a good motorized personal transporter(*) into another
TFH(+): Threads.
(!)
=Austin
(*) Segway -- aka segue.
(+) Topic From Hell
(!) All your base are belong to us! Fnord!
--- Michael Lazzaro [EMAIL PROTECTED] 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?
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.
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.
MikeL
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. 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. But even so I dare say it'll go in because Damian likes it. That statement I dont agree with. Yes Larry has put a lot of trust in Damian, but that has not resulted in Damian always getting what he wants, just most of the time :-) Graham.
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Brent Dax) writes: # # could do the same thing with a sub with a prototype of # # (block, *@list). 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. So if you want a lazy grep, you use (block, $list) rather than (block, *@list). Still no additional syntax required. -- Nuclear war can ruin your whole compile. -- Karl Lehenbauer
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
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
--- 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
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
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
* 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
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 Cfor 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 Cfor 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
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:
- Cmap, Cgrep, 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 Cmap or Cgrep method for a subclass of
Array, you don't need to worry about _also_ overriding the universal
Cmap and Cgrep 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
[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
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
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 Cfor 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
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 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
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 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
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 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. Cmap, 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 Cmap syntax. But whether we like the perl5 Cmap 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
--- 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. Cmap, 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 Cmap syntax. But whether we like the perl5 Cmap
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
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 Cfor 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 Cfor is missing its block. So it won't actually compile.
So the Cprint 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
--- 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
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
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
Cmap and Cgrep functions.
However, I suspect the correct inference is that Perl 6 will have
Cmap and Cgrep *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
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
