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

Re: Semantics of vector operations

Thread Previous | Thread Next
February 9, 2004 01:53
Re: Semantics of vector operations
Message ID:
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:

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

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


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.


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