RE: Libraries and hierarchies
| Wouldn't one still want the module prefix + relative module name | combination to produce unique module names? So presumably the prefix | should include the package name (though without a version number). I don't think so. Under our proposal, "original names" are globally unique and stable, but the name for a module in a compilation depends on what graftings you have done. 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? Simon
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.
On Thursday 07 August 2003 4:29 pm, Ross Paterson wrote:
[...] 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.
This separate mapping language is starting to sound a little like the module language in ML, component linking languages like Units (used in MzScheme, Knit and Jiazzi), etc. It's quite a bit simpler than those languages but it has a similar semantic effect. -- Alastair
participants (3)
-
Alastair Reid -
Ross Paterson -
Simon Peyton-Jones