Changes between Version 13 and Version 14 of Records/DeclaredOverloadedRecordFields/ImplementorsView


Ignore:
Timestamp:
Feb 22, 2012 10:05:09 PM (4 years ago)
Author:
AntC
Comment:

add note re changing record constructor -- AntC

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/ImplementorsView

    v13 v14  
    138138
    139139but in general, this would need instances for each perm/comb of fields.
     140
     141
     142=== Changing the record constructor ===
     143
     144The `set` method continues with the as-is record constructor, with no attempt to figure out the 'appropriate' constructor for the fields names presented. This follows H98 behaviour.
     145
     146So if in update syntax you present field names which are not in the current constructor (but are in other constructors for the same type), you'll get pattern match failure (`Non-exhaustive patterns in record update`). For example:
     147{{{
     148    data Txyz   =   Txyz { x :: Int, y :: String, z :: Bool }
     149                  | Tyx  { y :: String, x :: Int } 
     150             deriving (Show, Read, Eq)
     151
     152    tyx  = Tyx{ y = "hello", x = 72 }
     153
     154    txyz = tyx{ z = False }                              -- run-time fail: Non-exhaustive patterns in record update
     155                                                         -- no attempt to change to constructor Txyz
     156}}}
     157
     158To achieve this, you'd need to put an explicit data constructor (presumably using punning/wildcards):
     159{{{
     160    case tyx of { Tyx{..} -> Txyz{ z = False, .. } }
     161}}}
    140162
    141163=== Type-changing update ===