[Oberon] Language and implementation

[Srinivas Nayak]

Dear Paul,

Many thanks for your nice explanation.
This also shown me a new perspective with which we should consider languages;
that is of being an abstraction for infinite stack space, infinite module space...


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/

On 10/11/2016 02:24 PM, Paul Reed wrote:
> 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
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>