On 11/26/2013 6:17 AM, Peter Bex wrote:
> On Tue, Nov 26, 2013 at 09:44:27PM +0900, Alex Shinn wrote:
>> On Tue, Nov 26, 2013 at 12:34 PM, Michael Montague <xxxxxx@gmail.com>wrote:
>>
>>> Why can the procedure 'regexp' be called with an already compiled <re>
>>> which is just returned?
> Convenience, I'd say.  That way you can create modules which have an
> interface that accepts either SREs or regexp objects (like irregex does),
> having it automatically compile SREs.
>
>>> Why is the procedure 'valid-sre?' necessary? You could just call 'regexp'
>>> and use 'guard' to check for any errors.
>>>
>> Indeed, in fact `valid-sre?' could be defined as:
>>
>>    (define (valid-sre? x)
>>      (guard (else (exn #f)) (regexp x)))
>>
>> Whether you want to test in advance or catch errors
>> after the fact is a matter of personal style.
> And in some implementations compiling might be a lot more expensive than
> simply checking, and if you're just providing on-the-fly feedback to a
> user while building a regex dynamically (for example), it might be better
> or more efficient to use valid-sre? instead of compiling.
>
> I'm sure that in Irregex at least the DFA compilation is much more
> expensive for complex regexes than a simple "is it valid"-type check
> would be.
I don't think that these are strong arguments for having 'valid-sre?'.
An implementation for which compiling is expensive, could easily
internally do the "is it valid"-type check before compiling. Having it
in the interface adds no functionality that is not already easily available.

I propose dropping 'valid-sre?'.