Packages and modules

[Malcolm Wallace]

John Meacham <john at repetae.net> wrote:

> Package names should never appear in source files IMHO. if a package
> name is in the source file, then you might as well make it part of the
> module name.  Packages exist for 'meta-organization' of code. A way to
> deal with mapping code _outside_ of the language itself, putting
> packages inside the code will force the creation of yet another level,
> meta-packages, or something. packages should not be a language issue,
> they are an environment one.

I tend to the opposite view.  The meaning of the code should be
expressed in the code itself.  If a module M imports A.B.C, and I can
see two such modules called A.B.C, then the meaning of the code is
ambiguous and ill-defined.  I would rather not have to look elsewhere
(in the build system?  Makefile?  scons?  Cabal file?  DOS batch file?
where?) to find out how to resolve the ambiguity.  Surely the programmer
knew which import was intended.  Is it so difficult to communicate that
information somewhere close to the import itself?

This is the same situation as with compiler flags for language
extensions, foreign imports, and so on.  If a module uses a non-standard
language feature that changes the interpretation of the syntax (e.g.
template haskell), it should say so in the module itself {-# OPTIONS_GHC
-fth #-}, so that I as a human reader know what is going on.  Likewise,
if a foreign import requires a C header file, that should also be
referred to in the FFI decl, not solely as a build option at some
arbitrary distance in the filesystem.

Regards,
    Malcolm