Packages and modules

[Ketil Malde]

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:

Just one more thing:

>> PS: Is it correct that -- except for the new functionality in
>> symbols being annotated with package as well as module name -- all of
>> this is just a matter of convenience/syntactic sugar?  (Which would
>> explain the volume of the discussion :-)

> For the current proposal, yes.

Then I'm not convinced it is worth introducing new import syntax.  I
think 90% of the cases of ambiguity should be resolved globally for the
project, i.e. by compiler switches (typically in .cabal, Makefile, or
similar). These cases include using newer versions of standard
packages, regression testing for library versions, or alternative
implementations. 

For the remaining (and bear in mind that nobody have put forward
anything but hypothetical examples yet), I think a proxy module is
sufficient as a solution.  This is necessary where one program needs to
simultaneously use modules with the same hierarchical name from
different packages.  And the advantage of making this hurt a bit, is
that it puts pressure on different-functionality modules to populate
different locations in the hierarchical namespace - the pain here is a
feature, not a bug.

(Please enlighten me if I'm missing some important cases here.) 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants