[Haskell-cafe] A most inelegant approach to "extensible records"

[Günther Schmidt]

Hi everyone,

as I'm trying to design a "query language" the one thing that causes the 
most grieve is the apparent requirement for "extensible records".

There are by now a number of solutions in Haskell for this, most 
prominently HList.
But at the end of the day even for HList to work one needs to define 
singleton types, something like:

data FirstName = FirstName
data LastName = LastName
data BirthDate = BirthDate

Now this isn't much of a nit and at least it works.

But overall review of "extensible records" indicates that any 
solution/implementation requires a tremendous amount of type-level trickery.
I short, any approach I've seen so far uses elaborate type class 
hierarchies, functional dependencies, etc., all coding on the *type* level.

I have here a very, very inelegant alternative, of which I wonder if it 
offers a new angle to pursue the whole thing.

1. Initial "Record"

	names = \fn -> fn "firstName" "lastName" "birthDate" "zipCode"

Please ignore for now that all "fields" are of type String.


2. "Extension" of Record

	namesCity = \fn -> names fn "residence"

The record (1.) gets "extended" by the field "residence"


3. Selection

	nameZip n _ _ _ z = \fn -> fn n z

basically here we "extract" the fields firstName and residence.


4. Test

toList a b = [a, b]

test = (namesCity nameZip) toList


Now I know this is all very very inelegant and at 1st sight totally 
unfeasible. But maybe we can use Conal Eliots semantic editor 
combinators to smoothen this out?

Günther