
Have you considered moving these packages that are unrelated to web
development into a separate namespace? I know that I never considered
looking under the happstack namespace simply because I never do webapps.
On Thu, Dec 16, 2010 at 5:09 PM, Jeremy Shaw
Hello,
You should use happstack-data for this (you do not need the other happstack components to use happstack-data)*. It was created to solve this exact problem.
happstack-data builds on type of the 'binary' library and adds versioned data types and automatic version migration.
You can get an idea as to how it works by reading this old blog post,
http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
The modules names have changed from HAppS.* to Happstack.*, but otherwise it is still pretty accurate. The upcoming happstack 7 release cycle will be focusing on this area of happstack. Especially improved documentation. But, it is quite usable right now.
If you have questions about happstack-data, feel free to ask on the happstack mailing list or irc channel. (http://happstack.com/community)
I am happy to answer any questions or concerns you may have.
- jeremy
* the version on hackage depends on happstack-util, but the darcs version does not.
On Dec 16, 2010, at 12:26 PM, Dmitry V'yal wrote:
Greetings,
while developing my neural net simulator I stumbled upon a problem.
I have a data type NeuralNet and use Show and Read instances for saving and loading configurations. As time passed, I changed the data type, so the program can no longer load files saved in previous versions.
I want fix it. My current idea looks as follows. I'm going to create a bunch of types NN1, NN2, NN3..NNn for different versions and write converters c12 :: N1 -> N2, c23 :: N2 -> N3 and so on.
But how to organize the whole process of parsing String into NNn so it's easy to change formats? Something based on using a list of parsers [read, c43 . read, c43 . c23 . read, c43, c23 . c12 . read, c43 . c32 . c21 . read]
looks rather verbose and grows quadratically with N.
I'm sure there must be a more elegant way. Any ideas?
Dmitry
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe