
Malcolm Wallace
writes: With the orthogonal proposal, f is equivalent to f r b = foo r && b
I believe Simon's point is that, if dot is special, we can infer the "Has" type above, even if the compiler is not currently aware of any actual record types that contain a "foo" field.
Thanks Malcolm, yes I think I do understand what Simon had in mind. In effect .foo is a kind of literal. It 'stands for' the String type "foo" :: Symbol parameter to Has. (And that's "very odd", as SPJ's SORF write-up points out, because that isn't an explicit parameter to getFld.) But contrast H98 field selector functions. They're regular functions, nothing about them to show they're specific to a record decl. And they work (apart from the non-overloadability). So all we're doing is moving to foo being an overloaded field selection function. And it's a regular overloaded function, which resolves through instance matching.
If dot is not special, then there *must* be some record containing "foo" already in scope, ...
I think you have it the wrong way round. Field selector function foo must be in scope. (Or rather what I mean is that name foo must be in scope, and it's in-scope binding must be to a field selector.) And function foo must be in scope because there's a record in scope with field foo, that generated the function via -XPolyRecordFields.
..., where you can use a selector for a record that is not even defined yet, leads to good library separation.
You can't do that currently. So I think you're asking for something beyond Simon's "smallest increment".
Unless you require the type signature to be explicit, instead of
inferred. Well, I think that's reasonable to require a signature if you "use a selector for a record that is not even defined yet". I'm not convinced there's a strong enough use case to try to support auto type inference. Simon said "vanishingly rare".
(For the record, I deeply dislike making dot special, so I would
personally go for requiring the explicit
type signature in this situation.)
Regards, Malcolm