On Mon, Nov 21, 2005 at 11:25:20AM -0600, Patrick R. Michaud wrote:
: On Mon, Nov 21, 2005 at 09:02:57AM -0800, Larry Wall wrote:
: > : There's also <sp>, unless someone redefines the <sp> subrule.
: >
: > But you can't use <sp> in a character class. Well, that is, unless
: > you write it:
: >
: > <+[ a..z ]+<sp>>
: >
: > or some such. Maybe that's good enough.
:
: Er, that's now <+[ a..z ]+sp>, unless you're now changing it back.
No, just me going senile.
: > : 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.
: >
: > Something to be said for \_ in that regard.
:
: Yes, I thought of \_ but mentally I still have trouble
: classifying "_" along with the alphabetics -- '_' looks more
: like punctuation to me. And in general we use backslashes
: in front of metacharacters to remove their meta meaning
: (or when we aren't sure if a character has a meta meaning),
: so that \_ somehow seems like it ought to be a literal
: underscore, guarding against the possibility that the unescaped
: underscore has a meta meaning. (And yes, I can shoot
: holes in this line of thinking along with everyone else.)
I think we'll leave both _ and \_ meaning the same thing, just to avoid
that confusion path--I've seen people backwhacking anything remotely
resembling punctuation just in case it's a metacharacter, and if they
are confused about _, they might backwhack it. More to the point,
I think <sp> and +sp are about the right Huffman length, given that
matching a single space is usually wrong. You usually want \s or \s*.
: Whatever shortcuts we introduce, I'll be happy if we can just
: rule that backslash+space (i.e., "\ ") is a literal space
: character -- i.e., keeping the principle that placing a backslash
: in front of a metacharacter removes that character's "meta"
: behavior.
Yes, that will be a space.
: > I dunno. If «...» in ordinary code does shell quoting, maybe «...» in
: > rules does filename globbing or some such. I can see some issues with
: > anchoring semantics. Makes more sense on a string as a whole, but maybe
: > can anchor on element boundaries if used on a list of filenames.
: > I suppose one could even go as far as
: >
: > rule jpeg :i « *.jp{e,}g »
: >
: > or whatever the right glob syntax is.
:
: Since we already have :perl5, I'd think that we'd want globbing
: to be something like
:
: rule jpeg :i :glob /*.jp{e,}g/
:
: or, for something intra-rule-ish:
:
: m :w / mv (:glob *.c)+ <dir> /
Yep, that's what I decided in my other message that was thinking about
using < ... > for word boundaries and << ... >> for capturing $<>.
: And perhaps we'd want a general form for specifying other
: pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
: :syntax('perl5') and :syntax('glob') or something like that.
Maybe. Or maybe it's enough that there are syntactic categories for
adding rule modifiers. Doesn't seem like you'd want to parameterize
the current language very often.
Larry
