Re: reexport-from-module

[thi <ttn@mingle.glug.org>]

Jost Boekemeier writes:

 > > Both modules (A) and (C) now have access to that same variable, but
 > > through two differently named entries in two different obarrays.  So,
 > 
 > I don't think this is possible in a well designed module system.  The
 > current module system uses symbols that point to vcells (symbol/value
 > pairs).  This is simply wrong.  Lets assume the symbol `a' has the
 > value 12.  In the current module system `a' is a symbol bound to a
 > symbol with the name `a' which has the value 12: (a . (a . 12)).

I can see that it's simple, but why do you consider it wrong?  If
variables are first-class objects, they should be able to be passed
around and referenced by different symbols.  That variables also contain
a back-pointer to their original symbol is usually ignored (at least, I
ignore it).

 > But this is *not* the reason why I think re-naming of symbols is not
 > part of a normal module operation.  A module system has to make sure
 > that all symbols are different from each other.  That means that a
 > module system has to group related symbols and must qualify each of
 > them.

What do you mean by group?  What do you mean by qualify?

A module system's main job is to associate a reference (symbol in some
usage context) to some object somewhere, w/ usage context including
things like "current" name space and whether or not the particular
object is fluid.  All symbols are in fact different from each other, but
only in name.  The underlying objects that the symbols reference can be
the same, whether they live in this module or another.

So, module systems must take into account inter-module issues, or their
users will take care of it (like I have).  A well-designed module system
should not prevent this kind of stuff, IMO.

 > Repeated inheritance and feature renaming (what you call "renaming
 > and re-exporting") comes into play, when you design the object
 > system.

It seems to me that Scheme already has an object system: namely, most
everything is an object.  This object system is pretty minimal and so
features like inheritance are not included.  The module system is then
layered on top of that to provide name resolution procedures for all
these objects.

A more "mainstream" object system w/ inheritance can be built on top of
the module system, as you've noted.  Looks like the order of complexity
is primitive-object-system, primitive-module-system, meta-object-system.
After awhile, anything can be built on top of anything. :->

thi