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 edges?
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 >> >
