I am trying to do something which ought to be relatively simple but turns
out to be pretty horrible. I am working on a program in which there is a
particular function that gets called over and over again. There are two
different versions of this function, one which compiles quickly but runs
slowly, and one which compiles slowly but runs quickly. When the program
is first loaded you get the slow-running version. In order to get the
fast-running version you have to load a compiler that lives in a different
package, and then recompile the function using a macro that lives in that
other package.
I would like to automate the process of installing the fast-running version
of this function, i.e. I would like to make a macro that looks something
like:
(defmacro install-fast-running-version ()
`(progn
(load-hairy-compiling-functions)
(use-package :hairy-compiler)
(define-using-hairy-compiler the-often-used-function ...
The problem is that when you try to run this macro it bombs when it gets
to the use-package, because the symbol "define-using-hairy-compiler" is
already interned in the current package. (It got interned when
install-fast-
running-version was evaluated.)
I can think of at least two different ways of getting around this, but they
are both pretty awful. The first is to do the following:
(use-package :hairy-compiler)
(eval (read-from-string "(define-using-hairy-compiler... " ))
The second is to set up the hairy-compiler package ahead of time whether or
not the hairy compiler is ever loaded.
Can anyone think of a less hideous way of accomplishing this?
Thanks,
E.
--
Erann Gat
···@robotics.jpl.nasa.gov
Erann Gat <···@robotics.jpl.nasa.gov> wrote:
>I would like to automate the process of installing the fast-running
>version of this function, i.e. I would like to make a macro that
>looks something like:
>
>(defmacro install-fast-running-version ()
> `(progn
> (load-hairy-compiling-functions)
> (use-package :hairy-compiler)
> (define-using-hairy-compiler the-often-used-function ...
>
>The problem is that when you try to run this macro it bombs when it
>gets to the use-package, because the symbol
>"define-using-hairy-compiler" is already interned in the current
>package.
Messing with the package structure at run-time is usually just asking
for trouble: The effects are non-local, and it is v.v. tricky to make
sure you wind up in a state you want to be in. (For example, are you
sure the current value of *PACKAGE* is a good one?)
Personally, I would just define the hairy compiler package ahead of
time and lose the USE-PACKAGE call. While I'm at it (absent other
constraints you haven't mentioned), I'd define the installer as a
function instead of a macro and use a programatic (opp. macromatic)
interface to the hairy compiler:
(defun install-fast-running-version ()
(ensure-hairy-compiling-functions-loaded)
(hairy-compiler:define-using-hairy-compiler-1 'the-often-used-function))
If you just have to fiddle with the package structure, I'd do:
(defmacro install-fast-running-version ()
`(progn
(load-hairy-compiling-functions)
(use-package "HAIRY-COMPILER" "MY-PACKAGE")
(eval `(,(find-symbol "DEFINE-USING-HAIRY-COMPILER"
"HAIRY-COMPILER")
,the-often-used-function ...))))
Note the convention of using upcase strings to refer to symbol and
package names in order to avoid consing symbols in the keyword package
and to avoid problems with *READTABLE-CASE*.
--David Gadbois
In article <················@silicon.jpl.nasa.gov>, ···@robotics.jpl.nasa.gov (Erann Gat) writes:
...
|> I would like to automate the process of installing the fast-running version
|> of this function, i.e. I would like to make a macro that looks something
|> like:
|>
|> (defmacro install-fast-running-version ()
|> `(progn
|> (load-hairy-compiling-functions)
|> (use-package :hairy-compiler)
|> (define-using-hairy-compiler the-often-used-function ...
|>
|> The problem is that when you try to run this macro it bombs when it gets
|> to the use-package, because the symbol "define-using-hairy-compiler" is
|> already interned in the current package. (It got interned when
|> install-fast-
|> running-version was evaluated.)
No! It got interned when install-fast-running-version was *read*.
Somebody suggested using INTERN. That's what I'd do.
-- Drew McDermott