Path: utzoo!utgpu!water!watmath!clyde!rutgers!orstcs!ruffwork From: ruffwork@orstcs.CS.ORST.EDU (Ritchey Ruff) Newsgroups: comp.lang.lisp Subject: Correctness (was Re: Common Lisp lacks portability) Message-ID: <1547@orstcs.CS.ORST.EDU> Date: 16 Dec 87 21:01:54 GMT References: <1421@orstcs.CS.ORST.EDU> <233@spt.entity.com> <2126@ulowell.cs.ulowell.edu> <5208@sol.ARPA> Reply-To: ruffwork@CS.ORST.EDU (Ritchey Ruff) Organization: Oregon State University - CS - Corvallis, Oregon Lines: 37 I think I see the basic point of dissent in this discussion (but when I posted the original I never thought it would come to this ;-). The main difference in opinion seems to be what we "feel" the definition of "A CORRECT PROGRAM" is, right? I tend to come from a software engineering viewpoint, so I'll make my bast stab at it - 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! Comments? (Just a sec while I don my welding goggles and gloves and my aspestos suit ;-) --ritchey ruff ruffwork@cs.orst.edu -or- "Lisp is the best way to ruffwork%cs.orst.edu@relay.cs.net -or- abuse a computer." -anon. { hp-pcd | tektronix }!orstcs!ruffwork