Cabal vs Haskell [sic]

Benjamin Franksen 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 
situations.

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.

Ben


More information about the Libraries mailing list