Lambda the Ultimate

Thanks for the input. I believe the question is in no way related to Haskell: it is quite general, and it is mostly related to subtyping and its nuances.

Your interpretation is of course accurate in that the above function does an unwrap/update/rewrap. About the OOP, my intuition is that to represent aliasing you need to bind values of a supertype to values of the subtype for operations on the supertype, and if this is done automatically (inside a monad, for example) then you get code that looks very much like the imperative equivalent.

About the OOP, my intuition is that to represent aliasing you need to bind values of a supertype to values of the subtype for operations on the supertype, and if this is done automatically (inside a monad, for example) then you get code that looks very much like the imperative equivalent.

For object aliasing, you need the ability two objects to 'share' reference to a third. I.e. Alice and Charlie each contain a reference to Bob. If Alice effects an update on Bob, then Charlie can observe this update, even if Charlie is not aware of Alice. With the setup you describe, however, Alice would produce a new Bob' that is not shared by Charlie. This has absolutely nothing to do with supertype vs. subtype bindings. This has to do with how updates are expressed.

I lack the context to know whether 'f' is intended for something other than 'object' update. Aliasing (and even mutable 'pointers') has been achieved in Haskell in at least three different ways (that I've read about), and I suspect anyone really interested in Haskell object systems would eventually poke around at prior art.

That's great: could you provide pointers to these three approaches?

Thanks

For prior art, I would suggest studying Yampa (reactive and stateful) and OOHaskell (object-oriented and stateful). If those interest you, they have bibliographies for even more prior art.