R-alpha: libraries, modules, namespaces, ...

[Luke Tierney]

> 
> Very cool!  Do you think that if we have modules, we should get rid of
> the `library' mechanism altogether?  
> 

Something along those lines is probably still needed. Right now
library/provide/require are an imperative mechanism that (a) makes
additions to the global name space (b) makes code available.

Making code available is, I think, better handled by a declarative
module mechanism that describes what depends on what but leaves the
system the freedom to actually load the relevant code when it needs
to, unloaded it if it isn't needed, etc. A declarative mechanism in
which DLL's are viewed as just a special kind of module or as
containers for such modules (native modules if you like) would also
make handling of DLL code a bit easier and cleaner.

But modifying the global name space at run time to make certain groups
of things available is still something you need to be able to do (you
can think of it as an interactive import directive). So some variant
of a library command is still needed, but provide/require's
functionality would be replaced by the declarative module
mechanism. (At least from a user's point of view -- the implementation
might still use the same mechanism internally. Also some back door for
explicitly loading a module/DLL and for unloading would still be
useful during debugging of new code but would usually not be needed
once code is stable).

There is also a granularity issue that might be worth considering.  S
libraries tend to be fairly coarse-grained. With a module mechanism I
would tend to want to subdivide many of these libraries into smaller
modules, but it would still be useful to be able to organize them into
library-sized chunks. One way to allow that would be to allow nested
modules. While that might be an elegant solution in some sense, I
suspect it is too complex. A better choice is probably to have a
two-tiered mechanism like packages/classes in Java, libraries/modules
in dylan with libraries just a loose way of grouping modules.

One drawback of handling modules by something like

mymodule <- module { ... }

is that it strongly suggests that modules can be nested, are first
class, etc. If that is the case, great. But if not it would cause
confusion. If a simpler notion of module is used, a convention that
makes limitations clear (like comment-based module specification, or a
file=module convention) might be better.

Lots of things to think about.

luke
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-