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'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"><<a href="mailto:ml@isaac.cedarswampstudios.org">ml@isaac.cedarswampstudios.org</a>></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't<br>
explain well enough. Or maybe I don't understand your comments.<br>
<br>
For record.field, field is under the record'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'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 "record.field" is something equivalent to "undefined record" (using "undefined" as a function type), and the program is only correct if the type of "record" resolves to a concrete type? I don't know if "concrete type" is at all the right terminology; I mean a type-variable doesn't count (whether class-constrained, "Num a => a", or not, "a", or even "m Int" is not concrete). Is "forall a. Maybe a" okay (if Maybe were a record)? "forall a. Num a => Maybe a"? I'm guessing "yes".<br>
Does it get harder in the presence of the type-system extensions?<br>
"(a ~ SomeRecord) => a": presumably that works with record syntax? Can the compiler always figure out whether or not it can find a type-variable'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'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'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>