Re: what flet doesn't work here??

In article <4v768oF1aopabU1@xxxxxxxxxxxxxxxxxx>,
Pascal Costanza <pc@xxxxxxxxx> wrote:

Ron Garret wrote:
In article <96OdnekPAoaQSRDYnZ2dnUVZ_sOknZ2d@xxxxxxxxxxxxx>,
rpw3@xxxxxxxx (Rob Warnock) wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> wrote:
| The wonderful thing about CL is that it imposes very few constraints
| that cannot be dispensed with in a few lines of code:
| (defmacro ddefun (fname args &body body) ...)

Yes, but as I pointed out upthread, that only works if you use
DDEFUN to define *all* the functions you want to be able to later
use DFLET with. I got the impression the OP wanted to be able to
override functions already defined by other code [though I could
be mistaken], which your certainly nice macros can't help with.
[AFAIK, nothing can, in general.]


(defmacro dflet (bindings &body body)
(loop for (fname . ignore) in bindings do
(unless (member fname *dynamically-bound-functions*)
(push fname *dynamically-bound-functions*)
(eval `(progn
(defvar ,fname)
(setf ,fname ,(and (fboundp fname) `#',fname))
(defun ,fname (&rest args) (apply ,fname args))))))
`(let ,(mapcar (lambda (b) `(,(car b) (lambda ,(second b) ,@(cddr b))))

That's a neat hack at best. Rob talked about functions by other code.
You shouldn't mess around with other code like that because you don't
know what they do with these functions internally. (For example, the
other code could use side effects on function cells as well, and then
you will definitely get into trouble.)

The requirements as given required this kind of a hack. You're saying
that dynamically binding functions that have been defined in the normal
way is a bad idea. I do not disagree. But Rob claimed it couldn't be
done, and that's not true.

And more specifically, you are definitely not allowed to change
functions like that which are predefined by ANSI CL.

Yes, figuring out how to make dflet (appear to) work for CL built-ins is
left as an exercise.