"Simon Peyton-Jones" writes:

| If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted.

Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces System F code ("External Core"), in a file Foo.hcr. I'm not sure whether that was what you meant.

External Core is great for some purposes - if you want to play with new optimisation techniques for instance. A tracing system like Hat however wants to have lots of direct linkage back to the original source code. External core doesn't bear a terribly close resemblence to the source - it would require a significant amount of re-sugaring for presentation to the user of Hat. It also loses the actual location of expressions (line/column), although perhaps GHC-as-library would be better in this respect. The ideal front-end for a syntax-directed tool like Hat consists solely of a lexer/parser to an abstract syntax tree, with no desugaring whatsoever, and no typechecking. This is essentially what we have at the moment, but based on nhc98's front-end. For better coverage of language extensions, ghc's parser might be preferable. One can imagine that other tools would want to plug into the pipeline at differents points (after desugaring but before type-checking; after type-checking; etc.) Regards, Malcolm

On Thu, 2005-06-30 at 10:36 +0100, Simon Peyton-Jones wrote:

| If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted.

Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces System F code ("External Core"), in a file Foo.hcr. I'm not sure whether that was what you meant.

That is one option, but it wasn't really what I meant. I was thinking of plain old Haskell library code that implements Lexer, Parser, Desugar, Type Inference etc. All the bits that happen at the front of a Haskell compiler. This is what hatchet was supposed to be, and may one day become. I've tried in the past to pull the front end off ghc and nhc98 without much luck. Though it looks like ghc-as-a-library might be just what the doctor ordered. There is also the Programmatica project which seems to do a lot of what I'm thinking of already.

However, External Core doesn't seem to have really caught on.

One problem is that different tools will want different views of the code. External Core is probably too far away from the original source for something like hat.

Only 5% said it was essential, with another 16% saying "nice to have".

I would hazard a guess that fewer than 5% of GHC's users are writing source transformation tools :)

I'm sure there's room to improve the ExtCore route.

You are right, and to be honest I haven't really given much thought to that route until now. Thanks for the pointer. Cheers, Bernie.