[MLton] space safety for structures

Henry Cejtin henry@sourcelight.com
Fri, 2 Jul 2004 16:10:27 -0500


I would still argue strongly that in the more complicated case

    structure S =
       struct
          val l = <big object>
          val x = <small object>
       end

    structure T =
       struct
          val _ = <long computation>
       end

    structure U =
       struct
          val _ = <use of S.x but not S.l>
       end

then S.l is dead way before the <long computation> is evaluated.

Part  of  my  argument  is based on the fact that structures are NOT run-time
objects, they are just namespace control.

The argument about separate compilation is some what of a red herring  in  my
opinion because even with that, garbage collection requires global knowledge.

The problem is simply being caused not so much by separate compilation as  by
the  REPL.   Once  you have a REPL, all globals, or any thing in scope of the
REPL, must be viewed as part of the root set.

Once you have a notion of a closed world (no more `use'), safe for  space  in
the  MLton sense is clearly the way to go (I claim).  As you say, it requires
a global liveness, but that is just because that liveness is  doing  part  of
the  GC  at  compile time (which is good).  Switching to inserting black-hole
code would be pushing some of the GC back to run time (not good).