[MLton] ML Workshop, sML Evolution, and CUFP trip report

[Stephen Weeks]

> The piece that is in SMLSC that is not in MLBs is that SMLSC allows
> you to compile against an interface without having the
> implementation immediately available.  With MLBs, we need to
> elaborate some body of code to determine the basis environment under
> which the new code is elaborated.

Thanks, that makes perfect sense.  They say as much in the paper:

  ML Basis does not provide a way for programmers to write down
  interfaces or separately compile against unimplemented bases.

I just needed it pounded into my head one more time to make sense.

> If there was some way to express a basis environment directly, then
> you would have something much like SMLSC with MLBs.

Being able to write down a basis environment for the purpose of type
checking against a basis without having the implementation seems
useful, although I've not felt much pain using the fully functorized
style when prototyping.  I guess that's because when I want to assume
the existence of some module, I'm typically only using it in one other
module, and so the import is easily expressed with a functor.

> Just from my brief reading of the UM specification, it sounds like
> there is a lot of array access going on, so I'm not surprised about
> the hit from bounds checks.

50% still seems like too much to me.  For example, the bounds-check
hit on my machine for matrix multiply is less than 10%.

> It would be nice to have a stronger bounds check removal pass.

Indeed.  Anyone on the list interested?  I read the ABCD stuff a while
back and it seemed like it like it could get reasonable info and could
be fast enough to put in a whole-program optimizer.