[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] serialization of functions, closures, continuations
From: |
F. Wittenberger |
Subject: |
Re: [Chicken-users] serialization of functions, closures, continuations |
Date: |
Thu, 19 May 2005 10:47:28 +0200 |
> > 3. Can I serialize a continuation?
You might be interested in Askemos (www.askemos.org).
It is a transactional framework, where each so called "place" is in fact
a persistant continuation. Otherwise the progamming model somewhat
alludes to Erlang, where processes communicate via unreliable
asynchronous messages.
In contrast to simillar frameworks those places kept in virtual
synchrony (byzantine synchronisation) over a p2p network. In other
words, persistant data like xml trees, hash tables etc. are stored
natively (absolutely zero work for application programmers to serialise
them) and byzantine synchronised processes update the majority of the
database replicates at once (and resync stale nodes), making is
impervious even to intentional attack. To complete your safety: there
is no administrative super user, aka root account, in the system which
could be abused to break in and destroy your valuable data. Instead
there's a nice way for any user to introduce and delegate new
capabilities guided by a rule (grounded in a simple set theoretic proof)
which assures you'll never lose control.
The approach of serialising/storing the continuation is sort of strange
however: I'm doing it on source level. Every transaction is responsible
to return a) the xml or binary data to be sent to the browser/client, b)
messages to be sent to other places and c) code+data of the
continuation. This might sound complicated but it is not that bad. Ask
the people at irc://irc.pitcom.net/#askemos (available usually during
central european working time) for experiences.
The application programming languages at the current stage of
development include an incomplete xslt extended by not exactly Scheme,
but a DSSSL style, pure functional subset of it plus some SRFI's, SXPath
and DSSSL style XML accessors. That's the prize we paid for the virtual
synchrony. (The source contains actually stubs to implement languages
with side effects, but nobody came around to do that yet.)
Other than that it's easy to do tricks like the modal web server on top
of it.
It's implemented mostly in R5RS, with a few things, mainly the
(optional, "pointer swizzling at page fault time") persistant store
depending on RScheme. There used to be a chicken port, which need some
work to get it working again.
/Jörg
Am Mittwoch, den 18.05.2005, 03:14 -0400 schrieb Michele Simionato:
> On 5/18/05, felix winkelmann <address@hidden> wrote:
> > On 5/16/05, Michele Simionato <address@hidden> wrote:
> > > Hi Felix, my subject says it all.
> > >
> > > In Chicken:
> > >
> > > 1. Can I serialize a function?
> > > 2. Can I serialize a closure?
> >
> > No. A function/procedure/closure contains a pointer to compiled
> > C code and is built at run-time. Serialization into a file and subsequent
> > de-serialization would have to modify the code-pointer to the proper
> > value. Depending on the loaded symbols and linked in libraries
> > the locations of the code may vary wildly.
> > One solution would be to compile a function-map into the code
> > and use these to convert code-pointers into some unique identifier
> > on serialization and do the reverse lookup on deserialization.
> >
> > Oh, if I just had more time...
>
> So it seems possible but technically difficult.
> Are there Scheme implementations that can serialize functions and closures?
>
> > > 3. Can I serialize a continuation?
> > >
> >
> > See above (a continuation is just a special closure). One remark:
> > continuation serialization, even thoughj it is currently quite
> > fashionable, is IMHO somewhat questionable: estimating the size of a
> > continuation
> > is hard, even for someone who knows the implementation well. In
> > the worst case you drag in the whole global environment.
>
> Yes, I was reading
>
> http://www.double.co.nz/scheme/modal-web-server.html
>
> which is interesting but stops at the point of serializing continuations,
> making the approach unpractical, I cannot keep everything in memory!
> BTW, do you know how people solve this? I think PLT has a modal
> server in its library (not sure, I should check).
>
> The modal web server seems to be the only usage of continuations
> I cannot emulate with other means (i.e. if my language has already
> generators and coroutines, why would I want continuations? there
> would be a real advantage if I could serialize continuations, but it
> seems difficult/unpractical).
>
> Michele Simionato
>
> P.S: BTW, I have added a recipe on the Chicken Wiki on how to implement
> Python generators for the Pythonistas in this list ;)
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
- [Chicken-users] serialization of functions, closures, continuations, Michele Simionato, 2005/05/17
- Re: [Chicken-users] serialization of functions, closures, continuations, felix winkelmann, 2005/05/18
- Re: [Chicken-users] serialization of functions, closures, continuations, Michele Simionato, 2005/05/18
- Re: [Chicken-users] serialization of functions, closures, continuations, felix winkelmann, 2005/05/18
- Re: [Chicken-users] serialization of functions, closures, continuations,
F. Wittenberger <=