Cabal vs Haskell [sic]

[Benjamin Franksen]

On Tuesday 26 April 2005 05:54, S. Alexander Jacobson wrote:
> On Mon, 25 Apr 2005, John Meacham wrote:
> > You can compare Cabal's way of doing things to what specific compilers
> > have done, but not 'Haskell' because 'Haskell' doesn't concern itself
> > with these issues.
>
> Yeah Simon Marlow corrected me on this one too.  Cabal should be
> thought of Cabal is part of the Haskell source not its implementation:
>
>    Me: My fundamental point here is that the meaning of code shouldn't
>    change depending on the location where it is interpreted. [...]
>    Concretely, the meaning of "import Data.List" in a
>    haskell module shouldn't depend on whether the module is on my
>    computer or yours.
>
>    Simon: You can think of .cabal as part of the source if that helps.
>    It really is part of the source - but implemented and specified as a
>    layer on top of existing language and compiler technology, for
>    convenience and so that we can share the tools.

I don't want to take side in this discussion, but this is really nitpicking. 
Obviously Simon has not meant to say that .cabal is part of the source code 
in the sense of 'what is in its meaning defined by the Haskell standard'. In 
fact, it makes sense to think of your Makefile and documentation (and 
whatever else your package may consist of) as part of the source code, but of 
course in a wider sense, i.e. one not covered by the language definition.

BTW, I know of no programming language in which module import clauses have a 
global (world wide) meaning. Resolution of module names in import clauses to 
actual source or object code is always system or compiler dependent.

Apart from that, I gebin to wonder if the hierarchical module names were a 
good idea to start with. Maybe a better solution would have been to delegate 
resolution of module name conflicts to an external tool, similar to the Lace 
mechanism in Eiffel. In Eiffel, a program consists of a number of classes, 
each of which must have a unique name. But with Lace you can not only relate 
classes to file names, you can also rename conflicting classes (and you can 
do this for whole 'clusters', if you like, where a cluster is roughly the 
equivalent of a package). I think this is the superior approach because it 
gives the end user complete control.

Ben