I think y'all are talking past each other, a little bit. There are two ways to
serialize a function:
1) Serialize the bytecode for the function.
2) Serialize a persistant reference to a function that resides inside the
executable.
Personally, I think that either strategy is dubious. If you really need this,
I would recommend building a DSL to support your specific needs. When I was
working in Java I trusted the default serializer about as far as I could
physically throw it, and IIRC my associates at the time had the same instinct.
Functions in general can contain references to any data, including objects such
as MVar's who's behavior is actually determined by unreachable entities.
There's no amount of type system magic that can hold off monsters like _|_ or
things like lazy bytestrings that are finite but never intended to be fully
resident in memory. Or do we intend to serialize unevaluated thunks?
Friendly,
--Lane
On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
<l...@downstairspeople.org> wrote:
On Wed, 28 Apr 2010, Ben wrote:
I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume. Why is that unwise?
What are the alternatives?
B
On Tue, 27 Apr 2010, Ben wrote:
slightly off topic, but how does one handle pausing / saving /
restarting in the FRP framework, especially the arrowized version?
If we're about Arrow FRP, remember that the arrow typeclass includes a
function, 'arr', that admits any function as a parameter, and these are in
general impossible to serialize to disk. Since Arrow FRP ends up roughly in
a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the
state of the system. There are a few tactics that would get us around this
limitation, but they are rather severe. You could render 'arr' useless in
several ways, or you could save all the input to a system and replay it.
But I would argue that even if you wanted to do this, "saving an FRP system"
is, to me, like "saving a system in the IO monad," (which, there are tactics
that would let you do this, too). It's probablematic in part because the
FRP system probably has active hooks into the user interface, such as
windows and other widgits that it owns, and possibly other devices (such as
physical rocket engines). Even if the FRP system is completely pure and can
be referenced by a single pointer, it is easily and rightfully aware of
specific details of the hardware it is embedded in.
So it seems to me that what we actually want, to do complex simulations with
persistance, is not an FRP system that interacts with the outside world, but
a "self-contained, self-interacting, differential equation hairball." Such
a system would be very cool, but I think that the numerical algorithms
needed exceed what an FRP system should try to provide.
Friendly,
--Lane
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 28 Apr 2010, Peter Verswyvelen wrote:
As a side note, it's interesting that C# doesn't allow serialization
of closures (anonymous delegates). The compiler-generated name
assigned to an anonymous delegate can be different after each
re-compilation. This is also really annoying in C#/.NET, since one
must explicitly add a named method if serialization is needed. So I
wander how Clean solves this. I mean, consider
data MyData = MD (Int->Int)
myFunc x = x+1
myState1 = MyData myFunc
myState2 = MyData (\x -> x+1)
I can imagine that serializing myState1 is not too difficult, since it
should be possible to lookup the name of the compiled function
"myFunc".
However, what about serializing myState2? The lambda function has no
name, and it is not obvious to me how to give it a name that is unique
enough to survive a couple of iterations of source code modifications.
On Wed, Apr 28, 2010 at 9:56 PM, Gregory Crosswhite
<gcr...@phys.washington.edu> wrote:
On Apr 28, 2010, at 3:41 PM, Limestra?l wrote:
I think the problem with function serialization is that unlike languages which
run over a virtual machine, bytecode generated by GHC is platform-specific
(just as compilated C or C++) and therefore can run directly on top of the
system, which is far faster but less portable.
Is this true? I thought that ghc has separate machine code and byte-code
modes, and inferred that the latter was platform-independent. Is the latter
platform-specific because it is just a different way of organizing different
ways of (unlinked) machine code, or because parts of the byte-code depend on
things like the size of integers in the compilation machine that are
platform-dependent?
Also, it is worth noting that Clean supports serialization of values including
closures. It's not entirely clear to me how they do this, but looks like some
combination of seeing whether a referenced routine is already in the current
executable, then seeing whether it is in a nearby library, and then finally
just-in-type compiling the serialized platform-independent bytecode into native
code.
Cheers,
Greg
_______________________________________________
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
