Records in Haskell

[AntC]

Isaac Dupree <ml <at> isaac.cedarswampstudios.org> writes:

> 
> 
> Darn, I misinterpreted DORF.  There was too much text and too many options.
> 

Sorry! You might do better to stick to the implementor's page if you want a 
less 'option-laden' description. Also better to skip the speculative bits 
until you've got the basics clear.


> Tell me if I'm correct:
> A. Every declaration with record syntax creates Has instances for all 
> fields [1].

Correct

> B. "Has", "get" and "set" may not be written by users (guessing due to 
> representation-hiding fail).

Correct: I want the implementors to have design space for the mechanics behind 
the scenes.

> C. You create functions using "fieldLabel name [...]"

Correct-ish: create both functions and a proxy types. It's really the type 
that drives inference, not the function.

> D. which have the magical effect of, when in scope unqualified, ...

Nothing 'magical' going on: they're ordinary functions and types, with 
ordinary import/export/hiding. And you can use them qualified if you'd rather.

> ... causing 
> data types defined with record syntax to be accessible through that 
> particular fieldLabel function (and no other way).

The fieldLabel function behaves very similar to the H98-generated function. 
The difference is with DORF it's overloaded, but H98 is monomorphic.

You can still access the fields as per H98 through pattern match (using the 
data constructor), or positionally. [Yes I know that if we were designing 
a 'true' polymorphic record system we'd ban positional access.]

> E. (When two fieldLabels of the same name are in scope unqualified, 
> declaring a record containing that name is an error.)

Correct. Just like having any other clash of names in scope (for example all 
the competing declarations of `map`). And just like those, you can use module 
qualifiers to resolve the clash.

> F. So adding an import (for some other reason for your code) that 
> happens to include a fieldLabel can make your records accidentally be 
> more visible, rather than be compile-error or no-effect.

Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to 
access a record with a field `name` declared in module B. You'll get a 'no 
instance' compile fail. Same familiar rules as for any instance resolution.

This is the crucial difference compared to SORF: which can't control the scope 
of its String Kind. (Apologies that I added a speculative discussion of 
whether DORF could use String Kinds. I said that if doing so would open 
the 'back door' to the abstraction, then I'll stick with types.)

> 
> I feel weird about record fields having an option that depends on 
> whether something's in scope and cannot be controlled syntactically. 
> Maybe we can fix that without making the syntax worse.
> 

Absolutely agree. I designed DORF to correct that deficiency in SORF (as I saw 
it).


> G. It is possible (but rather ugly) to use dot-notation when there are 
> multiple fieldNames of the same name in scope. [2]
> 

Yep, agree with the "ugly".


> Hmm.  Maybe this is Haskelly as well as convenient enough.  Did I get 
> everything right?  What do you think about my concern about F?
> 

Well done! Nearly everything. I hope I've allayed your concerns re F.

AntC


> [1] 
> 
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields
/ImplementorsView
> [2] 
> 
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields
/DotPostfix#UsingDotnotationamongstqualifiednames
>