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@gregweber.info> wrote:


On Mon, Jan 9, 2012 at 2:22 PM, Isaac Dupree <ml@isaac.cedarswampstudios.org> wrote:
You mean this wiki page, right?:
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing


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 http://www.haskell.org/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