Records in Haskell
anthony_clayden at clear.net.nz
Tue Feb 28 10:56:05 CET 2012
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 .
> 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
> 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
> G. It is possible (but rather ugly) to use dot-notation when there are
> multiple fieldNames of the same name in scope. 
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.
More information about the Glasgow-haskell-users