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@haskell.org http://www.haskell.org/mailman/listinfo/libraries