Changes between Version 7 and Version 8 of Records/OverloadedRecordFields

Show
Ignore:
Timestamp:
12/28/11 18:17:38 (18 months ago)
Author:
quuxity
Comment:

few typos

Legend:

Unmodified
Added
Removed
Modified

  • Records/OverloadedRecordFields

    v7 v8  
    55idea there are numerous ramifications.  Records are a swamp! 
    66 
    7 See also a similar [http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html 2003 proposal by Simon PJ and Greg Morrisset].  It is essentially the same as the proposal below, but (a) has less detail and (b) adds anonymous reccord types.   Anonymous type could be an add-on feature to the design described here. 
     7See also a similar [http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html 2003 proposal by Simon PJ and Greg Morrisset].  It is essentially the same as the proposal below, but (a) has less detail and (b) adds anonymous record types.   Anonymous type could be an add-on feature to the design described here. 
    88 
    99= The base design = 
    1010 
    11 The '''base design''' has the folllowing distinct components: 
     11The '''base design''' has the following distinct components: 
    1212 
    1313 * A library class 
    … …  
    326326 will be rejected because `rv` is not polymorphic.  Again, this is '''not''' easy to fix.    
    327327 
    328  This problem seems to be a killer: if record-update syntax is interprested as a call to `set`, we cannot, ever, use record-update syntax to update a record with a polymorphic field. (We could use alternative notation; instead of `r { rev = reverse }` we could say 
     328 This problem seems to be a killer: if record-update syntax is interpreted as a call to `set`, we cannot, ever, use record-update syntax to update a record with a polymorphic field. (We could use alternative notation; instead of `r { rev = reverse }` we could say 
    329329{{{ 
    330330  case r of { HR { .. } -> HR { rev = reverse, .. } } 
    … …  
    335335another alternative is to stick with the status quo for record 
    336336updates; that is, not to support any sort of overloading.  But even 
    337 ''that'' is problemantic: what does `e { x = True }` mean if there are lots of "x" fields 
     337''that'' is problematic: what does `e { x = True }` mean if there are lots of "x" fields 
    338338in scope (which is precisely what we want to allow). Haskell's current record-update 
    339339syntax really relies on learning which type is involved, from the record selector; but if