I am in the preparation phase of a module system for
the Dogelog Runtime. It will implement some ideas of
LeanTalk. Some of these ideas are already realized in

Jekejeke Prolog. But Jekejeke Prolog suffers from
the use of (:)/2 and (::)/2. The operator (:)/2 is in collision
with the Prolog dicts. So the module system should

not make use of the operator (:)/2. We need to find
a new operator. Suggestion is to use the operator (.)/2
and a preliminarly named operator '$MOD'/2.

'$MOD'/2, which might be renamed later, is only for
input/output. It should show the module context that
is lexically assigned to the atoms during reading of

atoms. Jekejeke Prolog cannot yet input/output '$MOD'/2,
there is only a read/write option source. Dogelog Runtime
will have the same read/write option source, but additionally

support '$MOD'/2.

Lets make an example what is meant by lexically assigned
module context. Its the same idea like Scheme lexical scoping.
It is defined as follows:

3.4.4 Lexical Scope

The rules that we have just been describing are the details of how
Scheme implements “lexical scoping”. This subsection takes a brief
diversion to explain what lexical scope means in general and to
present an example of non-lexical scoping.

“Lexical scope” in general is the idea that

- an identifier at a particular place in a program always refers to
the same variable location — where “always” means “every time
that the containing expression is executed”, and that

- the variable location to which it refers can be determined by
static examination of the source code context in which that
identifier appears, without having to consider the flow of
execution through the program as a whole.

https://www.gnu.org/software/guile/manual/html_node/Lexical-Scope.html

Concerning Lexical Scoping and Module System:
- SWI-Prolog doesn't implement lexical scoping by default.
- Jekejeke Prolog implements lexical scoping by default.

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:53:13 UTC+2:
> I am in the preparation phase of a module system for
> the Dogelog Runtime. It will implement some ideas of
> LeanTalk. Some of these ideas are already realized in
>
> Jekejeke Prolog. But Jekejeke Prolog suffers from
> the use of (:)/2 and (::)/2. The operator (:)/2 is in collision
> with the Prolog dicts. So the module system should
>
> not make use of the operator (:)/2. We need to find
> a new operator. Suggestion is to use the operator (.)/2
> and a preliminarly named operator '$MOD'/2.
>
> '$MOD'/2, which might be renamed later, is only for
> input/output. It should show the module context that
> is lexically assigned to the atoms during reading of
>
> atoms. Jekejeke Prolog cannot yet input/output '$MOD'/2,
> there is only a read/write option source. Dogelog Runtime
> will have the same read/write option source, but additionally
>
> support '$MOD'/2.

Here is a test case that shows that SWI-Prolog doesn't know
lexical scoping, whereas Jekejeke Prolog implements lexical
scoping. The test case executed in SWI-Prolog and Jekejeke Prolog:

SWI-Prolog No Lexical Scoping:

?- module(foo).
foo: ?- [user].
test(X) :- X =.. [test2].
test2 :- write('Hello World!'), nl.
^D
foo: ?- test(X), X.
Hello World!
foo: ?- module(user).
?- foo:test(X), X.
ERROR: Unknown procedure: test2/0

Jekejeke Prolog Lexical Scoping:

?- begin_module(foo).
(foo) ?- [user].
test(X) :- X =.. [test2].
test2 :- write('Hello World!'), nl.
^D
(foo) ?- test(X), X.
Hello World!
(foo) ?- end_module.
?- foo:test(X), X.
Hello World!

See the difference?

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:56:37 UTC+2:
> Lets make an example what is meant by lexically assigned
> module context. Its the same idea like Scheme lexical scoping.
> It is defined as follows:
>
> 3.4.4 Lexical Scope
>
> The rules that we have just been describing are the details of how
> Scheme implements “lexical scoping”. This subsection takes a brief
> diversion to explain what lexical scope means in general and to
> present an example of non-lexical scoping.
>
> “Lexical scope” in general is the idea that
>
> - an identifier at a particular place in a program always refers to
> the same variable location — where “always” means “every time
> that the containing expression is executed”, and that
>
> - the variable location to which it refers can be determined by
> static examination of the source code context in which that
> identifier appears, without having to consider the flow of
> execution through the program as a whole.
>
> https://www.gnu.org/software/guile/manual/html_node/Lexical-Scope.html
>
> Concerning Lexical Scoping and Module System:
> - SWI-Prolog doesn't implement lexical scoping by default.
> - Jekejeke Prolog implements lexical scoping by default.
> Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:53:13 UTC+2:
> > I am in the preparation phase of a module system for
> > the Dogelog Runtime. It will implement some ideas of
> > LeanTalk. Some of these ideas are already realized in
> >
> > Jekejeke Prolog. But Jekejeke Prolog suffers from
> > the use of (:)/2 and (::)/2. The operator (:)/2 is in collision
> > with the Prolog dicts. So the module system should
> >
> > not make use of the operator (:)/2. We need to find
> > a new operator. Suggestion is to use the operator (.)/2
> > and a preliminarly named operator '$MOD'/2.
> >
> > '$MOD'/2, which might be renamed later, is only for
> > input/output. It should show the module context that
> > is lexically assigned to the atoms during reading of
> >
> > atoms. Jekejeke Prolog cannot yet input/output '$MOD'/2,
> > there is only a read/write option source. Dogelog Runtime
> > will have the same read/write option source, but additionally
> >
> > support '$MOD'/2.

So what will be different in Dogelog Runtime? After Jekejeke
Prolog has already lexical scoping, how will the Dogelog Runtime
differ? One change is to use the operator '.'/2 in place of (:)/2

and introduce the operator '$MOD'/2. Lets look at the last
query in Jekejeke Prolog, and project into the future how this
last query should work out in the Dogelog Runtime.

Currently in Jekejeke Prolog:

?- foo:test(X), X. %%% the operator (:)/2 is used, conflict with Dicts
Hello World!
X = test2 %%% no indication of lexical scope

Projected for Dogelog Runtime:

?- foo.test(X), X. %%% the operator ('.')/2 should be used
Hello World!
X = '$MOD'(foo,test2) %%% indicates the lexical scope of test2

We would like to use the shorter (:)/2 for '$MOD'/2, but if
we ban (:)/2 because of conflict with Dicts, we can
also not use it for what '$MOD'/2 will do.

'$MOD'/2 is only present in input/output. But internally
it disappears. Unlike ('.')/2 it cannot be used to change
the lexical scope. The lexical scope is attached to

the atoms, and '$MOD'/2 can show the first atom that
changes the lexical scope. A written term might have
multiple '$MOD'/2 for every lexical scope change.

More readable would be some infix operator, but so many
operators have meaning in other Prolog systems, so
we will first work with '$MOD'/2 and maybe find a short

operator and replace it later.

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 23:00:47 UTC+2:
> Here is a test case that shows that SWI-Prolog doesn't know
> lexical scoping, whereas Jekejeke Prolog implements lexical
> scoping. The test case executed in SWI-Prolog and Jekejeke Prolog:
>
> SWI-Prolog No Lexical Scoping:
>
> ?- module(foo).
> foo: ?- [user].
> test(X) :- X =.. [test2].
> test2 :- write('Hello World!'), nl.
> ^D
> foo: ?- test(X), X.
> Hello World!
> foo: ?- module(user).
> ?- foo:test(X), X.
> ERROR: Unknown procedure: test2/0
>
> Jekejeke Prolog Lexical Scoping:
>
> ?- begin_module(foo).
> (foo) ?- [user].
> test(X) :- X =.. [test2].
> test2 :- write('Hello World!'), nl.
> ^D
> (foo) ?- test(X), X.
> Hello World!
> (foo) ?- end_module.
> ?- foo:test(X), X.
> Hello World!
>
> See the difference?
> Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:56:37 UTC+2:
> > Lets make an example what is meant by lexically assigned
> > module context. Its the same idea like Scheme lexical scoping.
> > It is defined as follows:
> >
> > 3.4.4 Lexical Scope
> >
> > The rules that we have just been describing are the details of how
> > Scheme implements “lexical scoping”. This subsection takes a brief
> > diversion to explain what lexical scope means in general and to
> > present an example of non-lexical scoping.
> >
> > “Lexical scope” in general is the idea that
> >
> > - an identifier at a particular place in a program always refers to
> > the same variable location — where “always” means “every time
> > that the containing expression is executed”, and that
> >
> > - the variable location to which it refers can be determined by
> > static examination of the source code context in which that
> > identifier appears, without having to consider the flow of
> > execution through the program as a whole.
> >
> > https://www.gnu.org/software/guile/manual/html_node/Lexical-Scope.html
> >
> > Concerning Lexical Scoping and Module System:
> > - SWI-Prolog doesn't implement lexical scoping by default.
> > - Jekejeke Prolog implements lexical scoping by default.
> > Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:53:13 UTC+2:
> > > I am in the preparation phase of a module system for
> > > the Dogelog Runtime. It will implement some ideas of
> > > LeanTalk. Some of these ideas are already realized in
> > >
> > > Jekejeke Prolog. But Jekejeke Prolog suffers from
> > > the use of (:)/2 and (::)/2. The operator (:)/2 is in collision
> > > with the Prolog dicts. So the module system should
> > >
> > > not make use of the operator (:)/2. We need to find
> > > a new operator. Suggestion is to use the operator (.)/2
> > > and a preliminarly named operator '$MOD'/2.
> > >
> > > '$MOD'/2, which might be renamed later, is only for
> > > input/output. It should show the module context that
> > > is lexically assigned to the atoms during reading of
> > >
> > > atoms. Jekejeke Prolog cannot yet input/output '$MOD'/2,
> > > there is only a read/write option source. Dogelog Runtime
> > > will have the same read/write option source, but additionally
> > >
> > > support '$MOD'/2.

Posted the example on SWI-Prolog discourse. Mostlikely
I will get censored again? Who knows. I didn't mention
Logtalk nonsense. Mostlikely Logtalk nonsense has no
clue about lexical scoping. Well I am rediscovering it.

Its quite contrived in Jekejeke Prolog, and evolved without
looking at Scheme etc.. But now it appears again in the
targets of Dogelog, namely JavaScript and Python. Maybe
sticking to lexical scoping could be therefore

a good idea. Not yet sure. Will see.

Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 23:09:30 UTC+2:
> So what will be different in Dogelog Runtime? After Jekejeke
> Prolog has already lexical scoping, how will the Dogelog Runtime
> differ? One change is to use the operator '.'/2 in place of (:)/2
>
> and introduce the operator '$MOD'/2. Lets look at the last
> query in Jekejeke Prolog, and project into the future how this
> last query should work out in the Dogelog Runtime.
>
> Currently in Jekejeke Prolog:
>
> ?- foo:test(X), X. %%% the operator (:)/2 is used, conflict with Dicts
> Hello World!
> X = test2 %%% no indication of lexical scope
>
> Projected for Dogelog Runtime:
>
> ?- foo.test(X), X. %%% the operator ('.')/2 should be used
> Hello World!
> X = '$MOD'(foo,test2) %%% indicates the lexical scope of test2
>
> We would like to use the shorter (:)/2 for '$MOD'/2, but if
> we ban (:)/2 because of conflict with Dicts, we can
> also not use it for what '$MOD'/2 will do.
>
> '$MOD'/2 is only present in input/output. But internally
> it disappears. Unlike ('.')/2 it cannot be used to change
> the lexical scope. The lexical scope is attached to
>
> the atoms, and '$MOD'/2 can show the first atom that
> changes the lexical scope. A written term might have
> multiple '$MOD'/2 for every lexical scope change.
>
> More readable would be some infix operator, but so many
> operators have meaning in other Prolog systems, so
> we will first work with '$MOD'/2 and maybe find a short
>
> operator and replace it later.
> Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 23:00:47 UTC+2:
> > Here is a test case that shows that SWI-Prolog doesn't know
> > lexical scoping, whereas Jekejeke Prolog implements lexical
> > scoping. The test case executed in SWI-Prolog and Jekejeke Prolog:
> >
> > SWI-Prolog No Lexical Scoping:
> >
> > ?- module(foo).
> > foo: ?- [user].
> > test(X) :- X =.. [test2].
> > test2 :- write('Hello World!'), nl.
> > ^D
> > foo: ?- test(X), X.
> > Hello World!
> > foo: ?- module(user).
> > ?- foo:test(X), X.
> > ERROR: Unknown procedure: test2/0
> >
> > Jekejeke Prolog Lexical Scoping:
> >
> > ?- begin_module(foo).
> > (foo) ?- [user].
> > test(X) :- X =.. [test2].
> > test2 :- write('Hello World!'), nl.
> > ^D
> > (foo) ?- test(X), X.
> > Hello World!
> > (foo) ?- end_module.
> > ?- foo:test(X), X.
> > Hello World!
> >
> > See the difference?
> > Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:56:37 UTC+2:
> > > Lets make an example what is meant by lexically assigned
> > > module context. Its the same idea like Scheme lexical scoping.
> > > It is defined as follows:
> > >
> > > 3.4.4 Lexical Scope
> > >
> > > The rules that we have just been describing are the details of how
> > > Scheme implements “lexical scoping”. This subsection takes a brief
> > > diversion to explain what lexical scope means in general and to
> > > present an example of non-lexical scoping.
> > >
> > > “Lexical scope” in general is the idea that
> > >
> > > - an identifier at a particular place in a program always refers to
> > > the same variable location — where “always” means “every time
> > > that the containing expression is executed”, and that
> > >
> > > - the variable location to which it refers can be determined by
> > > static examination of the source code context in which that
> > > identifier appears, without having to consider the flow of
> > > execution through the program as a whole.
> > >
> > > https://www.gnu.org/software/guile/manual/html_node/Lexical-Scope.html
> > >
> > > Concerning Lexical Scoping and Module System:
> > > - SWI-Prolog doesn't implement lexical scoping by default.
> > > - Jekejeke Prolog implements lexical scoping by default.
> > > Mostowski Collapse schrieb am Dienstag, 14. September 2021 um 22:53:13 UTC+2:
> > > > I am in the preparation phase of a module system for
> > > > the Dogelog Runtime. It will implement some ideas of
> > > > LeanTalk. Some of these ideas are already realized in
> > > >
> > > > Jekejeke Prolog. But Jekejeke Prolog suffers from
> > > > the use of (:)/2 and (::)/2. The operator (:)/2 is in collision
> > > > with the Prolog dicts. So the module system should
> > > >
> > > > not make use of the operator (:)/2. We need to find
> > > > a new operator. Suggestion is to use the operator (.)/2
> > > > and a preliminarly named operator '$MOD'/2.
> > > >
> > > > '$MOD'/2, which might be renamed later, is only for
> > > > input/output. It should show the module context that
> > > > is lexically assigned to the atoms during reading of
> > > >
> > > > atoms. Jekejeke Prolog cannot yet input/output '$MOD'/2,
> > > > there is only a read/write option source. Dogelog Runtime
> > > > will have the same read/write option source, but additionally
> > > >
> > > > support '$MOD'/2.

More stuff that Logtalk can only dream of. In Dogelog Runtime we
recently introduced a new type tester called symbol/1. One can
imagine that it is bootstrapped from blob/2 as follows:

symbol(X) :- blob(X, _).

Dogelog Runtime does also accept symbols as functors, similar
like SWI-Prolog. This is used to inline disjunction and if-then-else,
and could have further optimization use cases. Functors are not
only restricted to atoms, they can be atoms or references:

/* Dogelog Runtime, 0.9.6 */
?- current_input(X), atom(X).
fail.

?- current_input(X), Y =.. [X, bar].
X = [object Object], Y = [object Object](bar).

See also:

Is there a Prolog name for atom/1 or stream/1 etc (SWI-Prolog)
https://stackoverflow.com/q/69137776/502187

But I am currently thinking about extending (=..)/2 even more.
Namely to allow a compound as functor. What should a
compound as functor do? Very simple:

/* Expected Result */
?- X =.. [foo(bar), baz].
X = foo(bar, baz)

So (=..)/2 would add the arguments to the given compound. This
further extension of (=..)/2 doesn't need a new data type in the
compound functor, but rather changes its behaviour.

It would have a couple of use cases:

-Old Higher Order:
Bootstrapping apply/2 would be as easy as:

apply(X,L) :- G =.. [X|L], G.

- New Higher Order:
Bottstrapping call/n would be as easy as:

call(X,Y) :- G =.. [X,Y], G.
call(X,Y,Z) :- G =.. [X,Y,Z], G.
call(X,Y,Z,T) :- G =.. [X,Y,Z,T], G.
Etc..

-DCG Expansion:
Expanding a non-terminal by an input and output list
would be only a matter of calling (=..)/2. Here is an example:

?- G =.. [np(X),I,O].
G = np(X,I,O).

Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:07:57 UTC+2:
> More stuff that Logtalk can only dream of. In Dogelog Runtime we
> recently introduced a new type tester called symbol/1. One can
> imagine that it is bootstrapped from blob/2 as follows:
>
> symbol(X) :- blob(X, _).
>
> Dogelog Runtime does also accept symbols as functors, similar
> like SWI-Prolog. This is used to inline disjunction and if-then-else,
> and could have further optimization use cases. Functors are not
> only restricted to atoms, they can be atoms or references:
>
> /* Dogelog Runtime, 0.9.6 */
> ?- current_input(X), atom(X).
> fail.
>
> ?- current_input(X), Y =.. [X, bar].
> X = [object Object], Y = [object Object](bar).
>
> See also:
>
> Is there a Prolog name for atom/1 or stream/1 etc (SWI-Prolog)
> https://stackoverflow.com/q/69137776/502187

A few weeks ago I would have posted the same idea on
SWI-Prolog discourse. But since I got massively censored
I will not anymore post anything on SWI-Prolog discourse.

On the otherhand I feel quite unrestricted on the Python
usenet list. The people there seem to be much less
envious than on SWI-Prolog discourse. Just imagine,

I went to the Python list, and told them 10x times that
Python, especially the Python version of Dogelog Runtime,
was extremly slow. There wasn't really a uproar or shit storm.

SWI-Prolog would already have lost it in the first second,
and censored every bit of what I was asking or reporting.
Python usenet group showed some professionality.

LoL

Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:11:37 UTC+2:
> But I am currently thinking about extending (=..)/2 even more.
> Namely to allow a compound as functor. What should a
> compound as functor do? Very simple:
>
> /* Expected Result */
> ?- X =.. [foo(bar), baz].
> X = foo(bar, baz)
>
> So (=..)/2 would add the arguments to the given compound. This
> further extension of (=..)/2 doesn't need a new data type in the
> compound functor, but rather changes its behaviour.
>
> It would have a couple of use cases:
>
> -Old Higher Order:
> Bootstrapping apply/2 would be as easy as:
>
> apply(X,L) :- G =.. [X|L], G.
>
> - New Higher Order:
> Bottstrapping call/n would be as easy as:
>
> call(X,Y) :- G =.. [X,Y], G.
> call(X,Y,Z) :- G =.. [X,Y,Z], G.
> call(X,Y,Z,T) :- G =.. [X,Y,Z,T], G.
> Etc..
>
> -DCG Expansion:
> Expanding a non-terminal by an input and output list
> would be only a matter of calling (=..)/2. Here is an example:
>
> ?- G =.. [np(X),I,O].
> G = np(X,I,O).
> Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:07:57 UTC+2:
> > More stuff that Logtalk can only dream of. In Dogelog Runtime we
> > recently introduced a new type tester called symbol/1. One can
> > imagine that it is bootstrapped from blob/2 as follows:
> >
> > symbol(X) :- blob(X, _).
> >
> > Dogelog Runtime does also accept symbols as functors, similar
> > like SWI-Prolog. This is used to inline disjunction and if-then-else,
> > and could have further optimization use cases. Functors are not
> > only restricted to atoms, they can be atoms or references:
> >
> > /* Dogelog Runtime, 0.9.6 */
> > ?- current_input(X), atom(X).
> > fail.
> >
> > ?- current_input(X), Y =.. [X, bar].
> > X = [object Object], Y = [object Object](bar).
> >
> > See also:
> >
> > Is there a Prolog name for atom/1 or stream/1 etc (SWI-Prolog)
> > https://stackoverflow.com/q/69137776/502187

The symbol/1 question also marks my return to stackoverflow,
for SWI-Prolog related questions. SWI-Prolog discourse has
become totally unusable due to its censoring.

If they cannot attack you directly. They start censoring other
peoples threads where you participate. And disown thread
owners (sic!). They did censor based on frequency of posts,

you hear arguments like "leave room for other people". They
did the same when Paulo Moura was in the SWI-Prolog group,
and I had the suspicion that most of the negative censoring

came from Paulo Moura. But since Paulo Moura has left the
SWI-Prolog group it is clear where the negative censoring
comes from. Most likely Paulo Moura is half as evil as I

thought, and the negative censoring is home made.
There is no danger of bringing Bin Laden into Afghanistan,
if you already have Bin Laden in Afghanistan.

Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:17:14 UTC+2:
> A few weeks ago I would have posted the same idea on
> SWI-Prolog discourse. But since I got massively censored
> I will not anymore post anything on SWI-Prolog discourse.
>
> On the otherhand I feel quite unrestricted on the Python
> usenet list. The people there seem to be much less
> envious than on SWI-Prolog discourse. Just imagine,
>
> I went to the Python list, and told them 10x times that
> Python, especially the Python version of Dogelog Runtime,
> was extremly slow. There wasn't really a uproar or shit storm.
>
> SWI-Prolog would already have lost it in the first second,
> and censored every bit of what I was asking or reporting.
> Python usenet group showed some professionality.
>
> LoL
> Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:11:37 UTC+2:
> > But I am currently thinking about extending (=..)/2 even more.
> > Namely to allow a compound as functor. What should a
> > compound as functor do? Very simple:
> >
> > /* Expected Result */
> > ?- X =.. [foo(bar), baz].
> > X = foo(bar, baz)
> >
> > So (=..)/2 would add the arguments to the given compound. This
> > further extension of (=..)/2 doesn't need a new data type in the
> > compound functor, but rather changes its behaviour.
> >
> > It would have a couple of use cases:
> >
> > -Old Higher Order:
> > Bootstrapping apply/2 would be as easy as:
> >
> > apply(X,L) :- G =.. [X|L], G.
> >
> > - New Higher Order:
> > Bottstrapping call/n would be as easy as:
> >
> > call(X,Y) :- G =.. [X,Y], G.
> > call(X,Y,Z) :- G =.. [X,Y,Z], G.
> > call(X,Y,Z,T) :- G =.. [X,Y,Z,T], G.
> > Etc..
> >
> > -DCG Expansion:
> > Expanding a non-terminal by an input and output list
> > would be only a matter of calling (=..)/2. Here is an example:
> >
> > ?- G =.. [np(X),I,O].
> > G = np(X,I,O).
> > Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:07:57 UTC+2:
> > > More stuff that Logtalk can only dream of. In Dogelog Runtime we
> > > recently introduced a new type tester called symbol/1. One can
> > > imagine that it is bootstrapped from blob/2 as follows:
> > >
> > > symbol(X) :- blob(X, _).
> > >
> > > Dogelog Runtime does also accept symbols as functors, similar
> > > like SWI-Prolog. This is used to inline disjunction and if-then-else,
> > > and could have further optimization use cases. Functors are not
> > > only restricted to atoms, they can be atoms or references:
> > >
> > > /* Dogelog Runtime, 0.9.6 */
> > > ?- current_input(X), atom(X).
> > > fail.
> > >
> > > ?- current_input(X), Y =.. [X, bar].
> > > X = [object Object], Y = [object Object](bar).
> > >
> > > See also:
> > >
> > > Is there a Prolog name for atom/1 or stream/1 etc (SWI-Prolog)
> > > https://stackoverflow.com/q/69137776/502187

I am not yet sure whether the speed dominancy of SWI-Prolog
can be broken. There are host languages which support
"garbage first", and using the heap instead of a custom

stack, as SWI-Prolog does, could maybe show the same
speed. Not yet sure. Working on it. "garbage first" is the
approach of Dogelog Runtime, its not the approach of

Jekejeke Prolog. What is more likely, instead of killing it
concerning speed, is a more clean cut module system written
in Prolog itself. Already read/write are written in Prolog

itself in Dogelog Runtime. Speed of the read/write is also
improving, see also:

Preview: Increasing the speed of the Dogelog parser. (Jekejeke)
https://twitter.com/dogelogch/status/1438164714002042891

Preview: Increasing the speed of the Dogelog parser. (Jekejeke)
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb am Freitag, 17. September 2021 um 14:25:51 UTC+2:
> The symbol/1 question also marks my return to stackoverflow,
> for SWI-Prolog related questions. SWI-Prolog discourse has
> become totally unusable due to its censoring.
>
> If they cannot attack you directly. They start censoring other
> peoples threads where you participate. And disown thread
> owners (sic!). They did censor based on frequency of posts,
>
> you hear arguments like "leave room for other people". They
> did the same when Paulo Moura was in the SWI-Prolog group,
> and I had the suspicion that most of the negative censoring
>
> came from Paulo Moura. But since Paulo Moura has left the
> SWI-Prolog group it is clear where the negative censoring
> comes from. Most likely Paulo Moura is half as evil as I
>
> thought, and the negative censoring is home made.

Do you say Python should not be used to implement
such things? In my opinion, Python has a high potential
to implement Prolog, because it has also ast.parse()

and compile(). But I do not yet have a showcase that uses
these features of Python to compile Prolog. I dont work 24/7
and I cannot clone myself. Currently the Prolog code is interpreted.

I have a prototype where Prolog code is compiled into JavaScript,
but I did not yet try this approach with Python. Here you see how
JavaScript closures are generated, a first prototype:

const alt4 = make_defined([new Clause(1, [0, 0], function(
display, actual, cont) {return(new Compound(".", [new Compound(
"==", [deref(actual.args[0]), "end_of_file"]), new Compound(
".", [new Compound("$CUT", [deref(display[0])]), cont
])]))}, 0, undefined), new Clause(1, [0, 0], function(
display, actual, cont) {return(new Compound(".", [new Compound(
"expand_include", [deref(actual.args[0]), deref(actual.args[1]
), display[0] = new Variable()]), new Compound(".",
[new Compound("handle_term", [deref(display[0])]), new Compound(
".", ["fail", cont])])]))}, -1, undefined)]);

add("next_term", 1, new Clause(2, [0], function(display, actual,
cont) {return(new Compound(".", [new Compound("read_term",
[deref(actual.args[0]), display[0] = new Variable(),
new Compound(".", [new Compound("variable_names", [
display[1] = new Variable()]), "[]"])]), new Compound(
".", [new Compound(alt4, [deref(display[0]), deref(
display[1])]), cont])]))}, -1, undefined));

https://github.com/jburse/dogelog-moon/issues/184

Will do the same for Python in the next weeks. Then later this approach
will be combined with a few planned optimizations. So far got a 25%
speed increase for JavaScript with this new compilation scheme, but

there is no official release out yet, that features this approach. And
there should be much more in it, also for Python.

Please be patient. A big problem with development can be
burnout. So I am trying to slow down things at the moment.
The ideas are easy to sketch, but implementation can take

weeks. Here is the idea again in a nutshell: use ast.parse()
and compile(). Or build directly an AST, not using the string
detour as in ast.parse(). How long will it take to have a

working solution? 11 years ago there was:

Pyrolog: Prolog written in Python using PyPy's RPython tool chain
https://www.reddit.com/r/prolog/comments/fbuz1/pyrolog_prolog_written_in_python_using_pypys/

RPython is a framework for implementing interpreters and virtual
machines for programming languages, especially dynamic languages.
https://rpython.readthedocs.io/en/latest/faq.html

Currently I am not planning to use RPython, want to to use
standard Python AST and compile(). Might have a look at
RPython or similar stuff later.

Mostowski Collapse schrieb am Sonntag, 19. September 2021 um 22:25:46 UTC+2:
> Do you say Python should not be used to implement
> such things? In my opinion, Python has a high potential
> to implement Prolog, because it has also ast.parse()
>
> and compile(). But I do not yet have a showcase that uses
> these features of Python to compile Prolog. I dont work 24/7
> and I cannot clone myself. Currently the Prolog code is interpreted.
>
> I have a prototype where Prolog code is compiled into JavaScript,
> but I did not yet try this approach with Python. Here you see how
> JavaScript closures are generated, a first prototype:
>
> const alt4 = make_defined([new Clause(1, [0, 0], function(
> display, actual, cont) {return(new Compound(".", [new Compound(
> "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> ".", [new Compound("$CUT", [deref(display[0])]), cont
> ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> display, actual, cont) {return(new Compound(".", [new Compound(
> "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> ), display[0] = new Variable()]), new Compound(".",
> [new Compound("handle_term", [deref(display[0])]), new Compound(
> ".", ["fail", cont])])]))}, -1, undefined)]);
>
> add("next_term", 1, new Clause(2, [0], function(display, actual,
> cont) {return(new Compound(".", [new Compound("read_term",
> [deref(actual.args[0]), display[0] = new Variable(),
> new Compound(".", [new Compound("variable_names", [
> display[1] = new Variable()]), "[]"])]), new Compound(
> ".", [new Compound(alt4, [deref(display[0]), deref(
> display[1])]), cont])]))}, -1, undefined));
>
> https://github.com/jburse/dogelog-moon/issues/184
>
> Will do the same for Python in the next weeks. Then later this approach
> will be combined with a few planned optimizations. So far got a 25%
> speed increase for JavaScript with this new compilation scheme, but
>
> there is no official release out yet, that features this approach. And
> there should be much more in it, also for Python.

Woa! There is some competition for JavaScript and
node.exe. PyPy is faster! Faster than GraalVM. Now
I get for my usual Python benchmark, figures in
milliseconds:

Standard GraalVM PyPy
170'996 28'523 9'755

Not bad. Only like 2x times slower than node.exe.
Now imaging I can realize the ast.parse() and
compile() idea as well! (Made an experiment
today, testing some corner with evaluation)

BTW: Here the full results. Was using:
pypy3.7-v7.3.5-win64\pypy3.exe

Test Standard GraalVM PyPy
nrev 20'389 3'611 1'254
crypt 17'103 3'248 960
deriv 20'808 3'111 1'250
poly 17'518 3'045 1'149
qsort 20'191 3'243 1'127
tictac 13'761 2'469 783
queens 17'691 3'242 1'024
query 6'161 1'155 313
mtak 17'209 2'300 907
perfect 20'165 3'099 988
calc N/A N/A N/A
Total 170'996 28'523 9'755

Mostowski Collapse schrieb am Sonntag, 19. September 2021 um 22:26:49 UTC+2:
> Please be patient. A big problem with development can be
> burnout. So I am trying to slow down things at the moment.
> The ideas are easy to sketch, but implementation can take
>
> weeks. Here is the idea again in a nutshell: use ast.parse()
> and compile(). Or build directly an AST, not using the string
> detour as in ast.parse(). How long will it take to have a
>
> working solution? 11 years ago there was:
>
> Pyrolog: Prolog written in Python using PyPy's RPython tool chain
> https://www.reddit.com/r/prolog/comments/fbuz1/pyrolog_prolog_written_in_python_using_pypys/
>
> RPython is a framework for implementing interpreters and virtual
> machines for programming languages, especially dynamic languages.
> https://rpython.readthedocs.io/en/latest/faq.html
>
> Currently I am not planning to use RPython, want to to use
> standard Python AST and compile(). Might have a look at
> RPython or similar stuff later.
> Mostowski Collapse schrieb am Sonntag, 19. September 2021 um 22:25:46 UTC+2:
> > Do you say Python should not be used to implement
> > such things? In my opinion, Python has a high potential
> > to implement Prolog, because it has also ast.parse()
> >
> > and compile(). But I do not yet have a showcase that uses
> > these features of Python to compile Prolog. I dont work 24/7
> > and I cannot clone myself. Currently the Prolog code is interpreted.
> >
> > I have a prototype where Prolog code is compiled into JavaScript,
> > but I did not yet try this approach with Python. Here you see how
> > JavaScript closures are generated, a first prototype:
> >
> > const alt4 = make_defined([new Clause(1, [0, 0], function(
> > display, actual, cont) {return(new Compound(".", [new Compound(
> > "==", [deref(actual.args[0]), "end_of_file"]), new Compound(
> > ".", [new Compound("$CUT", [deref(display[0])]), cont
> > ])]))}, 0, undefined), new Clause(1, [0, 0], function(
> > display, actual, cont) {return(new Compound(".", [new Compound(
> > "expand_include", [deref(actual.args[0]), deref(actual.args[1]
> > ), display[0] = new Variable()]), new Compound(".",
> > [new Compound("handle_term", [deref(display[0])]), new Compound(
> > ".", ["fail", cont])])]))}, -1, undefined)]);
> >
> > add("next_term", 1, new Clause(2, [0], function(display, actual,
> > cont) {return(new Compound(".", [new Compound("read_term",
> > [deref(actual.args[0]), display[0] = new Variable(),
> > new Compound(".", [new Compound("variable_names", [
> > display[1] = new Variable()]), "[]"])]), new Compound(
> > ".", [new Compound(alt4, [deref(display[0]), deref(
> > display[1])]), cont])]))}, -1, undefined));
> >
> > https://github.com/jburse/dogelog-moon/issues/184
> >
> > Will do the same for Python in the next weeks. Then later this approach
> > will be combined with a few planned optimizations. So far got a 25%
> > speed increase for JavaScript with this new compilation scheme, but
> >
> > there is no official release out yet, that features this approach. And
> > there should be much more in it, also for Python.