Hi Henrik,

> Some module updates, tested with Squeak3.3a-4857. Please test 
> these and give some feedback before rolling them into the updates:

I've looked at the changes and I have a couple of questions. Not that
the changes are broken (except one issue, see below), I just don't
understand the reasoning behind them.

> makeVMConstrReloadable, which refactors VMConstruction to be 
> reloadable after being unloaded.

There's a gotcha here. I posted the VMMaker updates recently (couple of
days back; they're not relayed to the public update stream yet) and I am
not to 100% certain if they might introduce a few more (or different)
dependencies since some of the translation interfaces have changed.
What's a way of finding out?! I noticed that you changed
FXBltSimulator>>translate:doInlining: which has gone away with VMMaker
but I don't know about any others.

Also, and this is the thing I don't understand, you've changed in
various places the references to globals residing in the same module by
a Module @ #(Foo Bar Mumble) reference (for instance refs to Interpreter
in InterpreterSupportCode and refs to FXBltSimulation in
FXBltSimulator).
Why is this necessary for a module in order to be unloaded and loaded
again? Does this mean we have to qualify every reference to a global
explicitly?! If not, what are the rules when and where explicit
references are required?!

> fixChessPool converts the chess pool to a module to remove 
> various problems.

Talking about pools - is there any anticipated way of dealing with the
issue of providing a module through initialization code?! The question
is basically, what do you do if you want to provide a (single) file in
which should contain the appropriated definitions?! Reviewing the
information on the Swiki it says that you have to convert pools into
pool modules and describes how to do that in ModuleRefactorer but what
about people who need some _new_ shared constants?! ;-)

Also, (and that's not directly to you but to anyone working in this
area) has there any progress been made on the front of providing an
understandable user model and programmer interface for modules?! Since
two (for me important) convenient and expressive features have gone
(system organization and pools) I feel more and more pressed to get
something back that's a little more convenient than having to write
Module @ (Foo Bar) for any global reference (see question above) or to
write "module externalModule: moduleOrPath alias: aliasOrNil version:
versionOrNil importNames: shouldImport" for importing the symbols of
another module (if that's what it does ;-)

In short, most of the documentation on the Swiki is of highly technical
nature and I am really missing something that states the five typical
tasks that most people want to do with modules and how to solve them in
the most straightforward way possible. Here's my list of things I want
to do (if you have any others add to them so we can make a TODO list out
of it):

[a] Have a straightforward way of importing, reviewing, and excluding a
(set of) modules and its definitions, visibly and in front of me for
both, classes and modules. Like when I want to use "Morphic" for some
application and don't want to care about what exactly this means (hey,
it's Morphic eh?!) or when I need the 3D engine in one specific class
but not the entire module.

[b] Have a way of defining, reviewing, and modifying the definitions
OTHER than classes defined in modules (like constants)

[c] Have the system provide a "current" module (equivalent to change
sets) tracking my modifications and automatically determine what
dependencies exist (based on the globals referenced) which delta modules
are required (based on method modifications) and what classes are
contained in the module (based on defined classes)

[d] Have a way of reviewing these automatically derived dependencies and
modify them if need be

None of the above seem to be really straightforward these days. Note
that [c] could be a really useful method to support users who don't know
(and don't want to know) about modules since if the system derives all
of the required (plus possibly a few unneeded) dependencies noone would
have to worry about "fixing" their code before they can store it into
the repository.

Cheers,
  - Andreas