Simon Marlow wrote:
We already have interfaces, in the sense that a package *is* an interface. You're suggestion decoupling these notions, which I believe would add a lot of extra complexity without enough benefit to make it worthwhile.
Well, a package is an interface in the sense that it incidentially defines one. However, I have no idea how to extract the interface from the package. I also don't really understand how to depend on it (see below). In general, I think it's fair to say that what we have now is somewhat akin to dynamic typing of packages. I'd like to have static typing. I expect the benefits to be similar to those of static over dynamic typing. As to the complexity, I don't think having explicit interfaces would be much more complex than implementing a tool which checks that the package versioning policy is being followed.
Let's take the examples you gave above:
1. several packages could implement the same interface. This can be done by having a single package that exports an interface and depends on one of the underlying "providers" selected at build-time.
By build-time, do you mean when building the application which depends on the interface or when building the interface package? I'm interested in the former but I suspect you mean the latter. As an example, suppose Alice writes a package and Bob writes an application that depends on it. Now, Chris doesn't like Alice and forks her package. He now wants to build Bob's application with his package instead of Alice's. How can he do it at the moment without having Alice and/or Bob apply any patches to their stuff? What if instead of an app, Bob writes a package which other apps depend on?
2. fine-grained dependencies: just split up packages, or define new packages that just re-export parts of existing packages, if that's what you want.
I don't think that splitting up packages is really an option since the packages' authors wouldn't always agree to it and in any case, we don't want to have a lot of artificially small packages. Reexporting would work, I guess, but do I now have to distribute all those packages which just reexport along with my stuff? I general, IMO packages and interfaces are simply at different levels of granularity. To make this more concrete: suppose Alice implements package trees and Bob package containers. Both contain compatible implementations of AVL trees. Chris need AVL trees in his application but doesn't care where they come from and wants his users to be able to pick one when building the app. What does he do? And how do Alice and Bob ensure that their implementations are, in fact, compatible?
3. one package could implement several versions of an interface. This is no different from having several versions of a package that can all be installed and used together.
I have to disagree here. There is quite a difference between maintaining a legacy interface in new versions of software and maintaining several versions of that software. Suppose I write a package and a lot of applications (not necessarily mine) depend on version 1 of that package. Now, for version 2 I completely redesign it such that the interface becomes incompatible with version 1. Unless there is a way for me to somehow provide the version 1 interface in my version 2 package, I'll have to keep maintaining the old version until all those applications migrate. This can be done now, I suppose, but not without jumping through some hoops.
4. interface definitions could have QuickCheck properties. Absolutely! And packages can have QuickCheck properties too.
Of course, but these properties can't be easily shared between packages which implement the same interface. Suppose Alice implements a package and Bob wants to reimplement it. He can copy Alice's QuickCheck properties into his code, of course, but that means that he we now have two sets of those properties which will be maintained separately. Also, these properties aren't really visible to a package's client at the moment since we don't even have a convention where to put those. IIUC, they aren't even considered part of the interface when it comes to package versioning. This is bad!
Using the Package Versioning Policy we have a clear way to know when a package's interface has changed, or when the interface has remained the same but the implementation has changed. We need tool support to check that the author is adhering to the PVP, though.
What will this tool check? That the set of exported names doesn't change? That they have the same signatures? That the QuickCheck properties remain the same? That the package satisfies the same theories (once we have support for formal reasoning)? If the answer to any of the above is no, then why not? On the other hand, if it will do all of the above, then wouldn't it be much easier to explicitly specify the interface instead of having to extract it from the package somehow? Also, I don't really understand how PVP is supposed to work, to be honest. If all I need is function doThis from package foo 1.0, what do I depend on? foo 1.*? What if foo 2.0 has a slightly different interface but still exports doThis? Finally, I was always under the impression that PVP is something we want to have for the core packages. I didn't realise that it is supposed to be a universally accepted policy and I don't think that would work. Almost all software companies, for instance, have their own versioning policy. We can't make them use ours. In general, the larger the Haskell community becomes the less likely it will be that any kind of convention will work. We ought to plan for the future and adopt an approach that scales.
Basically the current scheme minimizes the cognitive load by having a single concept (the package) that embodies several units: distribution, licensing, dependency, linking (amongst others).
I have my doubts about minimizing the cognitive load. To return to the dynamic vs. static typing analogy: although static typing requires more bookkeeping and introduces more concepts, it certainly leads to less cognitive load for me. Abstraction barriers are good! Well, as long as there aren't too many but at the moment, we don't have *any*. Roman