Re: [Maxima] problem calling MAXIMA function at lisp level

RJF> I think that maxima for the future should be compatible with
unicode.

Yes, I agree wholeheartedly.

Of course, that creates many new issues.  For example, if FullSimplify
and Fullsimplify are considered to be variants of the same identifier,
how about Greek capital Alpha and Latin capital A, which are graphically
identical in the vast majority of fonts?  (Because of this, Greek
capital Alpha is never, as far as I know, used in mathematical
notation.)

Are there good input methods for mathematical uses of Unicode?

Is it the system or the user who is responsible for the canonical form
of Unicode strings?  Unicode can represent a logical character in more
than one way using combining characters or using precomposed characters.
For example, e-acute can be represented as LATIN LETTER E followed by
COMBINING ACUTE ACCENT or by the single character LATIN LETTER E WITH
ACUTE.  Does string equality compare the canonical forms of two strings
(in which case two strings can be equal without being the same length)?
or their actual physical form (in which case two strings can be unequal
though they represent the same logical characters)?

How do we define which Unicode characters are parts of legal
identifiers?  For example, Unicode's superscript numerals don't make
sense as part of a Maxima identifier.  They should presumably be parsed
as exponents or indexes or whatever.

If we want to use Unicode's Mathematical Alphanumeric Symbols, then
we'll need to support not just the Base Multilingual Plane (16 bits) but
also longer encodings.  Personally, I think the higher planes of Unicode
are a mess, are completely antithetical to the original philosophy of
Unicode, and should never have happened.  It is NOT necessarily a good
idea to use those code points.  I would prefer to use base characters
with some sort of markup or combining characters rather than deal with
these 32-bit characters.

Etc. etc.

My point is that adding Unicode to Lisp and to Maxima involves a lot of
design decisions, not just a lot of implementation.

         -s