From ... From: Erik Naggum Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior. Date: 2000/11/04 Message-ID: <3182371042747250@naggum.net> X-Deja-AN: 689752496 References: mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 973382249 1547 195.0.192.66 (4 Nov 2000 23:57:29 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 4 Nov 2000 23:57:29 GMT Newsgroups: comp.lang.lisp * Marco Antoniotti | I just downloaded a trial version of ACL 6.0 (waiting for the | commercial upgrade) and found out, to my dismay, that ACL 6.0 ships | in non-ANSI mode when it comes to the reader behavior. I'm intrigued to learn why that causes _your_ dismay. | This has bit me very hard for a number of reasons. Now, this is obviously silly, as you explain yourself: The readme file does explain everything you need. What bit you was that you did not read the readme file, right? Don't blame the wrong guy here. | In the file 'readme.txt' Franz explains how to generate an ANSI | 'image' from the one available. Are these instructions insufficient for any reason? Rather than build a new image, I prefer to stuff this in .clinit.cl. (excl:set-case-mode :case-insensitive-upper) (when (lep:lep-is-running) (lep::eval-in-emacs "(setq fi::lisp-case-mode :upper)")) | My understanding is that the commercial release will come with an | ANSI image available, however, the commercial version is not | distributed yet. I think the readme file explains everything you need to do in order to build the kinds of images you need. I am decidedly ambivalent on the wisdom of shipping a lower-case image, myself, but I think the painlessness of making your own image makes complaints seem silly. Please note that for whatever reason, the Windows version seems to be in ANSI "mode". This is probably because Franz feels that Unix is already so deeply entrenched in the case-sensitive lower-case world that it would be a pain to many non-old-timers to be exposed to a Common Lisp where the case behavior of symbols is "unreasonable". One of the first things I did in Allegro CL was (setq-default *print-case* :downcase), just like I had figured out how to stop CMUCL from shouting, simply because I think a computer that talks to me in upper case is very rude and smells of age like some of the things in my refrigerator that had to be shot before they attacked Xyzzy, my lovely cat, but that does not _necessarily_ mean that I think symbols should be in lower-cased and the reader case sensitive. I have come to conclude that this case thing does not matter much to me -- although it is a deeply religious issue to people I otherwise respect. What matters to me is that I can know what to expect from the environment, but if you query Allegro CL in "modern Lisp" mode, it will lie to you about what it does. That bugs _me_ a helluva lot. (5) cl-user (readtable-case *readtable*) => :upcase (6) cl-user *print-case* => :upcase At the very least, readtable-case should return :preserve, which does have ANSI-defined semantics for the other printer variables and is exactly what the reader is doing. I have complained about this internally several times and it annoys me that I'm not heard on this issue, so now I'm airing it in public. Moreover, it is impossible to make a readtable in Modern Lisp that _does_ upcase when that's what I actually want. These are bugs, not features. These are breaking the standard and ignoring my needs. If the Common Lisp community is going to accept lower-case symbols, which is the crux of the matter, it must have a graceful upgrade path, not a fork in the road like a T intersection with no way to interoperate with the other decision. I think Franz Inc is doing the Common Lisp community a service by letting them know Common Lisp can have lower-case symbols and a case sensitive reader, too, like so many other modern languages, and that programming under a standard Common Lisp system which ignores case issues is a good thing. I think Franz Inc is doing the Common Lisp community a disservice by forcing people to use the ANSI mode if they want to have only _some_ features of the standard behavior. That way, people will _not_ be able to move to a more modern Lisp if they want to, but must stay "behind". Wanting case-insensitive and/or upper-case _parts_ of a system is not evil even if some think that upper-case symbols are or that a case-insensitive reader is. If Franz Inc wants to succeed with their modern Lisp, they must not force me to ignore them if I do not accept the whole package deal. It is simply wrong to tell me that I shall never need a readtable that _does_ upcase, and it is simply wrong to _lie_ to me about the case behavior of the current readtable. Stop that. Be nice to the upper-case people, and they might follow you, in time. Offend them like you have, and they will _have_ to antagonize you just to keep what they want to keep. Not that I haven't said this before, but it is precisely because you ignore me that I have to say it over and over. Until the modern Lisp stops lying and breaking readtable-case, it should not be published. When it has been fixed to work the right way, meaning: lower-case symbols, corresponding printer variable settings, and a default readtable-case value of :preserve, it should be let out in public, again. The use of some hidden variable to control the "case-mode" is bogus all the way. #:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush