Record syntax for pattern synonyms

Matthew Pickering matthewtpickering at
Mon Aug 10 23:10:36 UTC 2015

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 at 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.



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?


More information about the ghc-devs mailing list