home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / 3197 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  1.6 KB
  1. Path: sparky!uunet!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: macro question
  5. Date: 7 Jan 1993 17:56:01 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 23
  8. Message-ID: <1ihqrhINNg65@early-bird.think.com>
  9. References: <CONVERSE.93Jan5225205@sloth.uchicago.edu> <DAVIS.93Jan6102702@passy.ilog.fr> <CONVERSE.93Jan7001530@sloth.uchicago.edu>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <CONVERSE.93Jan7001530@sloth.uchicago.edu> converse@cs.uchicago.edu (timoshenko) writes:
  13. >    Sure, you're right that DEFCLASS and DEFSTRUCT and the like
  14. >have the useful side-effect of defining new functions, but those have
  15. >the advantage that they are part of the language already.
  16.  
  17. Once upon a time they weren't part of the language.  If programmers had
  18. avoided writing macros that define new functions, they never would have
  19. been written, and then they never would have become popular enough to be
  20. included in the standard language.  Lisp's powerful macro capability is
  21. what has enabled it to evolve so well over the years; new definition and
  22. control structures can be added as easily as procedures can.
  23.  
  24. Function-defining macros are a well-known, useful technique for procedural
  25. abstraction.  It allows you to write a single macro that incorporates the
  26. structural elements common to a class of functions that should be defined;
  27. the macro in the original post was obviously contrived and didn't
  28. demonstrate this utility.
  29.  
  30. -- 
  31. Barry Margolin
  32. System Manager, Thinking Machines Corp.
  33.  
  34. barmar@think.com          {uunet,harvard}!think!barmar
  35.