[lisp-interface-library-devel] Curating libraries

[Faré]

> Why did you use association-pair as a base class rather than some type of
> box?   (re: your note in interface/tree)
Aha! Someone here is paying attention.

> 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.
>
Indeed. I had the same idea, but I was hoping to do it
with a payload mixin, rather than a payload box.
The idea was that eventually, we might want data structures
with a tree shape (or better, several tree shapes!)
but a different payload (either fewer or more slots).
I was hoping that my transformers could ultimately use
the same mixin approach rather than boxes to do their magic.
Database records could similarly be implemented
with one slot per column, plus a few slots per index, etc.
One idea I'd like to realize is that
if C can do it efficiently one way, so can we, except more cleanly.

> 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.
>
But doesn't locality and avoiding indirection favor putting all the data
in the same record using mixins rather than boxes?

> 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.
>
The mixin approach also does it.

> 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?
>
Actually, I'm hoping to come up with a scheme for automatic management
of data mixins from the interface class hierarchy.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Bragg's principle:
    Everything in the future is a wave, everything in the past is a particle.