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