Subject: Re: What case problem is Franz trying to solve? From: Erik Naggum <erik@naggum.net> Date: 2000/11/15 Newsgroups: comp.lang.lisp Message-ID: <3183236007594313@naggum.net> * Marco Antoniotti <marcoxa@cs.nyu.edu> | 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. #:Erik -- 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.