50 Years of Prolog and Beyond
26 Jan 2022 - SWOT analysis
https://arxiv.org/abs/2201.10816

No mention of self-hosting systems? Like the AQUARIUS
Prolog system. I am not sure whether it was 100% self-hosting,
but had many parts written in Prolog itself, interpreter and compiler:

Aquarius Prolog 1.0
https://www.info.ucl.ac.be/~pvr/aquarius.html

What is self-hosting? See Wikipedia:

"In computer programming, self-hosting is the use of a
program as part of the toolchain or operating system that
produces new versions of that same program—for example,
a compiler that can compile its own source code."
https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29

Why isn't Prolog listed there?

Shit!!!! I am like a blink from self-hosting Dogelog player.
I only need open(write) and open(append) ISO predicates,
and maybe 2-3 other predicates, and it will be self-hosting.

One itchy thing is, I would like to make the cross compiler
output pretty printed, like not occupying lines longer than
75 characters, so I need a more intelligent pretty printing first,

before I can generate "nice" and VCS friendly and debuger
friendly cross compiled output.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> 50 Years of Prolog and Beyond
> 26 Jan 2022 - SWOT analysis
> https://arxiv.org/abs/2201.10816
>
> No mention of self-hosting systems? Like the AQUARIUS
> Prolog system. I am not sure whether it was 100% self-hosting,
> but had many parts written in Prolog itself, interpreter and compiler:
>
> Aquarius Prolog 1.0
> https://www.info.ucl.ac.be/~pvr/aquarius.html
>
> What is self-hosting? See Wikipedia:
>
> "In computer programming, self-hosting is the use of a
> program as part of the toolchain or operating system that
> produces new versions of that same program—for example,
> a compiler that can compile its own source code."
> https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
>
> Why isn't Prolog listed there?

Also I had some nice findings about style checks. The cross
compiler can also do a couple of them, although he fires and
forgets what he cross compiles. But the cross compiler can

keep the same meta data predicate property info like the
online system, and perform some style checks that go beyond
the trivial singleton check, makeing it ultimately show the same

warnings like the online system. Which would prevent a lot
of programming errors. The cross-compiler would then be a
little bit more restrictive what it accepts than the online system,

because it needs to interpret certain directives.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1:
> Shit!!!! I am like a blink from self-hosting Dogelog player.
> I only need open(write) and open(append) ISO predicates,
> and maybe 2-3 other predicates, and it will be self-hosting.
>
> One itchy thing is, I would like to make the cross compiler
> output pretty printed, like not occupying lines longer than
> 75 characters, so I need a more intelligent pretty printing first,
>
> before I can generate "nice" and VCS friendly and debuger
> friendly cross compiled output.
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> > 50 Years of Prolog and Beyond
> > 26 Jan 2022 - SWOT analysis
> > https://arxiv.org/abs/2201.10816
> >
> > No mention of self-hosting systems? Like the AQUARIUS
> > Prolog system. I am not sure whether it was 100% self-hosting,
> > but had many parts written in Prolog itself, interpreter and compiler:
> >
> > Aquarius Prolog 1.0
> > https://www.info.ucl.ac.be/~pvr/aquarius.html
> >
> > What is self-hosting? See Wikipedia:
> >
> > "In computer programming, self-hosting is the use of a
> > program as part of the toolchain or operating system that
> > produces new versions of that same program—for example,
> > a compiler that can compile its own source code."
> > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
> >
> > Why isn't Prolog listed there?

Ha Ha, their SWOT Analysis is cringe:

Threats (Section 4.4)
post-desktop world of JavaScript web-applications

Good luck with sticking to C, Java or other nonsense,
and not having self-hosting system, where the backend
can easily be switched. Or even self-hosting system

that target high-level languages with their own garbage
collection, such as JavaScript or Python. I cannot predict
the future, but I have the impression that if you have

an item on your SWOT Analysis as a threat and do not
adress it for years, what will be the outcome?

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1:
> Also I had some nice findings about style checks. The cross
> compiler can also do a couple of them, although he fires and
> forgets what he cross compiles. But the cross compiler can
>
> keep the same meta data predicate property info like the
> online system, and perform some style checks that go beyond
> the trivial singleton check, makeing it ultimately show the same
>
> warnings like the online system. Which would prevent a lot
> of programming errors. The cross-compiler would then be a
> little bit more restrictive what it accepts than the online system,
>
> because it needs to interpret certain directives.
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1:
> > Shit!!!! I am like a blink from self-hosting Dogelog player.
> > I only need open(write) and open(append) ISO predicates,
> > and maybe 2-3 other predicates, and it will be self-hosting.
> >
> > One itchy thing is, I would like to make the cross compiler
> > output pretty printed, like not occupying lines longer than
> > 75 characters, so I need a more intelligent pretty printing first,
> >
> > before I can generate "nice" and VCS friendly and debuger
> > friendly cross compiled output.
> > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> > > 50 Years of Prolog and Beyond
> > > 26 Jan 2022 - SWOT analysis
> > > https://arxiv.org/abs/2201.10816
> > >
> > > No mention of self-hosting systems? Like the AQUARIUS
> > > Prolog system. I am not sure whether it was 100% self-hosting,
> > > but had many parts written in Prolog itself, interpreter and compiler:
> > >
> > > Aquarius Prolog 1.0
> > > https://www.info.ucl.ac.be/~pvr/aquarius.html
> > >
> > > What is self-hosting? See Wikipedia:
> > >
> > > "In computer programming, self-hosting is the use of a
> > > program as part of the toolchain or operating system that
> > > produces new versions of that same program—for example,
> > > a compiler that can compile its own source code."
> > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
> > >
> > > Why isn't Prolog listed there?

Also JavaScript and Python in the form of node.js and
PyPy make a quite good impression also server side, nothing
to do with desktop or client side. Thats also nonsense.

But there are dozen of open questions now. How to make
it multi-threaded, how to make an auto-tuning garbage collector,
that somehow adapts to the performance of the target system.

On my old system I was deteriming fixed parameters so that garbage
collection does it job 60 times per second. Now on my new
system with some AMD Ryzen, these parameters are not correct

anymore, and it does more than 60 times per second. I running
it on an Apple M1 will be even worse.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1:
> Ha Ha, their SWOT Analysis is cringe:
>
> Threats (Section 4.4)
> post-desktop world of JavaScript web-applications
>
> Good luck with sticking to C, Java or other nonsense,
> and not having self-hosting system, where the backend
> can easily be switched. Or even self-hosting system
>
> that target high-level languages with their own garbage
> collection, such as JavaScript or Python. I cannot predict
> the future, but I have the impression that if you have
>
> an item on your SWOT Analysis as a threat and do not
> adress it for years, what will be the outcome?
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1:
> > Also I had some nice findings about style checks. The cross
> > compiler can also do a couple of them, although he fires and
> > forgets what he cross compiles. But the cross compiler can
> >
> > keep the same meta data predicate property info like the
> > online system, and perform some style checks that go beyond
> > the trivial singleton check, makeing it ultimately show the same
> >
> > warnings like the online system. Which would prevent a lot
> > of programming errors. The cross-compiler would then be a
> > little bit more restrictive what it accepts than the online system,
> >
> > because it needs to interpret certain directives.
> > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1:
> > > Shit!!!! I am like a blink from self-hosting Dogelog player.
> > > I only need open(write) and open(append) ISO predicates,
> > > and maybe 2-3 other predicates, and it will be self-hosting.
> > >
> > > One itchy thing is, I would like to make the cross compiler
> > > output pretty printed, like not occupying lines longer than
> > > 75 characters, so I need a more intelligent pretty printing first,
> > >
> > > before I can generate "nice" and VCS friendly and debuger
> > > friendly cross compiled output.
> > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> > > > 50 Years of Prolog and Beyond
> > > > 26 Jan 2022 - SWOT analysis
> > > > https://arxiv.org/abs/2201.10816
> > > >
> > > > No mention of self-hosting systems? Like the AQUARIUS
> > > > Prolog system. I am not sure whether it was 100% self-hosting,
> > > > but had many parts written in Prolog itself, interpreter and compiler:
> > > >
> > > > Aquarius Prolog 1.0
> > > > https://www.info.ucl.ac.be/~pvr/aquarius.html
> > > >
> > > > What is self-hosting? See Wikipedia:
> > > >
> > > > "In computer programming, self-hosting is the use of a
> > > > program as part of the toolchain or operating system that
> > > > produces new versions of that same program—for example,
> > > > a compiler that can compile its own source code."
> > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
> > > >
> > > > Why isn't Prolog listed there?

But I need a notion that goes beyond wall time now, something
like user time and system time. In JavaScript user time would
be suspended when for example a wait for setTime() or some

fetch is ongoing. But interestingly because the target language
has a certain event loop architecture, we can cooperate with this
event loop architecture, and for example do our own Prolog

garbage collection before we relinquish to the event loop,
so that the target system is not in a troubled situation when ever
it processes its own tasks. And we can kind of define the

two notions user time and system time on our own, so that
it seems feasible to create an auto-tuning garbage collector
for such target systems. Not yet sure. Will see.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:07:08 UTC+1:
> Also JavaScript and Python in the form of node.js and
> PyPy make a quite good impression also server side, nothing
> to do with desktop or client side. Thats also nonsense.
>
> But there are dozen of open questions now. How to make
> it multi-threaded, how to make an auto-tuning garbage collector,
> that somehow adapts to the performance of the target system.
>
> On my old system I was deteriming fixed parameters so that garbage
> collection does it job 60 times per second. Now on my new
> system with some AMD Ryzen, these parameters are not correct
>
> anymore, and it does more than 60 times per second. I running
> it on an Apple M1 will be even worse.
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1:
> > Ha Ha, their SWOT Analysis is cringe:
> >
> > Threats (Section 4.4)
> > post-desktop world of JavaScript web-applications
> >
> > Good luck with sticking to C, Java or other nonsense,
> > and not having self-hosting system, where the backend
> > can easily be switched. Or even self-hosting system
> >
> > that target high-level languages with their own garbage
> > collection, such as JavaScript or Python. I cannot predict
> > the future, but I have the impression that if you have
> >
> > an item on your SWOT Analysis as a threat and do not
> > adress it for years, what will be the outcome?
> > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1:
> > > Also I had some nice findings about style checks. The cross
> > > compiler can also do a couple of them, although he fires and
> > > forgets what he cross compiles. But the cross compiler can
> > >
> > > keep the same meta data predicate property info like the
> > > online system, and perform some style checks that go beyond
> > > the trivial singleton check, makeing it ultimately show the same
> > >
> > > warnings like the online system. Which would prevent a lot
> > > of programming errors. The cross-compiler would then be a
> > > little bit more restrictive what it accepts than the online system,
> > >
> > > because it needs to interpret certain directives.
> > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1:
> > > > Shit!!!! I am like a blink from self-hosting Dogelog player.
> > > > I only need open(write) and open(append) ISO predicates,
> > > > and maybe 2-3 other predicates, and it will be self-hosting.
> > > >
> > > > One itchy thing is, I would like to make the cross compiler
> > > > output pretty printed, like not occupying lines longer than
> > > > 75 characters, so I need a more intelligent pretty printing first,
> > > >
> > > > before I can generate "nice" and VCS friendly and debuger
> > > > friendly cross compiled output.
> > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> > > > > 50 Years of Prolog and Beyond
> > > > > 26 Jan 2022 - SWOT analysis
> > > > > https://arxiv.org/abs/2201.10816
> > > > >
> > > > > No mention of self-hosting systems? Like the AQUARIUS
> > > > > Prolog system. I am not sure whether it was 100% self-hosting,
> > > > > but had many parts written in Prolog itself, interpreter and compiler:
> > > > >
> > > > > Aquarius Prolog 1.0
> > > > > https://www.info.ucl.ac.be/~pvr/aquarius.html
> > > > >
> > > > > What is self-hosting? See Wikipedia:
> > > > >
> > > > > "In computer programming, self-hosting is the use of a
> > > > > program as part of the toolchain or operating system that
> > > > > produces new versions of that same program—for example,
> > > > > a compiler that can compile its own source code."
> > > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
> > > > >
> > > > > Why isn't Prolog listed there?

TauProlog and SWI-Prolog might also be on a path
forward here. SWI-Prolog discourse had recently
an interesting post:

Yielding prolog engines from within a foreign predicate
https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5

But this was in the context of Rust. What Scryer Prolog offers
here I don't know, the Rust and Crate build system is annyoingly
slow, and fails because of some OpenSSL issues on WSL.

No time to fix that and follow what Scryer Prolog is doing...

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:10:35 UTC+1:
> But I need a notion that goes beyond wall time now, something
> like user time and system time. In JavaScript user time would
> be suspended when for example a wait for setTime() or some
>
> fetch is ongoing. But interestingly because the target language
> has a certain event loop architecture, we can cooperate with this
> event loop architecture, and for example do our own Prolog
>
> garbage collection before we relinquish to the event loop,
> so that the target system is not in a troubled situation when ever
> it processes its own tasks. And we can kind of define the
>
> two notions user time and system time on our own, so that
> it seems feasible to create an auto-tuning garbage collector
> for such target systems. Not yet sure. Will see.
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:07:08 UTC+1:
> > Also JavaScript and Python in the form of node.js and
> > PyPy make a quite good impression also server side, nothing
> > to do with desktop or client side. Thats also nonsense.
> >
> > But there are dozen of open questions now. How to make
> > it multi-threaded, how to make an auto-tuning garbage collector,
> > that somehow adapts to the performance of the target system.
> >
> > On my old system I was deteriming fixed parameters so that garbage
> > collection does it job 60 times per second. Now on my new
> > system with some AMD Ryzen, these parameters are not correct
> >
> > anymore, and it does more than 60 times per second. I running
> > it on an Apple M1 will be even worse.
> > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:59:10 UTC+1:
> > > Ha Ha, their SWOT Analysis is cringe:
> > >
> > > Threats (Section 4.4)
> > > post-desktop world of JavaScript web-applications
> > >
> > > Good luck with sticking to C, Java or other nonsense,
> > > and not having self-hosting system, where the backend
> > > can easily be switched. Or even self-hosting system
> > >
> > > that target high-level languages with their own garbage
> > > collection, such as JavaScript or Python. I cannot predict
> > > the future, but I have the impression that if you have
> > >
> > > an item on your SWOT Analysis as a threat and do not
> > > adress it for years, what will be the outcome?
> > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:49:10 UTC+1:
> > > > Also I had some nice findings about style checks. The cross
> > > > compiler can also do a couple of them, although he fires and
> > > > forgets what he cross compiles. But the cross compiler can
> > > >
> > > > keep the same meta data predicate property info like the
> > > > online system, and perform some style checks that go beyond
> > > > the trivial singleton check, makeing it ultimately show the same
> > > >
> > > > warnings like the online system. Which would prevent a lot
> > > > of programming errors. The cross-compiler would then be a
> > > > little bit more restrictive what it accepts than the online system,
> > > >
> > > > because it needs to interpret certain directives.
> > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:47:41 UTC+1:
> > > > > Shit!!!! I am like a blink from self-hosting Dogelog player.
> > > > > I only need open(write) and open(append) ISO predicates,
> > > > > and maybe 2-3 other predicates, and it will be self-hosting.
> > > > >
> > > > > One itchy thing is, I would like to make the cross compiler
> > > > > output pretty printed, like not occupying lines longer than
> > > > > 75 characters, so I need a more intelligent pretty printing first,
> > > > >
> > > > > before I can generate "nice" and VCS friendly and debuger
> > > > > friendly cross compiled output.
> > > > > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 16:41:35 UTC+1:
> > > > > > 50 Years of Prolog and Beyond
> > > > > > 26 Jan 2022 - SWOT analysis
> > > > > > https://arxiv.org/abs/2201.10816
> > > > > >
> > > > > > No mention of self-hosting systems? Like the AQUARIUS
> > > > > > Prolog system. I am not sure whether it was 100% self-hosting,
> > > > > > but had many parts written in Prolog itself, interpreter and compiler:
> > > > > >
> > > > > > Aquarius Prolog 1.0
> > > > > > https://www.info.ucl.ac.be/~pvr/aquarius.html
> > > > > >
> > > > > > What is self-hosting? See Wikipedia:
> > > > > >
> > > > > > "In computer programming, self-hosting is the use of a
> > > > > > program as part of the toolchain or operating system that
> > > > > > produces new versions of that same program—for example,
> > > > > > a compiler that can compile its own source code."
> > > > > > https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
> > > > > >
> > > > > > Why isn't Prolog listed there?

But you see the problem with non-self-hosting Prolog systems.
If SWI-Prolog were self-hosting, there would be already a Rust
version of SWI-Prolog now. But SWI-Prolog is the anti-thesis

to a Prolog system that is 100% Prolog. Its rather a Prolog
system that is 100% C. And you cannot easily switch some
back-end from C to Rust, and have a top-level in Rust.

Its quite astonishingly how much SWI-Prolog relies on C,
even when you would only consider a very small subset. It
seems SWI-Prolog never trusted Prolog as an implementation

language because of performance issues. I don't know the
final judgement here, there is an old post by Richard O'Keefe
that says self hosting in principle shouldn't be a problem.

"John Griffith writes:
I know it will be slower.

Richard A. O'Keefe responds:
Are you sure? The measurements I did a couple of years ago
showed that tokenising was slower in Prolog than in C (typically
because Prolog implementors don't put the effort into making
get0/1 go as screamingly fast as it could go), but there was very
little difference in parsing if you had a good Prolog compiler."
7th November 1996 - Prolog Parser in Prolog
https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1:
> TauProlog and SWI-Prolog might also be on a path
> forward here. SWI-Prolog discourse had recently
> an interesting post:
>
> Yielding prolog engines from within a foreign predicate
> https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5
>
> But this was in the context of Rust. What Scryer Prolog offers
> here I don't know, the Rust and Crate build system is annyoingly
> slow, and fails because of some OpenSSL issues on WSL.
>
> No time to fix that and follow what Scryer Prolog is doing...

Disclaimer: Maybe SWI-Prolog does the parsing already in C,
and the C percentage is not that high. I am drawing some
extreme pictures here to make a point.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:33:46 UTC+1:
> But you see the problem with non-self-hosting Prolog systems.
> If SWI-Prolog were self-hosting, there would be already a Rust
> version of SWI-Prolog now. But SWI-Prolog is the anti-thesis
>
> to a Prolog system that is 100% Prolog. Its rather a Prolog
> system that is 100% C. And you cannot easily switch some
> back-end from C to Rust, and have a top-level in Rust.
>
> Its quite astonishingly how much SWI-Prolog relies on C,
> even when you would only consider a very small subset. It
> seems SWI-Prolog never trusted Prolog as an implementation
>
> language because of performance issues. I don't know the
> final judgement here, there is an old post by Richard O'Keefe
> that says self hosting in principle shouldn't be a problem.
>
> "John Griffith writes:
> I know it will be slower.
>
> Richard A. O'Keefe responds:
> Are you sure? The measurements I did a couple of years ago
> showed that tokenising was slower in Prolog than in C (typically
> because Prolog implementors don't put the effort into making
> get0/1 go as screamingly fast as it could go), but there was very
> little difference in parsing if you had a good Prolog compiler."
> 7th November 1996 - Prolog Parser in Prolog
> https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1:
> > TauProlog and SWI-Prolog might also be on a path
> > forward here. SWI-Prolog discourse had recently
> > an interesting post:
> >
> > Yielding prolog engines from within a foreign predicate
> > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5
> >
> > But this was in the context of Rust. What Scryer Prolog offers
> > here I don't know, the Rust and Crate build system is annyoingly
> > slow, and fails because of some OpenSSL issues on WSL.
> >
> > No time to fix that and follow what Scryer Prolog is doing...

Corr.: Typo

Disclaimer: Maybe SWI-Prolog does the parsing already in Prolog,
and the C percentage is not that high. I am drawing some
extreme pictures here to make a point.

Also instead of self-hosting, foreign-hosting, just using a
cross compiler, is of course also a solution. But ultimately
compiling your own system with your system,

is a nice bootstrapping test and decouples you from some
other system. Might be necessary to perform a certain
evolution through bootstrapping, when

you want to abandon the other system.

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:35:42 UTC+1:
> Disclaimer: Maybe SWI-Prolog does the parsing already in C,
> and the C percentage is not that high. I am drawing some
> extreme pictures here to make a point.
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:33:46 UTC+1:
> > But you see the problem with non-self-hosting Prolog systems.
> > If SWI-Prolog were self-hosting, there would be already a Rust
> > version of SWI-Prolog now. But SWI-Prolog is the anti-thesis
> >
> > to a Prolog system that is 100% Prolog. Its rather a Prolog
> > system that is 100% C. And you cannot easily switch some
> > back-end from C to Rust, and have a top-level in Rust.
> >
> > Its quite astonishingly how much SWI-Prolog relies on C,
> > even when you would only consider a very small subset. It
> > seems SWI-Prolog never trusted Prolog as an implementation
> >
> > language because of performance issues. I don't know the
> > final judgement here, there is an old post by Richard O'Keefe
> > that says self hosting in principle shouldn't be a problem.
> >
> > "John Griffith writes:
> > I know it will be slower.
> >
> > Richard A. O'Keefe responds:
> > Are you sure? The measurements I did a couple of years ago
> > showed that tokenising was slower in Prolog than in C (typically
> > because Prolog implementors don't put the effort into making
> > get0/1 go as screamingly fast as it could go), but there was very
> > little difference in parsing if you had a good Prolog compiler."
> > 7th November 1996 - Prolog Parser in Prolog
> > https://dtai.cs.kuleuven.be/projects/ALP/newsletter/archive_93_96/net/grammars/parser.html
> > Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1:
> > > TauProlog and SWI-Prolog might also be on a path
> > > forward here. SWI-Prolog discourse had recently
> > > an interesting post:
> > >
> > > Yielding prolog engines from within a foreign predicate
> > > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5
> > >
> > > But this was in the context of Rust. What Scryer Prolog offers
> > > here I don't know, the Rust and Crate build system is annyoingly
> > > slow, and fails because of some OpenSSL issues on WSL.
> > >
> > > No time to fix that and follow what Scryer Prolog is doing...

There is a fear that a Corona Wave will be like a wall,
in that it overruns the infrastructure like a Tsunami. But
implementing a prolog system not in 100% Prolog but

in imperative language like C, even if its high-level like
Java, will also hit a wall. Its much more easier to add
functionality to a Prolog system if the Prolog

system in 100% Prolog.

Example:
TauProlog hasn't even a discontiguous check!

LoL

Mostowski Collapse schrieb:
>
> 50 Years of Prolog and Beyond
> 26 Jan 2022 - SWOT analysis
> https://arxiv.org/abs/2201.10816
>
> No mention of self-hosting systems? Like the AQUARIUS
> Prolog system. I am not sure whether it was 100% self-hosting,
> but had many parts written in Prolog itself, interpreter and compiler:
>
> Aquarius Prolog 1.0
> https://www.info.ucl.ac.be/~pvr/aquarius.html
>
> What is self-hosting? See Wikipedia:
>
> "In computer programming, self-hosting is the use of a
> program as part of the toolchain or operating system that
> produces new versions of that same program—for example,
> a compiler that can compile its own source code."
> https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
>
> Why isn't Prolog listed there?
>

Maybe Unix, with its C language, and then
C-Prolog (1982) sent the wrong message.
But sooner or later every programming

language will provide some pattern matching,
and yearn to have Prolog logical variables.
So maybe the wall is lower if other

programming languages were used like JavaScript
or Python, that have some pattern matching,
for example Python introduce a new match

control construct in release 3.10. So how
is Tau Prolog classified:

"In other words, tProlog pursues a similar
intent with respect to tuProlog and JIProlog:
bringing Prolog interpreters to high-level
platforms and languages, except it focuses
on another platform, JavaScript."

This says nothing about the compiler and
runtime architecture, its just a naive
end-user view, of a blackbox.

Mostowski Collapse schrieb:
> There is a fear that a Corona Wave will be like a wall,
> in that it overruns the infrastructure like a Tsunami. But
> implementing a prolog system not in 100% Prolog but
>
> in imperative language like C, even if its high-level like
> Java, will also hit a wall. Its much more easier to add
> functionality to a Prolog system if the Prolog
>
> system in 100% Prolog.
>
> Example:
> TauProlog hasn't even a discontiguous check!
>
> LoL
>
> Mostowski Collapse schrieb:
>>
>> 50 Years of Prolog and Beyond
>> 26 Jan 2022 - SWOT analysis
>> https://arxiv.org/abs/2201.10816
>>
>> No mention of self-hosting systems? Like the AQUARIUS
>> Prolog system. I am not sure whether it was 100% self-hosting,
>> but had many parts written in Prolog itself, interpreter and compiler:
>>
>> Aquarius Prolog 1.0
>> https://www.info.ucl.ac.be/~pvr/aquarius.html
>>
>> What is self-hosting? See Wikipedia:
>>
>> "In computer programming, self-hosting is the use of a
>> program as part of the toolchain or operating system that
>> produces new versions of that same program—for example,
>> a compiler that can compile its own source code."
>> https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
>>
>> Why isn't Prolog listed there?
>>
>

Pitty Logtalk isn't self hosting. So Logtalk
doesn't trust Logtalk as an implementation
language of the Logtalk transpiler?

Proof that it isn't self hosting, this here
is still Prolog and not Logtalk:

core compiler and runtime
https://github.com/LogtalkDotOrg/logtalk3/blob/master/core/core.pl

LoL

Today I had a little use case, where I could
use some object orientation or some such on
Dogelog Player. A style check, which works

against different data models. So a future
version of Dogelog Player would be self hosting
and object oriented?

Mostowski Collapse schrieb:
> Maybe Unix, with its C language, and then
> C-Prolog (1982) sent the wrong message.
> But sooner or later every programming
>
> language will provide some pattern matching,
> and yearn to have Prolog logical variables.
> So maybe the wall is lower if other
>
> programming languages were used like JavaScript
> or Python, that have some pattern matching,
> for example Python introduce a new match
>
> control construct in release 3.10. So how
> is Tau Prolog classified:
>
> "In other words, tProlog pursues a similar
> intent with respect to tuProlog and JIProlog:
> bringing Prolog interpreters to high-level
> platforms and languages, except it focuses
> on another platform, JavaScript."
>
> This says nothing about the compiler and
> runtime architecture, its just a naive
> end-user view, of a blackbox.
>
> Mostowski Collapse schrieb:
>> There is a fear that a Corona Wave will be like a wall,
>> in that it overruns the infrastructure like a Tsunami. But
>> implementing a prolog system not in 100% Prolog but
>>
>> in imperative language like C, even if its high-level like
>> Java, will also hit a wall. Its much more easier to add
>> functionality to a Prolog system if the Prolog
>>
>> system in 100% Prolog.
>>
>> Example:
>> TauProlog hasn't even a discontiguous check!
>>
>> LoL
>>
>> Mostowski Collapse schrieb:
>>>
>>> 50 Years of Prolog and Beyond
>>> 26 Jan 2022 - SWOT analysis
>>> https://arxiv.org/abs/2201.10816
>>>
>>> No mention of self-hosting systems? Like the AQUARIUS
>>> Prolog system. I am not sure whether it was 100% self-hosting,
>>> but had many parts written in Prolog itself, interpreter and compiler:
>>>
>>> Aquarius Prolog 1.0
>>> https://www.info.ucl.ac.be/~pvr/aquarius.html
>>>
>>> What is self-hosting? See Wikipedia:
>>>
>>> "In computer programming, self-hosting is the use of a
>>> program as part of the toolchain or operating system that
>>> produces new versions of that same program—for example,
>>> a compiler that can compile its own source code."
>>> https://en.wikipedia.org/wiki/Self-hosting_%28compilers%29
>>>
>>> Why isn't Prolog listed there?
>>>
>>
>

Can we squeeze McCune's Method into Dogelog
Player? Yes! Thanks to Josephs Vidal-Rosset, who asked
about Quine's Method (I call it Boole's Method),

we can do the squeeze. Just use Boole's Method as
the backend SAT Solver. And it can already do:

?- falsify_fol((?[X]:p(X) => ![Y]:p(Y)), 2), !.
p(0).
true.

?- falsify_fol((![Y]: ?[X]:p(X,Y) => ?[Z]:![T]:p(Z,T)), 2), !.
p(0, 1).
p(1, 0).
true.

See also:

McCune’s Method from 1994 in Dogelog Player
https://twitter.com/dogelogch/status/1488165681434697728

McCune’s Method from 1994 in Dogelog Player
https://www.facebook.com/groups/dogelog

Just enjoying a TV show NOVA Alaska Dinosaurs, they
talk about small and big Dinosaurs. Didn't the big
Dinosaurs get extinct, and the small Dinosaurs

survived in the form of birds? But I wouldn't say
Dogelog is actually a Bird. It could also be a Snake
that bites its tail, in case it becomes self hosting.

Mostowski Collapse schrieb am Montag, 31. Januar 2022 um 19:37:08 UTC+1:
> Can we squeeze McCune's Method into Dogelog
> Player? Yes! Thanks to Josephs Vidal-Rosset, who asked
> about Quine's Method (I call it Boole's Method),
>
> we can do the squeeze. Just use Boole's Method as
> the backend SAT Solver. And it can already do:
>
> ?- falsify_fol((?[X]:p(X) => ![Y]:p(Y)), 2), !.
> p(0).
> true.
>
> ?- falsify_fol((![Y]: ?[X]:p(X,Y) => ?[Z]:![T]:p(Z,T)), 2), !.
> p(0, 1).
> p(1, 0).
> true.
>
> See also:
>
> McCune’s Method from 1994 in Dogelog Player
> https://twitter.com/dogelogch/status/1488165681434697728
>
> McCune’s Method from 1994 in Dogelog Player
> https://www.facebook.com/groups/dogelog

The beauty of 3 valued logic! Or is it linear logic? Like the
cut the new construct isn't commutative, but its implemented
with extending true/false inside the Prolog trampoline. Was
having a look at ECLiPSe Prolog engines.

yield(+ToParent, -FromParent)
Stop the running engine in the yielded-state, and wait for resume
https://eclipseclp.org/docs/7.0/bips/kernel/engines/

I made something simpler for Dogelog player, which
can be used to bootstrap a lot of things:

'$STOP'(R): Internal only
The built-in stops the interpreter loop with return value R.

This is a forever and ever stop! Can this be used for
anything? Well here is a sleep/1 implementation,
it is assumed that the integer return value is interpreted
as the delay of a timeout promise:

sleep(T) :- '$STOP'(T).
sleep(_).

Putting everything together and we get:

Async/Await Prolog Console for JavaScript/Python
https://twitter.com/dogelogch/status/1488831738348515334

Async/Await Prolog Console for JavaScript/Python
https://www.facebook.com/groups/dogelog

With video recording!

Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1:
> TauProlog and SWI-Prolog might also be on a path
> forward here. SWI-Prolog discourse had recently
> an interesting post:
>
> Yielding prolog engines from within a foreign predicate
> https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5
>
> But this was in the context of Rust. What Scryer Prolog offers
> here I don't know, the Rust and Crate build system is annyoingly
> slow, and fails because of some OpenSSL issues on WSL.

If I dont stop now, in a few days I will have an
Erlang system running. What already works is
a yielding engine in the Browser.

Non-Blocking Browser for Dogelog Player
https://twitter.com/dogelogch/status/1489350992793677827

Non-Blocking Browser for Dogelog Player
https://www.facebook.com/groups/dogelog

With video recording and funky background
sound! Next will be bring this yielding engine
node.js and to Python as well.

Mostowski Collapse schrieb am Mittwoch, 2. Februar 2022 um 12:46:30 UTC+1:
> The beauty of 3 valued logic! Or is it linear logic? Like the
> cut the new construct isn't commutative, but its implemented
> with extending true/false inside the Prolog trampoline. Was
> having a look at ECLiPSe Prolog engines.
>
> yield(+ToParent, -FromParent)
> Stop the running engine in the yielded-state, and wait for resume
> https://eclipseclp.org/docs/7.0/bips/kernel/engines/
>
> I made something simpler for Dogelog player, which
> can be used to bootstrap a lot of things:
>
> '$STOP'(R): Internal only
> The built-in stops the interpreter loop with return value R.
>
> This is a forever and ever stop! Can this be used for
> anything? Well here is a sleep/1 implementation,
> it is assumed that the integer return value is interpreted
> as the delay of a timeout promise:
>
> sleep(T) :- '$STOP'(T).
> sleep(_).
>
> Putting everything together and we get:
>
> Async/Await Prolog Console for JavaScript/Python
> https://twitter.com/dogelogch/status/1488831738348515334
>
> Async/Await Prolog Console for JavaScript/Python
> https://www.facebook.com/groups/dogelog
>
> With video recording!
> Mostowski Collapse schrieb am Freitag, 28. Januar 2022 um 17:15:36 UTC+1:
> > TauProlog and SWI-Prolog might also be on a path
> > forward here. SWI-Prolog discourse had recently
> > an interesting post:
> >
> > Yielding prolog engines from within a foreign predicate
> > https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5
> >
> > But this was in the context of Rust. What Scryer Prolog offers
> > here I don't know, the Rust and Crate build system is annyoingly
> > slow, and fails because of some OpenSSL issues on WSL.

It will take some time until I have an Erlang system.
The small things use a lot of time. Now I have
an non-async/await Sandbox and a async/await Sandbox

online. The Audio Player example allows playing with
the async/await Sandbox. The Audio Example will
disable the Tryit button and enable it again, when finished.

But its non-blocking, you can interact with the browser,
and it will not show the warning display in Chrome. Unfortunately
there is still an unsolved problem, the LIPS go down.

But this here works fine:

longrunning :-
between(1,300,_),
between(1,300,_),
between(1,300,_),
fail.
longrunning.

?- time(longrunning).
% Wall 37203 ms, gc 25 ms, 2206445 lips
true.

http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html

The LIPS go down because setTimeout() is clamped by 4ms in
the browser, and I do ca. 60x per Second setTimeout(). To give the
browser the opportunity to do his own stuff.

Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1:
> If I dont stop now, in a few days I will have an
> Erlang system running. What already works is
> a yielding engine in the Browser.
>
> Non-Blocking Browser for Dogelog Player
> https://twitter.com/dogelogch/status/1489350992793677827
>
> Non-Blocking Browser for Dogelog Player
> https://www.facebook.com/groups/dogelog
>
> With video recording and funky background
> sound! Next will be bring this yielding engine
> node.js and to Python as well.

Maybe I should show a spinning wheel or
something, while the thingy runs? The color
change in the button is nearly not seen...

Mostowski Collapse schrieb:
> It will take some time until I have an Erlang system.
> The small things use a lot of time. Now I have
> an non-async/await Sandbox and a async/await Sandbox
>
> online. The Audio Player example allows playing with
> the async/await Sandbox. The Audio Example will
> disable the Tryit button and enable it again, when finished.
>
> But its non-blocking, you can interact with the browser,
> and it will not show the warning display in Chrome. Unfortunately
> there is still an unsolved problem, the LIPS go down.
>
> But this here works fine:
>
> longrunning :-
> between(1,300,_),
> between(1,300,_),
> between(1,300,_),
> fail.
> longrunning.
>
> ?- time(longrunning).
> % Wall 37203 ms, gc 25 ms, 2206445 lips
> true.
>
> http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html
>
> The LIPS go down because setTimeout() is clamped by 4ms in
> the browser, and I do ca. 60x per Second setTimeout(). To give the
> browser the opportunity to do his own stuff.
>
> Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1:
>> If I dont stop now, in a few days I will have an
>> Erlang system running. What already works is
>> a yielding engine in the Browser.
>>
>> Non-Blocking Browser for Dogelog Player
>> https://twitter.com/dogelogch/status/1489350992793677827
>>
>> Non-Blocking Browser for Dogelog Player
>> https://www.facebook.com/groups/dogelog
>>
>> With video recording and funky background
>> sound! Next will be bring this yielding engine
>> node.js and to Python as well.

Since idiotic Tau Prolog is horsing around:
https://github.com/tau-prolog/tau-prolog/issues/291

Here my response:

Thats not what Erlang did. In Erlang there was a counter and long
running actors were automatically yielded. You can lookup the
Erlang documentation if you don't believe me.

Your suggestions from using sleep/1 to the other suggestion to
pressing enter in the top-level are ridiculous, you seem not to
understand what a yielding engine is.

Maybe hold back your nonsense suggestion and only respond
when you have a solution, or when a solution is dismissed for
some reasons. But I don't know why a yielding engine should

be imposible? I just had a look at your source code, especially
your async protocol with return true and again(). Quite impressive
and relatively simple solution. Maybe because catch/3 creates

another thread via new Thread() ? I don't know what the technical
issue is that after all these years a yielding engine isn't available?

Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 15:06:16 UTC+1:
> Maybe I should show a spinning wheel or
> something, while the thingy runs? The color
> change in the button is nearly not seen...
>
> Mostowski Collapse schrieb:
> > It will take some time until I have an Erlang system.
> > The small things use a lot of time. Now I have
> > an non-async/await Sandbox and a async/await Sandbox
> >
> > online. The Audio Player example allows playing with
> > the async/await Sandbox. The Audio Example will
> > disable the Tryit button and enable it again, when finished.
> >
> > But its non-blocking, you can interact with the browser,
> > and it will not show the warning display in Chrome. Unfortunately
> > there is still an unsolved problem, the LIPS go down.
> >
> > But this here works fine:
> >
> > longrunning :-
> > between(1,300,_),
> > between(1,300,_),
> > between(1,300,_),
> > fail.
> > longrunning.
> >
> > ?- time(longrunning).
> > % Wall 37203 ms, gc 25 ms, 2206445 lips
> > true.
> >
> > http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example03/package.html
> >
> > The LIPS go down because setTimeout() is clamped by 4ms in
> > the browser, and I do ca. 60x per Second setTimeout(). To give the
> > browser the opportunity to do his own stuff.
> >
> > Mostowski Collapse schrieb am Freitag, 4. Februar 2022 um 12:18:50 UTC+1:
> >> If I dont stop now, in a few days I will have an
> >> Erlang system running. What already works is
> >> a yielding engine in the Browser.
> >>
> >> Non-Blocking Browser for Dogelog Player
> >> https://twitter.com/dogelogch/status/1489350992793677827
> >>
> >> Non-Blocking Browser for Dogelog Player
> >> https://www.facebook.com/groups/dogelog
> >>
> >> With video recording and funky background
> >> sound! Next will be bring this yielding engine
> >> node.js and to Python as well.

Again, whats so difficult in providing a yielding engine?

One can make it configurable, shouldn't be a problem for
somebody with that programming skills.

I have it easily switchable on and off:

/* Switch yielding engine on */
set_gc_flags(gc_flags | GC_MASK_ASYNC);

Maybe its some mental blockage?

Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1:
> Since idiotic Tau Prolog is horsing around:
> https://github.com/tau-prolog/tau-prolog/issues/291
>
> Here my response:
>
> Thats not what Erlang did. In Erlang there was a counter and long
> running actors were automatically yielded. You can lookup the
> Erlang documentation if you don't believe me.
>
> Your suggestions from using sleep/1 to the other suggestion to
> pressing enter in the top-level are ridiculous, you seem not to
> understand what a yielding engine is.
>
> Maybe hold back your nonsense suggestion and only respond
> when you have a solution, or when a solution is dismissed for
> some reasons. But I don't know why a yielding engine should
>
> be imposible? I just had a look at your source code, especially
> your async protocol with return true and again(). Quite impressive
> and relatively simple solution. Maybe because catch/3 creates
>
> another thread via new Thread() ? I don't know what the technical
> issue is that after all these years a yielding engine isn't available?

The next step is make it cancellable. So you would have
maybe some way in the GUI to cancel an engine. But this
would be most effective if it is combined with AbortController

stuff from node.js. Not sure what the browser offers.
Did not yet work on this. But since in a non-blocking sandbox
the GUI remains responsive, you can have a GUI control

similar to Ctrl-C that one is used from SWI-Prolog.

Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1:
> Again, whats so difficult in providing a yielding engine?
>
> One can make it configurable, shouldn't be a problem for
> somebody with that programming skills.
>
> I have it easily switchable on and off:
>
> /* Switch yielding engine on */
> set_gc_flags(gc_flags | GC_MASK_ASYNC);
>
> Maybe its some mental blockage?
> Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1:
> > Since idiotic Tau Prolog is horsing around:
> > https://github.com/tau-prolog/tau-prolog/issues/291
> >
> > Here my response:
> >
> > Thats not what Erlang did. In Erlang there was a counter and long
> > running actors were automatically yielded. You can lookup the
> > Erlang documentation if you don't believe me.
> >
> > Your suggestions from using sleep/1 to the other suggestion to
> > pressing enter in the top-level are ridiculous, you seem not to
> > understand what a yielding engine is.
> >
> > Maybe hold back your nonsense suggestion and only respond
> > when you have a solution, or when a solution is dismissed for
> > some reasons. But I don't know why a yielding engine should
> >
> > be imposible? I just had a look at your source code, especially
> > your async protocol with return true and again(). Quite impressive
> > and relatively simple solution. Maybe because catch/3 creates
> >
> > another thread via new Thread() ? I don't know what the technical
> > issue is that after all these years a yielding engine isn't available?

So maybe lets start all-over and read my question in the
ticket again. How do your answers respond to my question:
> Is there another sandbox already online?

I don't want to change my Prolog code.
And I don't want to code a sandbox in JavaScript.

I understand that on the other hand it seems a yielding
engine is already there, by for example hooking into
the limit callback for example. But I don't find it

somewhere already wrapped into a sandbox. Or
maybe there is some other URL out in the wild?

Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:42:03 UTC+1:
> The next step is make it cancellable. So you would have
> maybe some way in the GUI to cancel an engine. But this
> would be most effective if it is combined with AbortController
>
> stuff from node.js. Not sure what the browser offers.
> Did not yet work on this. But since in a non-blocking sandbox
> the GUI remains responsive, you can have a GUI control
>
> similar to Ctrl-C that one is used from SWI-Prolog.
> Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1:
> > Again, whats so difficult in providing a yielding engine?
> >
> > One can make it configurable, shouldn't be a problem for
> > somebody with that programming skills.
> >
> > I have it easily switchable on and off:
> >
> > /* Switch yielding engine on */
> > set_gc_flags(gc_flags | GC_MASK_ASYNC);
> >
> > Maybe its some mental blockage?
> > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1:
> > > Since idiotic Tau Prolog is horsing around:
> > > https://github.com/tau-prolog/tau-prolog/issues/291
> > >
> > > Here my response:
> > >
> > > Thats not what Erlang did. In Erlang there was a counter and long
> > > running actors were automatically yielded. You can lookup the
> > > Erlang documentation if you don't believe me.
> > >
> > > Your suggestions from using sleep/1 to the other suggestion to
> > > pressing enter in the top-level are ridiculous, you seem not to
> > > understand what a yielding engine is.
> > >
> > > Maybe hold back your nonsense suggestion and only respond
> > > when you have a solution, or when a solution is dismissed for
> > > some reasons. But I don't know why a yielding engine should
> > >
> > > be imposible? I just had a look at your source code, especially
> > > your async protocol with return true and again(). Quite impressive
> > > and relatively simple solution. Maybe because catch/3 creates
> > >
> > > another thread via new Thread() ? I don't know what the technical
> > > issue is that after all these years a yielding engine isn't available?

Woa! That was quick, there is now a stop option:
https://github.com/tau-prolog/sandbox/issues/10

I always admire Steve Jobs, how he introduced the MacIntosh
with a mouse that only had one button. Those times there were
mouses with 3 buttons.

So currently trying to figure out what a good GUI would be.
I cannot speak for Tau Prolog. But in my system Limit is a
system resource, that the end-user has nothing

to do with. It is planned that for non-blocking via some
auto-tuning the optimal value is found. Browsers have
a certain affinity to 60 frames per second.(*)

Not yet sure how this turns out. For the control buttons,
I am rather think of something else. Don't know yet what.
Was just having a look at SWISH,

it shows me an animation and an abort button. Maybe
thats where I got the animation idea from. after a while
it shows stats. the abort button shows again after redo.

(*)
I found some docu about that. A browser might also updrade
or downgrade the frequency. There is also something related
to animation, called requestAnimationFrame(), but this is

probably not needed for DOM updates.

Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:48:36 UTC+1:
> So maybe lets start all-over and read my question in the
> ticket again. How do your answers respond to my question:
> > Is there another sandbox already online?
>
> I don't want to change my Prolog code.
> And I don't want to code a sandbox in JavaScript.
>
> I understand that on the other hand it seems a yielding
> engine is already there, by for example hooking into
> the limit callback for example. But I don't find it
>
> somewhere already wrapped into a sandbox. Or
> maybe there is some other URL out in the wild?
> Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:42:03 UTC+1:
> > The next step is make it cancellable. So you would have
> > maybe some way in the GUI to cancel an engine. But this
> > would be most effective if it is combined with AbortController
> >
> > stuff from node.js. Not sure what the browser offers.
> > Did not yet work on this. But since in a non-blocking sandbox
> > the GUI remains responsive, you can have a GUI control
> >
> > similar to Ctrl-C that one is used from SWI-Prolog.
> > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:35:58 UTC+1:
> > > Again, whats so difficult in providing a yielding engine?
> > >
> > > One can make it configurable, shouldn't be a problem for
> > > somebody with that programming skills.
> > >
> > > I have it easily switchable on and off:
> > >
> > > /* Switch yielding engine on */
> > > set_gc_flags(gc_flags | GC_MASK_ASYNC);
> > >
> > > Maybe its some mental blockage?
> > > Mostowski Collapse schrieb am Dienstag, 8. Februar 2022 um 22:23:17 UTC+1:
> > > > Since idiotic Tau Prolog is horsing around:
> > > > https://github.com/tau-prolog/tau-prolog/issues/291
> > > >
> > > > Here my response:
> > > >
> > > > Thats not what Erlang did. In Erlang there was a counter and long
> > > > running actors were automatically yielded. You can lookup the
> > > > Erlang documentation if you don't believe me.
> > > >
> > > > Your suggestions from using sleep/1 to the other suggestion to
> > > > pressing enter in the top-level are ridiculous, you seem not to
> > > > understand what a yielding engine is.
> > > >
> > > > Maybe hold back your nonsense suggestion and only respond
> > > > when you have a solution, or when a solution is dismissed for
> > > > some reasons. But I don't know why a yielding engine should
> > > >
> > > > be imposible? I just had a look at your source code, especially
> > > > your async protocol with return true and again(). Quite impressive
> > > > and relatively simple solution. Maybe because catch/3 creates
> > > >
> > > > another thread via new Thread() ? I don't know what the technical
> > > > issue is that after all these years a yielding engine isn't available?

Does your browser stutter?
https://www.testufo.com/animation-time-graph

Mostowski Collapse schrieb am Mittwoch, 9. Februar 2022 um 01:17:13 UTC+1:
> Woa! That was quick, there is now a stop option:
> https://github.com/tau-prolog/sandbox/issues/10
>
> I always admire Steve Jobs, how he introduced the MacIntosh
> with a mouse that only had one button. Those times there were
> mouses with 3 buttons.
>
> So currently trying to figure out what a good GUI would be.
> I cannot speak for Tau Prolog. But in my system Limit is a
> system resource, that the end-user has nothing
>
> to do with. It is planned that for non-blocking via some
> auto-tuning the optimal value is found. Browsers have
> a certain affinity to 60 frames per second.(*)
>
> Not yet sure how this turns out. For the control buttons,
> I am rather think of something else. Don't know yet what.
> Was just having a look at SWISH,
>
> it shows me an animation and an abort button. Maybe
> thats where I got the animation idea from. after a while
> it shows stats. the abort button shows again after redo.
>
> (*)
> I found some docu about that. A browser might also updrade
> or downgrade the frequency. There is also something related
> to animation, called requestAnimationFrame(), but this is
>
> probably not needed for DOM updates.