On Tue, Nov 22, 2005 at 07:52:24AM -0800, Larry Wall wrote:
>
> I think we'll leave both _ and \_ meaning the same thing, just to avoid
> that confusion path [...]
Yay!
> : 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.
Yay!
> : 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 $<>.
Yay! (Our messages on this crossed in the mail; mine was moderated for
some reason but that's been corrected.)
> : 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.
At least within PGE, I'm starting to come across the situation
where each application and host language wants its own slight variations
of the regular expression syntax (for compatibility reasons).
And I figured that since we (conjecturally) have C<:lang('PIR')>,
C<:lang('Python')> and C<:lang('TCL')> to indicate the language
to be used for the closures within a rule, it might be nice to
have a similar parameterized modifier for the pattern syntax
itself.
I was also thinking that one of the tricky parts to custom rule
modifiers such as :perl and :glob is that they actually change
the parsing for whatever follows, so it might be nice to have
a parameterized form to hook into rather than defining a custom
modifier for each syntax variant. But on thinking about it
further from an implementation perspective I guess it all comes
out the same anyway...
Pm
