develooper Front page | perl.perl6.language | Postings from January 2004

Re: Semantics of vector operations

Thread Previous | Thread Next
From:
Luke Palmer
Date:
January 23, 2004 13:24
Subject:
Re: Semantics of vector operations
Message ID:
20040123212420.GB26077@babylonia.flatirons.org
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About