GHC support for the new "record" package

Adam Gundry adam at well-typed.com
Thu Jan 22 09:22:36 UTC 2015


On 21/01/15 21:51, Simon Marlow wrote:
> Adam, do you have any measurements for how much code gets generated for
> a record declaration with ORF, compared with a record declaration in GHC
> right now?  That's one thing that has been a nagging worry for me with
> ORF, but I just don't have any idea if it's a real problem or not.

Yes, that was something that was a bit unsatisfying about the original
implementation, though unfortunately I don't have hard numbers comparing
the relative code sizes. But Simon PJ and I have realised that we can be
much more efficient: the only things that need to be generated for
record declarations are selector functions (as at present) and updater
functions (one per field, per type). Everything else (typeclass dfuns,
type family axioms) can be made up on-the-fly in the typechecker. So I
don't think it will make a practical difference.


> Under Nikita's proposal, zero code is generated for a record
> "declaration" (since there isn't one), and the lenses are tiny
> expressions too.  There's some boilerplate in the library, but it's
> generated once and for all, and isn't that huge anyway.  The
> lightweightness of it from a code-size standpoint is very attractive.

Agreed. I'm coming to see how much of a virtue it is to be lightweight!
I'm a bit worried, however, that if we want

    newtype T = MkT {| foo :: Int |}
    x = view [l|foo|] (MkT 42) -- whatever our syntax for [l|...|] is

to be well-typed, we need an instance for FieldOwner "foo" Int T to be
generated somewhere (perhaps via GND), so I suspect the code generation
cost for non-anonymous overloaded records is about the same as with ORF.
Nikita's proposal would let you choose whether to pay that cost at
declaration time, which has advantages and disadvantages, of course.

Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


More information about the ghc-devs mailing list