: > But, presumably, you could write a macro that has a whitespace-eater
: > encoded
: > somehow. That is,
: >
: > macro leach() { chomp_trailing_whitespace; return "?" }
: > macro reach () { chomp_leading_whitespace; return "?" }
: >
: > then the macro magic would expand "leach eq reach" as "?eq?" (which,
: > hopefully, it then re-parses as a single token^Woperator). This doesn't
: > solve the generalized problem of disambiguating, though I could see a
: > "_" operator defined as a macro that eats all its surrounding
: > whitespace.
:
: ...making it a "nospace" character (or is that a "no_space" character?
: Same thing?)
:
: You wouldn't be able to say "chomp_trailing_whitespace" if you did this,
: though.  

I doubt a _ macro would fire off in the middle of an identifier
like that.  Once a grammar rule has snarfed a construct such as an
identifier, it generally rules out other interpretations of the
construct.  There are all sorts of such context sensitivities in
Perl's grammar.  A bareword is not a bareword if there's a "sub"
in front of it, or a "$", "@", etc.

Now, if we get into token-gluing scenarios, these sorts of things
come into play.  But I think the _ proposal was for whitespace eating
without token gluing.

Larry