| ... | @@ -66,7 +66,7 @@ This would mitigate the problems caused by accessors being partial functions sin |
... | @@ -66,7 +66,7 @@ This would mitigate the problems caused by accessors being partial functions sin |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note from Simon. I hate that the above defn of 'f' has just one argument (val {x="foo")),
|
|
**Note from Simon**. I hate that the above defn of 'f' has just one argument (val {x="foo")),
|
|
|
whereas it looks as if it has two. (This is a problem with existing Haskell.) It looks
|
|
whereas it looks as if it has two. (This is a problem with existing Haskell.) It looks
|
|
|
like 'f' has an argument 'val' and another arguement that is a free-standing record,
|
|
like 'f' has an argument 'val' and another arguement that is a free-standing record,
|
|
|
something we really want in the end anyhow. Not sure how to fix this. `val@{x="foo")`?
|
|
something we really want in the end anyhow. Not sure how to fix this. `val@{x="foo")`?
|
| ... | @@ -125,6 +125,15 @@ Note the change in the type of the stored field. |
... | @@ -125,6 +125,15 @@ Note the change in the type of the stored field. |
|
|
At the moment, such a record update must be written using the data constructor, not the update syntax.
|
|
At the moment, such a record update must be written using the data constructor, not the update syntax.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**SLPJ:** That isn't true. Haskell 98 already supports what you suggest here, and the code above compiles with GHC without flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
However I would like to argue for *removing* this feature. It causes a quite unreasonable amount of
|
|
|
|
pain in the type checker, especially once we start thinking about GADTs and existentials. And I think the benefit is modest at best. I don't think programmers generally expect record update to be a type-changing operation.
|
|
|
|
|
|
|
|
|
|
|
## 'Open' statement
|
|
## 'Open' statement
|
|
|
|
|
|
|
|
|
|
|
| ... | | ... | |