Folks, Allegro Common Lisp has AllegroCache [1], a database built on B-Trees that lets one store Lisp objects of any type. You can designate certain slots (object fields) as key and use them for lookup. ACL used to come bundled with the ObjectStore OODBMS for the same purpose but then adopted a native solution. AllegroCache is not distributed or replicating but supports automatic versioning. You can redefine a class and new code will store more (or less) data in the database while code that uses the old schema will merrily chug along. Erlang [2] has Mnesia [3] which lets you store any Erlang term ("object"). It stores records (tuples, actually) and you can also designate key fields and use them for lookup. I haven't looked into this deeply but Mnesia is built on top of DETS (Disk-based Term Storage) which most likely also uses a form of B-Trees. Mnesia is distributed and replicated in real-time. There's no automatic versioning with Mnesia but user code can be run to read old records and write new ones. Would it make sense to build a similar type of a database for Haskell? I can immediately see how versioning would be much harder as Haskell is statically typed. I would love to extend recent gains in binary serialization, though, to add indexing of records based on a designated key, distribution and real-time replication. What do you think? To stimulate discussion I would like to ask a couple of pointed questions: - How would you "designate" a key for a Haskell data structure? - Is the concept of a schema applicable to Haskell? Thanks, Joel [1] http://franz.com/products/allegrocache/index.lhtml [2] http://erlang.org/faq/t1.html [3] http://erlang.org/faq/x1409.html -- http://wagerlabs.com/