Manuel M. T. Chakravarty writes:
> Lars Henrik Mathiesen <[EMAIL PROTECTED]> wrote,
>
> > > From: "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]>
> > > Date: Fri, 29 Sep 2000 10:17:56 +1100
> >
> > > I agree that usually the predicates as proposed by you would
> > > be better. The problem is that a scanner that wants to use
> > > the usual finite deterministic automation techniques for
> > > scanning, needs to be able to compute the overlap between
> > > different predicates.
> >
> > If the predicates are functions, computing the overlap as another
> > function is easy.
>
> Ok, I should have been more precise. The problem is to make
> it efficient. Usually, this is achieved by having a table
> into which you index with the input character to compute
> what state to enter next. If you have many predicates and
> potentially have to test a large number of them for each
> input character before being able to determine the next
> state, this might adversely influence the performance of the
> scanner.
>
> Manuel
Would it help to use lazily populated tables, to cache the results of
evaluating the corresponding predicates? It could be done in an outer
layer, so that it doesn't mar the purity of the predicate composition
approach. It may even be a happy medium, in cases where the input
document only uses a tiny fraction of the character set.
Regards,
Tom
