1. (defun foo () (bar)) does equivalent work to
(setf (symbol-function 'foo)
(lambda () (bar)))
plus some bookkeeping work (implementation details).
Should a macro that temporarily uses a new value for
(symbol-function 'name) be used? For instance,
(defun f (x) (1+ x))
(with-funcs ((f . (lambda (x) (1- x)))
(print (f 0)))
(print (f 0))
==> -1
1
Another way to implement this macro, assuming its
argument list is (defs &body body), is to search body
for occurances of the symbols in (mapcar #'car defs),
and replace them with FUNCALLs of the corresponding
CARs in the list (mapcar #'cdr defs)
2. Macros, among other things, can be used to extend
the language. To which extend is this true? In other
words, which set of code is the fundamental for a lisp
limplementation? Presumably this code offers all the
features lisp has which can't be implemented with
macros. These features along with anything macros
can be used for define the extensibility of the language.
Is there any material that documents the former?
Is it possible to add features to this list? Would it be
necessary to touch the implementations source?
3. I wrote this macro
(defmacro temporarily (name new-value &body body)
(with-gensyms (g)
`(let ((,g ,name))
(setf ,name ,new-value)
(unwind-protect
(progn ,@body)
(setf ,name ,g)))))
Now, if a set of functions has been designed with
*global* variables to use (probably poor terminology
to the ears of a lisper), this macro can be used to
abstract away and hide them in parameters.
If MY-CAR has been designed to return the car of *list*,
and we wished to change MY-CAR to work like CAR,
we could write:
(defun my-car2 (list) (temporarily *list* list (my-car)))
Do you think that is good style? I find it very convenient
to write code like that. I'm aware that for a large project
these function calls should be rewritten to work with
local bindings, to avoid unnecessary calls to functions
such as MY-CAR2 which set the environment and then
call the real thing, in my example MY-CAR.
(another important thing to note is that this macro would
misbehave if used by concurrently processes)
Lastly, I've tried but I'm unable to write a version that
works for multiple bindings, which would hypothetically
be used as:
(temporarily ((name1 . val1) (name2 . val2)) body-code)
Any hints/takes on this?
On 18 jun, 17:47, vippstar <········@gmail.com> wrote:
> 1. (defun foo () (bar)) does equivalent work to
> (setf (symbol-function 'foo)
> (lambda () (bar)))
> plus some bookkeeping work (implementation details).
>
> Should a macro that temporarily uses a new value for
> (symbol-function 'name) be used? For instance,
>
> (defun f (x) (1+ x))
> (with-funcs ((f . (lambda (x) (1- x)))
> (print (f 0)))
> (print (f 0))
> ==> -1
> 1
This is clearly not thread safe. If another thread invokes the
function f, things can go wrong. Try using flet / labels instead.
> Another way to implement this macro, assuming its
> argument list is (defs &body body), is to search body
> for occurances of the symbols in (mapcar #'car defs),
> and replace them with FUNCALLs of the corresponding
> CARs in the list (mapcar #'cdr defs)
This might be trickier than it sounds. It should be recursive to work,
but then there is another problem:
(with-funcs ((f (lambda (a b) 'something)))
(let ((e 1)
(f 2)) ;; <- it would try to substitute this f, creating an
error
(f e f)))
> 2. Macros, among other things, can be used to extend
> the language. To which extend is this true? In other
> words, which set of code is the fundamental for a lisp
> limplementation? Presumably this code offers all the
> features lisp has which can't be implemented with
> macros. These features along with anything macros
> can be used for define the extensibility of the language.
If I understood your question, then this "set of code" depends on the
implementation, each implementation have a distinct set of "internally
defined" functions and special operators (maybe also macros). But the
only thing that can't be made translated into a function or a macro
are the special operators (unless you use an special operator in the
macro expansion).
> Is there any material that documents the former?
> Is it possible to add features to this list? Would it be
> necessary to touch the implementations source?
>
> 3. I wrote this macro
>
> (defmacro temporarily (name new-value &body body)
> (with-gensyms (g)
> `(let ((,g ,name))
> (setf ,name ,new-value)
> (unwind-protect
> (progn ,@body)
> (setf ,name ,g)))))
What is the difference between your macro and the already existent
LET? LET already rebinds global variables, if that is what you intend
to do. Well, actually, there is a difference: yours is not thread safe
if "name" is a global variable.
> Now, if a set of functions has been designed with
> *global* variables to use (probably poor terminology
> to the ears of a lisper), this macro can be used to
> abstract away and hide them in parameters.
> If MY-CAR has been designed to return the car of *list*,
> and we wished to change MY-CAR to work like CAR,
> we could write:
>
> (defun my-car2 (list) (temporarily *list* list (my-car)))
Use LET instead, it works if you use it correctly:
(defvar *list* nil)
(defun my-car ()
(car *list*))
(defun my-car2 (list)
(let ((*list* list))
(my-car)))
CL-USER> (my-car2 '(1 2))
1
> Do you think that is good style? I find it very convenient
> to write code like that. I'm aware that for a large project
> these function calls should be rewritten to work with
> local bindings, to avoid unnecessary calls to functions
> such as MY-CAR2 which set the environment and then
> call the real thing, in my example MY-CAR.
>
> (another important thing to note is that this macro would
> misbehave if used by concurrently processes)
>
> Lastly, I've tried but I'm unable to write a version that
> works for multiple bindings, which would hypothetically
> be used as:
>
> (temporarily ((name1 . val1) (name2 . val2)) body-code)
>
> Any hints/takes on this?
On Jun 18, 4:47 pm, vippstar <········@gmail.com> wrote:
> 1. (defun foo () (bar)) does equivalent work to
> (setf (symbol-function 'foo)
> (lambda () (bar)))
> plus some bookkeeping work (implementation details).
> Should a macro that temporarily uses a new value for
> (symbol-function 'name) be used?
Probably not, unless you specifically know that you want to attach
special behavior to an existing function every time it's called
(something like TRACE, if CL didn't have TRACE already). Your Lisp
implementation may already provide a solution to this problem with
some sort of "advice" facility, and if it does, you're probably better
off using that.
> For instance,
> (defun f (x) (1+ x))
> (with-funcs ((f . (lambda (x) (1- x)))
> (print (f 0)))
> (print (f 0))
> ==> -1
> 1
> Another way to implement this macro, assuming its
> argument list is (defs &body body), is to search body
> for occurances of the symbols in (mapcar #'car defs),
> and replace them with FUNCALLs of the corresponding
> CARs in the list (mapcar #'cdr defs)
If local function definitions are what you want, just use FLET or
LABELS!
* (defun f (x) (1+ x))
F
* (flet ((f (x) (1- x)))
(print (f 0)))
-1
* (print (f 0))
1
[...]
> 3. I wrote this macro
> (defmacro temporarily (name new-value &body body)
> (with-gensyms (g)
> `(let ((,g ,name))
> (setf ,name ,new-value)
> (unwind-protect
> (progn ,@body)
> (setf ,name ,g)))))
> Now, if a set of functions has been designed with
> *global* variables to use (probably poor terminology
> to the ears of a lisper), this macro can be used to
> abstract away and hide them in parameters.
Er, you don't have to do this at all with special (i.e., dynamically
scoped) variables. This is the usual case with globals, since the only
standard way to define a global variable is to use DEFVAR or
DEFPARAMETER, like so:
* (defvar *list* '(1 2 3 4))
*LIST*
* (cdr *list*)
(2 3 4)
* (let ((*list* '(4 5 6))) (cdr *list*))
(5 6)
I'd suggest sitting down and carefully reading a decent introductory
Common Lisp book, since two of the things you're looking for are
pretty basic functionality of the language. Try /Practical Common
Lisp/:
http://www.gigamonkeys.com/book
Cheers,
Pillsy
On Jun 19, 12:30 am, Pillsy <·········@gmail.com> wrote:
> On Jun 18, 4:47 pm, vippstar <········@gmail.com> wrote:
<snip>
> > For instance,
> > (defun f (x) (1+ x))
> > (with-funcs ((f . (lambda (x) (1- x)))
> > (print (f 0)))
> > (print (f 0))
> > ==> -1
> > 1
> > Another way to implement this macro, assuming its
> > argument list is (defs &body body), is to search body
> > for occurances of the symbols in (mapcar #'car defs),
> > and replace them with FUNCALLs of the corresponding
> > CARs in the list (mapcar #'cdr defs)
>
> If local function definitions are what you want, just use FLET or
> LABELS!
>
> * (defun f (x) (1+ x))
> F
> * (flet ((f (x) (1- x)))
> (print (f 0)))
> -1
> * (print (f 0))
> 1
> [...]
FLET and LABELS create bindings in the scope they introduce. The point
of this function would be to modify the global functions, but I now
realize this is likely pointless because I can't imagine for which
problem we have the solution for. Also, TEMPORARILY can aid in
writting this macro: TEMPORARILY doesn't simply take a symbol name,
but a generalized variable (since it uses SETF on the arguments), and
thus can take (symbol-function symbol) as an argument.
>
> > 3. I wrote this macro
> > (defmacro temporarily (name new-value &body body)
> > (with-gensyms (g)
> > `(let ((,g ,name))
> > (setf ,name ,new-value)
> > (unwind-protect
> > (progn ,@body)
> > (setf ,name ,g)))))
> > Now, if a set of functions has been designed with
> > *global* variables to use (probably poor terminology
> > to the ears of a lisper), this macro can be used to
> > abstract away and hide them in parameters.
>
> Er, you don't have to do this at all with special (i.e., dynamically
> scoped) variables. This is the usual case with globals, since the only
> standard way to define a global variable is to use DEFVAR or
> DEFPARAMETER, like so:
>
> * (defvar *list* '(1 2 3 4))
> *LIST*
> * (cdr *list*)
> (2 3 4)
> * (let ((*list* '(4 5 6))) (cdr *list*))
> (5 6)
The difference is that TEMPORARILY works for any generalized variable,
it will also work for
(temporarily (gethash 'key table) 1
(print (gethash 'key table)))
LET can't do this.
On Jun 18, 6:00 pm, vippstar <········@gmail.com> wrote:
[...]
> FLET and LABELS create bindings in the scope they introduce. The point
> of this function would be to modify the global functions, but I now
> realize this is likely pointless because I can't imagine for which
> problem we have the solution for.
OK, if that is what you want to do, then this is a way of doing that
if you don't have some sort of "advice" facility in your
implementation. There may also be problems with thread-safety, though,
like gugamilare said.
In many instances, though, you're probably better off using hook
functions.
[...]
> > Er, you don't have to do this at all with special (i.e., dynamically
> > scoped) variables. This is the usual case with globals, since the only
> > standard way to define a global variable is to use DEFVAR or
> > DEFPARAMETER, like so:
> > * (defvar *list* '(1 2 3 4))
> > *LIST*
> > * (cdr *list*)
> > (2 3 4)
> > * (let ((*list* '(4 5 6))) (cdr *list*))
> > (5 6)
> The difference is that TEMPORARILY works for any generalized variable,
Not the way you've written it, since it will break on something like
this:
* (let ((array (vector 1 2 3 4)) (index 0))
(format t "~a" array)
(temporarily (aref array (incf index)) 5
(format t "~a" array))
(format t "~a" array))
vippstar <········@gmail.com> writes:
You really are making this harder on yourself than it needs to be. Most
of the functionality you are doing here already exists in lisp.
> 1. (defun foo () (bar)) does equivalent work to
> (setf (symbol-function 'foo)
> (lambda () (bar)))
> plus some bookkeeping work (implementation details).
>
> Should a macro that temporarily uses a new value for
> (symbol-function 'name) be used? For instance,
>
> (defun f (x) (1+ x))
> (with-funcs ((f . (lambda (x) (1- x)))
> (print (f 0)))
> (print (f 0))
Well, you could already just use the FLET or LABELS form to do what you
want. It would look like:
(defun f (x) (1+ x))
(flet ((f (x) (1- x)))
(f 0)) ==> -1
(f 0) ==> 1
By the way, if it's the last form, then you don't even need to invoke
PRINT, since the value of the last form will be printed anyway by Lisp's
read-eval-print loop. If you put the print in there, then you'll see
every value twice.
> ==> -1
> 1
>
> Another way to implement this macro, assuming its
> argument list is (defs &body body), is to search body
> for occurances of the symbols in (mapcar #'car defs),
> and replace them with FUNCALLs of the corresponding
> CARs in the list (mapcar #'cdr defs)
Well, you COULD do that, but you would have to be careful that you
really understand all of the binding forms in Common Lisp and also make
sure that you do proper macro-expansion of any macro forms.
In general, writing a code-walker is a pretty advanced project.
> 2. Macros, among other things, can be used to extend
> the language. To which extend is this true? In other
> words, which set of code is the fundamental for a lisp
> limplementation? Presumably this code offers all the
> features lisp has which can't be implemented with
> macros. These features along with anything macros
> can be used for define the extensibility of the language.
Well, language extension happens in a number of ways. Macros play a
part in that, mainly because they let you control evaluation, which is
often KEY for properly implementing control structures. It is also
highly useful for designing domain-specific languages.
But in general, one doesn't really need to worry about the core part of
Lisp unless you are doing a ground-up new implementation of lisp.
Instead, you just leave the Common Lisp functions as they are and
implement your additions to the language as additions, not replacements.
If you really have very extensive modifications, you would typically
then define your own package that does not :USE the COMMON-LISP package.
You then have a lot more control over what symbols are present.
> Is there any material that documents the former?
> Is it possible to add features to this list? Would it be
> necessary to touch the implementations source?
It shouldn't be necessary for you do to anything to the implementation.
That's one of the best parts of lisp extensions. It would be quite the
rare occurrence for you to have to do anything to the underlying code
base. Note that this applies to EXTENDING Common Lisp and not CHANGEING
it.
But there is a (hard-to-find?) book, "Lisp in Small Pieces" that goes
into detail about low-level implementation issues.
> 3. I wrote this macro
>
> (defmacro temporarily (name new-value &body body)
> (with-gensyms (g)
> `(let ((,g ,name))
> (setf ,name ,new-value)
> (unwind-protect
> (progn ,@body)
> (setf ,name ,g)))))
>
> Now, if a set of functions has been designed with
> *global* variables to use (probably poor terminology
> to the ears of a lisper), this macro can be used to
> abstract away and hide them in parameters.
> If MY-CAR has been designed to return the car of *list*,
> and we wished to change MY-CAR to work like CAR,
> we could write:
>
> (defun my-car2 (list) (temporarily *list* list (my-car)))
Again, this is already the normal function of LET binding of global
variables. You would just write
(defun my-car2 (list)
(let ((*list* list))
(my-car)))
and you would be done. Common Lisp already has a lot of this flexibilty
already built in.
> Do you think that is good style? I find it very convenient
> to write code like that. I'm aware that for a large project
> these function calls should be rewritten to work with
> local bindings, to avoid unnecessary calls to functions
> such as MY-CAR2 which set the environment and then
> call the real thing, in my example MY-CAR.
Well, no, I don't really approve of this style.
1. You should just use the existing structures that do what you want.
2. You really should try to use function parameters, unless the items
you are manipulating are some type of global state, or if they have
some sort of control function that crosses many levels of function
call (like the printer control variables or *standard-output* and
friends in Common Lisp)
> (another important thing to note is that this macro would
> misbehave if used by concurrently processes)
Well, there is that as well.
> Lastly, I've tried but I'm unable to write a version that
> works for multiple bindings, which would hypothetically
> be used as:
>
> (temporarily ((name1 . val1) (name2 . val2)) body-code)
>
> Any hints/takes on this?
You need to write some code that builds up the list of bindings by
iterating over the inputs. That is actually a nice macro exercise,
since it shows you you can use lisp program code to compute the
transformation of your values. In this case, it ends up being fairly
trivial, since all you are doing is taking a dotted list and
transforming it into a proper list. But it is work doing.
My choice would be to use LOOP for the job.
Also, I find it helpful when designing macros to take an example use of
the macro and then, by hand, write the code that I want to have the
macro produce. Then I work backwards toward having the macro compute
that expansion.
Since you just asked for hints, I'll leave it at that for now.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ <···@sevak.isi.edu> wrote:
+---------------
| vippstar <········@gmail.com> writes:
| > (defun my-car2 (list) (temporarily *list* list (my-car)))
|
| Again, this is already the normal function of LET binding of global
| variables. You would just write
|
| (defun my-car2 (list)
| (let ((*list* list))
| (my-car)))
|
| and you would be done. Common Lisp already has a lot of this flexibilty
| already built in.
+---------------
Even simpler: ;-}
(defun my-car2 (*list*)
(my-car))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jun 19, 11:40 am, ····@rpw3.org (Rob Warnock) wrote:
> Thomas A. Russ <····@sevak.isi.edu> wrote:
> +---------------| vippstar <········@gmail.com> writes:
>
> | > (defun my-car2 (list) (temporarily *list* list (my-car)))
> |
> | Again, this is already the normal function of LET binding of global
> | variables. You would just write
> |
> | (defun my-car2 (list)
> | (let ((*list* list))
> | (my-car)))
> |
> | and you would be done. Common Lisp already has a lot of this flexibilty
> | already built in.
> +---------------
>
> Even simpler: ;-}
>
> (defun my-car2 (*list*)
> (my-car))
More robust:
(defun my-car2 (*list* *list*)
(my-car))
thanks for all the replies I learned some things :-)
vippstar <········@gmail.com> wrote:
+---------------
| On Jun 19, 11:40�am, ····@rpw3.org (Rob Warnock) wrote:
| > Thomas A. Russ <····@sevak.isi.edu> wrote:
| > +---------------
| > | Again, this is already the normal function of LET binding of global
| > | variables. You would just write
| > | (defun my-car2 (list)
| > | (let ((*list* list))
| > | (my-car)))
| > | and you would be done.
| > +---------------
| >
| > Even simpler: ;-}
| >
| > (defun my-car2 (*list*)
| > (my-car))
|
| More robust:
| (defun my-car2 (*list* *list*)
| (my-car))
+---------------
That's not valid Common Lisp, and is therefore hardly "more robust".
You're not supposed to name the same variable twice in a lambda list.
Did you mean to write this, perhaps?
(defun my-car2 (&optional (*list* *list*))
(my-car))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jun 21, 6:13 am, ····@rpw3.org (Rob Warnock) wrote:
> vippstar <········@gmail.com> wrote:
> +---------------
> | More robust:
> | (defun my-car2 (*list* *list*)
> | (my-car))
> +---------------
>
> That's not valid Common Lisp, and is therefore hardly "more robust".
> You're not supposed to name the same variable twice in a lambda list.
>
> Did you mean to write this, perhaps?
>
> (defun my-car2 (&optional (*list* *list*))
> (my-car))
Yes, I noticed this mistake as soon as I posted the message. The
discussion is lighthearted, and you presumably know what I know, so I
decided to let this slip by.
On 2009-06-18, vippstar <········@gmail.com> wrote:
> 1. (defun foo () (bar)) does equivalent work to
> (setf (symbol-function 'foo)
> (lambda () (bar)))
> plus some bookkeeping work (implementation details).
>
> Should a macro that temporarily uses a new value for
> (symbol-function 'name) be used? For instance,
>
> (defun f (x) (1+ x))
> (with-funcs ((f . (lambda (x) (1- x)))
> (print (f 0)))
You could be looking for dynamically scoped functions, analogous to dynamic
variables.
http://p-cos.net/documents/dynfun.pdf
> (print (f 0))
> ==> -1
> 1
>
> Another way to implement this macro, assuming its
> argument list is (defs &body body), is to search body
> for occurances of the symbols in (mapcar #'car defs),
Then you're writing a code walker, doing which accurately and robustly
is non-trivial. As a rule of thumb, do not write a code walker if you
can do the job with LET, FLET, LABELS, MACROLET or SYMBOL-MACROLET.
For instance, instead of searching a form for occurences of various symbols
that are used in a variable binding context, and replacing them, generate
code which wraps the form in a SYMBOL-MACROLET.
;; BAD: replace A with (FOO) in FORM using some hacked code walker
(my-symbol-replacing-code-walker 'a '(foo) form)
;; GOOD: just wrap the form with code that sets up A as a local symbol macro:
`(symbol-macrolet ((a (foo))) ,form)
The code is still walked---by your Lisp system's macro expander!
> and replace them with FUNCALLs of the corresponding
> CARs in the list (mapcar #'cdr defs)
But that will just be static/lexical; use LABELS and FLET to make
lexical function bindings (as others have pointed out).
> 2. Macros, among other things, can be used to extend
> the language. To which extend is this true?
To the extent that you're willing to work at it, basically.
> In other
> words, which set of code is the fundamental for a lisp
> limplementation?
This depends on the implementation.
The difficulty is not in making a language within a macro, but
interoperability with the surrounding language.
Let's say you have a dialect of Lisp which has, say, no notion of a dynamic
return. It has no throw/catch, no unwind-protect. In this dialect, a form can
only terminate by a normal evaluation, returning a value. Suppose the dialect
has macros. Could you add features like unwind-protect, and throw/catch?
Of course you could use macros to make a sublanguage which has these
features. But, how well would it interoperate with the rest of the language?
For instance, could your sublanguage call a ``native'' function, then
have that native function call back into your sublanguage, and could
the callback issue a throw which would dynamically exit all the way back
to the toplevel native code?
How would that work, given that the native function has no way to terminate
except for a normal return?
> Presumably this code offers all the
> features lisp has which can't be implemented with
> macros.
It would be nice if that were so, but there are just some things
that can't be implemented with macros (in such a way that they fit
seamlessly into the surrounding language).
> These features along with anything macros
> can be used for define the extensibility of the language.
>
> Is there any material that documents the former?
> Is it possible to add features to this list? Would it be
> necessary to touch the implementations source?
>
> 3. I wrote this macro
>
> (defmacro temporarily (name new-value &body body)
> (with-gensyms (g)
> `(let ((,g ,name))
> (setf ,name ,new-value)
> (unwind-protect
> (progn ,@body)
> (setf ,name ,g)))))
This is what dynamically scoped variables do, except that in Lisp
implementations where there are threads, the local rebindings
are thread local.
Dynamically scoped variables are bound with normal binding
constructs like LET, so there is no need for TEMPORARILY.
> Now, if a set of functions has been designed with
> *global* variables to use (probably poor terminology
> to the ears of a lisper), this macro can be used to
> abstract away and hide them in parameters.
Yes; you can ``tame'' global variables with dynamic scoping.
> If MY-CAR has been designed to return the car of *list*,
> and we wished to change MY-CAR to work like CAR,
> we could write:
>
> (defun my-car2 (list) (temporarily *list* list (my-car)))
>
> Do you think that is good style?
Reinventing wheels like dynamic scope is never good style.
(defparameter *list* nil)
(defun my-car () (car *list*))
(defun my-car2 (list) (let ((*list* list)) (my-car)))
> (another important thing to note is that this macro would
> misbehave if used by concurrently processes)
But dynamic scope would not. MY-CAR2 will create a thread-local
binding of *LIST* which hides the global *LIST*.
(This is not in the language spec, but neither are threads).
> works for multiple bindings, which would hypothetically
> be used as:
>
> (temporarily ((name1 . val1) (name2 . val2)) body-code)
>
> Any hints/takes on this?
Something like:
(defmacro temporarily ((&rest var-val-pairs) &body body)
(let* ((gensyms (loop repeat (length var-val-pairs)
collecting (gensym)))
(vars (mapcar #'first var-val-pairs))
(vals (mapcar #'second var-val-pairs))
(gensym-var-pairs (mapcar #'list gensyms vars))
(var-val-interleave (mapcan #'list vars vals))
(var-gensym-interleave (mapcan #'list vars gensyms)))
`(let (,@gensym-var-pairs)
(unwind-protect
(progn
(setf ,@var-val-interleave)
(locally ,@body))
(setf ,@var-gensym-interleave)))))
I put the first setf inside the unwind-protect. Reason being:
the value forms themselves can cause a dynamic exit, and
so this must be protected. Suppose you have
(temporarily ((a 1) (b (throw 'x 42)) (c nil)) ...)
The evaluation of
(setf a 1 b (throw 'x 42) (c nil))
will clobber A, and then cause a dynamic exit to catch point X.
If this is outside of the unwind-protect, A is not restored.
I used LOCALLY so that BODY may start with declarations.
vippstar <········@gmail.com> writes:
> 1. (defun foo () (bar)) does equivalent work to
> (setf (symbol-function 'foo)
> (lambda () (bar)))
> plus some bookkeeping work (implementation details).
>
> Should a macro that temporarily uses a new value for
> (symbol-function 'name) be used? For instance,
No. You already have LABELS for that, but your version will affect
the function for other callers (unless there are compiler-macros
and/or implementation-equivalent that have rewritten them...so you
can't even be sure it'll work for any given call)
> 2. Macros, among other things, can be used to extend
> the language. To which extend is this true? In other
> words, which set of code is the fundamental for a lisp
> limplementation? Presumably this code offers all the
Look in the hyperspec for all the things listed as "special
operator".
> 3. I wrote this macro
>
> (defmacro temporarily (name new-value &body body)
> (with-gensyms (g)
> `(let ((,g ,name))
> (setf ,name ,new-value)
> (unwind-protect
> (progn ,@body)
> (setf ,name ,g)))))
>
> Now, if a set of functions has been designed with
> *global* variables to use (probably poor terminology
> to the ears of a lisper), this macro can be used to
> abstract away and hide them in parameters.
> If MY-CAR has been designed to return the car of *list*,
> and we wished to change MY-CAR to work like CAR,
> we could write:
>
> (defun my-car2 (list) (temporarily *list* list (my-car)))
This is called LET :)
> (another important thing to note is that this macro would
> misbehave if used by concurrently processes)
Yes; use LET instead.