I am looking for a 'standard' solution to the following problem:
I have a package called "MY-PACKAGE" in which I redefine the function *
(multiply).
When I import it into the "USER" package it works fine except for one
detail: the variable * which stores the last eval'ed result is lost.
The solution I have is to write:
(defun new-* (args) (...))
(setf (symbol-function '*) (symbol-function '*-new))
This works fine: it redefines the function * (when imported shadowing
into "USER") and also preserves the variable *.
I was just wondering whether there is a standard solution (i.e. using
define-package or other similar function) for importing symbols,
preserving the symbol-value but not the symbol-function or viceversa.
Thanks.
In article <·············@wrq.com> marisal <·······@wrq.com> writes:
> I am looking for a 'standard' solution to the following problem:
> I have a package called "MY-PACKAGE" in which I redefine the function *
> (multiply).
> When I import it into the "USER" package it works fine except for one
> detail: the variable * which stores the last eval'ed result is lost.
> The solution I have is to write:
There is no real solution to this problem, standard or not.
The reason is that packages manage the mapping between names and
symbols, and it is symbols that have both value and function cells.
That means you can't just get the symbol-function to shadow and not also
have symbol-value shadow.
> (defun new-* (args) (...))
> (setf (symbol-function '*) (symbol-function '*-new))
>
> This works fine: it redefines the function * (when imported shadowing
> into "USER") and also preserves the variable *.
It's not completely clear what you are doing here other than redefining
the function cl:* to be your new function. Neither of those lisp forms
have anything to do with shadowing import. The question that remains is
what happened to the function definition of cl:* ? It would seem that
you have lost it.
About the best you could hope to do would be save the existing value of
cl:*
(setf (symbol-function 'old-*) (symbol-function 'cl:*))
and then redefine cl:*
(defun cl:* (...) ...)
in such a way that anyone else's code that uses multiplication doesn't
break.
> I was just wondering whether there is a standard solution (i.e. using
> define-package or other similar function) for importing symbols,
In this case, the best answer would probably be not to import the symbol
at all and just use a package-qualified multiplication operator for your
specialized multiplication routines.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <·············@wrq.com>, marisal <·······@wrq.com> wrote:
>I have a package called "MY-PACKAGE" in which I redefine the function *
>(multiply).
>When I import it into the "USER" package it works fine except for one
>detail: the variable * which stores the last eval'ed result is lost.
No it isn't. You can still refer to it as COMMON-LISP:*.
>The solution I have is to write:
>
>(defun new-* (args) (...))
>(setf (symbol-function '*) (symbol-function '*-new))
>
>This works fine: it redefines the function * (when imported shadowing
>into "USER") and also preserves the variable *.
This is invalid. You're not allowed to redefine functions that are in the
COMMON-LISP package. This is because the implementation may depend on
these functions having their normal definition.
Furthermore, your change occurs at run time. At compile time, the compiler
will probably assume that * is bound to its usual definition, and will open
code calls to it, so you won't get your modified definition.
>I was just wondering whether there is a standard solution (i.e. using
>define-package or other similar function) for importing symbols,
>preserving the symbol-value but not the symbol-function or viceversa.
No. This is an unfortunate consequence of Common Lisp's package system --
it applies to symbols rather than bindings. The problems only occur when
the same symbol is used in multiple namespaces; the only standard symbols
that are like this are *, +, /, and -, an unfortunate historical anomaly.
--
Barry Margolin, ······@bbnplanet.com
BBN Corporation, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>