[Jscheme-user] Re: JScheme in Red Hat 9

[Ken A. <kan...@bb...>]

At 12:16 AM 1/16/2004 -0500, Aubrey Jaffer wrote:
>Having #null distinct from #f has caused 3 errors in jscheme.init.
>What purpose does having #null different from '(), #t, and #f serve?

The short answer is this we chose to distinquish #null from '() or #f so we could distinguish between them, though i don't think the argument was strong either way. I agree that checking for #null is annoying,  but what are you actually proposing?

Here are the usages of #null that i see:

(define (getenv path)
  (define prop (System.getProperty path))
  (and (not (eq? prop #null)) prop))  


          (and (or (slib.zip-on-classpath?)
                   (not eq? (Scheme.openResource "slib/require.scm") #null)) 
               "slib/")

(define (file-exists? f) (not (eq? (Scheme.open f) #null)))

Since Scheme.openResource and Scheme.open are under our control, returning #f would be more convenient in Scheme.  But what should the type signature of the methods be in Java?  Currently they are InputPort methods(String).  So, currently #null is a potential return value.  Since opening something that could be a file, a resource or a URL is useful perhaps it should be a JScheme primitive that returns #f.  In fact, these procedures were only used in Java.  I generalized (load) and (call-with-input-file) to do this because i realized it made slib support and remote code sharing easier.

If we made #null the same as '() we'd still have to do a test in the conditionals above, but we'd have only one procedure (null?).

If you're proposing treating #null as #f in conditionals that might make some JScheme code cleaner.

k