Specifying dependencies on Haskell code

[Duncan Coutts]

On Fri, 2008-05-02 at 00:28 +0200, Thomas Schilling wrote:
> On 20 apr 2008, at 22.22, Duncan Coutts wrote:

> [Replying so late as I only saw this today.]
> 
> I believe that using tight version constraints in conjunction with  
> the PVP to be a good solution.  For now.

I think I tend to agree.

> I don't quite know how Searchpath works (the website is rather  
> taciturn), but I think that we should strive for a better  
> approximation to real dependencies, specifically, name, interface,  
> and semantics of imported functions.  As I see it, what's missing is  
> proper tool support to do it practically for both library authors and  
> users.

Yes, we can make package name and version a better approximation of the
package interface with tools to enforce the versioning policy.

> Library users really shouldn't need to do anything except to run a  
> tool to determine all dependencies of a given package.  Library  
> authors should be able to run a tool that determines what's new and  
> what might have changed.  The package author then merely decides  
> whether semantics was changed and if so, in what way (i.e.,  
> compatible or not to previous semantics).  Packages will still carry  
> versions, but they are only used to mark changes.  Semantic  
> information is provided via a "change database" which contains enough  
> information to determine whether a version of a package contains  
> appropriate implementations of the functions (or, more generally,  
> entities) used in a dependent package.
> 
> For example, if we write a program that uses the function 'Foo.foo'  
> contained in package 'foo' and we happen to have used 'foo-0.42' for  
> testing of our program.  Then, given the knowledge that 'Foo.foo' was  
> introduced in 'foo-0.23' and changed semantics in 'foo-2.0' then we  
> know that 'foo >= 0.23 && < 2.0' is the correct and complete  
> dependency description.
> 
> That's the ideal, maybe we can work towards this?
> Or does this sound crazy?

I think extracting package APIs and comparing them across versions is an
excellent thing to do. It'd help users see what has changed and it'd let
us enforce the versioning policy (at least for interface changes, not
for semantic changes).

Having a central collection of those interfaces and using that to work
out which versions of which packages would be compatible with the
program I just wrote is quite an interesting idea.

It's related to what I was saying about identifying code by it's full
interface, as a functor, but then using that to map back to packages
that provide the interface.

Something like that might go some way to addressing David Roundy's quite
legitimate criticism that the system of specifying deps on package names
and versions requires one to know the full development history of that
code, eg to track it across package renames.

However it would only help for the development _history_, we still have
no solution for the problem of packages being renamed (or modules moving
between packages) breaking other existing packages. Though similarly we
have no solution to the problem of modules being renamed. Perhaps it's
just that we have not done much module renaming recently so people don't
see it as an issue.

Duncan