More feedback on Haskell 98 modules from the Programatica Team

[Simon Peyton-Jones]

| I don't think that this is a good idea. In particular because it may=20
| break existing programs. Consider two modules with one common=20
| name, e.g.
|=20
| module A where
|   f x =3D 1
|   ... a lot of other definitions ...
| module B where
|   f x =3D 2
|   ... a lot more definitions but none conflicting with A's=20
| top-level entities ...
|=20
| The following module is legal under the current semantics of=20
| the report=20
| (and will export everything from A and B except for A.f and in=20
| particular will generate no names clashes in the body of the module=20
|=20
| module C (module A,module B,module C) where
|   import A hiding(f)
|   import qualified A(f)
|   import B
|   ... code using A.f and f (i.e. B.f) ...
|=20
| With your proposed change there will be a name clash for the=20
| export of from module C.

That's a good point, Wolfgang.  Not breaking existing programs is
definitely a goal,
unless there is a pressing reason to make a change. Here there isn't a
pressing reason.
The alternative is:

	"module Y" in an export list is short for the set of all
entities whose *unqualified*
	names were brought into scope by an "import Y" or "import X as
Y" declaration.
	This set may be empty.

This would be closer to the Report as it currently stands, and meets
your objection.
Let's treat this as my revised proposal.

Thanks for pointing this out. =20

[Note: the above spec would be a little simpler if we didn't have to say

'...or "import X as Y"...'; but I am still mildly in favour of using the
'as' renaming
if it is given.  Consider =20
	module A( Y.f, Y.g ) where
	  import X as Y(f,g)
vs
	module A( module Y ) where=20
	  import X as Y(f,g)

It would seem funny to have to write "module X" in the latter case. But
it's a fine point
and I could be persuaded otherwise.  The Report is currently silent on
this matter.]

Simon