Wren/all 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 supporting.) AntC ----- Original Message Follows -----

...

On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken wrote: >> After more

...

...

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

On 2/25/12 10:18 AM, Gábor Lehel wrote: pondering, I finally think I understand what the DORFistas want. Here is an example: >> 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%

off!"

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 declaration.

-- Live well, ~wren

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users