Cabal vs Haskell [sic]
benjamin.franksen at bessy.de
Thu Apr 28 15:25:35 EDT 2005
On Thursday 28 April 2005 03:58, you wrote:
> On Tue, 26 Apr 2005, David Roundy wrote:
> > On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:
> >> Me: My fundamental point here is that the meaning of code shouldn't
> >> change depending on the location where it is interpreted. [...]
> > But that has *never* been true. The meaning of import Data.List has
> > always depended on which version of which compiler you've got.
> On Tue, 26 Apr 2005, Benjamin Franksen wrote:
> > BTW, I know of no programming language in which module import clauses
> > have a global (world wide) meaning. Resolution of module names in import
> > clauses to actual source or object code is always system or compiler
> > dependent.
> Ok, let me be more explicit. The *intensional* meaning of code
> shouldn't change depending on the location where it is interpreted.
> e.g. Data.List.sort should always mean "sorting a list"
While this sounds like a reasonable expectation, I still don't know of any
existing compiler/interpreter/language that enforces conformance of
implementations with an intensional meaning. Nor are there languages where
the module's /name/, as it appears in an import clause, is associated
statically and globally (i.e. world-wide) with such a specification.
Surely one could imagine some future system with these (or some of these)
properties. But Haskell is and never was such a system.
[The Haskell Prelude is one of the very few examples where in fact we have a
formal specification [albeit not a complete one, since the IO functions
aren't formally specified] and compilers and interpreters are indeed required
to conform to this spec. Nevertheless, this is a special situation and
conformance is not automatically checkable (apart from testing with random
data, that is).]
Until we have a way to provide full formal specs and a language in which a
module implementation can be automatically checked against such a spec, the
meaning of code must be dependent on whatever is installed on the machine
that runs resp. compiles the code, however inconvenient this may be in some
Apart from that, I can imagine situations where associating module names with
specifications in a global (world-wide valid) manner is not even desirable.
It could severely limit the evolution of software if local deviations from
the global rule aren't allowed. OTOH, if such local deviations are allowed,
then the global association of spec with module name cannot be relied upon.
More information about the Libraries