[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue DEFINING-MACROS-NON-TOP-LEVEL, v5



   Date: Sat 31 Dec 88 19:40:52-PST
   From: Kim A. Barrett <IIM@ECLA.USC.EDU>

   Regarding the definition of top-level, a case can be made for macrolet not
   pushing you from top-level to non-top-level.  The argument is that you can take
   a macrolet form, process the body to the extent of macroexpanding everything,
   throw away the macrolet, and then process the body as a top-level progn.  When
   we (at IIM) worked out what our compiler's notion of top-level was going to be,
   my boss argued us into implementing it this way.  In general it turns out to be
   a useful way to do things.

   kab
   -------

Yes, just last week I too found MACROLET very useful at top level, for
creating a number of related top-level forms, and using a macro to
factor out repeated structure among the forms.  Here's an example:

	(macrolet ((def-forwarded-to-head (acsor head-acsor)
		      `(defun ,acsor (x) (,head-acsor (person-head x)))))
	  (def-forwarded-to-head person-nose head-nose)
	  (def-forwarded-to-head person-mouse head-mouse)
	  (def-forwarded-to-head person-eye-1 head-eye-1)
	  ...)

There's no reason to clutter up your Lisp world with a top-level
definition for DEF-FORWARDED-TO-HEAD.  On the other hand, the
function definitions (of PERSON-NOSE, etc.) seem perfectly
top-level, as if defined by:

	(defmacro def-forwarded-to-head (acsor head-acsor)
	  `(defun ,acsor (x) (,head-acsor (person-head x))))

	(def-forwarded-to-head person-nose head-nose)
	(def-forwarded-to-head person-mouse head-mouse)
	(def-forwarded-to-head person-eye-1 head-eye-1)
	...

	(setf (macro-function 'def-forwarded-to-head) nil)

But the first rendering is cleaner.  It doesn't disturb the set of
top-level macros.

				-- John