Re: Cabal vs Haskell [sic]

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.

The Cabal spec says: build-depends: package list A list of packages, possibly annotated with versions, needed to build this one, e.g. foo > 1.2, bar. If no version constraint is specified, any version is assumed to be acceptable. http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html I interpret "needed to build this one" as requirement rather than recommendation. So I interpret build-depends as determining the referent. Moreover, I think Simon does too. He proposes that we should lift the overlap restriction by having module names map to (cabal-package, module) pairs. To me, that only makes sense if build-depends is determining the referent. He acknowledges that a consequence of this is that you risk errors like "can't unify (package foo, M.T) with (package bar, M.T)"! I am arguing instead that all modules in all packages used by a program should share the same referent for M.T, that we need a mechanism for establishing that referent, and that build-depends doesn't do that. I feel like we may actually be on the same wavelength here. Exciting! -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 21 Apr 2005, Malcolm Wallace wrote:

"S. Alexander Jacobson" writes:

...

I think I must be communicating extremely poorly here, because I think you are interpreting me to be saying something largely opposite what I think I am saying.

Well I must admit several of us have been having difficulty understanding what your point is. But we seem to be getting nearer to it now. :-)

...

...

The Haskell source does not now, and never has, determined the referent of an import statement. That has /always/ been external to the language.

Yes, that is precisely my point! My objection to Cabal is that it in fact DOES determine the referent of an import statement (build-depends).

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.

At least, for some compilers (Hugs, nhc98) this is true, so I figure it is true in general for the Cabal model, and indeed the Haskell model.

I believe the real problem you are objecting to is that a highly optimising compiler like ghc (or indeed the new jhc) DOES NOT SOLELY RELY ON THE INTERFACES of imported modules when it compiles another library module that uses them. These compilers do all kinds of cross-module optimisation, and therefore know a lot more about the actual implementation of the lower modules than just function names and type signatures. Hence, you cannot rip-and-replace a lower module at will, without also recompiling all higher modules that depend on it. Again, to be clear, this is ONLY in certain optimising compilers.

...

To be more precise, I believe that module names in import statements have a *denotational* meaning e.g Prelude refers to a set of functions defined in the Report and Data.List refers to a set of functions defined in the Standard Libraries.

Yes, I can see the general idea here. Unfortunately, Haskell doesn't have a particularly user-accessible notion of denotational interface, unlike Ada for instance. I think it would be nice if Haskell 2 could allow the user to write explicit interfaces, including properties beyond mere type signatures - especially if there is good semi-automated verification support for those properties. (I thinking QuickCheck, Programmatica, Alfa...) That would make it easier to replace the implementation of a module by a "better" one whilst guaranteeing it still does the "same" thing.

Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries