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