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