Austin Hastings writes:
> > -----Original Message-----
> > From: Gordon Henriksen [mailto:[EMAIL PROTECTED]
> > Austin Hastings wrote:
> >
> > > OTOH, Robin's concern for how to code when you're stuck with 7 bit
> > > ascii on the boot console of a Sun box remains valid, and *I* sure
> > > would rather have a short name available in a standard way.
> >
> > Perhaps a solution is a cultural one, that it simply be a point of good
> > style for library authors to provide ASCII alternatives in the form of
> > multimethods. Then, at least, the alternative name will be pertinent to
> > the module.
>
> Agreed. And since the first such situation that P6 learners will encounter
> is the built-in  and  operators, or the equally built-in   quoting
> delimiters, we get to be first, providing-a-good-ascii-alternative-wise.
>
> From http://www.unicode.org/charts/PDF/U0080.pdf, we have:
>
> 00AB Â LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
> = LEFT POINTING GUILLEMET
>
> 00BB Â RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
> = RIGHT POINTING GUILLEMET
>
> While quite descriptive, none of those really flows from the tongue.
>
> I believe that we SHOULD accept either of those terms, with or without
> hyphens, but not require them for ascii work. I'd much rather see E'<<' and
> E'>>' as valid aliases. (Yes, this implies a change to POD, too. But it's a
> good change.)
Right. And we also need a way for users to provide ASCII alternatives
when they come across a rude module. But, in perl's tradition of
starting quoting constructs with q, perhaps it should be qe'' instead.
But that doesn't quite work with POD, unless pod changed to using qe,
which isn't all that nice.
But I think that literal >> and << are quite nice alternatives for  and
 [1], and if the only think that's holding us back is the bitshift
operators, we should kill them -- turn them into functions or something.
C<shl> and C<shr> aren't so bad, are they?
Or perhaps << and >> can be the quoters, and separate from  and Â.
But I'm still sure that the unicode-deficient would rather write:
@a = @b >>+<< @c
Than
@a = @b E'>>'+E'<<' @c
Luke
[1] In fact, you'll probably find me writing them that way when they're
used as a quoting construct: I like << foo bar baz >> better than
Âfoo bar bazÂ.
Luke
>
> =Austin
>
