Newsgroups: perl.perl6.language
Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <fibon...@babylonia.flatirons.org>
Mailing-List: contact perl6-language-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-langu...@perl.org
Received: (qmail 52838 invoked by uid 76); 23 Jan 2004 21:24:38 -0000
Received: from x1.develooper.com (HELO x1.develooper.com) (63.251.223.170) by onion.perl.org (qpsmtpd/0.26) with SMTP; Fri, 23 Jan 2004 13:24:38 -0800
Received: (qmail 15086 invoked by uid 225); 23 Jan 2004 21:24:35 -0000
Delivered-To: perl6-langu...@perl.org
Received: (qmail 15081 invoked by alias); 23 Jan 2004 21:24:35 -0000
Received: from [161.97.199.99] (HELO babylonia.flatirons.org) (161.97.199.99)  by la.mx.develooper.com (qpsmtpd/0.27-dev) with ESMTP; Fri, 23 Jan 2004 13:24:23 -0800
Received: by babylonia.flatirons.org (Postfix, from userid 2003)	id A2E931A9; Fri, 23 Jan 2004 14:24:20 -0700 (MST)
Date: Fri, 23 Jan 2004 14:24:20 -0700
To: Perl6 <perl6-langu...@perl.org>
Subject: Re: Semantics of vector operations
Message-ID: <20040123212420.GB26077@babylonia.flatirons.org>
References: <20040122173859.GA13409@wall.org> <ICELKKFHGNOHCNCCCBKFOEKCCJAA.Austin_Hastings@Yahoo.com> <20040122212809.GB25098@babylonia.flatirons.org> <001a01c3e14d$60d04860$e58f8445@carolina.rr.com> <20040123012000.GC16181@wall.org> <20040123020326.GA29950@babylonia.flatirons.org> <20040123182250.GA23542@wall.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20040123182250.GA23542@wall.org>
User-Agent: Mutt/1.5.4i-ja.1
X-Spam-Check-By: la.mx.develooper.com
X-Spam-Status: No, hits=-2.7 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: fibon...@babylonia.flatirons.org (Luke Palmer)

Larry Wall writes:
> On Thu, Jan 22, 2004 at 07:03:26PM -0700, Luke Palmer wrote:
> : Larry Wall writes:
> : > On the other hand, we've renamed all the
> : > other bitwise operators, so maybe we should rename these too:
> : > 
> : >     +<		bitwise left shift
> : >     +>		bitwise right shift
> : 
> : I could have sworn we already did that.  I thought they were:
> : 
> :     +<<
> :     +>>
> : 
> : But I guess that's an extra unneeded character.
> 
> Yeah, I kinda wondered if we'd done that already.  But hey, if I
> don't remember what I already said, how can I get mad when other
> people don't remember.  :-)
> 
> For historical reasons it would be better to stick with the long
> versions, even if that does engender the occasional 4-character
> +<<= operator.  (Not to mention the 6-character æ  +<<=æ Ÿ operator.
> (Not to mention the 8-character >>+<<=<< operator.))  Though I guess
> that would make >>+<< ambiguous again, sigh...
> 
> Which probably means we have to force bitshifts to +< and +>, so
> we can tell the difference between >>+< and >>+<< and >>+<<<.  It's
> almost getting to the point where we want to allow disambiguating
> underscores in operators: >>_+<_<<.  Alternately we give up on <<>>
> as a qw// replacement and allow spaces: >> +< <<.
> 
> But we also have the ambiguity with <<'' and friends, so maybe the real
> problem is trying to make the << and >> workarounds look too much like
> æ Ÿ and æ  .  Maybe they should be :<< and :>> or some such.  Maybe we
> should be thinking about a more general trigraph (shudder) policy.
> Or some other kind of "entity" policy.  Though I don't think people
> would be terribly pleased when they see things like:
> 
>     @a &raquo;+<<&laquo; @b

All of these are getting pretty huge an unwieldy.  We do reward the
people with UTF-8 terminals, but oh how we punish those without.
Perhaps that's not the best way to go.

What about >: and :< ?  This doesn't visually interfere quite as much,
because we won't be seeing a distributed : or :: operator.  It's still
not terribly pretty on things like >:+<<:<, but it's more managable than
>>+<<<<, and not nearly as ambiguous :-)

Luke

> Particularly since the "r" one goes on the left, and the "l" on goes
> on the right.  Still, it's potentially a lot less ambiguous, and puts
> people into the "preprocessing" frame of mind, and would certainly
> motivate people to move toward editors and terminals that can display:
> 
>     @a æ  +<<æ Ÿ @b
> 
> And we wouldn't have to define yet another arbitrary list of mappings.
> On the other hand, we'd probably have to require a () on the &foo()
> notation to distinguish it from an &foo; entity.
> 
> As a half-measure, we could allow << and >> for most purposes and
> only require the entities when ambiguous.  That might be the best
> approach.
> 
> Larry