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.