Roman Leshchinskiy wrote:
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is
that they can be made sound with not much difficulty. If I say that
my package depends on base==3.0 and network==1.0, then I can guarantee
that as long as those dependencies are present then my package will
build. ("but but but..." I hear you say - don't touch that keyboard
yet!)
Suppose you used autoconf tests instead. You might happen to know
that Network.Socket.blah was added at some point and write a test for
that, but alas if you didn't also write a test for Network.Socket.foo
(which your code uses but ends up getting removed in network-1.1) then
your code breaks. Autoconf doesn't help you make your configuration
sound, and you get no prior guarantee that your code will build.
Cabal doesn't give this guarantee, either, since it allows you to depend
on just network or on network>x.
Indeed. That's why I was careful not to say that Cabal gives you the
guarantee, only that it's easy to achieve it.
Both systems are flawed, but neither fundamentally. For Cabal I think
it would be interesting to look into using more precise dependencies
(module.identifier::type, rather than package-version) and have them
auto-generated. But this has difficult implications: implementing
cabal-install's installation plans becomes much harder, for example.
Interesting. From our previous discussion I got the impression that you
wouldn't like something like this. :-)
Sorry for giving that impression. Yes I'd like to solve the problems that
Cabal dependencies have, but I don't want the solution to be too costly -
first-class interfaces seem too heavyweight to me. But I do agree with
most of the arguments you gave in their favour.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
