On Tue, 2004-11-23 at 15:53, Raymond Toy wrote:
> I poked around a bit and found a few more case bugs. For example,
>
> make_array('hashed, 3.5);
>
> produces the error message:
>
> NON-INTEGER NUMBER OF DIMENSIONS: 3.5
>
> from (merror "non-integer number of dimensions: ~M" (car dim1)).
>
> The upcasing is caused by a call to maknam, which calls make-symbol
> without adjusting the case. There are several other calls to
> make-symbol, and quite a few more calls to intern in the code.
>
> More case bugs exist, I'm sure.
>
> We should probably try to replace all calls to intern with a new
> function so we can tell that whether we want a case-preserving or
> case-inverting intern. As it is now, I can't tell anymore whether the
> case should be preserved or not.
Ray,
It appears to me that you have spent more time looking at these details
than I have. Please tell me if the following make sense to you. (Of
course, others should feel free to chime in, also).
The primary source of confusion here is the difference between Lisp
strings and Maxima "strings." When I enter
foo:"bar";
in Maxima, the value of $FOO becomes &BAR in Lisp. When I enter
(setf $foo "bar")
in Lisp, the value of $FOO becomes "bar".
It seems to me that the consistent way to treat the case of strings is
to require that they always be appropriate for their context, i.e.,
case-preserved strings in Lisp, case-inverted strings in Maxima. By that
argument merror, which is a lisp function, would continue to take a
string argument (sstring) with unmodified case, but the line where that
string becomes part of a maxima expression,
(setq $error `((mlist) ,sstring ,@ l))
would be modified to invert the case of sstring.
How does that sound?
--Jim