The missing dataCast1 is just a bug, yes. I suppose someone who uses Bag and cares can submit something about fixing gunfold.
On Thu, Sep 20, 2012 at 7:22 AM, José Pedro Magalhães <j...@cs.uu.nl> wrote: > Right now I was just planning to fix the missing dataCast1 from Bag, and > the rest from > Data.Data (see http://hackage.haskell.org/trac/ghc/ticket/7256). I think > those are just > a bug, unrelated to the abstraction story, no? > > > Cheers, > Pedro > > > On Thu, Sep 20, 2012 at 12:19 PM, Edward Kmett <ekm...@gmail.com> wrote: > >> Note: It was probably built with an eye towards how Data.Map and the like >> performed abstraction. However, This isn't necessary to protect the >> invariants of a bag. >> >> The constructors exposed via Data do not have to be the actual >> constructors of the data type. With this you can quotient out the portions >> of the structure you don't want the user to be able to inspect. >> >> See the libraries@ proposal that I put in 3-4 weeks ago (which will have >> just passed) to fix all the broken Data instances for containers by using >> virtual constructors such as 'fromList', (which incidentally led to Milan >> finding huge space and time improvements in fromList). >> >> Effectively allowing the user to use the 'listToBag' as a "constructor" >> loses no information violates no invariants, and prevents code written for >> uniplate, SYB, etc. from having to crash, panic or give up upon the sight >> of a mkNoRepType. >> >> My reaction for years to the sight of a mkNoRepType and undefined gunfold >> has been to hang my head. Now I just fix them. >> >> -Edward >> >> On Wed, Aug 29, 2012 at 7:11 AM, José Pedro Magalhães <j...@cs.uu.nl>wrote: >> >>> Hi Philip, >>> >>> On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies < >>> p...@st-andrews.ac.uk> wrote: >>> >>>> Dear GHCers, >>>> >>>> I'm performing traversals over GHC-API results (HsSyn et al). For this >>>> purpose, I'm using SYB generics. >>>> >>>> I found that I couldn't use "ext1Q" for a function with type "Data x => >>>> Bag x -> String", i.e. that this function was never applied. The source of >>>> Bag's instance of the Data class seems to explain why: >>>> >>>> >>>> instance Data a => Data (Bag a) where >>>> gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type >>>> abstractly >>>> toConstr _ = abstractConstr $ "Bag("++show (typeOf >>>> (undefined::a))++")" >>>> gunfold _ _ = error "gunfold" >>>> dataTypeOf _ = mkNoRepType "Bag" >>>> >>>> >>>> Is there a rationale to not allow gunfolds and to keep toConstr >>>> abstract? >>> >>> >>> As far as I understand, this is to keep `Bag` itself abstract, >>> preventing users from inspecting its internals. >>> >>> >>>> More to the point for my needs, is there a reason to not allow >>>> dataCast1 casting of Bags? >>>> >>> >>> That is a separate issue; I believe this instance is just missing a >>> `dataCast1 = gcast1` line. >>> All datatypes of kind `* -> *` should have such a definition. >>> >>> (Having a look at Data.Data, I guess the same applies to `Ptr a` and >>> `ForeignPtr a`. >>> And `Array a b` seems to be missing the `dataCast2` method. I propose >>> fixing all of these.) >>> >>> >>> Cheers, >>> Pedro >>> >>> >>>> >>>> Regards, >>>> Philip >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users@haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
