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 <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
