Hello Neil,<br><br><div class="gmail_quote">On Thu, Nov 27, 2008 at 13:17, Neil Mitchell <span dir="ltr"><<a href="mailto:ndmitchell@gmail.com">ndmitchell@gmail.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;">
Hi José,<br>
<br>
You may also want to weigh in on this issue:<br>
<br>
<a href="http://hackage.haskell.org/trac/ghc/ticket/2782" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/2782</a><br>
<br>
The instance of Ratio changed between 6.10 and 6.8 in a way that means<br>
a program can't reflect on the fields contained within the :%<br>
constructor using the value undefined. The reason is that :% is marked<br>
as strict in both arguments, so _|_ :% _|_ == _|_. This breaks<br>
Uniplate, and I've had to explicitly make a test for a type of<br>
Rational in the Uniplate code - which is ugly. I'm not sure how many<br>
other programs this might break - or if the impact was well understood<br>
when the change was made.<br>
<br>
This change is made massively worse by giving the error message<br>
"undefined" when it fails! If an SYB using program goes from working<br>
in GHC 6.8 to failing in GHC 6.10 with "undefined", this may be a<br>
culprit.</blockquote><div><br>I see that this in particular has been fixed already.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
I'm not sure there is a nice solution - reflection at the type level<br>
(using _|_ at the value level), combined with strictness at the value<br>
level, has limitations. It may be that the reflection machinery in SYB<br>
can be tweaked to either alert the user in advance (i.e. by getting<br>
the strictness of various fields), or providing some operation<br>
combining gmapQ and fromConstr which isn't strict. To see my use case<br>
take a look at "contains" in:<br>
<br>
<a href="http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs" target="_blank">http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/PlateData.hs</a></blockquote><div><br>I'm not sure there's an easy solution either. As you say, the problem here seems to be caused by the strictness. Getting the strictness of each field would require changes to the representation types and to the deriving mechanism.<br>
<br>Would your problem be solved if you used fromConstrB instead of simply fromConstr and built an entirely determined (without bottoms) value?<br><br><br>Thanks,<br>Pedro</div></div><br>