Cabal vs Haskell [sic]

[S. Alexander Jacobson]

On Thu, 28 Apr 2005, Benjamin Franksen wrote:
> 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.

Of course.  By definition, you can't reify intensional meanings 
(otherwise they would be extensional!).

We should think of module names as being like domain names, and module 
implementations as being like IP addresses.  Just as the owner of a 
domain name determines valid IP addresses for it, the owner of a 
module name should be able to determine valid implemementations.
Just as you can't provide domain name resolution for domain names you 
don't own, you should not be able to provide module name resolution 
for module names you don't own.

We need a Module Name System analogous to the Domain Name System. 
Haskell compilers should be able to query a root server to find which 
MNS server is authoritative for a particular module name.  A query to 
that MNS server should result in URLs for implementations of that 
module.

And we have an existence proof that this sort of system both works and 
scales reasonably well; the DNS.

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com









On Thu, 28 Apr 2005, Benjamin Franksen wrote:

> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>