Re: do-nothing macro generates nil nevertheless

[vogt@netcom.com (Christopher J. Vogt)]

In article <3iqno7$mab@news.internex.net>,
Dave Yost <yost@rclsgi.eng.ohio-state.edu> wrote:
>Point 1:
>
>I've been implementing some debug macros that only
>generate code depending on what's in *features*.  If
>the appropriate features are not enabled, I want my
>macros to have no effect.  As if they weren't there.
>This seems not to be possible.
>
>Consider this macro:
>
>  (defmacro mac1 () nil)
>
>Now consider this form:
>
>  (progn
>    3
>    (mac1))
>
>which returns nil.  (in MCL and CMU-CL)
>This seems to me to be a misfeature.
>
>A macro's job is to return a list to be compiled.

Try (listp nil).  It returns T, nil is a list.
Try (length nil).  It returns 0, nil is a list of length 0.
Try (values).  it doesn't return anything!  And I'll bet you
thought that everything in lisp returns a value.  Hah!

I am confident that you can achieve what you want,
but it is unclear to me what you want the above macro
to do.  Maybe the info above will be of help.  Otherwise
if you are more explicit I can help.

>If it returns nil, I would have thought that would mean
>that nothing should be compiled.  That would be useful.
>If you need a macro to compile in the constant nil, you
>can have it return 'nil.
>
>  (defmacro mac2 () 'nil)
>
>  (progn
>    3
>    (mac2))
>
>returns nil in MCL and CMU-CL.
>
>
>Point 2:
>
>While we're on the subject of debug printouts,
>it would be nice if there were a way one could insert
>a form after the last expression of a progn and have
>it be transparent with respect to what the progn
>returns.  Over-simplified example:
>
>  (implicit-progn
>     ...
>     3
>     (debug-print "ahah!")
>     )
>
>You'd like the return value to be 3, as if you'd done this
>
>  (implicit-progn
>     ...
>     (multiple-value-prog1
>       3
>       (debug-print "ahah!"))
>     )
>
>which is even more invasive.  For debug forms like this
>it would be nicer if they were defined to be usable
>anywhere without worry as to their effect on return values.

Try tracing the function, and if the progn isn't a function,
make it one and then trace it, ie (trace foo), it might do
what you want, then again it might not.

>This would require some sort of primitive like
>
>  (return-value-transparent &body body)
>
>which would leave the current return values undisturbed.
>This primitive could stand on its own, or it could be
>implemented using an even more useful primitive:
>
>  (with-captured-return-values (var) &body body)
>
>which could be useful in a macro that would expand thus:
>
>  (implicit-progn
>     ...
>     3
>     (with-captured-return-values (var)
>       (debug-print "You're about to return ~S" var)
>       (values-list var))
>     )
>
>Has this been done before?
>
>Isn't lisp great?

yes.

>Dave Yost
>    @    .com


-- 
Christopher J. Vogt vogt@netcom.com
From: El Eh, CA
-- 
Christopher J. Vogt vogt@netcom.com
From: El Eh, CA