Isaac Dupree
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/DeclaredOverloadedRecordFie... /ImplementorsView
[2]
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... /DotPostfix#UsingDotnotationamongstqualifiednames