Thank you for your comments Richard.
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
On Aug 10, 2015, at 7:10 PM, Matthew Pickering matthewtpicker...@gmail.com
wrote:
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 think debating the overall idea before implementing is a great idea. Here's
my reason why I like these: it allows a library designer to change an internal
representation of a previously-concrete datatype while providing backward
compatibility. Since the datatype had been exporting its
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
On Tue, Aug 11, 2015 at 9:11 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:
I haven't tried to do it, but I imagine you could do some cool lens-like
constructs with proper (ab)use of this feature.
Seems likely given that generalizing record update was the original impetus
for lenses. :)
--
Hi *,
I had a few questions about the linker I was hoping someone can help me with,
I'm pretty new to it so any insights would be appreciated.
1) Has to do with checkProddableBlock and #10672 and #10563
static void checkProddableBlock (ObjectCode *oc, void *addr, size_t size )
{
