Recursive mono

[b-studios]

This is an experiment to lift some restrictions in the mlton monomorphization PR #229

There are many different ways to solve the problem of (mutual) recursion over datatypes / records which are introduced by monomorphization. None is really satisfying.

https://gist.github.com/b-studios/c52a5c7a9cfa6c0021f441d3ac2655a2

Alternative 1

  (fn a => 1 + a,
   fn b => fn c =>
    if b then (#2 (myFun ())) b c else c);

print (Int.toString ((#2 (myFun ())) false 1));

This works, but is suboptimal, since ALL block member selections need to be translated to first "force". I don't like it, but it is the only solution so far, that actually works...

Alternative 2

Here is another version of the same idea, but it does not require to change any use sites:

  fun left self = (case (self ()) of
    (l, r) => l
  );
  fun right self = (case (self ()) of
    (l, r) => r
  );
  fun makeFun () = (fn a => 1 + a, fn b => if b then (right makeFun) b else false);
in makeFun () end;

print (Bool.toString ((#2 myFun) false));

It only requires to redefine the extractors locally (since they need to force self). However, it does not work in MLton (and also variants) since myFun will not be generalized.

Also local function definitions will not be generalized.

Alternative 3

This does also not work:

  (fn a => 1 + a,
   fn b => fn c =>
    if b then (#2 (makeFun ())) b c else c);

val myFun = makeFun ();

print (Int.toString ((#2 myFun) false 1));

Due to let generalization failing on myFun. Annotating explicitly gives:

Error: out/experiment.sml 6.5-6.9.
  Type of variable cannot be generalized in expansive declaration: myFun.
    type: _ * (_ -> ['a] -> ['a])
    in: val 'a myFun: ((int -> int) * (bo  ...  > 'a))) = makeFun ()

makeFun () is not a value and does not follow the value restriction! It does not know that it is pure, which would be an alternative to the value restriction..

Summary

So in the end, it looks like we can only go with Alternative 1 which is implemented in this PR.

Here is a very small and preliminary nano benchmark to check that this encoding does not massively lead to performance problems:

https://gist.github.com/b-studios/59d48fb4873341d7c64cc4f57ded953d