> 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. Isn't the point really that you need to know when the overlap is empty, so you don't get a combinatorial explosion of cases? Lars Mathiesen (U of Copenhagen CS Dep) <[EMAIL PROTECTED]> (Humour NOT marked)
- RE: combinator parsers and XSLT Doug Ransom
- RE: combinator parsers and XSLT Manuel M. T. Chakravarty
- Re: combinator parsers and XSLT Marcin 'Qrczak' Kowalczyk
- Re: combinator parsers and XSLT Manuel M. T. Chakravarty
- Re: combinator parsers and XSLT Marcin 'Qrczak' Kowalczyk
- Re: combinator parsers and XSLT piet
- Re: combinator parsers and XSLT Marcin 'Qrczak' Kowalczyk
- Re: combinator parsers and XSLT Manuel M. T. Chakravarty
- Re: combinator parsers and XSLT Marcin 'Qrczak' Kowalczyk
- Re: combinator parsers and XSLT Manuel M. T. Chakravarty
- Re: combinator parsers and XSLT Lars Henrik Mathiesen
- Re: combinator parsers and XSLT Manuel M. T. Chakravarty
- Re: combinator parsers and XSLT Tom Pledger
- Re: combinator parsers and XSLT Manuel M. T. Chakravarty