[Haskell-cafe] Records in Haskell
anthony_clayden at clear.net.nz
Thu Mar 1 10:10:37 CET 2012
Evan Laforge <qdunkan <at> gmail.com> writes:
> [ ccing the list because the wiki page was flawed and I made a bunch
> of changes, hope you don't mind ]
Thanks Evan, I've had a quick read through.
It's a bit difficult to compare to the other proposals.
I can't see discussion of extracting higher-ranked functions and applying them
in polymorphic contexts. (This is SPJ's `rev` example.)
Putting h-r fields into records is the standard way of emulating object-
oriented style. SPJ's view is that requirement is "very important in practice".
(No proposal has a good answer to updating h-r's, which you do discuss.)
Re the cons 1. "Still can't have two records with the same field name in the
same module since it relies on modules for namespacing."
Did you see the DORF precursor page ?
I tried to figure out if that would help, but I suspect not. (Looking at the
desugar for `deriving (Lens)`, you need the H98 field selector functions.)
Then for me, cons 1. is a show-stopper. (I know you think the opposite.)
I also don't see whether you can 'hide' or make abstract the representation of
a record type, but still allow read-access to (some of) its fields. Suppose a
malicious client declares a record with field #a. Can you stop them reading
and/or updating your field #a whilst still letting them see field #b of your
With SDNR, is it possibly to define a polymorphic field selector function? I
suspect no looking at the desugar for `deriving (Lens)`, but perhaps I've mis-
understood. I mean:
get_a r = ?? #a r -- gets the #a field from any record r
This mechanism then supports the idea of 'virtual' fields -- SPJ's example of
fullName, built from polymorphic firstName and lastName.
[By the way, did you mean to post to the cafe only? Most of the discussion is
going on on ghc-users.]
More information about the Haskell-Cafe