Case-sensitivity goals, policy and implementation

Stavros,

You ask many good questions. Let me add one thing from the outset: The
capitalized function names exist to make maxima functions simply
accessible from Lisp. I think their use in maxima language code should
be officially discouraged.

On Sun, 2004-10-10 at 13:58, Stavros Macrakis wrote:
> If we define both "sin" and "SIN", then the user has to know which
> functions are built-in and which aren't.  

It is probably a good idea to make that information available in some
way.  Vadim has already suggested we do so.

> What about functions defined
> in Share, either in Maxima language or Lisp?  

Good question. I think packages distributed with Maxima should maintain
the same upper/lower duality.

> What about packages
> distributed by people outside the official distribution (as NSET used
> to be, for example)?

Hmm.  I can see where it becomes difficult to define the cutoff. One
possibility would be to say that packages that are distributed should
use the upper/lower case system.

>   What about built-in constants like %PI, INF,
> etc.?  Is the function "GAMMA" the same as the function "gamma", but
> the constant "%GAMMA" different from the constant "%gamma"?

The proposal was to maintain upper and lower-case version of functions
only. There is a simple reason I don't want to extend upper/lower
versions to variables: I don't see a simple implementation strategy. For
functions we have (setf (symbol-function ..)). I don't know an analogous
way to maintain two names for variables. The only way I can think would
involve maintaing private copies of setf, setq, defparameter... It seems
that way lies madness.

Constants, on the other hand, could be given two different names. Since
they don't change, we wouldn't have to worry about maintaining equality.
My inclination, however, is to keep strict case sensitivity for
constants.

> What happens when a user redefines a built-in function?  That is
> perfectly legal (though it does give a warning), and occasionally it
> is even useful.  The proposed implementation would redefine the
> function for one spelling and leave the built-in definition for the
> other.  Yuck.

Actually, the proposed implementation wasn't detailed enough to specify
the behavior when built-in functions are redefined.  I would like to
amend the proposal to specify that redefinitions should affect both
function definitions.

> I agree that writing |$integrate| all over the place would be a pain,
> but surely we can find a solution that doesn't require clumsy
> programming, but also gives the user a simple, consistent experience.

I have presented the best idea I have had so far. I would love to see
another proposal.

--Jim