[MLton-devel] teaching a compiler course using MLton

[Suresh Jagannathan]

This is a first-year graduate course.  I suspect this will be the
first significant compiler class for most students.  I like your
idea for (1); maybe a reasonable compromise would be to use
the functional variant of Appel's Tiger as the source language.  
Students would have access to code for lexing and parsing such
a language, and could refer to the book for ideas on compiling its
various constructs.

It would require writing some translation passes from a simplified IL to 
MLton's, and figuring out how to merge MLton's implementation with 
the description given in the book.  The fact that Fun-Tiger is fairly
close to ML helps in the first case; I don't have a good sense of how
to explain MLton's compiler strategy in the context of a text like
Appel's; maybe we just don't and treat MLton as tool rather than as
an open compiler students examine.


On Thursday 19 September 2002 12:29 pm, Stephen Weeks wrote:
> > I'd rather not have students directly mimic MLton's compilation
> > strategy since I think it's sufficiently different/complex to make
> > it infeasible for a first-year grad. course.  Instead, I've been
> > thinking of a project along more classical lines:
> >
> >   -- convert source to CPS (A-normal form)
> >   -- implement 0CFA
> >   -- flow-directed inlining, uncurrying
> >   -- closure conversion
> >   -- simple first-order optimizations -- loop-invariance,  common
> >               subexpression, useless argument, ...
> >   -- code generation
>
> It looks to me like the major difference from MLton's strategy is that
> you put flow-directed inlining before closure conversion.  I suspect
> that is harder than putting it after (as MLton does).
>
> > The idea here is that we use the MLton backend for code generation;
>
> I think it would be cooler to have MLton more tightly integrated than
> just as a backend.  Here are a couple of ways I see to do this.
>
> 1. At the end of each pass, have the students target one of MLton's
> ILs, or some suitably sanitized version that you write a translator
> for.  This way they can test correctess and real performance impact at
> each pass.
>
> 2. Focus on adding a language feature (e.g. laziness) and pushing it
> all the way through the real compiler.  This way, students can see a
> lot, and what they do will have immediate, realistic impact.  Then
> look at how various SSA optimizations affect performance.  They can
> write a real optimization that affects real programs.
>
> My worry is that if you just do what you propose, there is a lot of
> overhead for the students in learning how to work with MLton without a
> lot of payoff.
>
> Will most of the students already have had one compiler course?  If
> not, then (1) seems better.  If so, then (2) seems better -- there is
> no need to have the students implement all the steps of compilation in
> detail.  It would probably be more instructive and fun to work on a
> real compiler.
>
> Note, I am not saying that (2) should have any research component at
> all.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> MLton-devel mailing list
> MLton-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mlton-devel


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel