Quoth Evan Laforge <[email protected]>,
...
> 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 the obvious, is it fair to say the root
of this problem is at least the lack of `first class' update syntax?
For example, in a better world you could write stuff like
modifyConfig :: (Config -> a) -> (a -> a) -> Config -> Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
... but today you get "`fr' is not a (visible) constructor field name"
So you need a modifyConfigTempo, etc. - when even the above is
inconveniently specific, as we'd rather have
modifyRecord :: RecordType r => (r -> a) -> (a -> a) -> r -> r
I'm not saying "modifyRecord (+ 20) tempo config" would be the ideal
syntax for everyone who's been dreaming of records improvement, just
trying to get at the underlying problem with minimal syntactic
distractions. Nested structure doesn't look like a special problem -
modifyRecord innerRecord (modifyRecord inInField (+ 20)) outRecord
An operator with some infixing doesn't seem to buy a lot -
(innerRecord \{} (inInField \{} (+ 20))) outRecord
... but better might be possible without sacrificing composability.
Donn
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
