GHC support for the new "record" package

[Adam Gundry]

Thanks for the feedback, Iavor!

On 23/01/15 19:30, Iavor Diatchki wrote:
> 2. I would propose that we simplify things further, and provide just one
> class for overloading:
> 
> class Field (name :: Symbol)
>             rec   rec'
>             field field'
>   | name rec         -> field
>   , name rec'        -> field'
>   , name rec  field' -> rec'
>   , name rec' field  -> rec
>   where
>   field :: Functor f => Proxy name -> (field -> f field') ->
>                                       (rec   -> f rec')
> 
> I don't think we need to go into "lenses" at all, the `field` method
> simply provides a functorial
> update function similar to `mapM`.   Of course, one could use the `lens`
> library to
> get more functionality but this is entirely up to the programmer.
> 
> When the ORF extension is enabled, GHC should simply generate an
> instance of the class,
> in a similar way to what the lens library does.

There's something to be said for the simplicity of this approach,
provided we're happy to commit to this representation of lenses. I'm
attracted to the extra flexibility of the IsRecordField class -- I just
noticed that it effectively gives us a syntax for identifier-like Symbol
singletons, which could be useful in completely different contexts --
and I'd like to understand the real costs of the additional complexity
it imposes.


> 3. I like the idea of `#x` desugaring into `field (Proxy :: Proxy "x")`,
> but I don't like the concrete symbol choice:
>   - # is a valid operator and a bunch of libraries use it, so it won't
> be compatible with existing code.

Ah. I didn't realise that, but assumed it was safe behind -XMagicHash.
Yes, that's no good.


>   - @x might be a better choice; then you could write things like:
>     view @x      rec
>   set  @x 3    rec
>   over @x (+2) rec

This could work, though it has the downside that we've been informally
using @ for explicit type application for a long time! Does anyone know
what the status of the proposed ExplicitTypeApplication extension is?


>   - another nice idea (due to Eric Mertens, aka glguy), which allows us
> to avoid additional special syntax is as follows:
>     - instead of using special syntax, reuse the module system
>     - designate a "magic" module name (e.g., GHC.Records)
>     - when the renamer sees a name imported from that module, it
> "resolves" the name by desugaring it into whatever we want
>     - For example, if `GHC.Records.x` desugars into `field (Proxy ::
> Proxy "x")`, we could write things like this:
> 
> import GHC.Records as R
> 
> view R.x      rec
> set  R.x 3    rec
> over R.x (+2) rec

Interesting; I think Edward suggested something similar earlier in this
thread. Avoiding a special syntax is a definite advantage, but the need
for a qualified name makes composing the resulting lenses a bit tiresome
(R.x.R.y.R.z or R.x . R.y . R.z). I suppose one could do

    import GHC.Records (x, y, z)
    import MyModule hiding (x, y, z)

but having to manually hide the selector functions and bring into scope
the lenses is also annoying.

Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/