GHC support for the new "record" package

Wed Jan 21 09:36:19 UTC 2015

On 20/01/2015 23:07, Edward Kmett wrote:

> It is a long trek from "this is plausible" to "hey, let's bet the
> future of records and bunch of syntax in the language on this".

Absolutely.  On the other hand, this is the first proposal I've seen
that really hits (for me) a point in the design space that has an
acceptable power to weight ratio.  Yes there are some corners cut, and
it remains to be seen whether, after we've decided which corners we want 
to uncut, the design retains the same P2W ratio.

A couple of answers to specific points:

> Re #1
>
> The main term and type level bits of syntax that could be coopted
> that aren't already in use are @ and (~ at the term level) and things
> like banana brackets (| ... |), while that already has some other,
> unrelated, connotations for folks, something related like {| ... |}.
> We use such bananas for our row types in Ermine to good effect.
>
> The latter {| ... |} might serve as a solid syntax suggestion for the
>  anonymous row type syntax.

Why not just use { ... } ?

> Re #2
>
> That leaves the means for how to talk about a lens for a given field
>  open. Under Adam's proposal that had evolved into making a really
> complicated instance that we could extract a lens from. This had the
>  benefit over the current state of the `record` package that we could
>  support full type changing lenses. Losing type-changing assignment
> would be a big step back from the previous proposal / the current
> state of development for folks who just use makeClassy or custom lens
> production rules with lens to get something similar, though.
>
> But the thing we never found was a nice short syntax for talking
> about the lens you get from a given field (or possibly chain of
> fields); Gundry's solution was 90% library and almost no syntax. On
> the other hand Adam was shackled by having to let the accessor be
> used as a normal function as well as a lens. Nikita's records don't
> have that problem.
>
> Having no syntax at all for extracting the lens from a field
> accessor, but rather to having it just be the lens, could directly
> address that concern. This raises some questions about scope, where
> do these names live? What happens when you have a module A that
> defines a record with a field, and a module B that does the same for
> a different record, and a module C that imports both, but, really, we
> had those before with Adam's proposal, so there is nothing new
> there.

Right.  So either
(a) A field name is a bare identifier that is bound to the lens, or
(b) There is special syntax for the lens of a field name

If (a) there needs to be a declaration of the name in order that we can
talk about scoping.  That makes (b) a lot more attractive; and if you
really find the syntax awkward then you can always bind a local variable
to the lens, or export the names from your library.

> And for what it is worth, I've seen users in the wild using
> makeLenses on records with several hundred fields (!!), so we'd need
> to figure out something that doesn't cap a record at 24 fields. This
> feedback came in because we made the lenses lazier and it caused some
> folks a great deal of pain in terms of time spent in code gen!

Sure.  We deal with large tuples by nesting, and I imagine something
similar could be done for records (I haven't worked through the details
though).

Cheers,
Simmon

> It would also necessarily entail moving a middling-sized chunk of
> lens into base so that you can actually do something with these
> accessors. I've been trying to draw lines around a "lens-core" for
> multiple years now. Everyone has a different belief of what it should
> be, and trust me, I've heard, and had to shoot down basically all of
> the pitches.
>
> We're going to be stuck with the warts of whatever solution we build
> for a very long time.
>
> So with those caveats in mind, I'd encourage us to take our time
> rather than rush into trying to get this 7.12 ready.
>
> Personally I would be happy if by the time we ship 7.12 we had a plan
>  for how we could proceed, that we could then judge on its merits.
>
> -Edward
>
>
> On Tue, Jan 20, 2015 at 4:44 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
> For those who haven't seen this, Nikita Volkov proposed a new
> approach to anonymous records, which can be found in the "record"
> package on Hackage: http://hackage.haskell.org/__package/record
> <http://hackage.haskell.org/package/record>
>
> It had a *lot* of attention on Reddit:
> http://nikita-volkov.github.__io/record/
> <http://nikita-volkov.github.io/record/>
>
> Now, the solution is very nice and lightweight, but because it is
> implemented outside GHC it relies on quasi-quotation (amazing that it
> can be done at all!).  It has some limitations because it needs to
> parse Haskell syntax, and Haskell is big.  So we could make this a
> lot smoother, both for the implementation and the user, by directly
> supporting anonymous record syntax in GHC.  Obviously we'd have to
> move the library code into base too.
>
> This message is by way of kicking off the discussion, since nobody
> else seems to have done so yet.  Can we agree that this is the right
> thing and should be directly supported by GHC?  At this point we'd be
> aiming for 7.12.
>
> Who is interested in working on this?  Nikita?
>
> There are various design decisions to think about.  For example, when
> the quasi-quote brackets are removed, the syntax will conflict with
> the existing record syntax.  The syntax ends up being similar to
> Simon's 2003 proposal
> http://research.microsoft.com/__en-us/um/people/simonpj/__Haskell/records.html
>
>
<http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html>
> (there are major differences though, notably the use of lenses for
> selection and update).
>
> I created a template wiki page:
> https://ghc.haskell.org/trac/__ghc/wiki/Records/Volkov
> <https://ghc.haskell.org/trac/ghc/wiki/Records/Volkov>
>
> Cheers, Simon _________________________________________________
> ghc-devs mailing list ghc-devs at haskell.org
> <mailto:ghc-devs at haskell.org>
> http://www.haskell.org/__mailman/listinfo/ghc-devs
> <http://www.haskell.org/mailman/listinfo/ghc-devs>
>
>