[Snow-users-list] high-priority snow packages and package naming

Julian Graham joolean at gmail.com
Sat Sep 15 19:28:47 EDT 2007


> Fine, but specify the input language -- the regexp language.
> If you take my advice, it will have just *, |, [], and ()

Sure, but most of the Scheme interpreters we're talking about already
accept a broader regexp syntax (usually it's POSIX).  And I thought we
were going for performance -- meaning that a pass-thru to the
interpreter's regexp API (which, in turn, is often a pass-thru to a
native implementation -- glibc, etc.) is the way to go.  Still, given
that different interpreters accept different regexp "extensions," I
agree that some normalization is required.  How to do it, though,
without actually implementing much regexp logic in this package?

> It's ok if the Scheme binding has to translate from
> a portable true regular expression syntax into whatever
> the system uses natively (e.g., posix, perl, whatever).

Right -- I'd think it would even be desirable.

> There should be no such thing as a "match object".
> If you want things like sub-exp positions, I'm saying
> don't use the posix re features for that or perl's ---
> write that stuff in Scheme, using the true regular
> expression matcher as the "inner loop".

Fair enough -- I'd just like to avoid situations in which there's no
way to prevent the Scheme interpreter from doing a lot of work that
we're just going to discard.  E.g., I can't think of a way (besides
memoization) to implement your (find-start ...) function on top of,
say, Guile's regexp implementation (which is a pass-thru to glibc's
native implementation) that doesn't involve the overhead of doing a
complete match just to obtain the position of the first submatch.  So,
yeah, I agree that match structures are kind of bullshit, but the
majority (maybe all) of the Scheme interpreters we're dealing with
here produce them -- I think it's slightly less bullshit when they
present a match as an S-expr of, say, (([start] . [end]) ([start] .
[end]) ...).  Given that the shitty, opaque match structures can be
translated into these somewhat more useful S-exprs, well... you know,
is that a palatable alternative?

> That's all you need to duplicate (and surpass) the functionality
> of full Posix regexps and Perl regexps using portable Scheme
> code.   And, those are all easy to do on top of either a Perl
> or Posix engine.

Easy, sure, but how efficient is it?


More information about the Snow-users-list mailing list