GHC support for the new "record" package

Wed Jan 21 16:01:31 UTC 2015

My thoughts mostly mirror those of Adam and Edward.

1) I want something that is backwards compatible.

2) Anonymous records are nice to have, but I don't want to have all records
be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)

3) I don't think it's a good idea to have lots of functions be polymorphic
in the record types of their arguments. If that falls out for free (like it
does both in ORF and Nikita's proposals) that's nice, but I think anonymous
records should be used sparsely.

To me, anonymous records look a lot like Go's interfaces, which structural
typing I don't think is a great idea. Go's interfaces give the appearance
of giving you more polymorphic functions (i.e. functions with arguments of
type { f :: T, ... }), but you have to express the required laws on these
record fields purely in terms of comments. With type class-based
polymorphism you're somewhat more specific and deliberate when you state
what kind of values your functions are polymorphic over. You don't just say
"this value must support a function f :: T" but instead "this value must
support a function f :: T, where the behavior of f is specified by the type
class it's defined in". I also have extensive experience of duck typing
from Python and there I think duck typing has not played out well (somewhat
collaborate by the fact that Python is adding base classes so it's possible
to talk about the laws I mentioned above.)

4) There are issues with strictness and unpacking.

5) I don't know if I want to commit the *language* to a particular lens
type.

On Wed, Jan 21, 2015 at 2:11 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Personally, I think the two proposals, ORF and Nikita's record approach
> address largely differing needs.
>
> The ORF proposal has the benefit that it doesn't require GHC itself to
> know anything about lenses in order to work and is mostly compatible with
> the existing field accessor combinators.
>
> Nikita's proposal on the other hand builds a form of Trex-like records
> where it has its own little universe to play in, and doesn't have to
> contort itself to make the field accessors backwards compatible. As its own
> little world, the fact that the ORF can't deal with certain types of fields
> just becomes a limitation on this little universe, and all existing code
> would continue to work.
>
> I, too, have a lot of skin in the game with the existing ORF proposal, but
> ultimately we're going to be stuck with whatever solution we build for a
> long time, and it is, we both have to confess, admittedly quite
> complicated, so it seems exploring the consequences of a related design
> which has different constraints on its design does little harm.
>
> I'm mostly paying the work the courtesy it deserves by considering to its
> logical conclusion what such a design would look like fleshed out in a way
> that maximized how nice the result could be to use. I'm curious, as mostly
> a thought experiment, how nice a design we could get in the end under these
> slightly different assumptions.
>
> If, in the end, having an anonymous record syntax that is distinct from
> the existing one is too ugly, it is okay for us to recoil from it and go
> back to committing to the existing proposal, but I for one would prefer to "
> steelman <https://themerelyreal.wordpress.com/2012/12/07/steelmanning/>"
> Nikita's trick first.
>
> Thus far, all of this is but words in a handful of emails. I happen to
> think the existing ORF implementation is about as good as we can get
> operating under the assumptions it does. That said, operating under
> different assumptions may get us a nicer user experience. I'm not sure,
> though, hence the thought experiment.
>
> -Edward
>
> On Wed, Jan 21, 2015 at 5:05 AM, Adam Gundry <adam at well-typed.com> wrote:
>
>> As someone with quite a lot of skin in this game, I thought it might be
>> useful to give my perspective on how this relates to ORF. Apologies that
>> this drags on a bit...
>>
>> Both approaches use essentially the same mechanism for resolving
>> overloaded field names (typeclasses indexed by type-level strings,
>> called Has/Upd or FieldOwner). ORF allows fields to be both selectors
>> and various types of lenses, whereas the record library always makes
>> them van Laarhoven lenses, but this isn't really a fundamental difference.
>>
>> The crucial difference is that ORF adds no new syntax, and solves
>> Has/Upd constraints for existing datatypes, whereas the record library
>> adds a new syntax for anonymous records and their fields that is
>> completely separate from existing datatypes, and solves FieldOwner
>> constraints only for these anonymous records (well, their desugaring).
>>
>> On the one hand, anonymous records are a very desirable feature, and in
>> some ways making them separate is a nice simplification. However, they
>> are not as expressive as the existing Haskell record datatypes (sums,
>> strict/unpacked fields, higher-rank fields), and having two records
>> mechanisms is a little unsatisfying. Do we really want to distinguish
>>
>>     data Foo = MkFoo { bar :: Int, baz :: Bool }
>>     data Foo = MkFoo {| bar :: Int, baz :: Bool |}
>>
>> (where the first is the traditional approach, and the second is a
>> single-argument constructor taking an anonymous record in Edward's
>> proposed syntax)?
>>
>> It might be nice to have a syntactic distinction between record fields
>> and normal functions (the [l|...|] in the record library), because it
>> makes name resolution much simpler. ORF was going down the route of
>> adding no syntax, so name resolution becomes more complex, but we could
>> revisit that decision and perhaps make ORF simpler. But I don't know
>> what the syntax should be.
>>
>> I would note that if we go ahead with ORF, the record library could
>> potentially take advantage of it (working with ORF's Has/Upd classes
>> instead of defining its own FieldOwner class). Then we could
>> subsequently add anonymous records to GHC if there is enough interest
>> and implementation effort. However, I don't want to limit the
>> discussion: if there's consensus that ORF is not the right approach,
>> then I'm happy to let it go the way of all the earth. ;-)
>>
>> (Regarding the status of ORF, Simon PJ and I had a useful meeting last
>> week where we identified a plan for getting it back on track, including
>> some key simplifications to the sticking points in the implementation.
>> So there might be some hope for getting it in after all.)
>>
>> Adam
>>
>>
>> On 20/01/15 21:44, Simon Marlow 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
>> >
>> > It had a *lot* of attention on Reddit:
>> > 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
>> > (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
>> >
>> > Cheers,
>> > Simon
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150121/adf16761/attachment.html>