ANN: Durable Clojure - Functions and Closures

[Alyssa Kwan]

Extension of http://groups.google.com/group/clojure/browse_thread/thread/7c917e983f345723/a7ee771a7bcaaefc

Hi everyone!

I've extended the Clojure core to extend durability to functions and
closures.

1. Functions with lexical and dynamic bindings are now supported. This
includes functions that generate functions.
1.a. There is a slight overhead applied to all compiled functions; the
bytecode is inaccessible at runtime except through a cache which
maintains an entry for all classes regardless of whether they are
eventually persisted or not. This doubles memory required per class,
but should, in practice, be negligible.
2. Identities of identities are now supported. This means that
persistent data structures of identities can be saved, i.e. you can
have a ref of a hash-map of refs.
3. sorted-map and sorted-set are now supported.

Get it here: git://github.com/kwanalyssa/clojure.git

More testing, especially performance testing, is very welcome.
However, at this point, I've satisfied my own requirements. I'd love
to get this in scope eventually for enhancing Clojure core, if pain-
free persistence is part of the grand vision. Discussion of API and
implementation is also welcome.

Thanks!
Alyssa Kwan

[Mark]

Hi -

I'm surprised your work doesn't generate more interest from folks. I
wish I had more time, I would definitely jump in and help.

On Nov 24, 3:37 pm, Alyssa Kwan <alyssa.c.k...@gmail.com> wrote:
> Extension ofhttp://groups.google.com/group/clojure/browse_thread/thread/7c917e983...

[Ken Wesson]

On Sat, Nov 27, 2010 at 1:10 PM, Mark <markad...@gmail.com> wrote:
> Hi -
>
> I'm surprised your work doesn't generate more interest from folks.  I
> wish I had more time, I would definitely jump in and help.

Persistence doesn't seem to generate much interest in general. I
posted my own stab at a way of persisting the ref world
near-transparently a few weeks ago and it sank without a ripple.

[Alyssa Kwan]

Yes, but why isn't persistence of <em>closures</em> generating more
interest. ;)

Persistence is "solved", if you're OK with not being truly ACID...

Seriously though, everyone has their own backends. I don't think
anyone wants to be tied to BDB JE.

Would there be interest in lazy-loading and -unloading data
structures?

On Nov 27, 7:35 pm, Ken Wesson <kwess...@gmail.com> wrote:

[Ken Wesson]

On Mon, Dec 6, 2010 at 1:09 PM, Alyssa Kwan <alyssa...@gmail.com> wrote:
> Yes, but why isn't persistence of <em>closures</em> generating more
> interest.  ;)
>
> Persistence is "solved", if you're OK with not being truly ACID...
>
> Seriously though, everyone has their own backends.  I don't think
> anyone wants to be tied to BDB JE.
>
> Would there be interest in lazy-loading and -unloading data
> structures?

That code I wrote does sort of do lazy loading and unloading data
structures. That is, it can be used to make structures that are loaded
in pieces, on demand, as an algorithm reaches a particular piece, and
that can be referenced without loading them just from hanging onto the
thing's address somewhere.