Thank you beneroth and Joh-Tob for this impressive and insightful explanation, very informative for me as well, thank you, I will put this on my PicoLisp notes.
On Thu, Mar 26, 2020 at 8:29 AM Joh-Tob Schäg <johtob...@gmail.com> wrote: > 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?subjectUnsubscribe > >
