I'm afraid at my level of CS theory I don't really know what is meant by a
picolisp atom being persistent, much less across distributed picolisp
instances. Could someone give me a concrete example of what you describe
as: "Any named bag of items automatically represents a (directed,
undirected) graph. The name then is the node, the items in the bag then
there represent the edges." I do understand the tree structure of a lisp
program. But that doesn't make it a graph database. When I tried to fathom
the Picolisp "graph database" example, I was quickly confused. The GUI
actually added confusion, AFAIC. I'm guessing from what I could
ausknobeln from example that the Picolisp version of a CLOS object is a
vertex, and the inheritance of that object from other (higher, more
general?) objects is a sort of edge. Correct me if I'm wrong. But then
there was talk of "records." Is creating a record the same as creating an
object instance -- and this record/object is a vertex? Where, what are the

Don't get me wrong, I have long felt that Lisp -- with its parsing actually
visible in the code you write -- is or could be very graphDB-friendly;
however, Lisp is functional, i.e., you write functions. And even though
they are set up as a graph-like tree in nested lists form, they are not in
themselves data in the traditional sense, rather, code meant to take you
from a domain/input to a range/result. This is not a "record" (or graph
vertex?) creation/query/deletion paradigm.

But this relates to a long-standing question I've had about software
libraries. As it stands, they may be auto-indexed for our viewing pleasure,
but they aren't in any real database form so that you might simply have
your program "query-and-plug-in" a library. (Although I've heard Haskell's
hlint almost writes your code for you!) No, you have to find the module,
plug it in yourself. The whole "code is data", therefore, doesn't seem to
get past the higher-order function trick of passing in a function as an
argument. What more is there to "code is data?" In Fortran the data was in
fact parked just below the code.

At some point I'm just scared and rambling on....

On Wed, Mar 25, 2020 at 7:12 AM Guido Stepken <gstep...@gmail.com> wrote:

> Lawrence, you haven't yet understood, that any Lisp, by default, is it's
> own Graph Database. Especially Picolisp, where Alex has made any Picolisp
> Atom persistent and even distributed across other Picolisp instances. 'Data
> is code, code is data'.
> Any named bag of items automatically represents a (directed, undirected)
> graph. The name then is the node, the items in the bag then there represent
> the edges. Even Picolisp sources you can consider a (directed) graph, often
> also called 'syntax tree'.
> If you like, you can put, group all "edges" with same properties into a
> new, searchable bag of edges for fast lookup. Since it's all lazy evaluated
> (even the persistent nodes), as Alex already pointed out, it's still ultra
> fast. And since in Picolisp everything can be persisted distributed,
> Picolisp automatically represents a distributed graph database (with
> sharding and everything) which you can build, implement on your own with
> just a few lines of code. It's a no-brainer!
> Picolisp is a genius strike, but most people can't see the forest for all
> the trees.
> Have fun!
> Regards, Guido Stepken
> P.S. Keep away from Windows and other viruses!
> Am Donnerstag, 12. März 2020 schrieb Lawrence Bottorff <borg...@gmail.com
> >:
>> I take it the picolisp graph database follows more the Neo4j property
>> graph idea than any RDF/OWL triples, correct? That seems obvious, but I
>> thought I'd check. I haven't dived in deep, buy you seem to use Lisp
>> objects to create a vertex. But then what are the edges? Again, I'm just
>> getting started.
>> LB
>> Grand Marais, MN, Oberer See

Reply via email to