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
--- 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 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).
> 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.
> 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.
> 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
>
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
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 C 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 C 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:
- C, C, 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 C or C method for a subclass of
Array, you don't need to worry about _also_ overriding the universal
C and C 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 C 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. C, 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 C syntax. But whether we like the perl5 C 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. C, 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 C syntax. But whether we like the perl5 C
> 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 C 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 C is missing its block. So it won't actually compile.
So the C 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"
C and C functions.
However, I suspect the correct inference is that Perl 6 will have
C and C *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
Re: L2R/R2L syntax
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 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?
Of course not. Nor is anybody arguing against the utility of
1-liners and short scripts, or the desirability of maintaining
Perl's usefulness for such.
> 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);
> }
In that scenario, if you wanted to alter the behavior of grep, you
could probably get away with just modifying the array method, but
some modifications might require changing the function, too. Having
to change something in two places is generally a bad thing.
> Or even if this function does not exist, there's nothing stopping
> the compiler from simply aliasing:
>
> grep {} @array;
Yes, but the goal is to avoid special cases. If these:
grep {expr} @array
map {expr} @array
become these:
@array.grep({expr})
@array.map({expr})
that violates the standard interpretation of such sequences. The
"indirect object" syntax (assuming that were inferred despite the
lack of a colon) would instead interpret them as this:
{expr}.grep(@array)
{expr}.map(@array)
While if we inverted the IO interpretation of the syntax, then this:
print $STDERR foo
would become this:
foo->print($STDERR)
What we're looking for is a way to keep something close to
the old syntax, but in a more generally applicable way.
Why? Because general rules are, in general (:)), better than special
cases, simply because they result in less stuff to remember. It's true
that you often have to violate that principle to get good usability, and
Perl is the archetypical example of willingness to do so, but that doesn't
mean that the principle itself is bad. It just can be overdone
(and TCL would be my candidate for the archetypical example of overdoing
it).
All that said, one other thing for both sides of this argument to remember
is this: if the final syntax is not to our liking, then there's
nothing to stop us from writing our own - as a global function or whatever.
And there's likely to be a module that supplies the alternative syntax
anyway, possibly even bundled with the distribution.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
RE: L2R/R2L syntax [x-adr][x-bayes]
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. I'd just as soon see a grant set up for Larry again this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. If so, I'm pretty sure I'll be able to match last years' contribution. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: L2R/R2L syntax
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 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
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 exactly equivalent:
#
# ($arg2, $arg3, $arg4) ~> subname $arg1;
# subname ($arg1, $arg2, $arg3, $arg4);
So
@a ~> grep { ... } ~> @b
Is the same as
@b = grep { ... } @a
?
# 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).
...
# Yes. And the inference that most people seem to have drawn
# is that this implies that Perl 6 would still have
# "stand-alone" C and C functions.
#
# However, I suspect the correct inference is that Perl 6 will
# have C and C *multimethods*.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
? And this would automagically get mapped into Array::grep? (Reminds
me of C++ operator overloading for e.g. "operator +(int,
MyStringType)"...)
--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 [x-adr][x-bayes]
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 this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. 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 in fact supporting the much broader benefits of Parrot development and funding me probably benefitted Perl 5 even more than Perl 6). However, I am sure they would welcome feedback on what the community would actually like to donate towards: http://www.perlfoundation.org/index.cgi?page=contacts If so, I'm pretty sure I'll be able to match last years' contribution. [People may not realize what a very generous offer that is. Garrett has been a *major* contributer in the past. And, unless he's living in a parallel economic dimension, funds must be tighter this year.] Damian
Re: L2R/R2L syntax
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.
? And this would automagically get mapped into Array::grep?
No. Both would be explicitly and separately defined.
(Reminds me of C++ operator overloading for e.g. "operator +(int,
MyStringType)"...)
Which is *exactly* why we're doing it slightly differently. ;-)
Damian
Civility, please. (was Re: L2R/R2L syntax)
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 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?) 'kay, let it be noted that I had let that first little zing slide, but I do think we need to be more careful here. I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, unless 'ignorant' is a new synonym for 'disagree with'. Argument by emotion has drawbacks. I could, for example, point out that everyone bitches about how the language needs to be more regular, until you point out an irregularity that they like. Or that people want the language to be cleanly object oriented, unless it means making things act more like objects. And Lord help us if we get into an argument about whether or not putting code on CPAN makes you more of an 'expert' programmer than someone who writes proprietary code for money. Or what 'expert' means, when it comes to Perl, and whether or not such technical prowess is solely proportional to your visibility at Perl-related conferences. Or if Perl5 syntax is truly the pinnacle of language design against no other ideas can hold a candle. So. If people wanted to point out the merits of the old C syntax, _aside_ from the fact that Perl5-did-it-that-way, that would be wonderful. But name-calling needs to go. Let's not light that fuse, OK? :-| MikeL
Re: L2R/R2L syntax [x-adr][x-bayes]
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 in fact supporting the much broader benefits of Parrot > development and funding me probably benefitted Perl 5 even more than Perl > 6). 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? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax [x-adr][x-bayes]
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. Of course, it's my belief that supporting Larry (and Dan) to create Perl 6 is the single most important thing that TPF could do. Because, ultimately, it will benefit all those other projects enormously too. But I'm clearly biased. :-) Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
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 > any of a hundred other projects on which their job depends on a daily basis. 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 backs of those projects. Yes, I know it's not that easy. No one's job depends on Perl 6 or Parrot (yet). Well, hardly anyone's :) Still, I suppose I am preaching to the choir in the wrong chapel. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax
[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."
Re: Civility, please. (was Re: L2R/R2L syntax)
[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. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: L2R/R2L syntax [x-adr][x-bayes]
[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 projects on which their job > depends on a daily basis. Amen to that. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Re: L2R/R2L syntax [x-adr][x-bayes]
[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 backs of those projects. And to what organisation do you suggest such companies make a donation in order to make best use of that funding? -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken
Re: Civility, please. (was Re: L2R/R2L syntax)
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. The rest of us are merely offering suggestions, feedback, and advice. It's important to remember that Larry loves Perl more than any of us, and that he's not about to be seduced into butchering it by the wild suggestions of so-called "ignorant amateurs". Though, of course, he would never *dream* of using that term himself (except perhaps as a profound compliment). On the other hand, I know that Larry cherishes all the "ignorant amateur" suggestions he receives. Because they help him explore the design space. Because they spark counter-ideas. And because they so often encode -- albeit sometimes very cyptically -- truly guileless expressions of real problems that real Perl users experience. Larry is well-known for extracting the nutritional value from these encodings (i.e. the underlying needs and desires they highlight) without swallowing the unpalatable packaging they sometimes come in. It's instructive to review the PSA ratings of the RFCs covered by the first six Apocalypses and consider the fact that Larry almost always rates the problem space addressed by an individual RFC much higher than the solution it proposes. And *then* typically goes on to describe an alternate approach that solves the problem better and far more generally. Personally, I think we're in safe hands. Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
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 required, namely the companies who are > > (hopefully) making a profit on the backs of those projects. Hey! You carefully elided my disclaimer. > And to what organisation do you suggest such companies make a donation in > order to make best use of that funding? It seems to me that TPC would be the perfect vehicle for any company wishing to fund a specific Perl project. Previous disclaimer still applies. But now we are off topic. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax
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 from the next arg.
If the rule was, "you can leave the comma out after any argument, no
matter what type", it would be more consistent. (But a nightmare.)
If the rule was, "you can never leave the comma out", it would be more
consistent. (But cost one more character.)
I'm not saying it's awful, and I'm not saying it's impossible. I'm
*just* saying that p6 does not have that syntax, _UNLESS_ it is given a
similar comma-sucking rule. So, should there be such a rule?
I am contesting the net benefit of the rule for p6. My objections:
1) It's a special case, which is by definition something to be generally avoided.
2) The commaless syntax looks enough like indirect object syntax to
confuse many people. Indirect object syntax (the colon form) is already
creating a lot of confusion, and I'm worried this rule would make
matters worse.
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
4) We have several ways around it: direct object syntax, indirect object
syntax, and pipelike syntax.
This is the sum total of my argument against the perl5 map syntax. May
Larry have mercy on my soul.
:-/
MikeL
Re: L2R/R2L syntax
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 comma to
separate it from the next arg.
If the rule was, "you can leave the comma out after any argument, no
matter what type", it would be more consistent. (But a nightmare.)
If the rule was, "you can never leave the comma out", it would be more
consistent. (But cost one more character.)
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, {...}
:-(
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
Without comma-optionality, their other p6 magic will be much less wonderous.
Damian
Re: Array Questions
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); Damian
Re: Array Questions
Jonathan Scott Duff wrote: > will this: my $a $b; be illegal? I certainly hope so! Damian
Re: Array Questions
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
