From ... From: Erik Naggum Subject: Re: A modest proposal (long) Date: 2000/03/03 Message-ID: <3161103283096688@naggum.no> X-Deja-AN: 592808270 References: <3160942638240195@naggum.no> <3160966858202840@naggum.no> <3161015458973462@naggum.no> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 952114517 6841 195.0.192.66 (3 Mar 2000 20:15:17 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 3 Mar 2000 20:15:17 GMT Newsgroups: comp.lang.lisp * Erann Gat | Common Lisp is case-sensitive like people expect. we might as well conclude at this time that special variables work just the way people expect, because we make a semi-conscious decision to ignore those values of "people" where "expect" returns false. _some_ people, however, do not expect the same as you do, and they might even react the same way you do to some aspect of special variables ("it's EVIL!") to some aspects of upper-case symbol names. it's _so_ amusing that you don't get this. the point being, put like a nice little riddle: those who have problems with symbol-value are also likely have problems with symbol-name. | I don't know whether this last item is part of the standard or simply a | consequence of the default read table case being :upcase. the symbols are all upper-case and Lisp has case conversion because the languages that Lisp talked to had upper-case names and case conversion, FORTRAN in particular. since symbols are first-class citizens in Lisp, and not in most other languages, we have been stuck with them in a way that other languages haven't. other languages have moved on to a much richer character set (the upper-case thing was merely an artifact of the terminal equipment and punched cards on which the code was written) and have dispensed with case conversion because it loses information that is now more readily available. | In any case, to make CL act like every other language out there we'd have | to 1) change the default readtable-case to :preserve and 2) change the | names of all the standard symbols. that's the straightforward answer, but now you're going into this "there's only one solution to this problem, and that's the one I just dreamt up, but since I didn't like the problem, I dreamt up a bad solution, so therefore the problem is also bad" mode which seems to have an incredible attraction to you. I'm explicitly trying to get you _off_ of that path. can you work with me on this, please? Allegro CL has the ability to do just what you're describing, and has had it forever because of the Franz Lisp legacy -- it was lower-case and case sensitive. today, excl:set-case-mode actually converts symbol names from upper-case to lower-case. Allegro CL is actually built with lower-case symbol names, upper-cased as a step in building the distributed version to customers. this is not a problem for Franz Inc, and not a problem for their customers. many customers also revert to lower-case mode simply because it makes a lot more sense than upper-case mode does at this time. that they don't talk about it has to do with the fact that some people get _really_ upset whenever case is brought up, but it finally dawned on me that we're _not_ talking about case, we're talking about which other languages we want to communicate with, and case issues _follow_ from that. it's not as if case is the primary factor of choice and we just happen to like FORTRAN better than C. it's that to talk to FORTRAN, you had to use the same case FORTRAN did, which were upper-case, but to talk to C, you have to use the same case C does, which is in both cases. it's a question of communication. of course, we can demand that other people talk to us, and refuse to listen to their arguments. people who do that on an habitual basis in real life, too, probably stick with upper-case in Common Lisp, as well. yet, however you wish to regard this, case-swapping is not something you do without vendor support. Allegro CL already has all the support it needs. in the case of CLISP or CMUCL, you're free to fix it yourself in any way you want that doesn't have to be "portable" at all. that leaves us with what Harlequin and Digitool would do if they were asked. | Straightforward implementation-specific hacks won't work because the | symbol name is stored in many places, not just in the symbol. so let's do non-straightforward implementation-specific hacks, then. (again, how hard can it possibly be to realize that when you have found an obvious flaw in a given _solution_, you keep looking for solutions, you don't just give up and shout the _inverse_ of "eureka!" and declare the _problem_ dead and buried.) | You could make duplicate symbols with lower-case names and copy their | value, function, and plist slots, but this would probably break | most compilers, which probably have code like (case (car form) (if ... again, I would prefer to engage the creative part of the brain, not the propaganda machine, when we encounter engineering problems. obviously, this idea is really stupid, and so it's an indirect insult to would-be proposers to assume that they haven't even thought about it. but, hey, this is also something I'm trying to get you away from resorting to. Common Lisp is often hailed as suitable for writing mini-languages. now, instead of writing a _new_ mini-language, I think it's important that we find a way for a fully conforming ANSI Common Lisp implementation to be able to handle source code in :preserve mode, written in lower-case. this is _obviously_ not a problem, since Common Lisp is good at writing mini-languages. right? right! let's see if it is possible to turn code written with :preserve and lower-case expectations into code that can be compiled without changing much anything. this should be eminently doable for the vast majority of cases. (if there be residiual problems, I hope we can avoid more propaganda machine output and instead focus on solving them or theorizing about the problems, not just sit down and wimper.) | Or you could just tell beginners not to mess with readtable-case at all | since the :upcase default generally does the Right Thing. and that's what I've been telling you to do with your "special" hacks. I'm relieved that you think this is an OK response to a silly proposal, but in this case, I'm trying to show you that my proposal, which I sort of expected you to dislike, is actually quite similar to your problem: how to get people's expectations to fit the language they use, and vice versa. you can't dismiss this _problem_, and I certainly did not dismiss it in your proposals, but you can still dismiss proposed solutions. that's why I wanted you to see the difference between bundling a problem with a solution and having it rejected and looking a problem square in the eye and determine to solve it by submitting a whole bunch of ideas for other people's rejection and perhaps that one winner. #:Erik