On Mon, 2012-05-07 at 06:56 -0700, Greg Weber wrote:
I worked with a student to lay out a vision for type-safe database access in a GSoC proposal [1]. I have little interest in the SQL variant at the moment, but plan on making a MongoDB version when I get a free weekend, which may not be until after I am done mentoring GSoC projects.
I come from the postgresql world, and my perspective is that Haskell is, loosely speaking, the language that SQL should be. SQL is statically typed with lazy evaluation, type inference, immutable state, controlled side effects. It's just, well, ugly, and the type system is a little squishy in some ways, and it has NULLs. All things that haskell can fix. However, I strongly caution haskellers to understand an actual SQL system like postgresql before embarking on a project like this. I've spent a lot of time thinking about how database systems should be, and their relationship to applications, and it's complicated. One thing that I've decided is vitally important is that the database system needs first-class support for all of the types that the application is concerned with -- and I don't mean just ints and strings and timestamps -- I mean _all_ of the interesting types. Although haskell is, in some ways, at the forefront of type systems, I believe that a DBMS offers new challenges that you may not have encountered before. For instance, you need to deal with data representation issues, index support, query optimization, and the fact that you have a running system that you are sending code fragments to (What about adding new types while the system is up? How does that affect the type resolution of other queries already present in other binaries?). I strongly encourage the haskell community to take a closer look at a system like postgresql, where you can see how pervasive types are and why they are important to a DBMS. Regards, Jeff Davis