home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / function / 1473 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!nic.umass.edu!dime!roo.cs.umass.edu!pop
  2. From: pop@cs.umass.edu ( Robin Popplestone )
  3. Newsgroups: comp.lang.functional
  4. Subject: Compiling transparent closures
  5. Keywords: closure compile
  6. Message-ID: <57690@dime.cs.umass.edu>
  7. Date: 17 Dec 92 19:20:43 GMT
  8. Sender: news@dime.cs.umass.edu
  9. Organization: University of Massachusetts, Amherst
  10. Lines: 52
  11. Originator: pop@roo.cs.umass.edu
  12.  
  13. In POPLOG SML there is the possibility of compiling closures to a more
  14. efficient form by relying on the fact that there is a POP-11 view of any
  15. ML object, available through the POP-11/SML interface. In POP-11, a closure
  16. C is a transparent entity for which pdpart(C) is the code, and frozval(i,C)
  17. is the i'th frozen value. Thus something like
  18.  
  19. define compile_closure(C);
  20.  popval( [ procedure  compile_1(C) %]);     ;;; compile stacked tokens.
  21. enddefine;
  22.  
  23. define compile_1(C);            ;;; Stack up POP-11 tokens
  24.   lvars C;
  25.   if is_closure(C) then
  26.     lvars i,n = datalength(C);
  27.     pdpart(C),                    ;;; Treat code part as function call
  28.     "(",
  29.     for i from 1 to n do          ;;; Stack up frozen values
  30.       compile_1(frozval(i,C));","
  31.     endfor, ")";
  32.   else C
  33.   endif;
  34. enddefine;
  35.  
  36. ml_val compile:('a->'b)->('a->'b) = compile_closure;
  37.  
  38. should work (The POP-11 compiler has a very general notion of "token").
  39. Or alternatively one could generate VM code directly using sysPUSH, sysCALL
  40. etc..
  41.  
  42. With any implementation, doing something more direct like trying to take
  43. code blocks apart is liable to present long-term maintenance problems. The
  44. POP-11 function product operation does in fact appear to concatenate the
  45. code blocks, but then it is maintained by the implementors...  The
  46. underlying conventions of any implementation can undergo cataclysms that
  47. are transparent to users (e.g. the requirements of an efficient interface
  48. to X-Windows, including callback from C, caused a significant revamp of
  49. POPLOG in the late 80's).
  50.  
  51. Thus it is an interesting question  as to what abstractions on  code-blocks
  52. would  be  useful.  The  frozval/pdpart   abstraction  was  based  on   the
  53. lambda-lifting approach  to  closures developed  for  POP-2 c.1968.  It  is
  54. general, but to prescribe it for a language like ML could be considered  as
  55. too  constraining  on   implementors,  who   might  want  to   go  for   an
  56. environment+code model of closure. Even worse is the problem of the code
  57. for non-closures. These may be considered to consist of a prologue (which
  58. establishes the PAR) a body and an epilogue. The POP-2/POP-11 approach of
  59. specifying argument passing and result returning on a stack provides a nice
  60. way in which one might be able to treat the above components of a code
  61. block as independent entities susceptible to recombination. However it is
  62. not an approach that makes for lightweight continuations (and I for one
  63. would dearly like to see ML outperform C for systems-programming
  64. applications; this clearly requires continuations to be light-weight).
  65.