🚀 go-pugleaf

cspw.quagga@p0.f4.n494.z5.fidonet.org (cspw quagga) writes:

[....]
> 
>I cannot see any mechanisms in Modula that would allow you to
>transparently 'break' one module into N fragments, while still
>allowing the user to believe that they are all part of the same module.

Oh yes, all you have to do is to introduce a new ``level" of modules.
So, you original module with the procedures P1, P2, .. , Pn becomes
a module that imports the procedures P1, P2, .. , Pn from the 
*seperately compiled* modules M1, M2, .. , Mn. So, the original
module is reduced to consist of IMPORT statements and initialisation
code for the module global variables. SIMPLE AS THAT!

Remember that unqualified IMPORT is totally transparent, name-wise.

OK, it may not be ``transparant'', but it will work.

Even if some of the procedures depend on each other, the dependecy
will be resolved by the programmer (doing the relevant IMPORT in
the relevant M.. files), and by the linker, the traditional way.

The way to do it (in my humble opinion) is to generate a global
DEFINITION MODULE containg *all* module global vars. Write a
DEFINITION MODULE for all the M.. files (simply by copying the 
procedure declaration out, using an editor). Write a ``standard''
IMPORT section (a header) for each of the M.. files (simply importing all
the vars from the glbal DEFINTION MODULE). Write all the
IMPLEMENTATION modules M.. by 
	-1 copy out the standard header to a file
	-2 copy the procedure declaration and body 
	   into that file.
This shouldn't take too long, using a nice editor (not to mention macros..).
The effort should be smaller than that for writing a smart linker.. ;^)

	Jens

jensting@diku.dk is
Jens Tingleff MSc EE, Research Assistent at DIKU
	Institute of Computer Science, Copenhagen University
Snail mail: DIKU Universitetsparken 1 DK2100 KBH O