Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior.
From: Erik Naggum <>
Date: 2000/11/05
Newsgroups: comp.lang.lisp
Message-ID: <>

* Erik Naggum
| 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.

* 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.

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