| In order to get part of the work for free I decided to design the | translator as a compiler backend. The best option so far seems to be | Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which | unfortunately lacks type information. | | I discarded GHC due to the current "bit-rotted" state of External Core | (http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html | ) and higher complexity of its core representation (SystemFC).
Yhc is a great, so don't let me stop you using it... but I can't resist explaining why FC is the way it is. There is a real tension here between simplicity and types. The reason that GHC uses FC as its intermediate language is precisely because FC is the simplest *typed* language we know that can serve as a target for Haskell. If you drop the types, you certainly can use a simpler language! However, you only pay for what you use; for example, if you don't use newtypes, GADT's, associated types, you won't see any coercions. It's true that the ExtCore rep is somewhat bit-rotted, but the only thing missing to get Core *output* is someone to beef up the pretty printer. I'd do it myself, except that there is a *design* task to do, namely to fix the concrete syntax for some of FC's constructs. One could choose anything, but it'd be good to choose a syntax that is easy to parse. Once the syntax is designed, it'd take an hour or two to make GHC emit it. (There's a separate job to make GHC parse and typecheck ExtCore as its source program, but you don't need that.) Aaron Tomb has offered to become the maintainer for External Core; I'm sure he'd be interested in having a "customer". Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe