Overloaded record fields

[AntC]

> 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" 
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
>