Cabal vs Haskell [sic]

[S. Alexander Jacobson]

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.

> You can compare Cabal's way of doing things to what specific compilers
> have done, but not 'Haskell' because 'Haskell' doesn't concern itself
> with these issues.

Yeah Simon Marlow corrected me on this one too.  Cabal should be 
thought of Cabal is part of the Haskell source not its implementation:

   Me: My fundamental point here is that the meaning of code shouldn't
   change depending on the location where it is interpreted. [...]
   Concretely, the meaning of "import Data.List" in a
   haskell module shouldn't depend on whether the module is on my
   computer or yours.

   Simon: You can think of .cabal as part of the source if that helps.
   It really is part of the source - but implemented and specified as a
   layer on top of existing language and compiler technology, for
   convenience and so that we can share the tools.

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com



> On Mon, Apr 25, 2005 at 08:01:56PM -0400, S. Alexander Jacobson wrote:
>> On Sun, 24 Apr 2005, Isaac Jones wrote:
>>> Once again, the current cabal story is not different from the current
>>> Haskell story.  Please stop saying that.
>>
>> 1. The current Haskell story is that the dependencies of a module are
>> the set of modules identified in its import statements.
>
> 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. Of course, there is an
> understanding that implementations should do something sane and most
> have done something akin to looking up modules in files of the same name
> and -i statements, but this is not required or specified by the report.
> This is why comparing haskell to cabal doesn't make sense, cabal is
> meerly one proposed implementation of behavior that is undefined by
> Haskell.
>
> You can compare Cabal's way of doing things to what specific compilers
> have done, but not 'Haskell' because 'Haskell' doesn't concern itself
> with these issues.
>
>        John
>
> -- 
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>