home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / mcl / 1599 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.3 KB
  1. Path: sparky!uunet!sequent!ogicse!emory!swrinde!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!stanford.edu!eos!data.nas.nasa.gov!taligent!apple!cambridge.apple.com!bill@cambridge.apple.com
  2. From: bill@cambridge.apple.com (Bill St. Clair)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: Making a lambda-expr more like a fn
  5. Message-ID: <9211161528.AA16443@cambridge.apple.com>
  6. Date: 16 Nov 92 16:33:40 GMT
  7. Article-I.D.: cambridg.9211161528.AA16443
  8. Sender: info-mcl-request@cambridge.apple.com
  9. Lines: 45
  10. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  11.  
  12. At 23:03 11/15/92 -0800, Rik Belew wrote:
  13. >One of the changes to CL2 that bit me has been that
  14. >raw lambda's can no longer be funcall'd (or apply'd)
  15. >directly.
  16. >
  17. >With CMULisp, I have remedied this by coercing the lambda
  18. >into a function first:
  19. >
  20. >        (setf (org-lexpr p) (coerce lexpr 'function))
  21. >
  22. >But CCL::COERCE-TO-FUNCTION won't have it:
  23. >
  24. >
  25. >> Error: value (LAMBDA (WLIST &AUX X1) (SETQ X1 (NTH 0 HISTORY)) (VALUES (+ (CAR WLIST) (* (NTH 1 WLIST) X1)) (LIST 1.0 X1))) is not of the expected type FUNCTION.
  26. >> While executing: CCL::COERCE-TO-FUNCTION
  27. >
  28. >I have also tried prepending the #' (function) abbrev., but
  29. >that result couldn't be funcalled either.
  30. >
  31. >I was able to get what I wanted compiling the form instead.  However, in
  32. >this application, I would like very much to avoid the compilation overhead
  33. >if at all possible.  Can I?
  34.  
  35. At 11:28 11/16/92 +0000, Ranson wrote:
  36. >Only the evaluator and the compiler process #' to create a function. If you
  37. >don't want to compile, call EVAL.
  38. >Or better, try to not create functions at run time.
  39. >     Daniel.
  40.  
  41. Daniel is correct. COERCE will either call COMPILE or do preprocessing for
  42. EVAL depending on the value of *compile-definitions*. The problem with
  43. COERCE is a known compiler bug. Compiling the expression:
  44.  
  45.   (coerce x 'function)
  46.  
  47. results in a call to ccl::coerce-to-function. It should result in a call to
  48. ccl::coerce-to-function-1. You can fix this in a number of ways:
  49.  
  50. 1) Take Daniel's advice and don't try to create functions at run time.
  51.  
  52. 2) Ask me to send you "coerce-to-function-patch"
  53.    This patch will be part of patch 2 for MCL 2.0.
  54.  
  55. 3) write (funcall 'coerce x 'function) instead of (coerce x 'function)
  56.    This will be slightly slower than option 2, but I doubt you'll notice.
  57.