Re: Did Lifeware Kill Scryer Prolog CLP(Z) ? (Was: A harsh wind is blowing into the face of Prolog now… [FORTRAN / TIOBE Index for May 2024])

Hi,
Whats then more disturbing, if you try picking subparts
of the parsing string, and integrate them in the
parse tree, i.e. your AST.
You then definitively lock the whole parsing source. But
the parsing source might be a couple of predicate
definitions, with constant arguments as found in Datalog:
foo(bar, baz) :- ....
...
The old school non sharing approach would be to have
an atom table and you have then deduplicated foo, bar,
baz, etc... in one place and the source doesn't get
locked. There is a also a new school, which I started
with Jekejeke Prolog and continued with Dogelog Player.
You don't share and you don't atom table.
If you don't use atom table, you might have copies
in your code of foo, bar, baz etc.. But this is only
a small factor, the used memory is still lower than
locking the whole source. And some Java versions have
string deduplication garbage collection under the hood now.
I am not sure what Python and JavaScript do.
But so far I think the small factor of extra memory
usage is not an issue.
Bye
Mild Shock schrieb:

Hi,
 But such a criteria is not satisfied in parsing,
especially if you use the more advanced last call
optimization and not only tail recursion optimization.
 As soon as parsing is deterministic, you can
leave behind the string part that you already parsed.
So you would need a special sharing that is kind of
 a weak sharing that can free some head part. There is
no such problem of freeing the head part, if you use
proper cons cell based lists for parsing.
 But naive substring sharing doesn't work for Prolog.
It will unnecessarely lock the whole string always.
Whereas a cell based parser can drop
 already parsed parts.
 Bye