home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / mcl / 1598 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  1.3 KB
  1. Path: sparky!uunet!spool.mu.edu!caen!saimiri.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!kab
  2. From: kab (Kim Barrett)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: Making a lambda-expr more like a fn
  5. Message-ID: <9211161525.AA16302@cambridge.apple.com>
  6. Date: 16 Nov 92 15:26:01 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 23
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. > One of the changes to CL2 that bit me has been that
  12. > raw lambda's can no longer be funcall'd (or apply'd)
  13. > directly.
  14. > 
  15. > With CMULisp, I have remedied this by coercing the lambda
  16. > into a function first:
  17. > 
  18. >         (setf (org-lexpr p) (coerce lexpr 'function))
  19. > 
  20. > But CCL::COERCE-TO-FUNCTION won't have it:
  21.  
  22. This is a known bug.  I believe there's a patch for it, but don't remember the 
  23. name.  Try asking bug-mcl.
  24.  
  25. > I was able to get what I wanted compiling the form instead.  However, in
  26. > this application, I would like very much to avoid the compilation overhead
  27. > if at all possible.  Can I?
  28.  
  29. Since MCL is (for the most part) a compiled-only implementation, there is 
  30. actually no real difference between the forms (coerce lexpr 'function) and 
  31. (compile nil lexpr), except that the former fails due to a bug.  That is, if 
  32. the bug were not present then the call to coerce would call the compiler to 
  33. process the lambda expression.
  34.