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.
Cfor as a junction operator
In the L2R thread, I made a comment where I contrasted a for loop
with a junction. On reflection, I think we could go further.
If we defined
my $prev = 0;
sub mangle($value) { $value + $prev; $prev=$value }
and then used it as:
my $x = any(1,2,3);
$y = mangle($x);
then the semantics of junctions are defined to fork 3 threads, to
evaluate Cmangle for each member of the junction in an
arbitrary order. So there are now many possible values for
$y. For example: any(2,5,6) if the order of evaluation is 2,3,1.
Let us now imagine that Cfor is a junction operator, instead of a
looping statement. Now we could write:
my $x = for(1,2,3);
my $y = mangle($x);
and we can be certain that $y == (1,3,6), because a for-junction
will distribute that evaluations sequentially.
This ties in nicely with the pipeline syntax discussion, because
for 1,2,3 ~ print;
and
for 1,2,3 - { print };
would naturally behave correctly. But by defining a special type of
sequentially distributed junction, we can do all sorts of clever (and
therefore nasty) things.
Dave.
--
mailto:[EMAIL PROTECTED]; http://dave.whipp.name
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: Cfor as a junction operator
Dave Whipp wrote: Let us now imagine that Cfor is a junction operator, instead of a looping statement. Now we could write: my $x = for(1,2,3); my $y = mangle($x); and we can be certain that $y == (1,3,6), because a for-junction will distribute that evaluations sequentially. Yes, but will it junctify them con-, dis-, ab-, or in-junctively??? Besides, I don't think we need to sacrifice Cfor to achieve this behaviour. If ordered junctions are a useful concept (and I can see that they might well be), we can have them like so: my $x = any(1,2,3) but ordered; my $y = mangle($x); This ties in nicely with the pipeline syntax discussion, because for 1,2,3 ~ print; There's still the issue of implicit serialization. Junctions...err...don't. 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: Civility, please.
Joseph F. Ryan wrote:
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.
Oy. One more time. My objection is this: I said Cmap {...} @a and
friends are special compared to normal subroutine syntax, because there
isn't a comma after the {...}. It was then stated that Cmap itself is
not special, because the '' in the prototype allows the special case to
exist not only in map, but in anything else prototyped in the same
way. True.
My error, therefore, was to not properly define what I meant by normal
subroutine syntax, because I thought it was clear from the context what
normal meant... it meant compared to having a comma there. But it
wasn't clear.
This, however, is a Computer Science discussion. Computer Science is
one of those fields populated almost exclusively by people who consider
any statement devoid of at least three explanatory footnotes to be an
act of aggression, and who measure their own genius in large part by
their practiced lack of ability to infer meaning from any string of
words not emanating from their own head.
Thus, a possible response like I don't agree with your use of the word
'special' to describe this case, because these other cases are
identically 'special' too is transformed without any apparent irony to
since you did not use the precise wording I myself would have used in
your two-sentence explanation, that provides conclusive evidence that
you therefore don't know Perl5.
Yes, in hindsight, I should have responded I know *why* the specialness
exists, you thundering blowhards, I'm just noting that it *is* special
compared to how *most* subroutine argument lists look. Quit assuming
that every last syntactic nuance will tunnel untouched to Perl6 by the
grace of your own unassailable wisdom, and tell me *why* this particular
one should. [1] Those sorts of communications can sometimes cross the
semantic barrier.
Yes, perhaps we should all have our mail proofread by a peer jury before
we post, thus attempting universal semantic clarity... or perhaps we can
all just practice those human social skills that some of us might have
seen on television or in the movies, and Get Over Ourselves. [2]
(Note that Damian was the *only* person who, at any point in the
discussion, was able to identify the notion that not having the comma
there was different from having the comma there, and was able to
respond with an argument more structured than because Perl5 does it.
_This_ is why his ideas get implemented. Duh.) [3]
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?
What I'm trying to avoid is the apparent need for programmers to degrade
every conversation into an I'm-smarter-than-you semantic duel. In the
entire history of the Perl6 process, there has been noone here to emerge
as God's Perfect Gift to Language Design -- I think the design has been
improved repeatedly by the collective thoughts of the group. But
nobody, individually, has a very good batting average, so I think nobody
is in a position to throw stones.
MikeL [4]
[1] OK, that's definitely not civil. Which is why I didn't originally
say it.
[2] Er, that's not great either, but probably in the range of acceptable.
[3] Note to self -- remove the 'Duh', and it will be fine.
[4] And yes, the irony of needing N paragraphs to try to convince
programmers of such a profoundly simple concept is not lost on me. Nor
is the fact that it will inevitably fail...
