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 (was Re: Everything is an object.)
On Wed, Jan 15, 2003 at 10:50:57PM -0500, Dan Sugalski wrote: At 12:05 AM + 1/16/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. I was shooting for the good old days of sarcasm that people noticed, but alas I missed. I think dry, unlabled sarcasm may be unwise, considering the number of crazy ideas that have been put forward in all seriousness. Some have even been adopted, and hence redefined as inspired. Nicholas Clark
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/16/03, Austin Hastings wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... -- 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.)
Dan Sugalski [EMAIL PROTECTED] wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... And vt100 consoles ! There are still sysadmins that struggle with a buggy perl script, having rebooted in single user mode, on a production box at 23:15 pm. But this has been already said...
Re: L2R/R2L syntax (was Re: Everything is an object.)
On 2003-01-16 at 11:41:56, Dan Sugalski wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... Unicode may have thousands of characters, but how many of them do you think you'll use often enough to need as keys? Even if Perl6 adopted all the Unicode operators suggested so far and several more, you should easily be able to make them one-modifier or at worst two-modifier keyboard macros. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 8:08 AM -0800 1/16/03, Austin Hastings wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... Perl has never cared about keyboards -- install some of the non-US keyboard layouts and then try typing a relatively normal perl script. Tilde? Brackets? Forward and backticks? Hell, even dollar-signs are scarce in some layouts -- wouldn't want to omit that Lb. or Euro sign. I'm relatively certain that it's a trivial matter to create a Perl IME for windows, if one knows the 2.6 million windows things that must be known to get started (which I sadly don't). That's probably the solution. =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody:
# --- Austin Hastings [EMAIL PROTECTED] wrote:
# It's very much like the good old days of trigraphs. But on the plus
# side, once all the losers get their fonts/xterms/editors
# up-to-speed
# on extended character sets, the trigraphs will die a
# forgotten death.
#
# How about people who can't? Lots of people don't own the
# computer they're using, so to upgrade stuff they'd have to
# ask the sysadmin. And you know what happens when you annoy
# the sysadmin...
I suspect that was sarcasm.
--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 (was Re: Everything is an object.)
--- Brent Dax [EMAIL PROTECTED] wrote: Mr. Nobody: # --- Austin Hastings [EMAIL PROTECTED] wrote: # It's very much like the good old days of trigraphs. But on the plus # side, once all the losers get their fonts/xterms/editors # up-to-speed # on extended character sets, the trigraphs will die a # forgotten death. # # How about people who can't? Lots of people don't own the # computer they're using, so to upgrade stuff they'd have to # ask the sysadmin. And you know what happens when you annoy # the sysadmin... I suspect that was sarcasm. Which was? Mine or Austin's? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday, January 16, 2003, at 08:57 AM, Mark J. Reed wrote: On 2003-01-16 at 11:41:56, Dan Sugalski wrote: And keyboards, don't forget keyboards. These pesky primitive ones we have now would require a lot of shift-control-alt-meta-cokebottle key sequences... Unicode may have thousands of characters, but how many of them do you think you'll use often enough to need as keys? Even if Perl6 adopted all the Unicode operators suggested so far and several more, you should easily be able to make them one-modifier or at worst two-modifier keyboard macros. Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (ƒ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (ω). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @array➌. And @array③ will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL
Re: L2R/R2L syntax (was Re: Everything is an object.)
Glad to see someone heeded that warning about unrecognizable sarcasm; no danger of misinterpretation here . . . :) On 2003-01-16 at 10:01:04, Michael Lazzaro wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (ƒ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (ω). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @array➌. And @array③ will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Michael Lazzaro [EMAIL PROTECTED] wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (Æ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (Ï). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @arrayâzcaron. And @array⢠will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL I think this is a great idea. Until now, it's been possible to read other people's code, so companies can fire a programmer and still have people who can read their code. Now employees will be able to be as bad as they want and nobody will be able to fire them. Job security through Unicode! (Yes, that was sarcasm.) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Michael Lazzaro [EMAIL PROTECTED] wrote: Well, I don't know about anyone else, but *I'm* planning on making many, many Unicode synonyms, to make my code shorter and more readable. For example, Cfor is too long, so I want to just make it curly-f, (Æ). And Cwhen is even longer, so I'm going to use something else, probably lowercase omega (Ï). The numbers-in-a-circle characters can be used for array options. Instead of @array[3], I'll be saying @arrayâzcaron. And @array⢠will mean every element of the array except for the third. I'm still looking for the Unicode sad-faced-clown-on-fire character. When I find it, I think I'm gonna make it mean Cshift. Well, that or Cunshift, I can't decide. It depends on how sad the clown looks. MikeL I think this is a great idea. Until now, it's been possible to read other people's code, so companies can fire a programmer and still have people who can read their code. Now employees will be able to be as bad as they want and nobody will be able to fire them. Job security through Unicode! (Yes, that was sarcasm.) Argh, I just realized the original was probably sarcastic too. Now I look like an idiot. Well, moreso than before. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
[EMAIL PROTECTED] (Mr. Nobody) writes: Argh, I just realized the original was probably sarcastic too. Now I look like an idiot. Well, moreso than before. There has been more than a touch of sarcasm about nearly every post in this thread in the last two days. -- So i get the chance to reread my postings to asr at times, with a corresponding conservation of the almighty leviam00se, Kai Henningsen. -- Megahal (trained on asr), 1998-11-06
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... You remember that stoner kid who always sat at the back of the class and pretty much C/D/F'ed every class? That's what trigraphs are for -- the middle-to-bottom of the curve. If you can't upgrade, and your admin won't upgrade, then you learn to use the trigraphs. Right now almost all of us are in that boat. And we're talking about trigraph ops, like ~ and ~ and |~ and [+=] and whatever. As we get better, more Unicapable, whatever, we'll move on to full Unicode ops. Look at MIME -- once, the only way to email a binary file was with uuencode. A few short years later, presto! Every pinhead in the marketing department is attaching 4 gigabyte pdf files to their corporate spam. It's the same thing -- if people want to do something, and can benefit from it, then they'll drive it to happen. Think about what would have happened if someone argued that NO files should be binary, because we couldn't email binary files -- there'd be no downloadable internet porn. :-( A vote for Unicode is a vote for naked chicks! Go us! =Austin
Re: (AUTORESPONSE)Re: L2R/R2L syntax (was Re: Everything is an object.)
Whoever is working for qlcomm.com tech support and subscribed from work should probably unsubscribe and use a personal account, unless your boss wants 20+ messages per day coming in to your corporate mailbox. --- Administrator [EMAIL PROTECTED] wrote: Dear Customer, Your query has been received. Our Tech Support team will be reverting to you within 8 business hours (India time). You can chat with our Tech Support team via Yahoo Messenger Our ID is qlc_tech. we are online on all working days 9:30 a.m. to 6:30 p.m. (Indian Standard Time) As a long term solution, you could also consider purchasing an Annual Maintainence Contract. PostMaster is supported onsite in over 60 Indian cities. Thank you. At your service, PostMaster Tech Support. QuantumLink Communications Pvt. Ltd. +91 22 24986445-50 CONFIDENTIALITY NOTICE: If you have received this e-mail in error, please immediately notify the sender by e-mail at the address shown. This e-mail transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. -- QuantumLink Communications Pvt Ltd, Bombay, India
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Austin Hastings [EMAIL PROTECTED] wrote: --- Mr. Nobody [EMAIL PROTECTED] wrote: --- Austin Hastings [EMAIL PROTECTED] wrote: --- Simon Cozens [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. It's very much like the good old days of trigraphs. But on the plus side, once all the losers get their fonts/xterms/editors up-to-speed on extended character sets, the trigraphs will die a forgotten death. Oh, glorious future ... =Austin How about people who can't? Lots of people don't own the computer they're using, so to upgrade stuff they'd have to ask the sysadmin. And you know what happens when you annoy the sysadmin... You remember that stoner kid who always sat at the back of the class and pretty much C/D/F'ed every class? That's what trigraphs are for -- the middle-to-bottom of the curve. If you can't upgrade, and your admin won't upgrade, then you learn to use the trigraphs. Right now almost all of us are in that boat. And we're talking about trigraph ops, like ~ and ~ and |~ and [+=] and whatever. As we get better, more Unicapable, whatever, we'll move on to full Unicode ops. Look at MIME -- once, the only way to email a binary file was with uuencode. A few short years later, presto! Every pinhead in the marketing department is attaching 4 gigabyte pdf files to their corporate spam. It's the same thing -- if people want to do something, and can benefit from it, then they'll drive it to happen. Think about what would have happened if someone argued that NO files should be binary, because we couldn't email binary files -- there'd be no downloadable internet porn. :-( A vote for Unicode is a vote for naked chicks! Go us! =Austin trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
[Note: I originally sent this to Mr. Nobody alone, but that wasn't my intent. I'm re-sending it here, where I wanted it to go in the first place. -- bmb] Mr. Nobody wrote: trigraphs are actually better, even if you are unicode capable. ~ is far easier to type than ctrl-u-15F9E2A01 or whatever it is. Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. I can also type or relatively easily as well. (I have no idea how well those will be transmitted on this list. I typed hiragana using the hiragana script, and katakana in katakana, two of the standard character sets of Japan. I'm not sure why I have my computer at work set up to allow me to input Japanese, since I'm not ? ?? nor do I speak ???) But the techniques for typing in funky characters is well known, and easy. Most likely, in the future when I have to work in Perl 6, my editor will be set up so that typing the Unicode squiggly-arrow character will be as simple as typing the two characters '~' and '', just like typing a Spanish N is as easy as typing '~' and 'N' right now. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 04:59:43PM -0500, Buddha Buck wrote: Buddha Buck wrote: Maybe, maybe not On my machine right now, it is very easy for me to type various accented letters, like a, e, etc, making words like resume (or is that resume) nearly as fast to type as the non-accented version resume. Hmmm, that's not what I wrote... On my machine, I had accents on the a and the e, and in the first two forms of resume. There are now four copies of the message in my sent folder (one to Mr. Nobody, one to the list, and two to myself), all of which have the proper characters in it. It appears that an intermediate relayer is converting my utf-8 formatted 8bit messages to us-ascii 7bit messages for no good reason. The Japanese came out badly, as well This would be one of the reasons why I don't think utf-8 perl6 scripts are a good idea. 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 Nicholas Clark
Re: L2R/R2L syntax (was Re: Everything is an object.)
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 :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On 2003-01-16 at 16:42:15, Buddha Buck wrote: [Note: I originally sent this to Mr. Nobody alone, but that wasn't my intent. I'm re-sending it here, where I wanted it to go in the first place. -- bmb] This came in with a content type text/plain, charset=us-ascii. US-ASCII is by definition 7 bits only, so if you're planning on sending Latin-1 accented characters, or UTF-8, or anything else that requires that 8th bit not to be stripped and assumed 0, your email program has to set the headers properly. Doesn't matter what it looks like in your outbox; all the transfer points along the way have to know how to treat the contents, too. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax (was Re: Everything is an object.)
[EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. -- A witty saying means nothing. -Voltaire
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 12:05 AM + 1/16/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing Sounds like the good old days of trigraphs. I was shooting for the good old days of sarcasm that people noticed, but alas I missed. -- 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 Friday, January 10, 2003, 9:05:42 PM, you (mailto:[EMAIL PROTECTED]) wrote: Universe 2 (pro-unicode): If we had a Unicode 'squiggly arrow' operator, then however it looks on everybody's display, it ought to at least look like some kind of squiggly arrow. U+21DC Leftwards Squiggle Arrow and U+21DE Rightwards Squiggle Arrow would seem to fit the bill rather well maybe the ascii ~ and ~ are merely aliases of the true symbols? -- Richard mailto:[EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Sun, Jan 12, 2003 at 11:50:14AM +, Richard J Cox wrote: U+21DC Leftwards Squiggle Arrow and U+21DE Rightwards Squiggle Arrow would seem to fit the bill rather well maybe the ascii ~ and ~ are merely aliases of the true symbols? If we go this route, I would suggest that we use U+219C (Leftwards Wave Arrow) and U+219D (Rightwards Wave Arrow). Not only are they closer to the potential ASCII aliases, but (IMHO) they are more attractive. (Although, of course, both parts of the above may not apply, since the arrows are allowed to be represented differently in different fonts.) To see what the Unicode Consortium thinks they look like: http://www.unicode.org/charts/PDF/U2190.pdf --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- David Storrs [EMAIL PROTECTED] wrote: On Sun, Jan 12, 2003 at 11:50:14AM +, Richard J Cox wrote: U+21DC Leftwards Squiggle Arrow and U+21DE Rightwards Squiggle Arrow would seem to fit the bill rather well maybe the ascii ~ and ~ are merely aliases of the true symbols? If we go this route, I would suggest that we use U+219C (Leftwards Wave Arrow) and U+219D (Rightwards Wave Arrow). Not only are they closer to the potential ASCII aliases, but (IMHO) they are more attractive. (Although, of course, both parts of the above may not apply, since the arrows are allowed to be represented differently in different fonts.) To see what the Unicode Consortium thinks they look like: http://www.unicode.org/charts/PDF/U2190.pdf --Dks Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops.
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Think it through... Perhaps not everyone feels they're a bad idea...? =Austin
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- Thom Boyer [EMAIL PROTECTED] wrote: Mr. Nobody [EMAIL PROTECTED] says: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. OK, now I think I know how _you_ would vote on the subject of Unicode operators. But would you care to share any *reasons* for your position? Yes, Unicode operators would cause us all some growing pains. Is that cost worth the payoff? I don't know -- it's a really tough choice. But I think it's far from being as clear-cut as your post would indicate. Most text editors don't support them. Just try getting utf8 characters into notepad, dos edit, or vi (not vim). Forcing people to get used to a new text editor just to program a new language is not a good idea. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 10:52 AM -0800 1/13/03, Austin Hastings wrote: --- Mr. Nobody [EMAIL PROTECTED] wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Think it through... Perhaps not everyone feels they're a bad idea...? The question, then, is Does Larry? (I already do, but that's not necessarily a showstopper) Requiring things outside the ASCII 7-bit range is problematic, as it requires a Unicode-capable system. That's somewhat troublesome if you're already dealing with an extended ASCII system that's not Unicode. (Full Latin-1, Cyrillic, Japanese, Chinese, or Korean systems, for example, though you can potentially get by) -- 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.)
--- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Because we decided to use them, at least for vector-ops. Take a look at http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=3DD9BBC5.9090209%40conway.org for one of the last messages I could find about vector-op syntax. Is it too late to contest that? I guess if there's going to be unicode operators no matter what, it wouldn't hurt to have a few more :| __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 10:52 AM -0800 1/13/03, Austin Hastings wrote: --- Mr. Nobody [EMAIL PROTECTED] wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: Unicode operators in the core are a very, very, very, very, very, very, very, very, very, very, very, very, very bad idea. We've already had this discussion. We wouldn't be bringing up using unicode operators for this function if we hadn't already talked about unicode operators for other things -- like vector ops. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Think it through... Perhaps not everyone feels they're a bad idea...? The question, then, is Does Larry? (I already do, but that's not necessarily a showstopper) Requiring things outside the ASCII 7-bit range is problematic, as it requires a Unicode-capable system. That's somewhat troublesome if you're already dealing with an extended ASCII system that's not Unicode. (Full Latin-1, Cyrillic, Japanese, Chinese, or Korean systems, for example, though you can potentially get by) In this case, that's not even a consideration -- the original proposal was the ascii7 flavor grin/dragon ops (~ ~). Only later did we say Wait, there's a uniglyph that does this in one (very wide) character!. So the real question should be What kind of upgrade path are we providing for converting these tired old multigraphs into single uniglyphs? To which I add: What's the right behavior / syntax for a I want all multimethods (even ones that haven't instantiated yet, a la AUTOLOAD) with this name here: ~(...) to now be visible as this name here: \u21CD(...) ? (This is only confusing to me because I don't understand the interrelationships between multimethod dispatch and autoload and type conversion/promotion, etc.) =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 11:19 AM -0800 1/13/03, Austin Hastings wrote: So the real question should be What kind of upgrade path are we providing for converting these tired old multigraphs into single uniglyphs? Ah, that's a different question. Having Unicode synonyms may well be considered reasonable thing, though there are then source-interchange problems. Dunno whether that'll be considered a problem, though. (I don't see it as such) -- 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.)
Mr. Nobody wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: Mr. Nobody wrote: --- Buddha Buck [EMAIL PROTECTED] wrote: We've already had this discussion. So if we already talked about why they're such a terrible idea, why are people still proposing them for other things? Because we decided to use them, at least for vector-ops. Is it too late to contest that? If you're going to do so, please make sure you're bringing something new to the argument. Many people have spoken against unicode operators, making many good points. And many people have spoken in favour, and also made some good points. Search Google[*0] for Piers's summary with the phrase Smylers is my hero of the week[*1] and follow the links therein. We stopped discussing the matter after Dan wisely pointed out that neither side was likely to convince the other, and that it was now left for Larry to make a decision. Now that all 'sides' of the discussion seem well aware of the opposing arguments, there doesn't seem much point in repeating them. That is distinctly not the same thing as everybody agreeing! [*0] Not Google Groups, strangely enough, but the webby Google. [*1] I figure that if that gets repeated enough, Googlism might pick it up. I guess if there's going to be unicode operators no matter what, it wouldn't hurt to have a few more :| At least several of the unicode operator proposals included having a non-unicode alternative, so that everything can be typed using ascii (it just might take a few extra characters and look less pretty). So yes, once we've passed the threshold of a unicode operator we may as well look to see what else can be made to look less ugly in unicode. Smylers
RE: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, 10 Jan 2003 14:12:12 +, Thom Boyer wrote: 'Course, then I've gotta explain why $x = 7 ~ 63; doesn't evaluate to 9 Surely because you haven't yet overloaded gozinta for the Number class! -- c
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Friday, January 10, 2003, at 09:56 PM, Damian Conway wrote:
Just out of curiosity, how did you measure that? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) returns Int is exported {
return sum [»ord«split/null/,$x] »-« [»ord«split/null/,$y]
}
and then:
#! /usr/bin/perl6
use Symbol::Readability;
print delta_r('~','|');
How else?
Hrm. What was the output?
=)
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
print sort { ... } ~ mymethod(42) ~ @b;
call sort on what comezouta calling mymethod(42) on what comezouta @b.
I think. Indirect objects are still somewhat confusing. :)
If I'm reading the info right on ~, then we want to make it clear
that you _don't_ put it between print and stuff you want to print, or
in other words that this ain't cout.
If I read the conversations right, I think that line is trying to do:
print (to stream mymethod(@b,42)) sort { ... }
I think to make it work like you wanted, you need ()'s
print (sort { ... } ~ mymethod(42) ~ @b); so that the ~ is directly
associated with the sort; otherwise sort is a param to the print, and
we're comezouta'ing the where do i print sort
and sort takes the how do i sort first and the What do i sort
second, yes? which makes me now wonder about all the sort { ... } ~
examples, and my understanding of the whole where do ~ and ~ stick
things? thing ...
OK, looking back, ~ binds to the indirect object ... and Damian's
examples use map { ... } and grep { ... } with ~'s, so I guess the
indirect object would work the same for sort { ... }, but now I'm not real
sure on what the indirect object IS in all these calls ...
Could someone explain how to know what's the indirect object? (who knew
the sentence diagramming would be USEFUL!!)
--attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
Andy Wardley wrote: s/~=/=~/ Indeed. And that's precisely why we're changing it to ~~ in Perl 6. ;-) The first 3 all relate to the familiar concept of 'minus', or more precisely a delta between two values. The last uses '-' as 'dash', another familiar concept which doesn't grate against the first usage, IMHO. Just as ~ and ~ use ~ as a squiggly dash, which doesn't grate either, IMHO. The arrow is a special case. I don't read that first character as '-', I think of the operator as one. I guess the visual cue forces me to see it like that. I'm suggesting that ~ and ~ will be the same. I'm just suggesting the same for the ~ character: This is where I get lost. I see 4 different concepts being overloaded onto '~'. I'd suggest that that's simply because your brain hasn't yet chunked the various uses of the ~ character in these four multicharacter symbols, the way it already has with the - character. So you read the ~'s as symbols rather than characters within symbols, which leads to the matchy or stringy overtones of their appearance to you. But once that chunking does occur for you -- and I'm suggesting it would -- then ~ and ~ will become atomic symbols in your brain, and I think the issue will disappear. Nevertheless, I deeply respect your concerns and your opinions, and appreciate that you look the time to set them out so clearly. So, we're going to have to agree to differ, I suspect. Having presented our respective arguments cogently in this forum, we can happily sit back and let Larry shoulder the burden of deciding this. Thanks, Andy. Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote: I find the normal function call and assignment far more readable than using some weird ugly operator. and later: That's going to be just plain confusing. Arguments to functions are supposed to be on the right. And what's up with using them for assignment? That's making them even more overcomplicated and ugly. Do you care about readability at all? You know, I usually find this kind of unsupported, emotive, ad hominen attack utterly unconvincing. But in this case, I find that your novel approach to our collaborative discussion *has* convinced me of something. *PLONK* Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- attriel [EMAIL PROTECTED] wrote: Could someone explain how to know what's the indirect object? (who knew the sentence diagramming would be USEFUL!!) Short version: If there's two people in the sentence, the verb-ee is either the direct or indirect object. If there's two people and a thing, the -ee is indirect. I hit him. (He's the direct object.) I gave the ball to him. (Ind.) In reality, the reference to indirect object is a bogus equivalence, because we're really making the SUBJECT of the sentence, as hit him :I becomes I.hit(him) However, the original term was a reference to Using an OBJECT's method INDIRECTly, hence indirect object notation. Just to make things less simple. =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway said: Andy Wardley wrote: The arrow is a special case. I don't read that first character as '-', I think of the operator as one. I guess the visual cue forces me to see it like that. I'm suggesting that ~ and ~ will be the same. I think that in part this may depend on the font being used. When I first saw these symbols, via webmail on a browser, the tilde appeared half way down the character, in the same position as the dash. This made it obvious to me that it was an arrow of some sort, and it looked good. When I later saw it using mutt in an xterm, the tilde was at the top of the character, where I was more used to seeing it and it didn't look like an arrow any more, nor did it look very good to me. This is the way it looks on my browser ~ When I get home I'll mail a message showing how it looks in my xterm ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Friday 10 January 2003 11:42 am, Paul Johnson wrote: Damian Conway said: Andy Wardley wrote: The arrow is a special case. I don't read that first character as '-', I think of the operator as one. I guess the visual cue forces me to see it like that. I'm suggesting that ~ and ~ will be the same. I think that in part this may depend on the font being used. True. It looks horrid in misc-fixed-* (what I'm assuming Paul has in his xterm).
RE: L2R/R2L syntax (was Re: Everything is an object.)
Paul Johnson [EMAIL PROTECTED] wrote: When I later saw it using mutt in an xterm, the tilde was at the top of the character, where I was more used to seeing it and it didn't look like an arrow any more, nor did it look very good to me. Well, at least now I understand why some people didn't see the squiggly arrow immediately, as I did. It seemed so obvious to MY eyes, I couldn't understand what the big deal was. I have been (quietly) siding with the let's use unicode characters as operators camp. But this little brouhaha has me splitting into two universes: Universe 1 (anti-unicode): If we have this much trouble seeing a tilde the same way, what are the chances that all these cool new operators will be visually comparable to all P6 coders? Universe 2 (pro-unicode): If we had a Unicode 'squiggly arrow' operator, then however it looks on everybody's display, it ought to at least look like some kind of squiggly arrow. We'll say goodbye now. =thom Delusions are often functional. A mother's opinions about her children's beauty, intelligence, goodness et cetera ad nauseam, keep her from drowning them at birth. --Lazarus Long
RE: L2R/R2L syntax (was Re: Everything is an object.)
Andrew Rodland [EMAIL PROTECTED] wrote: But you're missing the most important part! I propose that these operators should be named gozinta ( ~) and comezouta ( ~ ), just so that we can say that perl has them. Not to mention that the names work pretty well, for me. Here, here! All in favor, say Aye! 'Course, then I've gotta explain why $x = 7 ~ 63; doesn't evaluate to 9 :-) =thom Be wary of strong drink. It can make you shoot at tax collectors...and miss. --Lazarus Long
Re: L2R/R2L syntax (was Re: Everything is an object.)
Date: Fri, 10 Jan 2003 08:12:48 -0800 (PST) From: Austin Hastings [EMAIL PROTECTED] --- attriel [EMAIL PROTECTED] wrote: Could someone explain how to know what's the indirect object? (who knew the sentence diagramming would be USEFUL!!) Short version: If there's two people in the sentence, the verb-ee is either the direct or indirect object. If there's two people and a thing, the -ee is indirect. I hit him. (He's the direct object.) I gave the ball to him. (Ind.) In reality, the reference to indirect object is a bogus equivalence, because we're really making the SUBJECT of the sentence, as And the one we're modeling it after in Perl is: I gave him the ball. In Perl 6: gave him: the ball; But a better sentence to use as an example here would be a command, as most imperative (computer) languages use: Give the ball to him. Or equivalently, Give him the ball. In Perl 6: give him: the ball; And as you can see, it is no longer a misnomer. The subject is implicitly you or (in a Star Trek sense) computer. hit him :I becomes I.hit(him) I don't think so. Rather, that becomes: him.hit(I); And to clarify, you should probably format it like this: hit him: I; But computer languages aren't generally used to specify past tense anyway To summarize, the indirect object goes Ibetween the verb and the direct object, before the colon. Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Paul Johnson wrote: When I later saw it using mutt in an xterm, the tilde was at the top of the character, where I was more used to seeing it and it didn't look like an arrow any more, nor did it look very good to me. Ah yes, that's the problem. On all my fonts, the tilde appears at the top and it doesn't look anything like an arrow. Viewing it on a web browser with the tilde centered vertically does indeed bring out the arrow-ness of it. A
Re: L2R/R2L syntax (was Re: Everything is an object.)
I don't know about *your* font, but in mine the ~ and ~ versions are
at least twice as readable as the | and | ones.
Just out of curiosity, how did you measure that? ;-)
Well, obviously, I used the Symbol::Readability module:
module Symbol::Readability;
sub delta_r(Str $a, Str $a) returns Int is exported {
return sum [»ord«split/null/,$x] »-« [»ord«split/null/,$y]
}
and then:
#! /usr/bin/perl6
use Symbol::Readability;
print delta_r('~','|');
How else?
;-)
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Philip Hellyer wrote: Damian's proposal didn't say anything about array params. If I understood him correctly, then this should print FOO on standard out: my $foo = FOO; $foo ~ print; Correct. The opposite 'squiggly arrow' fiddles the indirect object, so perhaps this would print FOO on standard error (modulo the STDERR syntax, which I think changed when I wasn't looking): $foo ~ print ~ STDERR; Bad Philip! Wicked, wicked Philip! ;-) One *might* argue that ~ ought to be of higher precedence than ~ (i.e. that invocants ought to be bound ahead of other arguments). If so, then: $foo ~ print ~ $*STDERR is really: $foo ~ print $*STDERR: is really: $foo ~ print $*STDERR: $foo So yes. But don't do that! ;-) Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Jonathan Scott Duff suggested:
Oh, then we just need a syntax to split the streams. ... I know!
@list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep;
Unfortunately, that's already taken (it's the bitwise-OR-on-a-string operator).
Fortunately that doesn't matter, since no extra binary operator is actually
needed to achieve the unzipping you desire.
All we need is a unary prefix form of ~.
Unary ~ would (by analogy to unary dot) append the current topic to the
argument list of its operand.
Thus, your examples become simply:
given @list {
~ grep /bad!/ ~ @throw;
~ grep /good/ ~ @keep;
}
And:
given @list {
~ grep length == 1 ~ @onecharthings;
~ grep [0..29] ~ @numberslessthan30;
~ grep /^\w+$/ ~ @words;
~ grep $_%2==0 ~ @evennumbers;
}
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; Correct, if ~ is indeed slightly higher precedence than ~ which is probably not what i wanted... True. The presence of both operators in an expression probably ought to trigger a (silenceable) warning. Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
Andy Wardley wrote:
I also think this is semantically fabulous but syntactically slightly
dubious. '~' reads 'match' in my book,
Really? We don't have any trouble in Perl 5 with an = character
being used in various unrelated operators:
== comparison
=assignment
~= match
= comma
= less than or equal to
or with - as a component of each of:
-- decrement
-difference
-= subtraction
- dereference
-X file op
I'm just suggesting the same for the ~ character:
~~ smart-match
~concatenate
~| stringy bitwise OR
~ append args
~ invocate
I would prefer something like | and | which has a more obvious
connotation (to me at least) of pipe left or pipe right.
I can certainly see the appeal, and I did consider this very alternative
(after Dan had privately suggested the two symbols to me). But they simply
don't work as well visually.
I mean, compare:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
@a ~ sort ~ map {...} ~ grep {...} ~ @a;
with:
@a | grep {...} | map {...} | sort | @a;
@a | sort | map {...} | grep {...} | @a;
I don't know about *your* font, but in mine the ~ and ~ versions are
at least twice as readable as the | and | ones.
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
In a message dated Thu, 9 Jan 2003, Damian Conway writes: One *might* argue that ~ ought to be of higher precedence than ~ (i.e. that invocants ought to be bound ahead of other arguments). If so, then: $foo ~ print ~ $*STDERR is really: $foo ~ print $*STDERR: is really: $foo ~ print $*STDERR: $foo So yes. But don't do that! Well, shades of C++, how about just $*STDERR ~ $foo; or $foo ~ $*STDERR; ? Stylistically, I often find myself needing to embed a complex expression in a print(), and as anyone who's read my articles knows, I really despise parens in normal sub calls (not method calls). Yes, yes, I could do $*STDERR.print() instead, but I'm trying to reduce visual clutter, not resort to a mechanism that requires it :-) Trey -- I'm looking for work. If you need a SAGE Level IV with 10 years Perl, tool development, training, and architecture experience, please email me at [EMAIL PROTECTED] I'm willing to relocate for the right opportunity.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway wrote:
Really? We don't have any trouble in Perl 5 with an = character
being used in various unrelated operators:
== comparison
=assignment
~= match
s/~=/=~/
= comma
= less than or equal to
But these are all roughly related to the concept of equality, be it
testing equality, enforcing equality by assignment, equality in terms of
matching a pattern, setting a parameter to equal a value, testing is
something is equal or less than equal to something else.
The use of '=' seems entirely consistent in these operators.
-- decrement
-difference
-= subtraction
- dereference
-X file op
The first 3 all relate to the familiar concept of 'minus', or more
precisely a delta between two values. The last uses '-' as 'dash',
another familiar concept which doesn't grate against the first usage,
IMHO. The arrow is a special case. I don't read that first character
as '-', I think of the operator as one. I guess the visual cue forces
me to see it like that.
These operators may not be internally self-consistent, but I don't think
it's a problem having different meaning for '-', given that both meanings
are well understood to anyone who knows basic math and has used a command
line program with a -x argument.
I'm just suggesting the same for the ~ character:
~~ smart-match
~concatenate
~| stringy bitwise OR
~ append args
~ invocate
This is where I get lost. I see 4 different concepts being overloaded
onto '~'.
In the first it indicates 'match' just as it always has for =~ and !~.
In the second, it is being used for concatentation - nothing to do with
matching. In the third it is being used to cast stringwisely - nothing
to do with matching or concatenation. In the fourth and fifth it is being
used to re-order arguments - nothing to do with matching, concatenation
(well, possibly concatenation of argument lists) or stringwise casting.
Now that I look at it again, the '~~' operator bothers me in particular.
The first '~' seems to indicate 'stringwise' in keeping with '~|'
and the second implies 'match' in keeping with '=~'.
I find it questionable to use the same character twice in one operator
and have different semantics implied for each. '~' should either be
'match' or 'stringwise' but not both.
I would like to see '~' kept for matching and just matching. It is well
known in this role and is analogous to the roughly equals operator
in the Real World (extended ASCII character 247 - just don't ask me to type
it).
I also think '_' should be used for concatenation because it's in keeping
with the existing use of 123_456.
As a prefix character to indicate stringwise (numberwise, bitwise, etc)
casting, can we not use a single character prefix, e.g. 's' for string,
'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
$a s| $b;# stringwise
$a b| $b;# bitwise
$a n| $b;# numberwise
@a v| @b;# vector
@a vsn| @b; # vector stringwise bitwise
I see these as being similar to regex flags. In a regex we don't
have two separate metacharacters for matching \w case sensitively or
insensitively. Instead we use the 'i' flag outside the regex or
within the regex, scoping the parts of the pattern to which it applies:
m/foo/i
m/(?i:foo)/
m:i/foo/
I think we should adopt the same strategy for regular operators. Rather
than create umpteen new operators to perform every operation in every
different style, we should keep the operation orthogonal to the context
in which the operator is applied. So instead of having a vector addition
operator, we have an addition operator and a vector flag which can be
applied to it.
I mean, compare:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
with:
@a | grep {...} | map {...} | sort | @a;
I don't know about *your* font, but in mine the ~ and ~ versions are
at least twice as readable as the | and | ones.
In my font, or perhaps more importantly, to my eye, the | and | are
more readable. But regardless, I think it's more important to make the
operators consistent with each other, than to make them look pretty or
easy to read. The latter is important, of course, but I personally believe
that it's no use making something easy to read if the meaning is still hard
to comprehend. Better to make something harder to read but easier to
understand.
A
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody wrote:
I don't like either of these operators. What's wrong with
@out = sort map {...} grep {...} @a
?
For a start, if these functions were to become (only) methods in Perl 6,
it would have to be:
@out = sort map grep @a: {...} : {...} :;
And even if we do have both functional and methodical versions, this:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
is still clearer in its intent than:
@out = sort map {...} grep {...} @a;
And the squiggly version is also reversible, for those who are more
comfortable with reading left-to-right.
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
Plus we get a tee functionality from unary ~.
Damian
Re: L2R/R2L syntax (was Re: Everything is an object.)
I'm just suggesting the same for the ~ character:
~~ smart-match
~concatenate
~| stringy bitwise OR
~ append args
~ invocate
This is where I get lost. I see 4 different concepts being overloaded
onto '~'.
In the first it indicates 'match' just as it always has for =~ and !~.
In the second, it is being used for concatentation - nothing to do with
matching. In the third it is being used to cast stringwisely - nothing
to do with matching or concatenation. In the fourth and fifth it is
being used to re-order arguments - nothing to do with matching,
concatenation (well, possibly concatenation of argument lists) or
stringwise casting.
Well, I always used =~ // for strings, and (from what I gather) ~~ is the
uber =~ in that it can figure out types and meaningfully guess what
matches means, so I see the first 3 as string toys, just as the -- -
and -= were all subtraction
I'll give you that ~ and ~ don't do stringy things, though :) But I
think they'd be read, once it's more than theories in email messages ;o,
as single ops (like the -) rather than squiggly and arrow it'd be
squigglyarrow ... I think the major concern would, to me, be that ~ and
- are kinda close, visually, and I imagine nearly indistinguishable in
some fonts :/
I would like to see '~' kept for matching and just matching. It is well
known in this role and is analogous to the roughly equals operator in
the Real World (extended ASCII character 247 - just don't ask me to type
it).
Now you've given them ideas :) we're all gonna be typing #8776; (OK, so,
all I can get is that it's unicode 2248; still haven't figured out how to
ACTUALLY type it :o Alt-247() seems to be the wrong character though and
I don' see it anywhere on my HTML ascii chart :/
I also think '_' should be used for concatenation because it's in
keeping with the existing use of 123_456.
That actually reads like _ is a null character This is not the character
you are looking for. There is no character, there is only zool kinda
thing ... I know it's concat, but it reads more like a visual separation
character that is COMPLETELY ignored by the parser, except insofar as to
explicitly ignore it
As a prefix character to indicate stringwise (numberwise, bitwise, etc)
casting, can we not use a single character prefix, e.g. 's' for string,
'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
$a s| $b;# stringwise
$a b| $b;# bitwise
$a n| $b;# numberwise
@a v| @b;# vector
@a vsn| @b; # vector stringwise bitwise
I think this was brought up during the operators thread (I admit, I only
skimmed it ... I had 6 or 7 versions in my inbox when I got to it :/) and
the againsts pointed out that it would mandate whitespace separation
(although, some of the coders I know could live with some mandatory style
guidelines, ugh) ...
I mean, compare:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
with:
@a | grep {...} | map {...} | sort | @a;
I don't know about *your* font, but in mine the ~ and ~ versions are
at least twice as readable as the | and | ones.
In my font, or perhaps more importantly, to my eye, the | and | are
more readable. But regardless, I think it's more important to make the
To me, for some reason, | reads as a forward gate Do not continue unless
the previous item was true; if it was, feed the result here ... |
doesn't read like much, and | looks like some 1337 h4xx0r trying to be
cool, honestly :o It just looks broken! As an op, I would expect it to
translate to OR Less Than and I can't come up with how to use that $a
== 7 | 200 I guess :o
And would the consistency rules require them to be:
~ ~ ? so that the ops look similar? (If so, I'm gonna vote that ~
looks like a fish and is just weird :)
--attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway writes:
Unary ~ would (by analogy to unary dot) append the current topic to the
argument list of its operand.
Thus, your examples become simply:
given @list {
~ grep /bad!/ ~ @throw;
~ grep /good/ ~ @keep;
}
And:
given @list {
~ grep length == 1 ~ @onecharthings;
~ grep [0..29] ~ @numberslessthan30;
~ grep /^\w+$/ ~ @words;
~ grep $_%2==0 ~ @evennumbers;
}
Damian
but if I dont want to force @list in scalar context ???
since ~ and friends are _pure_ grammar while given is not ,
probably we can have unary postfix ~ ( or |~ )
{
@list ~ ; # ( or @list |~ ; )
~ grep length == 1 ~ @onecharthings;
~ grep [0..29] ~ @numberslessthan30;
~ grep /^\w+$/ ~ @words;
~ grep $_%2==0 ~ @evennumbers;
}
as a way to multiplex @list
arcadi
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Damian Conway [EMAIL PROTECTED] wrote:
Mr. Nobody wrote:
I don't like either of these operators. What's wrong with
@out = sort map {...} grep {...} @a
?
For a start, if these functions were to become (only) methods in Perl 6,
it would have to be:
@out = sort map grep @a: {...} : {...} :;
That's why I want them to be normal functions, not methods.
And even if we do have both functional and methodical versions, this:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
is still clearer in its intent than:
@out = sort map {...} grep {...} @a;
I find the normal function call and assignment far more readable than using
some weird ugly operator.
And the squiggly version is also reversible, for those who are more
comfortable with reading left-to-right.
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
That's going to be just plain confusing. Arguments to functions are supposed
to be on the right. And what's up with using them for assignment? That's
making them even more overcomplicated and ugly. Do you care about readability
at all? It seems to me that ~ and ~ have no use except making perl 6 uglier
and more complicated than it already is. They're completely unnecessary.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
That's going to be just plain confusing. Arguments to functions are
supposed
to be on the right. And what's up with using them for assignment? That's
making them even more overcomplicated and ugly. Do you care about
readability
at all? It seems to me that ~ and ~ have no use except making perl 6
uglier
and more complicated than it already is. They're completely unnecessary.
1) Arguments to functions are supposed to be on the right.
Hmmm. If you use a mathematical context, I guess supposed to could be code
for I've always done it that way. But certainly not supposed to in any
cosmic sense.
But what The Damian is proposing is much more like a Unix pipeline than
mathematics.
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
makes much more sense when you see it as being much more akin to
cat a | grep ... | tr ... | sort out
than
let out = sort(map {...} (grep {...} @a))
No, it's not like the math that is one of Perl's influences. It's like the
Unix shells, which is another of Perl's influences.
2) And what's up with using them for assignment? That's making them even
more overcomplicated and ugly.
If you read ~ and ~ as stuff this thingy into that doohicky, assignment
makes perfect sense. They are plumbing connectors: sometimes they connect
the water softener to the water heater (one device to another), and
sometimes they connect to the water supply (a source) or the sink (a sink).
I don't see that as an overcomplication, but as a very straightforward and
obvious extension.
3) Do you care about readability at all? It seems to me that ~ and ~
have no use except making perl 6 uglier and more complicated than it already
is.
I think ~ and ~ look pretty nice. They read well as a single symbol, they
make good sense, they make it possible to say more directly exactly what
your code means, they show the direction of data flow quite well, and the
ripply water look emphasizes the plumbing analogy.
=thom
Tom MacKenzie: Say, Jubal...how do you feel about astrology?
Jubal Harshaw: Never touch the stuff. Prefer brandy.
--Stranger in a Strange_Land
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 09, 2003 at 11:01:51AM -0700, Thom Boyer wrote: Mr. Nobody [EMAIL PROTECTED] wrote: 3) Do you care about readability at all? It seems to me that ~ and ~ have no use except making perl 6 uglier and more complicated than it already is. I think ~ and ~ look pretty nice. They read well as a single symbol, they make good sense, they make it possible to say more directly exactly what your code means, they show the direction of data flow quite well, and the ripply water look emphasizes the plumbing analogy. Yep. The only niggling problem that I have is that ~ and ~ aren't stringy but the look like they should be. If we hadn't already taken -, I'd've preferred to see - and - instead. But, I'm sure I'll be happy with whatever Larry decides. He always seems to apply the appropriate discriminator in his synthesis of ideas. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- Thom Boyer [EMAIL PROTECTED] wrote:
Mr. Nobody [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
That's going to be just plain confusing. Arguments to functions are
supposed
to be on the right. And what's up with using them for assignment? That's
making them even more overcomplicated and ugly. Do you care about
readability
at all? It seems to me that ~ and ~ have no use except making perl 6
uglier
and more complicated than it already is. They're completely unnecessary.
1) Arguments to functions are supposed to be on the right.
Hmmm. If you use a mathematical context, I guess supposed to could be
code
for I've always done it that way. But certainly not supposed to in any
cosmic sense.
But what The Damian is proposing is much more like a Unix pipeline than
mathematics.
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
makes much more sense when you see it as being much more akin to
cat a | grep ... | tr ... | sort out
than
let out = sort(map {...} (grep {...} @a))
No, it's not like the math that is one of Perl's influences. It's like the
Unix shells, which is another of Perl's influences.
It's not letting you do anything that you couldn't do before with normal
function calls and assignment.
2) And what's up with using them for assignment? That's making them even
more overcomplicated and ugly.
If you read ~ and ~ as stuff this thingy into that doohicky, assignment
makes perfect sense. They are plumbing connectors: sometimes they connect
the water softener to the water heater (one device to another), and
sometimes they connect to the water supply (a source) or the sink (a sink).
I don't see that as an overcomplication, but as a very straightforward and
obvious extension.
I see it as making a bad idea even worse. I've never liked having one thing
doing multiple completely different and ambiguous actions. (Does $a ~ $b
mean $b.($a) or $b = $a? How about if $a ~ foo {...}?)
3) Do you care about readability at all? It seems to me that ~ and ~
have no use except making perl 6 uglier and more complicated than it
already
is.
I think ~ and ~ look pretty nice. They read well as a single symbol, they
make good sense, they make it possible to say more directly exactly what
your code means, they show the direction of data flow quite well, and the
ripply water look emphasizes the plumbing analogy.
I agree that they look nice. It's a shame that they're being used for such an
awful proposal.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- Mr. Nobody [EMAIL PROTECTED] wrote:
--- Thom Boyer [EMAIL PROTECTED] wrote:
Mr. Nobody [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
That's going to be just plain confusing. Arguments to functions
are
supposed
to be on the right. And what's up with using them for assignment?
That's
making them even more overcomplicated and ugly. Do you care about
readability
at all? It seems to me that ~ and ~ have no use except making
perl 6
uglier
and more complicated than it already is. They're completely
unnecessary.
1) Arguments to functions are supposed to be on the right.
Hmmm. If you use a mathematical context, I guess supposed to
could be
code
for I've always done it that way. But certainly not supposed to
in any
cosmic sense.
But what The Damian is proposing is much more like a Unix pipeline
than
mathematics.
@a ~ grep {...} ~ map {...} ~ sort ~ @out;
makes much more sense when you see it as being much more akin to
cat a | grep ... | tr ... | sort out
than
let out = sort(map {...} (grep {...} @a))
No, it's not like the math that is one of Perl's influences. It's
like the
Unix shells, which is another of Perl's influences.
It's not letting you do anything that you couldn't do before with
normal
function calls and assignment.
Actually, this is false. The notion of directional pipeline operators
immediately begat two children, to wit:
1- The notion of simultaneous, synchronous execution of pipes, as in:
a ~ b ~ m ~ y ~ z;
Which people have sort of backed away from, but I think there still
might be something there, even if I can't personally set it yet.
2- It also (re) introduced the conceptual framework of unix pipes,
which immediately led to the (IMO: really good) suggestion of a tee
mechanism:
widget ~| expr a ;
~| expr b ;
~| expr c ;
And that one, I think, conceals a whole boatload of conceptual power.
So to me the pipeline operators are kind of like the ?: operator --
true, you don't need it (you could use Cif) but it enables other
things. Except in this case it might enable some really cool things.
And don't worry about the ~ syntax looking awkward. We'll probably
convert it to a Unicode special character in production :-) :-) :-).
=Austin
RE: L2R/R2L syntax (was Re: Everything is an object.)
Mr. Nobody:
# It's not letting you do anything that you couldn't do before
# with normal function calls and assignment.
We're writing a useful language, not a Turing machine.
# I see it as making a bad idea even worse. I've never liked
# having one thing doing multiple completely different and
# ambiguous actions. (Does $a ~ $b mean $b.($a) or $b =
# $a? How about if $a ~ foo {...}?)
It means C$a.infix:~($b), where $a's class inherits:
method infix:~ (Perl6::Call $call);
method infix:~ (Code $sub);
method infix:~ ($target);
Or somesuch.
# I agree that they look nice. It's a shame that they're being
# used for such an awful proposal.
He was saying that they look nice for this application, so you obviously
don't agree.
--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 (was Re: Everything is an object.)
On Thursday, January 9, 2003, at 03:05 AM, Damian Conway wrote: I don't know about *your* font, but in mine the ~ and ~ versions are at least twice as readable as the | and | ones. Just out of curiosity, how did you measure that? ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday 09 January 2003 01:01 pm, Thom Boyer wrote:
If you read ~ and ~ as stuff this thingy into that doohicky, assignment
makes perfect sense. They are plumbing connectors: sometimes they connect
the water softener to the water heater (one device to another), and
sometimes they connect to the water supply (a source) or the sink (a sink).
I don't see that as an overcomplication, but as a very straightforward and
obvious extension.
Agreed. I think that this is pretty nice.
3) Do you care about readability at all? It seems to me that ~ and ~
have no use except making perl 6 uglier and more complicated than it
already is.
I think ~ and ~ look pretty nice. They read well as a single symbol, they
make good sense, they make it possible to say more directly exactly what
your code means, they show the direction of data flow quite well, and the
ripply water look emphasizes the plumbing analogy.
But you're missing the most important part!
I propose that these operators should be named gozinta ( ~)
and comezouta ( ~ ), just so that we can say that perl has them. Not to
mention that the names work pretty well, for me.
Observe:
@a ~ map { ... } ~ grep { ... } ~ sort { ... } ~ @b;
@a gozinta map, which gozinta grep, then it gozinta sort, then it all gozinta
@b.
print sort { ... } ~ mymethod(42) ~ @b;
call sort on what comezouta calling mymethod(42) on what comezouta @b.
I think. Indirect objects are still somewhat confusing. :)
If I'm reading the info right on ~, then we want to make it clear that you
_don't_ put it between print and stuff you want to print, or in other words
that this ain't cout.
Anyway, cool beans. :)
-- Andrew hobbs Rodland arodland at noln dot com
P.S. Delurk. Hi.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Date: Wed, 08 Jan 2003 12:14:10 +0800
From: Damian Conway [EMAIL PROTECTED]
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
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;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
Further suppose that ~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort ~ map {...} ~ grep {...} ~ @a;
Or, under a special rule for variables on the LHS:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the expressions
actually *look* like processing sequences.
I think this is a big step towards readability. It allows you to put
whatever part of the expression wherever you want (reminiscent of
Latin); i.e. always keep the important parts standing out. I also
think that the operator (especially a cool 3d-looking one like ~) is
also much more readable than a word in this case.
It's a shame ~ is ambiguous. It's a lexical ambiguity, which can be
solved with whitespace
Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote: I think this is a big step towards readability. It allows you to put whatever part of the expression wherever you want (reminiscent of Latin); You didn't think Perligata was just for *fun*, did you? ;-) It's a shame ~ is ambiguous. It's a lexical ambiguity, which can be solved with whitespace ...and the longest token rule. And, of course, it's no more ambiguous than the ~~ operator: foo ~~ $bar # means: foo() ~~ $bar # not: foo( ~ ~$bar ) Damian
RE: L2R/R2L syntax (was Re: Everything is an object.)
# Damian Conway wrote:
# @out = sort ~ map {...} ~ grep {...} ~ @a;
#
# Or, under a special rule for variables on the LHS:
#
# @out ~ sort ~ map {...} ~ grep {...} ~ @a;
Hello,
Can one see it as a shell redirection/pipe? This may sound funny,
but is the following ok?
@b ~ @a ~ @c; # @c = @b = @a;
(@b ~ @a) ~ @c; # same order i guess
so one can also:
@keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;
is this if valid too?
@b ~ @a ~ @c; # push @a, @b, @c;
or: @b, @c ~ push @a;
qw/hello world/ ~ print
I guess it modifies $_
print $_ \t %stat{$_} \n ~ grep /^[Aa]/ ~ keys %stat
print $_ \t %stat{$_} \n for grep /^[Aa]/, keys %stat
Could we get pairs (or more), and also something like a step, for
example to only take one array elements every two?
Have a nice day,
Frederic
Re: L2R/R2L syntax (was Re: Everything is an object.)
frederic fabbro [EMAIL PROTECTED] wrote: Can one see it as a shell redirection/pipe? This may sound funny, but is the following ok? @b ~ @a ~ @c; # @c = @b = @a; (@b ~ @a) ~ @c; # same order i guess so one can also: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; is this if valid too? @b ~ @a ~ @c; # push @a, @b, @c; or: @b, @c ~ push @a; qw/hello world/ ~ print Just add ^~ and v~ and we've got our own Befunge flavor.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
@out = @a ~ grep {...} ~ map {...} ~ sort;
@out = sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can ~ and ~ be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
@a ~ grep (...) ~ sort ~ for ~ map (...) ~ @b {
(for content goes here)
}
With the understanding that
(1) EWWW, that is horribly ugly, but it was the first thing I could come
up with that meaningfully takes two list args
(2) Anyone who ACTUALLY does this with a for be shot on sight?
It would be more meaningful in another function that takes two lists and
does something useful, but without a body block ... More of a
@a ~ grep (...) ~ apply ~ sort ~ @b ;
So that the grep'd elements of @a are applied, 1:1, to the sorted @b ... ala
apply (grep (..., @a), sort(@b));
(again, more useful for a longer chain)
--attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
Atriel:
Damian:
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
@out = @a ~ grep {...} ~ map {...} ~ sort;
@out = sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can ~ and ~ be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
Damian's proposal didn't say anything about array params. If I understood
him correctly, then this should print FOO on standard out:
my $foo = FOO;
$foo ~ print;
The opposite 'squiggly arrow' fiddles the indirect object, so perhaps this
would print FOO on standard error (modulo the STDERR syntax, which I think
changed when I wasn't looking):
$foo ~ print ~ STDERR;
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should ensure this E-mail is checked for viruses. The Carphone Warehouse Group PLC
makes no representations as regards the absence of viruses in this E-mail. If you have
received this E-mail in error please notify our ISe Response Team immediately by
telephone on + 44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
immediately destroy this E-mail and any copies of it.
Please feel free to visit our website:
UK
http://www.carphonewarehouse.com
Group
http://www.phonehouse.com
RE: L2R/R2L syntax (was Re: Everything is an object.)
(b) Can ~ and ~ be used at the same time? I'm not entirely sure of what functions take two array params meaningfully, but could we do: Damian's proposal didn't say anything about array params. If I understood him correctly, then this should print FOO on standard out: DOH! All the examples were using @'s, and somehow that translated to this is an array opthingy :o $foo ~ print ~ STDERR; That makes a fair amount of sense (and certainly more than any of my array-based flawed examples :) Thanks for clearing up my fogginess :o --attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
# Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote: # frederic fabbro [EMAIL PROTECTED] wrote: # so one can also: # @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; # # is this if valid too? # @b ~ @a ~ @c; # push @a, @b, @c; # or:@b, @c ~ push @a; # qw/hello world/ ~ print # # Just add ^~ and v~ and we've got our own Befunge flavor. Hehe, yep ;-) I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Frederic
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Damian Conway [EMAIL PROTECTED] wrote:
@out = @a ~ grep {...} ~ map {...} ~ sort;
...
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence
of
~ and ~ eliminate the need for parens, and (best of all) the
expressions
actually *look* like processing sequences.
Brilliant! Keep pushing this. Finally, I'll be able to get investor
backing for my USB foot-pedal shift-key device. They say the first 20
million is the hardest...
Woo-hoo!
Q: How do you recognize a perl6 programmer?
A: His pinky is bigger than his thumb.
=Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Oh, then we just need a syntax to split the streams. ... I know! @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; which, of course, could be written in the more readable form: @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; And that, of course, leads us to sort of unzip were mutual exclusion is not a requisite: @list ~| grep length == 1 ~ @onecharthings ~| grep [0..29] ~ @numberslessthan30 ~| grep /^\w+$/ ~ @words ~| grep $_%2==0 ~ @evennumbers; :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Wed, Jan 08, 2003 at 08:31:51AM -0800, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
@out = @a ~ grep {...} ~ map {...} ~ sort;
...
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
For the record, I think this is great.
Brilliant! Keep pushing this. Finally, I'll be able to get investor
backing for my USB foot-pedal shift-key device.
http://www.tuxedo.org/~esr/jargon/html/entry/double-bucky.html
--Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 8 Jan 2003 11:30:51 -0500 (EST) From: attriel [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ Note 1) This is the second time I'm typing this Note 2) Ctrl-Shift-Capslock apparently closes all current instances of mozilla ... that was weird I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... I would, from the descriptions, imagine that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Would parse as: @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Nope. ~ and ~ only *rearrange* arguments, so if you only type @list once, you can only do things that you could before when you typed @list only once. When we present this in the documentation (wishful thinking, now), it will be important that we present it in precisely that way, as argument rearrangers, lest people actually try that kind of foulplay. In that documentation we should probably suggest that the arrows go only one way per statement, otherwise you might not get what you expect. Due to that being what is almost always going to be intended, I think. Also, since we'd want $a ~ 2 + 4; to be $a = 6;, I would imagine that ~ and ~ would need low priorities. Precedences. Yes. Further, since ~ stars at the end of the list and works its way left, it would need a lower priority than ~ which starts at the beginning and works its way right. Not necessarily. ~ will necessarily need to be right-associative, while ~ left, however. It would be logical to give them the same precedence, except for the opposite associativity thing, where parsers get different results based on their parse method. So different precedences would be good only to ensure that different parsers saw the same thing. So if it did have a parenthetical variation, I would imagine it would be @keep ~ grep /good/ ~ (@list ~ grep /bad!/ ~ @throw); Which is, still, probably not what you wanted. Right. And probably not recommended. OTOH, I'm still new at posting here, and I may not be following all the bits that came before :o You're quickly getting the hang of it. Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 8 Jan 2003 10:45:37 -0600 From: Jonathan Scott Duff [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mail-Followup-To: frederic fabbro [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Disposition: inline X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Oh, then we just need a syntax to split the streams. ... I know! @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; which, of course, could be written in the more readable form: @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; Spookily, this quantumish operation can be achieved with Perl's quantumish operators. @list ~ (grep /bad!/ ~ @throw) | (grep /good/ ~ @keep); I'd actually think I'd be happier if that didn't work. Fortunately, I don't think it does (how do you put an argument on the end of a | expression?)). What we really need is a beam-split operator: @list ~ (-grep /bad!/ ~|~ grep /good/) ~ @result; Then @result would contain all things bad or good, but not both, because they interfere! :) And that, of course, leads us to sort of unzip were mutual exclusion is not a requisite: @list ~| grep length == 1 ~ @onecharthings ~| grep [0..29] ~ @numberslessthan30 ~| grep /^\w+$/ ~ @words ~| grep $_%2==0 ~ @evennumbers; I'm not going even to try this one. :-) (-: Luke
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer wrote:
I would, from the descriptions, imagine that:
@keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;
Would parse as:
@keep ~ grep /good/ ~ @list;
@list ~ grep /bad!/ ~ @throw;
Nope. ~ and ~ only *rearrange* arguments, so if you only type @list
once, you can only do things that you could before when you typed
@list only once.
So what we have is (using a scalar for an arbitrary variable) is:
$a ~ subroutine $arg1;
is equivalent to:
subroutine $arg1, $a;
and
subroutine $arg1 ~ $a;
is equivalent to:
subroutine $arg1 $a:; # or , equivalently, subroutine $a: $arg1;
and
.. ~ $a;
is equivalent to
$a = ...;
and similarly,
$a ~ ...;
is equivalent to
$a = ...;
~ is left associative, ~ right associative, have the same precedence,
and can't be mixed in one expression because of conflicting associativity
That means that a standard chain like:
@list ~ grep /good/ ~ map - { s/good/bad/ } ~ @badlist;
would parse as
((@list ~ grep /good/) ~ map - { s/good/bad/ } ) ~ @badlist;
to
((grep /good/ @list) ~ map - {s/good/bad/ } ) ~ @badlist;
to
(map - {s/good/bad/}, (grep /good/ @list)) ~= @badlist;
to
@badlist = (map - {s/good/bad/}, (grep /good/ @list));
to
@badlist = map - {s/good/bad/}, grep /good/ @list;
(modulo possible regex sytax).
RE: L2R/R2L syntax (was Re: Everything is an object.)
--- attriel [EMAIL PROTECTED] wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... I would, from the descriptions, imagine that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Would parse as: @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Actually, if you can say @a ~ sort ~ grep /foo/ ~ @output then it's pretty obvious that ~ is left-associative, a la in C++. Remember: cout Hello, world! nl; First does coutHW and returns cout-prime, then does cout-prime nl Likewise, the perl example does @a ~ sort, returning @a-prime @a-prime ~ grep /foo/, returning @a-2prime @a-2prime ~ @output, returning @output-prime, I hope! Reversing the direction: @output ~ grep /foo/ ~ sort ~ @a First does sort :@a, (I hope the syntax is right) returning @a-prime then does grep /foo/ :@a-prime, returning @a-2prime then does @output.operator() :@a-2prime which we hope gets transmogrified into assignment, and I likewise hope this will return @output-prime. So ~ looks right-associative. @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; Assuming that ~ and ~ have equal precedence, and that there's not some hideous special case backing this syntax, the above becomes: 1: @list ~ grep /bad!/ 2: ~ @throw 3: grep /good/ ~ 4: @keep ~ Which greps the @throw list for goodies -- not what I think you want. @keep ~ grep /good/ ~ @list; @list ~ grep /bad!/ ~ @throw; Due to that being what is almost always going to be intended, I think. Which brings up the point: What DO we want here? Frankly, I'm in love with the idea of a simple pipeline operator. I find it really easy to write AND read scripts like this: cat file | sed -e ... | grep -v ... | nl | sort -k ... | awk ... | sort output Being able to draw the pipeline make it really readable for the maintainer. The idea of doing something similar: @a ~ grep ~ map ~ @output is attractive. Regardless, I'm sure I don't like $foo ~ print ~ STDOUT That one's going to die a lonely death. =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
Luke Palmer [EMAIL PROTECTED] wrote: Not necessarily. ~ will necessarily need to be right-associative, while ~ left, however. Not sure if you aren't getting this backwards, but anyway I often find myself confused with right and left. It would be logical to give them the same precedence, except for the opposite associativity thing, where parsers get different results based on their parse method. So different precedences would be good only to ensure that different parsers saw the same thing. Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations).
RE: L2R/R2L syntax (was Re: Everything is an object.)
Jonathan Scott Duff:
# And that, of course, leads us to sort of unzip were mutual
# exclusion is not a requisite:
#
# @list ~| grep length == 1 ~ @onecharthings
# ~| grep [0..29] ~ @numberslessthan30
# ~| grep /^\w+$/ ~ @words
# ~| grep $_%2==0 ~ @evennumbers;
Congratulations on re-inventing Cpart. :^)
--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 (was Re: Everything is an object.)
On Tuesday, January 7, 2003, at 08:14 PM, Damian Conway wrote: Just when you thougth it was safe to go back on the mailing list, Damian attempts to resurrect a dead can of worms: And all because Mike Lazzaro wrote: OK, but let it be known that the resulting megathread is now _your_ fault, not mine. :-) I have enough blamed on me. That way, everything is still a method call, the ultra-low precedence of ~ and ~ eliminate the need for parens, and (best of all) the expressions actually *look* like processing sequences. I too think this idea is fabulous. You are my hero. Let the record show that I came back to 50+ messages this morning, in which nearly *all* were agreeing with each other, in this thread and all the others. Wow. :_) MikeL
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote: On Wed, Jan 08, 2003 at 05:14:06PM +0100, frederic fabbro wrote: I'm not even sure how that would parse, though that: @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw; would go like: ( @keep ~ grep /good/ ~ @list ) ~ grep /bad!/ ~ @throw; which is probably not what i wanted... Oh, then we just need a syntax to split the streams. ... I know! @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; which, of course, could be written in the more readable form: @list ~| grep /bad!/ ~ @throw ~| grep /good/ ~ @keep; And that, of course, leads us to sort of unzip were mutual exclusion is not a requisite: @list ~| grep length == 1 ~ @onecharthings ~| grep [0..29] ~ @numberslessthan30 ~| grep /^\w+$/ ~ @words ~| grep $_%2==0 ~ @evennumbers; :-) Smiley aside, this is brilliant. It is nicely high-level (allowing for parallelization/optimization behind the scenes), it reads nicely, and it works as a high-leverage idiom. I can see this as a nice basis for built-in threading below the level of developer control. Also, it enables the two dimensional coding that Damian likes. And it doesn't have to be an array op. It could be a continuation op: -$b |~ + sqrt($b ** 2 - 4*$a*$c) ~ $n1; |~ - sqrt($b ** 2 - 4*$a*$c) ~ $n2; (Yes, I know this would be a primo spot for a junction, but that's off topic.) So |~ does ~ except it remembers the LHS of the last invocation, if one isn't provided (NOT the last ~, but the last |~). Likewise ~| I guess, but what does it remember? It could remember the object: my WshObject $obj = $app.CreateObject($browser, $pfx); MenuBar 0 ~| $obj; ToolBar 0 ~|; AddressBar 0 ~|; Height 600 ~|; Width 500 ~|; Visible 0 ~|; Or it could remember the method: my ($a, $b, $c, $d) = get_some_objects(); MethodCall $arg1, $arg2, $exp - $re + $ssion ~| $a; ~| $b; ~| $c; ~| $d; Shiny! is right. =Austin
RE: L2R/R2L syntax (was Re: Everything is an object.)
-Original Message- Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). You are correct in stating that in a classical yacc specification, you can't declare two operators to have the same precedence but different associativity. But that's because syntactically you can't express the idea. You'd have to do something like %left PIPE_LEFT_OPERATOR %right PIPE_RIGHT_OPERATOR Or you could put them in the opposite order. But, syntactically, they do have to be on different lines, and that makes them have different precedence. However, you could have the following productions in a yacc grammar: exprB: exprA PIPE_LEFT_OPERATOR exprA | exprA PIPE_RIGHT_OPERATOR exprA %PREC PIPE_LEFT_OPERATOR ; (or something close to that -- it's been a while since I actually wrote yacc grammars). I assume that the generated parser would act in a manner similar to the way it behaves when it catches you trying to chain together %nonassoc operators: it generates a parse error. And given the fact that (IMHO) hello, world ~ print ~ STDERR; is an abomination, a parse error would be just fine by me. But cooler heads might just decree that the shift/reduce conflict is to be resolved one way or another, so that A ~ B~ C~ O ~ X ~ Y ~ Z parses as either (A ~B ~ C ~ O) ~ (X ~ Y ~ Z) or (A ~B) ~ C) ~ (O ~ X ~ Y ~ Z) Neither is likely to be what you want, however. And given the level of difficulty that most people have with precedence and associativity rules, I think it reasonable to require the parens if you want to mix ~ and ~ like that. =thom There are 10 kinds of people in the world: those who understand binary, and those who don't.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Damian Conway wrote: [...] ~ and ~ Michael Lazzaro wrote: I too think this idea is fabulous. You are my hero. I also think this is semantically fabulous but syntactically slightly dubious. '~' reads 'match' in my book, so I'm reading the operators as 'match left' and 'match right'. Or perhaps even 'stringify left' and 'stringify right' with a different reading of '~'. I would prefer something like | and | which has a more obvious connotation (to me at least) of pipe left or pipe right. Damian is my hero regardless. :-) A
Re: L2R/R2L syntax (was Re: Everything is an object.)
Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? [Yes, I'm twisting things somewhat. the perl5 parser, written in C, can parse perl5] Although my brain thinks that having expressions with both ~ and ~ should be illegal, because it's too damn confusing. Roughly: ~ ... ~ # My brain leaking out of my ears ~ ... ~ # My brain collapses because it's under too much pressure. Nicholas Clark
Re: L2R/R2L syntax (was Re: Everything is an object.)
Buddha Buck [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
and similarly,
$a ~ ...;
is equivalent to
$a = ...;
But with the different precedence. At last, I can assign from a list without
using parentheses:
@a = 1, 2, 3; # newbie error
@a ~ 1, 2, 3; # would work
Something else springs to mind. Consider the Cfor syntax:
for 1,2,3 ~ foo - $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
Dave.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Nicholas Clark wrote in perl.perl6.language : Actually I don't think you can define a grammar where two operators have the same precedence but different associativity. Be it a pure BNF grammar, or a classical yacc specification (using the %left and %right declarations). But that would mean only perl6 could pass perl6, which isn't much different from the perl5 situation, is it? I meant that if ~ and ~ are going to have the same precedence, you can't parse s ~ t ~ u It's not a well formed phrase of the language (even though this language can't described by a nonambiguous BNF grammar.) In fact, this is different from the Perl 5 situation you're alluding to.
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote in perl.perl6.language : But with the different precedence. At last, I can assign from a list without using parentheses: @a = 1, 2, 3; # newbie error @a ~ 1, 2, 3; # would work or : @a ~ 1 ~ 2 ~ 3; or : 1, 2, 3 ~ @a; which would be also written as : 3 ~ 2 ~ 1 ~ @a; shoot me : 3 ~ 2 ~ @a ~ 1; (Aha, Damian's 1st proposal seems to imply that ~ has highest precedence than ~).
Re: L2R/R2L syntax (was Re: Everything is an object.)
Dave Whipp wrote:
Something else springs to mind. Consider the Cfor syntax:
for 1,2,3 ~ foo - $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
I think I see what you're saying...
$a ~ foo;
calls foo on $a, while
$a - $x { ... }
um, does nothing... OK, I didn't see what I thought I said.
Actually, I do see something like:
$a ~ - $x { ... }
as having meaning, namely call the anon sub with $a as an argument.
Does syntax already exist for doing that? Can one do:
- $x { ... } ($a);
already?
If not, then the ~ - construct has a use, perhaps a semi-common use,
and perhaps it should be simplified. Not to suggest another operator
here, but $a ~- $x { ... } anyone?
But you were looking for a way to play off their similar meanings to
avoid having to use a tilde
The BNF for anonymous subs is something like (I haven't read the
existing grammars, so if I'm not using the standard terms...sorry):
anon_sub :== sub block
| sub ( paramlist ) block
| - block
| - paramlist block
The BNF for left-to-right pipelines would be something like:
lr_pipe :== lr_pipe ~ variable
| lr_pipe ~ function_call
If we were to combine - and ~, would it lead to any ambiguity? I'm
not sure. Certainly we'd be talking about more than a one-token lookahead.
Actually, I'm not sure the lr_pipe is unambiguous in its own right. I
don't have it complete, obviously, but I see problems with the two calls
as is...
What is the result of:
$input ~ %functionTable{$state} ~ $state;
Is it equivalent to:
%functionTable($state) = $input;
$state = %functionTable($state);
or
$state = %functionTable($state).($input);
How does the grammar differentiate between the two?
Or would I have to type
$input ~ %functionTable{$state}.() ~ $state;
instead?
Dave.
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- Luke Palmer [EMAIL PROTECTED] wrote:
Date: Wed, 08 Jan 2003 12:14:10 +0800
From: Damian Conway [EMAIL PROTECTED]
Can I suggest that an alternative solution might be the following:
Suppose Perl 6 had two new very low precedence operators: ~ and ~
(a.k.a. bind rightwards and bind leftwards)
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;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
Further suppose that ~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort ~ map {...} ~ grep {...} ~ @a;
Or, under a special rule for variables on the LHS:
@out ~ sort ~ map {...} ~ grep {...} ~ @a;
That way, everything is still a method call, the ultra-low precedence of
~ and ~ eliminate the need for parens, and (best of all) the
expressions
actually *look* like processing sequences.
I think this is a big step towards readability. It allows you to put
whatever part of the expression wherever you want (reminiscent of
Latin); i.e. always keep the important parts standing out. I also
think that the operator (especially a cool 3d-looking one like ~) is
also much more readable than a word in this case.
I don't like either of these operators. What's wrong with @out = sort map
{...} grep {...} @a?
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
Trey Harris wrote: I love this. And any class could override the ~ operator, right? Right. I suppose it could be done like arithmetic overloading, if you define both ~ (I'm being pointed at from the right) and ~ (I'm being pointed at from the left) in your class then Perl will use whichever appears in code, but if you define just one, Perl will use it for both. H. Maybe. I'm not certain that Perl 6 operator overloading will be as highly dwimical as Perl 5's is. Damian
