catamorphism at gmail.com
Tue Feb 19 12:17:24 EST 2008
On 2/18/08, Guilherme Avelino <gavelino at gmail.com> wrote:
> I started my project implementing a stg compiler to .NET, as described in
> "Implementing Lazy Functional Languages on Stock Hardware: The Spineless
> Tagless G-Machine" [Jones, Peyton]. After that, I resolved to integrate it
> to GHC, so I thought the most easier way is to parser the STG representation
> generated for GHC, because it seems with the expected input for my backend.
There was some effort to build a .NET backend for GHC at some point. I
don't know what happened with that, but other people on this list
certainly will (which is why I'm replying to this to the list, even
though you sent your reply only to me.)
If you're just doing this to try to learn, of course, that's fine.
Parsing the -ddump-stg output is not easy. As Simon PJ said, it was
never intended to be machine-readable. It is intended for people who
are debugging the compiler.
> But, this is not possible without type informations. I´ve been trying to
> use the core language, but some changes are required to use it as my
> compiler input and I can´t find informations about the current GHC core.
The link that I sent you in my original reply:
contains a specification of External Core as of September 2001. There
have been some changes since then, which are not documented. As we
speak, I am working on revising the documentation and will be working
on bringing the External Core parser, typechecker and interpreter that
are part of the GHC distribution up to date. I hate to add to a long
history of wildly inaccurate External-Core-related time estimate, but
I expect to have this done within a month or two.
So if you can wait until then, it would save you a lot of effort.
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"If you keep *your* name, you don't need to know his." -- Marianne Terrot
More information about the Cvs-ghc