| 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
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
