On Sun, Feb 22, 2009 at 8:15 AM, John Meacham <span dir="ltr"><<a href="mailto:john@repetae.net">john@repetae.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote:<br>
> Would it be possible to separate the frontend (Haskell to Core) and backend<br>
> (Core to machine code) from the Haskell compilers (requiring a standard Core<br>
> language?)<br>
> I'm not sure how many extensions required a change to the Core language.<br>
<br>
</div>Well, it depends on what you mean by 'core'. If you mean a desugared<br>
version of haskell, I think such a front end could be quite useful.</blockquote><div><br>By the way, coming up pretty soon, I will need a desugared <i>annotated</i> Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-)<br>
<br>Luke<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> in<br>
particular, I'd like to see a standalone implementation of template<br>
haskell. If you mean something lower level, as in the ghc core<br>
intermediate language the compiler uses internally, or jhc's core or<br>
grin representation, things get a bit more tricky.<br>
<br>
Although many core languages are somewhat similar, based on a typed<br>
lambda calculus of some sort, the details will differ, and translating<br>
between them can be lossy.<br>
<br>
For instance, looking at jhc core:<br>
<a href="http://repetae.net/computer/jhc/manual.html#jhc-core-type-system" target="_blank">http://repetae.net/computer/jhc/manual.html#jhc-core-type-system</a><br>
you can see it has a very rich language for dealing with strictness and<br>
boxedness. For instances, a boxed value known to be in WHNF actually has a<br>
different _type_ than one that is possibly unevaluated. Such<br>
distinctions are quite useful for jhc's back end but not so much for<br>
ghc's, hence ghc core doesn't make that distinction and any translation<br>
between the two would 'lose' that useful information.<br>
<br>
In other cases things are even worse, for instance ghc has a powerful<br>
type equality concept in its core language which jhc has no counterpart<br>
for, so that information will be lost on translation. But losing that<br>
information will actually cause the core to not type check, since ghc<br>
core can type some things jhc core cannot (and vice versa) so coercions<br>
or other mechanisms to bypass the type system will have to be<br>
introduced.<br>
<br>
So, it is certainly possible to translate between the two, in fact, I<br>
made a jhc core -> ghc core translator, but the code it produced was<br>
necessarily riddled with unsafeCoerce#'s for everywhere the type systems<br>
didn't quite match up.<br>
<div><div></div><div class="Wj3C7c"><br>
John<br>
<br>
<br>
--<br>
John Meacham - ⑆<a href="http://repetae.net" target="_blank">repetae.net</a>⑆john⑈<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>