Re: [Jscheme-user] treating #null as #f in conditionals?

[Alan D. <ado...@cs...>]

On Thu, Nov 04, 2004 at 03:55:33PM -0500, Timothy John Hickey wrote:
> One problem with identifying #f and #null is that they have
> different semantics in Java and hence would create problems when
> calling Java methods/constructors etc.

> e.g. to create a Boolean array of size 4 and store two Boolean values 
> in it, we could use
> 
>   >   (define f (list->array Boolean.class  '( #f #t #null #null)))
> 
> But if #f and #null were identified, we would not be able to represent 
> #null
> 

I agree; I think it's much cleaner to keep #null distinct from #f.

I used to think that 'null' was simply the "absence of objects", but I
have recently come to think of it as an object in its own right,
albeit a special one on which method and field accesses all throw
exceptions, and which is a subclass of everything, an "instanceof" [*]
nothing, and is equal only to itself.

Here's a somewhat tangential explanation for that statement.  I'm
working on pointer analysis: it abstracts the value of an expression
by the set of object allocation sites it can point to.  Commonly, one
represents the null pointer by the empty set; however, this is not
always a good choice.  One application of pointer analysis is to prove
that an expression cannot point to 'null', so that a region of code
can be proven free of null-pointer exceptions (so one can optimise
away dynamic null checks).  In such an analysis, it is essential to
represent the null pointer as an explicit object; then, an empty
points-to set means that an expression has no value at all, not that
it is (or may be) null.

In this view of the world, #null should satisfy exactly the same set
of string?/list?/null? predicates as does any other instance of
java.lang.Object (which according to R4RS, is none, I suppose).

alan




[*] for "instanceof", read "non-null instance of a subclass of".