Cabal vs Haskell [sic]

[Malcolm Wallace]

"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