Matthew Farkas-Dyck
Hello all.
I wrote a new proposal for the Haskell record system. It can be found at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords
Records are indexed by arbitrary Haskell types. Scope is controlled as scope of key types. No fieldLabel declarations needed (as in DORF).
Cheers, strake
Thanks Matthew, It's good to explore the design space. Apart from the Quasifunctor bit, I think you'll find your proposal is a rather cut-down version of DORF, just using different syntactic sugar. (Oh, and with the arguments to Has in a different order, just to be confusing.) You do have the equivalent of fieldLabel decls. Those are all your type indexes: data X = X, etc. And you suggest defining x = X Which is equivalent to DORF mapping from field name `x` to phantom type Proxy_x, (but DORF keeps `x` as a field selector function, similar to H98). To make `x` a selector function instead, you'd go: x = (.) X -- or probably x = get X, see below Which is exactly the same as DORF (after adjusting for the different order of arguments). And presumably instead of X you'd want a LongandMeaningfulLabel? And if your data Customer_id = Customer_id was always an Int field, wouldn't it help the reader and the compiler to say that? (That's the main extra part in fieldLabels.) 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. Oh, and how do you deal with multiple record constructors as in H98: data T a = T1 { x :: a, y :: Bool } | T2 { x :: a } It wouldn't work to have a different record type for each constructor, 'cos you'd turn functions that use them from mono to polymorphic (overloaded -- needing a class and instances). 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 think you still need method get and sugar to turn the dot notation into a call to get. Having method (.) will usurp altogether dot as function composition -- you'll make a lot of enemies! And we need tight binding for dot notation, so we might as well treat it as special syntax. You don't show how you'd do record update. The litmus test is what is the type for: r{ X = True } That is: update record r, set its X field to True. AntC