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: > : > : +<< > : +>> > > Yeah, I kinda wondered if we'd done that already.
The most-recent of MikeL's operator lists on Google Groups still has them in the Perl 5 versions: http://xrl.us/perl6ops6 But the message from Andrew Wilson in that thread suggests the versions that Larry does above. > ... 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: >> +< <<. How about going back to what you originally decreed in Apocalypse 2, that the replacement for: qw<Statler Waldorf> will simply be: <Statler Waldorf> I think your reasoning, that using up a perfectly good set of brackets for input is a waste, still stands. It's also among the things people new to Perl find the most confusing, compared to an explicitly named function or method that they might expect for input; I don't think there'd be the same problem with something called C<read> or C<get> or C<getline> or C<input> or C<from> or C<line> or C<chunk> or C<data>. You describe as "likely" that in common situations no operator or function name will be needed anyway -- do you still think that's the case? (I also note that if people are really attached to the special case of empty C<< <> >> meaning 'read from files named in C<@ARG> or from stdin if C<@ARG> is empty', that could be left in, since it doesn't at all conflict with putting something inside the pointies to quote them. But I'm still not keen on that.) Or how about using backticks for quoting words: my @person = `Statler Waldorf`; Running shell commands and retrieving their output is also fairly rare, and doesn't really need special quote-symbol-using operator -- especially when compared to the C<system> command, which manages to do something quite similar as a mere named function. (Having them both as named functions might also reduce the incidences of people grabbing the command's output when they didn't mean to.) > 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. If you go along those lines then implementing (some of) those in RFC1345 would at least avoid inventing yet another set of symbols. They are reasonably mnemonic ("<<" does indeed stand for "«"), so you'd only need to pick designate the colon (or backtick or whatever) as the digraph-designator and what follows is anything in that RFC. That also has the advantage that 'Vim' users only need to learn one set of mappings from digraphs to non-Ascii characters, thereby providing a memorable upgrade path: people without the appropriate symbols have to learn to type things such as these in Perl: :<< :*X :.M if they upgrade their terminal/fonts/whatever then they can now insert the actual characters, and they can use the digraphs they've already learnt, simply pressing Ctrl+K instead of colon: Ctrl+K << « Ctrl+K *X × Ctrl+K .M · I of course realize that not everybody uses 'Vim', but it is an RFC, and possibly in use elsewhere too. Smylers
