[lisp-interface-library-devel] Fwd: Curating libraries

[Dan Lentz]

Begin forwarded message:

*From:* Dan Lentz <danlentz at gmail.com>
*Date:* October 31, 2012, 9:15:27 AM EDT
*To:* Faré <fahree at gmail.com>
*Subject:* *Re: Curating libraries*

Ok I've been rereading the LIL manifesto and its a lot clearer to me
this time around thanks to our discussion and the exercise of thinking
about a specific task, such as the rb/wb trees.   (probably the
repetition can't be hurting either :-)  So I'm jotting down a list of
general questions/thoughts etc that are not necessarily apropos of
anything we've been discussing and in no particular order.  I'll try
not to get too annoying with these, but here is one to start off:

One thought that popped up* was, "Gee, wouldn't <invertible> make a
good interface?"  Ie the inverse of insert is drop;  The inverse of
divide is join.  If we defined <invertible> with generics DO and UNDO
then we could do things like rollback a series of operations.  But
then I realized that insert/drop/divide/join etc are all functions not
interfaces.  So if not as an interface what would be the appropriate
means of doing this?

Generic functions could do it of course but then <invertible> would
not be a first class thing at least not in the sense of the other IPS
facilities.


* actually the rollback idea should be duly credited as result of
reading through billitch's transaction code in fact-database
----
Replace the method
the carefully chosen name
deletes the comment

On Oct 31, 2012, at 4:59 AM, "Faré" <fahree at gmail.com> wrote:

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/lisp-interface-library-devel/attachments/20121031/70c2d5b6/attachment.html>