Subject: Re: [not so] basic package question From: Erik Naggum <erik@naggum.net> Date: Thu, 25 Apr 2002 23:32:47 GMT Newsgroups: comp.lang.lisp Message-ID: <3228766366475099@naggum.net> * james anderson | i have, quite coincidentally, recently received a note from a lisp user | who was confounded in his effort to use an application by problems with | symbol name case. it was most amusing that, in keeping with the | respective lisp vendor's documents on the subject, the enquiry was | phrased in term of what one should do to make the application code | 'portable'." i had always presumed that "portable" would be confined to | runtime behaviour which itself conforms to "the standard". Well, I for one intensely dislike the hijacking of "portably" to mean "compatible with both the standard and our violation of the standard". If anyone wants a deviation from the standard, it should be made very, very explicit. I am working on a defsyntax form that takes care of many aspects of the reader and printer, and among them symbol case. You identify the source file with an in-syntax form and choose a syntax dynamically with with-syntax, all by name. These forms clearly require a previous in-package, too, so as to make a file without either still use standard syntax, and to be self-identifying for deviating syntaxes. My goal has been to ensure that all conforming code would work the same, but I am stuck with macros that define symbols. Suppose you have the form (defstruct EvilName ...). As long as you use monocase symbol names, this works just fine when the macro definition captures the syntax in which it was defined, but you would have to get MAKE-EvilName if you used the string "MAKE-", although you would get make-good-name as expected, With the aid of hindsight from CLOS, macros that generate symbol names are bad karma. That programmers do not use them without understanding how they work is virtually the only hope. I remain somewhat uncertain whether this pathological case is worth solving, but there is a snag here in that it matters whether you do early or late symbol-name extraction when you use that string to form other symbols. (This is why Franz Inc suggests that late symbol-name extraction is preferable. I am not sure I agree, but it would be a much better proposal with interned-string-style keywords as the name of symbols, even though that would not help against mixing conventions.) Generally, I think the need to support conventions like FooBarZot should be supported with automatic conversion to and from foo-bar-zot. I find the FooBarZot conventions so horribly disgusting that it has been a very serious detractor from solving the case-sensitive lower-case Common Lisp problem. I have even made Emacs help me not see that crap in Java. | in order for this to work, intern, defpackage, and read/print should all | have readily predictable effects as to the internal and external | representations of objects which they manipulate. i would have been less | likely to use that method if it were not trivially possible to predict | the internal symbol name case in a conforming lisp. The solution to the whole problem is to make the readtable hold a slot for intern, find-symbol, and symbol-name so the readtable determines whether (symbol-name 'car) returns "CAR" or "car". Switch to another readtable and you get what you expect. Good Common Lisp style mandates that you do not make dependencies on user-settable reader and printer control variables. (Franz Inc unfortunately does a shoddy job in this area, and this, I believe, is because the case-sensitive lower-case "solution" is there for them to point users at, which is another reason why this form of deviation is so very harmful and causes much unfair distrust in the standard.) | aside from my general curiosity about the possible advantages of | permitting the programmer to predict the effects of thirty-six possible | combinations of symbol case, readtable case, and print case, i am | concerned whether everything which can be expressed in any given mode | can also be expressed "portably". Unless "portably" here is the hijacked Franz meaning, the solution is quite simple, wrap your printing and reading in with-standard-io-syntax. | has there been any discussion on that question? As far as I can tell, the Franz Inc stance on lower-case symbol names is highly irrational and is based in personal animosity towards people, not any longer in anything actually technical -- if it were, they would have researched this and done something far better than they have -- and far less destructive. I mean, when they wanted to support CORBA, they did it amazingly well. When they wanted to support Java, they did it amazingly well. When they wanted to support Unicode, they did it amazingly well. Botching something so central is clearly not from incompetence, which in my eyes makes it much more than a nuisance. That said, I also think the internal symbol-names in Common Lisp should have been lower-case, the case of the symbol when interned should have been stored, and possibly even that matches that differ in case should produce a warning if the user so desired. But that was not the way it went, and if we want to change anything, it is vital that the decision that was made is respected and honored, or any new decision will not be, either. In order to make a transition actually work, we must be just as careful as when Internet mail went from 7-bit to 8-bit characters. MIME is the result of a clearly erroneous decision _not_ to support 8-bit in Internet mail dating back to the 7-bit-only characters on the computers that were on the ARPAnet in 1973. MIME is horribly ugly because of this ancient 7-bit restriction, but we can now send 8-bit text with ESMTP, which itself depends on MIME for the appropriate character set, but all the same, we still allow only 7-bit characters in the headers, leading to one of the most god-awful syntactic inventions since Perl. This is the kind of thing that happens when an old decision is crippling the future. However, this should have been invisible to users of reasonable-quality mail software. When it does not, when people are actually shown this crap instead of the information it represents, they object vociferously. Back in the early days, there were a lot of people who argued that we should "just send eight bits", causing massive grief around the world even though it sort of worked most of the time -- but only within a group of people who used the same 8-bit character set. Venture outside that group, and you lose big time with the "just send eight bits"-line. In order to make sure that people of different value systems or concrete values can work together, more elaborate systems need to be set up than those that work for a single person or homogeneous group. Respect for this more complicated system and the procedures necessary to arrive at them is at odds with the desire to "do it my way" and be satisfied with "it works for me". Actually achieving an improved standard or a workable change as a first step that satisfies all sides is very hard work. /// -- 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