Path: utzoo!mnetor!uunet!husc6!bbn!rochester!PT.CS.CMU.EDU!WB1.CS.CMU.EDU!ram From: ram@WB1.CS.CMU.EDU (Rob MacLachlan) Newsgroups: comp.lang.lisp Subject: Re: Common Lisp lacks portability Message-ID: <523@PT.CS.CMU.EDU> Date: 15 Dec 87 19:48:03 GMT References: <1421@orstcs.CS.ORST.EDU> <233@spt.entity.com> <2126@ulowell.cs.ulowell.edu> Sender: netnews@PT.CS.CMU.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 71 Keywords: Common Lisp >Wrong. Crreeeeaaaak, sound of Common lisp tomb being opened yet again, Eeeeee-hah! What fun! Even MMister JJacobs has crawled back on the net, dragging his odious slime-trail behind him. But I won't lower myself by responding to his message. Instead I will flame about compilers and declarations in Common Lisp, which Common Lisp fans know is one of my favorite topics. First of all, I point out that Common Lisp is a standard for writing portable programs. It is possible to write programs that run in particular Common Lisp implementation, yet are not Common Lisp programs. The declaration mechanism in Common Lisp provides a way to make many interesting assertions about a program. As a special case, it allows programmers to make untrue assertions. There are a number of areas in which "Common Lisp the Langauge" is vague about what constitutes a correct Common Lisp program, but the aspect of type declarations currently under discussion is not one of them. I think the real complaint here is: "Common Lisp has features that support unsafe (and efficient) compilation." This is true, but it should be up to the programmer to decide whether he wants to risk unsafe compilation. This is why Common Lisp proves the OPTIMIZE declaration -- to allow the programmer to tell the compiler how to evaluate speed/space/safety/compilation-speed tradeoffs. In the abstract, the Common Lisp OPTIMIZE declaration provides better control over these tradeoffs than any other Lisp dialect I know of. Unfortunately, as realized by existing implementations, this capability is largely lacking. The most unfortunate property of existing Common Lisp compilers is their assumption that a type declaration implies the generation of unsafe code. There is nothing in Common Lisp that suggests this: it is merely an evil vestiage of traditional Lisp compilation. I believe that a Common Lisp compiler should have some mode in which it actually emits extra code to verify all type declarations. This is a policy decision, controlled by the OPTIMIZE declaration, and not an issue of language semantics. Even without full type checking, the Common Lisp programmer is no worse off than the programmer in any other dialect. He can avoid the risk of incorrect type assertions by not making any. The real reason that people flame about Common Lisp portability is a paradoxical one: Common Lisp is the first Lisp dialect that has been implemented many different times. People move their "Common Lisp" programs from one implementation to another, expecting them to run without a hitch. When they hit a snag, they snivel and whine. They never had this problem with XYZZYLisp (of course, it only ran on one machine). I won't argue that it is impossible (or even difficult) to come up with a Lisp dialect that makes it harder to write non-portable code. Type declarations are an obvious source of non-portability; they were included in Common Lisp because efficiency was also a major goal. If anyone has suggestions for ways to make Common Lisp more portable without serious adverse effects on other design goals, then we would be glad to hear them. It is not acceptable to either require declarations to be checked or to forbid declarations, since both would cause serious efficiency problems. Common Lisp can strongly suggest that the compiler offer a mode which does full type checking, but it would be inconsistent with the language design philosophy to require it. In Common Lisp terms, this is an "environment issue". A given implementation can do whatever it wants to help programmers write correct programs, but once written, these programs should run in an environment that implmements only the features described in the manual. Rob MacLachlan (ram@c.cs.cmu.edu) CMU Common Lisp -- Making the world safe for symbolic computing.