Larry Wall skribis 2004-11-25 13:45 (-0800):
> Hmm, I would say that "" is short for qq//, not qq"". Quote characters
> lose their identity when used with generalized quotes. (I realize this
> is not always true with Perl 5, but that can be construed as a mistake.)
> So �� is not really short for qw�� unless you take the delimiters of the
> latter construct as simple characters without any �� baggage, including
> the need to have a <<>> workaround. So I'd rather say �� is short for qw//.
I'm happy to read this. Perl 5's semantics with qx|m|qr|s and ''
probably made me translate "" to qq"" instead of qq//, or qq{} as perlop
lists it.
> : But as � foo bar � and << foo bar >> are the same thing, I wonder what
> : qw<< foo bar >> means. Is that qw/< foo bar >/ or is that qw/foo bar/?
> : And is this consistent with other operators, i.e. rx�� versus rx<<>>?
> It means qw/< foo bar>/, and yes, that's consistent.
That's a relief :)
> This approach doesn't help the person who can't even *display* ��, but
> that problem will be solved before the input problem is. For instance,
> PerlMonks has no problem displaying ��, but I haven't a clue how to type
> it into my browser yet.
Should you happen to use X with the Xkb extension, it is a matter of
assigning a key to Multi_key and then typing Multi_key < <.
I have assigned my rightmost "Windows key" (the "Menu" key) with:
xmodmap -e "keysym Menu = Multi_key"
> So you want to violate Liskov substitutability on grammars, eh? :-)
I'd even violate gravity, if I could!
> While one can certainly redefine rule methods to pitch a fit if called,
> the real way you cut down the language is by not referring to those
> rules in the first place from elsewhere. Which means you have to override
> those referring rules, after which it almost doesn't matter if the
> previously referred to rules are somehow cancelled or not.
I was afraid that that'd be the answer.
> The other part of it is that some of the constructs are catalogued in
> hashes and arrays rather than in rule alternatives. When you derive
> a grammar you can certainly copy over a part of the hash or array and
> leave out other parts. These hashes and arrays are loaded up in the
> first place via the various syntactic categories we go on about. So
> maybe we have some way of cancelling syntax.
That's better news :)
> BEGIN { undef &circumfix:�<< >>�; }
But if mixed �>> is allowed, isn't that �<<�syntax error? Or did I
misinterpret the answer re mixing them?
> my macro circumfix:�<< >>� is gone;
Perhaps "is gone" is a bit too easy for something that shouldn't be
done.
Juerd
