On Sat, 25 Jan 2003, Damian Conway wrote:
> As far as I know Larry is not planning to remove the functional
> forms of C, C, etc.
>
> Those forms may, it's true, become mere wrappers for the OO forms.
> But I confidently expect they will still be available.
Hmmm, so that means that they should be
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,
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,
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-me
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
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
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
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
[[... Massive elision ...]]
> I'm thinking it would be a very good idea to unify C and C
> in their argument style. I still think the distinction between
> C's void and C's list context is a good one; i.e. don't
> make them I synonyms.
>
> But it seems
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 e
> 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 pipi
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,
"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 que
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 br
"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 precedenc
Damian Conway writes:
>
> Not equivalent at all. C<$foo~>bar> means "append $foo to the argument list
> of subroutine C". C means "make C<$foo> the invocant for method
> ".
>
> Curiously enough, the confusions I'm hearing over this issue are, to me, the
> strongest argument yet for using
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
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;
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
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 knowl
--- 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,
> >
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
> >
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 eag
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 fren
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 {..
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
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
> > ut
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
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
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
> 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
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:
>
> m
> 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;
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
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 associate
--- 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:
>
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
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 m
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:
Tha
> 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
--- 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:
> 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/
>
--- 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:
>
>
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 {
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
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 D
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_tria
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( Po
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, {
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)
sho
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, i
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) i
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.
"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
>> >> function
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 {
>>
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
"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 "
"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 (
Michael Lazzaro wrote:
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it f
On Sat, Jan 18, 2003 at 02:11:37AM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Paul Johnson) writes:
> > That may well be true, but it seems to me that if people's jobs depend
> > on those projects then there is (or could be or should be) a source of
> > funding available, should such be requi
Simon Cozens wrote:
This isn't name-calling; this is a plea for Perl 6 not to become a language
> designed by a committee of ignorant amateurs.
Fortunately there is absolutely no chance of that.
Perl 6 is a language being designed by exactly one person.
And he's neither ignorant, nor an amateur
[EMAIL PROTECTED] (Paul Johnson) writes:
> That may well be true, but it seems to me that if people's jobs depend
> on those projects then there is (or could be or should be) a source of
> funding available, should such be required, namely the companies who are
> (hopefully) making a profit on the
[EMAIL PROTECTED] (Damian Conway) writes:
> True. But I suspect that TPF's position is that, to many people, Perl 6 is
> far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or
> PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the
> Slashcode, or any of a hundred other pro
[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
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> No. I said it was _special_, not _impossible_.
You said in Perl 5 it was X instead of Y. But it turned out to be Y
after all.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote:
> True. But I suspect that TPF's position is that, to many people, Perl 6 is
> far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL,
> or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or
> an
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::Ma
On Fri, Jan 17, 2003 at 03:10:48PM -0800, Damian Conway wrote:
> It's my understanding that TPF is not intending to offer Larry (or Dan)
> another grant for 2003. They feel that too many people have come to see
> TPF's role and contribution to have been limited to Perl 6 (though
> funding Dan was
On Friday, January 17, 2003, at 02:17 PM, Joseph F. Ryan wrote:
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the "perlsub" documentation, which talks
about
"creating your own syntax" with the & prototype. You can do all this
in
Perl 5, and it
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
We should bear in mind that Larry has had some health issues.
And that he's currently unemployed with four children to support.
Other matters are taking precedence at the moment.
Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as
soon see a grant set up for Larry again t
Damian Conway:
# What ~> and <~ do is to (respectively) allow arguments and
# invocants to appear in a different position to normal:
# arguments to the left of the subroutine/method name, and
# invocants to the right of the method's argument list.
#
# So, for subroutine arguments, these are exa
Damian Conway:
# > Brent Dax wrote:
# >> Incorrect.
# No. Your reading was correct. This is a rare case of Brent
# being mistaken.
Ack, sorry to both you and Buddha, and anyone else I inadvertently
confused. Well, at least I'm good enough for this to be considered a
"rare" case. :^)
--Brent Da
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> We should bear in mind that Larry has had some health issues.
> And that he's currently unemployed with four children to support.
> Other matters are taking precedence at the moment.
Hmm... If the Larry and the Perl Foundation would be agreeable.
On 2003-01-17 at 17:17:03, Joseph F. Ryan wrote:
> >But as I see it, the real problem being solved by the new syntax
> >is that grep and map can exist solely as methods on some class
> >in the inheritance tree of @arrays, no global functions required.
> >That is a Good Thing.
> >
>
> In your op
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 an
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 posit
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 wh
--- 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
Dave Whipp wrote:
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer ("->") which was chosen, I think, because it worked well in
the context of a C loop. Consider the following:
$\ = "|"; $, = ",";
Except, of course, those won't exist in Perl 6.
You wan
--- 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
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 th
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 differen
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 w
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
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.
W
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 { ... } ~> gre
On Friday, January 17, 2003, at 10:41 AM, Dave Whipp wrote:
But then we shift our perception to think that -> is an L2R pipe into a
block: not an anonymous sub composer. Similarly, the C function is
a strange thing sends its elements down the pipe, one-by-one -- its not
a loop at afterall! (A ju
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 = gr
[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 o
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 {
"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
* 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
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 =
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 coul
--- 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 e
> 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 speciall
[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 Dissatisfyi
[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 thr
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 coul
1 - 100 of 225 matches
Mail list logo