Records in Haskell

[Greg Weber]

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