[Haskell-cafe] Some thoughts on Type-Directed Name Resolution - record update

[AntC]

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