Re: Cabal vs Haskell [sic]

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.

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). 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. But that the *operational* meaning should be determined by the module user e.g. different compilers may operationalize Prelude and Data.List very differently. Cabal attempts to give the packager author control over operational semantics; control that belongs in the hands of the package user. However, if this control is to be in the hands of package users, it would be nice to have tools that help them find implementations consistent with the import declarations of the modules they want to use. Is this any clearer? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 21 Apr 2005, Malcolm Wallace wrote:

"S. Alexander Jacobson" writes:

...

It is Cabal's build-depends tag that determines the meaning of import statement rather than the Haskell source.

Correct me if I'm wrong, but I think this statement is the core of your argument. However, it is untrue. The Haskell source does not now, and never has, determined the referent of an import statement. That has /always/ been external to the language.

There was once a compiler (Freja) that permitted multiple modules to occur in the same source file, which is slightly closer to what you want. But all other compiler implementations have adopted a separate-compilation model, where the mapping of an import statement (to the source code that supplies those entities) is determined external to the source code of the importing module, whether by Makefiles, hmake, manual -I/-package flags to the compiler, Cabal, or some other mechanism. This is exactly the same as in other languages like C, Ada, etc.

Apart from a self-contained program consisting of a single module, Haskell has always depended on an external specification (often implicit) of the mapping between module names and module implementations. Cabal does not change this - it just makes it more convenient to express what you want when there are large numbers of modules involved.

...

The existing module resolution mechanisms are inadequate to our needs. Lets focus on building something that meets them.

I do not think everyone agrees that the existing import resolution model is flawed. If you truly believe Haskell needs to be changed to make import resolution internal to the source code, then you need to demonstrate more clearly what is wrong with the status quo; to persuade us that something is broken.

Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries