16:23:59 <kizzo> Does happstack have an ORM, in the same way that Django does?
16:24:40 <kizzo> I'm trying to find reasons to use happstack for my next project instead of Django, and the hardest thing to part with is Django's ORM.
16:25:29 <kizzo> Haskell, in general, doesn't (appearantly) have damn-near any ORMs;
16:25:56 <kizzo> I have seen postgresql-orm (http://hackage.haskell.org/package/postgresql-orm-0.2.2), which is cool.
16:26:19 <kizzo> Someone respond (jk).
16:26:31 <donri> kizzo: ORM doesn't make much sense for acid-state
16:26:47 <kizzo> hmm.. quote-on-quote "acid-state"
16:27:04 <kizzo> Looking into that..
16:27:12 <donri> perhaps the closest thing to an ORM in haskell would be persistent
16:28:20 <kizzo> A big concern for me is making use of PostgreSQL (I love that database), but without using any SQL in the code (django, haskell, whatever).
16:28:39 <kizzo> If this acid-state or persistent thing does that, then we're gold maybe.
16:28:43 <kizzo> Checking out..
16:29:20 <kizzo> Seems exactly what the term ORM is for - using SQL but w/o that syntax and stuff.
16:30:49 <donri> kizzo: acid-state doesn't use external databases at all
16:31:23 <donri> kizzo: it's more similar to ZODB in python, but with a haskell twist
16:32:12 <donri> kizzo: if you want postgres without SQL, probably one of persistent, esquelito, haskelldb
16:33:01 <donri> ACTION personally thinks that the main reason to use something like postgres is for the power you get if you do in fact write the SQL by hand
16:48:03 <kizzo> hmm
19:42:19 <stepcut>  kizzo: acid-state is self contained, and is written from the ground up to use haskell datatypes for storage, and haskell functions for querys and updates. If you really want an underlying SQL database behind your system, then you can use things like persistent or haskelldb or some other things like that -- which allow you to abstract away from RAW SQL to varying degrees. Though I have little experience with those, because I am 100%
19:42:19 <stepcut>  acid-state for my projects :)
19:42:51 <stepcut> trying to mapping things like Tree into a SQL database is .. sucky no matter how you try it ;)
20:02:08 <yesthisisuser> Hello. The other day I was playing around with acid-state and a GADT data type.. Is there any way of deriving safecopy for such data?
20:07:08 <stepcut> I don't think so
20:07:29 <stepcut> I think the deriving mechanism does not support GADTs
20:07:44 <stepcut> did your type actually require GADTs or did you just want to use the GADT syntax?
20:08:28 <yesthisisuser> thanks .. let me paste some code and explain what I am trying to do
20:09:40 <yesthisisuser> http://lpaste.net/95984
20:10:23 <yesthisisuser> The ActionStack is what I would like to use as state
20:11:36 <stepcut> yes. that will be tricky -- or perhaps impossible
20:11:40 <yesthisisuser> of course, there are other fields on the Action data .. but I stripped out everything to show the basic idea
20:12:43 <yesthisisuser> yes.. hmm.. i ended up using a datatype   data Action = Action Action1 | Action2 | .. etc  instead
20:13:02 <yesthisisuser> making the code a lot less modular
20:13:07 <stepcut> the point of existential types is that you can't know what is in them
20:13:13 <stepcut> which makes it very hard to serialize and deserialize them
20:13:27 <stepcut> for the same reason you can't write Read/Show instances
20:13:52 <stepcut> well.. you can do Show.. I think Read is the hard part
20:14:10 <yesthisisuser> sure.. show works fine.. and deriving typeable seems to work
20:17:42 <stepcut> so, let's say you want a function like: decodeValue :: ByteString -> Action
20:19:35 <stepcut> there is not enough type information to know which decode function to call to decode the underlying 'a' value
20:20:29 <stepcut> the reason, you can do 'show' on an Action value is that when that Action value was created, there was enough type information available to know which show function to bundle up in the Action
20:20:53 <yesthisisuser> i have a feeling that what I'm asking for here is dependent typing
20:21:38 <stepcut> likewise, you could have a function like, decodeValue :: a -> ByteString -> Action -- where 'a' has the same type as the value you think is encoded in the 'ByteString'
20:22:24 <stepcut> but then you have to have some other mechanism that knows what type is in the Action -- which negates the whole purpose of hiding that information in the first place
20:25:07 <yesthisisuser> http://lpaste.net/95987
20:25:39 <yesthisisuser> that is pretty much what i am trying to do
20:25:40 <yesthisisuser> BUT
20:26:13 <yesthisisuser> making it possible for client code to add this actions is separate modules
20:26:29 <yesthisisuser> *these
20:26:32 <stepcut> you want to be able to extend both data structures and the functions that operate on them in a modular fashion?
20:26:48 <yesthisisuser> yes
20:27:01 <stepcut> are you familiar with 'the expression problem' ?
20:27:06 <yesthisisuser> no
20:27:48 <yesthisisuser> (googling)
20:31:05 <yesthisisuser> .. but GADTs surely works as a solution here.. just i lose the ability to serialize the data
20:31:46 <stepcut> http://citeseerx.ist.psu.edu/viewdoc/download?doi=
20:31:55 <stepcut> got disconnected
20:32:01 <stepcut> this is the original statement of the problem, http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt
20:32:14 <stepcut> though there are clearer formulations of it
20:33:02 <stepcut> basically, it is easy to have closed data types and open functions, or open data types and closed functions -- but having both open at the same time is .. an ongoing research problem :)
20:33:52 <yesthisisuser> yes.. i can see how this is what i am experiencing here
20:34:11 <yesthisisuser> i am a complete newbie when it comes to type theory.. i have started reading Harper's book recently
20:37:27 <yesthisisuser> so basically i am stuck with a GADT and no "acid" .. or a plain old data type. .but no modularity
20:38:35 <stepcut> this is a pretty good explanation, http://c2.com/cgi/wiki?ExpressionProblem
20:41:50 <stepcut> you could possibly make things work with the GADT if you impose certain limitations
20:42:15 <yesthisisuser> hmm.. type families are not of any help here or?
20:42:36 <stepcut> basically, your SafeCopy instance for Action has to know about every possible type that might appear serialized in the database
20:42:53 <stepcut> and then it needs a map from Typeable -> decoding function for all those types
20:43:26 <stepcut> when you serialize the data, you include the TypeRep in the serialized format, and when you decode it, you use the TypeRep to find the right decoding function
20:44:24 <stepcut> to make that map, you are going to have to do it by hand though -- and on a per-program basis -- since each program could extend that list with new types
20:44:43 <yesthisisuser> I guess i could have some sort of configuration file.. and when I add a module with a new Action..
20:44:44 <stepcut> and, if you forget to include a type -- then you will get a runtime error
20:46:42 <stepcut> that said -- you are likely to keep running into these types of problems if you head down that path -- i think very few people use existentials like that in real haskell code
20:47:23 <yesthisisuser> yes maybe it's not a good idea
20:48:48 <stepcut> there are some places that existentials are used -- such in exception handling
20:49:09 <stepcut> but the 'fake OO using existentials' pattern is not well loved
20:49:15 <yesthisisuser> but it is almost like a heterogeneous lists .. hehe
20:50:11 <stepcut> indeed
20:51:25 <yesthisisuser> maybe i should go for some sort of Template Haskell solution
20:53:05 <yesthisisuser> hmm..  this is one of the reasons i can understand why people defend relaxed type safety in languages like Erlang
20:54:26 <yesthisisuser> fake-OO.. haha.. is that what it is called.. and I thought i was being clever
21:17:29 <stepcut> that's what I call it.. not sure if it has an actual name
21:18:23 <stepcut> the relaxed type safety doesn't really fix the problem though does it ?
21:26:16 <yesthisisuser> well .. if i don't have to worry about what i function accepts as argument. then that would give me a lot more flexibility here.. but i am not saying that it is better in any way
21:38:38 <yesthisisuser> i think i will just do something like this: http://lpaste.net/95989
21:39:33 <yesthisisuser> then i could use code generation and TH to make it more "fancy"
22:05:43 <stepcut> possibly
22:07:44 <yesthisisuser> anyway thanks for the help. this problem was not so Happstack-related
22:08:01 <stepcut> you want to make a game, and then allow people to extend the game play through addon modules?
22:10:33 <yesthisisuser> no it's an idea i have .. i am trying to build a server-API where all actions are reversible.. and the server maintains a state that is distributed across a number of nodes in a network
22:11:03 <yesthisisuser> like in the "command" pattern in OO.. or an Undo/Redo-stack
22:11:30 <yesthisisuser> so each node has its own state that it operates on.. with these actions
22:14:34 <yesthisisuser> the modularity is really more for making the code more organized
22:40:23 <stepcut> sounds like the plain ADT is the way to go then
22:51:31 <yesthisisuser> i recall there is a GHC extension that allow me to write something like ... data Action = A | B | C .... data X (a :: Action)
22:51:46 <yesthisisuser> .. but that's just even more confusing
22:52:53 <yesthisisuser> i guess that is KindSignatures/DataKinds  .. and I don't think that would even help here