Records in Haskell
anthony_clayden at clear.net.nz
Wed Feb 29 02:52:29 CET 2012
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:
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
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).
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.
More information about the Glasgow-haskell-users