On Sun, 13 May 2001, Tim Rowledge wrote:

> Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> is widely believed to
> have written:
>
>
> >  And I personally would love if the
> > generated module source code would be identical for internal/external
> > versions.
> Why? What benefit does it confer?  You still have to compile
> differently, you still have to recompile the vm as well as the 'moved'
> plugin.

Sure, but I save the "generate sources from Squeak" step. Apart from
that ...

I guess my aversion against that re-generation of code solely for
switching the compile mode between internal/external is just that: it
doesn't smell right. Probably I do not see the generated sources as just a
bunch of intermediate files. As long as we use separate tools for
Squeaking and for VM hacking, the generated files have a value of their
own. Heck, they even come in the source code download and ar in the src/
directory!

For example, when we use CVS for the sources (which I still believe is a
good idea), the permanent re-generation trashes the revision history. An
actual code change in a module is almost indistinguishable from a change
introduced by changing the compile mode.

Actually, I'm fine with the module mechanism as it is now.  What I really
want are generated source files that only change when some Smalltalk code
was changed. This could as well be achieved within the current scheme by a
little macro magic, like the one for platform.exports. What would speak
against this?

The other concern is that it's still possible to call system functions
from any module in Linux. There seems to be no way to restrict the list of
exported functions for the VM itself ot the external modules. If noone
can come up with a way that removes these unwanted exports, the only
solution I can think of is to have a per-module table of functions allowed
to be called.

-- Bert