GHC support for the new "record" package

[Nikita Volkov]

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/5aac66d3/attachment.html>