Changes between Version 35 and Version 36 of Records


Ignore:
Timestamp:
Jan 16, 2012 9:50:24 AM (2 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records

    v35 v36  
    3434So we have decided to avoid the extensible record debate, but how can we have multiple record field selectors in scope and correctly resolve the type of the record? 
    3535 
    36  1. Overloading: polymorphic selection & update; see [wiki:Records/OverloadedRecordFields] 
    37  2. Namespacing: simple name-spacing & type resolution; see [wiki:Records/NameSpacing] 
     36 1. Simple Overloaded Record Fields (SORF); see [wiki:Records/OverloadedRecordFields] 
     37 2. Frege-derived Records (FDR): simple name-spacing & plus type resolution; see [wiki:Records/NameSpacing] 
     38 3. Type Directed Name Resolution (TDNR): like FDR, but without the name-spacing part; see [wiki:TypeDirectedNameResolution Type Directed Name Resolution]. 
    3839 3. '''Are there any other approaches?''' 
    3940 
     
    5960All of the name-space mechanisms require some level of user-supplied disambiguation: if there are two fields `a` in scope, you must use a qualified name to disambiguate them.  What is tantalising about this is that the ''type'' of the argument immediately specifies which one you mean. There is really no ambiguity at all, so it is frustrating to have to type qualified names to redundantly specify that information.  Object-oriented languages take for granted this form of type-directed disambiguation. 
    6061 
    61 One particular way of integrating this idea into Haskell is called [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution Type Directed Name Resolution] (TDNR). Proposed a couple of years ago, the Haskell community didn't like it much.  (But I still do; SLPJ.) 
     62One particular way of integrating this idea into Haskell is called (TDNR). Proposed a couple of years ago, the Haskell community didn't like it much.  (But I still do; SLPJ.) 
    6263 
    6364I believe the community rejected TDNR because they wanted extensible records. I think it is a shame that the debate over *extensible* records has resulted in holding back any form of progress , but I do think that the TDNR proposal seems a little weak for some reasons pointed out in the proposal itself, but also because it proposes not to solve name-spacing record updates. Note that the Frege proposal incorporates the TDNR syntax, and it tackles record updates. -- Greg Weber