<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>What if there is a good reason for a missing/broken Data.Data instance? I'm specifically thinking of GADTs. There are few currently, but I, for one, have toyed with the idea of adding more. My recollection is that Data.Data doesn't work with GADTs. As a concrete, existent example, see CoAxiom.BranchList, which allows for type-level reification of singleton lists as distinct from other, not-necessarily-singleton lists.</div><div><br></div><div>I would very much like to support API usage that would benefit from working Data.Data instances, but I also want to be sure we're not eliminating other possible futures without due discussion.</div><div><br></div><div>Richard</div><br><div><div>On Jul 27, 2014, at 2:04 PM, "Alan & Kim Zimmerman" <<a href="mailto:alan.zimm@gmail.com">alan.zimm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>Philip<br><br></div>How would you like to take this forward? From my side I would appreciate all guidance/help to get it resolved, it is a huge hindrance for HaRe.<br><br></div>Alan<br></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Sun, Jul 27, 2014 at 7:27 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Philip, Alan, <div><br></div><div>If you need a hand, I'm happy to pitch in guidance. <div><br></div><div>I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors like we do now in containers and Text where needed can be used to preserve internal invariants, etc.</div>


<div><br></div><div>This works far better for users of the API than just randomly throwing them a live hand grenade. As I recall, these little grenades in generic programming over the GHC API have been a constant source of pain for libraries like haddock.</div>


<div><br></div><div>Simon,</div><div><br></div><div>It seems to me that regarding circular data structures, nothing prevents you from walking a circular data structure with Data.Data. You can generate a new one productively that looks just like the old with the contents swapped out, it is indistinguishable to an observer if the fixed point is lost, and a clever observer can use observable sharing to get it back, supposing that they are allowed to try.</div>


<div><br></div><div>Alternately, we could use the 'virtual constructor' trick there to break the cycle and reintroduce it, but I'm less enthusiastic about that idea, even if it is simpler in many ways.</div><span class="HOEnZb"><font color="#888888"><div>


<br></div><div>-Edward</div></font></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 27, 2014 at 10:17 AM,  <span dir="ltr"><<a href="mailto:p.k.f.holzenspies@utwente.nl" target="_blank">p.k.f.holzenspies@utwente.nl</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction: ltr; font-family: Tahoma; font-size: 10pt; ">Alan,<br>
<br>
In that case, let's have a short feedback-loop between the two of us. It seems many of these files (Name.lhs, for example) are really stable through the repo-history. It would be nice to have one bigger refactoring all in one go (some of the code could use
 a polish, a lot of code seems removable).<br>
<br>
Regards,<br>
Philip<br>
<br>
<div style="font-family: 'Times New Roman'; font-size: 16px; ">
<hr>
<div style="direction:ltr"><font face="Tahoma"><b>Van:</b> Alan & Kim Zimmerman [<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>]<br>
<b>Verzonden:</b> vrijdag 25 juli 2014 13:44<br>
<b>Aan:</b> Simon Peyton Jones<br>
<b>CC:</b> Holzenspies, P.K.F. (EWI); <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Onderwerp:</b> Re: Broken Data.Data instances<br>
</font><br>
</div><div>
<div></div>
<div>
<div dir="ltr">By the way, I would be happy to attempt this task, if the concept is viable.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jul 24, 2014 at 11:23 PM, Alan & Kim Zimmerman <span dir="ltr">
<<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>While we are talking about fixing traversals, how about getting rid of the phase specific panic initialisers for placeHolderType, placeHolderKind and friends?<br>
<br>
</div>
In order to safely traverse with SYB, the following needs to be inserted into all the SYB schemes (see
<br>
<a href="https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/GhcUtils.hs" target="_blank">https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/GhcUtils.hs</a>)<br>
<br>
-- Check the Typeable items<br>
checkItemStage1 :: (Typeable a) => SYB.Stage -> a -> Bool<br>
checkItemStage1 stage x = (const False `SYB.extQ` postTcType `SYB.extQ` fixity `SYB.extQ` nameSet) x<br>
  where nameSet     = const (stage `elem` [SYB.Parser,SYB.TypeChecker]) :: GHC.NameSet       -> Bool<br>
        postTcType  = const (stage < SYB.TypeChecker                  ) :: GHC.PostTcType    -> Bool<br>
        fixity      = const (stage < SYB.Renamer                      ) :: GHC.Fixity        -> Bool<br>
<br>
</div>
And in addition HsCmdTop and ParStmtBlock are initialised with explicit 'undefined values.<br>
<br>
</div>
Perhaps use an initialiser that can have its panic turned off when called via the GHC API?<br>
<br>
</div>
Regards<br>
</div>
  Alan<br>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>
<div>On Thu, Jul 24, 2014 at 11:06 PM, Simon Peyton Jones <span dir="ltr">
<<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div bgcolor="white" lang="EN-GB">
<div>
<div><p class="MsoNormal" style="margin-left:36.0pt">So... does anyone object to me changing these "broken" instances with the ones given by DeriveDataTypeable?<br>
<br>
<u></u><u></u></p>
</div><p class="MsoNormal" style="margin-left:4.9pt">That’s fine with me provided (a) the default behaviour is not immediate divergence (which it might well be), and (b) the pitfalls are documented.<u></u><u></u></p><p class="MsoNormal" style="margin-left:4.9pt"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:4.9pt">Simon<span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span style="color:windowtext" lang="EN-US">From:</span></b><span style="color:windowtext" lang="EN-US"> "Philip K.F. Hölzenspies" [mailto:<a href="mailto:p.k.f.holzenspies@utwente.nl" target="_blank">p.k.f.holzenspies@utwente.nl</a>]
<br>
<b>Sent:</b> 24 July 2014 18:42<br>
<b>To:</b> Simon Peyton Jones<br>
<b>Cc:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Re: Broken Data.Data instances<u></u><u></u></span></p>
</div>
</div>
<div>
<div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Dear Simon, et al,<br>
<br>
These are very good points to make for people writing such traversals and queries. I would be more than happy to write a page on the pitfalls etc. on the wiki, but in my experience so far, exploring the innards of GHC is tremendously helped by trying small
 things out and showing (bits of) the intermediate structures. For me, personally, this has always been hindered by the absence of good instances of Data and/or Show (not having to bring DynFlags and not just visualising with the pretty printer are very helpful).<br>



<br>
So... does anyone object to me changing these "broken" instances with the ones given by DeriveDataTypeable?<br>
<br>
Also, many of these internal data structures could be provided with useful lenses to improve such traversals further. Anyone ever go at that? Would be people be interested?<br>
<br>
Regards,<br>
Philip<br>
<br>
<br>
<span style="font-size:12.0pt"><u></u><u></u></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div style="margin-left:18.75pt;margin-top:22.5pt;margin-right:18.75pt;margin-bottom:7.5pt">
<div style="border:none;border-top:solid #edeef0 1.0pt;padding:4.0pt 0cm 0cm 0cm;display:table">
<div><p class="MsoNormal" style="vertical-align:middle"><span><image001.jpg></span><u></u><u></u></p>


</div>
<div><p class="MsoNormal" style="vertical-align:middle"><a href="mailto:simonpj@microsoft.com" target="_blank"><b>Simon Peyton Jones</b></a><u></u><u></u></p>
</div>
<div><p class="MsoNormal" style="vertical-align:middle"><span style="color:#9fa2a5">24 Jul 2014 18:22</span><u></u><u></u></p>
</div>
</div>
</div>
<div style="margin-left:18.0pt;margin-right:18.0pt"><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d">GHC’s data structures are often mutually recursive. e.g.</span><u></u><u></u></p><p><u></u><span style="font-family:Symbol;color:#888888"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:12.0pt;color:#1f497d">The TyCon for Maybe contains the DataCon for Just</span><span style="color:#888888"><u></u><u></u></span></p><p><u></u><span style="font-family:Symbol;color:#888888"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:12.0pt;color:#1f497d">The DataCon For just contains Just’s type</span><span style="color:#888888"><u></u><u></u></span></p><p><u></u><span style="font-family:Symbol;color:#888888"><span>·<span style="font:7.0pt "Times New Roman"">       
</span></span></span><u></u><span style="font-size:12.0pt;color:#1f497d">Just’s type contains the TyCon for Maybe</span><span style="color:#888888"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d">So any attempt to recursively walk over all these structures, as you would a tree, will fail. 
</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d">Also there’s a lot of sharing.  For example, every occurrence of ‘map’ is a Var, and inside that Var is map’s type, its strictness, its rewrite RULE, etc etc.  In walking over a term you may
 not want to walk over all that stuff at every occurrence of map.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d">Maybe that’s it; I’m not certain since I did not write the Data instances for any of GHC’s types</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d">Simon</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:12.0pt;color:#1f497d"> </span><u></u><u></u></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs [<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">mailto:ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b><a href="mailto:p.k.f.holzenspies@utwente.nl" target="_blank">p.k.f.holzenspies@utwente.nl</a><br>
<b>Sent:</b> 24 July 2014 16:42<br>
<b>To:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Broken Data.Data instances</span><u></u><u></u></p>
</div>
</div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Dear GHC-ers,</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Is there a reason for explicitly broken Data.Data instances? Case in point:</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> instance Data Var where</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">>   -- don't traverse?</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">>   toConstr _   = abstractConstr "Var"</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">>   gunfold _ _  = error "gunfold"</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">>   dataTypeOf _ = mkNoRepType "Var"</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">I understand (vaguely) arguments about abstract data types, but this also excludes convenient queries that can, e.g. extract all types from a CoreExpr. I had hoped to do stuff like this:</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> collect :: (Typeable b, Data a, MonadPlus m) => a -> m b</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> collect = everything mplus $ mkQ mzero return</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> allTypes :: CoreExpr -> [Type]</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">> allTypes = collect</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Especially when still exploring (parts of) the GHC API, being able to extract things in this fashion is very helpful. SYB’s “everything” being broken by these instances, not so much.</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Would a patch “fixing” these instances be acceptable?</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Regards,</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US">Philip</span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p><p class="MsoNormal"><span lang="EN-US"> </span><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div>
</div>
</div>

<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>ghc-devs mailing list<br><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>http://www.haskell.org/mailman/listinfo/ghc-devs<br></blockquote></div><br></body></html>