Cabal vs Haskell [sic]

[Malcolm Wallace]

"S. Alexander Jacobson" <alex at alexjacobson.com> 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