[cells-devel] allegrocache

Ken Tilton kennytilton at optonline.net
Mon Dec 17 21:05:27 UTC 2007


rkm1000 wrote:
> I've spent more time with this. I believe it is worse than I first  
> imagined. Allegrocache helps ensure "in memory" object uniqueness for  
> classes of persistent-class.  But not for (at least some) non  
> persistent objects reachable from persistent objects (does that make  
> sense?). 

If you mean because not all slots of persistent-objects are persistent, 
sure.

> What Allegrocache does for graphs of CLOS objects, it does  not 
> do for graphs of structs; there is more to it than just  serialization. 
> If you naively encode and decode a cell struct when  called upon by 
> Allegrocache, you will wind up with several copies of  the cell. To add 
> the logic to track the loading of cell structs, and  load the model 
> objects that own the cell structs would require  reinventing some 
> (much?) of what Allegrocache already does for CLOS.  BTW, I hope I'm 
> wrong about this... I can provide more details if  anyone is interested.

This sounds OK. You /will/ have to create a solid layer of glue to make 
this work, and this just sounds like some of that. Of course I came to 
the task (with AStore) already sold on the enormous benefits that would 
follow from the effort, so I never worried about how much glue I was 
creating, I just worried about it being solid, ie, not going out of 
bounds of supported Astore.

> 
>  >This is pretty scary, two hours earlier I got invited to talk at ILC  
> 2008 and thought I would do RDFCells.
> Cool. I'd like to see RDFCells.
> 
> I can't quite see the big picture yet; meaning I'm not sure what I  will 
> miss from CLOS by embracing RDF, but it looks intriguing. How far  down 
> the road can you see at this point?

I want to present triple-cells (new name) at ECLM 2008 and I am taking a 
couple of days now to do a simple feasibility check before committing to 
that topic for the announcment, try me in a few.

I did a little work with AG and felt quite liberated in A Lisp Way 
compared with ACache, and my next conclusion was that maybe CLOS (and 
conventional OO) is not True Lisp. I am catching up with Graham and 
Gabriel on this, I think. Even before my AG work I had noticed that with 
Cells I do not need to subclass, and I have also noticed I do not use 
multiple dispatch all that much -- are types really at the heart of my 
design? I find myself thinking I should look at prototyping OO models, 
such as in Garnet.

It is all fuzzy now and there is a good chance I will not have done any 
serious application work with triple-cells by April when I go to ECLM, 
cuz I need to get my commercial app out the door and this is no time for 
a massive rewrite. So it might be a while before I know if I am nuts.

> Does RDFCells look more or  less 
> complex than Cells?

Not sure what you mean. triple-cells will sit on top of cells and AG to 
give AG triples the functionality of Cells. It is the same glue you are 
trying with AC. So it is really a different kind of project. Oh, wait. 
Do you mean from the user perspective? Well, of course we want these 
things to be as painless as possible at the user level, and macros god 
bless them usually let us do that. I may well end up with the same 
problem you are confronting, but I'll just hack through it, as you say 
doing my own cache management to deal with surprises. But on the user 
side I just see different API entry points for triples, so C? might 
become 3C?. Stuff like that.

cheers, ken



More information about the cells-devel mailing list