hirarchical module system qualifiers
hello, i have been using the hirarchical module system quite a bit lately, and i often find myself writing things like: import Syntax.Core.Struct as Struct import Utils.Set as Set etc. this is not a big bother, but it leads to clutter, and a few times i got errors, becasue i forgot to add the "as" clause. i would like to propose that by default, the qualified names introduced by an import are just the last part of the module name, and not the entire module name. the downside of this proposal is that it makes the "." in the module name mean something, but i am not sure that this is a bad thing. i think such a change should not break many programs, as i suspect not many people use qualified names, where the qualifiers are more than one "word" long. i also speculate that such a change should be relatively easy to implement. another benefit of such a change is that it makes export lists shorter. for example, currently one needs to write the following: module Syntax.Core.Struct (module Syntax.Core.Struct, module Names) where import Syntax.Core.Names as Names there doesn't seem to be a work around this, as we cannot give an alternative qualifier for the module we are defining. if the qualifier however was just the last part of the name, we would have shorter exports (and also shorter qualifiers for locally defined names). i am curious to hear what people think about that. bye iavor
"Iavor S. Diatchki" <diatchki@cse.ogi.edu> writes:
i would like to propose that by default, the qualified names introduced by an import are just the last part of the module name, and not the entire module name.
When originally proposing the hierarchical module namespace, I recognised this potential annoyance, and came up with the same solution as you, although I framed it as an optional extra in case people were not immediately convinced of the need. nhc98 implements it. Having said that, I don't use qualified naming very often myself, so I don't recall ever taking advantage of the feature.
i also speculate that such a change should be relatively easy to implement.
It is pretty easy, yes. Regards, Malcolm
participants (2)
-
Iavor S. Diatchki -
Malcolm Wallace