Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!ram
From: ram@spice.cs.cmu.edu.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1138@spice.cs.cmu.edu>
Date: Sun, 15-Feb-87 17:54:03 EST
Article-I.D.: spice.1138
Posted: Sun Feb 15 17:54:03 1987
Date-Received: Mon, 16-Feb-87 03:45:50 EST
References: <2581@well.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 42

Since some people may not have understood my claims for the desirability of
a standard not specifying everything, I will elaborate.

Consider the DOTIMES macro.  In CMU Common Lisp,
  (dotimes (i n) body) ==>

  (do ((i 0 (1+ i))
       (<gensym> n))
      ((>= i <gensym>))
    body)

Now, if Common Lisp required this implementation, it would imply that
setting "I" within the body is a meaningful thing to do.  Instead, Common
Lisp simply specifies in English what DOTIMES does, and then goes on to say
that the result of setting the loop index is undefined.  This allows the
implementation to assume that the loop index is not set, possibly increasing
efficiency.

The same sort of issues are present in the "destructive" functions, possibly
to a greater degree.  If an implementation was specified for NREVERSE, then
users could count on the argument being destructively modified in a
particular way.  This is bad, since the user doesn't need to know how the
argument is destroyed as long as properly he uses the result, and requiring
the argument to be modified in a particular way would have strong
interactions with highly implementation-dependent properties such as storage
management disciplines.  For example, in some implementations it might be
most efficient to make the "destructive" operations identical to the normal
operations, and not modify the argument at all.

In any case, the tremendous complexity of Common Lisp would make it very
difficult to specify it all in a formal way such as that used in the ADA
language specification.  When reading the Common Lisp manual, you must
assume that whenever the meaning of a construct is not explicitly specified,
it is undefined, and therefore erroneous.  

This difficulty of complete specification can be used as an argument against
complex languages such as Common Lisp, but you should remember that
specification is not an end in itself; languages exist to be used.
Completeness of specification certainly doesn't seem to predict language
success.  Consider Algol 68 and C.

  Rob