<div>For distributed execution you can look at the recent work on "CloudHaskell":</div><div><br></div><div> <a href="https://github.com/jepst/CloudHaskell" target="_blank">https://github.com/jepst/CloudHaskell</a></div>
<div> <a href="http://groups.google.com/group/cloudhaskell" target="_blank">http://groups.google.com/group/cloudhaskell</a></div>
<div><br></div><div>As for a programming model -- Philip Trinder et. al have a version of monad-par that works in a distributed way over CloudHaskell, likewise CloudHaskell itself provides a simple "Task" layer.</div>
<div><br></div><div>For a NOSQL layer -- I'm looking for the answer to that same question myself! We've been experimenting with Cassandra (used via the hscassandra package based in turn on cassandra-thrift). Already it's clear that there are many areas that need work. The Haskell code generated by Thrift itself has a lot of room for improvement (for the intrepid hacker: cycles there would be well-spent).</div>
<div> We haven't tried CouchDB yet. Please keep us posted on what you find.</div><div><br></div><div>I don't know if any one has a clean way for hooking a simple Haskell-ish interface (e.g. Data.Map) up to a persistence layer. But it seems like there have been a bunch of papers on "database supported haskell" and the like. One of them must have solved this!</div>
<div><br></div><div> <a href="http://hackage.haskell.org/package/DSH" target="_blank">http://hackage.haskell.org/package/DSH</a></div><div><br></div><div>Cheers,</div><div> -Ryan<br><br><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 4:53 PM, dokondr <span dir="ltr"><<a href="mailto:dokondr@gmail.com" target="_blank">dokondr@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, Oct 31, 2011 at 6:50 PM, John Lenz <span dir="ltr"><<a href="mailto:lenz@math.uic.edu" target="_blank">lenz@math.uic.edu</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
CouchDB works great, although I decided to go with SimpleDB since then it is amazon's problem to scale and allocate disk and so forth, which I like better. For couchdb, you can use my package couchdb-enumerator on hackage.<div>
<br><br></div></blockquote><div>Regarding CouchDB. So far I have my records keyed by Id and stored in Data.Map which I serialize to text file. Using Data.Map functions I do many operations with these records including mapping functions over keys and values, accumulation, lookup, intersection, union etc.<br>
When I move this data to CouchDB and start using couchdb-enumerator to work with it, how natural will it be to implement all these functions that I use from Data.Map? <br>Or maybe it makes more sense to store my serialized Data.Map as a blob in CouchDB? And do not use views or similar CouchDB / SimpleDB interfaces at all? Just retrieve necessary blob and deserialize it to Data.Map, update and then store modified blob to CouchDB again?<br>
<br>It would be great if somebody had time to implement Data.List, Data.Map, etc on top of generic NoSQL DB interface with specific instances for CouchDB, SimpleDB, etc. <br></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>