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 bi
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
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,
--- 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 wa
* 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, ever
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,
>e
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
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 { ...
--- 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)
>
> be
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 man
[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).
[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
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; #
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 t
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; #
--- 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 fo
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 o
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
[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
[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
> 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
--- 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
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
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 =
* 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
"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
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 {
[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
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
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
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 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
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 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
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 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
--- 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
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
--- 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
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
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
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
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
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.
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
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
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
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
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
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
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 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
[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."
[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] (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] (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
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
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
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
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
Michael Lazzaro wrote:
Great -- then I have only one more question, I think. In the words of a
certain cartoon character, what's *this* button do?
my $b is $a;
Syntax error, I'd expect. Though the desired effect could probably be achieved
with the C meta-property:
my $b is prop($a);
D
Jonathan Scott Duff wrote:
> will this:
my $a $b;
be illegal?
I certainly hope so!
Damian
Piers Cawley observed:
BTW, C is just sick!
(i.e. I'll *definitely* be using it ;-)
Surely anyone who does C<< my Array @foo >>, or C<< my Scalar $foo >>
will be using it, albeit indirectly.
Of course, but without the brain-twisting effect of the
repeated classname.
;-)
Damian
63 matches
Mail list logo
