Records in Haskell

[Simon Peyton-Jones]

| 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