Records in Haskell
anthony_clayden at clear.net.nz
Sun Feb 26 06:38:32 CET 2012
Please remember SPJ's request on the Records wiki to stick
to the namespace issue. We're trying to make something
better that H98's name clash. We are not trying to build
some ideal polymorphic record system.
To take the field labelled "name": in H98 you have to
declare each record in a different module and import every
module into your application and always refer to "name"
prefixed by the module.
DORF doesn't stop you doing any of that. So if you think of
each "name" being a different meaning, carry on using
multiple modules and module prefixes. That's as easy (or
difficult) as under H98.
You can declare fieldLabel "name" in one module, import it
unqualified into another and declare more records with a
"name" label -- contrary to what somebody was claiming.
Or you can import fieldLabel "name" qualified, and use it as
a selector function on all record types declared using it.
It's just a function like any other imported/qualified
function, for crying out loud!
So if there's 'your' "name" label and 'my' "name", then use
the module/qualification system as you would for any other
scoped name. Then trying to apply My.name to Your.record
will get an instance failure, as usual.
(And by the way, there's no "DORFistas", let's avoid
personalising this. There are people who don't seem to
understand DORF -- both those criticising and those
----- Original Message Follows -----
> On 2/25/12 10:18 AM, Gábor Lehel wrote:
> > On Sat, Feb 25, 2012 at 3:54 PM, Barney
> Hilken<b.hilken at ntlworld.com> wrote: >> After more
> pondering, I finally think I understand what the DORFistas
> want. Here is an example: >>
> >> You want to define records which describe people, and
> include (among other things) a field called "name". There
> might be several different record types with a name field,
> depending on whether the record refers to a customer, an
> employee, a business contact etc., but in each case "name"
> is the name of the person to which the record refers. You
> then write various functions which assume this, such as >>
> >>> spam :: Has r "name" String => r -> String
> >>> spam r = "Dear " ++ r.name ++ "\nHave you
> heard..." >>
> >> Now I want to define records which describe products,
> and I also use a field "name" in the same way, except that
> it is the brand name of the product. I also define
> functions such as >>
> >>> offer :: Has r "name" String => r -> String
> >>> offer r = "Reduced! " ++ r.name ++ " 50%
> >> It doesn't make any sense to apply your functions to my
> records or vice-versa, but because we both chose the same
> label, the compiler allows it. Putting the code in
> separate modules makes no difference, since labels are
> global. >
> > Exactly!
> FWIW, this is the concern I alluded to earlier. Namely
> that we may want to have two (or more), er, 'classes' of
> records--- where a field is polymorphic over an
> individual class, but we don't want those classes to
> merge simply because they happened to choose the same name
> and type for the field.
> I'm not sure it's a good proposal, but it seems like the
> only way to handle this issue is to (1) introduce a new
> kind for semantically-oriented field names, and (2) make
> the Has class use that kind rather than a type-level
> string. By (1), what I mean is that rather than referring
> to the field as "name", we would declare PersonalName and
> BrandName and then use those in lieu of the string. And if
> we do that, then (2) demands that we must somehow make
> explicit which one we mean, should we want the `name`
> field to be polymorphic for some given record
> Live well,
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users