Malcolm Wallace
Proposal 1 ---------- Introduce nested namespaces for modules. The key concept here is to map the module namespace into a hierarchical directory-like structure. * The use of qualified imports becomes more verbose: for instance [...] instance, either the fully-qualified or abbreviated-qualified names Text.Xml.Parse.element Parse.element would be accepted and have the same referent, but a partial qualification like Xml.Parse.element would not be accepted.
Why not? Perhaps one could have a warning/error if there are multiple "Parse" modules?
* Another consequence of using the dot as the module namespace separator is that it steals one extremely rare construction from Haskell'98: [...] No-one so far thinks this is any great loss, and if you really want to say the latter, you still can by simply inserting spaces: A.B . C.D
Personally, I'm not overly enthusiastic about using (.) for function composition - but I guess e.g the degrees sign was ruled out since it's not in (7bit) ASCII - and I think it should require spaces anyway, in order to differentiate it from its other uses.
Proposal 2 ---------- Adopt a standardised namespace layout to help those looking for or writing libraries, and a "Std" namespace prefix for genuinely standard libraries. (These are two different things.)
Sounds good! -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde writes:
instance, either the fully-qualified or abbreviated-qualified names Text.Xml.Parse.element Parse.element would be accepted and have the same referent, but a partial qualification like Xml.Parse.element would not be accepted.
Why not?
I suppose it would be possible to have an implicit import A.B.C.D.E as E import A.B.C.D.E as D.E import A.B.C.D.E as C.D.E import A.B.C.D.E as B.C.D.E To me, this seems like it introduces extra complexity with little benefit for ease of use. Wouldn't it be confusing to use C.D.E at some places in a program, and D.E at others? It isn't necessarily obvious that they refer to the same entity. After all, what if your project has a module hierarchy like: A/B/C/D/E B/C/D/E Z/B/C/D/E R/S/T/D/E ? To which of these paths might D.E refer? No, I think that restricting the implicit 'as' declaration to the simplest convenient case (just the last component) is the best compromise to improve readability, without introducing too many potential pitfalls. And of course, you can always give an explicit 'as' clause if you wish.
Perhaps one could have a warning/error if there are multiple "Parse" modules?
This is kind-of what currently happens in Haskell'98. You can rename two imports to the same qualifier: import A as M import B as M Provided that function f appears in only one of A or B, the qualified name M.f is resolved correctly. If function g is defined in both, then M.g is ambiguous and the compiler gives an error - but only if you actually mention M.g. It is okay for A and B to have overlapping definitions provided you don't try to use one of them.
Personally, I'm not overly enthusiastic about using (.) for function composition - but I guess e.g the degrees sign was ruled out since it's not in (7bit) ASCII - and I think it should require spaces anyway, in order to differentiate it from its other uses.
I have been thinking about defining centred dot in nhc98's Prelude as a synonym for the composition operator. Perhaps other Haskell systems might be prepared to do the same? (On my system I can type a centred dot easily with the sequence Compose-dot-dot.) Regards, Malcolm
participants (2)
-
Ketil Malde -
Malcolm Wallace