ICFP?

[Stephen Weeks]

> 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
  or two.

* 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,
etc. 

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
> examples,

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
lessons learned.

> 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.