One way to avoid explicit, per-type unmarshalling is to use the existentialquantification extension to make a box type that you can store in a map, thus producing a heterogenous map of any types (with constraints).
Cheers. ~Liam On 19 June 2010 04:08, aditya siram <[email protected]> wrote: > I've written code with less bugs in Haskell than any other language > I've used. And that's a credit to GHC and not because I'm a great > programmer. > > But I still don't know how to deal with the situation where you don't > have a clear picture of your data or heterogenous data that you are > wrapping up in a type just to make the compiler happy? > > Here's an example of the latter: I was writing some Haskell web app > code where continuations are used to compose multi-step web > transactions. The continuations were stored in a map keyed with a > unique session id and invoked when the user POST'ed back that session > id. The problem was that the map would only accept functions of one > intermediate type and one result type. So I had to marshall/unmarshall > all my functions to some common type (ContT () IO String in my case) > just so I could store it in the map - which felt kind of dirty. > > While pointers on this particular problem would be appreciated, I > think this is the kind of issue (needing to be flexible about data > types) is a stumbling block for many beginning Haskell programmers. > > -deech > > > On Fri, Jun 18, 2010 at 12:44 PM, Andy Stewart > <[email protected]> wrote: >> "Edward Z. Yang" <[email protected]> writes: >> >>> Excerpts from Bryan O'Sullivan's message of Fri Jun 18 13:16:58 -0400 2010: >>>> I'm inclined to disagree. It's precisely when the code is in a state of >>>> constant upheaval that I want the type system to be pointing out my dumb >>>> errors. >>> >>> In my experience, the type system has forced me to care about thing that I >>> don't want to care about (yet). It's a different mindset: in the words of >>> the >>> prototyper: being first is valued over being correct. >>> >>> This does mean that Haskell forces you to write long-term maintainable >>> code from the get-go, yes. :-) >> Haha, that's true. :) >> >> When i write Haskell code, it force me write *framework* code. >> >> Sometimes, i wrote dirty code quickly, >> Haskell will told me : >> >> "Hey, bad code! Rewrite it! I don't accept dirty code ... bla bla ...". >> >> Then i rewrite my code to make it flexible and maintainable. >> >> Once you build beautiful framework code, you will find your life is so >> simple. :) >> >> Cheers, >> >> -- Andy >> >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
