I added your relevant previous notes to the wiki page. I have no idea if what you said about type inference is right or wrong. I don&#39;t think that record fields can be called scope resolution in a normal sense - the scope is guaranteed to resolve without conflict (unless the user incorrectly types the field name).<div>

<br></div><div>We do need those very familiar with the GHC internals to weigh in with any implementation objections.<div><br><div class="gmail_quote">On Tue, Jan 10, 2012 at 11:42 PM, Isaac Dupree <span dir="ltr">&lt;<a href="mailto:ml@isaac.cedarswampstudios.org">ml@isaac.cedarswampstudios.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/10/2012 05:06 AM, Greg Weber wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some of your comments seem to not fully recognize the name-spacing (plus<br>
simple type resolution) aspect of this proposal that I probably didn&#39;t<br>
explain well enough. Or maybe I don&#39;t understand your comments.<br>
<br>
For record.field, field is under the record&#39;s namespace. A namespace (from<br>
a module or under the new system a record), cannot export conflicting<br>
names, and there this system prevents the importer from every having a<br>
conflict with a record field name because the field is still under the<br>
record&#39;s namespace when imported. The type system must resolve the type of<br>
the record, and generally the field cannot contribute to this effort.<br>
</blockquote>
<br></div>
(I have only used Haskell for several years, not implemented Haskell several times; apologies for my amateurish understanding of the type system.)<br>
<br>
So<br>
Type inference proceeds assuming that &quot;record.field&quot; is something equivalent to &quot;undefined record&quot; (using &quot;undefined&quot; as a function type), and the program is only correct if the type of &quot;record&quot; resolves to a concrete type? I don&#39;t know if &quot;concrete type&quot; is at all the right terminology; I mean a type-variable doesn&#39;t count (whether class-constrained, &quot;Num a =&gt; a&quot;, or not, &quot;a&quot;, or even &quot;m Int&quot; is not concrete).  Is &quot;forall a. Maybe a&quot; okay (if Maybe were a record)? &quot;forall a. Num a =&gt; Maybe a&quot;?  I&#39;m guessing &quot;yes&quot;.<br>


Does it get harder in the presence of the type-system extensions?<br>
&quot;(a ~ SomeRecord) =&gt; a&quot;: presumably that works with record syntax?  Can the compiler always figure out whether or not it can find a type-variable&#39;s concrete type?<br>
<br>
My concept of Haskell is that (except for Template Haskell), scope resolution happens before type inference happens, no exceptions.  So you&#39;re deliberately breaking that pattern.  Right?<br>
<br>
Does this order of stages (regular scope selection, then type inference, then record scope) make as high a fraction of code work as Frege&#39;s left-to-right model (which I am guessing interleaves type inference and record scope selection as it proceeds left-to-right through the program)?<br>


<br>
Correct me if I got something wrong,<br><font color="#888888">
<br>
-Isaac<br>
</font></blockquote></div><br></div></div>