base-3 vs base-4 (Was: Breakage with 6.10)

newer
Strictness in data declaration not...

Niklas Broberg

11 Oct 2008 11 Oct '08

1:52 a.m.

...
Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10?

By having it use base-3 rather than 4.

Right, and that's how I quickly fixed it up for now. But this doesn't sound like a long-term solution to me, I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such? Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?) Cheers, /Niklas

Show replies by date

José Pedro Magalhães

11 Oct 11 Oct

9:41 a.m.

Hello, On Sat, Oct 11, 2008 at 03:52, Niklas Broberg wrote:

...

Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?)

The new syb package has basically all the Data.Generics.* modules. In base4, no Data.Generics.* modules were kept. Instead, a new module, Data.Data, contains all that was in Data.Generics.Basics and most of Data.Generics.Instances. Therefore, in the syb package, Data.Generics.Basics only re-exports module Data.Data from base4, and Data.Generics.Instances defines the instances missing from Data.Data and re-exports the instances from Data.Data. Thanks, Pedro

David Menendez

4:41 p.m.

2008/10/11 José Pedro Magalhães :

...

In base4, no Data.Generics.* modules were kept. Instead, a new module, Data.Data, contains all that was in Data.Generics.Basics and most of Data.Generics.Instances.

Data.Data? Surely we can come up with something better than that. -- Dave Menendez http://www.eyrie.org/~zednenem/

José Pedro Magalhães

5:02 p.m.

On Sat, Oct 11, 2008 at 18:41, David Menendez wrote:

...

2008/10/11 José Pedro Magalhães :

...
In base4, no Data.Generics.* modules were kept. Instead, a new module, Data.Data, contains all that was in Data.Generics.Basics and most of Data.Generics.Instances.

Data.Data? Surely we can come up with something better than that.

Please do. That's the only name that came up in [1]. I think I'd still like Generics.SYB, but that might be too big of a change... Thanks, Pedro [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929/focus=9947

Claus Reinke

10:16 a.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

...

...
...
Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base?

ghc-pkg provides general help for finding packages for modules: $ ghc-pkg find-module Data.Generics.Instances c:/ghc/ghc-6.11.20081004\package.conf: base-3.0.3.0, syb-0.1.0.0 So there is a compatibility module in the new syb. Unfortunately, that won't tell you about the moves and rationale. Most of the time, you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the Haddock pages, or google for "syb" in the libraries@ archives): $ ghc-pkg find-module Data.Data c:/ghc/ghc-6.11.20081004\package.conf: base-4.0.0.0 $ ghc -ignore-dot-ghci -e ':browse Data.Data' | grep class class (Typeable a) => Data a where class Typeable a where typeOf :: a -> TypeRep class Typeable1 t where typeOf1 :: t a -> TypeRep class Typeable2 t where typeOf2 :: t a b -> TypeRep class Typeable3 t where typeOf3 :: t a b c -> TypeRep class Typeable4 t where typeOf4 :: t a b c d -> TypeRep class Typeable5 t where typeOf5 :: t a b c d e -> TypeRep class Typeable6 t where typeOf6 :: t a b c d e f -> TypeRep class Typeable7 t where typeOf7 :: t a b c d e f g -> TypeRep $ ghc -ignore-dot-ghci -e ':info Data.Data.Data' class .. instance ..

...

.. I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such?

I was wondering whether there is a way to set user-defined flags depending on whether some package is available. Then I recalled that flags don't work the way I expected - instead Cabal will try all flag settings to find a buildable configuration (a fact I only became aware of when a different kind of flag was added recently that does behave the way I expected;-). Which might be what you want in this case. Duncan: is this correct, and are these subtleties documented somewhere?

...

Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?)

Pedro: it might be helpful if the haddock pages for the old and new syb modules were to point to a syb wiki page (which could then link to the relevant threads on libraries@)? Or is that information already in the documentation patch for the latest builds? Claus

José Pedro Magalhães

10:25 a.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

Hello, On Sat, Oct 11, 2008 at 12:16, Claus Reinke wrote:

...

Pedro: it might be helpful if the haddock pages for the old and new syb modules were to point to a syb wiki page (which could then link to the relevant threads on libraries@)? Or is that information already in the documentation patch for the latest builds?

That's a good idea. I will set that up and push patches to the haddock documentation of both base and syb to link there. Thanks, Pedro

Niklas Broberg

11:04 a.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

...

So there is a compatibility module in the new syb. Unfortunately, that won't tell you about the moves and rationale. Most of the time, you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the Haddock pages, or google for "syb" in the libraries@ archives):

$ ghc-pkg find-module Data.Data c:/ghc/ghc-6.11.20081004\package.conf: base-4.0.0.0

Thanks a lot Claus and José for the info. Since all I use is the Data and Typeable classes (presumably like so many others, which I guess was the reason to keep these in base), it would obviously be better for me to avoid linking to the new syb package when I don't have to.

...

$ ghc -ignore-dot-ghci -e ':info Data.Data.Data'

Somehow I find this name hilarious. :-)

...

...
.. I would prefer to use the new base-4 when possible. The cabal file already includes a conditional "if flag(splitBase)" to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such?

I was wondering whether there is a way to set user-defined flags depending on whether some package is available. Then I recalled that flags don't work the way I expected - instead Cabal will try all flag settings to find a buildable configuration (a fact I only became aware of when a different kind of flag was added recently that does behave the way I expected;-). Which might be what you want in this case. Duncan: is this correct, and are these subtleties documented somewhere?

While these things would be good to know in general, it seems this is not what I want in this case, since I don't want to use the syb package after all. It seems instead what I want is to simply make a conditional import of either Data.Generics or Data.Data based on which version of base is available. I guess that means more CPP heresy, sigh. Thanks, /Niklas

Don Stewart

5:42 p.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

niklas.broberg:

...

...
So there is a compatibility module in the new syb. Unfortunately, that won't tell you about the moves and rationale. Most of the time, you'll want Data.Data (check "ghc -e ':browse Data.Data'" or the Haddock pages, or google for "syb" in the libraries@ archives):

$ ghc-pkg find-module Data.Data c:/ghc/ghc-6.11.20081004\package.conf: base-4.0.0.0

Thanks a lot Claus and José for the info. Since all I use is the Data and Typeable classes (presumably like so many others, which I guess was the reason to keep these in base), it would obviously be better for me to avoid linking to the new syb package when I don't have to.

Perhaps people could add details about managing the syb handover to the 'upgrading' wiki page, http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC...

José Pedro Magalhães

13 Oct 13 Oct

9:39 a.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

Hello, I created a new wiki page for SYB which also contains some more detailed information on the changes for 6.10: http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB Thanks, Pedro

José Pedro Magalhães

12:02 p.m.

New subject: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

Hello Ian, I'm attaching patches that add a link to the new wiki from the haddock of syb (and change the maintainer to generics@haskell.org). Thanks, Pedro On Mon, Oct 13, 2008 at 11:39, José Pedro Magalhães wrote:

...

Hello,

I created a new wiki page for SYB which also contains some more detailed information on the changes for 6.10: http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB

Thanks, Pedro