Cabal vs Haskell [sic]

[S. Alexander Jacobson]

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" <alex at alexjacobson.com> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>