Records in Haskell: Type-Indexed Records (another proposal)

[AntC]

Matthew Farkas-Dyck <strake888 <at> gmail.com> writes:

> 
> 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