One part of the solution that I didn't like is that the constraint on a
method had to explicitly list all the classes that declared that method.
That hampers generating the binding a class at a time, so I fixed it. I
still don't match the type of the method against the types declared, but
that sho
G'day all.
Quoting Peter Simons <[EMAIL PROTECTED]>:
> Just curious: Why would you want something like that? I thought that
> the good thing(tm) about regular expressions is that they can be
> parsed by a finite state machine rather than a recursive descent
> parser, [...]
Regular expressions ca
This seems to work. The type checker picks one rule to use at each point
so you can't get backtracking, but you explicitly build the sequence of
base classes, and use the overloading resolution to stop if we find our
goal. This is clever.
It looks like prolog could be interesting. My first introdu
G'day all.
Quoting Graham Klyne <[EMAIL PROTECTED]>:
> Nice. Do you know if anyone has done anything like this for regular
> expressions?
I've done it for regular expressions (e.g. lex, alex etc), but not for
regexps (e.g. Text.Regex). This particular terminology overload annoys
me no end, by
On Tue, 21 Oct 2003 13:47:51 +0100
Graham Klyne <[EMAIL PROTECTED]> wrote:
> At 04:17 21/10/03 -0400, [EMAIL PROTECTED] wrote:
> >I think I might have mentioned this previously, but here's an
> >interesting implementation of Knuth-Morris-Pratt substring searching
> >(which is indeed a "little lang
Graham Klyne writes:
> I'm thinking in particular that a function that turned a regular
> expression into a Parsec parser function could be useful, as in:
> regexp.compile :: String -> GenParser Char st [String]
Just curious: Why would you want something like that? I thought that
the good
