| | 157 | |
| | 158 | = How to proceed? = |
| | 159 | |
| | 160 | There 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 | |
| | 162 | I 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 | {{{ |
| | 164 | expressions: {n1 = e1, ... , nn = en} --> mkUnderlyingRecord n1 e1 ( ... mkUnderlyingRecord nn en underlyingEmptyRecord) |
| | 165 | types: {n1 :: t1, ..., nn :: tn} --> MkUnderlyingRecord n1 e1 ( ... MkUnderlyingRecord nn en UnderlyingEmptyRecord) |
| | 166 | patterns: {n1 = p1, ... , nn = pn} --> (viewUnderlyingRecord n1 -> p1) @ ... @ (viewUnderlyingRecord nn -> pn) |
| | 167 | }}} |
| | 168 | Libraries could then implement {{{mkUnderlyingRecord}}}, {{{underlyingEmptyRecord}}}, {{{MkUnderlyingRecord}}}, {{{UnderlyingEmptyRecord}}} and {{{viewUnderlyingRecord}}} in whatever way is best. |
| | 169 | What do you think? |
| | 170 | |
