Subject: Re: A modest proposal (long)
From: Erik Naggum <>
Date: 2000/03/03
Newsgroups: comp.lang.lisp
Message-ID: <>

* Erann Gat
| Common Lisp is case-sensitive like people expect.

  we might as well conclude at this time that special variables work just
  the way people expect, because we make a semi-conscious decision to
  ignore those values of "people" where "expect" returns false.  _some_
  people, however, do not expect the same as you do, and they might even
  react the same way you do to some aspect of special variables ("it's
  EVIL!") to some aspects of upper-case symbol names.  it's _so_ amusing
  that you don't get this.

  the point being, put like a nice little riddle: those who have problems
  with symbol-value are also likely have problems with symbol-name.

| I don't know whether this last item is part of the standard or simply a
| consequence of the default read table case being :upcase.

  the symbols are all upper-case and Lisp has case conversion because the
  languages that Lisp talked to had upper-case names and case conversion,
  FORTRAN in particular.  since symbols are first-class citizens in Lisp,
  and not in most other languages, we have been stuck with them in a way
  that other languages haven't.  other languages have moved on to a much
  richer character set (the upper-case thing was merely an artifact of the
  terminal equipment and punched cards on which the code was written) and
  have dispensed with case conversion because it loses information that is
  now more readily available.

| In any case, to make CL act like every other language out there we'd have
| to 1) change the default readtable-case to :preserve and 2) change the
| names of all the standard symbols.

  that's the straightforward answer, but now you're going into this
  "there's only one solution to this problem, and that's the one I just
  dreamt up, but since I didn't like the problem, I dreamt up a bad
  solution, so therefore the problem is also bad" mode which seems to have
  an incredible attraction to you.  I'm explicitly trying to get you _off_
  of that path.  can you work with me on this, please?

  Allegro CL has the ability to do just what you're describing, and has had
  it forever because of the Franz Lisp legacy -- it was lower-case and case
  sensitive.  today, excl:set-case-mode actually converts symbol names from
  upper-case to lower-case.  Allegro CL is actually built with lower-case
  symbol names, upper-cased as a step in building the distributed version
  to customers.  this is not a problem for Franz Inc, and not a problem for
  their customers.  many customers also revert to lower-case mode simply
  because it makes a lot more sense than upper-case mode does at this time.
  that they don't talk about it has to do with the fact that some people
  get _really_ upset whenever case is brought up, but it finally dawned on
  me that we're _not_ talking about case, we're talking about which other
  languages we want to communicate with, and case issues _follow_ from
  that.  it's not as if case is the primary factor of choice and we just
  happen to like FORTRAN better than C.  it's that to talk to FORTRAN, you
  had to use the same case FORTRAN did, which were upper-case, but to talk
  to C, you have to use the same case C does, which is in both cases.  it's
  a question of communication.  of course, we can demand that other people
  talk to us, and refuse to listen to their arguments.  people who do that
  on an habitual basis in real life, too, probably stick with upper-case in
  Common Lisp, as well.

  yet, however you wish to regard this, case-swapping is not something you
  do without vendor support.  Allegro CL already has all the support it
  needs.  in the case of CLISP or CMUCL, you're free to fix it yourself in
  any way you want that doesn't have to be "portable" at all.  that leaves
  us with what Harlequin and Digitool would do if they were asked.

| Straightforward implementation-specific hacks won't work because the
| symbol name is stored in many places, not just in the symbol.

  so let's do non-straightforward implementation-specific hacks, then.
  (again, how hard can it possibly be to realize that when you have found
  an obvious flaw in a given _solution_, you keep looking for solutions,
  you don't just give up and shout the _inverse_ of "eureka!" and declare
  the _problem_ dead and buried.)

| You could make duplicate symbols with lower-case names and copy their
| value, function, and plist slots, but this would probably break
| most compilers, which probably have code like (case (car form) (if ...

  again, I would prefer to engage the creative part of the brain, not the
  propaganda machine, when we encounter engineering problems.  obviously,
  this idea is really stupid, and so it's an indirect insult to would-be
  proposers to assume that they haven't even thought about it.  but, hey,
  this is also something I'm trying to get you away from resorting to.

  Common Lisp is often hailed as suitable for writing mini-languages.  now,
  instead of writing a _new_ mini-language, I think it's important that we
  find a way for a fully conforming ANSI Common Lisp implementation to be
  able to handle source code in :preserve mode, written in lower-case.
  this is _obviously_ not a problem, since Common Lisp is good at writing
  mini-languages.  right?  right!  let's see if it is possible to turn code
  written with :preserve and lower-case expectations into code that can be
  compiled without changing much anything.  this should be eminently doable
  for the vast majority of cases.  (if there be residiual problems, I hope
  we can avoid more propaganda machine output and instead focus on solving
  them or theorizing about the problems, not just sit down and wimper.)

| Or you could just tell beginners not to mess with readtable-case at all
| since the :upcase default generally does the Right Thing.

  and that's what I've been telling you to do with your "special" hacks.
  I'm relieved that you think this is an OK response to a silly proposal,
  but in this case, I'm trying to show you that my proposal, which I sort
  of expected you to dislike, is actually quite similar to your problem:
  how to get people's expectations to fit the language they use, and vice
  versa.  you can't dismiss this _problem_, and I certainly did not dismiss
  it in your proposals, but you can still dismiss proposed solutions.
  that's why I wanted you to see the difference between bundling a problem
  with a solution and having it rejected and looking a problem square in
  the eye and determine to solve it by submitting a whole bunch of ideas
  for other people's rejection and perhaps that one winner.