Have you already looked at the family example? Here is my brief overview of ascending order of abstractedness: PicoLisp had no graph database. What is has is this: - The ability to serialize/de-serialize all structures in the heap (Lists, numbers, functions, symbols etc) - It has the ability to fetch and deserialize structures when they are accessed by their reference (also called external symbol) and also GC the loaded content when it is no longer accessable - the ability to make atomic changes to such structures (by write locking the database). - it has relations which allow the database to place pointers in one or multiple directions, make space for indexes etc... (I have not fully grasped that myself) - The are indexes which automatically maintained and those are accessible to the database allowing you to discover objects placed in the database. - It has an mechanism which allows you to maintain database consistent of different machines (replication)
In PicoLisp you can solve many graph database problems with those structures, however PicoLisp does not care or know what a vertex is. It does not come support for weighted vertexes, you could build your own class but is usually more efficient to just implement what you actually need, not implement some paradigm because you heard of it/like it. Tailor PicoLisp to your problem, not your paradigm. This is a thing i had to learn over a long time. On Wed, 25 Mar 2020 at 21:46, Lawrence Bottorff <borg...@gmail.com> wrote: > > 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 -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
