[Axiom-developer] Re: defintrf.spad compiler bug

[Stephen Wilson]

Tim,

A further update:

My initial experiment appears to work, but it may not be the proper
fix (build still pending, at layer 20 ATM).

This is my analysis thus far.  I belive I have come to a decent theory
as to how this issue can be solved.  Please bear with me as I try to
explain.

In buildom.boot, mkUnionFunList, we have:

             cdownFun() ==
               gg:=GENSYM()
               if p is ['EQCAR,x,n] then
                  ref:=['QCDR,gg]
                  q:= ['QEQCAR, gg, n]
               else
                  ref:=gg
                  q:= substitute(gg,"#1",p)
               ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],ref,
                    ['check_-union,q,t,gg]]]


In particular note the variable t.  It is bound to an element of
listOfEntries, which represents the various types of branches in a
Union.

Note that in check-union (macros.lisp), the second argument is used
for error message only (expands into a call to coerce-failure-msg,
again macros.lisp).

Now, t is a sexp denoting a type.  All types I have encountered are
usually self-evaluating within a proper context.  In particular,
(|Record| (|:| |x| (|AType|))) is a macro which expands into
(|Record0| (LIST (CONS (QUOTE |x|) (|AType|)))).  Note well that the
label is quoted here.

OK.  When processing an anonymous function like
keeprec?(i.halfinf.endpoint, #1) in defintrf.spad, we end up
processing a partially the compiled expression which includes the
check-type forms built by mkUnionFunList above.  This processing
happens mainly in compWithMappingMode (compiler.boot).  The goal in
that function is to lambda-lift the anonymous function into a
top-level DEFUN.  To do this this free variables are identified and
lifted into a formal parameter represented as a vector.

My initial thought was to augment the lifting of the free variables by
checking if they are bound.

Now I am considering an explicit call to MACROEXPAND in the
mkUnionFunList code, as in:

          ['check_-union,q, MACROEXPAND t,gg]

This appears to be the proper fix, but it will take another build
cycle to verify and check.  It is a fix because after macroexpansion,
record labels are explicitly quoted -- quoted forms are not considered
candidates by compWithMappingMode as free variables.


Sorry if this rant is not clear.  I can try to answer any questions.


Thanks,
Steve