simonmar at microsoft.com
Wed Feb 22 06:15:12 EST 2006
On 21 February 2006 18:22, Henrik Nilsson wrote:
> Georg wrote:
> > Well, the hierarchical module system as it is implemented today and
> > how it is proposed for being included into Haskell' uses the file
> > system to locate modules.
> Yes, tools need to, somehow, locate modules.
> Yes, for portability reasons, it is convenient if tools support common
> But that does not mean that the *language standard* should nail down
> these details.
While I've always liked the principle that the language spec is
completely independent of implementation details such as the filesystem,
I'm not sure we can hang on to it forever.
This is not the first time that someone has made the same suggestion as
Georg, and for good reasons: there's a lack of modularity in the current
design, such that renaming the root of a module hierarchy requires
editing every single source file in the hierarchy. The only good reason
for this is the separation between language and implementation.
There are more elaborate proposals, such as "grafting", where a module
sub-hierarchy can be placed at an arbitrary position in the namespace at
compile time, which boils down to renaming modules at compile time
again, and violating the language/implementation separation.
I don't have anything concrete to say (sorry!) except that I'm not
convinced that the language spec should require a module to declare its
full name in the source code any more. I certainly don't believe that
the language spec should say anything at all about file systems, but it
should be open to the possibility that "unspecified
implementation-dependent behaviour" might affect how module definitions
are paired with import declarations.
More information about the Haskell-prime