GHC support for the new "record" package

Mon Jan 26 21:23:18 UTC 2015

Hello everyone!

I of course will be honoured to participate in the work on anonymous
records, if hopefully we get to it. However as I've seen there's been some
debate going on and confusion about whether they are at all worth
implementing. That is why I am writing an article titled “Why anonymous
records matter”, which I plan to publish this week.

Meanwhile I've updated "record" to support type-changing updates. Adam’s
proposal unfortunately wouldn’t work for anonymous records due to type
family instance conflicts. What I did was implement something in the spirit
of a Functional Dependencies based solution for tuples from Edward's "lens"
library. Thanks for inspiration!

Also I’ve decided to redo the “record” project as a full-blown preprocessor
with full Haskell syntax support using hacks around “haskell-src-exts”, as was
once suggested
<http://www.reddit.com/r/haskell/comments/2svayz/i_think_ive_nailed_it_ive_solved_the_records/cntyl7n>
by
Chris Done on Reddit. I’m planning to stick to Simon’s insightful proposal
concerning Implicit Values as much as possible. Hopefully this all will
turn the project into a play ground for a GHC extension, which people will
be able to use with existing GHC releases. However I’m only beginning to
work on this.

Also, as Adam’s already aware, I am exploring anonymous tagged unions
<http://www.reddit.com/r/haskell/comments/2svayz/i_think_ive_nailed_it_ive_solved_the_records/cnwgooc?context=3>.
Turns out they share quite a lot of properties with anonymous records and
in a similar style solve the constructor namespacing issue. Looks like
Implicit Values could come in handy for this as well.

Best regards,
Nikita

2015-01-27 0:18 GMT+03:00 Nikita Volkov <nikita.y.volkov at mail.ru>:

> Edward, I think the point that Simon was making was that sweetened
> expressions like `#bar` could directly instantiate lenses if only Lens was
> a distinct type, instead of an alias to a function. I.e., it would be `#bar
> . #baz`.
>
> Introducing such a change would, of course, exclude the possibility of
> making "lens"-compatible libraries without depending on "lens", like I did
> with "record". However the most basic functionality of "lens" could be
> extracted into a separate library with a minimum of transitive
> dependencies, then the reasons for not depending on it would simply
> dissolve.
>
>
> 2015-01-26 23:22 GMT+03:00 Edward Kmett <ekmett at gmail.com>:
>
>> Personally, I don't like the sigil mangled version at all.
>>
>> If it is then further encumbered by a combinator it is now several
>> symbols longer at every single use site than other alternatives put forth
>> in this thread. =(
>>
>> xx #bar . xx #baz
>>
>> or
>>
>> xx @bar . xx @baz
>>
>> compares badly enough against
>>
>> bar.baz
>>
>> for some as yet unnamed combinator xx and is a big enough tax for all
>> users to unavoidably pay that I fear it would greatly hinder adoption.
>>
>> The former also has the disadvantage of stealing an operator that is
>> already in wide use.
>>
>> Even assuming the fixity issues can be worked out for some other set of
>> operators to glue these tother we're still looking at
>>
>> x^!? #bar!? #baz
>>
>> vs.
>>
>> x^.bar.baz
>>
>> with another set of arcane rules to switch back and forth out of this to
>> deal with the lenses/traversals/prisms/etc that many folks have in their
>> code today.
>>
>> It is something like 3 extra sets of symbols to memorize plus a tax of 3
>> characters per lens use site.
>>
>> I know that I for one would hesitate to throw over my template haskell
>> generated lenses for something that was noisier at every use site. For all
>> that lenses are complex internally, they are a lot less arbitrary than that.
>>
>> The import Field trick is magic, yes, but it has the benefit of being the
>> first approach I've seen where the resulting syntax can be as light as what
>> the user can generate by hand today.
>>
>> -Edward
>>
>> On Mon, Jan 26, 2015 at 8:50 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>> |  "wired" into record selectors, which can't be undone later. I think we
>>> |  can fix some of that by desugaring record definitions to:
>>> |
>>> |  data T = MkT {x :: Int}
>>> |
>>> |  instance FieldSelector "T" T Int where
>>> |       fieldSelector (MkT x) = x
>>> |
>>> |  Then someone can, in a library, define:
>>> |
>>> |  instance FieldSelector x r a => IV x (r -> a) where
>>> |       iv = fieldSelector
>>> |
>>> |  Now that records don't mention IV, we are free to provide lots of
>>> |  different instances, each capturing some properties of each field,
>>> |  without committing to any one style of lens at this point. Therefore,
>>> |  we could have record desugaring also produce:
>>> |
>>> |  instance FieldSetter "T" T Int where
>>> |      fieldSet v (T _) = T v
>>> |
>>> |  And also:
>>> |
>>> |  instance FieldSTAB "T" T Int where
>>> |      fieldSTAB = ... the stab lens ...
>>>
>>> OK, I buy this.
>>>
>>> We generate FieldSelector instances where possible, and FieldSetter
>>> instances where possible (fewer cases).
>>>
>>> Fine.
>>>
>>>
>>>
>>> Cutting to the chase, if we are beginning to converge, could someone
>>> (Adam, Neil?) modify the Redesign page
>>> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign
>>> to focus on plan B only; and add this FieldGetter/Setter stuff?
>>>
>>> It's confusing when we have too many things in play.  I'm sick at the
>>> moment, so I'm going home to bed -- hence handing off in a hopeful way to
>>> you two.
>>>
>>> I have added Edwards "import Field(x)" suggestion under syntax, although
>>> I don't really like it.
>>>
>>> One last thing: Edward, could you live with lenses coming from #x being
>>> of a newtype (Lens a b), or stab variant, rather than actually being a
>>> higher rank function etc?  Of course lens composition would no longer be
>>> function composition, but that might not be so terrible; ".." perhaps.  It
>>> would make error messages vastly more perspicuous. And, much as I love
>>> lenses, I think it's a mistake not to abstraction; it dramatically limits
>>> your future wiggle room.
>>>
>>>
>>>
>>> I really think we are finally converging.
>>>
>>> Simon
>>> _______________________________________________
>>> 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/20150127/f7b1b832/attachment-0001.html>