Re: Case-sensitivity goals, policy and implementation



ole> I think it is good advise to let the Lisp Reader do just that
ole> (Read Lisp) - use a parser for anything else. If the
ole> macsyma/maxima developers for 30 years have resisted the
ole> temptation to call READ, I don't think this is the time to give
ole> in.

Ray> Almost all of the code was uppercase, and surely was uppercase 30
Ray> years ago.  Now is not the time to give in and make it lower
Ray> case!  Most of the code was written in a, uh, very eclectic
Ray> style.  Now is not the time to change style!  Maxima always
Ray> uppercased everything on input (until about 3 years ago).  Now is
Ray> not the time to make maxima case-sensitive defaulting to
Ray> lowercase!

I hope I wasn't argumenting against change as such, though your reply
seems to indicate that's how I came across:-) The point I'm trying to
make is that the Lisp Reader exists to Read Lisp.

Ray> And in this case we're not using the reader to parse anything.
Ray> It is only be used to do the desired case conversion.

You'll work hard to make it do *only* case conversion, cf character
syntax, macro characters, *PRINT-EVAL*.

ole> Secondly, by the time you've set up the readtable (with casing, macro
ole> characters and character syntax), and bound *PACKAGE*, *READ-EVAL* and
ole> friends, the effort by far exceeds writing simply:
ole> (...)

Ray> Surely you saw the patch I sent.  It certainly was less typing
Ray> than what you propose here,

If you count the lines needed to set up and switch readtables,
the difference is not that obvious:-) 

And you still mutate the system's readtable, and make no effort at
handling unusal input gracefully. Try maxima "load" on a lisp file
with UPPERCASE sourcecode, I'd expect that to work with an ANSI lisp
image.  Or try entering "test\:test" at the maxima prompt. And what
about "print\#\.\(ext\:quit\)"? Too exotic? Not if you're running a
web-based maxima service.

Ray> and all the other changes would be required whether you use
Ray> readtable-case or not.

Ray> And this only solves the input side.  You still have to solve the
Ray> output side, with a similar and equally simple function.  

True. Twice.

Ray> However, I think the correct approach is to have a function handle the
Ray> conversion and use it everywhere.  Then the function can do whatever
Ray> it feels like. (...)

I agree that it can do it in whatever *way* it feels like,
READ-FROM-STRING or otherways. But from a maxima-is-a-lisp-library
POV, it should not mutate the system's readtable, nor should it (SETQ
*READTABLE* ...) nor any other reader/printer special variables. If it
needs to dynamically bind *READTABLE* & al, the span should be as
short as possible.

Regards, Ole