Subject: Re: [not so] basic package question From: Erik Naggum <erik@naggum.net> Date: Fri, 26 Apr 2002 00:40:44 GMT Newsgroups: comp.lang.lisp Message-ID: <3228770443870854@naggum.net> * Duane Rettig | The documents we write about such case-portability are designed to show | a programmer how to write in a style that will work in both implementations. But standard, conforming code no longer works when you use the standard symbol-names in strings that are used to name symbols. Code that does a fraction of what the reader does, but which upcases the string in order to conform to the standard, will fail miserably. Protocols that specify uppercase names and use that directly to map to symbols will not work if the symbols are used in the program. This is wrong. This is bad. This has nothing to do with how you represent or deal with the symbol-names of symbols internal to the program. It has everything to do with how you treat _external_ input. Not being able to implement your _own_ reader because the implementation uses stealth case switching is fantastically hostile and exposes a decision that should be tacit and invisible to full view and discussion, like we have here periodically. Put slightly differently, you force every programmer to be _aware_ of the case issue when they should instead just _know_ what to do and expect. This is not unlike how you train soldiers to march. If you always start on one foot, you never have a problem -- they just get it right whether they are confused about left or right or not, but if you have an option to start on either foot, you have to communicate "left" or "right" at some point, and lots of people confuse them, so you get an inevitable mess out of just _creating_ the option, even if you think you solve something by offering a choice because you believe that the particular choice is no good. The whole key is to _accept_ that an arbitrary decision has to be made, make it, and move on with it as a declared constant, not keep it a variable as if you could undo the decision. Now, I sympathize with the problems that do occur when you want to use the symbol-name for something else, but a readtable-case of :invert and an additional inverter in, say, the FFI code, _does_ take care of it. However, I believe that programmers should also have a choice, but a _visible_ one that they cannot escape noticing. A source or object file does not know which Allegro CL image is used to load it amd it should not have to know, either, but if the source file _actually_ and _explicitly_ requests a particular readtable, it knows. This is the same argument that the SGML community had with respect to the SGML declaration. I helped make it possible to use named declarations instead of omitting it, which everybody did, because the whole declaration had to be inline. To this end, Allegro CL's support for named readtables is _very_ nice. Concomitant support for the in-syntax macro that Kent Pitman once offered would have been most welcome. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief. Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg