> 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 things to download, documentation, and giving a
> forum for discussions and applications of the parsers. Ideas range
> from simple formatting tools to library browsers ("I know there is a
> function with a similar type signature somewhere...") or computer
> aided source-to-source transformations.
Good for you!
I believe that Happy is either very nearly capable of supporting
a full Haskell parser, or is so capable (but nobody has built one).
Simon Marlow can doubtless advise.
In any case, a Happy-based Haskell parser would be a wonderful
thing, along with (as you say) an abstract syntax.
One point: in GHC we are very careful to keep the full Haskell
syntax present in the abstract syntax tree. So,
x:[]
is represented differently from
[x]
in the algebraic data type representing a Haskell program.
That makes the data type quite a lot bigger, but it does mean
that you can print out exactly the program that was read in,
rather than an equivalent but bastardised version.
Keeping source-location info is also important.
You might find GHC's HsSyn data types were a good start. I don't
propose them as the Right Thing.
(And I definitely don't propose GHC's current parser. Let's
do it all in Haskell.)
Simon
