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" 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@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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs