Re: a universal printer for Haskell?

Hi Haskellers,

...

...

...

...

"Bernard" == Bernard James POPE writes:

Bernard> Handling functions is always going to be hard. Actually, a Bernard> related issue in Haskell is what do you do with partially Bernard> evaluated structures? Certainly in some circumstances you Bernard> don't want to force the value just so that you can write it Bernard> out. sorry if I wasn't precise enough. I don't want to force ANY evaluation on the value to be marshalled; in some cases the computation may even not terminate! Instead, the string is an encoding of the smallest part of the heap that is necessary to restore the information. My aim is to save a state which contains unevaluated closures to disk and resume the computation at a later time or to send a state to a remote location. The nice property of a functional language, in contrast to imperative languages, is that you can make a snapshot of your computation without any support by the runtime environment if, of course, those (un)marshalling functions are available. Bernard> If you compiled to byte code, life would be a lot Bernard> easier, however everything will get a lot messier if you Bernard> want to mix machine code and byte code. urgh... The problem is to encode program functions, not just functions that arise during the computation. Compiling to byte code is a different issue. Bernard> It would be nice if you could write out some data to file from Bernard> GHC and then read it in using NHC :) That'll be very complicated and require a deep discussion about an interface language. Bernard> I think Clean has a prototype persistence mechanism, I saw Bernard> a short demo late last year. I'm not sure how they Bernard> represent functional values. I think you can only read the Bernard> data from within the same program that wrote the data. That would be OK for me. It would even be OK if it is the same binary, i.e., not to be used in heterogeneous networks. Anyway, I don't like to change my favourite programming language unless it's better than Haskell and that'll be very likely Haskell-II :-) Cheers -- Christoph