🚀 go-pugleaf

In POPLOG SML there is the possibility of compiling closures to a more
efficient form by relying on the fact that there is a POP-11 view of any
ML object, available through the POP-11/SML interface. In POP-11, a closure
C is a transparent entity for which pdpart(C) is the code, and frozval(i,C)
is the i'th frozen value. Thus something like

define compile_closure(C);
 popval( [ procedure  compile_1(C) %]);     ;;; compile stacked tokens.
enddefine;

define compile_1(C);            ;;; Stack up POP-11 tokens
  lvars C;
  if is_closure(C) then
    lvars i,n = datalength(C);
    pdpart(C),                    ;;; Treat code part as function call
    "(",
    for i from 1 to n do          ;;; Stack up frozen values
      compile_1(frozval(i,C));","
    endfor, ")";
  else C
  endif;
enddefine;

ml_val compile:('a->'b)->('a->'b) = compile_closure;

should work (The POP-11 compiler has a very general notion of "token").
Or alternatively one could generate VM code directly using sysPUSH, sysCALL
etc..

With any implementation, doing something more direct like trying to take
code blocks apart is liable to present long-term maintenance problems. The
POP-11 function product operation does in fact appear to concatenate the
code blocks, but then it is maintained by the implementors...  The
underlying conventions of any implementation can undergo cataclysms that
are transparent to users (e.g. the requirements of an efficient interface
to X-Windows, including callback from C, caused a significant revamp of
POPLOG in the late 80's).

Thus it is an interesting question  as to what abstractions on  code-blocks
would  be  useful.  The  frozval/pdpart   abstraction  was  based  on   the
lambda-lifting approach  to  closures developed  for  POP-2 c.1968.  It  is
general, but to prescribe it for a language like ML could be considered  as
too  constraining  on   implementors,  who   might  want  to   go  for   an
environment+code model of closure. Even worse is the problem of the code
for non-closures. These may be considered to consist of a prologue (which
establishes the PAR) a body and an epilogue. The POP-2/POP-11 approach of
specifying argument passing and result returning on a stack provides a nice
way in which one might be able to treat the above components of a code
block as independent entities susceptible to recombination. However it is
not an approach that makes for lightweight continuations (and I for one
would dearly like to see ML outperform C for systems-programming
applications; this clearly requires continuations to be light-weight).