Front page | perl.perl6.language |
Postings from January 2004
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. > > LarryThread Previous | Thread Next