simple extension to ghc's record disambiguation rules

[John Meacham]

On Sun, Feb 19, 2012 at 4:21 PM, AntC <anthony_clayden at clear.net.nz> wrote:
>>Hi, I'd like to propose an extremely simple extension to ghc's record
>>disambiguation rules,
> I wonder if John is teasing us? Nothing wrt to records is simple (IMHO).

That is rather defeatist. Degree of simplicity is actually something that very
quickly becomes very relevant and apparent as soon as one starts implementing
these proposals. Luckily, experience gives us some ability to figure out what
will be simple and what won't be.

> John seems to be unaware of the threads on 'Records in Haskell' (ghc-users)
> or 'Type-Directed Name Resolution' (cafe) that have been storming for the
> last few months.

Trust me, I am completely aware of them and have been following these ideas in
all their incarnations over the years. Seeing as how I will likely be one of
the people that actually implements said ideas, I do keep on top of such
things.

> He refers to a web page ...
>> ideally it would be combined with the 'update' and 'label-based
>> pattern-matching' extensions from this page
>> http://hackage.haskell.org/trac/haskell-prime/wiki/ExistingRecords
>
> ... which is several years old, requesting features that have been largely
> delivered in
> ghc's -XDIsambiguateRecordFields, -XNamedFieldPuns, and -XRecordWildCards.

Neither of those extensions I specifically mention are included in those you
list. Nor are in any way delivered by them.  Though, those extensions you do
list are quite handy indeed and I am glad to see ghc support them and in fact,
what I am proposing is dependent on them.

>> my motivation is that I often have record types with multiple constructors
>> but common fields.
>
> Perhaps this is a different requirement to those threads above?
> Most are dealing with the namespacing problem of common fields in different
> record types.
> I think John means common fields under different constructors within the
> same type(?).

No, I am trying to deal with namespace problems of common fields in different
labled field tyes. I refer to different constructors within the same type
because that is where the common mechanisms for dealing with said ambiguities
(such as the DisambiguateRecordFields extension) break down when presented with
such types.

The basic issue is that in order for DisambiguateRecordFields to work it needs
an unambiguous indicator of what type the record update is called at, currently
it can use the explicit constructor name as said indicator. my proposal is
simply to also allow an explicit type to have the same effect.

> "Extremely simple"? I don't think so.

Simple can be quantified here pretty easily

Ways in which it is simple:
* requires no changes to existing desugarings
* conservative in that it doesn't change the meaning of existing programs
* well tested in that it is an application of an existing extension
  (DisambiguateRecordFields) to a slighly broader context.

Ways in which it is complicated:
* record field names now depend on context. (already true with the
  DisambiguateRecordFields extension.)
* requires information transfer from the type checker to the renamer. (or some
  renaming to be delayed until the type checker). This is a common
feature of some
  proposed extensions out there, however this extension explicitly "cuts the
  recursive knot" requiring an explicit type signature, so while the renaming
  is affected by typing, the typing will not be affected by said renaming. A
  particularly thorny problem to resolve with some other proposals.


Your DORF proposal is interesting too, but is not really directly related to
this relatively local change to an existing extension. There is no reason to
conflate them.

    John