Python library and command-line validator for the Shapes Constraint Language

Extended vocabulary of metadata terms maintained by DCMI; includes DCMES elements plus properties, classes, datatypes, and encoding schemes for RDF and Linked Data

It seems this first occurs in 9.6, perhaps because of “Record updates for GADTs and other existential datatypes are now fully supported”. Have a look at Note [Record Updates] in the type checker source. It says To typecheck a record update, we desugar it first. Suppose we have data T p q = T1 { x :: Int, y :: Bool, z :: Char } | T2 { v :: Char } | T3 { x :: Int } | T4 { p :: Float, y :: Bool, x :: Int } | T5 Then the record update `e { x=e1, y=e2 }` desugars as follows e { x=e1, y=e2 } ===> let { x' = e1; y' = e2 } in case e of T1 _ _ z -> T1 x' y' z T4 p _ _ -> T4 p y' x' That is, strict `let`s are pulled out during type checking. I believe what happened is that in 9.4 and earlier this transformation happened when desugaring to Core, where Strict couldn’t get at it, now it happens in type checking, where Strict can get at it. I think this is a bug. In `let updated = person { ... }`, `updated` should be evaluated to its constructor, which doesn’t require evaluating the new lazy fields in the record update itself. I’m surprised this hasn’t been noticed before.