Matthew Farkas-Dyck <strake888 <at> gmail.com> writes: > > > I think you don't want all those type vars in your record decls -- but only > > vars for the mutatable types, like this: > > > > type R c = { X ::. Int, Y::. String, Z ::. c, ... } > > > > Then you don't need a Quasifunctor instance for every field, only the > > mutatable ones. > > Yes, I know. That is just a very general example. > > > Oh, and how do you deal with multiple record constructors as in H98: > > data T a = T1 { x :: a, y :: Bool } > > | T2 { x :: a } > > > Not sure what you mean. With an argument of such a multiconstructed > type, I would do as ever in Haskell: pattern-match.
So please show what record declarations look like. And how they get turned into Has instances. Your example decl on the wiki for R a b c is not valid Haskell. What's more the wiki hss it as a `type`. Did you mean a `data`? I'm confused. > > > You don't give full details for your Has instances, but presumably you'd do > > the same equality constraint style as SORF and DORF. > > I assume you mean > instance (v~a) => Has k v (R a) where ... > > I'm not sure why we need this, but I assume that we do, since it was > written by SPJ, so yes. > Matthew, you really, really need to understand why SPJ put it that way, if you want your proposal to be taken seriously. He wasn't just making it up. > > You don't show how you'd do record update. > > Yep. It's on the wiki. > "qfmap X f r is r mutated by f at X" > So do you mean this is what developers put in the code? > > what is the type for: > > r{ X = True } > > That is: update record r, set its X field to True. > > This is written as > qfmap X (const True) (r :: r) :: Quasifunctor X a Bool r s => s; > You mean this is what to put in the code? DORF is getting beaten up for the amount of boilerplate the programmer is expected to add (for fieldLabels, etc.) I can't compare apples with apples for your proposal, because I can't see what the code looks like that would appear in the program. So far (apart from Quasifunctor) all I can see is that you're varying the sugar, without adding anything to the semantics -- except you've not given the surface syntax, so I'm only guessing. AntC _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users