Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!gargoyle!ihnp4!inuxc!iuvax!pur-ee!newton.physics.purdue.edu!cca
From: cca@newton.physics.purdue.edu (Charles C. Allen)
Newsgroups: comp.lang.modula2
Subject: Re: some questions about modula2
Message-ID: <803@newton.physics.purdue.edu>
Date: Wed, 19-Aug-87 17:02:57 EDT
Article-I.D.: newton.803
Posted: Wed Aug 19 17:02:57 1987
Date-Received: Sat, 22-Aug-87 07:32:49 EDT
References: <13951@topaz.rutgers.edu> <57@oresoft.UUCP>
Distribution: world
Organization: Purdue Univ. Phys Dept, W.Lafayette, IN
Lines: 54
Summary: reference for "no exporting imports"?

> >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