Hi Bas,<br><br><div class="gmail_quote">On Thu, Sep 22, 2011 at 03:55, Bas van Dijk <span dir="ltr"><<a href="mailto:v.dijk.bas@gmail.com">v.dijk.bas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<br>
<br>
I just used the new GHC generics together with the DefaultSignatures<br>
extension to provide a default generic implementation for toJSON and<br>
parseJSON in the aeson package:<br>
<br>
<a href="https://github.com/mailrank/aeson/pull/26" target="_blank">https://github.com/mailrank/aeson/pull/26</a><br>
<br>
It appears that the generic representation of a sum type has a tree shape as in:<br>
<br>
(a :+: b) :+: (c :+: d)<br></blockquote><div><br>That is correct.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
In my case this tree-shaped representation is problematic when parsing<br>
a JSON value to this type. My overloaded parsing function is<br>
parameterized with a key which specifies which of the a, b, c or d<br>
constructors to parse. When it encounters a constructor it checks if<br>
it matches the key, if so it is parsed, if not parsing will fail.<br>
Because of the tree-shaped representation of sum types I have to<br>
recursively parse the left and right branch and join them using <|>:<br>
<br>
<a href="https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3fbb899/Data/Aeson/Types/Internal.hs#L1003" target="_blank">https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3fbb899/Data/Aeson/Types/Internal.hs#L1003</a><br>
<br>
I don't know for sure but I suspect that this can cause memory leaks<br>
since the <|> has to keep the right value in memory when it is parsing<br>
the left.<br></blockquote><div><br>It is not immediately clear to me why this would cause memory leaks...<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Ideally the generic representation of sum types is right associative as in:<br>
<br>
a :+: (b :+: (c :+: d))<br>
<br>
This way I only have to check if 'a' matches, if it does the right<br>
branch can be forgotten.<br>
<br>
Is there a good reason for not having it right associative?<br></blockquote><div><br>The reason is performance. In particular for large datatypes with many constructors, a balanced sum-of-products performs better than a right-nested one. Also, it makes things like writing generic space-efficient encoders/decoders easier.<br>
<br>But I would be very interested in understanding if/how the balanced view leads to a space leak, so please let me know if you can provide some more information.<br><br><br>Thanks,<br>Pedro<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Regards,<br>
<br>
Bas<br>
<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</blockquote></div><br>