proposal: standardize interface to Haskell' implementations

[Simon Marlow]

On 12 February 2006 22:43, Claus Reinke wrote:

> [an innocent question on ghc-users just reminded me of another
>  missed opportunity in previous Haskell definitions: by chosing to
>  ignore the very idea of implementations, they have left tool
>  implementors in a limbo.]
> 
> these days, there is some momentum for providing Haskell with
> various tools for refactoring, documentation, profiling, tracing,
> instance generators, analyzers, pre-processors for extensions,
> editor modes, interactive interfaces (textual, graphical, visual),
> .. and even first ides, but all that is hampered by the lack of a
> standardized interface to functionality that exists in every single
> Haskell implementation: parsing, type checking, AST, (pretty
> printing,) semantic information, (evaluation).
> 
> that functionality is common to most tools, hard (and
> unneccessary) work to reimplement, and almost impossible to
> keep up to date, diverting precious man-power from small teams
> trying to provide much needed tools.
> 
> all we have at the moment is the haskell-src part of the libraries
> Language.Haskell.{Parser,Pretty,Syntax), and some Hugs- or
> GHC-specific APIs (Hugs Server API, package GHC), or other
> frontends like Programatica, etc..
> 
> compare that with Lisp, Smalltalk, SML/NJ and the like, where
> reflection support means that tool builders get a fantastic head
> start by being able to reuse available implementation functionality.

You don't say what you don't like about the existing Language.Haskell.*
libraries - on the face of it, don't they at least fulfill the
requirements for a re-usable Haskell AST, parser, and pretty-printer?
That's what they were intended to be, because we recognised the
importance of having this a long time ago.

I'll start to answer my own question: no they don't fulfill the
requirements.  Not many projects *use* Language.Haskell.*.  Why is that?
One very good reason is that the AST isn't at all extensible, and
everyone wants to extend Haskell.  Even in Haddock, I couldn't use
Language.Haskell.Syntax because I wanted to add annotations to the AST.
Later on I wanted to add GHC extensions too.  So the programmatica
project started with Language.Haskell.Syntax and made it extensible
(that's my understanding - please correct me if I got the history
wrong).  Also, we now have haskell-src-exts which is haskell-src + (some
fixed set of extensions).

So if you standardise the AST, I'm pretty sure it has to be extensible
to be useful.  It seems hard to do a good job of this: Haskell doesn't
do open-ended extensible types very well, the programatica solution is
neat but a little unweildy if you ask me.

I'm not entirely sure why you're using the term "reflection" here - I
suppose there's some overlap in that you might want to obtain the AST of
the data declaration for a particular type at runtime, but mostly I
think runtime reflection is separate from a reusable front-end.  The
Data.Generics library does a pretty good job of reflection.

Standing back a little, I think this is an ideal candidate for a
standardisation process independent of Haskell' - it's too big a task to
squeeze into the Haskell' timeframe, and there are no dependencies that
prevent it from being separately defined.  It's just a library, after
all.

Cheers,
	Simon