<div>The Frege author does not have a ghc mail list account but gave a more detailed explanation of how he goes about TDNR for records and how often it type checks without annotation in practice. </div><div><br></div><div>

A more general explanation is here:</div><a href="http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/c3di9sw" target="_blank">http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/c3di9sw</a><br>


<br>He sent a specific response to Simon&#39;s mail list message, quoted below:<br><div><br></div><div>Simon Peyton-Jones is absolutely correct when he notes:</div><div><br></div><div>Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the expression e has type t and the type constructor of t is T and there exists a function T.m But that innocent-looking statement begs the *entire* question! How do we know if &quot;e has type t?</div>

<div><br></div><div>The way it is done in Frege is such that, if you have a function that uses or updates (nondestructively, of course) a &quot;record&quot; then at least the type constructor of that record has to be known. This is no different than doing it explicitly with case constructs, etc., just here you learn the types from the constructors you write in the patterns.</div>

<div><br></div><div>Hence, it is not so that one can write a function that updates field f to 42 for any record that contains a field f:</div><div><br></div><div>foo x = x.{f=42}    -- type annotation required for foo or x</div>

<div><br></div><div>In practice this means you&#39;ll have to write a type annotation here and there.</div><div>Often, the field access is not the only one that happens to some variable of record type, or the record is the result of another function application. In such cases, the type is known.</div>

<div>I estimate that in 2/3 of all cases one does not need to write (T.e x) in sparsely type annotated code, despite the fact that the frege type checker has a left to right bias and does not yet attempt to find the type of x in the code that &quot;follows&quot; the x.e construct (after let unrolling etc.)</div>

<div>I think one could do better and guarantee that, if the type of x is inferrable at all, then so will be x.e (Still, it must be more than just a type variable.)</div><br><div class="gmail_quote">On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber <span dir="ltr">&lt;<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones <span dir="ltr">&lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div lang="EN-GB" link="blue" vlink="purple">
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div>
<div>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start
 by using Frege&#39;s document as the proposal. We can start a new wiki page as discussions are needed.</span><u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d">If it’s a serious proposal, it needs a page to specify the design.  Currently all we have is a paragraph on
<a href="http://hackage.haskell.org/trac/ghc/wiki/Records" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/Records</a>, under “Better name spacing”.<u></u><u></u></span></p><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;">As previously stated on this thread, the Frege user manual is available here:</span><u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white"><a href="http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf" target="_blank">http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf</a></span><u></u><u></u></p>




</div>
<div>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)</span><u></u><u></u></p>




</div>
<div>
<p class="MsoNormal" style="margin-left:31.2pt"><u></u> <u></u></p>
</div>
</div><div><div>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">To all those concerned about Records: look at the Frege implementation and poke holes in it.
<span style="color:#1f497d"><u></u><u></u></span></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Well the most obvious issue is this.  3.2 says
<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:31.2pt;text-autospace:none"><i><span style="font-family:CMMI12">e</span></i><span style="font-family:CMSS12">.</span><i><span style="font-family:CMMI12">m
</span></i><span style="font-family:CMR12">= </span><span style="font-family:CMSS12">(</span><i><span style="font-family:CMMI12">T</span></i><span style="font-family:CMSS12">.</span><i><span style="font-family:CMMI12">m e</span></i><span style="font-family:CMSS12">)
 if the expression </span><i><span style="font-family:CMMI12">e </span></i><span style="font-family:CMSS12">has type
</span><i><span style="font-family:CMMI12">t </span></i><span style="font-family:CMSS12">and the type constructor<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:31.2pt"><span style="font-family:CMSS12">of
</span><i><span style="font-family:CMMI12">t </span></i><span style="font-family:CMSS12">is
</span><i><span style="font-family:CMMI12">T </span></i><span style="font-family:CMSS12">and there exists a function
</span><i><span style="font-family:CMMI12">T</span></i><span style="font-family:CMSS12">.</span><i><span style="font-family:CMMI12">m<u></u><u></u></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">But that innocent-looking statement begs the *<b>entire</b>* question!  How do we know if “e has type t?   This is the route ML takes for arithmetic
 operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on.</span> </p></div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div lang="EN-GB" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u><u></u></span></p>




<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you
 end up with<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:4.8pt;text-indent:31.2pt"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><a href="http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields</a></span></p>



</div></div></div></div></div></blockquote><div><br></div></div><div>More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation.</div>


<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">



<div><div><p class="MsoNormal" style="margin-left:4.8pt;text-indent:31.2pt"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Well, so maybe we can give up on that.  Imagine Frege without the above abbreviation.  The basic idea is that field names are rendered unique
 by pre-pending the module name.  As I understand it, to record selection one would then be forced to write (T.m e), to select the ‘m’ field.  That is the, qualification with T is compulsory.   The trouble with this is that it’s *<b>already</b>* possible; simply
 define suitably named fields<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">  data T = MkE { t_m :: Int, t_n :: Bool }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Here I have prefixed with a (lower case version of) the type name.  So we don’t seem to be much further ahead.<u></u><u></u></span></p>




<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Maybe one could make it optional if there is no ambiguity, much like Haskell’s existing qualified names.  But there is considerable ambiguity
 about whether T.m means <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">  m imported from module T<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">or<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">  the m record selector of data type T</span></p></div></div></div></div></div></blockquote>



<div><br></div></div><div>If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T&#39;s module: OtherModule.T.n or T.T.n</div><div>Alternatively these conflicts could be compilation errors.</div>



<div>Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now.</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div lang="EN-GB" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u><u></u></span></p>




<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white">Perhaps one could make it work out.  But before we can talk about it we need to see a design. Which takes us back to the question of leadership.<u></u><u></u></span></p>




<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><br></span></p></div></div></div></div></div></blockquote><div><br></div></div><div>


I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort.</div>
<div><br>At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don&#39;t have convenient access to those fields.</div>



<div>I am contacting the Frege author to see if we can get any more insights on implementation details.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div lang="EN-GB" link="blue" vlink="purple"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><font color="#888888">
Simon<u></u><u></u></font></span></p><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d;background:white"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">We only want critiques about</span><u></u><u></u></p>
</div></div><div>
<div>
<p class="MsoNormal"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">* achieving name-spacing right now</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation
 now, just possibly modify things slightly.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;background:white">Greg Weber</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones &lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt; wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">| The lack of response, I believe, is just a lack of anyone who<br>
| can cut through all the noise and come up with some<br>
| practical way to move forward in one of the many possible<br>
| directions.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">You&#39;re right.  But it is very telling that the vast majority of responses on<br>
       <a href="http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/" target="_blank">http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/</a><br>
were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem.  My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed.<br>




<br>
The trouble is that I just don&#39;t have the bandwidth (or, if I&#39;m honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn&#39;t *that* important to anyone.  That said, it clearly is *somewhat* important to a lot
 of people, so doing nothing isn&#39;t very satisfactory either.<br>
<br>
Usually I feel I know how to move forward, but here I don&#39;t.<br>
<span style="color:#888888"><br>
Simon<br>
<br>
</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div>
</div>
</div>
</div>

</blockquote></div></div><br>
</blockquote></div><br>