Hi

I just downloaded a trial version of ACL 6.0 (waiting for the
commercial upgrade) and found out, to my dismay, that ACL 6.0 ships in
non-ANSI mode when it comes to the reader behavior.

This has bit me very hard for a number of reasons.

In the file 'readme.txt' Franz explains how to generate an ANSI
'image' from the one available.

In the meantime, I would suggest Franz to start shipping a regular
ANSI image instead of the current incompatible one.

My understanding is that the commercial release will come with an ANSI
image available, however, the commercial version is not distributed
yet.

Cheers

  I'm intrigued to learn why that causes _your_ dismay.

| This has bit me very hard for a number of reasons.

  Now, this is obviously silly, as you explain yourself: The readme
  file does explain everything you need.  What bit you was that you
  did not read the readme file, right?  Don't blame the wrong guy here.

| In the file 'readme.txt' Franz explains how to generate an ANSI
| 'image' from the one available.

  Are these instructions insufficient for any reason?

  Rather than build a new image, I prefer to stuff this in .clinit.cl.

(excl:set-case-mode :case-insensitive-upper)
(when (lep:lep-is-running)
  (lep::eval-in-emacs "(setq fi::lisp-case-mode :upper)"))

| My understanding is that the commercial release will come with an
| ANSI image available, however, the commercial version is not
| distributed yet.

  I think the readme file explains everything you need to do in order
  to build the kinds of images you need.  I am decidedly ambivalent on
  the wisdom of shipping a lower-case image, myself, but I think the
  painlessness of making your own image makes complaints seem silly.

  Please note that for whatever reason, the Windows version seems to
  be in ANSI "mode".  This is probably because Franz feels that Unix
  is already so deeply entrenched in the case-sensitive lower-case
  world that it would be a pain to many non-old-timers to be exposed
  to a Common Lisp where the case behavior of symbols is "unreasonable".

  One of the first things I did in Allegro CL was (setq-default
  *print-case* :downcase), just like I had figured out how to stop
  CMUCL from shouting, simply because I think a computer that talks to
  me in upper case is very rude and smells of age like some of the
  things in my refrigerator that had to be shot before they attacked
  Xyzzy, my lovely cat, but that does not _necessarily_ mean that I
  think symbols should be in lower-cased and the reader case sensitive.

  I have come to conclude that this case thing does not matter much to
  me -- although it is a deeply religious issue to people I otherwise
  respect.  What matters to me is that I can know what to expect from
  the environment, but if you query Allegro CL in "modern Lisp" mode,
  it will lie to you about what it does.  That bugs _me_ a helluva lot.

(5) cl-user
(readtable-case *readtable*)
=> :upcase
(6) cl-user
*print-case*
=> :upcase

  At the very least, readtable-case should return :preserve, which
  does have ANSI-defined semantics for the other printer variables and
  is exactly what the reader is doing.  I have complained about this
  internally several times and it annoys me that I'm not heard on this
  issue, so now I'm airing it in public.  Moreover, it is impossible
  to make a readtable in Modern Lisp that _does_ upcase when that's
  what I actually want.  These are bugs, not features.  These are
  breaking the standard and ignoring my needs.

  If the Common Lisp community is going to accept lower-case symbols,
  which is the crux of the matter, it must have a graceful upgrade
  path, not a fork in the road like a T intersection with no way to
  interoperate with the other decision.

  I think Franz Inc is doing the Common Lisp community a service by
  letting them know Common Lisp can have lower-case symbols and a case
  sensitive reader, too, like so many other modern languages, and that
  programming under a standard Common Lisp system which ignores case
  issues is a good thing.

  I think Franz Inc is doing the Common Lisp community a disservice by
  forcing people to use the ANSI mode if they want to have only _some_
  features of the standard behavior.  That way, people will _not_ be
  able to move to a more modern Lisp if they want to, but must stay
  "behind".  Wanting case-insensitive and/or upper-case _parts_ of a
  system is not evil even if some think that upper-case symbols are or
  that a case-insensitive reader is.  If Franz Inc wants to succeed
  with their modern Lisp, they must not force me to ignore them if I
  do not accept the whole package deal.  It is simply wrong to tell me
  that I shall never need a readtable that _does_ upcase, and it is
  simply wrong to _lie_ to me about the case behavior of the current
  readtable.  Stop that.  Be nice to the upper-case people, and they
  might follow you, in time.  Offend them like you have, and they will
  _have_ to antagonize you just to keep what they want to keep.  Not
  that I haven't said this before, but it is precisely because you
  ignore me that I have to say it over and over.

  Until the modern Lisp stops lying and breaking readtable-case, it
  should not be published.  When it has been fixed to work the right
  way, meaning: lower-case symbols, corresponding printer variable
  settings, and a default readtable-case value of :preserve, it should
  be let out in public, again.  The use of some hidden variable to
  control the "case-mode" is bogus all the way.

cg-user(24): (defun test () 1)
test
cg-user(25): (defun TEST () 2)
TEST
cg-user(26): (test)
1
cg-user(27): (TEST)
2
cg-user(28): (Test)
Error: attempt to call `Test' which is an undefined function.
[condition type: undefined-function]

* Christopher Browne
| Where does setq-default come from?  That appears to be an
| "Allegro-ism;" it's not in CMUCL or CLISP, nor is it in the
| HyperSpec.

  Jesus, Christopher, of course.  But what can I say to this nonsense?
  You need to think carefully about the purpose of standards and
  portable code so you do not fall prey to a religious belief in them.
  You should also think _very_ carefully about the purpose and means
  of customization of a specific environment and why some environments
  and languages are designed to be customized and others are not.

  To achieve uniform external behavior, it is always necessary to
  write some non-portable code in different environments.  It is a
  _luxury_ to be able to use such portable code, it does _not_ come
  for free.  If you are unwilling to work to create that luxury for
  yourself, you will create _varying_ external behavior, instead.

  Perl succeeded in the mish-mash of Unix differences because it
  assumed the burden of unifying the behavior at a very high level, in
  stark contrast to the morass of #ifdefs in C and the inability to
  get shell scripts to work the same across the many implementations.
  Perl did not deny the differences, it did not suggest that people
  stick to some standard and hope they could do everything they wanted
  with it, it did not live in the world of wishful thinking and the
  irrational idiocy that only portable code is good code.

  Perl did some things well: It transcended implementation differences
  by staring them in the eye and fighting it out, not by giving up,
  whining that something isn't standard and portable, etc.  It gave
  the bad standards and their nonsensical implementation differences
  the finger and wrote its own standard.  For the kinds of tasks Perl
  does well, it is downright _impressively_ portable.  You need the
  ever expanding Perl book, but not the tens or hundreds of shelf-feet
  of manuals that you used to have to deal with.  Perl has created its
  own operating system interface precisely by being an incredibly ugly
  implementation, and I'll give Larry Wall this, but not much else: He
  did fully understand the value of uniform external behavior of a
  tool and he was willing to pay the price to get it.  There is no
  excuse for the _language_ he created in order to do this, however.

  Now, some people try to compare Perl and Common Lisp, which I think
  is an incredibly tasteless insult to the work of the Common Lisp
  community to create Common Lisp, because it already _did_ the same
  good things that Perl did.  Some people do not appreciate this and
  go ballistic over the complexity of pathnames, hailing Unix as the
  simple and elegant solution, but Unix is only simple, not elegant:
  That's why it needed Perl.  Common Lisp doesn't need _its_ Perl: It
  already _is_ everything that Perl aspired to be from the beginning.
  What needs to be done is to _build_ on that environment in the same
  vein: Uniform external behavior.  That means only one thing: Ugly,
  implementation-specific code that _exports_ simplicity and elegance,
  transcends the silliness of operating system vendors with only their
  own concerns to consider, transcends the incompetence of the Evil
  Empire, and defines a virtual operating system on top of whatever
  cruft people get for free on their fine computing machines.  This
  requires tons of code the equivalent of dirt under fingernails.
  This requires tons of work that is never seen because its main value
  is to hide and gloss over.  Once upon a time, the Common Lisp
  community was willing to do such work.  These days, most are so
  spoiled with the result of that prior work they are not even willing
  to use implementation-specific features to get what they _want_.

  People who go off to do their own thing need both policing and good
  friends.  Vendors cannot normally be trusted to do the right thing
  on their own unless they have wise critics and co-conspirators alike
  to guide them with input from the outside world at crucial times
  before releases and during development.  In much smaller capacity
  than I would like, I try to help Franz Inc that way, and it's much
  more work than I thought it would be, but it's rewarding most of the
  time.  Many people here favor some free software implementations
  where everybody's an insider, destroying that customer-critic-friend
  trichotomy, and brushing people aside by asking them to just supply
  patches, but that is not what this is all about, and write access to
  the source as in many Open Sores projects doesn't even work when you
  want politicing and good friends who tell you what you shouldn't do.
  Sharing code builds one type of community.  Sharing visions for the
  uniform external behavior builds another type of community.  Perl
  had the latter, but is moving towards the former.  Lisp sort of
  began with the former and is moving towards the latter.  However, if
  the "vision" is "don't use implementation-specific features; don't
  write non-portable code", it's an accountant's vision of the future:
  That of looking backwards in the books detailing the past.  We don't
  need that.  We need implementation-specific code where people agree
  on what matters: What other programmers will need to know and do to
  use it, not agreement on the code and a laissez-faire attitude to
  the interface.

  What does this all mean?  Respect the standard absolutely, but such
  respect comes from realizing that it was made by people in a process
  of much disagreement and pain.  Reject the standard as a limitation:
  It should never have been regarded that way if it were.  Reject the
  standard as the final vision: It isn't that, either.  Step onto it
  and use it as a higher vantage point.  (This works in the literal
  sense with ANSI Common Lisp, too.)

  And above all: Shoot the anti-visionaries.  They have kept Common
  Lisp back for many years by refusing to use non-standard tools,
  which has only led to a dearth of solutions to interesting problems
  after the standard.  Now, post-partum depression sets in with the
  release of standards, but even though we had a prolonged birth with
  that longish freeze time and final quibbles, it shouldn't still be a
  problem.  Especially not with people who weren't even there when the
  standard was hammered out, but who act like it's _their_ baby.  For
  some reason mankind shall probably never fully understand given that
  we _do_ understand what they go through, many women give birth to
  more than one child, so maybe some have felt that after the standard
  came out it was a good time to cut the wires and make like a raven
  and go "nevermore".  I don't see that in the people who are most
  likely to be able to pull the locomotive, then push it before they
  leave it running in its own.  I see that in a lot of people who look
  like they are fearful of being run over by _any_ moving object by
  virtue of standing completely still, themselves.  It's time to get
  this baby rolling again, to mix this paragraph's metaphors badly.

We had to choose just one to ship with the trial version to keep
the size of what you had to download within reason.

The 16-bit Modern version is the most flexible in the sense that
it can run all the tools (in particular this is the XML parser's
perferred mode).   Since the intention of the trial version is for
you to try things, it makes sense to distribute the most powerful
version.

The Modern image has slightly more information than the ANSI one.
You can generate the ANSI version from the Modern version but not
vice versa.  Thus supplying the Modern version and asking you to
create the ANSI one if you need it saves you download time and
requires very little effort on your part.

  Try (symbol-name 'defun) and see the light.

| That sure encourages the use of mixed case symbol names.  And soon
| we will have to deal with mixed case CL codes.  I don't like that.

  Do you feel encouraged to use mixed-case symbols?  Do you know
  anybody who are?  Or did you think you were playing in Scary Movie
  and had to make a stab at a charicature of something fearful?

  Arguments from fear of what stupid people might do if not controlled
  and punished is not the Lisp way.  Learn to trust Lisp programmers.
  Expect something from them.  (And shoot the buggers who think they
  are still in no-expectations-land.)

 I've been dealing with reader case issues since 1980 when
I ported Macsyma written in an upper case lisp (MacLisp) to
Franz Lisp a lower case, case-sensitive lisp.  One constraint
was that I couldn't change the source code (except for a line
here and there).  

 I learned quite a bit about what was needed to make lisp code
not just case independent, but independent of whether it
is case independent  (meta-case-independent?).

 All developers at Franz work in a case sensitive lower case Lisp
(i.e. now called a Modern mode lisp) yet all our code works in
an ANSI (upper case) lisp (except that just recently code to
interface with case sensitive things (e.g. XML
and Java) doesn't work well in ANSI mode, but that's off topic
for this discussion).

 So the point is that whatever you may think of the features of ACL,
it does provide a system in which you can develop ANSI-only
code, Modern-only code, or you can develop code that will work
in either mode.  Whenever possible we write code that works
in either mode.

  Why don't we set readtable-case to :preserve in a Modern lisp?
It's because that would harm the ability to import ANSI code
and make it work in Modern mode as well.  It would make it harder
to write code that works in ANSI and Modern modes.
The reason that it would cause problems is that it brings readtable-case
into play in Modern mode.  ANSI code may create a readtable, and then set
its
case to :upcase so it can read in some data that it had written before.
This isn't going to work in Modern lisp since standard symbols are
in lower case.  So when porting you're going to have
to search for all uses of readtable-case and insert conditional
code to make it work in ANSI and Modern mode.   The conditional
code has to be runtime and not compile time conditional since
the decision as to which mode to run in is made at
runtime and a given fasl file can be compiled in one mode and
run in another.

 So what we did with set-case-mode is akin to setting up a virtual
machine.  If you run in Modern mode your program still sees *print-case*
set to :upcase and readtable-case set to :upcase and happily
goes on it way, thinking that it's running in a normal ANSI
lisp (unless it checks the value of *current-case-mode*).

 I can only state that 20 years of experience has show that this
kind of thing works.   I've yet to find a single ANSI program that
I can't import and make work in both ANSI and Modern modes.  So
while what we have may not be pretty, it does the job that it was
designed to do.  

 If the decision hadn't been made to make Common Lisp case insensitive
upper (and I tried my best to stop it), then there wouldn't
be *print-case* or readtable-case in the language.  They
are just kludges to fix a botch in the language.  

 If you really think that you want case transformations in the
reader in Modern mode then we have to do them in a different
way (i.e. a different function name would have to be involved
(e.g readtable-case-modern)  so that it didn't ruin the virtual
machine effect we've got going.

 And to implementors of other lisps: I  encourage you to
add support for a Modern mode in your lisps as well.
If I can help you achieve this send me email.

        (setf excl:*ignore-package-name-case* t)

is a good thing as well.

        (readtable-case *readtable*) ==> :upcase

as the ANSI standard requires for the standard readtable.

Of course, I can go on and rewrite my code using the style described
in the document 'case.htm'.  However.

1 - I do not expect code that I know to be ANSI compliant (to the best
    of my abilities) to break on a new release of a new product.

2 - The style described is wasteful. You basically double the number
    of symbols (interned or not) for any package you write.

        (readtable-case *readtable*) ==> :preserve

and make the rest of CL case sensitive and lowercase biased.  I am
sure, there are justifications.

I hope the Franz people here hear you.

Cheers

Cheers

But you would agree I'm sure that people should be able to write
code any way they wish in the privacy of their own home.  So it's
right to give people the choice to program in whatever language
they choose.

If you write code that you wish to contribute to others you
as the author have to ensure that it will work on the target
platforms on which you wish it to run.  If you want it to run
on a pure ANSI lisp then you must make sure that if you use
mixed-case symbols in your program then there are no symbol
name clashes if the code is read by an ANSI reader.

While Franz has never delivered a Modern image before the lisp has
always been capable of running in Modern mode.  I haven't seen
any problems arise due to that.   I think that Lisp people
prefer to use a hyphen to separate words in a symbol instead
of Capitalization.   However if you want to refer to a Java
symbol MakeStringIOPort from lisp it's much clearer to me to refer
to it as MakeStringIOPort than make-string-i-o-port or MAKESTRINGIOPORT.
So I see people using mixed case when they need to denote
objects outside of lisp that are denoted by mixed case symbols.

Bottom line: Franz is not going to start introducing mixed case
APIs to normal lisp things.   You can use mixed case if you want,
it's your choice.  However when dealing with mixed case
objects (e.g. Java symbols, XML symbols) we will make use of ACL's mixed
case ability if the result is a cleaner interface.

  There is nothing in the case sensitivity of these languages that
  requires a that a case-insensitive reader be killed.  We have been
  able to work with case-sensitive readers for a very long time -- it
  really is no big deal.  When you lower-case all the symbol names,
  you make that much, much easier for all of us and I thank you for
  this, I really do, but I hate you for breaking the standard in the
  process when that is so _obviously_ unnecessary and a hidden agenda
  against the standard and the committee sticks out like a sore thumb.

| Why don't we set readtable-case to :preserve in a Modern lisp?  It's
| because that would harm the ability to import ANSI code and make it
| work in Modern mode as well.  It would make it harder to write code
| that works in ANSI and Modern modes.

  *boggle*  You have _broken_ readtable-case so it is hard-wired to
  :preserve no matter what it reports or I set it to.  If what you are
  saying is true, then _you_ have harmed the ability to import ANSI
  code and make it work in Modern mode as well by doing that.  Except
  you aren't telling anyone about it, which you would if you did make
  that change.

  What you're saying is pretty obviously false, but by now I realize
  that I'll never get through to you, which means I shall have to
  fight _against_ your Modern mode.  Pretty stupid move, John.  I want
  lower-case symbol names.  I want a case-sensitive reader by default.
  I _don't_ want to have to get rid of the case-insensitive reader in
  the process because I actually _need_ that functionality, but since
  you force me to accept that package deal, I simply _cannot_ work
  with the stuff I want, and I'll have to go back to the only mode in
  which readtable-case actually works as standardized.  What _are_ you
  so bone-headed about this?  What _would_ it cost you to keep within
  the standard on the rest of these issues?

  If you had set readtable-case to :preserve, which is its real value,
  anyway, the standard says to ignore all the other case settings,
  which is also precisely what you do, so the Modern behavior is all
  _within_ the standard.

  If people set the readtable-case directly, they know what they are
  doing.  If they want to read Lisp data in standard syntax, which is
  but one _effect_ of choosing :upcase, they are supposed to use the
  macro with-standard-io-syntax, not roll their own just because they
  can.  That would be a violation of intent, and Kent Pitman has made
  a very good point about accidental truths and necessary truths.  It
  is a _necessary_ truth that if you use with-standard-io-syntax, you
  will be able to read Lisp code in the standard syntax.  It is an
  _accidental_ truth that you may be able to do so if you set the
  readtable case to :upcase.  This is f*cking obvious.  Why do you
  fight this and refuse to get it?  What do you gain by antagonizing
  the standard and me and everybody else who would like to seee a Lisp
  with lower-case symbol names, a case sensitive reader, but still
  have the _choice_ we have come to love about Common Lisp?  What _is_
  it with you that makes you work so hard to remove that choice?  It
  really and truly does move the choice in a particular readtable with
  case-insensitive upper-casing behavior to a choice in Modern or ANSI
  Lisp, and that is not the choice I want to make just because I want
  a simple, straightforward, well-defined functionality in ANSI CL
  _with_ your new decisions, and there _is_ no technical reason you
  don't want to give it to me.  It's _political_, and although we have
  one of those "choose the idiot with the nicest teeth in his grin"
  contests right now, that doesn't mean I'm willing to buy any package
  deals based on similarly irrelevant criteria.

| The reason that it would cause problems is that it brings
| readtable-case into play in Modern mode.

  So you have created another, global, variable instead with exactly
  the same semantics as the readtable setting, forcing people to fuck
  with that instead of the standard interface to the reader for no
  other reason that you historically hate the decisions that led to
  their inclusions.  Good stuff for religions.  Bad engineering.

| ANSI code may create a readtable, and then set its case to :upcase
| so it can read in some data that it had written before.

  It may _also_ create a readtable and set its case to :upcase because
  it really wants the symbol names in upper-case.  You disallow that.
  I'm not objecting to what you have achieved.  I object to the fact
  that you force me to duplicate functionality with non-portable code
  for no good reason only to achieve what I used to achieve: upcasing
  symbol names in the reader.  Because of your obnoxious and personal
  dislike of the case stuff in ANSI Common Lisp, I have to redo what
  is supposed to be in there for those uses where case-insensitivity
  is well-defined and actually useful.  I'm beginning to hate your
  decisions on case for _that_ reason, not because you try to preserve
  some other property of the environment that I disagree with.

  If you have to break something to get something so fundamental and
  relatively simple changed, you're guilty of bad engineering, as in:
  Changing the world before you change your tools.

  What kinds of written data would your claim actually work out on?
  Because you have ripped out the case-translation in the reader, it
  would have to be all lower-case in the _input_ to get the right
  symbols, but that is _not_ the canonical case, so you end up with
  all upper-case symbols, anyway, since that _is_ standard, as in:
  produced within the body of a with-standard-io-syntax form.

  What you could do is take this back to the drawing board, declare
  yourself unfit to make technical decision because of too much
  personal involvement, and let other people find ways to reach all of
  your (technical) goals while breaking none of other people's goals
  and needs.  That is what mature standardization is all about, and
  that's how mature people interact when they have conflicting needs.
  You may think you won't find enough lower-case-friendly people to
  get the committee around if you had to, but that is _irrelevant_.
  You're already going ahead to implement something outside of the
  standard, so you should _minimize_ (as in: _good_ engineering) the
  effects upon the rest of the system with your change.

  E.g., with-standard-io-syntax should print in lower-case, escape
  upper-case letter in symbols (no harm done in case-sensitive mode)
  and lower-case symbols on input.  Just reverse the case in a fully
  consistent, predictable way and you'll be surprised how little of
  the language and environment actually _does_ change.

| This isn't going to work in Modern lisp since standard symbols are
| in lower case.

  So the readtable-case has to be :lower, instead, because symbols are
  now all lower-case.  Big deal.

| So when porting you're going to have to search for all uses of
| readtable-case and insert conditional code to make it work in ANSI
| and Modern mode.

  *boggle*  What?  Excuse me?  You cannot possibly be serious, John!

  We have with-standard-io-syntax to get standard syntax.  If people
  meddle with the readtable-case, they do that on purpose and must
  accept full responsiblity for it.  No need to look for anything.
  Their settings correspond to their input requirements.  If they set
  :upcase, they will look for symbols with upper-case names and they
  will have interned them with upper-case names, and if they are not
  the complete morons you expect them to be, they will write code that
  names them in all uppercase, too, simply because that is so much
  less confusing to the reader of the code.  (We agree fully that it's
  a royal mess to deal with case translations in your head while
  reading the code.  Case sensitive makes maximal sense across the
  board, but that's _code_, not input from the outside world.  You are
  _reversing_ the code-is-data paradigm of Lisp with this move, John!
  You force me to treat external data as if it code, but it's really
  the other way around: It is code that I may want to treat as data.)

| The conditional code has to be runtime and not compile time
| conditional since the decision as to which mode to run in is made at
| runtime and a given fasl file can be compiled in one mode and run in
| another.

  I wonder who you think you're fooling with this joke of an argument.
  I wonder if you realize how much you insult people's intelligence by
  pretending that this is valid reasoning that they are supposed to
  accept.

  John, you _do_ know better than this, so I wonder why you completely
  ignore the language as actually defined.  The language you keep
  arguing against is _not_ a full Common Lisp, but rather some stunted
  version that displays all the flaws you would like people to believe
  the full language suffers from, but that is simply not the case.
  I'm positively _flabbergasted_ that you think you can get away with
  such an obvious hoax in this forum, of all places.  I could be mean
  and say that you pit Modern Lisp against Ancient Lisp, not ANSI Lisp.

  The "ANSI reader" can be told to preserve case.  Except in Allegro
  CL, where that functionality has been ripped out on purpose in order
  to make code that wants to use this functionality break.

  Symbol quoting has _always_ worked.  In fact, it's in there because
  people wanted an escape from the case-insensitivity.  You can write
  |IThinkSmallTalkIsBetterThanCommonLispAnyway| and get _exactly_ what
  you typed as the symbol name.  Oh, I'm sure we'll hear aesthetics
  arguments, now, but that is irrelevant: If you want it, you got it.
  Thank you for not breaking this property of ANSI Common Lisp.

| While Franz has never delivered a Modern image before the lisp has
| always been capable of running in Modern mode.

  Huh?  ACL 5.0 Trial was delivered with :case-sensitive-lower, IIRC.
  ACL 5.0.1 Trial was delivered with :case-insensitive-upper after
  much of the same kind of resistance that you are facing now, having
  learned nothing from last time.  That just adds to my being annoyed.

| I think that Lisp people prefer to use a hyphen to separate words in
| a symbol instead of Capitalization.

  More than that, people are not using MixedCaseWordsStrungTogether in
  any environments other than those in which they are taught it is a
  good thing, despite no shortage of case sensitive systems.  Ever see
  users use filenames like that on Unix?  Ever see _Windows_ users
  flock to the StupidCapsCamp?  One would perhaps think that they
  should because their programmers tend towards such identifiers, but
  that is not what we find in practice.

| Bottom line: Franz is not going to start introducing mixed case APIs
| to normal lisp things.   You can use mixed case if you want, it's
| your choice.  However when dealing with mixed case  objects
| (e.g. Java symbols, XML symbols) we will make use of ACL's mixed
| case ability if the result is a cleaner interface.

  FWIW, I think this is a good argument for case sensitivity.  Lisp
  has always been a language for making communication easy, and the
  upper-case thing was mostly due to communication with FORTRAN way
  back when (now known as Fortran :).  Lisp as such has no intrinsic
  need for either case or case sensitivity, which is why it works just
  as well to write Common Lisp code in case-insensitive-upper as in
  case-sensitive-lower modes.  (Yeah, I know I'm rubbing it in.)

Wow, that's pretty brutal coming from someone I consider a friend.

I'm too shell shocked to know where to begin so I'll just go back
a bit and reiterate that the goal our our case mode switching code
was to painless permit ANSI code to be imported into Modern lisp.
It's like the x86 architectures all support 8086 code.
Intel could have said that in order to run 8086 code on the 386
you had to write it in a certain way the the 386 chip would have
been a lot less popular (which may have been a good thing for the
world, but that's another topic).  
Likewise telling people to change their code to use with-standard-io-
syntax
rather than hacking readtables would be possible but would make the mode
less popular.   It may even prevent some code from being ported.

The current situation is that most people out there are using
lisps in ANSI mode and producing ANSI-only code.

At Franz nearly all of our code works in ANSI or Modern mode.

There are probably some people developing in Modern-only mode (we see
messages from them on occasion).

What I'd like to see is a movement toward Modern mode.  I'd like to
see other lisps support it and I'd like people to start making their
code work in ANSI and Modern modes.

Then when that's done we can start to move toward Modern only

The way we deal with readtable-case makes it easy to convert code
into a mode where it works in ANSI or Modern mode.  That's a critical
first step.  If we scare people away and make it too hard to do the
conversion they won't bother.

Clearly you've got a problem where doing case conversions in the
reader is critical.  The question is whether that can be solved in
another way.

A question for other (human) readers of this is: given that you are
working
in a case sensitive lisp, is readtable-case something you need for
your application.

Let me make my comment about porting clearer.

If you work in Modern mode you can write code like this

(let* ((Field (create-class 'Field))
       (field (create-instance Field)))

    (print-class Field)
    (print-instance field)      
)

That is you can have two variables that differ by case only.

Now if you give this code to your buddy who runs in ANSI mode
it won't work, the reader will only create one symbol FIELD.

If this code is just for your own use then that's ok, you can leave
it as it is.
If you want this code to have wider use then you can either change
the name of one of the variables or else use escaping:

(let* ((|Field| (create-class '|Field|))
       (field (create-instance |Field|)))

    (print-class |Field|)
    (print-instance field)      
)

The point I was making in response to Kebe Abe's comment was that
you as an ANSI user won't have to worry about a great influx of
code with mixed case identifiers since the author of the code,
if he wants maximum portability, will have already dealt with the
consequences of mixed case identifiers.  

I hope that clears up the confusion.

=========

Yes, ACL 5.0.1 trial was delivered in ANSI mode.  That was because
we didn't have any packages at that time that worked better in
Modern mode.    It should be possible to switch it to Modern mode
with set-case-modea function (which has been in the lisp for 15 years).

=========

 Switching to Modern mode is more than just binding a variable or two.
It involves changing the print name of almost every symbol in the system
(including those symbols whose print names are stored in shared
read-only memory).  
 When this happens you no longer have an ANSI Common Lisp.  
Try (find-symbol "CAR") and you'll get nil back.    

  If it isn't clear to everyone what Erik and I have been discussing
is how things should work in this non-ANSI common lisp.   He's looking
toward
the future and saying how things should be ideally.  I want that
too but more than that I want to drag people currently using ANSI
mode into the Modern mode.  

it's wysiwyg.

What we've done with the ANSI and Modern mode is create a system where
all the old code can run, and where people can if necessary use
mixed case to naturally interface with existing languages.

(defpackage :net.aserve
  (:use :common-lisp :excl :net.html.generator)
  (:export
   #:authorize
   #:authorizer
   #:base64-decode
   #:base64-encode
   #:compute-strategy
   #:computed-entity
  ....
))

If I'm in `modern mode' in acl, and I want to read some stuff in case
insensitive uppercase, then I have a choice of:

1. write my own reader;

2. toggle, globally, into ansi mode and back, losing case information
   about potentially every symbol in the system in the process.

3. don't use modern mode, and live with || where I need
   case-sensitivity.

3 is the only option that I could possibly use. 1 is mad. 2
potentially breaks things in completely random ways, not just because
I lose just the kind of distinction that case-sensitivity get me when
FOO -> FOO -> foo, but because I might have other threads in the
system which will fall about in ANSI mode, so I basically have to do a
without-interrupts while I sit and wait for something to come down
some network connection for 20 minutes.

Is it this bad?

Wouldn't it be possible to split this thing in two -- a part which
controls the readtable case sensitivity of a readtable (which I think
we already have in ANSI CL) and some utility which will change the
case of symbols in one or more packages?  That way I could be in a
lower-case lisp (after using the second utility) but I could control
how I read things by adjusting readtable parameters and/or changing
readtables.

Nothing in the standard ANSI CL definition prohibits you from calling your
symbols FooBar if you want, but I as an outsider can still see them as FOOBAR
if I want.  By making them mixed, you force me to not be able to interface
to your code as either a reader of the text, a viewer of the output, or a
caller of the code without confronting your case choice, and so by consequence
you force on people exactly what you said you didn't want to in the paragraph
above.

And if you don't think anyone will ever link with your code, I
honestly have to ask whether you're writing for posterity.  Most of my
code has had a substantially longer life than I ever expected.  Code I
wrote over 20 years ago is still in active use today, even some code I
didn't expect to be.

Or maybe you mean to trick people by using a meaning of modern that only
happens in uppercase-initial mode, hoping they won't notice it doesn't have
the Webster's meaning.

I think this is bad.

I also don't think there's evidence of convergence on case sensitivity.
HTML and XML are not case-sensitive, for example.

Neither the Windows file system nor the Mac file system is case-sensitive.

The English language itself is not case-sensitive.

It is not at all confusing to people to be told that case is not significant,
and there are plenty of ways to defend this behavior as "modern".

 (defun make-string-i/o-port (...) (jcall "MakeStringIOPort" ...))

I don't see any reason to muck around with the readtable to make this feel
elegant.

Incidentally, I assume this also encourages enormous misconceptions about
the internal case of symbols, since "car" (and I assume you don't require
the person to write "CAR", like I'd probably write) is not uppercase
internal in its printname, and yet retaining the case of "car" means
finding a symbol whose case is flipped from the normal.

OTOH, I don't see how old code can run without modification and
conditionalization.  For example, the series package exports symbols
like "COLLECT-SUM" and uses lower-case symbols in the source.  The use
of the modern image requires a conditionalization of the defpackage
forms, I suppose (like #+modern or something).

This lead me to a possibly irrelevant and naive question: why isn't case
preservation or modern behavior controlled at the package level?  Java
function calls and several other things are rightly case-sensitive.
Would it not make sense to give the package maintainer freedom to
specify whether the symbols created in that package are case-sensitive
or not?  It would help retain compatibility with packages that are
nothing to do with interfacing (like series), and even let the door open
for future swings back to case-insensitivity in the outside world.  As
(interned) symbols are managed by packages, would it not be the right
level, rather than the entire image, in the name of modularity and
scalability?

A slight correction: XML *is* case sensitive, while HTML is as you say
case insensitive.  This is one of the numerous hurdles involved in
going from HTML to XHTML, that is HTML reformulated into XML.