Records in Haskell

AntC anthony_clayden at clear.net.nz
Fri Feb 24 01:25:09 CET 2012


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?

> 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 ;-)



> 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?


> 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






More information about the Glasgow-haskell-users mailing list