Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!usc!ucla-cs!srt
From: srt@maui.cs.ucla.edu (Scott Turner)
Newsgroups: comp.lang.lisp
Subject: Summary of Macro Question
Message-ID: <31623@shemp.CS.UCLA.EDU>
Date: 7 Feb 90 17:47:15 GMT
Sender: news@CS.UCLA.EDU
Reply-To: srt@maui.cs.ucla.edu (Scott Turner)
Distribution: usa
Organization: UCLA Computer Science Department
Lines: 83

In an earlier article, I posted a question about defining macros in Common
Lisp.  I wanted to define a macro which would allow the user to type in a
form like:

	(rule:define rule-name
		(test (list? *spec*))
		(body (car *spec*)))

Where "*spec*" would be a parameter passed into the lambda wrapped around
test and body, i.e., test would expand into something like:

	(lambda (*spec*) (list? *spec*))

A problem arises in that the expansion actually looks something like this:

	(lambda (rule::*spec*) (list? *spec*))

This arises from the fact that the defmacro is evaluated in one
environment and expanded in another.  I showed the way I hacked around
this (by delaying the evaluation of the parameter using intern) and
asked if there was a better way to deal with this.

One suggestion, made by Barry, Daniel Haug, and Joe Weening was to have
the user import rule::*spec* into the current package.  That's an appealing
solution because it can be (I believe) incorporated into the macro, i.e., 

	(defmacro rule::define (...)
	  `(progn
		(import 'rule::*spec*)
		... ))

This seems to work, and has the advantage of relieving the user of having 
to deal with such things.  (Which of course is the whole point of the macro.)

Similarly, several people suggested making the user type out "rule::*spec*"
but I don't consider that an acceptable interface.

Elliot and Barry also suggested changing the syntax of the macro to allow 
the user to specify his own parameters, i.e., 

	(rule::defrule big-rule (x)
	  (:test   (eql x 'foo))
	  (:action (cons x 'foo)))

As an interface this has some problems.  The rule is to be applied later to 
a fixed set of arguments, and it's confusing to the user to have to specify
something that's going to be fixed anyway.  But it is a solution that might
be useful in other circumstances.

Lou Steinberg pointed out some problems with my suggested solution using 
intern, for which I was grateful.

Finally, Jamie Zawinski had some rather dire advice:

	Don't try to circumvent the namespace hierarchy like this; you
	*will* lose, eventually...

	If you don't feel like you fully understand the package
	system, don't use it.  Put all of your code in one package
	until you do.

Which is probably good advice, though I wonder how one is to learn about the 
package system without trying out things.

Jamie also said:

	I think one of the biggest flaws with the Common Lisp package
	system is that it is confusing.  In fact, it is so confusing,
	that sometimes people get the notion that evil hacks like the
	above are "right" or "clean."

with which I can only agree.  I'm not an inexperienced programmer, in
Lisp or other languages, and I find packages in CL to be confusing and
non-intuitive.  On an abstract intellectual level I both understand
and appreciate the package idea, but on a usage level I constantly
find myself stumbling and mystified.  But I'm a comparative novice at 
CL so perhaps that's to be expected.

Thanks to everyone for the input and reccomendations.
 
    Scott R. Turner
    UCLA Computer Science     "Help Me Please!"
    Domain: srt@cs.ucla.edu