Records in Haskell

[AntC]

Oliver Batchelor <saulzar <at> gmail.com> writes:

> 
> I think the DORF approach is quite principled in it's namespacing. The
> labels are just normal functions which can be exported and imported
> between modules. I believe that is it's main strength - so I think to
> say "it only solves the narrow name-spacing issue within a module." is
> not quite accurate.
> 

Thank you Oliver, yes you got it. And very restrained of you to say "not quite 
accurate". In the following I shall try to do the 'egoless programmer' thing.

Seeing as DORF's control over namespacing is a considerable improvement over 
SORF (in my view), I'm particularly miffed to see an allegation that it can't 
do EXACTLY WHAT IT'S DESIGNED TO DO.

And since that allegation has been repeated in several places, just so 
there's "no probable possible shadow of doubt, no possible doubt whatever", 
I've updated the wiki with an illustration:
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields
#ImportExportandRepresentationhiding
and attached a working example to the implementor's page.

The example shows that within a single record decl:
  0. You can import fieldLabel decls.
  1. You can create fields that share Labels with imports.
  2. You can create fields that don't share, even with the same Label name.
           (That is, the module system continues to control the namespace.)
  3. You can prevent using the wrong field selector with the wrong record type,
            even if they have the same Label name.

Points 2 and 3 are there especially for all the people who want multiple 
`name`s that label String fields but don't "mean" the same thing.

The example shows that if you use the wrong `name` selector with the wrong 
record type, you get an instance failure (even if the record type has a field 
`name`).

Just before they slip on the straightjacket for all this mumbling about what's 
in a name, one further point:

- if there's a difference of "meaning" going on,
- you can use the type system to manage your meanings,
- with a newtype to screen the representation.

That's what Chris Done's example is doing, and it's a good discipline to 
manage complex data structures. (Thank you Greg for posting it back on to the 
Records wiki front page). 
http://hackage.haskell.org/trac/ghc/wiki/Records#Problemswithusingthecurrentmod
ulenamespacemechanism

Chris's post is what started me down the track of designing DORF, as an 
improvement over SORF, and to avoid the suggestions of sub-modules.

AntC