Overloaded record fields
anthony_clayden at clear.net.nz
Fri Jun 28 15:46:00 CEST 2013
> Malcolm Wallace <malcolm.wallace <at> me.com> 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"
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
> 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
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.)
More information about the Glasgow-haskell-users