HaloO,

Patrick R. Michaud wrote:
There's also <sp>, unless someone redefines the <sp> subrule.
And in the general case that's a slightly more expensive mechanism to get a space (it involves at least a subrule lookup). Perhaps we could also create a visible meta sequence for it, in the same way that we have visible metas for \e, \f, \r, \t. But I have no idea what letter we might use there.

How about \x and \X respectively? Note the *space* after it :)
I mean that much more serious than it might sound err read.
I hope the concept of unwritten things in the source beeing
interesting values of void/undef applies always.

OTOH, I'm usually not saying anything in the area of the grammar
subsystem, but I still try to wrap my brain around the underlying
unifyed conceptual level where rules and methods or subs and macros
are indistinguishable. So, please consider this as a well wanting
question. And please forgive the syntax errors.

With something like

   # or token? perhaps even sub?
   macro   x ( HexLiteral *[$char = 32, [EMAIL PROTECTED] )
   is parsed( <HexLiteral>* )
   {...}

and \ in match strings escaping out to the macro level when
the circumfix match creator is invoked, I would expect

   m/  \x           /;  # single space is required
   m/  \x20         /;  # same
   m/ <{x}>         /;  # same?
   m/  \X           /;  # any single char except space
   m/  \x\x\x       /;  # exactly three spaces
   m/  \x[20,20,20] /;  # same, as proposed by Larry
   m/  \xy          /;  # parse error 'y not a hex digit'
   m/  \x y         /;  # one space then y

to insert verbatim, machine level chars into the match definition.
In particular *no* lookup is compiled in.

I would call \x the single character *exact* matcher and \X
the *excluder*. BTW, the definition of the latter could just be

   &X ::= !&x; # or automagically defined by up-casing and outer negation

if ? and ! play in the meta operator league.


I don't think I like this, but perhaps C<< <> >> becomes <?null> and C<< < > >> becomes <' '>? Seems like not enough visual distinction
there...

I strongly agree. I would ask the moot question *how* the single space
in / / is removed ---as leading, trailing or separating space---when the
parser goes over it. But I would never expect the source space to make it
into the compiled match code!
--

Reply via email to