Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!ira.uka.de!fauern!tub!net
From: net@tub.UUCP (Oliver Laumann)
Newsgroups: comp.lang.scheme
Subject: Re: On the standard behavior of "load"
Message-ID: <1324@tub.UUCP>
Date: 8 May 90 10:51:50 GMT
References: <3601@jato.Jpl.Nasa.Gov>
Reply-To: net@tub.UUCP (Oliver Laumann)
Organization: Technical University of Berlin, Germany
Lines: 50

In article <3601@jato.Jpl.Nasa.Gov> brian@granite.Jpl.Nasa.Gov (Brian of ASTD-CP) writes:

> I would like to start a discussion concerning the Scheme essential
> procedure "load". The Scheme definition, R3.99RRS, states that the
> return value of "load" is unspecified. However, I think that "load"
> should have a specified return value [...]

I don't think "load" should have a return value which indicates success
or error.  When the file could not be opened or some other error condition
occurred, it should simply "signal an error" (whatever this means) like
all other primitive procedures do in case of an error condition.

After all, "write" doesn't return #f either when a write error occurred
(disk full or whatever).

In addition, Scheme implementations could provide an "(autoload 'foo)"
function which causes a file "foo.scm" or so to be loaded automatically
the next time the symbol foo is evaluated but not bound.  In this case one
wouldn't be able to test the return value of the call to "load" anyway.

I'm sure most Scheme implementations allow you to catch and handle an
error anyway, for instance by "hooking" into the "system error handler"
or by redefining the error handler.  In Elk, for instance, one can
easily write an equivalent to the Lisp "errset" which can be wrapped
around the call to "load" to test whether it failed.

> It is highly advantageous to maintain the modules separately from the
> clients. In particular, clients should not require knowledge of the
> directories modules reside in.  Clients should simply refer to modules
> by name, as in  (load-module "methods.sch")   [...]

> The implementation of load-module is simple. It searches a canonical
> list of module directories, using the return value of load to decide
> whether to continue or terminate the search.

I think this can be handled by the more general concept of a "load
path".  Some (many?) Scheme and Lisp implementations maintain a list
of directories that are searched for the file that is specified in
the call to "load".

In Elk, for instance, "load-path" is a variable bound in the initial
environment; the initial value is a list of directories where the
Scheme system files and extensions can be found plus the current
directory.  Applications can bind the "load-path" to a different
list of directories or add the directories where the applications'
modules reside.

--
    Oliver Laumann, Technical University of Berlin, Germany.
    pyramid!tub!net   net@TUB.BITNET   net@tub.cs.tu-berlin.de