[lisp-interface-library-devel] Curating libraries

[Dan Lentz]

I am still digesting everything you said in your previous message, but on
an unrelated topic...

Why did you use association-pair as a base class rather than some type of
box?   (re: your note in interface/tree)  The reason I ask is that in my
code I currently also have both key and value slots hard wired and I think
I preferred my previous approach which amounted to a single "payload" slot
in the node which would contain (the equivalent of) a single-value-box for
sets, an association-pair box for maps, and a specialized kind of
association pair box for seqs.  One  reason this seems to be a better way
is that when implementing persistence (as in on disk) the key and or value
tend to be serialized lisp objects ie octet vectors of some length.
 Keeping them together in a single object makes it much simpler when
manually allocating storage.  Thus nodes will be of a fixed allocation size
(containing essentially 4 pointers :  payload left right height --
typically each being a fixnum offset into a file stream,  mmap index, or
heap address)  Also when creating new nodes in the pure interface, one does
not have to duplicate the long serialized key/value data (if it were to be
physically stored in the node) or, more likely, deal with separate
allocation and pointers to the serialized data of key and value slots.   In
the non persistent case things work as normal of course.

Another benefit, possibly less (or not) important under IPS was that
This leaves the underlying tree node as the same class regardless of the
type of collection, set map or seq, and one can distinguish the type of
collection by simple examination of any tree node just by looking at the
class of its payload box.

I can work either way of course, and like I said wb and rb currently also
use quintuple nodes (kvlrh) but I've thought once or twice that given the
opportunity I'd change back to my previous approach using quad nodes
(plrh).

Thoughts?



On Wednesday, October 31, 2012, Faré wrote:

> > My "box" was implemented as a CSTM transactional-class with one slot:
> VALUE.
> > I used this as a container for the root node of a pure functional tree to
> > effect a transactionally mutable variant of that structure.  A
> transaction
> > would be to replace the root node in this box with the root node of the
> > updated tree on commit.
> >
> That would be a nice thing to add to interface/box.lisp
> and to use with the define-mutating-interface macro
> to automatically deduce shared-mutable objects
> from pure interfaces.
>
> > I forked LIL and placed some sources taken from my wb and rb trees into
> > contrib if you're interested to take a look at where I'm starting from.
> > It's the majority of the core treeish stuff but pruned to the basic
> > routines.   Naturally it is just for reference and doesn't compile in
> this
> > state.
> >
> Forking is fine. I'd rather the work be committed to master
> in steps that don't involve breaking the workingness of the system
> (i.e. compiles and passes tests) or importing non-working files
> (there are a few in funds/ already).
>
> But I prefer working code to non-working code,
> even if there is some ugly commit history.
>
> > The implementation is mostly based on Adams purely functional data
> > structures, plus a couple other papers mentioned in the weight balanced
> > file.  One good thing is that it seems like it should be straightforward
> to
> > translate my use of layers into interfaces, at least at the moment.
> >
> Any link to Adams?
> We should probably maintain a bibliography somewhere.
>
> > I see the AVL trees do "post-balanced" where balancing occurs in the
> > stateful interface-- is that correct and is that technique something I
> > should try to replicate?
> >
> For stateful trees, I believe this works great.
> For pure trees, I have so far overridden the node method.
> I'm wondering if state-passing :post and :pre method combinators
> wouldn't be better instead.
> And of course I eventually want both pure & stateful
> from a single linear logic specification.
>
> > It would be nice if my binary trees conformed with
> > your AVL as much as possible I think but on the other hand maybe there is
> > some value in the Adams approach?
>
> > OTOH your way results in a truly mutable
> > structure in stateful, where my approach was just to have a mutable "box"
> > containing the current root node.
> >
> IIUC, that approach is what my "mutating" macro gives you automatically
> from a pure interface.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> To most Christians, the Bible is like a software license. Nobody
> actually reads it. They just scroll to the bottom and click "I agree."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/89dfb2bb/attachment.html>