[Haskell-cafe] Translating Haskell to VHDL. What approach to follow?

Simon Peyton-Jones simonpj at microsoft.com
Mon Nov 6 03:37:01 EST 2006


| 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


More information about the Haskell-Cafe mailing list