Subject: Re: [not so] basic package question
From: Erik Naggum <>
Date: Thu, 25 Apr 2002 23:32:47 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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: