[comp.lang.modula2] JPI export rules

Pat.Terry@p101.f19.n490.z2.fidonet.org (Pat Terry) (03/19/89)

Ben Thornton has raised the problem of referencing objects exported from an
inner module, and Randy Bush has suggested that one should examine the
following program:

    MODULE t1;
    (* should write
       m0.p called
       m1.p called *)
    FROM InOut IMPORT WriteString, WriteLn;
      MODULE m0;
        IMPORT WriteString, WriteLn;
        EXPORT QUALIFIED p;
        PROCEDURE p ();
        BEGIN WriteString ("m0.p called"); WriteLn () END p;
        END m0;
      MODULE m1;
        IMPORT WriteString, WriteLn;
        EXPORT p;
        PROCEDURE p ();
        BEGIN WriteString ("m1.p called"); WriteLn () END p;
        END m1;
    BEGIN
      m0.p ();
      p ();          (* calls m1's p *)
      m1.p ();       (* illegal?     *)
      END t1.

I have tried this on various MS-DOS implementations: FST 2.0, Logitech 3.03,
JPI 1.14, QuickMod, FTL 1.32 SMM and LMM, Collier 2, and also on my Sage
Volition (remember that? - still a remarkably good one, even five years on!)

All accept it quite happily (including the "illegal" call, except for FTL
which will not accept the m1.p() call, reporting "undefined id".  A strange
error message indeed.

I think what may have caused Thornton's problem is the rather strange
interpretation JPI have put on export in various releases of their system.
Release 1.02 wouldn't allow an EXPORT QUALIFIED in an inner module at all.
So far as I could see, they interpreted the change from PIM2 to PIM3 which
dispensed with EXPORT QUALIFIED in DefMods as an indication that the clause
should not appear in local modules either (presumably hoping that PIM4 would
come out and correct the "misprint" in dues course!)  Since then I think
there have been various rethinks, but they still have not got it correct.

The problem is worse with the following example:

     DEFINITION MODULE junk;

       PROCEDURE Test;

     END junk.

followed by

  IMPLEMENTATION MODULE junk;
    FROM InOut IMPORT WriteString;

    MODULE Inner (*which might be needed if one wanted a priority module*);
      IMPORT WriteString;
      EXPORT Test;

      PROCEDURE Test;
        BEGIN WriteString('hello world') END Test;

      END Inner;

  END junk.

So far as I can see, this should be quite legal.  But not all compilers will
accept it.  Volition, FST, Logitech and Quickmod are all happy.  Collier, FTL
and JPI collapse on it, claiming a "duplicate definition" of Test has
occurred (or words to that effect).

If the Inner EXPORT clause is changed to EXPORT QUALIFIED I think one gets
an illegal program.  So do the authors of JPI, Volition, FST, FTL, Collier
and Logitech.  QuickMod is still happy with it, however.

The JPI system can programmed around as follows:

  IMPLEMENTATION MODULE junk;
    FROM InOut IMPORT WriteString;

    MODULE Inner (*which might be needed if one wanted a priority module*);
      IMPORT WriteString;
      EXPORT QUALIFIED Test;

      PROCEDURE Test;
        BEGIN WriteString('hello world') END Test;

      END Inner;

    PROCEDURE Test;
      BEGIN Inner.Test; END Test;

  END junk.

although this is clumsy, and this would not be possible for variables and
constants (which is what Thornton mentioned, but did not exemplify).

I seem to remember that an intermediate release of JPI (I have had several
updates between 1.02 and 1.14) would allow something like

  IMPLEMENTATION MODULE junk;
    FROM InOut IMPORT WriteString;

    MODULE Inner (*which might be needed if one wanted a priority module*);
      IMPORT WriteString;
      EXPORT QUALIFIED Test;

      PROCEDURE Test;
        BEGIN WriteString('hello world') END Test;

      END Inner;

    PROCEDURE Test;
      BEGIN Inner.Test END Test;

  END junk.

as well, which is quite badly wrong, but I cannot be sure of this now.





--  
uucp: ..!{mcvax!uunet,tektronix,sun!nosun}!oresoft!dawggon!2!490!19.101!Pat.Terry
Internet: Pat.Terry@p101.f19.n490.z2.fidonet.org