Record field updates via patsyns looks very weird to me (and, as just a
user, it would be unexpected). Can't we do just matchers and builders for
now, and add field updaters as a second step, if there's concensus that
it's a Good Idea?
Bye,
Gergo
On 11 Aug 2015 07:11, "Matthew Pickering"
I was looking at implementing #8582 but before I got too far I thought it best to clear up a few design points.
A summary can be found below and a more fleshed out version with some examples can be found on the wiki page[1].
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} ```
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? (At least partiality in patterns is warned but how comprehensive is the coverage?)
``` foo :: Maybe a -> Maybe Int foo x = x {bar = 5}
-- error as `bar` unique determines that we need Foo bar = Nothing {bar = 5} ```
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.
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?
[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