This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Translators/source language detection
- To: Jim Blandy <jimb at red-bean dot com>
- Subject: Re: Translators/source language detection
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 21 Feb 2000 09:32:03 +0100
- Cc: bickiia at earlham dot edu, guile at sourceware dot cygnus dot com
- References: <200001241859.NAA24652@earlham.edu> <m3zosv5x9y.fsf@savonarola.red-bean.com>
Jim Blandy <jimb@red-bean.com> writes:
> So I think Guile should have a function (generic-load "FOO"), that
> tries different extensions
I think this is not general enough. When the loader finds "foo.so",
how should the module system find out which services foo.so offers? I
I think that every foreign language file should be accompanied by a .scm
file which describes foo's interface. (See my other mail to Ian).
The module loader should only open .scm files. These .scm files must
do whatever is necessary to deal with the foreign language files (load
the shared library and register wrapper functions, initialize a
tcl->scheme/elips->scheme interpreter and register wrapper functions
etc.).
I wouldn't call it "generic-load", because load suggests that the code
is loaded into the current environment. I think "open" or
"generic-open" is better.
> Why not just redefine `load'? Because R5RS says that it loads Scheme
> expressions from the named file.
R5RS "load" sucks anyway :> as it doesn't have a environment
parameter. load is only useful for loading code into the current
"interaction-environment". Richard Kelsey says that it is optional
and only there for backward compatibility. It will definitely not
work in a module context---if you load code from one module the code
will show up in the current interaction-environment, not in the
module's eval-environment.
Jost