Re: implied contracts in the mapping functions?

[Eric Benson <BENSON at SPA-NIMBUS>]

    Date: Thursday, 22 September 1983, 15:27-EDT
    From: Daniel L. Weinreb <DLW@SCRC-TENEX>
	Date: 19 Sep 83 16:07:49 EDT
	From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
	It is dangerous to have a feature that obviously ought to be in a
	language not be there, or be there in only half the implementations.  No
	matter what you say in the manual, people will use it where it works.

    I strongly disagree.  It is completely unavoidable that some people will
    depend on the peculiarities of any implementation.  It does not follow
    that every peculiarity should be a defined part of Common Lisp that
    every implementation must follow.  If we are to belive what you are
    saying, then EVERY place in the manual that says "it is an error" should
    be changed to either say "it signals an error" or else be precisely
    defined.

And of course that's only the beginning.  The only way to ensure that
every implementation has exactly the same behavior is to define a very
low-level virtual machine and write the entire system in terms of it.
Then there would truly be one Common Lisp, and any program which ran on
one version would run on any other.  This is how UCSD Pascal is defined,
for example.  Programs can be compiled on Z80's and run on 6502's.  This
is not the goal of the Common Lisp language definition as I understand
it, however.  I believe the intention is similar to that of Standard
Lisp, to define an @i(interchange subset).  Programs which rely only on
the behavior described in the manual will run on any Common Lisp
implementation.  No machine can enforce the Common Lisp standard,
although automated tools can of course aid the programmer in adhering to
it.