Changes between Version 16 and Version 17 of ExtensibleRecords


Ignore:
Timestamp:
Nov 14, 2007 1:12:34 PM (6 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExtensibleRecords

    v16 v17  
    4444The other proposals allow labels to be arbitrary strings, and distinguish them by context. 
    4545 
     46This is related to the problem of Label Sharing: if the label `L` is declared in two different modules `M1` and `M2`, both of which are imported, do we have one label `L` or two labels `M1.L` and `M2.L`? Should there be a mechanism for identifying labels on import? 
     47 
    4648= Type Systems = 
    4749 
     
    8284 * partial evaluation of type class programs: to achieve constant time record field access. Again, this feature is not specific to records, but crucial for record programming practice. 
    8385 * portability: it would be nice if extensible records libraries were portable over multiple Haskell implementations. That not only means that these implementations need to support the same features, but that they need to interpret these features in the same way (this is currently not the case for the interaction of functional dependencies and type class overlap resolution in GHC and Hugs). 
     86 * permutativity: The easiest way to implement permutativity of field labels is to sort them by some total ordering. Although this can be implemented using functional dependencies, it's complex and inefficient. Compiler support for a global order on typids (based on fully qualified name, perhaps) would be very helpful. Does this conflict with type sharing? 
    8487 
    8588= Examples =