Oliver Batchelor
Hi,
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.)
Perhaps this situation could occur though?
Module A fieldLabel name String
Module B import A -- unknowingly picking up the name label
data Foo = Foo { name :: String } -- uses the name label by accident
So there'd have to be some syntax to make sure you intend to use a label rather than accidentally use it? (Not that this is a big issue, the situation is surely minor compared to sharing unrelated labels all the time)
Oliver
Thanks Oliver, hmm ... Did module B import A unqualified? Did module B not have its own declaration of fieldLabel `name`? And presumably module B has set the option to use DORF. Then DORF is going to take it that you mean to share the `name`. (And actually I don't see much harm resulting.) Them's the rules. If there's a fieldLabel `name` in Module B, Foo will use that. If furthermore B imports A unqualified, that's a clash of fieldLabels, so compile fail. If module B is compiled with H98 style records, there's a name clash with the H98 field selector function. I think this is no worse (and no better) than business-as-usual 'accidental' usage-without-declaration matching an unknowingly imported binding. (As part of the 'minimal changes' requirement, I'm trying to avoid syntax changes to record decls.) AntC