<br><br><div class="gmail_quote">Am 11. Januar 2012 08:42 schrieb Isaac Dupree <span dir="ltr"><<a href="mailto:ml@isaac.cedarswampstudios.org">ml@isaac.cedarswampstudios.org</a>></span>:<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>
</blockquote><div><br></div><div>Exactly. More specific, the type must be of the form T a1 ... an, where T is a type constructor.</div><div>The a_i are not needed for field selection, but of course *if* a field is found in namespace T, and the construct was r.f then the type checker is going to check (T.f r), hence the type of r must fit the first argument of T.f in the usual way. The type of T.f itself is of course already known (just like that of any other function the currently typechecked function depends on).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
</blockquote><div><br></div><div>I think that the way it is done in the current Frege compiler (note that the language does not prescribe any particular order or way of typechecking) is the one with the worst percentage of "hits", because it's the most simple approach. </div>
<div><br></div><div>-- </div></div><br>Ingo<br>