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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
