[Oberon] Should hidden re-imports be able to coexist with identifiers

[Andreas Pirklbauer]

Ok, so before I respond to more emails on this topic off-forum, I have now
uploaded the various variants (some have been suggested by others) to
implement the compiler’s import handler to:

  https://github.com/andreaspirklbauer/Oberon-module-imports

Variant1 (ORB1.Mod):

  - "conflict with re-import" if a module M is first re-imported, and then M is used as an alias

  - "conflict with alias" if M is first used as an alias name, and then module M is re-imported

  - "invalid import order" if a module M is first re-imported and then explicitly imported

Variant 2 (ORB2.Mod):

  - hidden re-imports can peacefully coexist with aliases

  - "invalid import order" if a module M is first re-imported and then explicitly imported

Variant (ORB3.Mod):

  - no more restrictions at all, i.e. can import modules in *any* order.


* * *


All of these variants differ only by a few lines of code (i.e. zero cost, and there is
no need for module anchors or GModtab's, etc as in Griesermer’s approach).

It’s now a matter of taste which variant to pick. Personally I’m currently (but that
may change) leaning towards variant ORB2, i.e. I intentionally leave the “invalid
import order” restriction in the compiler.

Why? Because I view it is a desirable property if the compiler, if it encourages
the programmer to write the import list of a module in the “right” order, i.e.
reflecting the module hierarchy.. fully knowing that enforcing the rule that
explicit imports must always become before re-imports may in some (rare?)
cases force the programmer of a client module to change the import order,
if the programmer of an imported module changes *its* import list.

I understand that some people feel more strongly about this restriction and
absolutely want to be able to write the module list in the IMPORT statement
in *any* order -> well, they can now just pick variant ORB3.Mod if they want.


-ap