Thanks to my testing sixth sense, the first Ciao Playground issue:
https://github.com/ciao-lang/ciao_playground/issues/1

I hope its not ending like Scryer Prolog, which has a wooping
223 open tickets, tendency is not yet that the number of open
tickets goes down.

My favorite formula for such an explosion of tickets is:

The Ticket Backlog Curve
https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3

So an initial explosion of tickets is linearly reduced.
Where in this curve is Scryer Prolog right now?

Mostowski Collapse schrieb am Freitag, 5. August 2022 um 10:19:46 UTC+2:
> It was two questions already, or a different question altogether,
> namely asking for WASM as well.
>
> Disclaimer: Oh my, I invented the word “asyncify” spontanously
> yesterday. But it has also some meaning in relation to WASM.
> My previous portraying is from experience with CheerpJ, Tau-
>
> Prolog and Dogelog, and only CheerpJ has WASM (the recent
> version using 64-bit). Maybe for more WASM specific questions
> you need to consult other source, I find for example:
>
> https://web.dev/asyncify/
>
> Possibly when the above community is talking about asyncification
> it has a total different meaning then what I described. Attention! Attention!
>
> Also CheerpJ comes without auto-yielding. You can add it
> yourself, by calling Java Thread.yield(), it was an undocumented
> feature of CheerpJ. But in CheerpJ I could not yield promises so
>
> easily, maybe there is an exotic Java API, and then there
> is a danger that CheerpJ doesn’t support it, since it is rather
> tailord towards bringing some convetional Swing/Standalone
>
> applications to the web, so this is a specific new feature of the
> Dogelog engine, breaking out of a particular Java world.
> Mostowski Collapse schrieb am Freitag, 5. August 2022 um 10:16:49 UTC+2:
> > Question was, what means syncify?
> >
> > It means that you turn your Prolog interpreter into an Engine
> > that can yield, but that you also have some auto-yielding.
> > So that the the browser or node.exe can process operating
> >
> > system tasks while the Prolog system is running. Basically the
> > JavaScript async/await is an extended iterator code rewriting
> > of a form of yield, which yields promises. If you take this path
> >
> > you would also need to extended the engine concept so that
> > you can voluntarily yield promises, like for example for a fetch.
> > In such a scenario the Prolog system might appear to block,
> >
> > this is the other illusion the asyncification can create. Basically
> > you can create the following illusions by asyncification
> > without the need of a pre-emptive scheduler:
> >
> > - Non-blocking parallelism between Prolog system and operating system
> > - Blocking wait for completion of some operating system tasks
> >
> > Optionally you can also use it for multiple Prolog threads, but
> > I don’t see a point in doing this. So I branded this “misuse”.
> > But you could do this as well and it has certainly some use
> >
> > cases if the multiple Prolog threads do a lot of operating
> > system tasks. But it is missing in the above list for the moment,
> > so conceptionally there are only “two” co-routines the single
> >
> > threaded Prolog system and the operating system tasks event
> > loop provided by the browser or node.exe. In the same way its
> > possible to make a Python variant of such an engine.
> > Mostowski Collapse schrieb am Freitag, 5. August 2022 um 03:01:16 UTC+2:
> > > Workers do still synchronously process message
> > > they receive. As a result Ciao cannot send an “abort”
> > > control to a worker, since Ciao Prolog itself inside
> > >
> > > the worker is not asyncified. As a result I see one
> > > Worker going down and another Worker comming
> > > up, when I press Abort button in Ciao, and the
> > >
> > > dynamic database state is gone. Bye Bye.
> > >
> > > BTW: As soon as you have asyncified your Prolog
> > > interpreter, you don't need the single worker anymore.
> > > Mostowski Collapse schrieb am Freitag, 5. August 2022 um 02:58:17 UTC+2:
> > > > Ciao Prologs “State of the Art” is rather the
> > > > night mare of “The Art of loosing State”.
> > > >
> > > > ?- assertz(foo).
> > > > yes
> > > >
> > > > ?- foo.
> > > > yes
> > > >
> > > > ?- repeat, fail.
> > > > { Execution aborted }
> > > >
> > > > ?- foo.
> > > > {ERROR: No handle found for thrown exception error(existence_error(procedure,'user:foo'/0),'user:foo'/0)}
> > > > aborted
> > > >
> > > > https://ciao-lang.org/playground/
> > > >
> > > > I hope SWI-Prolog will not blindly immitate
> > > > every nonsense from Ciao Prolog.

Many WASM projects now coming out of the closet. My expectation,
this is only a win win situation in the long run, but it might be
painful at the beginning.

For a stealth project, which wasn’t on GitHub from the beginning,
and which has some non-public tickets somewhere, its more
difficult to estimate the current standing from the outside.

For Scryer Prolog the struggle is minutely documented:

Compiling and running scryer as a WebAssembly binary?
https://github.com/mthom/scryer-prolog/issues/615

Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:07:29 UTC+2:
> Thanks to my testing sixth sense, the first Ciao Playground issue:
> https://github.com/ciao-lang/ciao_playground/issues/1
>
> I hope its not ending like Scryer Prolog, which has a wooping
> 223 open tickets, tendency is not yet that the number of open
> tickets goes down.
>
> My favorite formula for such an explosion of tickets is:
>
> The Ticket Backlog Curve
> https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
>
> So an initial explosion of tickets is linearly reduced.
> Where in this curve is Scryer Prolog right now?

How it started:

Somebody wrote yesterday:
"For anyone finding this project interesting, we kindly as
everyone to try and explore our system, file issue reports,
contribute, and of course star our repository :wink: .

BTW, this reminds me that it is really a pity that we do
not have a common Prolog forum to discuss, like in the old days.
Newsgroups do not work, and a “single system”

discourse group is not a solution."

How its going:

A few hours ago, when starting to make visible some
limitations, everything diverted in a blink from “hello
community” to “bilateralism”.

Somebody wrote today:
"I’m happy to have a discussion on exchanging code and
ideas between our projects. I think a telco is a better medium
for that than here. Just drop me a personal message."

Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:25:37 UTC+2:
> Many WASM projects now coming out of the closet. My expectation,
> this is only a win win situation in the long run, but it might be
> painful at the beginning.
>
> For a stealth project, which wasn’t on GitHub from the beginning,
> and which has some non-public tickets somewhere, its more
> difficult to estimate the current standing from the outside.
>
> For Scryer Prolog the struggle is minutely documented:
>
> Compiling and running scryer as a WebAssembly binary?
> https://github.com/mthom/scryer-prolog/issues/615
> Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:07:29 UTC+2:
> > Thanks to my testing sixth sense, the first Ciao Playground issue:
> > https://github.com/ciao-lang/ciao_playground/issues/1
> >
> > I hope its not ending like Scryer Prolog, which has a wooping
> > 223 open tickets, tendency is not yet that the number of open
> > tickets goes down.
> >
> > My favorite formula for such an explosion of tickets is:
> >
> > The Ticket Backlog Curve
> > https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
> >
> > So an initial explosion of tickets is linearly reduced.
> > Where in this curve is Scryer Prolog right now?

Anyway, I have an admin questions, so playground tickets
don’t go into the Ciao Playground repo but into the Ciao repo?
Historically Bilateralism does not have a good Reputation

"The first rejection of bilateralism came after the First World War
when many politicians concluded that the complex pre-war
system of bilateral treaties had made war inevitable."
https://en.wikipedia.org/wiki/Bilateralism#History

So we might see some Prolog Web API wars in the near future?
Because of some coalition formation between SWI-Prolog and
Ciao Prolog? And then them against the rest of the Prolog world?

Mostowski Collapse schrieb am Freitag, 5. August 2022 um 16:56:06 UTC+2:
> How it started:
>
> Somebody wrote yesterday:
> "For anyone finding this project interesting, we kindly as
> everyone to try and explore our system, file issue reports,
> contribute, and of course star our repository :wink: .
>
> BTW, this reminds me that it is really a pity that we do
> not have a common Prolog forum to discuss, like in the old days.
> Newsgroups do not work, and a “single system”
>
> discourse group is not a solution."
>
> How its going:
>
> A few hours ago, when starting to make visible some
> limitations, everything diverted in a blink from “hello
> community” to “bilateralism”.
>
> Somebody wrote today:
> "I’m happy to have a discussion on exchanging code and
> ideas between our projects. I think a telco is a better medium
> for that than here. Just drop me a personal message."
> Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:25:37 UTC+2:
> > Many WASM projects now coming out of the closet. My expectation,
> > this is only a win win situation in the long run, but it might be
> > painful at the beginning.
> >
> > For a stealth project, which wasn’t on GitHub from the beginning,
> > and which has some non-public tickets somewhere, its more
> > difficult to estimate the current standing from the outside.
> >
> > For Scryer Prolog the struggle is minutely documented:
> >
> > Compiling and running scryer as a WebAssembly binary?
> > https://github.com/mthom/scryer-prolog/issues/615
> > Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:07:29 UTC+2:
> > > Thanks to my testing sixth sense, the first Ciao Playground issue:
> > > https://github.com/ciao-lang/ciao_playground/issues/1
> > >
> > > I hope its not ending like Scryer Prolog, which has a wooping
> > > 223 open tickets, tendency is not yet that the number of open
> > > tickets goes down.
> > >
> > > My favorite formula for such an explosion of tickets is:
> > >
> > > The Ticket Backlog Curve
> > > https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
> > >
> > > So an initial explosion of tickets is linearly reduced.
> > > Where in this curve is Scryer Prolog right now?

So for how long should we buy popcorn? How long will
this Prolog Web API wars last, months to years?

LoL

Thats actually the most astonishing und upredictable
thing here, the time scale. Can the unknown be planned?
Is a late adopter in a more advantageous position. What

if his system, like for example SWI-Prolog, is rather larger
Prolog system, organically grown for certain target systems,
and also moved away over the past from the

small ISO core standard.

Mostowski Collapse schrieb am Freitag, 5. August 2022 um 16:56:57 UTC+2:
> Anyway, I have an admin questions, so playground tickets
> don’t go into the Ciao Playground repo but into the Ciao repo?
> Historically Bilateralism does not have a good Reputation
>
> "The first rejection of bilateralism came after the First World War
> when many politicians concluded that the complex pre-war
> system of bilateral treaties had made war inevitable."
> https://en.wikipedia.org/wiki/Bilateralism#History
>
> So we might see some Prolog Web API wars in the near future?
> Because of some coalition formation between SWI-Prolog and
> Ciao Prolog? And then them against the rest of the Prolog world?
> Mostowski Collapse schrieb am Freitag, 5. August 2022 um 16:56:06 UTC+2:
> > How it started:
> >
> > Somebody wrote yesterday:
> > "For anyone finding this project interesting, we kindly as
> > everyone to try and explore our system, file issue reports,
> > contribute, and of course star our repository :wink: .
> >
> > BTW, this reminds me that it is really a pity that we do
> > not have a common Prolog forum to discuss, like in the old days.
> > Newsgroups do not work, and a “single system”
> >
> > discourse group is not a solution."
> >
> > How its going:
> >
> > A few hours ago, when starting to make visible some
> > limitations, everything diverted in a blink from “hello
> > community” to “bilateralism”.
> >
> > Somebody wrote today:
> > "I’m happy to have a discussion on exchanging code and
> > ideas between our projects. I think a telco is a better medium
> > for that than here. Just drop me a personal message."
> > Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:25:37 UTC+2:
> > > Many WASM projects now coming out of the closet. My expectation,
> > > this is only a win win situation in the long run, but it might be
> > > painful at the beginning.
> > >
> > > For a stealth project, which wasn’t on GitHub from the beginning,
> > > and which has some non-public tickets somewhere, its more
> > > difficult to estimate the current standing from the outside.
> > >
> > > For Scryer Prolog the struggle is minutely documented:
> > >
> > > Compiling and running scryer as a WebAssembly binary?
> > > https://github.com/mthom/scryer-prolog/issues/615
> > > Mostowski Collapse schrieb am Freitag, 5. August 2022 um 13:07:29 UTC+2:
> > > > Thanks to my testing sixth sense, the first Ciao Playground issue:
> > > > https://github.com/ciao-lang/ciao_playground/issues/1
> > > >
> > > > I hope its not ending like Scryer Prolog, which has a wooping
> > > > 223 open tickets, tendency is not yet that the number of open
> > > > tickets goes down.
> > > >
> > > > My favorite formula for such an explosion of tickets is:
> > > >
> > > > The Ticket Backlog Curve
> > > > https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
> > > >
> > > > So an initial explosion of tickets is linearly reduced.
> > > > Where in this curve is Scryer Prolog right now?

I have bad news for Ciao Prolog concerning:

Just in case it is useful, we published this paper back in
2012 about translation of Prolog to JS. We had some
libraries to interact with the DOM and JS and some
kind of JS foreign interface:
[1210.2864] Lightweight compilation of (C)LP to JavaScript
https://arxiv.org/abs/1210.2864

Its not extremly relevant, since the presented Ciao JS is not asyncified.
For example if I go to this page, I do not find that it is asyncified:

8-Queens Demo
http://cliplab.org/~jfran/ptojs/queens_ui/queens_ui.html

It doesn’t count as a prior art of an asyncified Prolog system.
asyncified Prolog systems basically started with Tau-Prolog
to some extend, they use a kind of continuation style asyncification.

The milestone was when they started demonstrating some
async task stuff a few years ago.

But meanwhile Tau Prolog has evolved and now also
provide a modern async/await interface, similar like
Dogelog player has since a few months. So you

can now use Tau Prolog without ugly Promise chains
and with elegant async/await. At least I find
something like this now documented here:

Promises interface
http://tau-prolog.org/manual/promises-interface

But they do not 100% follow the naming convention for async
functions. I also do not 100% follow the naming convention.
In Dogelog I use async_XXX and Tau Prolog uses promiseXXX,

but according to this web article the naming convention would be XXXAsync:

JavaScript Method Naming Convention for Async Functions
https://blog.8bitzen.com/posts/13-06-2019-javascript-method-naming-convention-for-async-functions

Mostowski Collapse schrieb am Samstag, 6. August 2022 um 21:45:44 UTC+2:
> I have bad news for Ciao Prolog concerning:
>
> Just in case it is useful, we published this paper back in
> 2012 about translation of Prolog to JS. We had some
> libraries to interact with the DOM and JS and some
> kind of JS foreign interface:
> [1210.2864] Lightweight compilation of (C)LP to JavaScript
> https://arxiv.org/abs/1210.2864
>
> Its not extremly relevant, since the presented Ciao JS is not asyncified.
> For example if I go to this page, I do not find that it is asyncified:
>
> 8-Queens Demo
> http://cliplab.org/~jfran/ptojs/queens_ui/queens_ui.html
>
> It doesn’t count as a prior art of an asyncified Prolog system.
> asyncified Prolog systems basically started with Tau-Prolog
> to some extend, they use a kind of continuation style asyncification.
>
> The milestone was when they started demonstrating some
> async task stuff a few years ago.

Maybe one can build an asyncified SWI-Prolog WASM
around eyebrow. The code currently contains
Promise chains:

fetch('https://josd.github.io/eye/eye.pl')
.then(response => response.text())
.then(data => (Module.FS.writeFile('/eye.pl', data)));
https://github.com/josd/eyebrow/blob/master/socrates.html

But in principle the SWI-Prolog WASM should have a
consult, and could intiate this fetch by itself, by suspending
with the new js_yield/2 or a variant of it. So the page is

not 100% asyncified, since the SWI-Prolog WASM itself
is not yet asyncified. BTW: There would be another style
to asyncify the above fetch, instead as an old style

How to use the Fetch API with async/await
https://rapidapi.com/guides/fetch-api-async-await

Promise chain, it could be also realized with the newer style
async/await above. Brainwriting here helps me develop the
same for Dogelog, which is asyncified but has still

some synchronous parts.

If the eyebrow SWI-Prolog WASM were 100% asyncified,
by the new style async/await or by the old style
Promise chains, then we would not see:

var SWIPL = (() => {

But rather this here in the new style:

var SWIPL = (async() => {

But I am not 100% sure how to asyncify it. Currently it
creates a promise, but this is rather pointless, since
the .then((module) => is only called once, I suspect.

But an asyncified SWI-Prolog WASM would resume again
and again, realize a await promise loop. It has also some
custom rolled async support, like for example addRunDependency

and removeRunDependency, not sure what it is doing, in
connection with asyncLoad().

Mostowski Collapse schrieb am Sonntag, 7. August 2022 um 14:24:49 UTC+2:
> Maybe one can build an asyncified SWI-Prolog WASM
> around eyebrow. The code currently contains
> Promise chains:
>
> fetch('https://josd.github.io/eye/eye.pl')
> .then(response => response.text())
> .then(data => (Module.FS.writeFile('/eye.pl', data)));
> https://github.com/josd/eyebrow/blob/master/socrates.html
>
> But in principle the SWI-Prolog WASM should have a
> consult, and could intiate this fetch by itself, by suspending
> with the new js_yield/2 or a variant of it. So the page is
>
> not 100% asyncified, since the SWI-Prolog WASM itself
> is not yet asyncified. BTW: There would be another style
> to asyncify the above fetch, instead as an old style
>
> How to use the Fetch API with async/await
> https://rapidapi.com/guides/fetch-api-async-await
>
> Promise chain, it could be also realized with the newer style
> async/await above. Brainwriting here helps me develop the
> same for Dogelog, which is asyncified but has still
>
> some synchronous parts.

Corr.:
var is also deprecated nowadays

let SWIPL = (async() => {

Mostowski Collapse schrieb am Sonntag, 7. August 2022 um 14:26:25 UTC+2:
> If the eyebrow SWI-Prolog WASM were 100% asyncified,
> by the new style async/await or by the old style
> Promise chains, then we would not see:
>
> var SWIPL = (() => {
>
> But rather this here in the new style:
>
> var SWIPL = (async() => {
>
> But I am not 100% sure how to asyncify it. Currently it
> creates a promise, but this is rather pointless, since
> the .then((module) => is only called once, I suspect.
>
> But an asyncified SWI-Prolog WASM would resume again
> and again, realize a await promise loop. It has also some
> custom rolled async support, like for example addRunDependency
>
> and removeRunDependency, not sure what it is doing, in
> connection with asyncLoad().
> Mostowski Collapse schrieb am Sonntag, 7. August 2022 um 14:24:49 UTC+2:
> > Maybe one can build an asyncified SWI-Prolog WASM
> > around eyebrow. The code currently contains
> > Promise chains:
> >
> > fetch('https://josd.github.io/eye/eye.pl')
> > .then(response => response.text())
> > .then(data => (Module.FS.writeFile('/eye.pl', data)));
> > https://github.com/josd/eyebrow/blob/master/socrates.html
> >
> > But in principle the SWI-Prolog WASM should have a
> > consult, and could intiate this fetch by itself, by suspending
> > with the new js_yield/2 or a variant of it. So the page is
> >
> > not 100% asyncified, since the SWI-Prolog WASM itself
> > is not yet asyncified. BTW: There would be another style
> > to asyncify the above fetch, instead as an old style
> >
> > How to use the Fetch API with async/await
> > https://rapidapi.com/guides/fetch-api-async-await
> >
> > Promise chain, it could be also realized with the newer style
> > async/await above. Brainwriting here helps me develop the
> > same for Dogelog, which is asyncified but has still
> >
> > some synchronous parts.

I am just writing down what comes to my mind.
For example when I read this here:

Reverse the burden of proof
http://josd.github.io/Talks/2022/06welding/#(7)

Then I think this is a too narrow view what
Jan Wielemaker work could do. Although I have
no clue how much work it is for SWI-Prolog and
where SWI-Prolog is going. But basically:

- Yielding plus asyncify can be also used on
the server and headless mode, via nodejs, its
not restricted to the client and the browser. (Works in Dogelog so far)
https://nodejs.org/en/

- Yielding plus asyncify can be also done for
Python, and some other languages, Python
even has the new async/await as well. (Works in Dogelog so far)

- Its an age old technique, practically every operating
system has coroutine rings inside threads

- In the Java world its usually called fibers

- It is what allowed Erlang to have millions of actors

In the broader view you can use it for peer to peer
communication between servers as well, like some
blockchain confirmation counts etc…

And the peer can be even a browser client, but you
need to change the same-origin credentials I guess.

Disclaimer: Somebody from the industry could
surely talk more competently about it. Like somebody
from https://tokio.rs/ ?

Some results of a 48 hour SWIPL WASM Hackathon?
https://dev.swi-prolog.org/wasm/shell

?- assertz(foo).
true.

?- foo.
true.

?- repeat, fail.
ERROR: Execution Aborted
?- foo.
true.

ultimately superior to some polished academic papers,
that need 3 years from inception to publication

LoL

(Possibly also a nice display of continuous integration (CI) and
continuous deployment (CD). For example the WASM thingy.)

Mostowski Collapse schrieb am Dienstag, 9. August 2022 um 00:07:47 UTC+2:
> Some results of a 48 hour SWIPL WASM Hackathon?
> https://dev.swi-prolog.org/wasm/shell
>
> ?- assertz(foo).
> true.
>
> ?- foo.
> true.
>
> ?- repeat, fail.
> ERROR: Execution Aborted
> ?- foo.
> true.
>
> ultimately superior to some polished academic papers,
> that need 3 years from inception to publication
>
> LoL

When I write something I mean it dead serious, including

“The proof is in the pudding. Prove it!”.

I know that SWI-Prolog and some other Prolog systems
started in 1980’s. Which would give 40 years accumulated work.
My personal feeling about the web problem is that I am still in

my baby pampers. Although there was some quick progress,
possibly the progress will now slow down. I could like list 1’000
unresolved challenges I am facing right now. For example

the abort problem is related to the implementation of concurrent_and/2
via workers, if you want the concurrent_and/2 make gracefully
abortable itself and handing the abort gracefully to its slave

workers. etc… etc… Maybe Ciao Prolog has already a solution?
Doing a worker is not so difficult. But I got the idee fix, that it should
have many features of Prolog threads, including thread_signal/2.

Cooperative multitasking is not for the faint-hearted.
Quickly a mountain of unsolved problems appears,
which is much easier to solve with real multi-threading.

But who knows, maybe just wait and do nothing. I am just reading,
looks pretty similar to Java bytecode and Java applets from 1995 back then:
(BTW Java applets could already do true multi threading,
but the integration with JavaScript through LiveScript was horrible):

"Its initial aim is to support compilation from C and C++,
though support for other source languages such as Rust,
..NET languages] and AssemblyScript (TypeScript-like) is
also emerging. After the MVP release, there are plans to
support multithreading and garbage collection which would
make WebAssembly a compilation target for garbage-collected
programming languages like C# (supported via Blazor),
F# (supported via Bolero with help of Blazor), Python, and
even JavaScript where the browser’s just-in-time compilation
speed is considered too slow. A number of other languages
have some support including Python, Java, Julia, and Ruby.
https://en.wikipedia.org/wiki/WebAssembly#Compilers

Which confirms Greenspuns 13. Amendment:
“Every environment morphs into a Java runtime sooner or later.”
But the new trend has possibly a more positive spin on it,
deliberating the technology both from Oracle and Microsoft?

Mostowski Collapse schrieb am Dienstag, 9. August 2022 um 12:23:32 UTC+2:
> When I write something I mean it dead serious, including
>
> “The proof is in the pudding. Prove it!”.
>
> I know that SWI-Prolog and some other Prolog systems
> started in 1980’s. Which would give 40 years accumulated work.
> My personal feeling about the web problem is that I am still in
>
> my baby pampers. Although there was some quick progress,
> possibly the progress will now slow down. I could like list 1’000
> unresolved challenges I am facing right now. For example
>
> the abort problem is related to the implementation of concurrent_and/2
> via workers, if you want the concurrent_and/2 make gracefully
> abortable itself and handing the abort gracefully to its slave
>
> workers. etc… etc… Maybe Ciao Prolog has already a solution?
> Doing a worker is not so difficult. But I got the idee fix, that it should
> have many features of Prolog threads, including thread_signal/2.

This never gets old, the article starts with:

“The Stop Microsoft Corp bandwaggon is gathering pace, and
Netscape Communications Corp and Sun Microsystems Inc have
pooled their resources to create JavaScript, which combines Sun’s
Java and Netscape’s LiveScript.”
- December 5, 1995
https://techmonitor.ai/technology/sun_java_netscape_livescript_married_as_javascript

Who stops whom nowadays from what by what?

Mostowski Collapse schrieb am Dienstag, 9. August 2022 um 21:27:27 UTC+2:
> Cooperative multitasking is not for the faint-hearted.
> Quickly a mountain of unsolved problems appears,
> which is much easier to solve with real multi-threading.
>
> But who knows, maybe just wait and do nothing. I am just reading,
> looks pretty similar to Java bytecode and Java applets from 1995 back then:
> (BTW Java applets could already do true multi threading,
> but the integration with JavaScript through LiveScript was horrible):
>
> "Its initial aim is to support compilation from C and C++,
> though support for other source languages such as Rust,
> .NET languages] and AssemblyScript (TypeScript-like) is
> also emerging. After the MVP release, there are plans to
> support multithreading and garbage collection which would
> make WebAssembly a compilation target for garbage-collected
> programming languages like C# (supported via Blazor),
> F# (supported via Bolero with help of Blazor), Python, and
> even JavaScript where the browser’s just-in-time compilation
> speed is considered too slow. A number of other languages
> have some support including Python, Java, Julia, and Ruby.
> https://en.wikipedia.org/wiki/WebAssembly#Compilers
>
> Which confirms Greenspuns 13. Amendment:
> “Every environment morphs into a Java runtime sooner or later.”
> But the new trend has possibly a more positive spin on it,
> deliberating the technology both from Oracle and Microsoft?
> Mostowski Collapse schrieb am Dienstag, 9. August 2022 um 12:23:32 UTC+2:
> > When I write something I mean it dead serious, including
> >
> > “The proof is in the pudding. Prove it!”.
> >
> > I know that SWI-Prolog and some other Prolog systems
> > started in 1980’s. Which would give 40 years accumulated work.
> > My personal feeling about the web problem is that I am still in
> >
> > my baby pampers. Although there was some quick progress,
> > possibly the progress will now slow down. I could like list 1’000
> > unresolved challenges I am facing right now. For example
> >
> > the abort problem is related to the implementation of concurrent_and/2
> > via workers, if you want the concurrent_and/2 make gracefully
> > abortable itself and handing the abort gracefully to its slave
> >
> > workers. etc… etc… Maybe Ciao Prolog has already a solution?
> > Doing a worker is not so difficult. But I got the idee fix, that it should
> > have many features of Prolog threads, including thread_signal/2.

Somebody wrote, deliberatively taken out of context here:

"All good ideas of academic systems are adopted by industrial
ones, which is really awesome, but unfortunately the origin of
those ideas is often lost."

When its only about vanity, I don’t see any practical use of PEPs.
Before you can write a PEP, you have to have something working.
I am very impressed by the recent SWI-Prolog WASM Hackathon.

An alternative name for Hackathon could be Mob Programming:

Mob Programming and the Power of Flow - Woody Zuill, 2019
https://www.youtube.com/watch?v=28S4CVkYhWA

Interestingly Woody Zuill supports my idea of ticketless development,
he says somewhere to the point of “no inventory”. I have switched in
Dogelog to ticketless development. I think Scryer Prolog and maybe other

Prolog systems suffer from a big backlog on GitHub issues. Everytime I
watch Scryer Prolog GitHub issues, their number has increased.
Probably their is only 1 Developer and 10 Advisors, creating noise.

Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:13:12 UTC+2:
> Somebody wrote, deliberatively taken out of context here:
>
> "All good ideas of academic systems are adopted by industrial
> ones, which is really awesome, but unfortunately the origin of
> those ideas is often lost."
>
> When its only about vanity, I don’t see any practical use of PEPs..
> Before you can write a PEP, you have to have something working.
> I am very impressed by the recent SWI-Prolog WASM Hackathon.
>
> An alternative name for Hackathon could be Mob Programming:
>
> Mob Programming and the Power of Flow - Woody Zuill, 2019
> https://www.youtube.com/watch?v=28S4CVkYhWA

Where is Scryer Prolog on this curve now?

Ticket Explosion and Reduction over Time
https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3

I see 54 Open Tickets by UWN, thats around 25% of the Tickets
I see 51 Open Tickets by triska, thats also around 25% of the Tickets

Should rename Scryer Prolog to Troll Prolog. I had contact
with a Logician recently trying to port fCube by Ferrari, Fiorentini
and Fiorino to Scryer Prolog. But Scryer Prolog crashed,

exact same code worked in Dogelog. I then adviced the Logician
to make Ticket. He refused to do so, he told me that he rather not
use Scryer Prolog for the moment. Its not me who thinks these

Tickets and the behaviour of some People is repellant.

Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:41:55 UTC+2:
> Interestingly Woody Zuill supports my idea of ticketless development,
> he says somewhere to the point of “no inventory”. I have switched in
> Dogelog to ticketless development. I think Scryer Prolog and maybe other
>
> Prolog systems suffer from a big backlog on GitHub issues. Everytime I
> watch Scryer Prolog GitHub issues, their number has increased.
> Probably their is only 1 Developer and 10 Advisors, creating noise.
> Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:13:12 UTC+2:
> > Somebody wrote, deliberatively taken out of context here:
> >
> > "All good ideas of academic systems are adopted by industrial
> > ones, which is really awesome, but unfortunately the origin of
> > those ideas is often lost."
> >
> > When its only about vanity, I don’t see any practical use of PEPs.
> > Before you can write a PEP, you have to have something working.
> > I am very impressed by the recent SWI-Prolog WASM Hackathon.
> >
> > An alternative name for Hackathon could be Mob Programming:
> >
> > Mob Programming and the Power of Flow - Woody Zuill, 2019
> > https://www.youtube.com/watch?v=28S4CVkYhWA

Now I have blocked Ulrich Neumerkel and Markus Triska.
My original plan was to not block any people anymore
on GitHub. But they are full of nonsense.

Here is an example of some gibberisch:

> More properties are preserved in application code, the easier it is to
reason about the code, also via automated reasoning. [...] Using (==)/2
prevents such optimization, and (=)/2.
https://github.com/mthom/scryer-prolog/pull/468#issuecomment-625388237

Here is my response to the uninformed pestillence:

Why would it prevent such optimizations?
For example if you index on the main functor you can apply the
same indexing for (==)/2 and (=)/2, thats implemented in Jekejeke Prolog.

See for yourself:
http://pages.xlog.ch/srctab/doclet/docs/05_run/common/jekpro/model/rope/IndexFront.html

Its not a code transformation indexing, but indexing is possible.

Mostowski Collapse schrieb am Samstag, 13. August 2022 um 14:19:23 UTC+2:
> Where is Scryer Prolog on this curve now?
>
> Ticket Explosion and Reduction over Time
> https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
>
> I see 54 Open Tickets by UWN, thats around 25% of the Tickets
> I see 51 Open Tickets by triska, thats also around 25% of the Tickets
>
> Should rename Scryer Prolog to Troll Prolog. I had contact
> with a Logician recently trying to port fCube by Ferrari, Fiorentini
> and Fiorino to Scryer Prolog. But Scryer Prolog crashed,
>
> exact same code worked in Dogelog. I then adviced the Logician
> to make Ticket. He refused to do so, he told me that he rather not
> use Scryer Prolog for the moment. Its not me who thinks these
>
> Tickets and the behaviour of some People is repellant.
> Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:41:55 UTC+2:
> > Interestingly Woody Zuill supports my idea of ticketless development,
> > he says somewhere to the point of “no inventory”. I have switched in
> > Dogelog to ticketless development. I think Scryer Prolog and maybe other
> >
> > Prolog systems suffer from a big backlog on GitHub issues. Everytime I
> > watch Scryer Prolog GitHub issues, their number has increased.
> > Probably their is only 1 Developer and 10 Advisors, creating noise.
> > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:13:12 UTC+2:
> > > Somebody wrote, deliberatively taken out of context here:
> > >
> > > "All good ideas of academic systems are adopted by industrial
> > > ones, which is really awesome, but unfortunately the origin of
> > > those ideas is often lost."
> > >
> > > When its only about vanity, I don’t see any practical use of PEPs.
> > > Before you can write a PEP, you have to have something working.
> > > I am very impressed by the recent SWI-Prolog WASM Hackathon.
> > >
> > > An alternative name for Hackathon could be Mob Programming:
> > >
> > > Mob Programming and the Power of Flow - Woody Zuill, 2019
> > > https://www.youtube.com/watch?v=28S4CVkYhWA

Non-code transformation body guard indexing isn't any
secret. Is was for example documented here:

Demand-Driven Indexing of Prolog Clauses
Vıtor Santos Costa, Konstantinos Sagonas, and Ricardo Lopes
http://user.it.uu.se/~kostis/Papers/iclp07.pdf

SWI-Prolog made it also wrong, it now has a code
transformation for (=)/2 indexing:

?- [user].
p(X) :- X=a.

?- listing(p/1).
p(a).

Thats just nonsense as well. Does this say it cannot
index (==)/2, functor/3, etc..?

LoL

Mostowski Collapse schrieb am Samstag, 13. August 2022 um 16:20:40 UTC+2:
> Now I have blocked Ulrich Neumerkel and Markus Triska.
> My original plan was to not block any people anymore
> on GitHub. But they are full of nonsense.
>
> Here is an example of some gibberisch:
>
> > More properties are preserved in application code, the easier it is to
> reason about the code, also via automated reasoning. [...] Using (==)/2
> prevents such optimization, and (=)/2.
> https://github.com/mthom/scryer-prolog/pull/468#issuecomment-625388237
>
> Here is my response to the uninformed pestillence:
>
> Why would it prevent such optimizations?
> For example if you index on the main functor you can apply the
> same indexing for (==)/2 and (=)/2, thats implemented in Jekejeke Prolog.
>
> See for yourself:
> http://pages.xlog.ch/srctab/doclet/docs/05_run/common/jekpro/model/rope/IndexFront.html
>
> Its not a code transformation indexing, but indexing is possible.
> Mostowski Collapse schrieb am Samstag, 13. August 2022 um 14:19:23 UTC+2:
> > Where is Scryer Prolog on this curve now?
> >
> > Ticket Explosion and Reduction over Time
> > https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
> >
> > I see 54 Open Tickets by UWN, thats around 25% of the Tickets
> > I see 51 Open Tickets by triska, thats also around 25% of the Tickets
> >
> > Should rename Scryer Prolog to Troll Prolog. I had contact
> > with a Logician recently trying to port fCube by Ferrari, Fiorentini
> > and Fiorino to Scryer Prolog. But Scryer Prolog crashed,
> >
> > exact same code worked in Dogelog. I then adviced the Logician
> > to make Ticket. He refused to do so, he told me that he rather not
> > use Scryer Prolog for the moment. Its not me who thinks these
> >
> > Tickets and the behaviour of some People is repellant.
> > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:41:55 UTC+2:
> > > Interestingly Woody Zuill supports my idea of ticketless development,
> > > he says somewhere to the point of “no inventory”. I have switched in
> > > Dogelog to ticketless development. I think Scryer Prolog and maybe other
> > >
> > > Prolog systems suffer from a big backlog on GitHub issues. Everytime I
> > > watch Scryer Prolog GitHub issues, their number has increased.
> > > Probably their is only 1 Developer and 10 Advisors, creating noise.
> > > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:13:12 UTC+2:
> > > > Somebody wrote, deliberatively taken out of context here:
> > > >
> > > > "All good ideas of academic systems are adopted by industrial
> > > > ones, which is really awesome, but unfortunately the origin of
> > > > those ideas is often lost."
> > > >
> > > > When its only about vanity, I don’t see any practical use of PEPs.
> > > > Before you can write a PEP, you have to have something working.
> > > > I am very impressed by the recent SWI-Prolog WASM Hackathon.
> > > >
> > > > An alternative name for Hackathon could be Mob Programming:
> > > >
> > > > Mob Programming and the Power of Flow - Woody Zuill, 2019
> > > > https://www.youtube.com/watch?v=28S4CVkYhWA

Maybe in SWI-Prolog it makes sense, since their
JIT indexes might also move down and not only
move right, when they make it multi argument index,

not sure what would be the cost do adopt ICLP07
approach. The ICLP07 paper talks also about some
multi-argument indexing. Maybe every (new) Prolog

system should list the paper it was using while
implementing its Prolog system. For example Ichiban
does that. I find, when I scroll down:

A PORTABLE PROLOG COMPILER (Bowen et al. 83)
[...]
https://github.com/ichiban/prolog#acknowledgments

I also try to give references, best is even to put references
in the source code. What are the references for Scryer
Prolog? Some nonsense word of mouth by two idiots?

Mostowski Collapse schrieb am Samstag, 13. August 2022 um 16:30:21 UTC+2:
> Non-code transformation body guard indexing isn't any
> secret. Is was for example documented here:
>
> Demand-Driven Indexing of Prolog Clauses
> Vıtor Santos Costa, Konstantinos Sagonas, and Ricardo Lopes
> http://user.it.uu.se/~kostis/Papers/iclp07.pdf
>
> SWI-Prolog made it also wrong, it now has a code
> transformation for (=)/2 indexing:
>
> ?- [user].
> p(X) :- X=a.
>
> ?- listing(p/1).
> p(a).
>
> Thats just nonsense as well. Does this say it cannot
> index (==)/2, functor/3, etc..?
>
> LoL
> Mostowski Collapse schrieb am Samstag, 13. August 2022 um 16:20:40 UTC+2:
> > Now I have blocked Ulrich Neumerkel and Markus Triska.
> > My original plan was to not block any people anymore
> > on GitHub. But they are full of nonsense.
> >
> > Here is an example of some gibberisch:
> >
> > > More properties are preserved in application code, the easier it is to
> > reason about the code, also via automated reasoning. [...] Using (==)/2
> > prevents such optimization, and (=)/2.
> > https://github.com/mthom/scryer-prolog/pull/468#issuecomment-625388237
> >
> > Here is my response to the uninformed pestillence:
> >
> > Why would it prevent such optimizations?
> > For example if you index on the main functor you can apply the
> > same indexing for (==)/2 and (=)/2, thats implemented in Jekejeke Prolog.
> >
> > See for yourself:
> > http://pages.xlog.ch/srctab/doclet/docs/05_run/common/jekpro/model/rope/IndexFront.html
> >
> > Its not a code transformation indexing, but indexing is possible.
> > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 14:19:23 UTC+2:
> > > Where is Scryer Prolog on this curve now?
> > >
> > > Ticket Explosion and Reduction over Time
> > > https://www.wolframalpha.com/input?i=1+-+exp%28-x%29+-+x%2F3+from+0+to+3
> > >
> > > I see 54 Open Tickets by UWN, thats around 25% of the Tickets
> > > I see 51 Open Tickets by triska, thats also around 25% of the Tickets
> > >
> > > Should rename Scryer Prolog to Troll Prolog. I had contact
> > > with a Logician recently trying to port fCube by Ferrari, Fiorentini
> > > and Fiorino to Scryer Prolog. But Scryer Prolog crashed,
> > >
> > > exact same code worked in Dogelog. I then adviced the Logician
> > > to make Ticket. He refused to do so, he told me that he rather not
> > > use Scryer Prolog for the moment. Its not me who thinks these
> > >
> > > Tickets and the behaviour of some People is repellant.
> > > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:41:55 UTC+2:
> > > > Interestingly Woody Zuill supports my idea of ticketless development,
> > > > he says somewhere to the point of “no inventory”. I have switched in
> > > > Dogelog to ticketless development. I think Scryer Prolog and maybe other
> > > >
> > > > Prolog systems suffer from a big backlog on GitHub issues. Everytime I
> > > > watch Scryer Prolog GitHub issues, their number has increased.
> > > > Probably their is only 1 Developer and 10 Advisors, creating noise.
> > > > Mostowski Collapse schrieb am Samstag, 13. August 2022 um 13:13:12 UTC+2:
> > > > > Somebody wrote, deliberatively taken out of context here:
> > > > >
> > > > > "All good ideas of academic systems are adopted by industrial
> > > > > ones, which is really awesome, but unfortunately the origin of
> > > > > those ideas is often lost."
> > > > >
> > > > > When its only about vanity, I don’t see any practical use of PEPs.
> > > > > Before you can write a PEP, you have to have something working.
> > > > > I am very impressed by the recent SWI-Prolog WASM Hackathon.
> > > > >
> > > > > An alternative name for Hackathon could be Mob Programming:
> > > > >
> > > > > Mob Programming and the Power of Flow - Woody Zuill, 2019
> > > > > https://www.youtube.com/watch?v=28S4CVkYhWA

Ok, Scryer Prolog, you got list_to_set/2. Woa!
Was ticking along with this O(n^2) version:

/* Folklore Solution */
list_to_set(L, R) :-
sys_list_to_set(L, [], R).

sys_list_to_set([], _, []).
sys_list_to_set([X|L], R, H) :-
memberchk(X, R), !,
sys_list_to_set(L, R, H).
sys_list_to_set([X|L], R, [X|H]) :-
sys_list_to_set(L, [X|R], H).

Then I found nevertheless in Scryer Prolog this one:

/* Scryer Prolog Solution */
list_to_set(Ls0, Ls) :-
maplist(lists:with_var, Ls0, LVs0),
keysort(LVs0, LVs),
same_elements(LVs),
pick_firsts(LVs0, Ls).

Is the above faster than the SWI-Prolog version,
which does two sorts?

BTW: Theoretical Computer Science tells me that a hash table with an
input order overlay wouldn’t be so bad, basically O(n), faster than O(n*log(n)).
I had this in Jekejeke Prolog for ages, still have it, it works like that:

/* Jekejeke Prolog Solution */
?- sort([2,1,3,1], X).
X = [1, 2, 3]
?- sort([2,1,3,1], X, [type(hash)]).
X = [2, 1, 3]

The hash table with an input order overlay is the age old Java:
https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html
The O(n) complexity assumes amortized complexity O(1) of a hash table lookup.

Right? Yes or no?

Mostowski Collapse schrieb am Donnerstag, 18. August 2022 um 16:16:49 UTC+2:
> Ok, Scryer Prolog, you got list_to_set/2. Woa!
> Was ticking along with this O(n^2) version:
>
> /* Folklore Solution */
> list_to_set(L, R) :-
> sys_list_to_set(L, [], R).
>
> sys_list_to_set([], _, []).
> sys_list_to_set([X|L], R, H) :-
> memberchk(X, R), !,
> sys_list_to_set(L, R, H).
> sys_list_to_set([X|L], R, [X|H]) :-
> sys_list_to_set(L, [X|R], H).
>
> Then I found nevertheless in Scryer Prolog this one:
>
> /* Scryer Prolog Solution */
> list_to_set(Ls0, Ls) :-
> maplist(lists:with_var, Ls0, LVs0),
> keysort(LVs0, LVs),
> same_elements(LVs),
> pick_firsts(LVs0, Ls).
>
> Is the above faster than the SWI-Prolog version,
> which does two sorts?

This is the more fun solution:

/* Folklore Solution */
list_to_set([], R) :- append(R, [], _), !.
list_to_set([X|L], R) :- member(X, R), !,
list_to_set(L, R).

Only for mode (+,-).

Mostowski Collapse schrieb am Donnerstag, 18. August 2022 um 16:17:41 UTC+2:
> BTW: Theoretical Computer Science tells me that a hash table with an
> input order overlay wouldn’t be so bad, basically O(n), faster than O(n*log(n)).
> I had this in Jekejeke Prolog for ages, still have it, it works like that:
>
> /* Jekejeke Prolog Solution */
> ?- sort([2,1,3,1], X).
> X = [1, 2, 3]
> ?- sort([2,1,3,1], X, [type(hash)]).
> X = [2, 1, 3]
>
> The hash table with an input order overlay is the age old Java:
> https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html
> The O(n) complexity assumes amortized complexity O(1) of a hash table lookup.
>
> Right? Yes or no?
> Mostowski Collapse schrieb am Donnerstag, 18. August 2022 um 16:16:49 UTC+2:
> > Ok, Scryer Prolog, you got list_to_set/2. Woa!
> > Was ticking along with this O(n^2) version:
> >
> > /* Folklore Solution */
> > list_to_set(L, R) :-
> > sys_list_to_set(L, [], R).
> >
> > sys_list_to_set([], _, []).
> > sys_list_to_set([X|L], R, H) :-
> > memberchk(X, R), !,
> > sys_list_to_set(L, R, H).
> > sys_list_to_set([X|L], R, [X|H]) :-
> > sys_list_to_set(L, [X|R], H).
> >
> > Then I found nevertheless in Scryer Prolog this one:
> >
> > /* Scryer Prolog Solution */
> > list_to_set(Ls0, Ls) :-
> > maplist(lists:with_var, Ls0, LVs0),
> > keysort(LVs0, LVs),
> > same_elements(LVs),
> > pick_firsts(LVs0, Ls).
> >
> > Is the above faster than the SWI-Prolog version,
> > which does two sorts?