<div dir="ltr">Hello,<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 13:57, Ross Paterson <span dir="ltr"><<a href="mailto:ross@soi.city.ac.uk">ross@soi.city.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another attempt:<br>
<br>
These [standard] instances are uncontroversial and can accompany the<br>
Data class:<br>
<br>
[] Maybe Either () tuples<br>
Bool Ordering Char Double Float Integer<br>
<div class="Ih2E3d"> Int Int8 Int16 Int32 Int64 Word Word8 Word16 Word32 Word64<br>
<br>
</div>These instances could also be [standard], after fixing:<br>
<br>
Ratio Complex</blockquote><div><br>So Ratio would have to be given a proper gfoldl definition, to fits its unfold:<br><blockquote style="font-family: courier new,monospace;">gunfold k z c | constrIndex c == 1 = k (k (z (:%)))<br>
</blockquote><br>Complex has a derived instance. In Data.Complex:<br><blockquote style="font-family: courier new,monospace;">data (RealFloat a) => Complex a<br> = !a :+ !a <br># if __GLASGOW_HASKELL__<br> deriving (Eq, Show, Read, Data)<br>
# else<br> deriving (Eq, Show, Read)<br># endif<br></blockquote>Was there a problem with this?<br><br><br></div></div>Regarding the other places that have to be changed [1]:<br><blockquote><span style="font-family: courier new,monospace;">./array/Data/Array.hs</span><br>
</blockquote>The Data instance of Array should be moved from Data.Generics.Instances into Array, to avoid syb dependency.<br><blockquote><span style="font-family: courier new,monospace;">./containers/Data/IntMap.hs</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">./containers/Data/IntSet.hs</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">./containers/Data/Map.hs</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">./containers/Data/Sequence.hs</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">./containers/Data/Set.hs</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">./containers/Data/Tree.hs</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">./network/Network/URI.hs</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">./packedstring/Data/PackedString.hs</span><br></blockquote>As far as I can see, these are not problematic, but the imports should be fixed to avoid bringing into scope all the instances.<br>
<blockquote><span style="font-family: courier new,monospace;">./haskell-src/Language/Haskell/Syntax.hs</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">./template-haskell/Language/Haskell/TH/Quote.hs</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">./template-haskell/Language/Haskell/TH/Syntax.hs</span><br></blockquote>The use of Ratio instances here is not problematic if the instance for Ratio is fixed?<br><blockquote>
<span style="font-family: courier new,monospace;">./bytestring/Data/ByteString/Internal.hs</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">
./bytestring/Data/ByteString/Lazy/Internal.hs</span><span style="font-family: courier new,monospace;"></span><br></blockquote>These depend on an instance for ForeignPtr Word8. What to do here? Reclassify instances for types with phantom types into "standard", since there is nothing to traverse?<br>
<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 13:23, Claus Reinke <span dir="ltr"><<a href="mailto:claus.reinke@talk21.com">claus.reinke@talk21.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(*) of course, it would be nice if ghc's deriving mechanism was<br>
based on a derived instance specification in the module providing<br>
the class, rather than being hardcoded into the compiler itself;<br>
so even with 'Data' out of 'base', that part currently cannot be<br>
changed without updating ghc. or if class aliases allowed the<br>
generated old-style 'Data' instances to be re-interpreted as<br>
'DataA' and 'DataB' instances.. but none of that is realistic for<br>
the current split decision.</blockquote><div><br>I fully agree that the deriving mechanism should be customizable. That would make generic programming in general much nicer in Haskell. However, I don't think it's realistic to expect such changes for 6.10...<br>
</div></div><br><br>Thanks,<br>Pedro<br><br>[1] <a href="http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957">http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957</a><br></div>