Re: Haskell 2010: libraries

On Thu, Jul 16, 2009 at 4:36 AM, Simon Marlow wrote:

On 15/07/2009 18:10, David Menendez wrote:

...

On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow  wrote:

...

On 15/07/2009 15:54, Ian Lynagh wrote:

...

On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:

...

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do).  Most packages will then have dependencies that look like

  build-depends: base-4.*, haskell-std-2010

We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment.

That's the case with base-3/base-4 at the moment.  Is it a problem?

Could I use two packages of arrow code which depend on base 3.0.2 and base 3.0.3, respectively, in the same project?

No.  (though I'm not sure the significance of "arrow code" here).  Is there a package that depends on base-3.0.2, and doesn't work with base-3.0.3?

Any package that defines an Arrow instance can't work with both 3.0.2 and 3.0.3, because they provide incompatible class definitions. (That's where Category was introduced.) It broke at least one package at the time, although I think it's been fixed by now. In http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015774.h..., you argued:

We simply *can't* provide the same API as base-3.0.2 without defining a new Arrow class, and that would kill compatibility with base-4. On the other hand, we did know this could happen (changes to datatypes also cause the same problem), it's the tradeoff with trying to provide base-3 as a compatibility layer over base-4.

Which is probably the right call for obscure classes like Arrow, but not more common ones like Num or Monad. -- Dave Menendez http://www.eyrie.org/~zednenem/ -- Dave Menendez http://www.eyrie.org/~zednenem/