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

Reply via email to