| The starting point a new records implementation was to be pragmatic | and get something done. Simon has identified that Has constraints are | required to implement records. I think it'd be overstating it to say "required". But Has constraints do seem to be a modest way to make progress that fits with the rest of the language. | 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. | 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. Thanks for working on this. I'll await the writeup that you and Anthony Clayden are doing. Simon