Re: Case-sensitivity goals, policy and implementation

>>>>> "ole" == ole rohne <ole.rohne@cern.ch> writes:

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

Point taken.

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

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

Well, I think you still have a lot of work to do, no matter what
method is used.  

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

I wasn't modifying the default readtable.  The modified readtable was
only supposed to be used in the maxima repl.  It's very likely I
screwed up.

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

That was the intent of what I had done.  The execution may not have
been right, though.

It also seems that the patch I sent has incomplete, because when I
apply it to a clean checkout, maxima doesn't work at all anymore with
cmucl.  clisp is ok.  I have no idea what's wrong. :-(

But I think your solution is a good one and we don't have to worry
about gcl at all, which might be the best reason of all.

Ray