Some very rough benchmarks: folding over these two implementations of a binary tree<br>data Node1 a = Node1 a (Maybe (Node1 a)) (Maybe (Node1 a))<br><br>data Node2 a = Node2A a | Node2B a (Node2 a) | Node2C a (Node2 a) | Node2D a (Node2 a) (Node2 a)<br>

<br>with the latter of Simon&#39;s examples gives the following measurements when performing 100 traversals over randomly generated trees of size 3000:<br>                min    mean    +/-sd  median    max<br>Packed:    12.001  16.001   4.000  16.001  24.002<br>

Unpacked:  12.000  13.144   1.952  12.001  16.001<br><br>(I&#39;m not entirely sure what I&#39;m doing, as this is my first contribution to the compiler proper, and pointers as to how to obtain more convincing benchmarks would be appreciated.)<br>

<br>My motivation is more philosophical than anything else, though:<br><ul><li>The behavior of unpacking several multi-constructor types can be highly useful to the programmer, and is also (precisely because of the exponential growth) difficult and time-consuming for the programmer to duplicate by hand.  </li>

<li>Currently, UNPACK pragmas have *no effect* when used on multi-constructor types, and give no warnings or other hints that they are having no effect.  There is currently no reason for a programmer to use an UNPACK pragma on a multi-constructor type, so I would not expect to see code bloat occurring in older programs.  The primary exception to this would be in programmers that use the (already regarded as a sledgehammer) -funbox-strict-fields option.</li>

<li>As it stands, it is already the programmer&#39;s burden to know how many constructors an UNPACK&#39;d type has, because the pragma will only have any effect if it is a single-constructor type.  The effect of the proposal is to attach consequences to UNPACKing multi-constructor types, and placing the burden on the programmer to be sure that exponentially great code expansion does not get out of hand.</li>

</ul>The first two bullets are really the ones that grate on me -- that use of the UNPACK pragma in this fashion on multi-constructor types could be seriously useful to a programmer, but currently has no effect, and as a result, I would expect that implementing this proposal wouldn&#39;t cause problems in old programs and could be useful in new ones.<br>

<br>I think I&#39;m making sense.  Would anyone else care to chime in?<br><br>Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br>
<br><br><div class="gmail_quote">On Tue, Jul 21, 2009 at 6:38 PM, Don Stewart <span dir="ltr">&lt;<a href="mailto:dons@galois.com">dons@galois.com</a>&gt;</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;">

Might be interesting to try the transformation manually and benchmark?<br></blockquote></div><br>