Path: utzoo!mnetor!uunet!husc6!necntc!dandelion!ulowell!ross From: ross@ulowell.cs.ulowell.edu (Ross Miller) Newsgroups: comp.lang.lisp Subject: Re: Common Lisp lacks portability Message-ID: <2126@ulowell.cs.ulowell.edu> Date: 14 Dec 87 20:19:16 GMT References: <1421@orstcs.CS.ORST.EDU> <233@spt.entity.com> Reply-To: ross@swan.cs.ulowell.edu (Ross Miller) Organization: University of Lowell, Computer Science Dept. Lines: 50 Keywords: Common Lisp In article <233@spt.entity.com> gz@spt.entity.com (Gail Zacharias) writes: >Common Lisp does provide a number of ways to portably request type checking >at run time, such as CHECK-TYPE and ASSERT, etc. But it doesn't specify the >behavior of incorrect programs (such as programs in which declarations are >false). Basically, the debugging environment is up to the implementation. I >don't think that's a major shortcoming of the Common Lisp standard. The >important thing is that once your program is debugged, it should run in any >Common Lisp implementation. Wrong. Crreeeeaaaak, sound of Common lisp tomb being opened yet again, I have read and read, and reread that section looking for a way out. An implementation is free to ignore type checking and not return any errors, but it must except the code that declares type checking. That is not a quote, but it is the jist. Here is a case where a program could be perfectly debugged and still fail. What if we had an implemenation of GKS for lisp. This is being worked on by X3H3.4 of ANSI. The lisp is actually an interface to another language that the GKS is really written in. The GKS is perfect passes all the test suites etc. But now an application programmer sits down to actually use this beast. By accident he sends a float to polyline when an integer was expected. Lisp then passes the 32bit word down to say C, machine size may vary, and C blithly trys to write out a few million polylines, or some other random number or worse a negative array reference, and the OS informs us of an array overflow. Please keep in mind the actual error could vary greatly depending on what the final GKS spec looks like and what the implentation actually does but you get the idea. If the GKS is actually implemented in lisp, then lisp will return an error eventually from such garbage being passed to it, and again the applications programmer is going to have to intuitivly figure out what is wrong. Worse, nothing is wrong the GKS is perfect only his program is wrong but he will get errors unrelated to what is wrong because data with garbage types will be being passed around. In fact the resolution of the committee was garbage in garbage out. An implentation is free to check the types manually upon invokation of the function but is not required to do so. This was resolved so that code could continue to be portable across GKS applications in different lisps. On another subject have I missed the argument on why arrays are not always passed by value? Ross -- csnet: ross@ulowell.cs.ulowell.edu uucp: ross@ulowell.cs.ulowell.edu || ...harvard!ulowell!ross Trust the computer. The computer is your friend.