Hello,
I just read through Adam's proposal and here is my take:
1. I like the general idea---in particular:
- backwards compatibility is very important to me as I make extensive use
of records in all my code,
- for me, anonymous records are fairly low priority
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.
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.
- @x might be a better choice; then you could write things like:
view @x rec
set @x 3 rec
over @x (+2) rec
- 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
-Iavor
On Fri, Jan 23, 2015 at 2:25 AM, Adam Gundry <a...@well-typed.com> wrote:
> On 23/01/15 10:17, Simon Marlow wrote:
> > On 23/01/2015 04:12, Johan Tibell wrote:
> >>
> >>
> >> On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow <marlo...@gmail.com
> >> <mailto:marlo...@gmail.com>> wrote:
> >>
> >> On 21/01/2015 16:01, Johan Tibell wrote:
> >>
> >> My thoughts mostly mirror those of Adam and Edward.
> >>
> >> 1) I want something that is backwards compatible.
> >>
> >>
> >> Backwards compatible in what sense? Extension flags provide
> >> backwards compatibility, because you just don't turn on the
> >> extension until you want to use it. That's how all the other
> >> extensions work; most of them change syntax in some way or other
> >> that breaks existing code.
> >>
> >>
> >> In this case in the sense of avoiding splitting code into a new-Haskell
> >> vs old-Haskell. This means that existing records should work well (and
> >> ideally also get the improved name resolution when used in call sites
> >> that have the pragma enabled) in the new record system.
> >
> > I understand that position, but it does impose some pretty big
> > constraints, which may mean the design has to make some compromises.
> > It's probably not worth discussing this tradeoff until there's actually
> > a concrete proposal so that we can quantify how much old code would fail
> > to compile and the cost of any compromises.
>
> In this spirit, I've started to prepare a concrete proposal for a
> revised OverloadedRecordFields design, based on recent feedback:
>
>
> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign
>
> This would not necessarily include anonymous records at first, but they
> do fit nicely as a potential later extension, and it would work well
> with a slightly amended version of the record library in the meantime.
> I'd be very interested to hear what you think of this.
>
> Also, if someone would be prepared to flesh out a proposal based on the
> anonymous records idea, that might be a useful point of comparison.
>
> Adam
>
> --
> 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
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
