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

Re: Semantics of vector operations

Thread Previous | Thread Next
Larry Wall
January 23, 2004 10:23
Re: Semantics of vector operations
Message ID:
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

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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About