Mon Apr 12 17:34:22 EDT 2004
I have no problem with the term "module". At this point I feel that
using another term will only **add** to the confusion. Anyway, we
should wait until we have a good understanding of what we are
specifying before we get too involved in finding a good name for it
(but in case we do depart from the term "module" let me suggest the
term "capsule" which is reminiscent of encapsulation).
My main issue with Matthew's proposal is that I don't understand how
the pieces of code (the modules) are put together to form a program.
This is a central issue because there are different kinds of
"programs" that should be possible:
1) standalone statically linked program (we know all of the
constituent modules at application build time)
2) dynamically linked program (we know some of the modules at
application build time and some others will be loaded at run time,
possibly more than once for debugging or hot code-upgrade reasons)
3) scripts (there is a single file containing the whole user program,
but some code may be in standard libraries, or libraries installed
by the user/administrator in some standard location)
4) REPL-style "program" where the user manually constructs the program
by entering code, loading files, and requesting evaluations.
I would like a module system that works well in all these situations.
What the strawman proposal specifies is a way to write pieces of code
(i.e. modules), but it is not clear how to glue these pieces of code
together to form a program.
More information about the R6RS