[Haskell-cafe] type inference and named fields

[Malcolm Wallace]

Malcolm Wallace wrote:
> > Yes, I find it interesting that consecutive updates are not equivalent
> > to a combined update.  I believe this is largely because named fields
> > are defined as sugar - they behave in some sense like textual macros
> > in other languages, which can often turn out to have unexpected
> > properties.

Christian Maeder <maeder at tzi.de> writes:
> I share your characterization "like textual macros". The question is,
> should this be eliminated?

Although the behaviour is initially surprising, I suppose it is
easily explained.  After all, an equivalent expression using lambdas
would have the same typing problem:

  data A a = A { one, two :: a }

  update  v@(A{}) = v { one = Void } { two = Void }
  update' v@(A{}) = (\A one two -> A one Void) $ (\A one two -> A Void two) $ v

Because of this, I would be reluctant to define that consecutive
field updates can be semantically amalgamated into a single update.

> Would it be cleaner, though less convenient
> some times, if the types of updated values must not change?

I believe this is a very different question from the consecutive
update one.  By analogy with the lambda equivalent, I can see no
reason to outlaw a type change, where all the relevant types change
at the same time:

  update_ok  v@(A{}) = v { one=Void, two=Void }
  update_ok' v@(A{}) = (\A one two -> A Void Void) v

Regards,
    Malcolm