Kaz Kylheku
2/29/2016 4:01:00 PM
On 2016-02-29, Jim Newton <jimka.issy@gmail.com> wrote:
> Can I use the :around-compile feature of asdf to work around this limitation of compile-file?
>
> I have a deftype in my program which has a side effect, for example
>
> (deftype rte (pattern)
> `(and sequence
> (satisfies ,(calc-match-function pattern))))
>
> The call to calc-match-function returns a dependably named symbol which has thus
> had its symbol-function set to a generated and compiled function. The code for the
> function is created as a function of the pattern, and the resulting lambda expression has
> been passed to eval to create a function object. If calc-match-function is called a second
> time with the same pattern, it simply returns the calculated name, but doesn't re-generate nor
> re-comiple the function.
>
> This works fine if the code is loaded from source, but not if loaded from fasl. Why,
> because the derived function exists in the lisp where the function is compiled, but not necessarily
> in the lisp which loads the fasl.
Common Lisp provides a compile-and-load friendly mechanism for
calculating a value once and then returning the calculated value.
Look at LOAD-TIME-VALUE.
LOAD-TIME-VALUE can calculate objects which are not externalizable
in the compiled format. This is because the construction of these
objects is triggered at load time.
If you absolutely must calculate this value at compile time, because
(for instance) it depends on some data in the build environment, then
LOAD-TIME-VALUE won't work. It's possible that some of the inputs could
be split? Identify the minimum that you need from compile time, and
encode that in your object file as simple types that are externalizable.
Then use LOAD-TIME-VALUE to construct the non-externalizable object
(function or whatever) out of those compile-time-captured pieces.