Records in Haskell

Ingo Wechsung ingo.wechsung at
Wed Jan 11 10:39:33 CET 2012

Am 11. Januar 2012 08:42 schrieb Isaac Dupree <
ml at>:

> On 01/10/2012 05:06 AM, Greg Weber wrote:
>> Some of your comments seem to not fully recognize the name-spacing (plus
>> simple type resolution) aspect of this proposal that I probably didn't
>> explain well enough. Or maybe I don't understand your comments.
>> For record.field, field is under the record's namespace. A namespace (from
>> a module or under the new system a record), cannot export conflicting
>> names, and there this system prevents the importer from every having a
>> conflict with a record field name because the field is still under the
>> record's namespace when imported. The type system must resolve the type of
>> the record, and generally the field cannot contribute to this effort.
> (I have only used Haskell for several years, not implemented Haskell
> several times; apologies for my amateurish understanding of the type
> system.)
> So
> 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".

Exactly. More specific, the type must be of the form T a1 ... an, where T
is a type constructor.
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).

> 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)?

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list