forwarded message from Henry Cejtin

Tue, 10 Oct 2000 15:37:01 -0700 (PDT)

Message-Id: <200010102222.RAA32337@syzygy.clairv.com>
From: Henry Cejtin <henry@sourcelight.com>
To: sweeks@intertrust.com
Subject: Re: MLton's closure conversion
Date: Tue, 10 Oct 2000 17:22:08 -0500

Interesting.  Note, one thing we can do is to delay any selection (or some of
the selections) until you get to a split in the control flow such  that  some
of  the  environment  is  dead  in one of the branches.  Since everything was
flattened out already in the F2 example (non-curried case) this wouldn't help
there,  I  could  imagine big improvements otherwise.  I.e., in one branch of
that all the environment is dead, and in the other all of it is  alive:  thus
you  would  just  delay  all selects (eliminating them from the fast case and
delaying further in the slow case).

The general problem of currying also is interesting.  We tend not to use  it,
so  it  doesn't  show  up  very much in our code.  We could transform curried
functions into curried calls to uncurried ones.  I.e., replace

    fun f a b c =
           if a > 0
              then f (b + c) x (f y z w)
           else 17

to
    fun f' (a, b, c) =
           if a > 0
              then f' (b + c, x, f' (y, z, w))
              else 17

    fun f a b c = f' (a, b, c)

and then use the inliner to convert the f calls to f' in the case that it  is
completely called.