From Newsgroup: comp.lang.prolog

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
("," | ""),
digit(Digit),
number_tail(Digits, RestDigitsCount),
{
DigitsCount #= RestDigitsCount + 1,
Number #= Digit * 10 ^ RestDigitsCount + Digits
}.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
("," | ""),
digit(Digit), !,
number_tail(Digits, RestDigitsCount),
{
DigitsCount #= RestDigitsCount + 1,
Number #= Digit * 10 ^ RestDigitsCount + Digits
}.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal termination and (much rarer) existential termination.

In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812

Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
  ("," | ""),
  digit(Digit),
  number_tail(Digits, RestDigitsCount),
  {
    DigitsCount #= RestDigitsCount + 1,
    Number #= Digit * 10 ^ RestDigitsCount + Digits
  }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
  ("," | ""),
  digit(Digit), !,
  number_tail(Digits, RestDigitsCount),
  {
    DigitsCount #= RestDigitsCount + 1,
    Number #= Digit * 10 ^ RestDigitsCount + Digits
  }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

An then you have the poor guy who asked
the question, and doesn't have a single useful
take away. Possibly anyway a payed Ass-Licker:

Thank you all for the comments! https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13707072

Scryer Prolog is totalla fake nonsense.

Bye

Mild Shock schrieb:

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal termination and (much rarer) existential termination.

In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812

Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit),
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit), !,
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

In the end Scryer Prolog is a big Dunning
Kruger pyramid scheme:

The Dunning–Kruger effect is a cognitive bias in
which people with limited competence in a particular
domain overestimate their abilities. It was first
described by the psychologists David Dunning and
Justin Kruger in 1999.
https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

Its a pyramid scheme, because its based on incompetent
people on different levels,

and its all about to grab some money:

Lisp and Prolog appear in the European
Commission's eGovernment Benchmark 2025 https://github.com/mthom/scryer-prolog/discussions/2994

Just nonsense, nothing else...

Bye

Mild Shock schrieb:

Hi,

An then you have the poor guy who asked
the question, and doesn't have a single useful
take away. Possibly anyway a payed Ass-Licker:

Thank you all for the comments! https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13707072

Scryer Prolog is totalla fake nonsense.

Bye

Mild Shock schrieb:

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal
termination and (much rarer) existential termination.
;
In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812


Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit),
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit), !,
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

?- op(699,xf,>.).
true.
?- writeq(>(>.(a),b)).
outputs("a>. >b"), unexpected. https://github.com/trealla-prolog/trealla/issues/834#issue-3216005033

Why unexpected? The >. is not a terminating period:

/* GNU Prolog 1.5.0 (64 bits) */
?- op(699,xf,>.).
yes
?- X = (a>. > b).
X = (a>. >b)

The period has to be single-standing, no preceeding graphic
characters, to be a candidate for a terminating period.

Bye

Mild Shock schrieb:

Hi,

In the end Scryer Prolog is a big Dunning
Kruger pyramid scheme:

The Dunning–Kruger effect is a cognitive bias in
which people with limited competence in a particular
domain overestimate their abilities. It was first
described by the psychologists David Dunning and
Justin Kruger in 1999.
https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

Its a pyramid scheme, because its based on incompetent
people on different levels,

and its all about to grab some money:

Lisp and Prolog appear in the European
Commission's eGovernment Benchmark 2025 https://github.com/mthom/scryer-prolog/discussions/2994

Just nonsense, nothing else...

Bye

Mild Shock schrieb:

Hi,

An then you have the poor guy who asked
the question, and doesn't have a single useful
take away. Possibly anyway a payed Ass-Licker:

Thank you all for the comments!
https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13707072


Scryer Prolog is totalla fake nonsense.

Bye

Mild Shock schrieb:

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal
termination and (much rarer) existential termination.
;
In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812


Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit),
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit), !,
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Now this line of code made me both smile and cry:

doge.pl: $(PROG)
$(file >$@,false :- \+true. ?- ['$<'],$(MAIN).)

Why define false so complicated:

false :- \+ true.

Why not define it as follows:

false :- fail.

The stack overflow user by the name false who
institutionalized false/0 as a synonym for fail/0
by way of ISO Prolog Corrigendum 2:

8.15.5.4 Examples
false.
Fails.

https://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#false

Mild Shock schrieb:

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal termination and (much rarer) existential termination.

In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812

Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit),
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit), !,
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Some Prolog systems have only:

true/0
fail/0

Then some other Prolog systems have:

true/0
fail/0
otherwise/0 (synonyme for true/0)
false/0 (synonyme for fail/0)

Why not include otherwise/0 as well in the ISO
core standard, it can be used to make if-then-else
more readable. Like instead of writing:

(X = red -> write('Roses');
X = blue -> write('Violets');
write('Onions')).

One would write:

(X = red -> write('Roses');
X = blue -> write('Violets');
otherwise -> write('Onions')).

Bye

Mild Shock schrieb:

Now this line of code made me both smile and cry:

doge.pl: $(PROG)
    $(file >$@,false :- \+true. ?- ['$<'],$(MAIN).)

Why define false so complicated:

     false :- \+ true.

Why not define it as follows:

     false :- fail.

The stack overflow user by the name false who
institutionalized false/0 as a synonym for fail/0
by way of ISO Prolog Corrigendum 2:

8.15.5.4 Examples
false.
   Fails.

https://www.complang.tuwien.ac.at/ulrich/iso-prolog/dtc2#false

Mild Shock schrieb:

Hi,

Well Ulrich Neumerkel is of course the biggest
quack of all as usual:

order of clause can only influence termination properties

This depends on your definition of termination. There is universal
termination and (much rarer) existential termination.
;
In a pure, monotonic program, order of clauses does not even

influence > universal termination. That is, a goal G_0, false will
terminate in

the very same way regardless of the clause order. (For a goal G_0,
false both universal and existential termination are the same.)

https://github.com/mthom/scryer-prolog/discussions/3004#discussioncomment-13704812


Complete idiots, nothing to do with terminations. DCGs
that consume characters do anyway terminate. What is he talking about?

Bye

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit),
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

If DCGs had a cut, one would any way do:

number_tail(Number, DigitsCount) -->
   ("," | ""),
   digit(Digit), !,
   number_tail(Digits, RestDigitsCount),
   {
     DigitsCount #= RestDigitsCount + 1,
     Number #= Digit * 10 ^ RestDigitsCount + Digits
   }.
number_tail(0, 0) --> [].

Push the determinancy into the DCG. Otherwise you have
an explosion of choice points, and a lot of things go
totally wrong.

But the new DCG standard has no cut (!)/2.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Thats a nice test case, failed by Trealla Prolog
and Scryer Prolog. Currently working on fixing it
for Dogelog Player and Jekejeke Prolog:

/* SWI-Prolog 9.3.26 */

% ?- member(N,[5,10,15]), time(test3(N)), fail; true.
% % 2,007 inferences, 0.000 CPU in 0.000 seconds (0% CPU, Infinite Lips)
% % 2,012 inferences, 0.000 CPU in 0.000 seconds (0% CPU, Infinite Lips)
% % 2,017 inferences, 0.000 CPU in 0.001 seconds (0% CPU, Infinite Lips)
% true.

/* Trealla Prolog 2.80.4 */

% ?- member(N,[5,10,15]), time(test3(N)), fail; true.
% % Time elapsed 0.001s, 3020 Inferences, 4.741 MLips
% % Time elapsed 0.019s, 3030 Inferences, 0.159 MLips
% % Time elapsed 0.511s, 3040 Inferences, 0.006 MLips
% true.

/* Scryer Prolog 0.9.4-547 */

% ?- member(N,[5,10,15]), time(test3(N)), fail; true.
% % CPU time: 0.002s, 7_120 inferences
% % CPU time: 0.053s, 7_135 inferences
% % CPU time: 1.657s, 7_150 inferences
% true.

The test case:

hydra(0, n) :- !.
hydra(N, s(X,X)) :-
M is N-1,
hydra(M, X).

hydra2(0, _) :- !.
hydra2(N, s(X,X)) :-
M is N-1,
hydra2(M, X).

test3(N) :-
hydra(N,X), hydra2(1,Y),
between(1,1000,_), unify_with_occurs_check(X, Y), fail; true.

Mild Shock schrieb:

Woa! This nonsense really made my day:

https://github.com/mthom/scryer-prolog/discussions/3004

It starts with, where somebody "tried" a declarative DCG
using constraint logic programming:

number_tail(0, 0) --> [].
number_tail(Number, DigitsCount) -->
  ("," | ""),
  digit(Digit),
  number_tail(Digits, RestDigitsCount),
  {
    DigitsCount #= RestDigitsCount + 1,
    Number #= Digit * 10 ^ RestDigitsCount + Digits
  }.

He then noticed that its not deterministic. And since
it is not deterministic, clause ordering changes the
result when onced via once/1.

LoL

--- Synchronet 3.21a-Linux NewsLink 1.2