At 11:02 AM -0800 1/23/03, Michael Lazzaro wrote:
Yes, no doubt so, and good point. I think I should make it clear
that my speculation on somehow unifying C and C is _not_
an attempt to gut A4, because I like A4 quite a lot. I'm just
thinking out loud about how we could _extend_ A4 in one par
Michael Lazzaro writes:
>
> Think, think. What do these things have in common?
>
> # known from A4
>
> for @a, sub ($x) {...} # primitive spelling
> for @a -> $x {...} # pointy sub, looks great
>
> map {...} @a # old-style map syntax
>
On Wednesday, January 22, 2003, at 07:40 PM, Thomas A. Boyer wrote:
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 promulgate
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
David Storrs <[EMAIL PROTECTED]> writes:
> 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 "poi
--- 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
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
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
> >
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 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
20 matches
Mail list logo
