[vivace-graph-devel] nodes, fixnums/upper bounds, and multi-constituent indices

[Dan Lentz]

> > Another topic I have been looking at related to the indexing and
> > uuid's is the representation (reification?) of nodes, or lack
> > thereof.
> >
> > One difference in vivace graph versus other tstores I've played with
> > is the ability to reference nodes as first class "things".
>
> Maybe because they resolve to first class Lisp objects and don't
> resort to mediating the inferior objects spat out by lesser non-lispy
> sources :)
>
> No doubt this will eventually change once the VG2
> transaction/persistence/indexing stuff is better established
> (hopefully sooner than later).
>
>

Ok, actually i worked out a pleasant node/namespace/package/symbol mapping
automation last evening last night based on the "graph-words" which i'm
using as the canonical node representation with lambdas (fdefinitions) and
symbol-values to dereference and map back and forth.  It's simply
housekeeping but it's convenient, even more-so than the "bang reader" macro,
so if there is any interest i'd be happy to post a more thorough description
or code snippet.

I like the graph-words convention and looked a little bit into combining the
above with ContextL, which i believe could be used to nice effect in order
to provide a conveniently namespace-aware symbol mapping like the above, but
with symbols mapped based on dynamic context established with something like
a "with-graphs" macro.  ContextL is pretty fast at switching between these
dynamic symbol mappings, although (important note) the packages (namespaces)
themselves are static.  The "contents" (symbols) are dynamic.


> >part 2
> >
> > This sort of blends into another indexing-model question, related to
> > the current model which is based on a hierarchical index structure?
> > Couldn't additional speed be achieved though multi-constituent
> > indexing?  IE and SP index, PO, index etc in which multiple nodes of
> > a single triple are hashed in the aggregate to allow for direct
> > lookup.
>
> Having spent some more time looking at the linear-hashing papers Kevin
> provided I'm have trouble see this as an either/or situation,
> e.g. underneath its all gonna eventually wind-up as hash-tables
> arrays, integers and de-referenced bucket/node/leaf/offset pointers :)
>
> I'm interested to learn from Kevin how much of the linear-hashing
> scheme he believes is already "built-in" to the existing VG-2
> code-base.
>
> In particular, if most of the footwork for the linear-hashing work is
> already in place?
>
> And, if not whether there is some drop-in data-structure capable of
> implementing the linear-hashing scheme he envisions.
>
> And, if not what does he anticipate is required to implement a
> functional linear-hashing scheme as he envisions.
>
>
So, in effect, multi-constituent indexing should be easy to tack on later
down the road?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/vivace-graph-devel/attachments/20110915/b9e41a2c/attachment.html>