Changes between Version 26 and Version 27 of Records


Ignore:
Timestamp:
Jan 7, 2012 11:25:37 PM (2 years ago)
Author:
GregWeber
Comment:

organize & compare namespacing to overloading

Legend:

Unmodified
Added
Removed
Modified
  • Records

    v26 v27  
    3030The verbose name-spacing required is an in-your-face, glaring weakness telling you there is something wrong with Haskell. This issue has been solved in almost every modern programming languages, and there are plenty of possible solutions available to Haskell. 
    3131 
    32 == Solutions ==  
     32== Solutions == 
    3333 
    34 As part of improving records, we may need or want to improve name-spacing, possibly giving each record (or any data declaration) its own name-space. See below for more discussion. 
     34So 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 The main question is: how can we have multiple record field selectors in scope and correctly resolve the type of the record? 
    37  
    38  1. Nonextensible records with polymorphic selection & update; see [wiki:Records/OverloadedRecordFields] 
    39  2. Nonextensible records with simple type resolution; see below 
    40  
    41 The discussion here has many similarities with the original Type directed name resolution proposal: the question seems to be largely about nailing down a concrete implementation; see below and [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution TDNR] 
    42  
    43 Note that the name-spacing and simple type resolution approach is an attempt to port the records solution in [http://code.google.com/p/frege/ Frege], a haskell-like language on the JVM. See Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) of the [http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf Frege user manual] 
     36 1. Overloading: polymorphic selection & update; see [wiki:Records/OverloadedRecordFields] 
     37 2. Namespacing: simple name-spacing & type resolution; see below 
    4438 
    4539'''Are there any other approaches?''' 
    4640 
    47 -------------------------- 
    48 === Better name spacing === 
     41The discussion has many similarities with the original Type directed name resolution proposal: the question seems to be largely about nailing down a concrete implementation; see below and [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution TDNR]. The original TDNR proposal had Overloading in mind, but Namespacing ends up having similarities. 
     42 
     43The benefit of Overloading over Namespacing is being able to write code that works against any Record with a given field. So I can have a function: 
     44 
     45{{{ 
     46getA = r.a 
     47}}} 
     48 
     49and that can work for both Record and RecordClash because they both have a field a. 
     50With Namespacing this will fail to type check unless the compiler can determine the type of r. The advantage of Namespacing is that the implementation is clear, straightforward, and has already been done (whereas there are still questions as to the feasibility of Overloading). Namespacing also has other benefits related to namespacing that are not as directly related to solving the records issue. 
     51In the words of the Frege author, who abandoned Overloading: 
     52 
     53    * only very inefficient code could be generated, if you have to access or update a field of some unknown record. In the end, every record type was basically a map. 
     54    * it turned out that errors stemming from mistyping a field name often could not be diagnosed at the point where they were committed, but led to inferred types with crazy signatures and an incomprehensible type error at the use side of the function that contained the error. 
     55    * the extra constraints complicated the type checker and did not play well with higher kinded type variables (at least in the code I had then, I do not claim that this is nessecarily so). 
     56 
     57 
     58 
     59=== Better name spacing & simple type resolution === 
     60 
     61Note that the name-spacing and simple type resolution approach is an attempt to port the records solution in [http://code.google.com/p/frege/ Frege], a haskell-like language on the JVM. See Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) of the [http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf Frege user manual] 
    4962 
    5063In Haskell, you can look at an occurrence of any identifier `f` or `M.f` and decide where it is bound without thinking about types at all.  Broadly speaking it works like this: 
     
    6275 * '''Use the module name space mechanism'''; after all that's what it's for.  But putting each record definition in its own module is a bit heavyweight. So maybe we need local modules (just for name space control) and local import declarations.  Details are unclear. (This was proposed in 2008 in [http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html this discussion] on the Haskell cafe mailing list and in #2551. - Yitz). 
    6376 
    64  Rather than strictly re-use modules it would make more sense to have a name-spacing construct that is shared between both records and modules - hopefully this would make implementation easier. Overall this seems to be more of an implementation detail that may have a side effect of making local modules easier to implement than a concrete design proposal relating to records. -- Greg Weber. 
     77 Rather than strictly re-use modules it may make more sense to have a name-spacing implementation construct that is shared between both records and modules - hopefully this would make implementation easier and unify behavior. In the Frege approach, each data declaration is its own namespace - if we were to go this far (instead of stopping purely at records) there may be much less need for local namespaces. Overall this seems to be more of an implementation detail that may have a side effect of making local modules easier to implement than a concrete design proposal relating to records. -- Greg Weber. 
    6578 
    6679