On the subject of bridging relational persistence and fucntional programming I wish to communicate on what I'm working on (Tránsito Abierto Library) (or Open Transit): 1) Whole objective: To disminish to gap between functional and relational paradigms. 2) Specific objetive: Illustrate and explore the gap. 3) Narrow focus: I'm using Takusen and Oracle and Haskell (á la GHC). And Template Haskell (TH). 4) Hypothesis: There'll be always a gap because you're using distinct nature beasts, but you a bit more of convinience would yield great improvements. 4.1) Another thought on this is: A mapping always needs to be specified between data shapes (types/representations). 5) Findings/Achievements(?): 5.1) Generation of Haskell types and iterator code given the shape of relational table. This is not very useful itself. Because of (4.1), using SQL is an effective way to: (1) convey such mapping and (2) specify queries that involve more than one table. 5.2) Given a sql query text, use the facilities on Oracle database to describe the query. With such description, use Template Haskell to generate Haskell types and iterator code. Let us call Geco to this generated code that is built by means of an AST. 5.3) As 5.2 (spliced Geco) but saving the Geco AST. What for? It turns out that later, during program execution you can regenerate a fresh AST code and compare it to Geco AST. If there's a difference it means your database environment is changed and it is likely that your code is no longer safe. The idea here, your program reacts to the enviroment detecting if its unsafe to run. 5.4) Takusen covers many database datatypes but not all. 5.5) I was about to automate pl/sql bindings using a inspired Takusen wrapper found on the enumerator tests directory . It follows scheme 5.2. But it is uncomplete. 5.6) Takusen is limited to iterators up to 8 fields. By using TH, easily you can have any number of columns in your query. 5.7) I wrote a serialiser library on the DB side and a deserialiser library on Haskell side. The idea it's to push *any* pl/sql result onto a string and recover it on the Haskell side. Needs schemes 5.2 and 5.5 to work. Status: Not working. 6) I believe intelligent schema generation is possible following the scheme above. What you would get is a whole module that would enforce constraints (cardinality, restrictions, etc). 7) I haven't try the way Haskell -> DB. Neither the storing of functional values as it was done before in Persistent Haskell and others. Cheers, -- Leonel Fonseca.