Why is Bag's Data instance "broken"?

Edward Kmett ekmett at gmail.com
Wed Aug 29 19:10:40 CEST 2012


I've been meaning to put in a proposal to replace the Data instances for
Map, etc. with one that pretends there is a fake 'fromList' constructor
that restores the invariants.

In my experience this works much better than just making everyone who
relies on Data randomly crash, and it preserves the invariants of the
opaque structure.

I use this approach on many of my own container types.

-Edward

On Wed, Aug 29, 2012 at 7:11 AM, José Pedro Magalhães <jpm at cs.uu.nl> wrote:

> Hi Philip,
>
> On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies <
> pkfh at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120829/41e69c9c/attachment.htm>


More information about the Glasgow-haskell-users mailing list