Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!defun.utah.edu!shebs
From: shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs)
Newsgroups: comp.lang.lisp
Subject: Re: Correctness (was Re: Common Lisp lacks portability)
Message-ID: <5179X@utah-cs.UUCP>
Date: 21 Jan 88 00:00:00 GMT
References: <1421@orstcs.CS.ORST.EDU> <233@spt.entity.com> <2126@ulowell.cs.ulowell.edu> <5208@sol.ARPA> <1547@orstcs.CS.ORST.EDU>
Sender: news@utah-cs.UUCP
Reply-To: shebs%defun.utah.edu.UUCP@utah-cs.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 50

In article <1547@orstcs.CS.ORST.EDU> ruffwork@CS.ORST.EDU (Ritchey Ruff) writes:

>	A correct program is one that -
>		- has a specification of correct behavour for both
>		  correct *and* *incorrect* input;
>		- will give the correct output for *ANY* possible input
>		  (using above specifiaction for validation).
>
>This means -
>	(1) common lisp IS correct (it is following its definition ;-), but
>	(2) it makes it VERY hard for programmers to write "portable"
>	    correct code because Steele et.al. underspecified the
>	    definition of the language.  You are FORCED to either use
>	    a subset of the whole language or validate it on every
>	    CL implementation  (and even version) you will run it on.
>
>This get right back to my original conclusion - *IF* you follow
>my definition of "correct", *AND* you want to have "portable" code,
>YOU CAN'T USE STATEMENTS THAT EFFECT THE SEMANTICS OF THE PROGRAM 
>BUT THAT CAN BE IGNORED because then (by definition) you will not have
>a program that you can be sure is "correct" when running under CL
>implementations that you have not validated it on.  *This* was my
>original gripe!

In other words, you want a language definition that requires all
implementations to detect mistakes in the program.  Presumably you're
going to be generous and not require that implementations detect
infinite loops that are due, say, to misuse of counters...  Even
given that,  there are other situations, such as memory exhaustion,
that a system is unlikely to deal with gracefully.  Getting back to
type declarations, it's surely unreasonable to expect a Common Lisp
system to take an expression like

	(the fixnum (+ (the fixnum x) (the fixnum y))

and analyze all the possible values for x and y to make sure that their
sum doesn't exceed the range of fixnums.  The only truly safe choice for
the compiler is to not opencode the addition, but of course that defeats
the whole purpose of declarations.  Instead, the CL spec says that this
sort of thing "is an error", and implementations are free to do anything
up to and including the erasure of your home directory :-) if the program
causes such an error.  The alternative is Lisp system performance that you
would not like at all...

Lower-level languages like Pascal can be more portable because they are
more restrictive and can therefore be statically checked better.

I'd say that although you do have something to gripe about, it comes with
the territory, and you should plan to acquire lots of CL implementations
if you want to write portable code... 1/2 :-)