Conversion to ANSI Common Lisp via FUTURE-COMMON-LISP

[KMP@STONY-BROOK.SCRC.Symbolics.COM (Kent M Pitman)]

    Date: Mon, 10 Dec 1990 11:59 EST
    From: lgm@iexist.att.com

    I am about to convert our group's software to CLOS, and would like to
    convert to ANSI Common Lisp at the same time, at least to the extent of
    its implementation in FUTURE-COMMON-LISP in Genera 8.0.1.  That is, I
    would USE-PACKAGE both SCL and FUTURE-COMMON-LISP but prefer the latter
    in symbol conflicts.  Are people using FUTURE-COMMON-LISP extensively
    yet?  What pitfalls should I watch out for?  Offhand, the following seem
    to be the major points of caution:
    ...
    Does anyone have any others?  Am I acting prematurely to attempt this at
    all?  Are some implemented features of FUTURE-COMMON-LISP known to be
    buggy?

This isn't to address your question directly, but rather to add a perspective
which you (or others who read your note) may not be considering, but should:

We chose the name FUTURE-COMMON-LISP (and did not make a short name for it)
deliberately in order to make it hard to type--because we knew that
neither the language nor our implementation had stabilized enough for us
to document them, and we were afraid that people would `notice' their
presence and attempt to prematurely convert without properly
understanding what it was that they were converting to.

The draft ANSI specification continues to evolve, and a public draft
version is not even available.  Guy Steele's CLtL2 is a snapshot of work
in progress toward that draft, but is not officially sanctioned by X3J13
in any way.  It is, by Guy's own admission, superficial in some
treatments, buggy in others, and in some cases already out of date even
on things about which it was correct at the time it went to press.  The
future is a moving target, so even if we professed to have implemented
FUTURE-COMMON-LISP correctly for one release, it might have to change in
a subsequent release.

Also, our implementation continues to evolve.  We made for ourselves a
stub version of the new dialect by filling in parts from SCL.  As more
parts of the real implementation are filled in, the two dialects may
seem more different.  (Genera 8.1 will have many more differences
between the two dialects than Genera 8.0 did, for example.)  We are
-not- encouraging Genera 8.0 customers to do a conversion to this
dialect because we are not supporting the package as a whole at this
time.  CLOS is documented and supported.  FUTURE-COMMON-LISP:SETF, which
was pretty much needed in for proper integration with CLOS, is also
documented and also supported.

Note also that traditionally our Release Notes only document incompatible
changes to software which was previously released.  We do not in general
attempt to document changes to things which were never intended to be used
in the first place.  As such, if you convert prematurely, their is a fair
likelihood that you will suddenly find that your code `breaks' without 
warning when you receive Genera 8.1 because you might not be anticipating
some change that was essential to making FUTURE-COMMON-LISP come in line
with the emerging ANSI spec, but which was not expected to have been 
already receiving use.

We admit the possibility that some users may have legitimate reasons for
converting early to FUTURE-COMMON-LISP, but they do so fully at their own
risk.  Problems due to using undocumented code which turns out not to work,
or due to finding that such undocumented code changes in behavior from 
release to release are beyond the scope of things for which we can accept
responsibility.  Obviously, this isn't a threat that things will change 
utterly at random.  There are those who may be able to accept these risks,
and who may find it beneficial to do so--especially people who are in very
close touch with the standards process, have a lot of time to debug things
when they go wrong, don't mind if a new release perturbs things a bit, etc.
But please don't go into this without clearly understanding the risks.

This message has taken a necessarily conservative stance for reasons I
hope you'll appreciate, in direct reaction to your suggestion of
"prematurely" attempting a transition.  That's really the operative word
and I wanted to make sure you understand the implications of it.
It's always possible, of course, that the Release Notes for some
future release (i.e., 8.1 or later) will be able to say something more
encouraging about some of these things... So stay tuned.