goran.hultgren at bluefish.se asks:
> > i believe modules/modularity is the most important problem to be solved
> > in the squeak world, and i have been reading most postings regarding
> > this topic, but still do not buy into the proposed solutions.  i'm
> 
> what do you not buy into? just curious.

I don't buy in because no one is selling.  You and your collaborators
clearly have much more expertise in this area than I have, and you are
proceeding without design documentation that people like me can
understand.  I'm not complaining; just stating as fact that I don't yet
understand how the current effort will satisfy what I see as basic
requirements for Squeak modules.  

I know some of this has already been discussed in the group, so no need
to reply.  But if it helps, here are some basic stories for how I think
a module system should be used:

Sharing Objects: Peter begins with the Squeak-vN.M image, adds objects
to create functionality F that passes test suite F.test.  Peter
publishes this functionality as a module named F that is dependent only
on Squeak-vN.M.  Pat can use another Squeak-vN.M platform to locate
module F by name in a repository.  Squeak-vN.M can load module F from
the repository and immediatly run and pass the test suite F.test.

Dependencies: Pricilla can create module G passing tests G.test, that
depends on F.  Pat can start again with a fresh Squeak-vN.M image and
load module G.  Module F and any other dependencies may be loaded
automatically.  Pat may run G.test immediately after the load of module
G completes and the test suite will pass.

Evolution: Pam may change the interface semantics of F and publish the
changes as F-v2.0 (She cannot publish with a version number that is
already taken).  Paul may create a new module H passing tests H.test,
that depends on F-v2.0.  Pat can; with the same image that runs G.test
with modules F and G; load module H and successfully run H.test.  The
required module F-v2.0 will be loaded automatically and execute without
conflict with the earlier version.

Shrinking: Peter begins with a Squeak-vN.M image and wants to shrink the
image by unloading all modules not needed to execute a given test suite.
 The system is able to mark all modules required by the test suite and
unload all others automatically.

Growing: Pat is able to begin with a tiny Squeak image that is able to
do little more than evaluate small talk expressions from an input stream
and load modules from the network.  From this image, she can input an
expression to send a #start message to an object defined in an arbitrary
module.  The system can locate and load the module by name, instantiate
the object and send the message.  Code in the module may, in turn, refer
to other objects in other modules that are loaded in similar fashion.

The questions this set of requirements raises for the current module
design (as I read it at http://minnow.cc.gatech.edu/squeak/2247) include
the following:

1. We are not allowed to have a module with arbitrary objects?  Can we
have a module that includes just an Array of Form instances?
2. Is it too much burden for the programmer to indicate dependencies? 
The example at http://minnow.cc.gatech.edu/squeak/2449 implies that the
programmer must search for dependencies and document them.  Why can't
the programmer just 'import' the modules they choose and let exceptions
be raised if they type a global name that cannot be found?
3. Will we be able to lazily load modules so that dependencies are
resolved only if that code path is actually executed?  Are we able to
eagerly load modules so that execution will not be delayed by the need
to load more modules?
4. How small is the code needed to locate and load modules?  Is this
core small enough to allow Squeak to run in a light switch?

Richard