When I see these long squiggles of line noise, I can't help thinking that English might be a better alternative. Using Larry's terminology from a few posts ago, we might think of:
@a \C[leach] + \C[reach] @b Not mnemonic in a visual sense, but extendable to all sorts of trigraph contexts. Indeed, if we had a "this is an operator" operator, we could give every symbol a textual name: $a \op[assign] $b \op[plus] $c; @a = @b \op[leach plus reach] @c; Dave. "Luke Palmer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 :-) > > 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
