On Aug 10, 2015, at 7:10 PM, Matthew Pickering
My main question is about how best to deal with record updates. Say that Foo is a record pattern synonym then how would we expect the following program to behave?
``` foo a@Foo{..} = a {bar = baz} ```
I'm assuming `pattern Foo{bar, baz} = (bar, baz)` from the wiki page, without any further pattern type signature. This example then looks straightforward to me -- I feel I'm missing the subtlety. `foo` would get the type `(a,b) -> (b,b)` and would be roughly equivalent to `foo a@(bar, baz) = case a of (_, baz2) -> (baz, baz2)`. The case statement and baz2 is necessary just to provide a predictable desugaring of record updates; handwritten code should clearly be more succinct.
Then say that `pattern Foo{bar} = Just bar`, how should the following two programs behave? Is this partiality any different to that caused by ordinary use of pattern synonyms?
Did you mean "pattern synonyms" --> "record updates"?
(At least partiality in patterns is warned but how comprehensive is the coverage?)
``` foo :: Maybe a -> Maybe Int foo x = x {bar = 5}
This would desugar to `foo x = case x of Just _ -> Just 5`. I'm not sure about pattern exhaustiveness warnings, but I would expect such a record update to be partial. The partiality of record updates has been surprising in the past, but I don't think adding pattern synonyms to the mix should change that.
-- error as `quux` unique determines that we need Foo quux = Nothing {bar = 5}
This (renamed example) does not compile, as GHC would parse this as a record-creation expression using the Nothing constructor, which does not have record fields. On the other hand
quux = (Nothing) {bar = 5}
*would* compile. (This is no different than record updates today.) It would desugar to `quux = case Nothing of Just _ -> Just 5` and `quux` would have type `Maybe Int` (assuming `5 :: Int`). Evaluating `quux` would clearly fail.
```
Abandoning record updates seems to make record syntax for pattern synonyms far less useful and confusing to users. Is this design how others have imagined it? I have cced Gergő who originally implemented the extension and created #8582.
I would like to keep record updates for the same reasons you appear to. I will warn that they are quite hard to work with, though! About 220 lines of dense code (including comments) are necessary to type-check regular old record updates. This isn't to scare you off, but to have you suitably forewarned and forearmed.
Matt
----
Unidirectional patterns * Provide the same ability to match as normal records (RecordWildcards etc) * Provide selector functions
Bidirectional patterns * Provide the constructor which can be used as normal record constructors
Record Updates - unclear * Generalise update syntax to arbitrary expressions?
What do you mean here? Without checking, I assumed that the x in `x { ... }` had to be a variable. But this is wrong! See 3.15.3 of the Haskell 2010 report (https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-490003.1...). So I think it's already generalized. Many thanks for taking this on! Richard
[1]: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#RecordPatternSynonyms _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs