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 ----------