Mon, 10 Sep 2001 12:37:26 -0700
> I didn't get back until yesterday afternoon, so I didn't get a chance to tell
> you what went on, but the summary was: it was FANTASTIC. Truly MLton was
> much much discussed. There is no denying that the tee shirts that Stephen
> made up were a truly great bit of marketing.
I agree with Henry. I talked to 10-15 different people about MLton, and all
seemed quite positive, including other SML compiler people (Russo, Harper,
Dimock, ...) and functional compiler people (Karl Filip-Faxen, Fergus
Henderson, ...). The use of MLton by the TILT group in the ICFP contest was
especially pleasing. As to the t-shirts, they were such a success that I
think I will make one more batch in the same style, since I already should
send one to Tom Murphy, and probably Barak. Also, I promised one to some guy
if he ports MLton to BSD. Henry promises us a new, more professional design
by our next conference.
Other interesting news.
* Bob Harper said that some student of his is using some portion of MLton's
front-end for a certifying compiler prototype. I asked him to put the
student in touch with us.
* Riccardo Pucella is thinking of making his mlidl stuff work with MLton.
* The TILT compiler is supposed to have an initial release in the next month
* The SML.NET compiler is close to a self-compile, and will have a release
when legal allows it.
> I think that Stephen wrote some stuff on ideas for the opus.
I wrote several pages of notes one evening. My take on the whole paper is that
it is mostly informal (hence, I'm not sure JFP is right, but ignore that for
now). We can talk about the lessons we have learned in 4+ years (wow) of a
compiler project and about what we think MLton has demonstrated: effectiveness
of whole-program compilation, applicability of traditional optimizations,
I'll try to type in my notes and send them out this week.
> Simon Peyton Jones told Stephen that he would like to have an article on
> MLton for the Journal of Functional Programming, so he (Stephen) and I talked
> a bit about the opus. My notion would be that especially for that journal
> the point is showing the translation down to the (new) SSA IL, mainly with
Yes. This sounds good to me.
> and then talking about things like how the types used express all
> the information that the flow analysis found, and also prove that that
> analysis was safe.
> I.e., the basic point would be pushing the idea of
> monomorphisation and de-functionalization down to a simply typed first order
> language being possible, practical and effective.
Yep. This summarizes the main point of the paper very well.
> Truly wonderful! I would love to start working on the opus again and the
> pitch from Peyton-Jones is an outstanding piece of good news! I think the
> opus should be very much along the lines you suggested, with maybe a slightly
> more expansion of the SAS paper talking about closure conversion.
I don't want to go down the path of spelling out ILs (other than maybe SSA)
and translations formally in the paper. The problem is that will lead to way
to much bloat. I think that apporach detracts from our main points, which are
independent of technicalities.
> I also
> think that there's a tremendous amount to be gained in talking about
> optimizations possible on the first-order language, especially based on the
> latest release. Do you guys want to setup a time sometime this week to talk
> about it? I'd be happy to take a first crack at structuring the paper (using
> the earlier (presently defunct) version of the opus as a starting point).
I think we are all in agreement about the importance of stressing first-order
traditional optimizations. Good. As to the defunct opus, as far as I am
concerned, some of it is still relevant, like the overview, and compiler
structure, but some of it is way too detailed, like the flow analysis stuff.
Again, I don't think it is worthwhile to put in the detailed formalism for
flow analysis, contification, monomorphisation or anything else. We can refer
to other papers or the compiler sources. I think the paper will have much
more impact and be more widely accepted if we stick to examples and general
> Also Stephen and I talked a bit about a new optimization (and change to the
> IL) for handing exceptions.
I wrote down about 10 pages of notes, semantics, safety conditions, etc on the
plane ride back from Paris. I'll try to tex them up in the next week or two.
As an overview, here's what I imagine.
* Source IL: First-order direct-style language.
* Translation from direct-style to SSA IL via a CPS like algorithm. This
translation also does handler inference, converts raises to jumps, and
annotates nontail calls with the desired handler. This pass is not in MLton
yet, but it will be as soon as SSA gets pushed back to the closure converter.
* Show how explicit insertion of Save, Restore, SetLocal, and SetHandler l
statements into the SSA program can implement handlers.
* Safety constraints on the inserted statements that verify that they have the
proper handler at calls, returns, raises, etc.
* Several different strategies for inserting statements. I have a couple in
mind, but there is definitely room for improvement here.
* Dynamic counts comparing the strategies to each other and to what is
dynamically optimal (which can be computed by eliminating redundant
statements at run time).
* Some measure of the overall run-time and code-size cost of handlers.