Stop untracked dependencies!

[S. Alexander Jacobson]

Simon says:
> I'm afraid it's the same thing, because packages are indivisible.

In other words, packages should be minimal sets of mutually 
interdependent modules.  This fact combined with no-grafting rule's 
global module namespace implies that the whole notion of build-depends 
or package files is a mistake!

Module names map directly to sets of project locations via some 
community consensus.  And user visible package names are just 
overhead.

We just need a way for a community to resolve module names to package 
locations.  Ideally, this would be a standard protocol by which 
haskell implementations can do such lookups of package URLs against a 
set of known module name servers.

Strawman protocol 1: Define a new DNS record, URL, and define some 
translation of module names into domain names.

Strawman protocol 2: Use HTTP/HTTPS and define a query syntax such as
GET ResolverURL/moduleName and use 30x headers for redirection to the 
appropriate server.

Thoughts?

-Alex-

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










On Mon, 4 Apr 2005, Simon Marlow wrote:

> On 01 April 2005 20:31, S. Alexander Jacobson wrote:
>
>> If we are in agreement about the overall goal, then I'll move on to
>> the specific issues that need addressing:
>>
>> * We Need Free Packaging
>>
>> Anyone should be able to create a package at any time for use in their
>> projects without having having to negotiate with any particular
>> centralized authority or community.
>
> Absolutely!  I suggested that URLs should be valid package names before,
> and I still think that's a reasonable solution.
>
> Using Hackage will be completely optional.  No-one is about to tell you
> how and where you can distribute your own packages.
>
>> * Free Packaging Means We To Handle Collisions in Module Namespace
>>
>> Anyone should be able to use any combination of packages they want in
>> any of their programs at any time without worrying about whether those
>> packages export the same module name.
>>
>> Simon says:
>>> We don't allow programs to contain two modules with the same name,
>>> for good reasons.
>>
>> I'm not asking for that.  I am totally ok with each module name
>> mapping to one and only one implementation per program.  I just want
>> to be able choose that implementation even when my program uses two
>> packages that both happen to export the same module name.
>
> I'm afraid it's the same thing, because packages are indivisible.
> Packages are indivisible for two reasons:
>
>  - modules within a package depend on each other.  If you need one,
>    you need all its dependencies too.  Packages don't tell you what
>    their inter-module dependencies are.  That's part of the reason
>    for having packages: to decrease the granularity of dependencies.
>
>  - technical reasons: a package may be shipped as a shared library,
>    which is indvisible and populates the global symbol table with
>    all of its symbols.  You can't pick and choose which ones you
>    want.  (static libraries allow a kind of shadowing, but it would
>    also lead to problems I think).
>
> So to do what you're asking for, we'd have to support overlapping
> modules.  I agree with your reasoning for wanting to be able to do this:
> we need as much freedom to be able to combine packages from third
> parties as possible.  Unfortunately, it requires a non-trivial
> technological leap.
>
>> * We Need to Associate Module Names with Specific Packages
>
> You could specify the connection between modules and packages if you
> want.  Given that you can't use two packages containing the same module,
> the information would be redundant (apart from documentation) right now.
>
>> * Default Exposed Packages Are Untenable
>>
>> Although, I agree that fussing with a -packages command line is
>> annoying, the need to associate module names with packages ids
>> makes the existing default exposed package compromise untenable.
>>
>> But, all is not lost!  If you choose (c) above, nothing stops you from
>> having a default global "Packages" file.  Then your marginal work is
>> just to supply a package name in your import statements e.g.:
>>
>>    import HaXML HaXML.XML.Parse
>
> Your global "Packages" file is a source of untracked dependencies, isn't
> it?  Don't I have to provide that file with every scrap of source code I
> publish?  How do I merge someone else's Packages file with mine?  In
> what way is it better than specifying dependencies in a .cabal file
> which is already shipped with a package?
>
> Also, the Haskell module hierarchy is supposed to reflect functionality,
> whereas package names are purely administrative.  This is a reason for
> not including package names in source code.
>
> There are some other administrative details which amount to
> dependencies, and which are tracked by .cabal files but not by your
> proposal:
>
>  - language extensions
>  - include paths
>  - library paths
>  - C library dependencies
>  etc.
>
> some of these you can put in {-# GHC_OPTIONS #-}, but not all.  And in
> any case you probably want to specify them once per package, not once
> per module.
>
>> * In Any Case, Default Exposed Packages Are Also a Poor Compromise.
>>
>> I don't want to have to worry about accumulating untracked dependcies
>> when I am doing quickie work with GHCi.  I want my dependencies
>> checked every step of the way and should not have to round trip
>> through a Cabal packaging step just to verify them.
>
> Your dependencies are still untracked.  But anyway, I see the point.  If
> you want package dependencies checked as you write source code, here are
> a couple of possibilities:
>
>  - GHC could have a checked pragma on each import, eg:
>
>      import {-# PACKAGE base >= 1.0 #-} Data.List
>
>    I don't want to write these in my source code personally,
>    but it would be easy enough to implement.  It could be
>    made mandatory, optionally.
>
>  Or:
>
>  - GHCi could have a Cabal front end.  i.e. you give GHCi a
>    .cabal file instead of specifying source files directly,
>    and it checks dependencies.  This is easy enough to
>    implement too.
>
> In both cases you would have to restart GHCi if you made use of a
> non-exposed package, thoughl.
>
>> * Conclusion: Freedom is good.
>
> No argument from me on that one!
>
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>