I apologize that this is sent twice, but I think only part of it was sent in the previous message. # Groundhog We discussed Persistent and Groundhog with Boris, the author of Groundhog who was kind enough to show up and meet with us. The differences were summarized: * groundhog uses gadts to greatly clean up PersistEntity, and to avoid the need for a bunch of associated types and extra constructors. downside: gadts + type families is a ghc 7 feature, although it might be possible to use phantom types and support ghc6 * persistent requires all datatypes be defines through its QQ syntax, groundhog allows types to be declared as normal. i think this allows persistent to sidestep a lot of sticky naming issues, but groundhog is more flexible * groundhog supports "and" and "or", persistent only supports "and * groundhog use operators, persistent uses constructors * groundhog supports complex arithmetic expressions * groundhog supports comparing fields to fields

From a Persistent standpoint we want all of these features. There are a few minor issues we didn't like, such as preferring our current naming convention to groundhog's, in which 'Field' is appended to every field instead of pre-pending the table name. The main thing we didn't like about Groundhog is its support for Sum data types, which is a neat feature, but complicates the rest of the persistence library, and makes some other functionality more difficult. There are also a few other implementation differences.

The direction we want to take Persistent is to incorporate all the good features. This means breaking the current API to make a much nicer one. We plan on providing an upgrade script, much like the upgrade script from hamlet 6 to 7. After Yesod hits 1.0 we will be much more careful to change APIs, all the more reason to make some more drastic changes now. Boris was even kind enough to offer his help in incorporating these features in into Persistent. But 1) he wants to see how it all shakes out first and 2) we don't want to limit his excellent experimentation, so there will be no official merge now. We will continue to try to standardize the APIs of the 2 packages. # Future Meeting Technologies Text meetings can seem a bit laborious at times, although it makes it easy to write this summary. Particularly if we want to hack on some code, it would be much nicer to have audio. I tried out the EVO conferencing tool that was suggested. From a UI standpoint it was a craptacular Java Servlet. It does seem quite featureful, although audio did not work by default on my Ubuntu computer, and the window was annoyingly shaky, possible it doesn't like XMonad. It also uses quite a bit of CPU. So I don't think this is a good solution. I am open to other suggestions. Here are others that I found, but have not tried yet: * https://www.webhuddle.com/ * http://www.openmeetings.de/ Otherwise, we will just do skype breakout sessions as needed. # Future meeting times I created a doodle that people can mark time on next week: http://doodle.com/av92qzmvwyh48hcs Doodle isn't really setup well for large ranges of time though. See you next week! Greg Weber