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.