Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!macrakis
From: macrakis@harvard.ARPA (Stavros Macrakis)
Newsgroups: net.lang
Subject: Nil dereferencing protection
Message-ID: <346@harvard.ARPA>
Date: Wed, 30-Jan-85 21:23:15 EST
Article-I.D.: harvard.346
Posted: Wed Jan 30 21:23:15 1985
Date-Received: Sun, 3-Feb-85 02:08:45 EST
References: <2340@hplabsc.UUCP> <4948@utzoo.UUCP> <6292@boring.UUCP> <536@mako.UUCP> <338@harvard.ARPA> <6299@boring.UUCP>
Distribution: net
Organization: Aiken Comp. Lab., Harvard
Lines: 31
Xref: seismo net.lang:1385

> > > ...	> > ...
> The point is, that it is possible to define a language so that it is
> possible statically to guarantee that nil is never dereferenced.
> ...	-- Steven Pemberton, CWI, Amsterdam; steven@mcvax.

Yes, yes, agreed that you can do this, but only if there is no nil in
the ordinary sense (since you use the word `nil', presumably there must
be a nil!).  Instead, you use access types with no nil and some other
mechanism (such as a union type or variant record), or you use tricks
like circular lists (or is there some better way?).  In the first case,
the dynamic check for nil is replaced by a dynamic check for the right
variant (is that any different?); in the second, it is replaced by
obscure code (which is likely to replace dereferencing nil with
incorrectly terminating at the end of lists...!).  In any case, there is
runtime cost and runtime notification of the error, not compile time.

Perhaps unions or variants are cleaner than nil's, but they don't
eliminate the dynamic checks.  Dynamic checks are fine with me.

A more radical approach simply eliminates pointers altogether...and
relies instead on higher-level concepts--but let me not digress.

But I do fully agree with Pemberton's original point, that languages and
language tools should support the programmer as much as possible:  the
costs are surely negligible compared to the additional safety.

	-s

PS This whole chain of responses could presumably have been avoided if
Pemberton had been a bit less mysterious about his remark on static
checking.  (A stitch in time saves nine?)