Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!rochester!quiroz
From: quiroz@cs.rochester.edu (Cesar Quiroz)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp lacks portability
Message-ID: <4985@sol.ARPA>
Date: Tue, 8-Dec-87 14:29:11 EST
Article-I.D.: sol.4985
Posted: Tue Dec  8 14:29:11 1987
Date-Received: Sun, 13-Dec-87 06:41:21 EST
References: <1421@orstcs.CS.ORST.EDU>
Reply-To: quiroz@ROCHESTER.UUCP (Cesar Quiroz)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 45
Summary: Cannot argue about buggy code.  Declarations are still valuable.

Expires:

Sender:

Followup-To:


(Context:  Ritchey Buff complains about the freedom given to the
implementors to ignore certain elements of the language
(declarations) without any warning to the user.)

First of all, I agree that each implementation should tell you which
declarations are ignored and how the used ones affect your code.  (I
know of at least one implementation where declarations may slow down
correct code.)  Indeed, all the implementations I know of at least
try, so I don't see why the language specification is in fault.  You
need the info to decide on efficiency matters, but the info is often
provided anyway.

What prompts me to follow-up is the conclusion of the article.
Notice carefully that you cannot demand that any implementation tag
arbitrarily *incorrect* code.  You can, however, compare the quality
of the attempt: If an implementation catches more errors than other,
the first one is probably the one you desire most.

So one cannot build an argument around *incorrect* code.  (Your
subject line should have been `Incorrect Common Lisp code lacks
portability'.  We suspected that much long ago.)  Your example was
just wrong, the fact that one implementation missed it is
unfortunate and, at most, reflects on that implementation.  And
without the declarations, none of the implementations you tested
would have given you any error message.  The conclusion should be
the opposite: if you can, provide more declarations as you improve
your code.  High quality implementations may use that information to
help you debug, lesser ones should still do something useful when
your code is correct.  What you propose is that, because some
implementations cannot catch some errors, we should avoid
discovering those bugs in all the implementations.

To sum: Declarations can affect (perhaps negatively!) the efficiency
of correct code, but never make a correct program incorrect.
Declarations do not make incorrect code correct.  The behavior of
incorrect code (other than some error reporting when it is
explicitly guaranteed that `an error is signalled') is, of course,
undefined and well up to the implementation.  And decent
implementations document the decisions left up to them.


-- 
Cesar Augusto  Quiroz Gonzalez
Department of Computer Science     ...allegra!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@cs.rochester.edu