[plt-scheme] dynamic-require error message

At Tue, 13 Mar 2007 21:59:37 +0000, "Paulo J. Matos" wrote:
> In case dynamic-require is passed a symbol which is not provided by
> the module the exn:fail:contract is raised (from the docs). However,
> nothing is said when the path to the file doesn't exist.
> If I try that I get an error from open-input-file.
> It would be nicer to have the error mention dynamic-require and if
> possible, have an exception thrown.

An exception is thrown, but the error message in DrScheme does say
`open-input-file' instead of `dynamic-wind'. In plain MzScheme, the
message says `default-load-handler' instead of `open-input-file'.

Here's what happens in MzScheme: `dynamic-require' has to call the
module name resolver. The module name resolver sometimes calls, in
turn, the load handler. If the file doesn't exist, an exception is
raised at that point, but the load handler doesn't know that it's
working on behalf of `dynamic-require'. So the error message says that
it comes from `default-load-handler'.

In DrScheme, the installed load handler is different, and it
effectively adds a layer, so that the error is reported from
`open-input-file'.


Of course, even if `dynamic-require' knew that name resolution would
trigger loading a file, simply checking for the file's existence
wouldn't help much. The file might be ill-formed, or it might even
disappear before it could be loaded. The exception really has to
originate from the load handler.


This problem shows up a lot, and we don't have a general and convenient
solution that has an acceptably low overhead.


One general solution is to catch any exception in `dynamic-require' and
then re-raise it with a message that mentions `dynamic-require'. That's
tedious for the `dynamic-require' implementor, though, and if the
strategy were applied consistently, it would mean a lot of new code to
catch and re-raise exceptions. (In this particular case, the exception
would also be caught and re-raised by the module name resolver. In
DrScheme, the exception one would caught and re-raised by yet one more
layer.)

Further, suppose you import `dynamic-require' with the local name
`go-get-it'. Shouldn't the error message say `go-get-it', instead of
`dynamic-require'? We know one way to implement this (analogous to
contracts), but it's expensive.


So, ideas are welcome. It looks like a thesis topic to me.

Matthew