On 17 October 2011 16:44, Michael Snoyman <[email protected]> wrote: > On Mon, Oct 17, 2011 at 4:42 PM, Roman Leshchinskiy <[email protected]> > wrote: >> Michael Snoyman wrote: >>> On Mon, Oct 17, 2011 at 12:14 PM, Bas van Dijk <[email protected]> >>> wrote: >>>> >>>> My idea is that when vector-bytestring is as fast as bytestring, it >>>> can replace it. When that happens it doesn't matter if users use the >>>> vector interface. I would even recommend it over using the bytestring >>>> interface so that bytestring can eventually be deprecated in favor of >>>> vector. >>> >>> +1. I'm in favor of using the OverlappingInstances/no newtype and >>> specialized Show instance. I think that, if there was *ever* a case >>> where OverlappingInstances was a good fit, it's this one. We're >>> talking about a single module exporting both the base and overlapped >>> instance, so which instance gets used should be completely decidable. >>> (Unless of course someone defines an orphan instance elsewhere, but >>> that's a different issue IMO.) And even in a worst-case-scenario where >>> somehow we get the wrong instance, we're only talking about output >>> used as a debugging aid, so the damage is minimal. >> >> So suppose we change the Show and Read instances for Storable vectors of >> Word8 and Char. What happens with unboxed and boxed vectors of these >> types? Should these be changed as well? Should these be changed as well? >> If not, why not? > > I don't have any strong opinion on the matter, but it seems like they > may as well be changed also. It seems like all the same "useful for > debugging" arguments would apply there as well. > > Michael >
Yes I think that makes sense. My patch already adds specific Show and Read instances to all vectors of Chars and Word8s: http://trac.haskell.org/vector/ticket/64 Bas _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
