[Oberon] IMPORT Modules: why does order matter?

[Jörg]

Procedure variables are needed anyway (for handlers and call backs). Having them, you don‘t necessarily need the additional language feature „forward declaration“. Forward declaration can be seen as the static variant of the dynamic procedure variables.
Jörg

Am 03.03.2019 um 12:05 schrieb Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:

>> Maybe there *are* good use cases for forward declarations. So I am just saying
>> that I have never seen such cases yet.
> 
> Historically, only forward *references* (which can occur when a nested procedure
> Q calls a procedure P of a surrounding scope) were implemented in Experimental
> Oberon, but *not* forward *declarations* of procedures.
> 
> This was originally done to fix a bug in FPGA Oberon with nested procedures.
> The change actually made the compiler *shorter*.
> 
> Later, the original bug with nested procedure calls was fixed in a different way
> in the official FPGA Oberon system and published on www.projectoberon.com 
> 
> At that point, one could have undone the fix in Experimental Oberon as well. But it
> was decided to retain it - as it made nested procedure calls (slightly) more efficient.
> 
> Later, it was realized that *once* that mechanism is in place, forward *declarations*
> of procedures could be *also* be added back with practically no additional effort:
> with less than 10 lines of code .. much simpler than in the Ceres implementation.
> 
> Of course, just because a feature is easy to implement is a rather poor reason for
> doing so, but in the end it was decided to re-introduce forward references for 3 reasons:
> 
>  1. Direct procedure calls are more efficient than using procedure variables.
>  2. Legacy programs that contain forward references of procedures are now accepted again.
>  3. Introducing forward declarations of procedures added only about 10 lines of source code.
> 
> Whether forward declarations of procedures *should* be re-introduced into the Oberon
> language, can of course be debated. There are good reasons against them. Indeed, 
> they have been eliminated in the Oberon-07 language revision, the rationale being that
> they can always be eliminated from any program by an appropriate nesting or by introducing
> procedure variables (see section 2 of www.inf.ethz.ch/personal/wirth/Oberon/PortingOberon.pdf).
> 
> As with many features of Experimental Oberon, the main interest was to "just do the
> experiment” (either to further the education of the author or for some other reason..)
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon