
I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up. So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems. My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done. Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes. So what you interested in?

On Mon, May 7, 2012 at 8:03 PM, Leon Smith
I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
Postgresql, pgsql-simple, and Ferry/DSH:) more broadly, I'm looking for something that gives me type safety and efficient joins - I've spent too much time coaxing ActiveRecord not to do N+1 queries to start the whole process over in Haskell. probably just a spectator here, though - I haven't implemented a database in my life... cheers Mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Very long term goal : ANSI SQL compliant RDBMS / OS runing on VM.
Shorter term : Haskell based RDBMS.
I'm quite new to Haskell and still in the early design phase.
2012/5/7 Leon Smith
I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel

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.
[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/zhulikas/...
On Mon, May 7, 2012 at 3:03 AM, Leon Smith
I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel

Hi all, just wanted to say `hi'. We are the folks working on Database-Supported Haskell (DSH on hackage [1]), a library which allows you to continue to use the famililar list-processing combinators -- or list comprehensions, for that matter -- when formulating database queries.[2] Such expressions are compiled into a (small) group of cooperating SQL statements which effectively evaluate the expression over the tables of an associated relational DBMS (these tables are thus looked at as if they were lists of tuples). We are always interested in growing the set of functions that DSH understand as ``database-able''. Further work is underway to support arbitrary non-recursive algebraic datatypes in such queries (based on GHC's generic deriving mechanism). We're thus living on the ``don't embed literal SQL text into your Haskell source at all'' end of the spectrum, somewhat distant from postgresql-simple and friends, I guess. Still, we're quite interested where these other efforts go. Cheers, --Torsten [1] http://hackage.haskell.org/package/DSH [2] http://db.inf.uni-tuebingen.de/research/dsh On 7 May 2012, at 15:56, 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.
[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/zhulikas/...
On Mon, May 7, 2012 at 3:03 AM, Leon Smith
wrote: I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel
-- | Prof. Dr. Torsten Grust | Database Systems — Universität Tübingen (Germany) | torsten.grust@uni-tuebingen.de | db.inf.uni-tuebingen.de

Hello!
I'm particularly interested in getting non-relational databases working
well with Haskell, particularly ones with distributed queries/processing
such as MapReduce. My first goal is to fix up a better interface to
MongoDB's MapReduce for applications using Persistent.
My general interests are SQL-alternatives and distributed computing.
However I'll be swamped for the next two months, so I'm not expecting any
progress any time soon.
Drew Haven
drew.haven@gmail.com
On Mon, May 7, 2012 at 7:10 AM, Torsten Grust
Hi all,
just wanted to say `hi'. We are the folks working on Database-Supported Haskell (DSH on hackag e [1]), a library which allows you to continue to use the famililar list-processing combinators -- or list comprehensions, for that matter -- when formulating database queries.[2]
Such expressions are compiled into a (small) group of cooperating SQL statements which effectively evaluate the expression over the tables of an associated relational DBMS (these tables are thus looked at as if they were lists of tuples).
We are always interested in growing the set of functions that DSH understand as ``database-able''. Further work is underway to support arbitrary non-recursive algebraic datatypes in such queries (based on GHC's generic deriving mechanism).
We're thus living on the ``don't embed literal SQL text into your Haskell source at all'' end of the spectrum, somewhat distant from postgresql-simple and friends, I guess. Still, we're quite interested where these other efforts go.
Cheers, --Torsten
[1] http://hackage.haskell.org/**package/DSHhttp://hackage.haskell.org/package/DSH [2] http://db.inf.uni-tuebingen.**de/research/dshhttp://db.inf.uni-tuebingen.de/research/dsh
On 7 May 2012, at 15:56, 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.
[1] http://www.google-melange.com/**gsoc/proposal/review/google/** gsoc2012/zhulikas/1http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/zhulikas/...
On Mon, May 7, 2012 at 3:03 AM, Leon Smith
wrote: I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
______________________________**_________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/**mailman/listinfo/database-**develhttp://www.haskell.org/mailman/listinfo/database-devel
______________________________**_________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/**mailman/listinfo/database-**develhttp://www.haskell.org/mailman/listinfo/database-devel
-- | Prof. Dr. Torsten Grust | Database Systems — Universität Tübingen (Germany) | torsten.grust@uni-tuebingen.de | db.inf.uni-tuebingen.de
______________________________**_________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/**mailman/listinfo/database-**develhttp://www.haskell.org/mailman/listinfo/database-devel

On Mon, May 7, 2012 at 6:26 AM, Mark Wotton
probably just a spectator here, though - I haven't implemented a database in my life...
I've never implemented a database engine either, and I suspect that
describes a majority of the people here. My wish for a relational
alternative to SQL is just that: a wish. It seems to me that this list
is likely to be far more focused on interacting with existing database
engines, like HDBC, *-simple, persistent, DSH, and the like.
On Mon, May 7, 2012 at 10:10 AM, Torsten Grust
We're thus living on the ``don't embed literal SQL text into your Haskell source at all'' end of the spectrum, somewhat distant from postgresql-simple and friends, I guess. Still, we're quite interested where these other efforts go.
Well, I don't think embedded SQL is entirely bad, but I don't think embedded SQL as particularly desirable either; I see DSH as basically a higher-level layer on top of postgresql-simple and friends. It's just that I'm mucking around in lower-level details right now, trying to get those halfway right, so that DSH can be that much better. Also, it seems to me that the benefits of database-specific features tend to outweigh trying to be database-independent; the least common denominator seems terribly constraining, and even the SQL standard is often not implemented consistently. So one generic concern is that a higher-level abstraction doesn't get in the way of correct, often database-dependent SQL. But I haven't played with DSH, so I would emphasize that this is a _generic_ concern. So I'm basically working at the problem from the opposite direction: looking at the low-level interfaces and the pain points that they cause and trying to improve those. Another obvious problem is failing faster: it'd be really nice to have syntax checking and end-to-end typechecking; although this can't always be done 100% statically because there are reasons to use dynamically-generated SQL. Best, Leon

Hello! I'm the author of hssqlppp, which is a parser and type checker for SQL. I'm interested in writing applications in Haskell with the data in a relational DBMS. This is what I would like to build/use: Typesafe wrapper for SQL in Haskell using quasi quotes, with fallback for SQL which isn't understood by the parser or typechecker. Alternative syntax instead of SQL, but still running on a SQL DBMS - something based on Tutorial D, but with more Haskell-y concrete syntax. Simple DBMS written in Haskell which supports the above two syntaxes. Thanks, Jake.

Hello!
My interest stems from work I'm doing currently that includes trying to
design a nice data frame (a la R) as a library that leverages all of
haskell's good parts. Depending on how the overall project that I'm doing
this for evolves, I might try to grow it into a general (ish) purpose db as
a library.
My interest (via the data frame project) stems from thinking that there is
no nice end to end tool chain from db / data store -> machine learning /
mathematical modellibng -> other things (datavis / actions / various other
things) and experimenting with trying to put my thoughts on this whole
process together
on a more near term and prosaic side, I've a few projects in their nascent
stages that need their algorithmic cores to be written in haskell (for
reasons of correctness and really needing to have things work right) where
I'll also need a gis capable DB, so I hope to help contribute to that part
of the eco system, whether by contribing small
things towards postgres-simple or otherwise.
I"m really excited about this list!
-Carter
On Tue, May 8, 2012 at 2:39 AM, Jake Wheat
Hello!
I'm the author of hssqlppp, which is a parser and type checker for SQL.
I'm interested in writing applications in Haskell with the data in a relational DBMS.
This is what I would like to build/use:
Typesafe wrapper for SQL in Haskell using quasi quotes, with fallback for SQL which isn't understood by the parser or typechecker.
Alternative syntax instead of SQL, but still running on a SQL DBMS - something based on Tutorial D, but with more Haskell-y concrete syntax.
Simple DBMS written in Haskell which supports the above two syntaxes.
Thanks, Jake.
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel

and some of those nascent projects are potentially businesses which I can
use to help lure more great haskell hackers to NYC (I hope :) )
On Tue, May 8, 2012 at 4:40 PM, Carter Schonwald wrote: Hello!
My interest stems from work I'm doing currently that includes trying to
design a nice data frame (a la R) as a library that leverages all of
haskell's good parts. Depending on how the overall project that I'm doing
this for evolves, I might try to grow it into a general (ish) purpose db as
a library. My interest (via the data frame project) stems from thinking that there is
no nice end to end tool chain from db / data store -> machine learning /
mathematical modellibng -> other things (datavis / actions / various other
things) and experimenting with trying to put my thoughts on this whole
process together on a more near term and prosaic side, I've a few projects in their nascent
stages that need their algorithmic cores to be written in haskell (for
reasons of correctness and really needing to have things work right) where
I'll also need a gis capable DB, so I hope to help contribute to that part
of the eco system, whether by contribing small
things towards postgres-simple or otherwise. I"m really excited about this list!
-Carter On Tue, May 8, 2012 at 2:39 AM, Jake Wheat Hello! I'm the author of hssqlppp, which is a parser and type checker for
SQL. I'm interested in writing applications in Haskell with the data in a
relational DBMS. This is what I would like to build/use: Typesafe wrapper for SQL in Haskell using quasi quotes, with fallback
for SQL which isn't understood by the parser or typechecker. Alternative syntax instead of SQL, but still running on a SQL DBMS -
something based on Tutorial D, but with more Haskell-y concrete
syntax. Simple DBMS written in Haskell which supports the above two syntaxes. Thanks,
Jake. _______________________________________________
database-devel mailing list
database-devel@haskell.org
http://www.haskell.org/mailman/listinfo/database-devel

hi, i will mostly lurk here, because i do not currently have any project involving haskell. i am interested in functional-relational programming though and hope to use it once. in the meantime, i will happily but silently follow discussions here. tobias florek

Selfish request: any chance of a demo dsh project, to make it easier to play around with? The types area bit forbidding in a vacuum.
Cheers
Mark
Sent from my iPad
On 08/05/2012, at 12:10 AM, "Torsten Grust"
Hi all,
just wanted to say `hi'. We are the folks working on Database-Supported Haskell (DSH on hackage [1]), a library which allows you to continue to use the famililar list-processing combinators -- or list comprehensions, for that matter -- when formulating database queries.[2]
Such expressions are compiled into a (small) group of cooperating SQL statements which effectively evaluate the expression over the tables of an associated relational DBMS (these tables are thus looked at as if they were lists of tuples).
We are always interested in growing the set of functions that DSH understand as ``database-able''. Further work is underway to support arbitrary non-recursive algebraic datatypes in such queries (based on GHC's generic deriving mechanism).
We're thus living on the ``don't embed literal SQL text into your Haskell source at all'' end of the spectrum, somewhat distant from postgresql-simple and friends, I guess. Still, we're quite interested where these other efforts go.
Cheers, --Torsten
[1] http://hackage.haskell.org/package/DSH [2] http://db.inf.uni-tuebingen.de/research/dsh
On 7 May 2012, at 15:56, 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.
[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/zhulikas/...
On Mon, May 7, 2012 at 3:03 AM, Leon Smith
wrote: I thought I should break the ice here; we currently have 22 subscribers, with names I recognize from acid-state, mysql-simple, postgresql-simple, hssqlppp, persistent, and even PostgreSQL itself. If I've missed anything relevant here, please speak up.
So the goal of this list is to help improve the state of database programming in Haskell; I'm not picky about particular topics as long as they are of reasonable quality and relevant to database programming and Haskell. This could be implementing a database in Haskell itself (like acid-state), to interacting with traditional RDBMSes or newer NoSQL systems.
My personal interest at the moment primarily lies at coming up with a good mid-level interface to RDBMSes along the lines of the -simple libraries, but I also have interest in an auto-pipelining client library for PostgreSQL, which involves some very low-level details of the PostgreSQL frontend/backend protocol. I'm also interested in higher-level abstractions for dealing with relational databases in general, but I really don't have well-formed opinions on how this should be done.
Also while SQL can be cool, it hides that coolness under a lot of syntactic (and some semantic) ugliness; I often wish for a simpler, saner syntax, replacing NULL with algebraic data types, and a richer attribute types, especially relationally valued attributes.
So what you interested in?
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel
-- | Prof. Dr. Torsten Grust | Database Systems — Universität Tübingen (Germany) | torsten.grust@uni-tuebingen.de | db.inf.uni-tuebingen.de
_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel

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
participants (10)
-
Carter Schonwald
-
Drew Haven
-
Greg Weber
-
Henri Chapelle
-
Jake Wheat
-
Jeff Davis
-
Leon Smith
-
Mark Wotton
-
me@ibotty.net
-
Torsten Grust