Les Tyrrell wrote:

> Actually, I think I need to be more clear about what I have reservations
> about.

You actually were quite clear the first time. But I addressed these points
with my 'parameterized modules' clarification (sorry for forgetting to
proofread parts of it). I am a little surprised that your response doesn't
mention it, however.

> I am primarily concerned with Modules being given the responsibility of
> knowing explicitly which other modules they are working with.

Let's not reinvent the wheel: It all comes down to interface vs
implementation. We do not use knowledge of the internals of other pieces,
but we do know and use their interfaces. Submodules are (by definition) part
of a module's implementation, like methods and instvars are part of a class
definition. Imports/parameters refer only to the interfaces of others (which
includes their name and their exports), and these are used in the
implementation.

Actually, to me its seems you are suggesting that the implementation of one
module should not know about the _interface_ of another module, which is an
added, non-standard part of this. It is however handled by module
parameters.

On the inside of a parameterized module, you may use parameter names and not
know about the bindings of those names, which are provided when you
instantiate a method/module/whatever. If you want every foreign name used in
a module to be a declared parameter in the module interface, fine. But that
would break the ability to ignore modularity and work in the good ol' way as
per Dan's proposal. I would greatly prefer if you could provide module names
without using parameters as well, since it is done in the interface anyway.
This is how it is done elsewhere.

> Modules are independent entities with no knowledge of the internals of other
> modules, Backplanes are the means by which modules are "bound" together,
> modules can plug into Backplanes, and Backplanes can themselves plug into
> "super" Backplanes.

Is this like clusters and packages? But note that the module-savvy
programming languages that are considered elegant don't make this
separation. They use interface and implementation, which is a well-known
idea, and which is exactly like how methods/procedures/functions work. A
reason for my choice of parameterized modules was just this close
similarity. 

Clusters and packages, modules and backplanes, blorfs and schwungs. ;-)
Interface and implementation already does it, and this pair is a core idea
of OO already. I have already stated the analogy between method parameters
and internals on one hand and module parameters and internals on the other.
It should be obvious that both are examples of interface vs. implementation,
and that module parameters therefore are a natural extension of this
concept. 

> Whether the above scheme will do this, or Henrik's cannot do this,
> I cannot guarantee, but this is a characteristic which I feel will be
> strongly desireable.

We can safely guarantee that interface vs. implementation, and parameterized
modules, work. Others have already proven that. This is part of why I like
them. I am not aware of any similar demonstrations for blorfs and schwungs,
however.

In case anyone wonders, the formal reference for parameterized modules is
J.A. Goguen, "Reusing and Interconnecting Software Components", IEEE
Computer, February 1986 (thank you Google). However it is far more technical
and ambitous than what we need here, and I don't really think it informs the
present discussion much.

One thing from the paper that one could easily do is to have code that
validates module configurations (ie. the parameters that we pass to a
module). "Is this a Transcript which I see before me?"

Having PM's would give Squeak certain technical bragging rights over other
languages. Some people tend to like such things. "My language is bigger than
yours, nya!" But it should be the other way round, right? ;)

Henrik