Re: persistent data feature

[Ihor Radchenko]

Qiantan Hong <qhong@mit.edu> writes:

>> Doesn’t elisp’s printer detects cycles and print #0, #1, etc. where 
>> needed?
> I think there’s some confusion here.
>
> My first “incremental” has a specific meaning in “incremental image”,
> it means dumping part of the Lisp heap, compared to “full image”
> which dump the whole heap. `prin1` can be viewed as a trivial
> implementation of this, but usually this is done much more efficiently
> by dumping out the memory representation directly.

Thanks for the clarification!

> I believe the “incremental” Ihor means is to store incremental changes
> to a data structure/object graph, as what I did in resist!.el for hash
> tables. This is indeed hard to do in general. Either we need to
> modify the Elisp VM to add hook that detect changes, or we
> need to do graph edit distance algorithm on different snapshots
> of objects. It probably doesn’t worth the effort.
>
> As what Ihor (I suppose) had in mind is incremental log operation,
> prin1 is unrelated to this context because it prints out the whole object 
> graph.

Yep. You are right. I was thinking about your resist!.el and also about
textual representation of sqlite databases.

Also, I had several cases when prin1 is not accurate on large circular
objects generating un_read_able output or entering recursion deeper
than max-specpdl-size. Incremental logging could be easier in this
context.

Best,
Ihor