<a href="http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours">http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours</a><br><br>Not sure if this is exactly what you want, but you could certainly fufill all of your requirements using this as a baseline. Instead of evaluating the actual statements in your eval function, you could simply render them to C. <br>
<br>As far as FFI, if you are statically compiling to C, you can leave your variables unboxed. This would allow you to call C functions directly. <br><br>Hope that helps. <br><br><br><div class="gmail_quote">On Sat, Mar 7, 2009 at 6:32 PM, Loup Vaillant <span dir="ltr"><<a href="mailto:loup.vaillant@gmail.com">loup.vaillant@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is a homework question. I am mainly looking for guidance or<br>
pointers. Source code, even. (Not GHC's, though, it is too complicated<br>
for me right now. The AST of STG is fine, but the rest kinda scares<br>
me.)<br>
<br>
Ideally, I would very much like to compile to C.<br>
<br>
The requirements are easily stated. My language must<br>
-> be lazy by default,<br>
-> support algebraic data types and case expressions (unless I can get<br>
away with encoding them as functions),<br>
-> have some kind of FFI with C (I suppose it imply some support for<br>
unboxed values).<br>
<br>
There is also the first class functions thing, but lambda lifting is okay.<br>
<br>
I don't care about any kind of execution efficiency. I just want my<br>
compiler to be As Simple As Possible. Eventually, I intend to<br>
bootstrap. Then, I will start dreaming about doing better than the<br>
Mighty Simons. (I can dream, right?)<br>
<br>
I figured I would start by the back-end. I began to write 15 pathetic<br>
lines of code to start an STG machine. Needles to say, I am stuck. I<br>
don't know where to start.<br>
<br>
I am already familiar with some papers. In particular, [1] (on<br>
template instantiation), [2] and [3]. I once wrote a simple graph<br>
reducer using template instantiation (about 20 lines at most).<br>
<br>
I have chosen the STG machine because I thought i would be easier to<br>
get an FFI and case exprs out of it. Maybe I am wrong, and template<br>
instantiation is really easier. There is also the BRISK machine, and<br>
GRIN. But the paper I read were less readable to me than the three<br>
mentioned.<br>
<br>
So, If any of you can give me some pointer or guidance or advice about<br>
where to start, I would be very grateful.<br>
<br>
Loup<br>
<br>
<br>
[1] <a href="http://www.cs.otago.ac.nz/cosc459/books/pjlester.pdf" target="_blank">http://www.cs.otago.ac.nz/cosc459/books/pjlester.pdf</a><br>
[2] <a href="http://research.microsoft.com/%7Esimonpj/Papers/spineless-tagless-gmachine.ps.gz" target="_blank">http://research.microsoft.com/~simonpj/Papers/spineless-tagless-gmachine.ps.gz</a><br>
[3] <a href="http://research.microsoft.com/%7Esimonpj/Papers/eval-apply/index.htm" target="_blank">http://research.microsoft.com/~simonpj/Papers/eval-apply/index.htm</a><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>
</blockquote></div><br><br clear="all"><br>-- <br>We can't solve problems by using the same kind of thinking we used when we created them. <br> - A. Einstein<br>