On Dec 20, 2006, at 2:37 PM, Joachim Durchholz wrote:

Ross Paterson schrieb:
It might be not feasible though. The papers mention that you can't serialize (well, actually unserialize) function values with it. For the envisioned update-through-marshalling process, this would prevent me from ever using function values in data that needs to be persistent, and that's quite a harsh restriction.
That's hard to avoid, unless you have a data representation of the
functions you're interested in.

I could encode functions by their name. I don't think that would scale to a large application with multiple developers, but it's not this kind of project anyway. I'd be reluctant to accept that way if it means adding boilerplate code for every function that might ever be serialized. Since I'm planning to serialize an entire application, I fear that I'd need that boilerplate code for 90% of all functions, so even a single line of boilerplate might be too much.

Let me just say here that what you are attempting to do sounds very difficult. As I understand, you want to be able to serialize an entire application at some (predetermined / arbitrary?) point, change some of its code and/or data structures, de-serialize and run the thing afterwards. Doing something like this without explicit language support is going to be hard, especially in a fairly static language like Haskell.

I would think Smalltalk, Erlang, or something from the Lisp/Scheme family would be more suitable for this sort of work (caveat, I have little experience with any of these languages). Also, take a look here (http://lambda-the-ultimate.org/node/526) for some related discussion.



Regards,
Jo


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
          -- TMBG



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to