> > There is a similar bug in my Table implementation, that comes
> > from allowing Table to work with "apply".
>
> What do you mean by allowing it to work with apply?
I really meant a specific way of using apply.
The line in my Table code is the one that looks like the following.
At this point 'l' should be a list of one or more iterators, where
an iterator is something like [i,1,10].
Version I:
(setq iter (meval* (first l))) ; meval* to
; allow >>> apply(lambda([x], Table(i,x)), [ [i,4]]);
This allows me to reproduce this example from the documentation
Table[i-j, ##]& @@ {{i,4},{j,5}}
with this
Example A:
apply(lambda([x,y], Table((i - j), x,y)), [ [i,4], [j,5] ] );
If instead of Version I, I use
Version II:
(setq iter (first l));
Then I get this error:
apply(lambda([x,y], Table((i - j), x,y)), [ [i,4], [j,5] ] );
argument 'X' does not have the correct form for an iterator
But, the disadvantage of Version I is that I get this:
Example B:
a:1$
Table(a,[a,1,2]);
Maxima encountered a Lisp error:
Error in PROGV [or a callee]: 1 is not of type SYMBOL.
Version II avoids this problem. So you see that Version I and
Version II each fail for exactly one of examples A or B.
I actually found a solution, which seems a little kludgy,
but controls evaluation better.
Version III
(setq iter (first l))
(cond ( (not (listp iter)) (setq iter (meval* iter))))
This works in both examples A and B because an iterator specification
always must be a list. So if its not, evaluate iter and
hope the result is a list (or you could check again and
give an error if its not a list)
--John