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?

Wanna know whats the Cancer of Prolog?

Try this:

fizzbuzz :-
foreach(between(1, 100, X), print_item(X)).

print_item(X) :-
( 0 is X mod 15
-> print('FizzBuzz')
; 0 is X mod 3
-> print('Fizz')
; 0 is X mod 5
-> print('Buzz')
; print(X)
),
nl.

https://rosettacode.org/wiki/FizzBuzz#Prolog

And then try this in (Ciao Prolog Playground or search their documentation):

?- foreach(member(X, [1,2,3]), print(X)).
{ERROR: No handle found for thrown exception
error(existence_error(procedure,'user:foreach'/2),'user:foreach'/2)}

LoL

What does your Prolog float/1 and your Prolog (**)/2 do?
Does it do the right thing, or some nonsense?

Here are some results:

/* Jekejeke Prolog 1.5.4 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 551.

/* Trealla Prolog 2.2.5 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 12750.

/* Scryer Prolog 0.9.0 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 500254.

/* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10.0 =\= float(N**10)), C).
C = 585342.

Maybe one needs also look into float/1, not only (**)/2 ?
Especially float/1 of a bigint, I guess smallint could be ok.

I did more testing:

/* Jekejeke Prolog, JDK 19 */
C = 551.

/* Dogelog Player, Python (CPython and PyPy) */
C = 1991.

/* Dogelog Player, JavaScript (FireFox) */
C = 1991.

/* Jekejeke Prolog, JDK 1.8 */
C = 15586.

/* Dogelog Player, JavaScript (Chrome and NodeJS) */
C = 97722.

Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> What does your Prolog float/1 and your Prolog (**)/2 do?
> Does it do the right thing, or some nonsense?
>
> Here are some results:
>
> /* Jekejeke Prolog 1.5.4 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 551.
>
> /* Trealla Prolog 2.2.5 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 12750.
>
> /* Scryer Prolog 0.9.0 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 500254.
>
> /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10.0 =\= float(N**10)), C).
> C = 585342.

The differences can be explained that the different host
languages have different runtime systems, with different
intrinsic Math.pow(double, double) implementations, that

is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
was all tested on the same hardware, so they possibly use
soft implementation of the pow intrinsic. Or maybe some

use hard implementation delegating to FPU, and I might
even see differences on different hardward. Will check with
a different hardware as welll. Give me some time. Since I

have Ryzen and Intel here, maybe will see a difference.

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> Maybe one needs also look into float/1, not only (**)/2 ?
> Especially float/1 of a bigint, I guess smallint could be ok.
>
> I did more testing:
>
> /* Jekejeke Prolog, JDK 19 */
> C = 551.
>
> /* Dogelog Player, Python (CPython and PyPy) */
> C = 1991.
>
> /* Dogelog Player, JavaScript (FireFox) */
> C = 1991.
>
> /* Jekejeke Prolog, JDK 1.8 */
> C = 15586.
>
> /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> C = 97722.
> Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > What does your Prolog float/1 and your Prolog (**)/2 do?
> > Does it do the right thing, or some nonsense?
> >
> > Here are some results:
> >
> > /* Jekejeke Prolog 1.5.4 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 551.
> >
> > /* Trealla Prolog 2.2.5 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 12750.
> >
> > /* Scryer Prolog 0.9.0 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 500254.
> >
> > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10.0 =\= float(N**10)), C).
> > C = 585342.

Yes there is also a hardware dependency, and these figures
are no joke, i.e. that one figure is permutation of the other figure,
thats some random accident. I get the following result:

/* Jekejeke Prolog, JDK 1.8, Ryzen, 5 4500U */
C = 15586.

/* Jekejeke Prolog, JDK 1.8, Intel, i5-1135G7 */
C = 15856.

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:23:25 UTC+2:
> The differences can be explained that the different host
> languages have different runtime systems, with different
> intrinsic Math.pow(double, double) implementations, that
>
> is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
> was all tested on the same hardware, so they possibly use
> soft implementation of the pow intrinsic. Or maybe some
>
> use hard implementation delegating to FPU, and I might
> even see differences on different hardward. Will check with
> a different hardware as welll. Give me some time. Since I
>
> have Ryzen and Intel here, maybe will see a difference.
> Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> > Maybe one needs also look into float/1, not only (**)/2 ?
> > Especially float/1 of a bigint, I guess smallint could be ok.
> >
> > I did more testing:
> >
> > /* Jekejeke Prolog, JDK 19 */
> > C = 551.
> >
> > /* Dogelog Player, Python (CPython and PyPy) */
> > C = 1991.
> >
> > /* Dogelog Player, JavaScript (FireFox) */
> > C = 1991.
> >
> > /* Jekejeke Prolog, JDK 1.8 */
> > C = 15586.
> >
> > /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> > C = 97722.
> > Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > > What does your Prolog float/1 and your Prolog (**)/2 do?
> > > Does it do the right thing, or some nonsense?
> > >
> > > Here are some results:
> > >
> > > /* Jekejeke Prolog 1.5.4 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 551.
> > >
> > > /* Trealla Prolog 2.2.5 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 12750.
> > >
> > > /* Scryer Prolog 0.9.0 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 500254.
> > >
> > > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10.0 =\= float(N**10)), C).
> > > C = 585342.

Some progress was reported for SWI-Prolog:

/* Ubuntu AMD3950X, gcc-11 */
C = 807
/* Apple M1, AppleClang 13.1 */
C = 1225
/* Windows, MinGW 11.2 */
C = 508689

Maybe MinGW suffers from:

- Theory: You know something, but it doesn’t work.
- Practice: Something works, but you don’t know why.
- Programming: Combine theory and practice: Nothing works, and we don’t know why!

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:41:01 UTC+2:
> Yes there is also a hardware dependency, and these figures
> are no joke, i.e. that one figure is permutation of the other figure,
> thats some random accident. I get the following result:
>
> /* Jekejeke Prolog, JDK 1.8, Ryzen, 5 4500U */
> C = 15586.
>
> /* Jekejeke Prolog, JDK 1.8, Intel, i5-1135G7 */
> C = 15856.
> Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:23:25 UTC+2:
> > The differences can be explained that the different host
> > languages have different runtime systems, with different
> > intrinsic Math.pow(double, double) implementations, that
> >
> > is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
> > was all tested on the same hardware, so they possibly use
> > soft implementation of the pow intrinsic. Or maybe some
> >
> > use hard implementation delegating to FPU, and I might
> > even see differences on different hardward. Will check with
> > a different hardware as welll. Give me some time. Since I
> >
> > have Ryzen and Intel here, maybe will see a difference.
> > Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> > > Maybe one needs also look into float/1, not only (**)/2 ?
> > > Especially float/1 of a bigint, I guess smallint could be ok.
> > >
> > > I did more testing:
> > >
> > > /* Jekejeke Prolog, JDK 19 */
> > > C = 551.
> > >
> > > /* Dogelog Player, Python (CPython and PyPy) */
> > > C = 1991.
> > >
> > > /* Dogelog Player, JavaScript (FireFox) */
> > > C = 1991.
> > >
> > > /* Jekejeke Prolog, JDK 1.8 */
> > > C = 15586.
> > >
> > > /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> > > C = 97722.
> > > Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > > > What does your Prolog float/1 and your Prolog (**)/2 do?
> > > > Does it do the right thing, or some nonsense?
> > > >
> > > > Here are some results:
> > > >
> > > > /* Jekejeke Prolog 1.5.4 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 551.
> > > >
> > > > /* Trealla Prolog 2.2.5 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 12750.
> > > >
> > > > /* Scryer Prolog 0.9.0 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 500254.
> > > >
> > > > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10.0 =\= float(N**10)), C).
> > > > C = 585342.

Will a change to float/1 also affect (/)/2. In the past I had high
regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
ECLiPSe Prolog has degraded. But there is now the issue, suppose

there is a new SWI-Prolog version with a new float/1 compatible
with (**)/2, do the results still hold?

?- aggregate_all(count, (between(1,1000000,N),
(123456789*123456789*N)/123456789 =\= float(123456789*N)), C).

/* SWI-Prolog 8.5.17 */
C = 0

/* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
C = 72226

/* ECLiPSe Prolog 7.0.61 */
C = 494175

And of course there is the question of timing. SWI-Prolog, the
version 8.5.17 I have available, is rather behind, possibly rather
an issue of (/)/2, but could be an issue of both (/)/2

and float/1 in the future:

?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
=\= float(123456789*N), fail; true)).

/* SWI-Prolog 8.5.17 */
% 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)

/* Jekejeke Prolog 1.5.4, JDK 19 */
% Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)

/* Jekejeke Prolog 1.5.4, JDK 1.8 */
% Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> Will a change to float/1 also affect (/)/2. In the past I had high
> regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> ECLiPSe Prolog has degraded. But there is now the issue, suppose
>
> there is a new SWI-Prolog version with a new float/1 compatible
> with (**)/2, do the results still hold?
>
> ?- aggregate_all(count, (between(1,1000000,N),
> (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
>
> /* SWI-Prolog 8.5.17 */
> C = 0
>
> /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> C = 72226
>
> /* ECLiPSe Prolog 7.0.61 */
> C = 494175

Its also lacking behind on Unix, via WSL2 on the same machine,
but this is not yet a version with some new float/1:

/* SWI-Prolog 8.4.2 */
% 2,000,001 inferences, 0.543 CPU in 0.543 seconds (100% CPU, 3685380 Lips)
JDK 1.8 does it in 261 ms. But I use a different (/)/2 algorithm.
Actually one could also introduce two float division algorithms, similar
to two power raise functions (**)/2 and (^)/2:

- Fast but less precise (/)/2: Calling X is A/B will use a less precise algorithm,
like for example float(A)/float(B). The benefit would be more speedier,
disadvantage less precision. The error is not that bad, see above in the
example I get only 72226 faults. Same idea could be applied to (**)/2.

- Slow but more precise (rdiv)/2 and float/1 combo: Call X is float(A rdiv B) will
use a more precise algorithm, for example divmod/4 and extra shifting
based as in mpq_get_d_nearest . The benefit would be more precise,
disadvantage less speed. Same idea could be appled to (^)/2.

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:11:35 UTC+2:
> And of course there is the question of timing. SWI-Prolog, the
> version 8.5.17 I have available, is rather behind, possibly rather
> an issue of (/)/2, but could be an issue of both (/)/2
>
> and float/1 in the future:
>
> ?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
> =\= float(123456789*N), fail; true)).
>
> /* SWI-Prolog 8.5.17 */
> % 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)
>
> /* Jekejeke Prolog 1.5.4, JDK 19 */
> % Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)
>
> /* Jekejeke Prolog 1.5.4, JDK 1.8 */
> % Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)
> Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> > Will a change to float/1 also affect (/)/2. In the past I had high
> > regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> > ECLiPSe Prolog has degraded. But there is now the issue, suppose
> >
> > there is a new SWI-Prolog version with a new float/1 compatible
> > with (**)/2, do the results still hold?
> >
> > ?- aggregate_all(count, (between(1,1000000,N),
> > (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
> >
> > /* SWI-Prolog 8.5.17 */
> > C = 0
> >
> > /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> > C = 72226
> >
> > /* ECLiPSe Prolog 7.0.61 */
> > C = 494175

I also tested Trealla Prolog and Scryer Prolog, here precision:

/* Trealla Prolog 2.2.6 */
C = 72226

/* Scryer Prolog 0.9.0 */
C = 494423

Here the time measurements, Trealla Prolog nearly as fast as JDK 1.8:

/* Trealla Prolog 2.2.6 */
% Time elapsed 0.293s

/* Scryer Prolog 0.9.0 */
% % CPU time: 1.559s

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 17:55:23 UTC+2:
> Its also lacking behind on Unix, via WSL2 on the same machine,
> but this is not yet a version with some new float/1:
>
> /* SWI-Prolog 8.4.2 */
> % 2,000,001 inferences, 0.543 CPU in 0.543 seconds (100% CPU, 3685380 Lips)
> JDK 1.8 does it in 261 ms. But I use a different (/)/2 algorithm.
> Actually one could also introduce two float division algorithms, similar
> to two power raise functions (**)/2 and (^)/2:
>
> - Fast but less precise (/)/2: Calling X is A/B will use a less precise algorithm,
> like for example float(A)/float(B). The benefit would be more speedier,
> disadvantage less precision. The error is not that bad, see above in the
> example I get only 72226 faults. Same idea could be applied to (**)/2.
>
> - Slow but more precise (rdiv)/2 and float/1 combo: Call X is float(A rdiv B) will
> use a more precise algorithm, for example divmod/4 and extra shifting
> based as in mpq_get_d_nearest . The benefit would be more precise,
> disadvantage less speed. Same idea could be appled to (^)/2.
> Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:11:35 UTC+2:
> > And of course there is the question of timing. SWI-Prolog, the
> > version 8.5.17 I have available, is rather behind, possibly rather
> > an issue of (/)/2, but could be an issue of both (/)/2
> >
> > and float/1 in the future:
> >
> > ?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
> > =\= float(123456789*N), fail; true)).
> >
> > /* SWI-Prolog 8.5.17 */
> > % 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)
> >
> > /* Jekejeke Prolog 1.5.4, JDK 19 */
> > % Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)
> >
> > /* Jekejeke Prolog 1.5.4, JDK 1.8 */
> > % Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)
> > Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> > > Will a change to float/1 also affect (/)/2. In the past I had high
> > > regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> > > ECLiPSe Prolog has degraded. But there is now the issue, suppose
> > >
> > > there is a new SWI-Prolog version with a new float/1 compatible
> > > with (**)/2, do the results still hold?
> > >
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
> > >
> > > /* SWI-Prolog 8.5.17 */
> > > C = 0
> > >
> > > /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> > > C = 72226
> > >
> > > /* ECLiPSe Prolog 7.0.61 */
> > > C = 494175

Remembering Joe Armstrong - 20. April 2024:
https://www.heise.de/news/Hello-Mike-hello-Robert-goodbye-Joe-Zum-Tode-von-Joe-Armstrong-4404170.html

Some quote:

"Make it work, then make it beautiful, then
if you really, really have to, make it fast.

90% of the time, if you make it beautiful,
it will already be fast.

So really, just make it beautiful!
-Joe Armstrong, Erlang"

Now I have a couple of questions:
- Was Jekejeke beautiful? [No! LoL]
- Is Trealla beautiful?
- Is Scryer beautiful?
- Is Dogelog beautiful? [Yes! LoL]
- Is SWI-Prolog beautiful?
- Is GNU Prolog beautiful?
- Is ECLiPSe Prolog beautiful?
- Is XSB Prolog beautiful?
- Is SICStus Prolog beautiful?
- Etc..

Hey Scryer Prolog, whats up?
Why the tooltip "Artificial Intelligence" over "AI"

Scryer Prolog Meetup 2024
https://www.digitalaustria.gv.at/eng/insights/Digital-Austria-Events-EN/Scryer-Prolog-Meetup-2024.html

What does AI mean in Austria, Austrian Idiotism?
Why don't you simply write:

Artificial Inteligence (AI) in the first occurence,
then in every other occurence you can write AI.
And then the thingy gets also printable.

Mild Shock schrieb:
> Remembering Joe Armstrong - 20. April 2024:
> https://www.heise.de/news/Hello-Mike-hello-Robert-goodbye-Joe-Zum-Tode-von-Joe-Armstrong-4404170.html
>
>
> Some quote:
>
> "Make it work, then make it beautiful, then
> if you really, really have to, make it fast.
>
> 90% of the time, if you make it beautiful,
> it will already be fast.
>
> So really, just make it beautiful!
> -Joe Armstrong, Erlang"
>
>
> Now I have a couple of questions:
> - Was Jekejeke beautiful? [No! LoL]
> - Is Trealla beautiful?
> - Is Scryer beautiful?
> - Is Dogelog beautiful? [Yes! LoL]
> - Is SWI-Prolog beautiful?
> - Is GNU Prolog beautiful?
> - Is ECLiPSe Prolog beautiful?
> - Is XSB Prolog beautiful?
> - Is SICStus Prolog beautiful?
> - Etc..
>
>
>