Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.prolog > #14859 > unrolled thread

Who will win the new Prolog race? SWI or Scryer?

Back to article view | Back to comp.lang.prolog

Contents

  Who will win the new Prolog race? SWI or Scryer? Mild Shock <janburse@fastmail.fm> - 2025-09-28 08:57 +0200
    The only problem is, Rust is shiiiit (Was: Who will win the new Prolog race? SWI or Scryer?) Mild Shock <janburse@fastmail.fm> - 2025-09-28 09:01 +0200
      Recent hybrid: Python beats Rust (Was: The only problem is, Rust is shiiiit) Mild Shock <janburse@fastmail.fm> - 2025-09-28 09:13 +0200
    Trealla drastically beats Scryer [Jaffar's Algorithm] (Re: Who will win the new Prolog race? SWI or Scryer? Mild Shock <janburse@fastmail.fm> - 2025-09-29 12:19 +0200
      Boris the Loris and the American Fuzzy Lop (Was: Trealla drastically beats Scryer [Jaffar's Algorithm]) Mild Shock <janburse@fastmail.fm> - 2025-09-29 12:54 +0200
        Was Boris living under a rock, how many Fuzzy Testing tools? (Was: Boris the Loris and the American Fuzzy Lop) Mild Shock <janburse@fastmail.fm> - 2025-09-29 12:59 +0200
          Not a Nazi-Retard, maybe a payed Troll on Putins payroll (Was: Was Boris living under a rock, how many Fuzzy Testing tools?) Mild Shock <janburse@fastmail.fm> - 2025-09-29 13:07 +0200
        Boris / EricGT: Why dont you tap into TAP? (Was: Boris the Loris and the American Fuzzy Lop) Mild Shock <janburse@fastmail.fm> - 2025-11-18 23:00 +0100
          Closing the abstract interpretation GAP (Re: Boris / EricGT: Why dont you tap into TAP?) Mild Shock <janburse@fastmail.fm> - 2025-11-18 23:12 +0100
      Fast, but not correct implementation (Was: Trealla drastically beats Scryer [Jaffar's Algorithm]) Mild Shock <janburse@fastmail.fm> - 2025-09-30 21:39 +0200
        Boris the Loris saw it all comming [Weak Prolog Community] (Was: Fast, but not correct implementation) Mild Shock <janburse@fastmail.fm> - 2025-09-30 21:53 +0200
    War between Scryer Prolog and Ciao Prolog [9:0 Triska vs Hermenegildo] (Was: Who will win the new Prolog race? SWI or Scryer?) Mild Shock <janburse@fastmail.fm> - 2025-11-19 12:49 +0100
      Useless as the Thirty Years War / Generalized Facts (Was: War between Scryer Prolog and Ciao Prolog) Mild Shock <janburse@fastmail.fm> - 2025-11-19 13:11 +0100
    The Guerilla tactics of SWI are amazing: Shell India? (Was: Who will win the new Prolog race? SWI or Scryer?) Mild Shock <janburse@fastmail.fm> - 2025-11-24 15:22 +0100
      The SWI7 exotism (dicts, etc..) has no value? (Was: The Guerilla tactics of SWI are amazing: Shell India?) Mild Shock <janburse@fastmail.fm> - 2025-11-24 15:41 +0100
        My new TinyCLP is much faster [100% Prolog] (Was: The SWI7 exotism (dicts, etc..) has no value?) Mild Shock <janburse@fastmail.fm> - 2025-11-24 21:27 +0100
    Railgun CLP versus Scryer Prolog [Euler #30 Variant] (Was: Who will win the new Prolog race?) Mild Shock <janburse@fastmail.fm> - 2026-01-30 02:10 +0100

#14859 — Who will win the new Prolog race? SWI or Scryer?

Hi,

Who will win the new Prolog race?
SWI or Scryer? Is it enough that SWI-Prolog
has teamed up with Ciao Prolog?

What about resources that really can
code a Prolog systems. SWI-Prolog is
now doomed to have professional moron

Julio Di Egidio on board. Not sure whether
he will ever become a heavy committer to
SWI-Prolog source. But who knows, we should

also give Julio Di Egidio a chance. My
gut feeling at the moment:

- SWI-Prolog:
   Pull Requests 10 Open / 560 Closed

- Scryer Prolog:
   Pull Requests 40 Open / 751 Closed

In the past I would measure active committers.
But the new "liveness" indicator of a Prolog
system could be indeed Pull Requests.

So who will win?

P.S.: Data sources:

https://github.com/mthom/scryer-prolog/pulls

https://github.com/SWI-Prolog/swipl-devel/pulls

[toc] | [next] | [standalone]

#14860 — The only problem is, Rust is shiiiit (Was: Who will win the new Prolog race? SWI or Scryer?)

Hi,

The only problem is Rust is shiiiit.
At least some argument about precise
garbage collection induced by immediate

malloc / free doesn't strike me as
convincing. Many modern programming
languages don't use the malloc / free

paradigma for memory management. You
don't get automatically pause free
systems when relying on malloc / free.

It can be even worse. I have seen browsers
that take a while to close a window
because they did synchrously release all

the resources of a window. So there
is a fallacy involved in all believes that
immediate malloc / free leads to pause

free systems, it can be even worse.

Bye

Mild Shock schrieb:
> Hi,
> 
> Who will win the new Prolog race?
> SWI or Scryer? Is it enough that SWI-Prolog
> has teamed up with Ciao Prolog?
> 
> What about resources that really can
> code a Prolog systems. SWI-Prolog is
> now doomed to have professional moron
> 
> Julio Di Egidio on board. Not sure whether
> he will ever become a heavy committer to
> SWI-Prolog source. But who knows, we should
> 
> also give Julio Di Egidio a chance. My
> gut feeling at the moment:
> 
> - SWI-Prolog:
>    Pull Requests 10 Open / 560 Closed
> 
> - Scryer Prolog:
>    Pull Requests 40 Open / 751 Closed
> 
> In the past I would measure active committers.
> But the new "liveness" indicator of a Prolog
> system could be indeed Pull Requests.
> 
> So who will win?
> 
> P.S.: Data sources:
> 
> https://github.com/mthom/scryer-prolog/pulls
> 
> https://github.com/SWI-Prolog/swipl-devel/pulls
> 

[toc] | [prev] | [next] | [standalone]

#14861 — Recent hybrid: Python beats Rust (Was: The only problem is, Rust is shiiiit)

Hi,

Yesterday I did again some testing of the
unification algorithm. Somehow Scryer is
also a moving target, so my measurement for

Scryer Prolog has somehow changed. Possibly
because I changed the test cases a little bit,
used the (\+ \+) to have different scenarios.

But with the new hybrid prototype from
yesterday it shows for bisimulation (=)/2
resp (==)/2 and the N = 1’048’576 test case:

Hybrid Solution

Test	Java	JavaScript	Python	Scryer
(=)/2	99	115	469	132
(==)/2	68	71	140	127

Ok, the Python almost beats Rust, was
exaggerating for the effect, and only
for (==)/2, we have still 140 > 127.

And otherwise for (=)/2 its drastic 469 > 132.
Not sure what is going on in the (=)/2,
why Python is so slow. On the other hand

Java and JavaScript run away from Rust,
are better in my implementation if bisimulation
and Jaffar's Unification, not significantly,

but noticeable I suspect.

Bye

Mild Shock schrieb:
> Hi,
> 
> The only problem is Rust is shiiiit.
> At least some argument about precise
> garbage collection induced by immediate
> 
> malloc / free doesn't strike me as
> convincing. Many modern programming
> languages don't use the malloc / free
> 
> paradigma for memory management. You
> don't get automatically pause free
> systems when relying on malloc / free.
> 
> It can be even worse. I have seen browsers
> that take a while to close a window
> because they did synchrously release all
> 
> the resources of a window. So there
> is a fallacy involved in all believes that
> immediate malloc / free leads to pause
> 
> free systems, it can be even worse.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Who will win the new Prolog race?
>> SWI or Scryer? Is it enough that SWI-Prolog
>> has teamed up with Ciao Prolog?
>>
>> What about resources that really can
>> code a Prolog systems. SWI-Prolog is
>> now doomed to have professional moron
>>
>> Julio Di Egidio on board. Not sure whether
>> he will ever become a heavy committer to
>> SWI-Prolog source. But who knows, we should
>>
>> also give Julio Di Egidio a chance. My
>> gut feeling at the moment:
>>
>> - SWI-Prolog:
>>    Pull Requests 10 Open / 560 Closed
>>
>> - Scryer Prolog:
>>    Pull Requests 40 Open / 751 Closed
>>
>> In the past I would measure active committers.
>> But the new "liveness" indicator of a Prolog
>> system could be indeed Pull Requests.
>>
>> So who will win?
>>
>> P.S.: Data sources:
>>
>> https://github.com/mthom/scryer-prolog/pulls
>>
>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>
> 

[toc] | [prev] | [next] | [standalone]

#14864 — Trealla drastically beats Scryer [Jaffar's Algorithm] (Re: Who will win the new Prolog race? SWI or Scryer?

Hi,

Now I have the feeling that Trealla implements
the extreme of Jaffar's Unification, to the extend
that it keeps and trails functor linking? Was

studying the source of Trealla . Have also the
impression that it uses a very large native stack.
Is this trailing what gave it the name Trealla,

despite the geographic beach location with such a name ?
BTW: I have new benchmark results (*) = Dogelog:

Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
-- | -- | -- | -- | -- | --
(=)/2 | 184 | 514 | 1750 | 210 | 53
unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
(==)/2 | 95 | 227 | 1265 | 250 | 65
compare/3 | 86 | 221 | 1328 | 250 | 65
copy_term/2 | 409 | 589 | 2579 | 108 | N/A
term_variables/2 | 168 | 318 | 1469 | 166 | 90
ground/1 | 40 | 120 | 516 | 70 | 121
acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
numbervars/3 | 170 | 327 | 1516 | 164 | 100

Pitty `copy_term/2` and `acyclic_term/1` do not
yet work with a hydra example.

I am using a hydra variant, which puts less
pressure on the memory, but does benchmark
the built-ins in a loop, so that I see some

numbers. My problem was that Trealla was
below the 1 ms mesurememt:
```
hydra(0, _) :- !.
hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).

hydra(0, A, A) :- !.
hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).

/* Binary Built-ins */
bench :-
    hydra(65536, X), hydra(65536, Y, Y),
    time((between(1,64,_), X = Y, fail; true)),
    time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
    time((between(1,64,_), X == Y, fail; true)),
    time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.

/* Unary Built-ins */
bench2 :-
    hydra(65536, X), hydra(65536, Y, Y),
    time((between(1,64,_), copy_term(X-Y,_), fail; true)),
    time((between(1,64,_), term_variables(X-Y,_), fail; true)),
    time((between(1,64,_), ground(X-Y), fail; true)),
    time((between(1,64,_), acyclic_term(X-Y), fail; true)),
    fail; true.

/* Misc Built-ins */
bench3 :-
    hydra(65536, X), hydra(65536, Y, Y),
    time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
    fail; true.
```
Bye

Mild Shock schrieb:
> Hi,
> 
> Who will win the new Prolog race?
> SWI or Scryer? Is it enough that SWI-Prolog
> has teamed up with Ciao Prolog?
> 
> What about resources that really can
> code a Prolog systems. SWI-Prolog is
> now doomed to have professional moron
> 
> Julio Di Egidio on board. Not sure whether
> he will ever become a heavy committer to
> SWI-Prolog source. But who knows, we should
> 
> also give Julio Di Egidio a chance. My
> gut feeling at the moment:
> 
> - SWI-Prolog:
>    Pull Requests 10 Open / 560 Closed
> 
> - Scryer Prolog:
>    Pull Requests 40 Open / 751 Closed
> 
> In the past I would measure active committers.
> But the new "liveness" indicator of a Prolog
> system could be indeed Pull Requests.
> 
> So who will win?
> 
> P.S.: Data sources:
> 
> https://github.com/mthom/scryer-prolog/pulls
> 
> https://github.com/SWI-Prolog/swipl-devel/pulls
> 

[toc] | [prev] | [next] | [standalone]

#14865 — Boris the Loris and the American Fuzzy Lop (Was: Trealla drastically beats Scryer [Jaffar's Algorithm])

Hi,

Information for Boris the Loris, chief grammar
Nazi of SWI-Prolog discourse. Here is a summary
of my No Fuzz(y) declaration for the

Trealla & Co. benchmarking from my previous post:

- No fuzzy logic involved.
   Its all binary.

- No fuzzy testing involved.
   Its all manual testing.

- No fuzz testing involved.
   See above fuzzy testig.

- No fuzzing test involved.
   See above fuzzy testig.

What about the American Fuzzy Lop (AFL),
a free software fuzzer:

https://en.wikipedia.org/wiki/American_Fuzzy_Lop_%28software%29

Or was a breed of rabbit, by the
the name American Fuzzy Lop involved?

https://en.wikipedia.org/wiki/American_Fuzzy_Lop

No neither of the 2 AFLs were involved.

Bye

Mild Shock schrieb:
> Hi,
> 
> Now I have the feeling that Trealla implements
> the extreme of Jaffar's Unification, to the extend
> that it keeps and trails functor linking? Was
> 
> studying the source of Trealla . Have also the
> impression that it uses a very large native stack.
> Is this trailing what gave it the name Trealla,
> 
> despite the geographic beach location with such a name ?
> BTW: I have new benchmark results (*) = Dogelog:
> 
> Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
> -- | -- | -- | -- | -- | --
> (=)/2 | 184 | 514 | 1750 | 210 | 53
> unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
> (==)/2 | 95 | 227 | 1265 | 250 | 65
> compare/3 | 86 | 221 | 1328 | 250 | 65
> copy_term/2 | 409 | 589 | 2579 | 108 | N/A
> term_variables/2 | 168 | 318 | 1469 | 166 | 90
> ground/1 | 40 | 120 | 516 | 70 | 121
> acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
> numbervars/3 | 170 | 327 | 1516 | 164 | 100
> 
> Pitty `copy_term/2` and `acyclic_term/1` do not
> yet work with a hydra example.
> 
> I am using a hydra variant, which puts less
> pressure on the memory, but does benchmark
> the built-ins in a loop, so that I see some
> 
> numbers. My problem was that Trealla was
> below the 1 ms mesurememt:
> ```
> hydra(0, _) :- !.
> hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).
> 
> hydra(0, A, A) :- !.
> hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).
> 
> /* Binary Built-ins */
> bench :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), X = Y, fail; true)),
>     time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
>     time((between(1,64,_), X == Y, fail; true)),
>     time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.
> 
> /* Unary Built-ins */
> bench2 :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), copy_term(X-Y,_), fail; true)),
>     time((between(1,64,_), term_variables(X-Y,_), fail; true)),
>     time((between(1,64,_), ground(X-Y), fail; true)),
>     time((between(1,64,_), acyclic_term(X-Y), fail; true)),
>     fail; true.
> 
> /* Misc Built-ins */
> bench3 :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
>     fail; true.
> ```
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Who will win the new Prolog race?
>> SWI or Scryer? Is it enough that SWI-Prolog
>> has teamed up with Ciao Prolog?
>>
>> What about resources that really can
>> code a Prolog systems. SWI-Prolog is
>> now doomed to have professional moron
>>
>> Julio Di Egidio on board. Not sure whether
>> he will ever become a heavy committer to
>> SWI-Prolog source. But who knows, we should
>>
>> also give Julio Di Egidio a chance. My
>> gut feeling at the moment:
>>
>> - SWI-Prolog:
>>    Pull Requests 10 Open / 560 Closed
>>
>> - Scryer Prolog:
>>    Pull Requests 40 Open / 751 Closed
>>
>> In the past I would measure active committers.
>> But the new "liveness" indicator of a Prolog
>> system could be indeed Pull Requests.
>>
>> So who will win?
>>
>> P.S.: Data sources:
>>
>> https://github.com/mthom/scryer-prolog/pulls
>>
>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>
> 

[toc] | [prev] | [next] | [standalone]

#14866 — Was Boris living under a rock, how many Fuzzy Testing tools? (Was: Boris the Loris and the American Fuzzy Lop)

Hi,

Was Boris living under a rock, maybe on
the moon in a secret Nazi Facility?

Who knows, maybe he was in another facility,
some kind of mental asylum, until he was

hired by SWI-Prolog. How many Fuzzy Testing
tools are there? Actually plenty:

http://fuzzing-survey.org/

Some excerpt:

Creal
FishFuzz
ParmeSan
WindRanger
loFuzz
UAFL
HAFL
MobFuzz
WINNIE
CAFL
DynSQL
MirageFuzz
IRFU
PhyFu
NestFuzz
AMPFuzz
MC2
AIFORE
IPEA-Fuzz
FuzzlnMem
CarpetFuzz
JIGSAW
YARPGen
PDGF
BEACON
Mallory
Fuzz
LLM-Fuzzer
FAST
DAFL
OddFuzz
KRAKEN
CDFUZ7
MALinten+
ChatAFL
TWINFUZ7
DeepGo
xFUZZ
FreeWavm
Halo
Select
Titan
Etc...

Bye

Mild Shock schrieb:
> Hi,
> 
> Information for Boris the Loris, chief grammar
> Nazi of SWI-Prolog discourse. Here is a summary
> of my No Fuzz(y) declaration for the
> 
> Trealla & Co. benchmarking from my previous post:
> 
> - No fuzzy logic involved.
>    Its all binary.
> 
> - No fuzzy testing involved.
>    Its all manual testing.
> 
> - No fuzz testing involved.
>    See above fuzzy testig.
> 
> - No fuzzing test involved.
>    See above fuzzy testig.
> 
> What about the American Fuzzy Lop (AFL),
> a free software fuzzer:
> 
> https://en.wikipedia.org/wiki/American_Fuzzy_Lop_%28software%29
> 
> Or was a breed of rabbit, by the
> the name American Fuzzy Lop involved?
> 
> https://en.wikipedia.org/wiki/American_Fuzzy_Lop
> 
> No neither of the 2 AFLs were involved.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Now I have the feeling that Trealla implements
>> the extreme of Jaffar's Unification, to the extend
>> that it keeps and trails functor linking? Was
>>
>> studying the source of Trealla . Have also the
>> impression that it uses a very large native stack.
>> Is this trailing what gave it the name Trealla,
>>
>> despite the geographic beach location with such a name ?
>> BTW: I have new benchmark results (*) = Dogelog:
>>
>> Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
>> -- | -- | -- | -- | -- | --
>> (=)/2 | 184 | 514 | 1750 | 210 | 53
>> unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
>> (==)/2 | 95 | 227 | 1265 | 250 | 65
>> compare/3 | 86 | 221 | 1328 | 250 | 65
>> copy_term/2 | 409 | 589 | 2579 | 108 | N/A
>> term_variables/2 | 168 | 318 | 1469 | 166 | 90
>> ground/1 | 40 | 120 | 516 | 70 | 121
>> acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
>> numbervars/3 | 170 | 327 | 1516 | 164 | 100
>>
>> Pitty `copy_term/2` and `acyclic_term/1` do not
>> yet work with a hydra example.
>>
>> I am using a hydra variant, which puts less
>> pressure on the memory, but does benchmark
>> the built-ins in a loop, so that I see some
>>
>> numbers. My problem was that Trealla was
>> below the 1 ms mesurememt:
>> ```
>> hydra(0, _) :- !.
>> hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).
>>
>> hydra(0, A, A) :- !.
>> hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).
>>
>> /* Binary Built-ins */
>> bench :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), X = Y, fail; true)),
>>     time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
>>     time((between(1,64,_), X == Y, fail; true)),
>>     time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.
>>
>> /* Unary Built-ins */
>> bench2 :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), copy_term(X-Y,_), fail; true)),
>>     time((between(1,64,_), term_variables(X-Y,_), fail; true)),
>>     time((between(1,64,_), ground(X-Y), fail; true)),
>>     time((between(1,64,_), acyclic_term(X-Y), fail; true)),
>>     fail; true.
>>
>> /* Misc Built-ins */
>> bench3 :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
>>     fail; true.
>> ```
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Who will win the new Prolog race?
>>> SWI or Scryer? Is it enough that SWI-Prolog
>>> has teamed up with Ciao Prolog?
>>>
>>> What about resources that really can
>>> code a Prolog systems. SWI-Prolog is
>>> now doomed to have professional moron
>>>
>>> Julio Di Egidio on board. Not sure whether
>>> he will ever become a heavy committer to
>>> SWI-Prolog source. But who knows, we should
>>>
>>> also give Julio Di Egidio a chance. My
>>> gut feeling at the moment:
>>>
>>> - SWI-Prolog:
>>>    Pull Requests 10 Open / 560 Closed
>>>
>>> - Scryer Prolog:
>>>    Pull Requests 40 Open / 751 Closed
>>>
>>> In the past I would measure active committers.
>>> But the new "liveness" indicator of a Prolog
>>> system could be indeed Pull Requests.
>>>
>>> So who will win?
>>>
>>> P.S.: Data sources:
>>>
>>> https://github.com/mthom/scryer-prolog/pulls
>>>
>>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#14867 — Not a Nazi-Retard, maybe a payed Troll on Putins payroll (Was: Was Boris living under a rock, how many Fuzzy Testing tools?)

Hi,

Maybe Boris the Loris is even not a Nazi-Retard.
Maybe he is a payed Troll on Putins payroll?

Similarly Julio Di Egidio, all his posts indicate
some radical anti-capitalist stance, mostlikely

just a romantic communist that exist in the thousands
in Italy, and other south European countries.

Bye

Mild Shock schrieb:
> Hi,
> 
> Was Boris living under a rock, maybe on
> the moon in a secret Nazi Facility?
> 
> Who knows, maybe he was in another facility,
> some kind of mental asylum, until he was
> 
> hired by SWI-Prolog. How many Fuzzy Testing
> tools are there? Actually plenty:
> 
> http://fuzzing-survey.org/
> 
> Some excerpt:
> 
> Creal
> FishFuzz
> ParmeSan
> WindRanger
> loFuzz
> UAFL
> HAFL
> MobFuzz
> WINNIE
> CAFL
> DynSQL
> MirageFuzz
> IRFU
> PhyFu
> NestFuzz
> AMPFuzz
> MC2
> AIFORE
> IPEA-Fuzz
> FuzzlnMem
> CarpetFuzz
> JIGSAW
> YARPGen
> PDGF
> BEACON
> Mallory
> Fuzz
> LLM-Fuzzer
> FAST
> DAFL
> OddFuzz
> KRAKEN
> CDFUZ7
> MALinten+
> ChatAFL
> TWINFUZ7
> DeepGo
> xFUZZ
> FreeWavm
> Halo
> Select
> Titan
> Etc...
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Information for Boris the Loris, chief grammar
>> Nazi of SWI-Prolog discourse. Here is a summary
>> of my No Fuzz(y) declaration for the
>>
>> Trealla & Co. benchmarking from my previous post:
>>
>> - No fuzzy logic involved.
>>    Its all binary.
>>
>> - No fuzzy testing involved.
>>    Its all manual testing.
>>
>> - No fuzz testing involved.
>>    See above fuzzy testig.
>>
>> - No fuzzing test involved.
>>    See above fuzzy testig.
>>
>> What about the American Fuzzy Lop (AFL),
>> a free software fuzzer:
>>
>> https://en.wikipedia.org/wiki/American_Fuzzy_Lop_%28software%29
>>
>> Or was a breed of rabbit, by the
>> the name American Fuzzy Lop involved?
>>
>> https://en.wikipedia.org/wiki/American_Fuzzy_Lop
>>
>> No neither of the 2 AFLs were involved.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Now I have the feeling that Trealla implements
>>> the extreme of Jaffar's Unification, to the extend
>>> that it keeps and trails functor linking? Was
>>>
>>> studying the source of Trealla . Have also the
>>> impression that it uses a very large native stack.
>>> Is this trailing what gave it the name Trealla,
>>>
>>> despite the geographic beach location with such a name ?
>>> BTW: I have new benchmark results (*) = Dogelog:
>>>
>>> Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
>>> -- | -- | -- | -- | -- | --
>>> (=)/2 | 184 | 514 | 1750 | 210 | 53
>>> unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
>>> (==)/2 | 95 | 227 | 1265 | 250 | 65
>>> compare/3 | 86 | 221 | 1328 | 250 | 65
>>> copy_term/2 | 409 | 589 | 2579 | 108 | N/A
>>> term_variables/2 | 168 | 318 | 1469 | 166 | 90
>>> ground/1 | 40 | 120 | 516 | 70 | 121
>>> acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
>>> numbervars/3 | 170 | 327 | 1516 | 164 | 100
>>>
>>> Pitty `copy_term/2` and `acyclic_term/1` do not
>>> yet work with a hydra example.
>>>
>>> I am using a hydra variant, which puts less
>>> pressure on the memory, but does benchmark
>>> the built-ins in a loop, so that I see some
>>>
>>> numbers. My problem was that Trealla was
>>> below the 1 ms mesurememt:
>>> ```
>>> hydra(0, _) :- !.
>>> hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).
>>>
>>> hydra(0, A, A) :- !.
>>> hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).
>>>
>>> /* Binary Built-ins */
>>> bench :-
>>>     hydra(65536, X), hydra(65536, Y, Y),
>>>     time((between(1,64,_), X = Y, fail; true)),
>>>     time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
>>>     time((between(1,64,_), X == Y, fail; true)),
>>>     time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.
>>>
>>> /* Unary Built-ins */
>>> bench2 :-
>>>     hydra(65536, X), hydra(65536, Y, Y),
>>>     time((between(1,64,_), copy_term(X-Y,_), fail; true)),
>>>     time((between(1,64,_), term_variables(X-Y,_), fail; true)),
>>>     time((between(1,64,_), ground(X-Y), fail; true)),
>>>     time((between(1,64,_), acyclic_term(X-Y), fail; true)),
>>>     fail; true.
>>>
>>> /* Misc Built-ins */
>>> bench3 :-
>>>     hydra(65536, X), hydra(65536, Y, Y),
>>>     time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
>>>     fail; true.
>>> ```
>>> Bye
>>>
>>> Mild Shock schrieb:
>>>> Hi,
>>>>
>>>> Who will win the new Prolog race?
>>>> SWI or Scryer? Is it enough that SWI-Prolog
>>>> has teamed up with Ciao Prolog?
>>>>
>>>> What about resources that really can
>>>> code a Prolog systems. SWI-Prolog is
>>>> now doomed to have professional moron
>>>>
>>>> Julio Di Egidio on board. Not sure whether
>>>> he will ever become a heavy committer to
>>>> SWI-Prolog source. But who knows, we should
>>>>
>>>> also give Julio Di Egidio a chance. My
>>>> gut feeling at the moment:
>>>>
>>>> - SWI-Prolog:
>>>>    Pull Requests 10 Open / 560 Closed
>>>>
>>>> - Scryer Prolog:
>>>>    Pull Requests 40 Open / 751 Closed
>>>>
>>>> In the past I would measure active committers.
>>>> But the new "liveness" indicator of a Prolog
>>>> system could be indeed Pull Requests.
>>>>
>>>> So who will win?
>>>>
>>>> P.S.: Data sources:
>>>>
>>>> https://github.com/mthom/scryer-prolog/pulls
>>>>
>>>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>>>
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#15026 — Boris / EricGT: Why dont you tap into TAP? (Was: Boris the Loris and the American Fuzzy Lop)

Hi,

Now my post is gone, still nobody knows how
fuzzy testing works in logic programming:

Using SWI-Prolog PLUnit for Fuzzy Testing - Nice to know
https://swi-prolog.discourse.group/t/using-swi-prolog-plunit-for-fuzzy-testing/9220

Instead some bogus claim by EricGT, that
coverage would make it better. I even don't
understand what he wants to say, was this

written by an early Chat GPT-2 ? Is this even English?

The issue emerged when using code coverage (via 
library(prolog_coverage)) alongside a comprehensive set of unit tests 
(in a *.plt file, also generated by the LLM),
while aiming for 100% code coverage of a knowledge
base built with library(persistency). Without
striving for full coverage, the problem likely
wouldn’t have been detected so quickly.
https://swi-prolog.discourse.group/t/llm-generated-code-with-hallucinated-predicate-options/9391

Code coverage only measures reached code locations,
the typical tools doesn't measure the call value
patterns, of the invoke procedures, the SWI-Prolog

tooling for logic programming isn't any different.
You only see some call counts of the Byrd Box model
ports. Which says practialy not about an example

such as option value [access(readonly)].

Bye

P.S.: Hey EricGT and Boris, why dont you tap into TAP?

Since 2007, the Test and Proof (TAP) conference has
long been a leading venue for research on the
intersection of dynamic analyses, in particular
software testing, and formal verification.
https://conf.researchr.org/track/fm-2026/fm-2026-tap

Mild Shock schrieb:
> Hi,
> 
> Information for Boris the Loris, chief grammar
> Nazi of SWI-Prolog discourse. Here is a summary
> of my No Fuzz(y) declaration for the
> 
> Trealla & Co. benchmarking from my previous post:
> 
> - No fuzzy logic involved.
>    Its all binary.
> 
> - No fuzzy testing involved.
>    Its all manual testing.
> 
> - No fuzz testing involved.
>    See above fuzzy testig.
> 
> - No fuzzing test involved.
>    See above fuzzy testig.
> 
> What about the American Fuzzy Lop (AFL),
> a free software fuzzer:
> 
> https://en.wikipedia.org/wiki/American_Fuzzy_Lop_%28software%29
> 
> Or was a breed of rabbit, by the
> the name American Fuzzy Lop involved?
> 
> https://en.wikipedia.org/wiki/American_Fuzzy_Lop
> 
> No neither of the 2 AFLs were involved.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Now I have the feeling that Trealla implements
>> the extreme of Jaffar's Unification, to the extend
>> that it keeps and trails functor linking? Was
>>
>> studying the source of Trealla . Have also the
>> impression that it uses a very large native stack.
>> Is this trailing what gave it the name Trealla,
>>
>> despite the geographic beach location with such a name ?
>> BTW: I have new benchmark results (*) = Dogelog:
>>
>> Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
>> -- | -- | -- | -- | -- | --
>> (=)/2 | 184 | 514 | 1750 | 210 | 53
>> unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
>> (==)/2 | 95 | 227 | 1265 | 250 | 65
>> compare/3 | 86 | 221 | 1328 | 250 | 65
>> copy_term/2 | 409 | 589 | 2579 | 108 | N/A
>> term_variables/2 | 168 | 318 | 1469 | 166 | 90
>> ground/1 | 40 | 120 | 516 | 70 | 121
>> acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
>> numbervars/3 | 170 | 327 | 1516 | 164 | 100
>>
>> Pitty `copy_term/2` and `acyclic_term/1` do not
>> yet work with a hydra example.
>>
>> I am using a hydra variant, which puts less
>> pressure on the memory, but does benchmark
>> the built-ins in a loop, so that I see some
>>
>> numbers. My problem was that Trealla was
>> below the 1 ms mesurememt:
>> ```
>> hydra(0, _) :- !.
>> hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).
>>
>> hydra(0, A, A) :- !.
>> hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).
>>
>> /* Binary Built-ins */
>> bench :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), X = Y, fail; true)),
>>     time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
>>     time((between(1,64,_), X == Y, fail; true)),
>>     time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.
>>
>> /* Unary Built-ins */
>> bench2 :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), copy_term(X-Y,_), fail; true)),
>>     time((between(1,64,_), term_variables(X-Y,_), fail; true)),
>>     time((between(1,64,_), ground(X-Y), fail; true)),
>>     time((between(1,64,_), acyclic_term(X-Y), fail; true)),
>>     fail; true.
>>
>> /* Misc Built-ins */
>> bench3 :-
>>     hydra(65536, X), hydra(65536, Y, Y),
>>     time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
>>     fail; true.
>> ```
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Who will win the new Prolog race?
>>> SWI or Scryer? Is it enough that SWI-Prolog
>>> has teamed up with Ciao Prolog?
>>>
>>> What about resources that really can
>>> code a Prolog systems. SWI-Prolog is
>>> now doomed to have professional moron
>>>
>>> Julio Di Egidio on board. Not sure whether
>>> he will ever become a heavy committer to
>>> SWI-Prolog source. But who knows, we should
>>>
>>> also give Julio Di Egidio a chance. My
>>> gut feeling at the moment:
>>>
>>> - SWI-Prolog:
>>>    Pull Requests 10 Open / 560 Closed
>>>
>>> - Scryer Prolog:
>>>    Pull Requests 40 Open / 751 Closed
>>>
>>> In the past I would measure active committers.
>>> But the new "liveness" indicator of a Prolog
>>> system could be indeed Pull Requests.
>>>
>>> So who will win?
>>>
>>> P.S.: Data sources:
>>>
>>> https://github.com/mthom/scryer-prolog/pulls
>>>
>>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#15028 — Closing the abstract interpretation GAP (Re: Boris / EricGT: Why dont you tap into TAP?)

Hi,

The lore if there were no abstract interpretation:

"To prove the correctness of a program is to demonstrate,
through impeccable mathematical techniques, that it has
no bugs. To test a program is to run it with the expectation
of discovering bugs. These two paths to software reliability
seem to diverge from the very start: if you have proved your
program correct, it is fruitless to comb it for bugs; and
if you are testing it, that surely must be a sign that you
have given up on any hope to prove its correctness.
Accordingly, proofs and tests have, since the onset of
software engineering research, been pursued by distinct
communities using different kinds of techniques and tools."

But there are verification techniques that work with
abstract interpretation, sometimes confusingly also
called predicate abstraction. Or the requirements and

environment assumptions might be based on simplifications,
the reflecting formally the reality in the wild. In the
end formal methods might not yield the same demonstration

power than one  would expect from the above lore. So what
does the TAP conference offer:

Synergistic Techniques and Tools

     Combination of model checking, theorem proving,
         and runtime verification
     Synergies between symbolic execution, fuzzing, and formal analysis
     Test-case generation from formal specifications
     Using test execution results to guide or automate proof discovery
     Static analysis for test-suite reduction,
         prioritization, and optimization
     Verification-based and property-based testing
     Formal methods for testing AI/ML-based systems
     AI/ML techniques for enhancing formal verification and testing
     Derivation of specifications and contracts from tests
     Combination of static and dynamic analysis for
         security vulnerability detection

Have Fun!

Bye

[toc] | [prev] | [next] | [standalone]

#14871 — Fast, but not correct implementation (Was: Trealla drastically beats Scryer [Jaffar's Algorithm])

Hi,

Tricky problem, how validate unify_with_occurs_check/2 ?
If the two arguments S and T are acyclic terms, the
unify_with_occurs_check/2 can be simulated as follows:

/* simulation */
unify_with_occurs_check2(X, Y) :-
    X = Y, acyclic_term(X).

It also shows that theoretically the problem can be
solved in quasi linear time, since (=)/2 is quasi linear
and acyclic_term/1 is linear.

Now I find that unify_with_occurs_check2/2 and
unify_with_occurs_check/2 do not agree in Trealla
Prolog. For this test case for example:

/* Trealla Prolog 2.83.11 */
/* built-in */
?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
    unify_with_occurs_check(S,T).
    S = s(s(s(B,A),s(B,A)),1), A = s(B,A),
    T = s(s(s(B,A),s(B,A)),1), C = s(B,A).

/* simulation */
?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
    unify_with_occurs_check2(S,T).
    false.

One can also check with Scryer Prolog it has
also a different result for the pair S and T:

/* Scryer Prolog 0.10.0 */
/* built-in */
?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
    unify_with_occurs_check(S,T).
    false.

Bye

Mild Shock schrieb:
> Hi,
> 
> Now I have the feeling that Trealla implements
> the extreme of Jaffar's Unification, to the extend
> that it keeps and trails functor linking? Was
> 
> studying the source of Trealla . Have also the
> impression that it uses a very large native stack.
> Is this trailing what gave it the name Trealla,
> 
> despite the geographic beach location with such a name ?
> BTW: I have new benchmark results (*) = Dogelog:
> 
> Test | Java (*) | JavaScript (*) | Python (*) | Scryer | Trealla
> -- | -- | -- | -- | -- | --
> (=)/2 | 184 | 514 | 1750 | 210 | 53
> unify_with_occurs_check/2 | 213 | 601 | 2344 | N/A | 53
> (==)/2 | 95 | 227 | 1265 | 250 | 65
> compare/3 | 86 | 221 | 1328 | 250 | 65
> copy_term/2 | 409 | 589 | 2579 | 108 | N/A
> term_variables/2 | 168 | 318 | 1469 | 166 | 90
> ground/1 | 40 | 120 | 516 | 70 | 121
> acyclic_term/1 | 129 | 290 | 1281 | 386 | N/A
> numbervars/3 | 170 | 327 | 1516 | 164 | 100
> 
> Pitty `copy_term/2` and `acyclic_term/1` do not
> yet work with a hydra example.
> 
> I am using a hydra variant, which puts less
> pressure on the memory, but does benchmark
> the built-ins in a loop, so that I see some
> 
> numbers. My problem was that Trealla was
> below the 1 ms mesurememt:
> ```
> hydra(0, _) :- !.
> hydra(N, h(X, X)) :- N > 0, N0 is N-1, hydra(N0, X).
> 
> hydra(0, A, A) :- !.
> hydra(N, h(X, X), A) :- N > 0, N0 is N-1, hydra(N0, X, A).
> 
> /* Binary Built-ins */
> bench :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), X = Y, fail; true)),
>     time((between(1,64,_), unify_with_occurs_check(X, Y), fail; true)),
>     time((between(1,64,_), X == Y, fail; true)),
>     time((between(1,64,_), compare(_, X, Y), fail; true)), fail; true.
> 
> /* Unary Built-ins */
> bench2 :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), copy_term(X-Y,_), fail; true)),
>     time((between(1,64,_), term_variables(X-Y,_), fail; true)),
>     time((between(1,64,_), ground(X-Y), fail; true)),
>     time((between(1,64,_), acyclic_term(X-Y), fail; true)),
>     fail; true.
> 
> /* Misc Built-ins */
> bench3 :-
>     hydra(65536, X), hydra(65536, Y, Y),
>     time((between(1,64,_), numbervars(X-Y,0,_), fail; true)),
>     fail; true.
> ```
> Bye

[toc] | [prev] | [next] | [standalone]

#14872 — Boris the Loris saw it all comming [Weak Prolog Community] (Was: Fast, but not correct implementation)

Hi,

Yeah, Boris the Loris saw it all comming,
when he mentioned that the Prolog Community
is probably overwhelmed by Fuzzy Testing.

And I must confess, I succumbed to the guilty
pleasure of Fuzzy Testing. To find a pair S, T
I used this fuzzy testing device:

needle(S, T) :-
    between(1,1000,_),
    sample((pick(T), acyclic_term(T))),
    sample((pick(S), acyclic_term(S))),
    \+ ((unify_with_occurs_check(T, S) -> A = 1; A = 0),
        (unify_with_occurs_check2(T, S) -> B = 1; B = 0),
        A == B).

With this sample generator. It has slight
modification in pick/1, it starts with [T,_,_]
instead of [T], so that non-linear acyclic terms

are created, which is required that unification
leads to cricles. Only unify acyclic linear terms
with each other that have disjoint variables,

doesn't give cyclic terms. So this modification
is needed so that we find something at all:

sample(G) :-
    term_variables(G, L),
    repeat, maplist(pick, L),
    G, !.

pick(T) :-
    pick([T,_,_], T).

pick(L, T) :-
    random(V), N is truncate(V*3),
    (N = 0 -> T = 1;
     N = 1 -> T = s(P,Q), pick([P|L], P), pick([Q|L], Q);
     length(L, M),
     random(W), I is truncate(W*M),
     nth0(I, L, S), S = T).

Bye

Mild Shock schrieb:
> Hi,
> 
> Tricky problem, how validate unify_with_occurs_check/2 ?
> If the two arguments S and T are acyclic terms, the
> unify_with_occurs_check/2 can be simulated as follows:
> 
> /* simulation */
> unify_with_occurs_check2(X, Y) :-
>     X = Y, acyclic_term(X).
> 
> It also shows that theoretically the problem can be
> solved in quasi linear time, since (=)/2 is quasi linear
> and acyclic_term/1 is linear.
> 
> Now I find that unify_with_occurs_check2/2 and
> unify_with_occurs_check/2 do not agree in Trealla
> Prolog. For this test case for example:
> 
> /* Trealla Prolog 2.83.11 */
> /* built-in */
> ?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
>     unify_with_occurs_check(S,T).
>     S = s(s(s(B,A),s(B,A)),1), A = s(B,A),
>     T = s(s(s(B,A),s(B,A)),1), C = s(B,A).
> 
> /* simulation */
> ?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
>     unify_with_occurs_check2(S,T).
>     false.
> 
> One can also check with Scryer Prolog it has
> also a different result for the pair S and T:
> 
> /* Scryer Prolog 0.10.0 */
> /* built-in */
> ?- S = s(s(A,s(B,A)),1), T = s(s(C,C),1),
>     unify_with_occurs_check(S,T).
>     false.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#15036 — War between Scryer Prolog and Ciao Prolog [9:0 Triska vs Hermenegildo] (Was: Who will win the new Prolog race? SWI or Scryer?)

Hi,

This wasn't clear to me. That there is a
veritable war going on between Scryer Prolog
and Ciao Prolog. One protagonist

being Markus Triska, famous by the "Power
of Prolog", and the other protagonist Manuel
V. Hermenegildo somehow backed by the

Prolog education group (PEG) and SWI ? So who
will win the war, and exercise world domaninance
in constraint logic programming, based

on bogus notions such as "pure Prolog", which
are inherently inconsistent? The war is
mainly fought over teaching materials distributed,

less over tangible systems and applications.
Currently I would say the clear winner is
Markus Triska with 9 adoptions:

- As of 2018, Norbert Zeh
- As of 2018, Andrej Bauer
- As of 2018, José A. Alonso Jiménez
- As of 2019, Adam Dingle
- As of 2019, Dylan Schwesinger
- As of 2020, Andrea Schwertner Charão
- As of 2020, Alejandro Guerra Hernández
- As of 2021, Ilkka Kokkarinen
- As of 2025, Wang-Zhou Dai
https://github.com/triska/the-power-of-prolog

So it currently stands at 9:0 for Triska
vs Hermenegildo.

Bye

Mild Shock schrieb:
> Hi,
> 
> Who will win the new Prolog race?
> SWI or Scryer? Is it enough that SWI-Prolog
> has teamed up with Ciao Prolog?
> 
> What about resources that really can
> code a Prolog systems. SWI-Prolog is
> now doomed to have professional moron
> 
> Julio Di Egidio on board. Not sure whether
> he will ever become a heavy committer to
> SWI-Prolog source. But who knows, we should
> 
> also give Julio Di Egidio a chance. My
> gut feeling at the moment:
> 
> - SWI-Prolog:
>    Pull Requests 10 Open / 560 Closed
> 
> - Scryer Prolog:
>    Pull Requests 40 Open / 751 Closed
> 
> In the past I would measure active committers.
> But the new "liveness" indicator of a Prolog
> system could be indeed Pull Requests.
> 
> So who will win?
> 
> P.S.: Data sources:
> 
> https://github.com/mthom/scryer-prolog/pulls
> 
> https://github.com/SWI-Prolog/swipl-devel/pulls
> 

[toc] | [prev] | [next] | [standalone]

#15037 — Useless as the Thirty Years War / Generalized Facts (Was: War between Scryer Prolog and Ciao Prolog)

Hi,

I suspect that this war will be as bloody
and useless as the Thirty Years war, that
ravaged Europe. The victimes will be students

that learn useless stuff, because a narrow view
of logic is offered. Not to speak of the
dangerous nonsense of "pure Prolog", adding

an adjective from "logic", i.e. pure to
a thing from "computation", i.e. Prolog. Extensions
such as Liquid Haskell or Tabled Constraints,

are as useless as well. Except if you think
your knowledge and reasoning fits into
generalized facts, as we have already studied

40 years ago based on my own ProQuel:

"Following [KKR90], we call an implication of the
form A <- c_1, & .. & C_n, (n > 0) where A is a
user-defined atom and the ci are atomic constraints
a generalized fact (generalized tuple). In order
to emphasize the special nature of generalized facts,
we will in the following often use the notation
< A | C1, ..., Cn>"
https://www.research-collection.ethz.ch/entities/publication/43d19c38-122f-43d7-a8df-82e001e55075

Have Fun everybody!

Bye

P.S.: Just make a reality check from modern
AI. How large is a context. Is a context a
generalized fact, or a collection of generalizd
facts? Or maybe something else? What is it?

How long will the generalized facts idea be at the party?

Databases and Higher Types
It maybe of interest that I did not get into this
line of work from the database side. I began with
attempts to treat various classic philosophical problems
as simply as possible in a modal context, work culminating
in [4]. This, in turn, led to an interest in higher
type modal logics, connected with a desire to understand
Godel's ontological argument. My work on this can be found in.
Databases came in, unnoticed, by a side door. But they
are at the party, and it may be they will have a good time
https://www.researchgate.net/publication/225181835

But the above is possibly too benevolent, should
be challenged by AI, and especially by generative AI.

Mild Shock schrieb:
> Hi,
> 
> This wasn't clear to me. That there is a
> veritable war going on between Scryer Prolog
> and Ciao Prolog. One protagonist
> 
> being Markus Triska, famous by the "Power
> of Prolog", and the other protagonist Manuel
> V. Hermenegildo somehow backed by the
> 
> Prolog education group (PEG) and SWI ? So who
> will win the war, and exercise world domaninance
> in constraint logic programming, based
> 
> on bogus notions such as "pure Prolog", which
> are inherently inconsistent? The war is
> mainly fought over teaching materials distributed,
> 
> less over tangible systems and applications.
> Currently I would say the clear winner is
> Markus Triska with 9 adoptions:
> 
> - As of 2018, Norbert Zeh
> - As of 2018, Andrej Bauer
> - As of 2018, José A. Alonso Jiménez
> - As of 2019, Adam Dingle
> - As of 2019, Dylan Schwesinger
> - As of 2020, Andrea Schwertner Charão
> - As of 2020, Alejandro Guerra Hernández
> - As of 2021, Ilkka Kokkarinen
> - As of 2025, Wang-Zhou Dai
> https://github.com/triska/the-power-of-prolog
> 
> So it currently stands at 9:0 for Triska
> vs Hermenegildo.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Who will win the new Prolog race?
>> SWI or Scryer? Is it enough that SWI-Prolog
>> has teamed up with Ciao Prolog?
>>
>> What about resources that really can
>> code a Prolog systems. SWI-Prolog is
>> now doomed to have professional moron
>>
>> Julio Di Egidio on board. Not sure whether
>> he will ever become a heavy committer to
>> SWI-Prolog source. But who knows, we should
>>
>> also give Julio Di Egidio a chance. My
>> gut feeling at the moment:
>>
>> - SWI-Prolog:
>>    Pull Requests 10 Open / 560 Closed
>>
>> - Scryer Prolog:
>>    Pull Requests 40 Open / 751 Closed
>>
>> In the past I would measure active committers.
>> But the new "liveness" indicator of a Prolog
>> system could be indeed Pull Requests.
>>
>> So who will win?
>>
>> P.S.: Data sources:
>>
>> https://github.com/mthom/scryer-prolog/pulls
>>
>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>
> 

[toc] | [prev] | [next] | [standalone]

#15043 — The Guerilla tactics of SWI are amazing: Shell India? (Was: Who will win the new Prolog race? SWI or Scryer?)

Hi,

Pitty SWI cannot throw Markus Triska out of
their discourse forum or out of the awful
PIP forum also on discourse. He is not present there.

I am pretty sure they would do it if they
could, they are so desparate. The newest
gimmick in their fight is this pearl of warfare:

Our prototype has been implemented in SWI Prolog,
and we have already tested this early-stage system
with potential clients such as Siemens China and
Shell India. Comparison between Prolog systems as
input for the upcoming conference
https://github.com/mthom/scryer-prolog/discussions/3150

LoL, nice try Dutchies. But who believes this
inbreed nonsense. Why not compare with some
industrial strength C++ constraint solver?

And what does Shell India even mean? Historically
it has its roots indeed with the Dutchies:

formerly known as "the Royal Dutch Company for
the Exploitation of Petroleum Wells in
the Dutch East Indies"
https://en.wikipedia.org/wiki/Shell_plc

But I suspect its an international company
with head quarters in London. According to
MarketScreener, about 52.95% of Shell is
held by “Institutional” investors.

Geographical Distribution (by Country) of
Major Shareholders. Based on MarketScreener’s
breakdown of the top ~1,000 shareholders:

United States	~23.6%
United Kingdom	~17.5%
Norway	~3.28%
Switzerland	~1.56%
Canada	~1.46%
Germany	~1.06%

According to MarketScreener’s breakdown of
Shell’s top ~1,000 shareholders, India is
not listed explicitly in their “geographical
origin of shareholders” chart.

MarketScreener reports that ~44–45% of
Shell’s shares (within their top-1,000-holder
data set) are “Unknown” — meaning they can’t
clearly map them to a specific
institution or geography.

Because of that, even if some Indian investors
hold Shell shares, they may be lumped into
the “unknown” category if they aren’t among
the largest disclosed institutional holders,
or if their holdings are registered through
nominee accounts / omnibus custodians.

Bye

P.S.: Just be happy to get called Dutchies:

"Be happy they call you Dutchies, usually
we Easter Europeans get called Alocoholics
or thieves around these regions lol"
https://www.reddit.com/r/Netherlands/comments/1ehqy3a/calling_us_dutch_people_dutchies/


Mild Shock schrieb:
> Hi,
> 
> Who will win the new Prolog race?
> SWI or Scryer? Is it enough that SWI-Prolog
> has teamed up with Ciao Prolog?
> 
> What about resources that really can
> code a Prolog systems. SWI-Prolog is
> now doomed to have professional moron
> 
> Julio Di Egidio on board. Not sure whether
> he will ever become a heavy committer to
> SWI-Prolog source. But who knows, we should
> 
> also give Julio Di Egidio a chance. My
> gut feeling at the moment:
> 
> - SWI-Prolog:
>    Pull Requests 10 Open / 560 Closed
> 
> - Scryer Prolog:
>    Pull Requests 40 Open / 751 Closed
> 
> In the past I would measure active committers.
> But the new "liveness" indicator of a Prolog
> system could be indeed Pull Requests.
> 
> So who will win?
> 
> P.S.: Data sources:
> 
> https://github.com/mthom/scryer-prolog/pulls
> 
> https://github.com/SWI-Prolog/swipl-devel/pulls
> 

[toc] | [prev] | [next] | [standalone]

#15044 — The SWI7 exotism (dicts, etc..) has no value? (Was: The Guerilla tactics of SWI are amazing: Shell India?)

Hi,

There was this caboom when SWI7 introduced
dicts. But at the same time Markus Triska (Side B)
stopped contributing to SWI (Side A) ?

Side A now stands at a precarious crossroads,
its future hinging on innovations whose success
is far from guaranteed. The irony is striking:
the very battle consuming its attention is fought

over familiar, time-tested techniques,
while the exotic approaches that once promised
differentiation remain unproven. Compounding
the dilemma, one of Side A’s original core

developers—who helped shape its early trajectory—
is now contributing to Side B’s efforts,
carrying insight and experience that subtly
tilt the balance. The technical debt that

arose from earlier choices to diverge from
standard practices or established collaborations
is still manageable, yet it lingers like a
quiet undercurrent, shaping both strategy

and execution. This is a story of ambition and
ingenuity, but also of hubris: of how the
pursuit of the novel and exotic can, paradoxically,
leave an organization vulnerable, even as it bets

on a future that may or may not arrive.
- ChatGPT, 24.11.2025

Bye

Mild Shock schrieb:
> Hi,
> 
> Pitty SWI cannot throw Markus Triska out of
> their discourse forum or out of the awful
> PIP forum also on discourse. He is not present there.
> 
> I am pretty sure they would do it if they
> could, they are so desparate. The newest
> gimmick in their fight is this pearl of warfare:
> 
> Our prototype has been implemented in SWI Prolog,
> and we have already tested this early-stage system
> with potential clients such as Siemens China and
> Shell India. Comparison between Prolog systems as
> input for the upcoming conference
> https://github.com/mthom/scryer-prolog/discussions/3150
> 
> LoL, nice try Dutchies. But who believes this
> inbreed nonsense. Why not compare with some
> industrial strength C++ constraint solver?
> 
> And what does Shell India even mean? Historically
> it has its roots indeed with the Dutchies:
> 
> formerly known as "the Royal Dutch Company for
> the Exploitation of Petroleum Wells in
> the Dutch East Indies"
> https://en.wikipedia.org/wiki/Shell_plc
> 
> But I suspect its an international company
> with head quarters in London. According to
> MarketScreener, about 52.95% of Shell is
> held by “Institutional” investors.
> 
> Geographical Distribution (by Country) of
> Major Shareholders. Based on MarketScreener’s
> breakdown of the top ~1,000 shareholders:
> 
> United States    ~23.6%
> United Kingdom    ~17.5%
> Norway    ~3.28%
> Switzerland    ~1.56%
> Canada    ~1.46%
> Germany    ~1.06%
> 
> According to MarketScreener’s breakdown of
> Shell’s top ~1,000 shareholders, India is
> not listed explicitly in their “geographical
> origin of shareholders” chart.
> 
> MarketScreener reports that ~44–45% of
> Shell’s shares (within their top-1,000-holder
> data set) are “Unknown” — meaning they can’t
> clearly map them to a specific
> institution or geography.
> 
> Because of that, even if some Indian investors
> hold Shell shares, they may be lumped into
> the “unknown” category if they aren’t among
> the largest disclosed institutional holders,
> or if their holdings are registered through
> nominee accounts / omnibus custodians.
> 
> Bye
> 
> P.S.: Just be happy to get called Dutchies:
> 
> "Be happy they call you Dutchies, usually
> we Easter Europeans get called Alocoholics
> or thieves around these regions lol"
> https://www.reddit.com/r/Netherlands/comments/1ehqy3a/calling_us_dutch_people_dutchies/ 
> 
> 
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Who will win the new Prolog race?
>> SWI or Scryer? Is it enough that SWI-Prolog
>> has teamed up with Ciao Prolog?
>>
>> What about resources that really can
>> code a Prolog systems. SWI-Prolog is
>> now doomed to have professional moron
>>
>> Julio Di Egidio on board. Not sure whether
>> he will ever become a heavy committer to
>> SWI-Prolog source. But who knows, we should
>>
>> also give Julio Di Egidio a chance. My
>> gut feeling at the moment:
>>
>> - SWI-Prolog:
>>    Pull Requests 10 Open / 560 Closed
>>
>> - Scryer Prolog:
>>    Pull Requests 40 Open / 751 Closed
>>
>> In the past I would measure active committers.
>> But the new "liveness" indicator of a Prolog
>> system could be indeed Pull Requests.
>>
>> So who will win?
>>
>> P.S.: Data sources:
>>
>> https://github.com/mthom/scryer-prolog/pulls
>>
>> https://github.com/SWI-Prolog/swipl-devel/pulls
>>
> 

[toc] | [prev] | [next] | [standalone]

#15045 — My new TinyCLP is much faster [100% Prolog] (Was: The SWI7 exotism (dicts, etc..) has no value?)

Hi,

Simple test case, indirect permutation:

/* SWI-Tinker 32 bits, version 9.3.35 */
% 127,767,777 inferences, 4.456 CPU in 4.456 seconds
(100% CPU, 28673199 Lips)
true.

Ok a bit slower, but no WASM, only JavaScript!

/* Dogelog Player 2.1.4 for JavaScript */
% Zeit 4705 ms, GC 0 ms, Lips 10386607

TinyCLP is written in 100% Prolog, LoL.

Bye

P.S.: I can also beat it on 64-bit:

/*  SWI-Prolog threaded, 64 bits, version 9.3.35 */
?- time(test).
% 127,670,227 inferences, 2.031 CPU in 2.042 seconds
(99% CPU, 62853035 Lips)
true.

/* Dogelog Player 2.1.4 for Java */
?- time(test).
% Zeit 1567 ms, GC 0 ms, Lips 31186335
true.

P.S.: This was the test case:

:- use_module(library(clpfd)).

test :-
     length(L, 9),
     L ins 1..9,
     all_different(L),
     label(L),
     fail.
test.

Mild Shock schrieb:
> Hi,
> 
> There was this caboom when SWI7 introduced
> dicts. But at the same time Markus Triska (Side B)
> stopped contributing to SWI (Side A) ?
> 
> Side A now stands at a precarious crossroads,
> its future hinging on innovations whose success
> is far from guaranteed. The irony is striking:
> the very battle consuming its attention is fought
> 
> over familiar, time-tested techniques,
> while the exotic approaches that once promised
> differentiation remain unproven. Compounding
> the dilemma, one of Side A’s original core
> 
> developers—who helped shape its early trajectory—
> is now contributing to Side B’s efforts,
> carrying insight and experience that subtly
> tilt the balance. The technical debt that
> 
> arose from earlier choices to diverge from
> standard practices or established collaborations
> is still manageable, yet it lingers like a
> quiet undercurrent, shaping both strategy
> 
> and execution. This is a story of ambition and
> ingenuity, but also of hubris: of how the
> pursuit of the novel and exotic can, paradoxically,
> leave an organization vulnerable, even as it bets
> 
> on a future that may or may not arrive.
> - ChatGPT, 24.11.2025
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#15360 — Railgun CLP versus Scryer Prolog [Euler #30 Variant] (Was: Who will win the new Prolog race?)

Hi,

Sometimes my new Railgun CLP for Dogelog
Player is blazing fast. Like here:

?- time((euler(_), fail; true)).
% Zeit 1ms, GC 0ms, Lips 6675k
true.

?- euler(_L), maplist(deref, _L, R).
R = [3, 7, 1];
R = [1, 5, 3];
fail.

Compare to Scryer Prolog:

/* Scryer Prolog 0.10 */
?- time((euler(_), fail; true)).
    % CPU time: 0.203s, 326_594 inferences
    true.
?- euler(L).
    L = [1,5,3]
;  L = [3,7,1]
;  false.

The test case:

/**
  * find 3 non-zero digits such
  * that the number equals the cube sum:
  *
  * 371 = 3^3 + 7^3 + 1^3
  * 153 = 1^3 + 5^3 + 3^3
  */

% euler(-List)
euler(L) :-
    L = [X,Y,Z],
    L ins 1..9,
    100*X+10*Y+Z #= X*X*X+Y*Y*Y+Z*Z*Z,
    labeling([ff], L).

Similar problem to:
https://math.berkeley.edu/~elafandi/euler/p30/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.prolog

csiph-web