<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br></div><div>Begin forwarded message:<br><br></div><blockquote type="cite"><div><b>From:</b> Dan Lentz <<a href="mailto:danlentz@gmail.com">danlentz@gmail.com</a>><br>
<b>Date:</b> October 31, 2012, 9:15:27 AM EDT<br><b>To:</b> Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>><br><b>Subject:</b> <b>Re: Curating libraries</b><br><br></div></blockquote><blockquote type="cite">
<div><span>Ok I've been rereading the LIL manifesto and its a lot clearer to me</span><br><span>this time around thanks to our discussion and the exercise of thinking</span><br><span>about a specific task, such as the rb/wb trees. (probably the</span><br>
<span>repetition can't be hurting either :-) So I'm jotting down a list of</span><br><span>general questions/thoughts etc that are not necessarily apropos of</span><br><span>anything we've been discussing and in no particular order. I'll try</span><br>
<span>not to get too annoying with these, but here is one to start off:</span><br><span></span><br><span>One thought that popped up* was, "Gee, wouldn't <invertible> make a</span><br><span>good interface?" Ie the inverse of insert is drop; The inverse of</span><br>
<span>divide is join. If we defined <invertible> with generics DO and UNDO</span><br><span>then we could do things like rollback a series of operations. But</span><br><span>then I realized that insert/drop/divide/join etc are all functions not</span><br>
<span>interfaces. So if not as an interface what would be the appropriate</span><br><span>means of doing this?</span><br><span></span><br><span>Generic functions could do it of course but then <invertible> would</span><br>
<span>not be a first class thing at least not in the sense of the other IPS</span><br><span>facilities.</span><br><span></span><br><span></span><br><span>* actually the rollback idea should be duly credited as result of</span><br>
<span>reading through billitch's transaction code in fact-database</span><br><span>----</span><br><span>Replace the method</span><br><span>the carefully chosen name</span><br><span>deletes the comment</span><br><span></span><br>
<span>On Oct 31, 2012, at 4:59 AM, "Faré" <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Why did you use association-pair as a base class rather than some type of</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>box? (re: your note in interface/tree)</span><br></blockquote></blockquote><blockquote type="cite"><span>Aha! Someone here is paying attention.</span><br>
</blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>The reason I ask is that in my</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>code I currently also have both key and value slots hard wired and I think I</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>preferred my previous approach which amounted to a single "payload" slot in</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the node which would contain (the equivalent of) a single-value-box for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>sets, an association-pair box for maps, and a specialized kind of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>association pair box for seqs.</span><br></blockquote></blockquote>
<blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>Indeed. I had the same idea, but I was hoping to do it</span><br></blockquote><blockquote type="cite">
<span>with a payload mixin, rather than a payload box.</span><br></blockquote><blockquote type="cite"><span>The idea was that eventually, we might want data structures</span><br></blockquote><blockquote type="cite"><span>with a tree shape (or better, several tree shapes!)</span><br>
</blockquote><blockquote type="cite"><span>but a different payload (either fewer or more slots).</span><br></blockquote><blockquote type="cite"><span>I was hoping that my transformers could ultimately use</span><br></blockquote>
<blockquote type="cite"><span>the same mixin approach rather than boxes to do their magic.</span><br></blockquote><blockquote type="cite"><span>Database records could similarly be implemented</span><br></blockquote><blockquote type="cite">
<span>with one slot per column, plus a few slots per index, etc.</span><br></blockquote><blockquote type="cite"><span>One idea I'd like to realize is that</span><br></blockquote><blockquote type="cite"><span>if C can do it efficiently one way, so can we, except more cleanly.</span><br>
</blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>One reason this seems to be a better way is</span><br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite"><span>that when implementing persistence (as in on disk) the key and or value tend</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>to be serialized lisp objects ie octet vectors of some length. Keeping them</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>together in a single object makes it much simpler when manually allocating</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>storage. Thus nodes will be of a fixed allocation size (containing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>essentially 4 pointers : payload left right height -- typically each being</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>a fixnum offset into a file stream, mmap index, or heap address) Also when</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>creating new nodes in the pure interface, one does not have to duplicate the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>long serialized key/value data (if it were to be physically stored in the</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>node) or, more likely, deal with separate allocation and pointers to the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>serialized data of key and value slots. In the non persistent case things</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>work as normal of course.</span><br></blockquote>
</blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>But doesn't locality and avoiding indirection favor putting all the data</span><br>
</blockquote><blockquote type="cite"><span>in the same record using mixins rather than boxes?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Another benefit, possibly less (or not) important under IPS was that</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This leaves the underlying tree node as the same class regardless of the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>type of collection, set map or seq, and one can distinguish the type of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>collection by simple examination of any tree node just by looking at the</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>class of its payload box.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote>
<blockquote type="cite"><span>The mixin approach also does it.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>I can work either way of course, and like I said wb and rb currently also</span><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>use quintuple nodes (kvlrh) but I've thought once or twice that given the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<span>opportunity I'd change back to my previous approach using quad nodes (plrh).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite"><span>Thoughts?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>Actually, I'm hoping to come up with a scheme for automatic management</span><br>
</blockquote><blockquote type="cite"><span>of data mixins from the interface class hierarchy.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org">http://fare.tunes.org</a></span><br>
</blockquote><blockquote type="cite"><span>Bragg's principle:</span><br></blockquote><blockquote type="cite"><span> Everything in the future is a wave, everything in the past is a particle.</span><br></blockquote></div>
</blockquote></body></html>