Records in Haskell

Greg Weber greg at
Tue Jan 10 11:06:16 CET 2012

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.

Otherwise the comments have some good ideas and details that I will have
time to look over in more detail and incorporate into the wiki later.

On Mon, Jan 9, 2012 at 6:07 PM, Greg Weber <greg at> wrote:

> On Mon, Jan 9, 2012 at 2:22 PM, Isaac Dupree <
> ml at> wrote:
>> You mean this wiki page, right?:
>>  That is, there are no fundamental
>>> objections to the implementation of this records implementation.
>> I think that might be overly optimistic... I think there's a risk that
>> SPJ finds an irritating complication to type inference & the rest of us
>> aren't type-system-savvy enough to continue trying to guess at that :) But
>> I think you're referring to whether we object to ad-hoc overloading of
>> record field names (neither parametric nor class-based polymorphism), if no
>> difficulties crop up.  Some of the concerns on**
>> haskellwiki/**TypeDirectedNameResolution<>apply -- I'm not sure to what extent, but address those concerns rather
>> than require those people to repeat themselves again! :)
>> (If we dodge all those obstacles, well, a better record system is better!)
> This shouldn't complicate type inference (other than the fact that we must
> avoid a left-right bias?) because the record field names are not overloaded
> - instead it puts some burden back on the user to add more type
> annotations. The difficult aspect of TDNR was that it was assuming
> overloading - although there is really no reason why it can't instead
> assume name-spacing. TDNR and this record proposal share many of the same
> syntax issues you list. Thanks for the detailed feedback! I am travelling
> right now, will review when I get a chance.
> Greg Weber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list