Subject: Re: What case problem is Franz trying to solve?
From: Erik Naggum <>
Date: 2000/11/15
Newsgroups: comp.lang.lisp
Message-ID: <>

* Marco Antoniotti <>
| All the proposals I saw deal only with READTABLE-CASE manipulation.
| In the case of John's proposal, there is a blanket statement that
| institutes the behavior of symbol lookup on certain (all) packages.
| My proposal (which is beyond ANSI) explicitely gives the control about
| how symbols get interned in packages to the user, and IMHO it obviates
| the problem of eventually breaking currently working ANSI packages.

  Placing this information in the package is a big mistake.  The package
  does not know which case you are using today, and it should not know
  in the future, either.  The package has a hashtable that needs to deal
  with access to symbols, and intern needs to know about it, but the
  package is the wrong place to store that decision.  This is not only a
  question of use-package and the "mystery factor" that will force a
  user to know which package a symbol is interned in, but of abstraction
  and goes to the whole purpose of the package system.

  It is _paramount_ that we maintain case insensitivity as a major
  concern.  If we _design_ for system-wide case sensitivity, we _must_
  lose big time on several fronts and we are almost certain to commit a
  Foderaro and just go ahead and "solve" all the problems that crop up,
  instead of rethinking the problem when the number of problems becomes
  too high.  Franz Inc's solution, with separate images, global changes
  to all symbols, etc, with no memory of original case or anything, is a
  fantastic mistake.  It "works" because Franz Inc has chosen to invest
  the resources it takes to _make_ it work and that has mostly to do
  with some irrational antipathies towards upper-case symbols.  From
  what I can see, it is an unwarranted waste of resources to do it the
  way they have done it.

  The purpose of a change should be to increase freedom of expression.
  Given that, we must consider the consequences of employing both lower-
  and upper-case symbols (and code that creates and accesses them) in
  the same Lisp image.  However, in so doing, we must also consider the
  argument that Unicode case translation is expensive.  It is expensive
  if done wrong, but if we keep in mind that case translation should be
  very, very efficient, we optimize this by storing into each character
  object as read from a stream more information than strictly necessary
  for storing into strings.  This is viable because we are going to do a
  _lot_ of table lookups at that point, anyway, when using any external
  format that translates into Unicode.

  ALGORITHM: a procedure for solving a mathematical problem in a finite
  number of steps that frequently involves repetition of an operation.
  ALGOREISM: a procedure for solving an electoral problem in a finite
  number of steps that frequently involves repetition of an operation.