PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011

Evan Laforge qdunkan at
Fri Feb 26 00:07:18 EST 2010

> (I know how you're always looking for things to take out of
> Haskell ...)
> I can see the ugliness of having a name with two
> incompatible types (especially in the same scope).

That's a good point, but even if not totally logical I think the
automatic "Rec -> X" function is more important than the X meaning.
Functions are more resistant to change (for instance, I changed from
String to Data.Text but could keep the old recString as a function
when the field named changed), so while I think the sugar to bring
names into scope is handy, I think functional access should be
encouraged as the "main" way to do it.

The whole tension between syntactic convenience of pattern matching
and the flexibility of function accessors in the face of change is
kind of unfortunate.  It mirrors the OO dilemma of x.y vs. x.y(),
which some OO languages do away with altogether.

So I'd want to go the other way by making functional access and update
more convenient and prominent rather than syntactical.

Maybe we could have a little extension of view patterns where "f
(field ->) = y" is transformed to "f (field -> field) = y".  It's
still a shadow, but at least now it works with any function.

It might be nice to do the same with update functions, but those
aren't even generated automatically (anyone got a generics thing that
cranks those out?).

More information about the Haskell-prime mailing list