Adam Warner <[EMAIL PROTECTED]> writes:
> This leaves us with the peculiar situation that it appears easier to
> create a global function within a function using a macro and attach a
> global property to that function than it is to directly create a global
> variable using a macro within a function.
Actually, the situation is rather similar, e.g. take the following
invocation of test using your original definitions (or, in fact, the
new ones):
(test
(defun-grab plus1 (number) (1+ number))
(write plus1)
(write (plus1 5)))
This will, e.g. in Allegro Common Lisp, exhibit a similar problem as
the variable issue, in that the compiler will warn you at compile time
that the function plus1 is undefined:
;;; Fasl write complete
Warning: While compiling these undefined functions were referenced:
PLUS1 from position 391 in defun.lisp
#p"defun.fasl"
T
NIL
Which is of course correct, in that the compiler is not required to
deduce that the function will happen to be defined at run-time, prior
to evaluation of the (plus1 5) form.
(That CMUCL doesn't emit this warning can probably be taken to be one
of the bugs that Bill Newman referred to).
The situation is only slightly more problematic for special variables,
because missing special declarations can cause the compiled code to
erroneously refer to an intervening lexical binding, or in fact create
such a binding, where a dynamic binding was intended. Since there
are no dynamic (i.e. special) bindings for functions (only lexical
bindings and the global fdefinition value), this is less problematic
for functions.
Generally, it seems to me that you might want to be working with
(local) macros, rather than with functions, BTW. E.g.:
(defmacro document (&body body)
... whatever ...
`(progn ...whatever... ,@body))
(defmacro let-environment ((name lambda-list &body body) &body body)
`(macrolet ((,name ,lambda-list ,@body)) ,@body))
(document
(let-environment (mylist (&rest items)
`(make-list ... ,@(loop for item in items
collect `(bold ,item))))
(section "foo"
(mylist
"Item1"
"Item2"))))
Of course I don't know what you are really trying to achieve, so take
this with a large lump of NaCL...
Regs, Pierre.
--
Pierre R. Mai <[EMAIL PROTECTED]> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
