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,
The factor is smaller if the source has anyway a
diversity of strings. If the source has a lot of
redundant strings the factor is higher. You
can explore Prolog compilation techniques that further
deduplicate, but these compilation technqiques are
best appplied by a more broader view, i.e. sharing
numbers and compounds as well. Only looking at strings
is possibly not worth the effort. But if you
cross compile you don't have to do anything anyway.
If I cross compile Dogelog Player to Java, the
Jave byte code class format has a constant pools, so
the Java compiler does the deduplication of strings for you.
A cross compiled Datalog with a lot of foo, bar, baz, ..-
foo(bar, baz) :- ....
...
Will have a compilation output that uses a constant pool,
and the strings in itself foo, bar, baz, etc.. will
be shared. So the factor is again very low for
cross compiled artefacts. Not sure what Python and JavaScript
do, they might do a constant pooling as well. The constant
pooling is very known for Java byte code class format the
output of Java compilers, it was already there in the beginning.
Bye
Mild Shock schrieb:

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