Nice taunts, Paul!

I've outlined my own ideas about modularity before, so instead of talking about the technology
( which would be better done with a web site ) I'm going to talk about what I actaully intend to
do about it.  Hopefully, this will be better than all the previous discussions where I've mentioned
all this before, but haven't gone very far with it.

First, what I am actually working on in a Squeak-specific sense: Formatting.
This is good becuase people want it, and because it gets me down into parts of
Squeak which I need to modify in order to do other things for the main interest,
Modularity.  It's also good because I'm actually working in Squeak, building the
infrastructure I'll need later, rather than working in VisualWorks, building things
that have to stand on that infrastructure.  The tie-in with Modularity comes in
the analysis of legacy source code- I need a visitor framework for my stuff to
work.  I need the analysis capability in order to work on schemes for automatic
extraction of the object interfaces, which I feel I need in order to do modules right.
I'll start putting together a web page for this so interested parties can get involved.

The mods I'm doing to support  formatting involve fairly substantial changes down
in the parser framework.  I'd appreciate hearing from others working on building
or modifying the parser framework, otherwise we're all going to step on each
other's toes.  In particular, Cragi Latta, you have mentioned that you are working
on this, and I am also aware of Hal Hildebrand's Loki work.  Loki is in many
ways siimilar to what I want, but not qute., and the change set that is available
bothers me in a few areas.  At this time I intend to stay somewhat with the existing
Squeak parser framework, but decompse it along lines similar to Loki.

Getting back to modules, the story on that is that I have code sketching out bits
of it, but my belief is that the modules are not the hard part.  Instead, dealing with
legacy code is, and that is why I am working on the analysis stuff, and why I need
the visitor framework for the parse nodes, and why I'm bothering with that and
doing the formatting to boot.  I know about Modular Smalltalk, from the original
publications as well as from a thesis on the topic, so I'll keep that in mind as I go.
If possible, I will try to get these documents along with my own scheme onto a single
web site for interested parites.

What I need out of the analysis stuff is the ability to find out what a given module
needs in order to work.  This includes named things, such as 'global' variables
( or, in the context of modules, externally defined variables and such ) and a specification
of what a given module expects out of the objects that enter and leave it.
The first is easier, and that is mostly working now.  The last part is the hard one, but I
have a start on that.

I'll work on writing out a better overview of the things I'm doing, and on getting
the web site up.  When this is ready, I'll send a message to the list.

les