OK, we could implement lenses, make `tempo' a lens instead of a selector,
desugar the update syntax to call the update 'method' out of the lens, ...
And of course somehow arrange the sugar that when `tempo' appears in other
contexts we take the select 'method'.
implement lenses - Done, of
On 10/02/2012 03:22, Donn Cave wrote:
modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
data Config { tempo :: Int, ...}
f = modifyRecord tempo (+20)
I'm hoping I missed something, and that you don't intend the (r - a)
part of this in particular to be taken literally.
Donn Cave donn at avvanta.com writes:
Quoth Evan Laforge qdunkan at gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating
Quoth AntC anthony_clay...@clear.net.nz,
...
No, Donn, it's not the lack of syntax, it's the lack of semantics for first-
class (polymorphic) record update. And there's very little that's obvious.
Ah, you're right, I certainly shouldn't have used the word syntax there.
But just to be clear on
Donn Cave donn at avvanta.com writes:
-- modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
modifyRecord :: RecordType r = (r - a) - (a - a) - r - r
... while this does obviously represent a polymorphic function,
Exactly!
if I write
-- data Config { tempo :: Int, ...}
Quoth AntC anthony_clay...@clear.net.nz,
Donn Cave donn at avvanta.com writes:
...
The narrow issue we're trying to address is namespacing, and specifically name
clashes: two different records with the same named field.
...
Now in return for me answering that, please answer the questions in my
