Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekchips!kend
From: kend@tekchips.LABS.TEK.COM (Ken Dickey)
Newsgroups: comp.lang.scheme
Subject: Re: On the standard behavior of "load"
Message-ID: <6149@tekcrl.LABS.TEK.COM>
Date: 7 May 90 21:53:51 GMT
References: <3601@jato.Jpl.Nasa.Gov>
Sender: news@tekcrl.LABS.TEK.COM
Reply-To: kend@tekchips.LABS.TEK.COM (Ken Dickey)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 45

In article <3601@jato.Jpl.Nasa.Gov> brian@granite.Jpl.Nasa.Gov (Brian of ASTD-CP) writes:
...
>With many implementations of Scheme, load returns
>#f when the file passed to it is not found, and #t
>otherwise. I think this ought to be the standard
>behavior of load.
...


It is certainly desireable to have a portably standard behavior here.
It is also somewhat difficult to achieve.

In some implementations of Scheme, load acts like BEGIN in that it
returns the last value of the storage loaded.  Aside from returning
some possibly useful value directly, I think that there are 2 kinds of
information which could be returned:
  [A] Was the file/object/whatever found or not.
  [B] Was the file/object/whatever successfully loaded, partially
loaded, or not loaded?

Once error conditions are considered, the question of what LOAD
returns becomes more complex--complex enough that there has not yet
evolved a concensus for a standard Scheme error system [I would
certainly like one!].  I believe that it will be difficult to resolve
the question of what LOAD should return in the absence of a standard
interface for failure/error handling.  What if there is no error
handling mechanism?  Also to be considered are behaviors which differ
in loading compiled vs source files.

Possibilities suggested:
  Have [possibly optional] success and failure continuations passed in,
  Call an `system' error handler in a specified way,
  Pass in a function to be called on error, 
  etc.  

Adding parameters, however, gets into parameter order and issues of
first-class environments and whether LOAD takes an environment
parameter.

Given that LOAD is very system dependent, the prudent approach is to
hide it abstractly away somewhere with other system dependent code.



-Ken