[Oberon] Language and implementation

[Paul Reed]

Dear Srinivas,

> Regarding the dangling procedure variable,
> Is it a language issue?...or its implementation issue?
> ...Language said, modules can be imported.
> Imported modules can export procedure variables.
> Importers can assign Procedures to them.
> ...I feel, language did its own job, saying this much.
> It shouldn't go on to dictate when to load imported module,
> when to load importer module, When to unload which one,
> whether to allow or disallow loading/unloading,
> and what is the consequence of loading/unloading etc...
>
> Or it should dictate all such things? (to guide implementation...)
> Where do we generally draw the lines?

I think you make a great point.

The language usually implies some abstractions which are simply
impossible for implementers, e.g. infinite stack size, infinite heap size,
infinite module space.

One thing which Prof. Wirth has repeatedly pointed out is how delicate
the language definition process is.  He tends deliberately to leave things
unsaid in order to leave freedom for implementers.  I think this is informed
by his experience as a language implementer, not just a language designer.

(Sometimes this goes a bit wrong - like the well-known lack of
"short-circuit" boolean operators in Pascal - and in the light of experience
is corrected.)

In the case of procedure variables pointing to module code which has been
unloaded, you could argue that an implementation should *re-load* the module,
maintaining the abstraction of an infinite module space (as it happens, a
kind of
higher-level version of the virtual memory idea), since this is how the
system
automatically loads missing code in the first place: on demand.

This could be done using thunks/trampolines as others have suggested - in
one implementation where I was particularly worried about this, I went to
some
effort to implement exactly that - and yet, it was never needed in practice.

So the main point I think is that it's necessary to be pragmatic,
implement what's
reasonable.  This will be different for different people, and at different
times.  In at
least one version of the original Ceres Oberon system, the book points out
that
the available and otherwise-unused hardware (the NS32032 processor's memory-
management unit) was used to detect these dangling procedure pointers,
because
that was relatively easy to do.  The book also admits it's not an ideal or
a general
solution.

Cheers,
Paul