Re: Syb Renovations? Issues with Data.Generics

Ian Lynagh wrote:
If so, the first "pro" isn't a pro at all. Debatably it's a con - it would make it less convenient to derive instance Data for types containing IO etc.
maybe in those cases of "convenience" we could use a tool like Data.Derive, and make some name to derive with it like "DubiousData". Then the dubious Data instances wouldn't have to be defined/imported. I wonder if it would be possible to have Derive have a "NotSoDubiousData" that somehow figured out whether dubious types were involved and rejected them.. (Admittedly, last I tried, using Derive or DrIFT for a project that wasn't using it already, was much harder than the built-in deriving mechanism) here's an example (which don't know enough to say whether it supports any particular position) : say we have a type data Something a = Something a (IO a) If we want instance (Data a) => Data (Something a) ignoring the IO member but traversing the "a" member, then if we use the normal deriving where we have dubious instances, then (Something (a->b)) is going to be in Data even if it shouldn't be, and it will be easy not to notice. Given how popular polymorphism is in Haskell, I guess this is fairly likely to happen? -Isaac

maybe in those cases of "convenience" we could use a tool like Data.Derive, and make some name to derive with it like "DubiousData". Then the dubious Data instances wouldn't have to be defined/imported. I wonder if it would be possible to have Derive have a "NotSoDubiousData" that somehow figured out whether dubious types were involved and rejected them..
generating instances of a different class might lead to ambiguities/ overlaps in use, but I like the idea of making deriving smarter to get rid of dummy instances. Let me see if I got your idea correctly. data Something a = Something a (IO a) Currently, we have two choices to get 'Data Something': - use naive deriving, for which we'd need to supply both 'Data a' and 'Data (IO a)', with unwanted consequences for the latter - write the Data instance for Something by hand, skipping the 'IO a' component If deriving was only a little bit smarter, we could write: data Something a = Something a {-# Data: skip #-} (IO a) deriving (Data,Typeable) and the deriving mechanism could give us a modified Data instance for Something that doesn't need 'Data (IO a)'. No need for instances we can't really write, and a clear hint in the source code that the 'IO a' component is treated specially (skipped rather than traversed)! I like the idea, Claus
participants (2)
-
Claus Reinke
-
Isaac Dupree