Row polymorphism packages in Haskell

#1

In my experience, row polymorphism significantly reduces boilerplate when writing business applications. I used to rely on the row-types package whenever I needed row polymorphism. The package was once used at Target but appears to have been abandoned, with the author moving it to their personal account.

Although there’s a GHC proposal for native support, it seems to have stalled. In the meantime, I’m curious about which packages the community uses in commercial apps.

4 Likes
#2

I don’t use it, but large-anon: Scalable anonymous records is most likely best because of its scalability.

1 Like
#3

There is an elaborate wiki page on GHC’s gitlab here: extensible records · Wiki · Glasgow Haskell Compiler / GHC · GitLab, and also the libraries vinyl, HList and record. Don’t know about their usability though.

1 Like
#4

Thank you, @arybczak and @markus. I’ve looked into large-anon and vinyl previously. I’m more interested in hearing about any production experiences with these or other alternative packages.

#5

I’m using large-anon sporadically in a newish production codebase. Nothing super compelling yet. It’s straightforward to use and has neat syntax. I’ve used it for some toJSON instances where instead of importing Data.Aeson's object and .= (the latter especially is being a name that clashes with many libs including lens/optics) you can just use record syntax. Like

instance ToJSON MyError where
  toJSON (MyError (FailureResponse req resp)) = toJSON ANON
    { request = ANON
      { httpVersion = Text.decodeUtf8Lenient req.requestHttpVersion
      , method = Text.decodeUtf8Lenient req.requestMethod
      , path = Text.decodeUtf8Lenient req.requestPath
      }
    , response = ...
    }

But I think where it would be a much more tangible benefit is if SQL libraries like beam/opaleye/hasql-th adopted it for return and parameter types. It’s fairly cumbersome defining new types for every new query, or using tuples. Squeal-postgresql has a lot of integration with generics-sop which is nice but when I used it last had a pretty big compilation time penalty.

3 Likes
#6

FYI Opaleye doesn’t require any specific structure of product types in its API. You can use anything you like (including large-anon presumably) as long as you can write the correct instance.