trgsmp.mac and translated files



>>>>> "Raymond" == Raymond Toy  writes:

    Raymond> rtest1.mac fails during translation because it doesn't know how to
    Raymond> translate 

    Raymond> t[0](x):=1;

On further investigation, the translation is totally messed up for
this.

If you're not interested, stop here; this is just a public record of
what I've found in case someone looks at this later.

The test in rtest1.mac is:

        t[n](x):=ratexpand(2*x*t[n-1](x)-t[n-2](x));
        t[0](x):=1;
        t[1](x):=x;


In the interpreter, the first expression creates the variable $t, with
a value of NIL.  The symbol-plist of $t is:

    (MPROPS
     (NIL AEXPR
      ((LAMBDA) ((MLIST) $N)
       ((LAMBDA) ((MLIST) $X)
        (($RATEXPAND)
         ((MPLUS)
          ((MTIMES) 2 $X ((MQAPPLY) (($T ARRAY) ((MPLUS) $N ((MMINUS) 1))) $X))
          ((MMINUS) ((MQAPPLY) (($T ARRAY) ((MPLUS) $N ((MMINUS) 2))) $X))))))
      HASHAR G2213))

So the thing after aexpr is the ratexpand expression.  This also tells
us that $t is a hashed array (hashar).  The symbol g2213 (really an
uninterned gensym) contains additional information about the array.
The symbol-plist for g2213 is:

    (ARRAY #(4 0 1 NIL NIL NIL NIL)) 

This tells us it's an array; I think the 4 means there are currently
room for 4 entries (the NILs above); the the 0 means there are
currently no entries, and the 1 means we have a 1D array.

After entering t[0](x):=1; g2213 becomes:

    (ARRAY #(4 1 1 (((0) (LAMBDA) ((MLIST) $X) 1)) NIL NIL NIL))

So, we now have 1 entry, and the first entry contains a function of 1
arg, returning 1.

After entering t[0](x):=x, we get

    (ARRAY
     #(4 2 1 (((0) (LAMBDA) ((MLIST) $X) 1)) (((1) (LAMBDA) ((MLIST) $X) $X)) NIL
       NIL))

so the second entry is a function returning x.  As we evaluate
t[2](x), t[3](x), g2213 gets filled with the various values that
maxima has computed.

The translation produces something totally different.  First there are
a few bugs where the code thinks you can funcall g2213.  The general
expression is on the plist of the symbol, but with the wrong
indicator.  The translator gets confused t[0](x) because 0 is not a
symbol.  Even if you work around these, t[0](x) isn't placed in the
symbol-plist for g2213.

This is a major mess.  Even in the interpreted code, the hashed array
implementation seems overly complex.  Perhaps we should consider a
redesign and reimplementation of hashed arrays.  Someday.

Yuck,

Ray