[Bese-devel] Re: compile-op error on backtracking.lisp
Nikodemus Siivola
nikodemus at random-state.net
Fri Jun 16 10:39:27 UTC 2006
Marco Baringer <mb at bese.it> writes:
> (defaction foo ((a bar))
> ...)
>
> which is expanded into:
>
> (defmethod foo ((a bar))
> (with-call/cc ...))
>
> when sbcl compiles that defmethod form it will macro expand the body
> twice, the first time around the lexical environment (the &environment
> object passed to macros) will be NIL and with-call/cc won't see the
> binding of A, the second time around a complete environment object is
> passed and the code works (in fact the generated compiled code is
> correct since sbcl throws away with-call/cc's expansion on that first
> expansion) . what happens on that first expansion is that with-call/cc
> signals a warning, asdf, on sbcl, treats this a compile _error_ and
> breaks.
>
> anybody with sbcl skilz able to suggest a solution?
The first expansion comes from the PCL code walker that is responsible
for all sorts of CLOS magic, and the second expansion comes from the
actual compiler.
As first approximation, I'd suggest STYLE-WARNING instead, or
MUFFLE-WARNING to deal with the rogue warnings, or alternatively
ASDF:*COMPILE-FILE-FAILURE-BEHAVIOUR* to make ASDF not grind to halt
if COMPILE-FILE returns a tertiary value of true.
As for actual solutions... well, obviously it would be good if the
code-walker provided environments isometric similar to the ones
generated by the compiler.
Question: what kind of queries do you perform on the environment, and
how? Do you dip into the internals, or do you use eg. SB-CLTL2?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
More information about the bese-devel
mailing list