That is a downside the Frege author had - one of the reasons he abandandoned this style of implementation. It is listed on the wiki.<br><br><div class="gmail_quote">On Sat, Jan 14, 2012 at 3:28 PM, Jan-Willem Maessen <span dir="ltr">&lt;<a href="mailto:jmaessen@alum.mit.edu">jmaessen@alum.mit.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones<br>
&lt;<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>&gt; wrote:<br>
&gt; [... good summary of the issues...]<br>
<div class="im">&gt; But note what has happened: we have simply re-invented SORF.  So the<br>
&gt; conclusion is this:<br>
&gt;<br>
&gt;   the only sensible way to implement FDR is using SORF.<br>
<br>
</div>An obvious question at this point: can records have unboxed fields?<br>
I&#39;m worried a bit about the kinds that can appear in a has constraint:<br>
<div class="im"><br>
&gt; A feature of SORF is that you can write functions like this<br>
&gt;<br>
&gt;   k :: Has r &quot;f&quot; Int =&gt; r -&gt; Int<br>
&gt;   k r = r.f + 1<br>
<br>
</div>I&#39;m thinking out loud about the implementation implications here.<br>
<font color="#888888"><br>
-Jan-Willem Maessen<br>
</font></blockquote></div><br>