Cabal vs Haskell [sic]

[Malcolm Wallace]

> > 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.
> 
>     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.
> 
> I interpret "needed to build this one" as requirement rather than 
> recommendation.  So I interpret build-depends as determining the 
> referent.

"Needed to build" tells me which interfaces must be available at
compile-time, no more and no less.  I found recently that ghc-pkg
(whose input format is essentially Cabal+extras) has a separate
"builds" field, which maps the interfaces given in the "build-depends"
field to a set of specific implementations.  So the referent is
(potentially) determined separately from the interface.

Your confusion probably arises because there is no really hard
separation between interface and implementation in the Haskell'98
source language.

As it happens, different compilers blur the boundary between interface
and implementation to a greater or lesser extent.  But that's a
compiler issue, not something intrinsic to either the language or
to Cabal.

OK, maybe you could complain that the language spec should be
more explicit about interfaces, and I might be inclined to agree.
(Versions 1.0 and 1.1 actually mentioned interface files, but they
were deleted in 1.2, long before the '98 standard.)

> 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.

Well, the overlap restriction exists in the language already.
If you want to lift it, you really need to change the language.
Simon's proposal (which I support) is a hack to permit the restriction
to be lifted without changing existing code, by re-interpreting all
module imports to have an implicit (disambiguating) prefix.  It is
just an engineering tradeoff to ensure that huge mounds of legacy code
are not broken purely for the sake of some rather rare overlap case.

I think, even with the lifting of the overlap restriction, it will
still be the base that certain compilers could permit the remapping of
(package-version-module) identifiers to implementations.  The version
uniquely identifies the interface, not necessarily the implementation.

Of course, in that situation, it starts to become complicated,
because then you will want separate identifiers/versions for different
implementations that match a particular (version of the) interface.

Regards,
    Malcolm