[Oberon] Modula2 vs Oberon IMPORT

[Bob Walkden]

> Yes! I realized that about qualified IMPORTs - after all, the entire
> Module is referenced in the IMPORT statement. Qualified imports simply
> allow you to use procedures with the same name, as I understand it.
> 

You could not IMPORT P FROM M0, P FROM M1. You would have to IMPORT M0, M1;
and refer to M0.P and M1.P as appropriate.

> > With Oberon the components are loaded and unloaded on demand or by
> the
> > garbage collector. In this case qualified import would just be a way
> of
> > avoiding writing the full module name. Oberon gives you a different
> way of
> > obscuring your code by using the rename feature, eg IMPORT Prolixity
> := P;
> > [...] P.Obfuscate; [...].
> 
> Yes! Nikitin calls this "aliasing" in his book. Would you explain what
> you mean by, "components are loaded and unloaded on demand or by the
> > garbage collector." I'm not seeing how that fits in the topic.
> 

An Oberon system loads components on demand. In other words, they are
dynamically linked rather than statically linked. Under program control you
can unload them, or the garbage collector will unload them when they are no
longer needed.

The Modula-2 language report doesn't mention anything about static or
dynamic linking as far as I can see in a quick scan. Most M2 implementations
that I have used (all on DOS) linked statically. In other words, there was a
'make' step which produced a self-contained executable.

> > Component Pascal goes even further and lets you ignore part of the
> module
> > name. eg IMPORT StdLog; [....]; Log.Write( ...
> 
> My concern is this - if a "main" Module IMPORTS 10 "slave" Modules,
> but uses only (e.g.) one procedure from each, then the code bloat in
> the final executable would be absurd, would it not? 

It depends on the size of the imported modules, but in principle it could
be. However, this is not a question of language design or specifically the
design of the IMPORT statement. Neither static nor dynamic linking implies
anything about whether the whole module is loaded (and later unloaded) or
just those parts that are immediately required. It is a matter for the
designer of the compiler and the operating system's loader / linker.

A C compiler could be just as smart or as dumb in its treatment of an
#include as an Oberon compiler could be in its treatment of an IMPORT.

> I might as well
> cut-n-paste the code into the "main" module, and re-use the code that
> way. 

That would be a bad idea (or possibly a good idea if you wanted long-term
employment maintaining buggy code). When you found a bug in the copied code
you would have to change it in every source file, rather than in one place
and recompile / relink. In a system which supports dynamic loading and
unloading you just recompile the now bug-free software and recycle it.

> Maybe this something a "peephole optimizer" could do?

Optimising is a different matter. An optimiser should eliminate dead code,
of course, if the programmer is foolish enough to write it, but again that
is nothing to do with the language design. Of course, if an optimiser can
recognise it and clean it up, a compiler should be able to recognise it,
tell the programmer about it, and not generate it.

B