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