Changes between Version 30 and Version 31 of ExtensibleRecords


Ignore:
Timestamp:
Nov 26, 2007 3:27:19 PM (7 years ago)
Author:
barney
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExtensibleRecords

    v30 v31  
    155155}}} 
    156156 
     157 
     158 = How to proceed? = 
     159 
     160There are a lot of design decisions listed on this page, some of which inspire strongly-help opinions. It is clear that discussion will not resolve these, and we don't seem to have a lot of examples to help clarify matters. The deadlock is unchanged: we still have too many good ideas. 
     161 
     162I believe the way forward is to implement several of the possible systems, and release them for feedback. To get users to actually try out the libraries, I think we need some concrete syntax for constant records, so I suggest we put in a feature request. Something like: 
     163{{{ 
     164expressions: {n1 = e1, ... , nn = en} --> mkUnderlyingRecord n1 e1 ( ... mkUnderlyingRecord nn en underlyingEmptyRecord) 
     165types: {n1 :: t1, ..., nn :: tn} --> MkUnderlyingRecord n1 e1 ( ... MkUnderlyingRecord nn en UnderlyingEmptyRecord) 
     166patterns: {n1 = p1, ... , nn = pn} --> (viewUnderlyingRecord n1 -> p1) @ ... @ (viewUnderlyingRecord nn -> pn) 
     167}}} 
     168Libraries could then implement {{{mkUnderlyingRecord}}}, {{{underlyingEmptyRecord}}}, {{{MkUnderlyingRecord}}}, {{{UnderlyingEmptyRecord}}} and {{{viewUnderlyingRecord}}} in whatever way is best. 
     169What do you think? 
     170