On 26 April 2005 04:55, S. Alexander Jacobson wrote:

On Mon, 25 Apr 2005, John Meacham wrote:

...

The haskell report (and hence the haskell language) specifies __nothing__ about how imported module names are actually mapped to code. This has always been left up to implementations. [...] This is why comparing haskell to cabal doesn't make sense, cabal is meerly one proposed implementation of behavior that is undefined by Haskell.

That's what I thought too! But, Malcolm Wallace and Simon Marlow corrected me a few posts back and they are the authors of the spec. They say that, like Haskell, Cabal actually specifies __nothing__ about how imported module names are mapped to code either.

Me: My objection to Cabal is that it in fact DOES determine the referent of an import statement (build-depends).

Malcolm: I can see why you might object, if that were the case, but Cabal does NOT in fact determine the referent! Cabal is just a convenient way of grouping together the denotational /interface/ of a large bunch of modules. The implementations of those modules can be replaced at any time, provided they still meet the interface.

Me: The Cabal spec says "build-depends: [...] a list of packages [..] needed to build this one"

Malcolm: "needed to build" tells me which interfaces must be available at compile-time, no more and no less.

Simon: Build-depends uses the source-code notion of interface, not the object code. So, build-depends has the same meaning for all compilers.

Malcolm is pointing out that it's possible to substitute object code for a module as long as the replacement supports the same interface. The definition of "interface" in this case is compiler-dependent, so I think we should separate this observation from the discussion at hand - it's an extra complication (IMHO). You're interested in what the meaning of Cabal+Haskell is. Here's a succinct interpretation of the relationship: Haskell: "A program consists of a set of modules." Cabal+Haskell: "A program consists of a set of modules. I'm going to provide a way to construct that set of modules, by combining sets of modules called packages." Cheers, Simon