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