Thanks. And here is one more http://hackage.haskell.org/trac/ghc/ticket/2750 For potentially-breaking changes the right thing to do is to announce (and justify) the proposed change using the usual library-change protocol, with a discussion period. The important thing is that someone is driving the discussion -- thank you very much for that. I'll assign these tickets to you. Simon From: josepedromagalhaes@gmail.com [mailto:josepedromagalhaes@gmail.com] On Behalf Of José Pedro Magalhães Sent: 21 November 2008 15:30 To: Simon Peyton-Jones Cc: libraries@haskell.org; Generics Mailing List Subject: Re: Generics Hello Simon, Thanks for pointing these out to me. I won't be able to look into this for the next week, but from what I could see so far, #2760 seems easy: copy mkNorepType to mkNoRepType, mark mkNorepType as deprecated and replace usage everywhere to avoid warnings and pass validation. I can submit the patch for this. #2759 has some deeper implications, though. Replacing the FloatConstr Double by FloatConstr Rational might break existing client code (even though it probably wouldn't be too hard to fix it). Additionally, I see that the serializer code in compiler/utils/Serialized.hs would also need changes (it's no longer serializing a Double). But I guess this is also not too problematic... Cheers, Pedro On Fri, Nov 21, 2008 at 13:34, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote: Jose As part of your work on the SYB library, could you spare the time to look into these two library bug reports? http://hackage.haskell.org/trac/ghc/ticket/2759 http://hackage.haskell.org/trac/ghc/ticket/2760 Many thanks Simon

Hello Neil, On Thu, Nov 27, 2008 at 13:17, Neil Mitchell wrote:

Hi José,

You may also want to weigh in on this issue:

http://hackage.haskell.org/trac/ghc/ticket/2782

The instance of Ratio changed between 6.10 and 6.8 in a way that means a program can't reflect on the fields contained within the :% constructor using the value undefined. The reason is that :% is marked as strict in both arguments, so _|_ :% _|_ == _|_. This breaks Uniplate, and I've had to explicitly make a test for a type of Rational in the Uniplate code - which is ugly. I'm not sure how many other programs this might break - or if the impact was well understood when the change was made.

This change is made massively worse by giving the error message "undefined" when it fails! If an SYB using program goes from working in GHC 6.8 to failing in GHC 6.10 with "undefined", this may be a culprit.

I see that this in particular has been fixed already.

I'm not sure there is a nice solution - reflection at the type level (using _|_ at the value level), combined with strictness at the value level, has limitations. It may be that the reflection machinery in SYB can be tweaked to either alert the user in advance (i.e. by getting the strictness of various fields), or providing some operation combining gmapQ and fromConstr which isn't strict. To see my use case take a look at "contains" in:

http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs

I'm not sure there's an easy solution either. As you say, the problem here seems to be caused by the strictness. Getting the strictness of each field would require changes to the representation types and to the deriving mechanism. Would your problem be solved if you used fromConstrB instead of simply fromConstr and built an entirely determined (without bottoms) value? Thanks, Pedro

Hello Neil, On Thu, Dec 11, 2008 at 09:49, Neil Mitchell wrote:

Hi Pedro,

...

...

I'm not sure there is a nice solution - reflection at the type level (using _|_ at the value level), combined with strictness at the value level, has limitations. It may be that the reflection machinery in SYB can be tweaked to either alert the user in advance (i.e. by getting the strictness of various fields), or providing some operation combining gmapQ and fromConstr which isn't strict. To see my use case take a look at "contains" in:

http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs

I'm not sure there's an easy solution either. As you say, the problem here seems to be caused by the strictness. Getting the strictness of each field would require changes to the representation types and to the deriving mechanism.

Would your problem be solved if you used fromConstrB instead of simply fromConstr and built an entirely determined (without bottoms) value?

I might be able to use fromConstrB, but it requires a lot more work - initialising lots of things and creating lots of dummy values. I'll look into it.

Would this help? {-# LANGUAGE ScopedTypeVariables #-}

{-# LANGUAGE FlexibleContexts #-}

module Data.Generics.Builders (empty) where

import Data.Data import Data.Generics.Aliases (extB)

-- | Construct the empty value for a datatype. For algebraic datatypes, the -- leftmost constructor is chosen. empty :: forall a. Data a => a empty = general `extB` char `extB` int `extB` integer `extB` float `extB` double where -- Generic case general :: Data a => a general = fromConstrB empty (indexConstr (dataTypeOf general) 1)

-- Base cases char = '\NUL' int = 0 :: Int integer = 0 :: Integer float = 0.0 :: Float double = 0.0 :: Double

I also note that the documentation for fromConstrB seems to have disappeared. See: http://haskell.org/ghc/docs/latest/html/libraries/syb/doc-index.html - the entry is still there but the link is gone.

fromConstrB is not in the syb package. It's in base4, in Data.Data: http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Data.html#v%... Thanks, Pedro

(I'm also aware that the Hoogle documentation for it is missing, but hope to fix that this weekend - I've had issues trying to build things)

Thanks

Neil

On Thu, Dec 11, 2008 at 09:57, Neil Mitchell wrote:

HI Pedro,

...

Would this help?

...

{-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-}

module Data.Generics.Builders (empty) where

import Data.Data import Data.Generics.Aliases (extB)

-- | Construct the empty value for a datatype. For algebraic datatypes, the -- leftmost constructor is chosen. empty :: forall a. Data a => a empty = general `extB` char `extB` int `extB` integer `extB` float `extB` double where -- Generic case general :: Data a => a general = fromConstrB empty (indexConstr (dataTypeOf general) 1)

-- Base cases char = '\NUL' int = 0 :: Int integer = 0 :: Integer float = 0.0 :: Float double = 0.0 :: Double

Yep, that should do it!

It's slated for release with the next version of the SYB library, so in a near future you'll only need to import it. Cheers, Pedro