Fri Aug 20 05:53:50 EDT 2004
I have to read carefully the module of MzScheme before I can have a strong
opinion. Just one remark about the following:
> * How are modules identified? Possibilities include by name and
> by normalized pathname. (I prefer by name with the pathname being
> advisory---information about where to find the module if it isn't
> already loaded. I believe that Matthew prefers by normalized
> pathname, which is what MzScheme currently does.)
I'm not sure to understand the two proposals here. However, let me give
my (humble) opinion. I *HATE* the Java binding from class name to a file.
This unfortunate binding is probably the main reason why I definitely refuse
to program with Java. You never know where (in which directory) you have to
run the compiler, you never know were you have to run the Java vm. In addition,
it is a nightmare if you want to re-organize the files that belongs to a
In Bigloo I have adopted (a long time before Java) a different strategy.
1- In a import clause, the imported may refer to a module by its identifier
or by its identifier *and* the file (in the OS sense) containing the module.
2- Alternatively, an external table (i.e. a assoc list) enables the compiler
to discover where modules are stored.
For instance imagine a module m1 stored in file proj/dir1/f1 and a module m2
stored in proj/dir2/f2. If you want to compile from the directory proj, you
have to produce a table such as:
((m1 "dir1/f1") (m2 "dir2/f2"))
and run the compiler with this table.
Of course it is straightforward to automate the generation of such tables.
More information about the R6RS