Front page | perl.perl6.language |
Postings from November 2004
On Thu, Nov 25, 2004 at 09:55:54PM +0100, Juerd wrote:
: As we now know, in many situations, << and « mean the same thing. In
: exactly those situations, the same is true for >> and ». However,
: sometimes, « cannot be used where << can. Here-docs are an example.
:
: «» (or <<>>, if you wish) quotes. I am assuming that «» is a shorthand
: for qw«», except where special syntax is used with hash slices and
: :-pairs, just like //, which is short for m//, "" for qq"", etcetera.
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//.
: 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.
: Another question comes to mind as I am typing this message. Can « and >>
: be used together, or does « always need » and << need >>? If a matching
: pair is required, then does the same hold true for vector ops with anqle
: quotes on both sides (i.e. is that seen as a "quoted" operator, or as an
: operator that happens to have two vectorizing symbols)?
I don't see that it's terribly important either to allow that or to
disallow it. I do think we should discourage asymmetry, but I can well
imagine that someone who doesn't have easy «» access might end up replacing
one end without replacing the other. It should be easy for someone in
this fix to translate the line to the «» form. Perhaps perl itself ought
to offer to do the translation for you. Basically, the sooner we can get
code into a canonical form, the less trouble we'll have overall.
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.
Some people might actually prefer to have the <<>> form illegal, not because
they don't want to type it in that way, but because they want to be forced
to translate to «» before the semi-bogus <<>> forms enter The Record.
: One last question for now: how hard will it be to implement a grammar
: with certain not otherwise specified language features *removed*?
So you want to violate Liskov substitutability on grammars, eh? :-)
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.
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.
BEGIN { undef &circumfix:«<< >>»; }
or maybe even:
my macro circumfix:«<< >>» is gone;
That would have the effect of removing the '<<' key from the term hash,
or for a lexical declaration, making a copy of the term hash without
that key, so that when we hit the end of this lexical scope. we can
restore the old hash.
Larry