[Oberon] Language and implementation

[Andreas Pirklbauer]

Paul,
You are making a very good point indeed. Language should not be burdened with all implementation details.Dangling pointers to unloaded modules are a good example. It should not be something that the language definition should be concerned about. And indeed, the Oberon *language* doesn’t - rightly so. Now, for the implementation of the Oberon *system*, there are at least two choices:

1) Don’t implement a mechanism such as “safe module unloading” or “automatic reloading” of modules, i.e. leave it up to the user to not break the system.

2) Implement it such mechanisms.

I would be interesting in hearing more about your perspective on what might be considered the best-practice approach. Although “safe module unloading” can easily be implemented (as shown in Experimental Oberon, where it is done with only a few dozen lines of code), I’m not sure it should be part of the Oberon core system.

On the other hand, having an Oberon *system* where the user can easily crash the OS merely by unloading modules seems incomplete. A kind of “safe software lifecycle” should be part of any system. Imagine and iPhone, which crashes simply because you unloaded an app.

Andreas

—————————————————————————————————————

Paul Reed paulreed at paddedcell.com  <mailto:oberon%40lists.inf.ethz.ch?Subject=Re:%20Re%3A%20%5BOberon%5D%20Language%20and%20implementation&In-Reply-To=%3C00e23e38971df5b005e58df8ca0c1aec.squirrel%40webmail.gradwell.com%3E>
Tue Oct 11 10:54:52 CEST 2016
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161011/469523de/attachment.html>