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