Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!gatech!lll-lcc!well!jjacobs
From: jjacobs@well.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <2606@well.UUCP>
Date: Wed, 18-Feb-87 02:36:17 EST
Article-I.D.: well.2606
Posted: Wed Feb 18 02:36:17 1987
Date-Received: Thu, 19-Feb-87 06:47:32 EST
References: <2601@well.UUCP> <2603@well.UUCP>
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 71


In <1138@spice.cs.cmu.edu> Rob MacLachlan

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

There are two possibilities here; 1. The implementation allows
the "i" to be set, as in some other, older languages, or 2.
the disclaimer can be made in English.  "Result is undefined"
is a valid specification; not specifying things is a different
animal.

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

I see; as long as the result of (RPLACA X Y) is any CONS cell with
the CAR set to Y and the CDR the same as before, then this is
ok!!!!

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

See the InterLISP manual, and others.

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

I've seen enough spec's in my time to know that making those kinds
of assumptions is deadly.  Further, that is nearly the
definition of a bad specification!

>Completeness of specification certainly doesn't seem to predict language
>success.  Consider Algol 68 and C.

C isn't successful??????

>  Rob

 Jeffrey M. Jacobs
 CONSART Systems Inc.
 Technical and Managerial Consultants
 P.O. Box 3016, Manhattan Beach, CA 90266
 (213)376-3802
 CIS:75076,2603
 BIX:jeffjacobs
 USENET: jjacobs@well.UUCP