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 conventions.
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. Cheers, Simon
Dear all, Simon M. wrote:
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.
Point taken. (I did say that Georg's proposal had its merits, and this is basically what I meant.)
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.
Personally, I like the fact that the module names are explicitly there, but again, yes I can certainly see that it can be inconvenient. But as always, how much "refactoring support" should there be in the language, and what does properly belong in tools? Anyway, I'm not fundamentally opposed to more flexible imports, I'm only worried about too many environmental dependencies unnecessarily infiltrating the language spec. As long as a discussion would be in terms of a hierarchical module name space (or some other language-centred notion like that), I have no objects to the discussion as such.
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.
Yes, that might be necessary in the end. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
Dear all, Okay, I see the point of not including the environment into the spec. However other languages like Java for example do this as far as I know. Anyway, I would like to hear your comments about point 2-4 of my original mail, because there are more important from my point of view. These don't depend on how files are named or located after all. Good day! Georg On Wednesday 22 February 2006 12:29, Henrik Nilsson wrote:
Dear all,
Simon M. wrote:
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.
Point taken. (I did say that Georg's proposal had its merits, and this is basically what I meant.)
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.
Personally, I like the fact that the module names are explicitly there, but again, yes I can certainly see that it can be inconvenient.
But as always, how much "refactoring support" should there be in the language, and what does properly belong in tools?
Anyway, I'm not fundamentally opposed to more flexible imports, I'm only worried about too many environmental dependencies unnecessarily infiltrating the language spec.
As long as a discussion would be in terms of a hierarchical module name space (or some other language-centred notion like that), I have no objects to the discussion as such.
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.
Yes, that might be necessary in the end.
Best,
/Henrik
-- ---- Georg Martius, Tel: +49 177 6413311 ----- ------- http://www.flexman.homeip.net ----------
Georg Martius wrote:
Okay, I see the point of not including the environment into the spec. However other languages like Java for example do this as far as I know.
To be precise, no, the Java specs leave this to the implementation: JLS - 7.2. host support for packages Each host determines how packages, compilation units, and subpackages are created and stored, and which compilation units are observable (§7.3) in a particular compilation. http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.2 JVM Spec - 5.3 Creation and Loading Typically, a class or interface will be represented using a file in a hierarchical file system. The name of the class or interface will usually be encoded in the pathname of the file. http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html... Respectfully submitted, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Simon Marlow wrote:
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.
I don't see how this is related to implementation. Surely all the language spec has to say is that the implementation has some unspecified way of finding the code for a module given only its canonical name, along with (if desired) a way of expanding a glob to a list of canonical names. Then the module namespace reform boils down to rules for converting partial names into canonical names. I can't see how any useful functionality in the module system could depend on a particular way of organizing code on disk. -- Ben
participants (5)
-
Ben Rudiak-Gould -
Georg Martius -
Henrik Nilsson -
Johannes Waldmann -
Simon Marlow