You may have a look at my version of the parser combinators, which:
- are deterministic, and thus relatively fast
- correct errors in the input
- have now been tuned with a scanner coming with it
- have been extended with some new useful combinators.
Unfortunately I am now in Bolivia (so do not
Simon PJ says:
> I believe that Happy is either very nearly capable of supporting
> a full Haskell parser, or is so capable (but nobody has built one).
One thing that springs to mind is that adding yacc-style %right and
%left directives to Happy would be very useful in constructing a parser
gram
I saw the usefulness/need of a Haskell parser for various applications
sometime ago as well. Hence I had a student write one for me. Before you
hold your breath let me state first that it is currently a
pre-alpha-alpha version.
The parser is really built in Haskell (not with parser generators ;-)
Sven Panne <[EMAIL PROTECTED]> writes:
> A long-standing gap in Haskell environments is the lack of tools
> (written in Haskell, of course :-) for the manipulation or analysis of
> Haskell source programs. Other languages have a rather rich collection
> of such tools:
>
> [blah blah blah]
>
> On
> So here is my call for contribution:
>
>Send an abstract syntax and/or a parser specification!
>
> It doesn't matter if a parser generator is used or recursive descent
> techniques are applied.
>
> If there is enough echo, I'd like to setup a web page for this
> project, containing thing
Which Haskell tools, if any, correspond to MLYACC and MLLEX?
The document "The Definition of Standard ML (Revised)" attempts
to describe ML with a quality suitable for compiler writers.
Shouldn't Haskell have something of similiar quality and intent?
I realize that funding is an issue,
but these
