Donn Cave
Quoth Evan Laforge
, ... 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?
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. SPJ was "not very happy with any of this." SPJ in the SORF proposal asks: what does e { x = True } mean if there are lots of "x" fields in scope? (which is precisely what we want to allow) So he's supposing some syntax -- where `e' is some expression that evaluates to a record. (There's a shorter discussion in the TDNR proposal.) If Haskell supported polymorphic update semantics (as well as polymorphic field selection), you could build for yourself all those update idioms you talk about. More abstractly, can Haskell offer a polymorphic `set' (and `get') method for the `Has' class? set :: (Has r fld t) => fld -> t -> _r -> r get :: (Has r fld t) => r -> fld -> t -- fld in record r at type t -- where fld is a type/Kind that identifies the field The SORF proposal discusses lots of awkward cases which make polymorphic update difficult. I've built a prototype that hacks round some of those cases. SPJ's view (on a quick inspect) is that it's workable in some cases, limited in others, and not scalable in general. Are you/everybody here prepared to give away some of the current record features so that you can go poly? - Do you want to change the type of a record? (that's why I've put `_r' in `set's type `_r' is the as-was type that we're throwing away.) Haskell currently supports changing the type of the record. (SPJ doubts whether type-changing has ever been a valuable feature. So do I.) - Do you want to update Higher-rank fields? (typically used in records representing OO-style objects) Or is it enough to initialise the HR field when you create the record, then never change it? How many forall'd variables might you like in the HR field? - Do you want to put constraints on the HR's forall'd types? This is where the issue is stuck. Very possibly if we agree workable constraints, we're going to just run into further difficulties (like type inference becoming unmanageable without lots of type annotations to help resolve instances). AntC