🚀 go-pugleaf

In article <13951@topaz.rutgers.edu> dalal@topaz.rutgers.edu (Mukesh Dalal) writes:
>1. Is the type checking based on name equivalence or structure
>equivalence? 

Name equivalence.  E.g.
  TYPE t = [0..42];
  VAR  a : t;
       b : [0..42];
  PROCEDURE f ( VAR p : t );
       BEGIN END f;
  f(a) (*legal*);
  f(b) (*illegal*);

> More specifically, Is the following construct allowed:
>	Type
>	 P= Record
>		...
>	    End;
>	 Q = P;

Yes, as the two types are IDENTICAL, as Q is of type P.

>2. Can a global module export an item which it has imported?

  DEFINITION MODULE m;
  FROM Foo IMPORT Bar;
  EXPORT QUALIFIED Bar,  (* is not legal*)
                   Feen; (* is legal *)
  TYPE Feen = Bar;
  END m.

>3. Can the definition of a global-module M refer to a type P which is
>neither declared there (either as opaque or transparent) nor is
>imported from some other module but is defined/imported in the
>corresponding implementation module of M?

No.

>4. Is the following construct allowed:
>
>	Definition:
>		procedure abc (..);
>	Implementation:
>		var x: ...;
>		procedure abc (...);
>			...
>			x := ...;
>		end;
>		...

Yes.
-- 
Randy Bush, Compiler Group, Oregon Software, Portland Oregon (503) 245-2202
uucp: ..!tektronix!oresoft!randy       Telemail: RBush     Fidonet: 1:105/6

The f(a) and f(b) constructs are allowed in the
modula2 compiler I am using.  The short program module compiles AND runs
with no problems.
  where's modula3?!?

                             -D.H.
----
David Hiebeler       hiebeler@csv.rpi.edu
Chatham, NY         "Illusions, Richard!  Every
(also Troy, NY)      bit of it illusions!"

> >2. Can a global module export an item which it has imported?
> 
>   DEFINITION MODULE m;
>   FROM Foo IMPORT Bar;
>   EXPORT QUALIFIED Bar,  (* is not legal*)
>                    Feen; (* is legal *)
>   TYPE Feen = Bar;
>   END m.

Could someone please show where this is explicitly disallowed in
Wirth?  The second edition is unclear, and nobody around here seems to
have the third edition (I'm rather reluctant to buy it with a
standards committee on the loose).

If it IS specifically disallowed, I'm going to be dissappointed.  It
is a good way of splitting up large modules into smaller sub-modules,
then packaging the results together.  For instance:

	DEFINITION MODULE listLife;
	EXPORT QUALIFIED ListNew, ListEmpty, ListFree;
	...
	END listLife.

	DEFINITION MODULE listAdd;
	EXPORT QUALIFIED ListAddFirst, ListAddLast;
	...
	END listAdd.

	DEFINITION MODULE listRemove;
	EXPORT QUALIFIED ListRemoveFirst, ListRemoveLast;
	...
	END listRemove.

	DEFINITION MODULE Lists;
	FROM listLife IMPORT ListNew, ListEmpty, ListFree;
	FROM listAdd IMPORT ListAddFirst, ListAddLast, ...;
	FROM listRemove IMPORT ListRemoveFirst, ListRemoveLast, ...;
	EXPORT QUALIFIED
		List,
		ListNew, ListEmpty, ListFree,
		ListAddFirst, ListAddLast,
		ListRemoveFirst, ListRemoveLast;
	TYPE List;
	END Lists.

The user just imports what he wants from the Lists module.

This is from a real-life example.  The actual code has about eight
sub-modules, with an average of 5 or 6 functions per sub-module.
Stuffing it all into one file (the only other alternative) makes the
code less readable, and greatly increases the compilation time when
changes are made.

Charlie Allen		cca@newton.physics.purdue.edu

In article <803@newton.physics.purdue.edu> cca@newton.physics.purdue.edu (Charles C. Allen) writes:
>> >2. Can a global module export an item which it has imported?
>> 
>>   DEFINITION MODULE m;
>>   FROM Foo IMPORT Bar;
>>   EXPORT QUALIFIED Bar,  (* is not legal*)
>>                    Feen; (* is legal *)
>>   TYPE Feen = Bar;
>>   END m.
>
>Could someone please show where this is explicitly disallowed in
>Wirth?  The second edition is unclear, and nobody around here seems to
>have the third edition (I'm rather reluctant to buy it with a
>standards committee on the loose).

PIM2-2, page 158, Chap 11, paragraph 1

"The export list specifies all identifiers of objects declared within the
module and used outside."

As import is not a declaration, an imported object may not be directly
exported.  This point has been discussed and worried over many times and
places, and, admittedly, the current resolution is less than satisfactory.

Also note that, as PIM2-3 does not provide export from a definition module,
the question becomes moot.
-- 
Randy Bush, Compiler Group, Oregon Software, Portland Oregon (503) 245-2202
uucp: ..!tektronix!oresoft!randy       Telemail: RBush     Fidonet: 1:105/6