This may have been done by the GCL developers _precisely to make Maxima run!_ They were probably not in a good position to fix Maxima itself, so they "fixed" Lisp instead.
I recall making Maxima work in an early Common Lisp (KCL) & running into all kinds of strange behavior that it would have taken months to track down; it was just easier to allow the Common Lisp to look a little more like Maclisp.
At 04:25 PM 8/24/2011, Robert Dodier wrote:
>GCL returns NIL for list operations on non-lists instead of
>triggering an error. That may be controlled by the compiler safety setting or
>something like that. Anyway, I get the error for versions of
>Maxima from 5.10 through the present with Lisp varieties other than GCL.
>
>About the T argument, I just copied what I saw in a trace.
>I will try it again with NIL.
>
>best, Robert Dodier
>
>On 8/24/11, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>> This doesn't cause a problem in Maxima 5.23.2 GCL 2.6.8. What version are
>> you running? I wonder what has changed between the versions.
>>
>> I suspect that the problem in your example below is that you are calling
>> (simplus x 1 t) and not (simplus x 1 nil). When the third arg to simplus is
>> T, it means that all the arguments of mplus have already been simplified,
>> which is not the case here. Given that the precondition is violated, I
>> wouldn't be surprised that great was called on something it shouldn't be
>> called on.
>>
>> -s
>>
>> On Tue, Aug 23, 2011 at 01:30, Robert Dodier <robert.dodier at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I've found that this Lisp program:
>>>
>>> (defparameter x '((mplus) ((foo) ((mrat simp ($c) (#:c1635)) (#:c1635
>>> 1 -1) . 1) $a)
>>> ((foo) ((mrat simp nil nil) 1 . 1) ((mtimes simp) $a $b))))
>>> (simplus x 1 t)
>>>
>>> triggers an error: CAR: #:C1635 is not a list
>>>
>>> I see that GREAT uses MARGS to decompose the MRAT expressions,
>>> which leads to the error because MARGS is naive, it just returns
>>> the CDR of the expression.
>>>
>>> How should GREAT and/or MARGS handle MRAT?
>>> The simplest thing to do is to reformat the arguments of GREAT
>>> but I suspect that's too expensive.
>>>
>>> I guess that whatever we come up with should be applied to
>>> other expressions with special representations.
>>>
>>> Thanks for any light you can shed on this.
>>>
>>> Robert Dodier
>>>
>>> PS. I discovered the error like this:
>>>
>>> load (ezunits);
>>> x : (rat(1) ` a) * (1 ` b + c);
>>> expand (x);
>>> => "not a list" error
>>>
>>> When the error is triggered, * has been distributed over +
>>> and SIMPLUS is sorting the arguments, hence the call to GREAT.