Re: L2R/R2L syntax (was Re: Everything is an object.)

[David Storrs]

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.)

[Dan Sugalski]

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.)

[Petras]

* 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.)

[Austin Hastings]

--- 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]

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.)

[Dan Sugalski]

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.)

[David Storrs]

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.)

[Mark J. Reed]

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.)

[Jonathan Scott Duff]

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.)

[Nicholas Clark]

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.)

[Buddha Buck]

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

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Buddha Buck]

[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.)

[Austin Hastings]

--- "Mr. Nobody" <[EMAIL PROTECTED]> wrote:
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:

[... Massive elision ...]

> > 
> > 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.
> > 
> 
> trigraphs are actually better, even if you are unicode capable. ~> is
> far
> easier to type than ctrl-u-15F9E2A01 or whatever it is.

Likewise, it wasn't possible until recently to EASILY type an accented
vowel, or an n-tilde, from a US keyboard. Now, however, there's an IME
that converts APOS + a into á (accented small a). 

Likewise, someone could write a Perl IME that converted TILDE+GREATER
into Unicode-wiggly-right-arrow.

And then it would be trivial, and you'd wonder what the fuss was about
back in K2 ... 

=Austin

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Mr. Nobody]

--- 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: (AUTORESPONSE)Re: L2R/R2L syntax (was Re: Everything is an object.)

[Austin Hastings]

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]

--- "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: L2R/R2L syntax (was Re: Everything is an object.)

[Simon Cozens]

[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]

--- "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, C is too long, so I want to just make it curly-f, 
> > (ƒ).  And C 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âzŒ.  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 C.  Well, that or 
> > C, 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.)

[Mr. Nobody]

--- 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, C is too long, so I want to just make it curly-f, 
> (ƒ).  And C 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âzŒ.  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 C.  Well, that or 
> C, 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.)

[Mark J. Reed]

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, C is too long, so I want to just make it curly-f, 
> (ƒ).  And C 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 C.  Well, that or 
> C, 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]

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, C is too long, so I want to just make it curly-f, 
(ƒ).  And C 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 C.  Well, that or 
C, I can't decide.  It depends on how sad the clown looks.

MikeL

RE: L2R/R2L syntax (was Re: Everything is an object.)

[Mr. Nobody]

--- 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.)

[Brent Dax]

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.)

[Mr. Nobody]

--- 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.)

[Austin Hastings]

--- 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.)

[Mark J. Reed]

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.)

[Rafael Garcia-Suarez]

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.)

[Dan Sugalski]

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.)

[Austin Hastings]

--- 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.)

[Nicholas Clark]

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.)

[Dan Sugalski]

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.)

[Simon Cozens]

[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.)

[Simon Cozens]

[EMAIL PROTECTED] (Mr. Nobody) writes:
> Unicode operators in the core are a very, very, very, very, very, very, very,
> very, very, very, very, very, very bad idea.

We've done that.

-- 
COBOL is for morons.
-- E.W. Dijkstra

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Smylers]

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.)

[Dan Sugalski]

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.)

[Austin Hastings]

--- 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.)

[Mr. Nobody]

--- 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 
>

> 
>   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]

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.)

[Mr. Nobody]

--- 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.)

[Austin Hastings]

--- "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.)

[Mr. Nobody]

--- 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.)

[Buddha Buck]

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.)

[Mr. Nobody]

--- 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.)

[David Storrs]

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.)

[Richard J Cox]

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.)

[arcadi shehter]

Luke Palmer writes:
 > 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
 > 

why priperties are sort of ... because they tell the state of the
thing as a result of some action that happend ( prbably in very close
) past : 

 him.hit(I); #  him is being hit by me; 

 him is hit(I); # him was hit by me -- and this has some consequences !!!
 
it seems that some times "is" may be replaced by "was" 
 
him was initialized ; 


:-) 

arcadi 

Re: L2R/R2L syntax (was Re: Everything is an object.)

[David Wheeler]

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//,$x] »-« [»ord«split//,$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.)

[chromatic]

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.)

[Damian Conway]

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//,$x] »-« [»ord«split//,$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.)

[Mark J. Reed]

Let me just chime in here that I have been reading all the
messages via mutt in an xterm font in which the
tilde is at the top of the space, and this has in no way
affected my appreciation of the new operators.

I don't want them to look like arrows, because that's reminiscent
of ->, which is misleading as to the direction of data flow.
Visually, I think of <~ and ~> as modifications of the shell redirect
operators, which works very well.


-- 
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.)

[Paul Johnson]

On Fri, Jan 10, 2003 at 03:55:30PM -0500, Andrew Rodland wrote:
> 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).

-bitstream-courier-* actually, now that I can check, but the effect is
the same.

Maybe someone can cook up a Perl font that we can recommend to anyone
who needs to see the source?

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Andy Wardley]

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.)

[Luke Palmer]

> 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 I the verb and the
direct object, before the colon.

Luke

RE: L2R/R2L syntax (was Re: Everything is an object.)

[Thom Boyer]

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.)

[Thom Boyer]

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]

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.)

[Austin Hastings]

--- attriel <[EMAIL PROTECTED]> wrote:
> Ah.  OK, thanks :)  I had the basic idea, but I wasn't sure how to
> tell in perl which parameter was the indirect object :o

Right, "o" in your sentence above is the object. 

> if I'm following this right, it's the inferred object such that (in
> p5) if I called I.hit(him) the sub would receive @_ = I, him; yes?

Yep.

> and thus it would be hit (him) <~ I; in the current thread?

Yep.  

Henceforth, <~ shall be the "dragon operator", because (1) you're
draggin' the object back to the method; and (2) operator:<~ looks like
a chinese dragon.

Likewise, ~> shall be the "grin operator", because of the smiley in
"operator:~>".

=Austin

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Damian Conway]

Trey Harris raised the spectre of:


shades of C++, how about just

  $*STDERR <~ $foo;


Yes. Assuming C were suitably overloaded.


or

  $foo ~> $*STDERR;


Yes. Assuming C were suitably overloaded.

Not sure whether that would come "standard", but if not, here's
a first cut of the necessary module for future reference:

	module IO::Stroustrupian;

	# Output operators...
	my infix::<~(IO $fh, $datum) is multi is exported { print $fh: $datum }
	my infix::<~(IO $fh, @data)  is multi is exported { print $fh: @data  }
	my infix::~>($datum, IO $fh) is multi is exported { print $fh: $datum }
	my infix::~>(@data,  IO $fh) is multi is exported { print $fh: @data  }
	
	# Input operators...
	my infix::<~($var is rw, IO $fh) is multi is exported { $var = <$fh> }
	my infix::<~(@var is rw, IO $fh) is multi is exported { @var = <$fh> }
	my infix::~>(IO $fh, $var is rw) is multi is exported { $var = <$fh> }
	my infix::~>(IO $fh, @var is rw) is multi is exported { @var = <$fh> }


Damian

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Paul Johnson]

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.)

[Austin Hastings]

--- 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]

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.)

[Damian Conway]

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.)

[attriel]

> 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.)

[Andrew Rodland]

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.)

[David Wheeler]

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.)

[Brent Dax]

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.)

[Austin Hastings]

--- "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 C) 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]

--- 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.)

[Jonathan Scott Duff]

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]

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.)

[David Storrs]

(/dks attempts to pour water.)

Damian Conway <[EMAIL PROTECTED]> wrote:
> > 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;
 
Mr. Nobody wrote:
> I find the normal function call and assignment far more readable than using
> some weird ugly operator.

Ok, but "weird" and "ugly" are personal opinions--that is, they are a
question of aesthetics, not language design, and aesthetics varies
from person to person.  A lot of other people (myself included), seem
to find the ~> operator to be kinda cool.  Is this a case where we
could just agree that TIMTOWTDI?


> > 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. 

Don't think of it as a function call then.  Think of it as a pipeline,
where data flows in the direction of the arrows.


> 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.

Now don't hold back on account of social niceties like not wanting to
cloud the issue with emotion or low-level ad hominem attacks.  Tell us
what you _really_ think. :>


--Dks

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Mr. Nobody]

--- 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.)

[arcadi shehter]

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.)

[attriel]

>> 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 ≈ (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 "against"s 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]

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.)

[Andy Wardley]

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.)

[Trey Harris]

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]

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.)

[Damian Conway]

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.)

[Damian Conway]

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.)

[Damian Conway]

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.)

[Damian Conway]

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

Re: L2R/R2L syntax (was Re: Everything is an object.)

[Mr. Nobody]

--- 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.)

[Buddha Buck]

Dave Whipp wrote:


Something else springs to mind. Consider the C 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.)

[Rafael Garcia-Suarez]

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.)

[Rafael Garcia-Suarez]

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]

"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 C 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]

> 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.)

[Andy Wardley]

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.)

[Thom Boyer]

-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.)

[Austin Hastings]

--- 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.)

[Michael Lazzaro]

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.)

[Brent Dax]

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 C.  :^)

--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.)

[Rafael Garcia-Suarez]

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.)

[Austin Hastings]

--- 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 cout<<"HW" 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.)

[Buddha Buck]

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.)

[Luke Palmer]

> 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]

> 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.)

[David Storrs]

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.)

[Jonathan Scott Duff]

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]