Cabal vs Haskell [sic]

[S. Alexander Jacobson]

> 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" <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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>