AntC> Steve, I think that proposal has been rather superseeded by AntC> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields, which AntC> draws on TDNR. But SORF is best seen as an evolving design space, with precise AntC> details yet to be clarified/agreed. I've put my own variation into the ring: AntC> http://www.haskell.org/pipermail/glasgow-haskell-users/2011- AntC> December/021298.html -- which seems to have fallen into a black hole :-( AntC> One of the aspects of TDNR that wasn't so popular was that its type-directed AntC> resolution was very similar to instance resolution, but subtly and confusingly AntC> different. AntC> I guess we have to be very careful about the dot. It seems to be in a AntC> very 'crowded' syntax space, so if we implement the wrong way, we could end up AntC> shutting the door with the keys left inside. AntC> (...) All this dot syntax magic frankly frightens me. Haskell, as a pure functionnal language, requires (and allows !) a programming style that just does not mix well with object oriented practices. Stretching the syntax to have the dot feel a-bit-but-not-really like object oriented programming, mainly to have IDE autocompletion on some cases, does not make much sens. If the editor matters - and it probably does -, we could rather take a more ambitious path, and work on a real semantic editor, as opposed to a plain left-to-right text editor, with hacked semantic goodies to alleviate the pain. Indeed, very often in haskell, we just don't think code left to right, or top to bottom. Emacs ability to move point quickly certainly helps, but I'd surely welcome a drastic switch, to something allowing us to work directly on type-checked syntax trees. -- Paul