Thank you for your comments.  I don't understand the first two.

John Cowan wrote:

> 1) I suggest exposing the textual->text macro provided in the
> implementation, either as a macro or as a wrapper procedure.  It may be
> convenient for users that want to make sure they are always getting the
> O(1) benefit.

A textual->text procedure would not be O(1).  I'm guessing you
mean the result returned by that procedure would always be a
text, which would guarantee O(1) running time when that result
is passed to certain other procedures.

> 2) I think that the O(mn) constraint on text-contains(-right) should be
> flushed, so that implementations that favor either small data or small
> code can coexist with those that favor speed.

I don't see how the O(mn) constraint interferes with small data,
small code, speed, or combinations thereof.

The usual algorithm for naive string search, combined with the
O(1) guarantee for text-ref, already gives you O(mn) running time.

In the sample implementation, that algorithm is implemented by the
%textual-contains:naive and %textual-contains-right:naive procedures.
Their code is pretty small.  Indeed, their code is smaller than the
code required to parse optional arguments passed to textual-contains
and textual-contains-right.  Implementations that want to minimize
code size can flush the more sophisticated algorithms and still
achieve the O(mn) constraint.

The purpose of the O(mn) requirement is to outlaw extraordinarily
naive algorithms, such as those that extract so many subtexts they
take Omega(m^2 n) time.

Will