Records in Haskell
greg at gregweber.info
Sat Feb 11 15:47:46 CET 2012
> | 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
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
> | 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.
> Thanks for working on this. I'll await the writeup that you and Anthony Clayden are doing.
More information about the Glasgow-haskell-users