[snip]
| So I propose we move forward with implementing Has constraints, but do | not expose it to the user (similar to TDNR). We don't add abstraction | over fields or virtual fields or any special capabilities that would | expose the implementation.
Fair enough. I call this the "ML numeric solution" in the sense that ML lets you use "+" for floating point addition and integer addition, but insists that the choice be made statically; if you write f x = x+x it'll ask which "+" you mean, so you can have f :: Int -> Int or f :: Float -> Float but not both. Haskell generalises by allow you to abstract over the constraint f :: Num a => a -> a
Choosing the ML way for records constraints has the advantage of addressing the immediate problem while making as few future commitments as possible.
I don't call the solution the ML solution. I call it the Haskell solution. In Haskell there is no implicit abstraction over names: one must explicitly create a typeclass instance to abstract over the same function name. I think it is important to maintain the Haskell way of opting-in to typeclasses. If we like, we could have special conveniences to make opting-in to a shared field name as convenient as possible (maybe use deriving).
| With this in mind, what limitations are left? are updates still a | problem, and can we solve it (for now at least) by being more | demanding of type annotations?
Yes I think updates (of polymorphic fields) are still a problem. It seems like the main difficulty in your current story.
Ok, looking into it now. One aspect that complicates updates is that the type of a polymorphic field can be changed during an update. What is the use case for changing the type of a record field on update? This seems to make things harder on the implementer and harder on users to reason about the types in their program. I think it would be easier on everyone to just remove this capability or have an explicit syntax for changing the type to make it easier for both implementer (to distinguish) and user (to declare intent). I am not sure what the syntax would be, or if it should be a separate action or mixed in with a normal record update. Greg Weber
Thanks for working on this. I'll await the writeup that you and Anthony Clayden are doing.
Simon