[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] environment egg - any replacement?

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] environment egg - any replacement?
Date: 13 Sep 2011 14:57:33 +0200

On Sep 12 2011, Felix wrote:

There will be a replacement, but it will need some modifications
in the evaluator. Do you evaluate a lot of code, are the environments
long- or short-lived and small or large? Do you reuse them or create
many environments on the fly?

Good questions, the answer is: it depends.  On cond-expand'ed code sections.

At minimum I could live without manipulating environments at all,
but this would need some changes to the code, where I do so far have
no alternative path.

At maximum - including some ideas, which so far are only prepared to
be done at a time - I would have:
- a few environments prepared upon start and living all day long
 those would be read-only
- some environments on the fly, which would contain several hundred
 bindings (say Scheme plus some SRFIs) those would be cached to live
 longer, r/o too
- a few hundred environments created on the fly containing only about
 5-20 bindings.  Subject to transactions (r/w).

At this time those different use cases are all implemented by simple
domain specific evaluators.  Even the case which broke for me is at
this time handled by it's own evaluator.  The idea however would
be to generalize my whole code base.

The thing is Askemos is basically yet another Scheme interpreter.
But with a difference: it runs one interpreter per object it handles
(sandboxed so to say), those objects can talk to each other using
asynchronous messages (like in Erlang or termite, just in contrast
to termite there is - for the sake of security - no way to break out
of the scheme), object can be replicated on several hosts - in this
case there is no master copy but a majority decision among the copies
on each update, eventually there is a small Scheme alike language to
update the graph of known objects (equivalent to let, let*, begin
and set! only).
(In fact it's slightly more: the most basic objects are readily
usable as nodes in a file system tree.  So file systems are simple
to implement.  And quite a lot of work has been put into running
sqlite in it's own posix thread using the virtual file system feature
from sqlite to feed it's blocks into the replicated file system.
BTW: does anybody know a second SQL data base which has peer-to-peer
replication (sans master copy)?)

I could imagine to simplify/unify a lot of the code - once it runs
on a not-so-dead compiler as rscheme is by now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]