It is clear that the clown UWN downvotes this feature request, because
UWN opposes a living standard prolog. Scryer Prolog already implements
living standard, since it accepts for example foo(+,-,-) and current_op(X,Y,+).

Why stop half way, and implement living standard prolog only 50%.
SWI-Prolog is much better off, it has a larger stopper set. And therefore
can read TPTP Syntax. Scryer Prolog on the other hand has only implemented

the strategy of the living standard half way.

Feature request , add period to the operator stoppers #1297
https://github.com/mthom/scryer-prolog/issues/1297

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 12:09:46 UTC+1:
> Ok Scryer Prolog already handles this case:
>
> ?- [user].
> foo(+, -, -).
> ^D
>
> It doesn't bark. So what is missing? Why does
> TPTP Syntax not work?
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 12:06:05 UTC+1:
> > There is no straight forward way to convert a
> > SWI-Prolog text into a Scryer Prolog text?
> >
> > listing/[0,1] doesn't work:
> >
> > ?- [user].
> > foo(+,-,-).
> > ^D
> > ?- listing(foo/3).
> > foo(+, -, -).
> >
> > On first sight I though listing would work,
> > because SWI-Prolog is notorious for inserting
> >
> > (f), for example I see this here:
> >
> > ?- X = (- - -).
> > X = - - (-).
> >
> > But interestingly it does already not insert
> > (f) in the foo/3 case. Cool.
> > Mostowski Collapse schrieb am Donnerstag, 24. Februar 2022 um 17:17:38 UTC+1:
> > > Being lazy and stupid is no excuse.
> > > Having Scryer Prolog requiring me to write:
> > >
> > > : -mode decomp((+),(-),(-)).
> > >
> > > is the most idiotic thing in Prolog history.

Ha Ha, GNU Prolog cant do it either:

?- op(200,fy,!).
yes
?- X = foo(!).
X = foo(!)
?- X = (foo :- !).
uncaught exception: error(syntax_error('user_input:1 (char:80) expression expected or previous operator needs brackets'),read_term/3)

On the other hand TauProlog can do it:

?- op(200,fy,!).
true.
?- X = foo(!).
X = foo(!)
?- X = (foo :- !).
X = (foo:-!).

Was only testing the stopper ')'. It seems the stopper
')' is differently handled in GNU Prolog, depending on whether
the expression is simple as in foo(!) or more complex

as in (foo :- !). This could be the cause of the reduced
flexibility in parsing of GNU Prolog. Possibly Scryer Prolog
adopted the same inflexibility.

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 12:35:28 UTC+1:
> It is clear that the clown UWN downvotes this feature request, because
> UWN opposes a living standard prolog. Scryer Prolog already implements
> living standard, since it accepts for example foo(+,-,-) and current_op(X,Y,+).
>
> Why stop half way, and implement living standard prolog only 50%.
> SWI-Prolog is much better off, it has a larger stopper set. And therefore
> can read TPTP Syntax. Scryer Prolog on the other hand has only implemented
>
> the strategy of the living standard half way.
>
> Feature request , add period to the operator stoppers #1297
> https://github.com/mthom/scryer-prolog/issues/1297
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 12:09:46 UTC+1:
> > Ok Scryer Prolog already handles this case:
> >
> > ?- [user].
> > foo(+, -, -).
> > ^D
> >
> > It doesn't bark. So what is missing? Why does
> > TPTP Syntax not work?
> > Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 12:06:05 UTC+1:
> > > There is no straight forward way to convert a
> > > SWI-Prolog text into a Scryer Prolog text?
> > >
> > > listing/[0,1] doesn't work:
> > >
> > > ?- [user].
> > > foo(+,-,-).
> > > ^D
> > > ?- listing(foo/3).
> > > foo(+, -, -).
> > >
> > > On first sight I though listing would work,
> > > because SWI-Prolog is notorious for inserting
> > >
> > > (f), for example I see this here:
> > >
> > > ?- X = (- - -).
> > > X = - - (-).
> > >
> > > But interestingly it does already not insert
> > > (f) in the foo/3 case. Cool.
> > > Mostowski Collapse schrieb am Donnerstag, 24. Februar 2022 um 17:17:38 UTC+1:
> > > > Being lazy and stupid is no excuse.
> > > > Having Scryer Prolog requiring me to write:
> > > >
> > > > : -mode decomp((+),(-),(-)).
> > > >
> > > > is the most idiotic thing in Prolog history.

BTW: Living standard Prolog is probably the correct name to address
the issue. Scryer Prolog also fails this living standard Prolog test:

$ target/release/scryer-prolog
?- op(200,fy,!).
true.
?- X = foo(!).
X = foo(!).
?- X = (foo :- !).
caught: error(syntax_error(incomplete_reduction),read_term/3:1)

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:02:54 UTC+1:
> Ha Ha, GNU Prolog cant do it either:
>
> ?- op(200,fy,!).
> yes
> ?- X = foo(!).
> X = foo(!)
> ?- X = (foo :- !).
> uncaught exception: error(syntax_error('user_input:1 (char:80) expression expected or previous operator needs brackets'),read_term/3)
>
> On the other hand TauProlog can do it:
>
> /* Tau Prolog 0.3.2 (beta) */
> ?- op(200,fy,!).
> true.
> ?- X = foo(!).
> X = foo(!)
> ?- X = (foo :- !).
> X = (foo:-!).
>
> Was only testing the stopper ')'. It seems the stopper
> ')' is differently handled in GNU Prolog, depending on whether
> the expression is simple as in foo(!) or more complex
>
> as in (foo :- !). This could be the cause of the reduced
> flexibility in parsing of GNU Prolog. Possibly Scryer Prolog
> adopted the same inflexibility.

Is the living standard Prolog a bad thing. Rather not,
it rather safeguards to some problems that Prolog
always bugs. For example a pair A-B might be rather

a bad idea, because ‘-’ is infix and prefix. Here it works fine:

?- X = (!-a), write_canonical(X), nl.
-(!,a)
X = !-a.

?- X = (!,a), write_canonical(X), nl.
','(!,a)
X = (!, a).

But it happened that I loaded the TPTP syntax, and things started going wrong:

/* SWI-Prolog */
?- op(200,fy,!).
true.

?- X = (!-a), write_canonical(X), nl.
!(-(a))
X = !-a.

?- X = (!,a), write_canonical(X), nl.
','(!,a)
X = ((!), a).

But at least the stopper ',' helps that the (A,B) pair still works.

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:04:24 UTC+1:
> BTW: Living standard Prolog is probably the correct name to address
> the issue. Scryer Prolog also fails this living standard Prolog test:
>
> $ target/release/scryer-prolog
> ?- op(200,fy,!).
> true.
> ?- X = foo(!).
> X = foo(!).
> ?- X = (foo :- !).
> caught: error(syntax_error(incomplete_reduction),read_term/3:1)
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:02:54 UTC+1:
> > Ha Ha, GNU Prolog cant do it either:
> >
> > ?- op(200,fy,!).
> > yes
> > ?- X = foo(!).
> > X = foo(!)
> > ?- X = (foo :- !).
> > uncaught exception: error(syntax_error('user_input:1 (char:80) expression expected or previous operator needs brackets'),read_term/3)
> >
> > On the other hand TauProlog can do it:
> >
> > /* Tau Prolog 0.3.2 (beta) */
> > ?- op(200,fy,!).
> > true.
> > ?- X = foo(!).
> > X = foo(!)
> > ?- X = (foo :- !).
> > X = (foo:-!).
> >
> > Was only testing the stopper ')'. It seems the stopper
> > ')' is differently handled in GNU Prolog, depending on whether
> > the expression is simple as in foo(!) or more complex
> >
> > as in (foo :- !). This could be the cause of the reduced
> > flexibility in parsing of GNU Prolog. Possibly Scryer Prolog
> > adopted the same inflexibility.

In Scryer Prolog I cannot use (A,B) either:

?- op(200,fy,!).
true.

?- X = (!-a), write_canonical(X), nl.
!(-(a))
X = !- a.

?- X = (!,a), write_canonical(X), nl.
caught: error(syntax_error(incomplete_reduction),read_term/3:1)

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 16:55:17 UTC+1:
> Is the living standard Prolog a bad thing. Rather not,
> it rather safeguards to some problems that Prolog
> always bugs. For example a pair A-B might be rather
>
> a bad idea, because ‘-’ is infix and prefix. Here it works fine:
>
> ?- X = (!-a), write_canonical(X), nl.
> -(!,a)
> X = !-a.
>
> ?- X = (!,a), write_canonical(X), nl.
> ','(!,a)
> X = (!, a).
>
> But it happened that I loaded the TPTP syntax, and things started going wrong:
>
> /* SWI-Prolog */
> ?- op(200,fy,!).
> true.
>
> ?- X = (!-a), write_canonical(X), nl.
> !(-(a))
> X = !-a.
>
> ?- X = (!,a), write_canonical(X), nl.
> ','(!,a)
> X = ((!), a).
>
> But at least the stopper ',' helps that the (A,B) pair still works.
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:04:24 UTC+1:
> > BTW: Living standard Prolog is probably the correct name to address
> > the issue. Scryer Prolog also fails this living standard Prolog test:
> >
> > $ target/release/scryer-prolog
> > ?- op(200,fy,!).
> > true.
> > ?- X = foo(!).
> > X = foo(!).
> > ?- X = (foo :- !).
> > caught: error(syntax_error(incomplete_reduction),read_term/3:1)
> > Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:02:54 UTC+1:
> > > Ha Ha, GNU Prolog cant do it either:
> > >
> > > ?- op(200,fy,!).
> > > yes
> > > ?- X = foo(!).
> > > X = foo(!)
> > > ?- X = (foo :- !).
> > > uncaught exception: error(syntax_error('user_input:1 (char:80) expression expected or previous operator needs brackets'),read_term/3)
> > >
> > > On the other hand TauProlog can do it:
> > >
> > > /* Tau Prolog 0.3.2 (beta) */
> > > ?- op(200,fy,!).
> > > true.
> > > ?- X = foo(!).
> > > X = foo(!)
> > > ?- X = (foo :- !).
> > > X = (foo:-!).
> > >
> > > Was only testing the stopper ')'. It seems the stopper
> > > ')' is differently handled in GNU Prolog, depending on whether
> > > the expression is simple as in foo(!) or more complex
> > >
> > > as in (foo :- !). This could be the cause of the reduced
> > > flexibility in parsing of GNU Prolog. Possibly Scryer Prolog
> > > adopted the same inflexibility.

So a living standard Prolog has a lot of advantages.
There are much more advantages. I don't think Tau
Prolog should change anything.

It will break TPTP Syntax, like here:

Cannot consult file
https://github.com/mthom/scryer-prolog/issues/1289

So its not a bug. The ISO core standard is nonsense. Its
better to implement a living standard Prolog, than strictly
follow ISO core standard, because there are a lot of

legacy Prolog texts, that need to be also supported. You
have to publish a legacy to ISO converter on your Scryer
Prolog website, if you want to use legay Prolog texts.

But I nowehere find such a utility. Scryer Prolog leaves
their users alone. On the other hand Tau Prolog can use
legacy Prolog texts directly. This is a plus and thumbs up

for TauProlog that it doesn't follow such nonsense!

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 16:56:15 UTC+1:
> In Scryer Prolog I cannot use (A,B) either:
> ?- op(200,fy,!).
> true.
>
> ?- X = (!-a), write_canonical(X), nl.
> !(-(a))
> X = !- a.
> ?- X = (!,a), write_canonical(X), nl.
> caught: error(syntax_error(incomplete_reduction),read_term/3:1)
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 16:55:17 UTC+1:
> > Is the living standard Prolog a bad thing. Rather not,
> > it rather safeguards to some problems that Prolog
> > always bugs. For example a pair A-B might be rather
> >
> > a bad idea, because ‘-’ is infix and prefix. Here it works fine:
> >
> > ?- X = (!-a), write_canonical(X), nl.
> > -(!,a)
> > X = !-a.
> >
> > ?- X = (!,a), write_canonical(X), nl.
> > ','(!,a)
> > X = (!, a).
> >
> > But it happened that I loaded the TPTP syntax, and things started going wrong:
> >
> > /* SWI-Prolog */
> > ?- op(200,fy,!).
> > true.
> >
> > ?- X = (!-a), write_canonical(X), nl.
> > !(-(a))
> > X = !-a.
> >
> > ?- X = (!,a), write_canonical(X), nl.
> > ','(!,a)
> > X = ((!), a).
> >
> > But at least the stopper ',' helps that the (A,B) pair still works.
> > Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:04:24 UTC+1:
> > > BTW: Living standard Prolog is probably the correct name to address
> > > the issue. Scryer Prolog also fails this living standard Prolog test:
> > >
> > > $ target/release/scryer-prolog
> > > ?- op(200,fy,!).
> > > true.
> > > ?- X = foo(!).
> > > X = foo(!).
> > > ?- X = (foo :- !).
> > > caught: error(syntax_error(incomplete_reduction),read_term/3:1)
> > > Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 13:02:54 UTC+1:
> > > > Ha Ha, GNU Prolog cant do it either:
> > > >
> > > > ?- op(200,fy,!).
> > > > yes
> > > > ?- X = foo(!).
> > > > X = foo(!)
> > > > ?- X = (foo :- !).
> > > > uncaught exception: error(syntax_error('user_input:1 (char:80) expression expected or previous operator needs brackets'),read_term/3)
> > > >
> > > > On the other hand TauProlog can do it:
> > > >
> > > > /* Tau Prolog 0.3.2 (beta) */
> > > > ?- op(200,fy,!).
> > > > true.
> > > > ?- X = foo(!).
> > > > X = foo(!)
> > > > ?- X = (foo :- !).
> > > > X = (foo:-!).
> > > >
> > > > Was only testing the stopper ')'. It seems the stopper
> > > > ')' is differently handled in GNU Prolog, depending on whether
> > > > the expression is simple as in foo(!) or more complex
> > > >
> > > > as in (foo :- !). This could be the cause of the reduced
> > > > flexibility in parsing of GNU Prolog. Possibly Scryer Prolog
> > > > adopted the same inflexibility.

Ok I found a way to convert legacy Prolog text into Scryer Prolog
format. The steps are relatively simple:

1) Consult the Prolog text in SWI-Prolog

2) Call listing/[0,1] in SWI-Prolog

SWI-Prolog puts an additional parenthesis around operators, even
when they were not there during input. So for example I get now:

?- listing(prove2/_).
prove2(?[X]:Fml, UnExp, Lits, FreeV, VarLim) :-
VarLim>0,
(!),
copy_term((X, Fml, FreeV),
(X1, Fml1, FreeV)),
append(UnExp, [?[X]:Fml], UnExp1),
VarLim2 is VarLim+ -1,
prove2(Fml1,
UnExp1,
Lits,
[X1|FreeV],
VarLim2)

The SWI-Prolog output seems to have sufficient quality so that
I can run it with Scryer Prolog, redoing my benchmarks gives me:

?- time((between(1,10,_), test(time, seq), fail; true)).
% CPU time: 0.435s
true.
?- time((between(1,10,_), test(time, tap), fail; true)).
% CPU time: 0.197s
true.

Thanks to this automatic conversion, I am now willingly to test more
TPTP stuff. Like for example to test also leanTap= and leanSeq= as
I did for SWI-Prolog WASM.

Its the most crazy thing I have ever seen, that such
a conversion step is necessary. Every sane person
might ask the following question:

- Why can SWI-Prolog parse it in the first place,
obviously correctly, since the code executes ok?

- And why can't Scryer Prolog parse it in the
first place? What is the ISO core standard worth,

when it cannot read legacy Prolog texts, that
is obviously unambigiously readable?

So many question marks now!!!

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 21:39:04 UTC+1:
> Ok I found a way to convert legacy Prolog text into Scryer Prolog
> format. The steps are relatively simple:
>
> 1) Consult the Prolog text in SWI-Prolog
>
> 2) Call listing/[0,1] in SWI-Prolog
>
> SWI-Prolog puts an additional parenthesis around operators, even
> when they were not there during input. So for example I get now:
>
> ?- listing(prove2/_).
> prove2(?[X]:Fml, UnExp, Lits, FreeV, VarLim) :-
> VarLim>0,
> (!),
> copy_term((X, Fml, FreeV),
> (X1, Fml1, FreeV)),
> append(UnExp, [?[X]:Fml], UnExp1),
> VarLim2 is VarLim+ -1,
> prove2(Fml1,
> UnExp1,
> Lits,
> [X1|FreeV],
> VarLim2)
>
> The SWI-Prolog output seems to have sufficient quality so that
> I can run it with Scryer Prolog, redoing my benchmarks gives me:
> ?- time((between(1,10,_), test(time, seq), fail; true)).
> % CPU time: 0.435s
> true.
> ?- time((between(1,10,_), test(time, tap), fail; true)).
> % CPU time: 0.197s
> true.
>
> Thanks to this automatic conversion, I am now willingly to test more
> TPTP stuff. Like for example to test also leanTap= and leanSeq= as
> I did for SWI-Prolog WASM.

It seems I must retract my hands clapping and tend now to
be more agnostic what Tau Prolog does, and wouldn't care less
what Scryer Prolog thinks Tau Prolog should do.

I could relieve myself from this madness!!!! A madness of
different Prolog camps fighting each other. The remaining
question is only whether I should do something for

Dogelog player or formerly Jekejeke Prolog. But if SWI-Prolog
can do the conversion I don't see any need to do it. Maybe
introduce a write option in formerly Jekejeke Prolog in the

short run, and in the long run maybe move also some of these
features to Dogelog player. Dogelog player has anyway not
yet pretty printing. So when introducing pretty printing

this matters can be rethought. Lets see. Not yet sure.
At least this madness has stopped!!! Huray!!! Jippie!!!

Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 21:46:08 UTC+1:
> Its the most crazy thing I have ever seen, that such
> a conversion step is necessary. Every sane person
> might ask the following question:
>
> - Why can SWI-Prolog parse it in the first place,
> obviously correctly, since the code executes ok?
>
> - And why can't Scryer Prolog parse it in the
> first place? What is the ISO core standard worth,
>
> when it cannot read legacy Prolog texts, that
> is obviously unambigiously readable?
>
> So many question marks now!!!
> Mostowski Collapse schrieb am Freitag, 25. Februar 2022 um 21:39:04 UTC+1:
> > Ok I found a way to convert legacy Prolog text into Scryer Prolog
> > format. The steps are relatively simple:
> >
> > 1) Consult the Prolog text in SWI-Prolog
> >
> > 2) Call listing/[0,1] in SWI-Prolog
> >
> > SWI-Prolog puts an additional parenthesis around operators, even
> > when they were not there during input. So for example I get now:
> >
> > ?- listing(prove2/_).
> > prove2(?[X]:Fml, UnExp, Lits, FreeV, VarLim) :-
> > VarLim>0,
> > (!),
> > copy_term((X, Fml, FreeV),
> > (X1, Fml1, FreeV)),
> > append(UnExp, [?[X]:Fml], UnExp1),
> > VarLim2 is VarLim+ -1,
> > prove2(Fml1,
> > UnExp1,
> > Lits,
> > [X1|FreeV],
> > VarLim2)
> >
> > The SWI-Prolog output seems to have sufficient quality so that
> > I can run it with Scryer Prolog, redoing my benchmarks gives me:
> > ?- time((between(1,10,_), test(time, seq), fail; true)).
> > % CPU time: 0.435s
> > true.
> > ?- time((between(1,10,_), test(time, tap), fail; true)).
> > % CPU time: 0.197s
> > true.
> >
> > Thanks to this automatic conversion, I am now willingly to test more
> > TPTP stuff. Like for example to test also leanTap= and leanSeq= as
> > I did for SWI-Prolog WASM.

Maybe I should also add this to the latest Dogelog player
milestone. I have this in formerly Jekejeke Prolog.
But I didn't check yet Scryer Prolog nor Tau-Prolog.

Also Dogelog player has not yet call/n and also
not yet predsort/3. There is a little asymmetry in Prolog,
that there is no number_compare/3 for the number

comparison, whereas we have compare/3 for syntactic
comparison. If one use a predicate that adheres to the
argument arrangement and return value of compare/3,

you could use it with predsort/3 of SWI-Prolog provenience:

?- sort([1, 1.0], L).
L = [1.0, 1].

?- predsort(number_compare, [1, 1.0], L).
L = [1].

I used this implementation, but I don’t know whether I
should recommend it:

number_compare(R, X, Y) :- X < Y, !, R = < .
number_compare(R, X, Y) ;- X =:= Y, !, R = = .
number_compare(>, _, _).

Using a comparator round(sign(N1 - N2)) would also work, if predsort/3
would understand -1, 0 and 1. Not sure whether it does. The point would
be that a Prolog systems provides this number_compare/3 natively. The

reason is that evaluating N1 - N2 can be quite expensive, it will create a new
number object. Whereas number comparison can be done more cheaply. Its
also possible to lift number_compare/3 to Prolog terms. So we are in the mist

of chaos, or a proliferation of possible design decisions.

Mostowski Collapse schrieb am Freitag, 4. März 2022 um 18:08:04 UTC+1:
> Maybe I should also add this to the latest Dogelog player
> milestone. I have this in formerly Jekejeke Prolog.
> But I didn't check yet Scryer Prolog nor Tau-Prolog.
>
> Also Dogelog player has not yet call/n and also
> not yet predsort/3. There is a little asymmetry in Prolog,
> that there is no number_compare/3 for the number
>
> comparison, whereas we have compare/3 for syntactic
> comparison. If one use a predicate that adheres to the
> argument arrangement and return value of compare/3,
>
> you could use it with predsort/3 of SWI-Prolog provenience:
>
> ?- sort([1, 1.0], L).
> L = [1.0, 1].
>
> ?- predsort(number_compare, [1, 1.0], L).
> L = [1].
>
> I used this implementation, but I don’t know whether I
> should recommend it:
>
> number_compare(R, X, Y) :- X < Y, !, R = < .
> number_compare(R, X, Y) ;- X =:= Y, !, R = = .
> number_compare(>, _, _).