Re: Records in Haskell

I looked at the DORF implementers view http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... 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 wrote:

On Thu, Feb 23, 2012 at 4:25 PM, AntC wrote:

...

Greg Weber 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users