« prev · plain text · next »       2000 · Erik Naggum comp.lang.lisp archive       search · random

Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
From: Erik Naggum <erik@naggum.net>
Date: 07 Nov 2000 04:57:40 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3182561860085563@naggum.net>

* John Foderaro -> Lieven Marchand
| Are you suggesting that we remove everything from our Lisp that isn't 
| part of the ANSI standard?

  John, please listen, now.  Nobody is suggesting any such thing.
  Least of all I, but you know that, already.  I support what you do
  in extra-standard work.  I have argued strongly, vociferously, and
  fervently at times, that people _should_ use implementation-defined
  extensions both to the language (like the effect of threads on the
  binding behavior of special variables) because that moves the
  language _forward_.  I don't support what you do to _break_ the
  standard, because that moves the language _backward_.

| Case sensitivity is just one more variant.  In fact it's far less
| likely to be a porting issue than, for example, the particular
| foreign function interface you use.

  It would be even less of a problem if you didn't break the workings
  of readtable-case.  I have shown you, with the code to support my
  claim, that your choice to break that functionality is gratuitous at
  best, and purposefully undermining the standard because you think
  that particular functionality is a kludge to fix a botch at worst.
  Your insistence on not getting this has pissed me off for a long
  time, and you're doing exactly nothing to understand it now, either.

| Ever since the Common Lisp definition started to gel evolution in the 
| Lisp language has slowed.   Lisp used to be a springboard for 
| experimenting with language ideas, then change became a dirty word.
| So yes, we have to get Lisp jumpstarted again.

  I think I have said so quite explicitly, but I said one more thing
  that you consistently omit: First we fully implement the _entire_
  standard, because that works as a better springboard to really know
  what needs to be changed or expanded.  If you jump from a broken
  springboard, it's just foolish to blame non-broken springboards, but
  that's what you keep doing, John.  Because you _break_ the standard
  you don't like, you _blame_ the standard for not supporting what you
  need, and use that as an excuse to continue to dislike it, but this
  is fantastically counter-productive.  But as I have shown you, by
  nuking that stupid *force-readtable-case-raw* thing, you can get
  what you want _within_ the standard operating parameters of the
  readtable and the printer control variables.  Take this to heart.

| > Although I like case insensitivity, and find very little value in
| > your |field| vs. |Field| example from a software engineering
| > aproach,
| 
| If you look at object oriented case sensitive languages you'll
| generally find this is the convention they use (Smalltalk, C++,
| Java).

  Others have chosen a namespace-like approach.  Like Common Lisp does
  special variables with *stars*, Dylan has classes with <brackets>.
  I actually think this makes a helluva lot of sense, that it is quite
  elegant, and furthermore, the abuse of case reminds me of German.
  The use of underscores is clearly Too Ugly, so some fools instead
  went for AlternatingCapitalLetters, which I can't help snicker at --
  it looks like the really want to be programming with crayons!  With
  their keyword-rich languages and highly redundant syntaxes, exactly
  what kept them from using internal _whitespace_ in identifiers?  If
  you look at the grammars of these languages, you find that there
  _is_ room for internal whitespace in identifiers.  So why don't
  they?  Braindamaged language designers who can't think outside of
  the box they live in, that's what.

  I don't think caving in to other language's bad choices is a good
  choice for doing stupid things in Common Lisp.  Common Lispers are
  like English-speakers: used to words with several meanings depending
  on the context and any modifying words in the context.  This is not
  a problem that needs solving.  In languages designed by people who
  have never quite progressed beyond coloring the parts of speech
  differently when parsing sentences, hating the fact that many words
  exist in multiple roles, they can't have an identifier named the
  same as a type, or a function the same as a variable.  This is so
  _ridiculous_!  How could anyone _be_ so unintelligent as to set this
  kind of mess up for himself?

  Now, why do I want a Common Lisp with case sensitive symbols and
  normally all lower-case symbols?  Because I want the _freedom_ of
  actually referring to a symbol as, say, NORDPOOL in all caps, and
  have it print back to me the same way it was read.  That has nothing
  to do with what other languages have conventions for -- the fact
  that they _have_ those conventions _came_ from that freedom, so it's
  the (fundamental) freedom I want, not their (random) conventions.

| That's the key point I've been making.  Old code continues to work
| either in ANSI mode or in Modern mode.

  This is just plain wrong, John.  It is only true if you follow Franz
  Inc coding standards in ANSI mode.  People don't do that.  They'd
  have to change their ways to use a case-sensitive Lisp no matter
  what you think, precisely because of the nature of the change.  I'm
  staring in disbelief at your repeated assertions that I know to be
  completely untrue and I wonder what the hell you're thinking.  Who
  the hell do you think you're fooling with this useless propaganda?

| That's my #1 goal for without it we require everyone to choose one
| or the other and people will just stick with the old ANSI version.

  I have given you an alternative that you won't listen to: Switch to
  lower-case symbol names as a separate step from case sensitivity.
  That way, people will find their dependencies on case first, and
  when that is gone (since it's a good idea not to have that kind of
  dependencies, since the case of symbols is an arbitrary decision).
  This can only be done if you are honest about the case change, which
  you are not, and which it bugs me to no end that you don't realize.

  _When_ people have become accustomed to lower-case symbols and have
  stopped making assumptions about the internal case of symbols,
  there's a natural fall-out: case sensitivity will be much closer,
  and much less harmful to introduce to the Common Lisp world.

  If you introduce case sensitivity with lower-case symbols at the
  same time, you will meet with legitimate and strong resistance,
  because it is just too much at once.  Contrary to what you think,
  there _is_ no migration path from a Lisp with upper-case symbols and
  a case-insensitive reader to a Lisp with lower-case symbols and a
  case-sensitive reader which you can walk, carrying all the baggage
  in one trip.  If you have to make several trips, you need to break
  the migration path in two or more parts so people can make one trip
  per "leg" in the whole migration path, but they must also not be
  allowed to return.  Each step must leave something behind that you
  _don't_ want.  In the case of Common Lisp, you are asking us to
  leave too _much_ behind that we are supposed not to want, like your
  stupid (sorry, John, but that's exactly what I think it is) disdain
  for the standard's solution to the problem of case, and we won't
  move.  Enticing people to make changes in their lives is hard work,
  but there are some things you need to do right: First, make them
  want to move by offering something at the other end of a journey
  across the migration path, but also make them want to leave
  something they do not want behind and make sure the two are so
  tightly coupled they can't have one without leaving the other.
  Second, make sure that you can't go back and pick up your old ways,
  or people will do just that.  The leaving behind thing is serious
  business.  (You seem to think that people are as disgusted with the
  case issue in Common Lisp that you cannot fathom that people do not
  want to leave readtables behind, but that's your _big_ mistake.)

  This wisdom actually comes from my father, who was in charge of
  "rationalization" at an industrial plant when I was just a kid.  At
  the time, it was a problem that workers returned to their old ways
  despite what the management thought were good reasons to move to a
  new way of doing things.  The problem wasn't that the reasons were
  not good enough.  The problem was that they _could_ return.  All the
  effort of the rationalization had been spent on making the move into
  a smooth process, like crossing a plain.  But that's just wrong.
  You have to cross a hill or at best a mountain pass to move to a
  better world and _stay_ there.  That's why I don't move to the
  U.S. -- it's easy enough for me to get the best of both worlds, not
  to mention some crucial developments in the politics of the U.S.,
  what with the dire consequences of having that moron George W. Bush
  in the driver's seat for four to eight years and his Supreme Court
  justices and other key personnel in charge for the next several
  decades, I imagine myself wanting out of there like so many other
  Americans currently feel like fleeing the place before it's too late.

  What you are suggesting to us all, John, is that we leave behind the
  things in the standard that you personally hate with a passion.
  (Please don't try to deny this -- at first I couldn't believe the
  hostility towards the resolution to the case issue in Common Lisp
  that you harbored.)  But most of us don't feel that way about these
  issues.  On the contrary, many of us are actually happy with the way
  it has been decided and how it has worked out.  We're not going to
  pick up your hatred and leave all that behind.  You're not that good
  a cult leader, John, and if you think in cult terms (like a "Modern
  Cult"), you're doing it all wrong.  The Common Lisp community is
  just that: a community, where we _respect_ a common set of rules and
  laws and standards.  You don't.  That's _your_ problem, not ours.
  You _must_ be thrown out if you persist in disrespecting what the
  rest of the community respects.  Don't do that to yourself!  This is
  a fight you can't win.  You can win if you _don't_ fight, however.

  If you want us to do something differently, make sure we get
  something back for doing it that can motivate us to join you.  The
  freedom of using and preserving case information is enough for me,
  for instance.  The simplicity of dealing with symbols that look
  excatly like they are written is appealing to me.  I think upper-
  case symbols look old and clunky and don't want to explain why we do
  things that way to people I'd like to use Common Lisp, not the least
  because I fail.  Case is an arbitrary decision if you have a case
  insensitive reader, but like all arbitrary decisions, they have to
  fall down on one side, and that side invariably carries some kinds
  of connotations with it.  Upper-case communicates "old and clunky"
  to a lot of people.  I'd like to move away from that to a new world.

  But you can't lie to people if you want them to join you.  That only
  works for idiots who run for President, and that's only because they
  get much power it's worth the loss of credibility to get it.  You
  are not going to get any power just because some Lispers move from
  upper- to lower-case symbol names, and you have already realized
  that you aren't going to get the entire community with you, anyway.
  That code written to ANSI X3.226-1994 is going to continue to work
  when ou downcase the symbol names and don't even downcase in the
  reader, but claim that you upcase, insead, is just obviously false.
  I can't believe you think you can fool anyone with that hoax, John.
  It pisses me off that you do, too, because it's such a gross insult
  to people's intelligence.  Common Lisp programmers are among the
  very smartest programmers around.  You treat them like they are
  stupid because they don't _rebel_ against upper-case symbol names
  when it's _you_ who are stupid because you _rebel_ instead of work
  _with_ the community to make this at first an implementation-defined
  property of the Common Lisp implementation.

  The way you're going about this case issue has bugged me for years.
  The way you have consistently denigrated those who don't agree with
  you on the case issue may in fact explain why they stick to _their_
  ways instead of listening to you, and why you don't budge, either.
  I was not there at the time, but I have a feeling from what I have
  read in the publicly available notes, that you went about this as
  irrationally and counter-productively in the committee as you do now
  and that you failed because you never realized that in order to get
  your choice, you have to make the other choice available, too.

  If we shall ever succeed in getting Common Lisp away from specifying
  that all symbol names are in upper-case and that the reader upcases,
  we must make it implementation-defined, forcing people to check if
  they need to know, and use symbols to get their names, not the other
  way around, meaning that the reader has the _only_ opportunity to
  leave _its_ decision behind in the code.  This means full support
  for readtable-case and the printer control variables, which you
  hate.  This means that the Franz Inc coding standards that works for
  both lower-case and upper-case Lisps becomes more popular, and we
  can get a new and better world where the internal case of symbols no
  longer matters.  But we do this the community-friendly way, through
  the standards bodies, with working systems that _respect_ the work
  of the standards bodies and the communities behind them.  You have
  shown us that a lower-case Lisp works just fine.  That is good.  I
  have shown you that you don't have to break readtable-case to get
  that lower-case Lisp.  That is good, too.  Now we can show people
  that if they write code that does not assume an arbitrary decision
  has been made one particular way, they will win something and write
  better and more robust code, too.  That is a good way to go.

  A splinter group, a Modern Cult, an implementation broken in the way
  it deals with specified behavior, is a very bad, very stupid way to
  make a community move in your chosen direction.  I am so thoroughly
  annoyed with you for not using your sometimes brilliant mind to get
  this simple picture, but continuing to do stupid things that hurts
  the Lisp community with your hatred for parts of the standard.  You
  have not listened to me before, and I sort of doubt that you will
  listen to me now, but you're a really smart guy with a serious
  hangup that needs to be cured before you can get the respect your
  work deserves.  The reason is that you don't respect those who hold
  opinions on the case issue different from your own and ignore their
  needs and their requirements, which are far more important things
  than whether some code "works" or not.

  With a standard, we build a society based on trust in common resepct
  for the standard, in best-effort implementations of it, and we hold
  implementers harmless for mistakes if they also work to fix them.
  With a standard, we build communities that work and communicate
  together with a common baseline that is not subject to violation
  except by malicious outsiders, criminals, and destructive forces of
  other kinds.  With a standard, we sign contracts and pay monies for
  work assuming the entire contents of the standard as part of the
  specification for that work by reference.  With a standard, we take
  part in a very, very long legal tradition that extends far beyond
  programming and contracts: That of trusting an authoritative third
  party to resolve our disputes, reasonable as well as unreasonable.

  With your standards-breaking attitude, specifically that _you_
  should be that authority (no longer a trusted third party) and that
  whatever _you_ decide shall prevail, you throw not just some parts
  of this framework of trust out the window, but _all_ of it.

  This works for Microsoft because they have succeeding in building
  their own society and community around trust in their authority,
  such as it is.  Microsoft has built their community around them.
  Franz Inc is a vendor that sells to a community they have not built
  on their own.  They do not own the community and they cannot dictate
  the community will.  Franz Inc _chose_ to implement Common Lisp
  instead of continuing Franz Lisp.  That meant something to you once.
  It means something to me now, and not just because I like the way
  the standard does things, but because I like standards as such,
  because I like lawa snd organized societies that relieve me of
  fighting for my rights all the time so I can instead form bonds with
  people based on mutual trust and respect.  Granted, today's
  political reality is a far cry from what I expect and want to live
  under, but my operating principle is that _I_ shall not contribute
  to any further destruction of society-building mechanisms as defined
  and reasonably well upheld.  I am deeply insulted and offended when
  you don't give a fuck about these principles, John, and just want to
  go off and destroy all the work that went into building this
  community just because you harbor a long-standing hatred for the
  committee's choice of upper-case symbol names.

  Let's build a bigger community, not more and smaller societies.
  Let's find ways to make room for your lower-case needs within the
  important political desire not to specify arbitrary decisions so
  strictly that reasonable choices are no longer available.  And that
  includes you, John: You have to make room for the upper-case needs
  and other people's desire to have reasonable choices, too.

#:Erik
-- 
  Does anyone remember where I parked Air Force One?
                                   -- George W. Bush