Message from discussion Semantics of vector operations
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) (184.108.40.206) 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
Received: (qmail 15081 invoked by alias); 23 Jan 2004 21:24:35 -0000
Received: from [220.127.116.11] (HELO babylonia.flatirons.org) (18.104.22.168) 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
References: <20040122173859.GA13409@wall.org> <ICELKKFHGNOHCNCCCBKFOEKCCJAA.Austin_Hastings@Yahoo.com> <20040122212809.GB25098@babylonia.flatirons.org> <email@example.com> <20040123012000.GC16181@wall.org> <20040123020326.GA29950@babylonia.flatirons.org> <20040123182250.GA23542@wall.org>
Content-Type: text/plain; charset=utf-8
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/
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 »+<<« @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 :-)
> 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