Gabriel Dos Reis wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> | CY wrote:
> | > Confirmed - builds on sbcl and clisp. Wow! Thanks Waldek!
> | >
> | > I don't know if it's important, but I am getting a lisp readout when
> | > using the integration package:
> | >
> | > (2) -> integrate(sin(x),x)
> | > [loading messages]
> | > /home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i686-pc-
> | > linux/algebra/COMPLEX.fasl
> | > for domain Complex
> | >
> | >
> | > ; in: LAMBDA NIL
> | > ; (VMLISP:QCAR BOOT::|#1|)
> | > ; --> CAR
> | > ; ==>
> | > ; (THE CONS BOOT::|#1|)
> | > ;
> | > ; caught WARNING:
> | > ; undefined variable: |#1|
> | >
> |
> | AFAICS this comes because Axiom uses eval and sbcl by default
> | compiles all evals. I am investigating whether the warning
> | indicate some real problem. One can silence warning switching
> | to interpreted eval (which will be done for different reasons
> | in next revision):
>
> There is a questionable habit in the Axiom core source code of
> defining variables through SETQ -- that tends to trigger warnings
> from several Lisp implementations. Is it possible that the above
> is such a warning? (the |#1| are names for synthetized lambdas).
>
The problem is more subtle: the code above (printed by sbcl)
references |#1|. Apparently sbcl complier does not see that
|#1| is defined, but it is.
In more detail, Axiom uses Lisp eval to replace |#1| by aproproate
value. Relevant part of backtrace is:
17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EQCAR |#1| 0) #<NULL-LEXENV>)
18: (|evalSharpOne|
(EQCAR |#1| 0)
(0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
19: (|coerceUnion2Branch|
((|Union| (|Expression| (|Integer|)) (|List| (|Expression| (|Integer|))))
WRAPPED 0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
|evalSharpOne| is defined as:
(defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))
so at the time of eval |#1| has special binding. My understanding is
that such bindings are visible to eval. The '#<NULL-LEXENV>' part
made me suspicious, but testing indicate that in sbcl code works
as expected.
--
Waldek Hebisch
[EMAIL PROTECTED]
_______________________________________________
Axiom-developer mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/axiom-developer
