On Wed, Aug 06, 2003 at 12:34:41PM +0100, Simon Peyton-Jones wrote:
Maybe you are saying "what happens if you graft two modules from different packages so that both modules get the same name?". For example, suppose we have two packages
dataOps-1.0 has a module with (relative) name A.B foo-2.7 has a module with (relative) name X.A.B
Suppose you graft in dataOps-1.0 at site DataOps.X and foo-2.7 at site DataOps
Then "import DataOps.X.A.B" is ambiguous: it could mean either module.
That is plainly an error. To be consistent with name clashes within module, the complaint should probably only come if you actually try to import it.
Was that what you meant?
Yes. I would have thought that library authors would want to avoid this. I guess you don't mind: the library user just grafts one of the libraries in somewhere else. So the mapping supplied with the package is presumably just a default that can be overridden. And to read someone else's source code I also need their personalized mappings for the various packages they're using. So you have extended the syntax of the language: you need a syntax for these mappings, and the static semantics operates on ordinary source plus this mapping language.