simple modules

[David Herman]

>> - a "module context" is a set of module instances
> 
> Please call this something else.

Okay.

> It is confusing for "context" to
> mean "execution context" and "module context" depending on the
> "context".  I've called this a "system of modules" or "sandbox of
> modules" in the past.

Well, a "module system" is a language construct that provides modules. I think "sandbox" sort of suggests more isolation than is necessarily provided. PLT Scheme uses the worst possible name for the concept (I won't even say what it is, it's so awful).

I'll think about alternatives and update the wiki.

>> Different module contexts may have different module ID resolvers, so for example it would be possible for host environments to provide a SecureESContext that didn't allow identifiers to resolve to the "filesystem" module or the "dom" module.
> 
> This verbiage implies black-listing.  It would be good to be clear
> that the object formerly known as a "module context" should be
> explicitly populated with a white-list of module instances for SES.

Okay; all I was saying was you could create any kind of restricted context you want, with whatever policies you want, in a security-oriented setting. But when there's a proposal please do inspect the verbiage.

> ...it should
> never be necessary to edit code to give a module, or a tree of
> modules, an alternate name.  That kind of coupling has wasted many
> days of my time, integrating disparate projects with tight linkage.


A mechanism for specifying modules through a level of indirection, like Allen was urging, should make these kinds of problems solvable.

Dave