Records in Haskell

[Greg Weber]

I looked at the DORF implementers view
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView

It appears that we still have no solution for record updates that
change the type of a polymorphic field.
I think this means we need to look to ways to solve this update issue
other than just de-sugaring to typeclasses.

On Thu, Feb 23, 2012 at 5:01 PM, Greg Weber <greg at gregweber.info> wrote:
> On Thu, Feb 23, 2012 at 4:25 PM, AntC <anthony_clayden at clear.net.nz> wrote:
>> Greg Weber <greg <at> gregweber.info> writes:
>>
>>>
>>> Thanks to Anthony for his DORF proposal, and spending time to clearly
>>> explain it on the wiki.
>>>
>>> I have a big issue with the approach as presented - it assumes that
>>> record fields with the same name should automatically be shared. As I
>>> have stated before, to avoid circular dependencies, one is forced to
>>> declare types in a single module in Haskell that would ideally be
>>> declared in a multiple modules. ...
>>
>> Thanks Greg, but I'm struggling to understand what the difficulty is with
>> sharing the same name, or why your dependencies are circular. Would you be
>> able to post some code snippets that illustrate what's going on (or what's
>> failing to go on)?
>>
>> Or perhaps this is an experience from some application where you weren't using
>> Haskell? Could you at least describe what was in each record type?
>
> You can get an idea of things in the section 'Problems with using the
> module namespace mechanism' here:
> http://hackage.haskell.org/trac/ghc/wiki/Records?version=4
> The attachment that Chris Done left to demonstrate his types seems to
> be overwritten.
> I will bring back his text as it seems his point does need to be driven home.
> A lot of Haskell projects have a separate Types module to avoid issues
> with circular dependencies.
>
>>
>>> Continuing the database example, I
>>> will have multiple tables with a 'name' column, but they do not have
>>> the same meaning.
>>>
>>> If I have a function:
>>>
>>>   helloName person = "Hello, " ++ person.name
>>>
>>> The compiler could infer that I want to say hello to inanimate objects!
>>
>> So the first question is:
>> * do your fields labelled `name` all have the same type? (Perhaps all String?)
>> * what "meaning" does a name have beyond being a String?
>>
>> Your code snippet doesn't give the types, but if I guess that you intend
>> `person` to be of type `Person`. Then you can give a signature:
>>     helloName :: Person -> String
>>
>> If person can be 'anything' then the type inferred from the bare function
>> equation would be:
>>     helloName :: r{ name :: String } => r -> String
>>
>> So you could say hello to your cat, and your pet rock. You couldn't say hello
>> to a pile of bricks (unless it's been given a name as an art installation in
>> the Tate Gallery ;-)
>
> Of course we know that we can always add type annotations to clarify
> things. The question is whether we want to be opt-out and have to
> explain people that they can end up with weakly typed code when they
> don't want to share fields.
>
>>
>>
>>
>>> Note that I am not completely against abstraction over fields, I just
>>> don't think it is the best default behavior.
>>>
>>
>> So what is the best default behaviour, and what is the range of other
>> behaviours you want to support?
>
> I believe the best default is to not share fields, but instead have
> the programmer indicate at or outside of the record definition that
> they want to share fields. Basically just use type-classes how they
> are used now - as opt-in. But I am OK with making an especially easy
> way to do this with records if the current techniques for defining
> typeclasses are seen as to verbose.
>
>>
>>
>>> And the section "Modules and qualified names for records" shows that
>>> the proposal doesn't fully solve the name-spacing issue.
>>>
>>
>> I think it shows only that record field labels can run into accidental name
>> clash in exactly the same way as everything else in Haskell (or indeed in any
>> programming language). And that Haskell has a perfectly good way for dealing
>> with that; and that DORF fits in with it.
>>
>> Greg, please give some specific examples! I'm trying to understand, but I'm
>> only guessing from the fragments of info you're giving.
>>
>> AntC
>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users