On Sun, Feb 19, 2012 at 4:21 PM, AntC
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