Changes between Version 64 and Version 65 of Records


Ignore:
Timestamp:
Mar 3, 2012 4:52:27 PM (2 years ago)
Author:
GregWeber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records

    v64 v65  
    5353 5. '''[wiki:Records/DeclaredOverloadedRecordFields Declared Overloaded Record Fields] (DORF)'''. Tweak to SORF. (Plan B) 
    5454 6. '''[wiki:Records/SyntaxDirectedNameResolution Syntax Directed Name Resolution]'''. Alternative that relies on syntactic rewriting and lenses. 
    55  7. '''[wiki:Records/TypeIndexedRecords]'''. (Plan B) 
     55 7. '''[wiki:Records/TypeIndexedRecords Type Indexed Records]'''. (Plan B) 
    5656 8. '''Are there any other approaches?''' 
    5757 
     
    6969 
    7070 
    71 The DORF proposal is a variant of SORF with similar goals. ~~~However, it only solves the narrow name-spacing issue within a module. If a record is imported into another module, it will still clash.~~~ It is perfectly possible to import Declared Overloaded Record Fields into other modules, and 'share' them in records declared in the importing module (and use the selector function for both the declared records and records imported). Alternatively, if the names are an 'accidental' clash, use qualified naming. (The type system prevents using the 'wrong' selector for a record type.). This is no worse than existing H98 modules/qualified naming. -- corrected by AntC, author of DORF. 
     71The DORF proposal is a variant of SORF with similar goals. However, it only solves the narrow name-spacing issue within a module. If a record is imported into another module, it must either share labels with it (automatic abstraction over fields) or use qualified module names. 
    7272 
    7373DORF and SORF abstract over fields. The benefit of abstracting over field names is being able to write code that works against any Record with a given field. So I can have a function: