Is it a sign, that the SWI-Prolog parser/unparser wasn’t built
from a master class in test driven development? Well testing
input/output in Prolog system can be a headache.

I have a new take on a corresponding harness. This is quite
interesting. It is a harness tailored towards Dogelog Player,
which unlike formerly Jekejeke Prolog does NOT ASSUME:

- Memory Files: For Dogelog Player we do NOT ASSUME
to have access as we did in formerly Jekejeke Prolog. So
a memory file is simulated by memory.txt, ordinary file.

- setup_call_cleanup/3: For Dogelog Player we currently do
NOT ASSUME, although such a predicate might come later.
In formerly Jekejeke Prolog the harness uses this.

So how do we check with output to? Here is our new take:

/**
* with_text_to(A, G):
* The predicate succeeds whenever the goal G succeeds and
* unifies A with its text output.
*/
% with_text_to(-Atom, +Goal)
with_text_to(A, G) :-
current_output(S),
try_call_finally(
redirect_text_output,
G,
fetch_text_output(S, A)).

% redirect_text_output
redirect_text_output :-
open('memory.txt', write, S),
set_output(S).

% fetch_text_output(+Stream, -Atom)
fetch_text_output(S, A) :-
current_output(T),
close(T),
open('memory.txt', read, R),
get_atom(R, -1, A),
close(R),
set_output(S).

And then:

/**
* try_call_finally(T, G, F):
* The predicate succeeds whenever G succeeds. The goal T is
* called for the call and redo port. The goal F is called for
* the exit, fail and error port.
*/
% try_call_finally(+Goal, +Goal, +Goal)
try_call_finally(T, G, F) :-
(T; F, fail),
'$MARK'(X),
catch(G, E, (F, throw(E))),
'$MARK'(Y),
(X == Y -> !, F; (F; T, fail)).

It should be noted that we added a new built-in
to Dogelog Player, get_atom/3. This is a kind of
read_line/2, but with a different semantic than the

read line we had so far. get_atom/3 can be used
to read line via get_atom(S, 0'\n, X), and it can
be also used to read full files get_atom(S, -1, X).

The difference to our old read line, when using
get_atom(S, 0'\n, X) it will include the 0'\n in
the result. A big surprise was now the harness

for with input from. It uses change_arg/3 !!!

/**
* with_text_from(A, G):
* The predicate succeeds whenever the goal G succeeds and
* provides A as its text input.
*/
% with_text_from(+Atom, +Goal)
with_text_from(A, G) :-
current_input(S),
H = v(A),
try_call_finally(
redirect_text_input(H),
G,
advance_text_input(S, H)).

% redirect_text_input(+Compound)
redirect_text_input(H) :-
arg(1, H, A),
open('memory.txt', write, S),
put_atom(S, A),
close(S),
open('memory.txt', read, T),
set_input(T).

% advance_text_input(+Stream, +Compound)
advance_text_input(S, H) :-
current_input(T),
get_atom(T, -1, A),
close(T),
change_arg(1, H, A),
set_input(S).

The source code of these Dogelog Player testing utilities
is open sourced in a new folder dogelog_comply:

Prolog Text "charsio" - Compliance Dogelog Spieler
http://pages.xlog.ch/littab/doclet/docs/10_samples/04_doge_comply/reference/harness/charsio.html

Mostowski Collapse schrieb:
> Is it a sign, that the SWI-Prolog parser/unparser wasn’t built
> from a master class in test driven development? Well testing
> input/output in Prolog system can be a headache.
>
> I have a new take on a corresponding harness. This is quite
> interesting. It is a harness tailored towards Dogelog Player,
> which unlike formerly Jekejeke Prolog does NOT ASSUME:
>
> - Memory Files: For Dogelog Player we do NOT ASSUME
> to have access as we did in formerly Jekejeke Prolog. So
> a memory file is simulated by memory.txt, ordinary file.
>
> - setup_call_cleanup/3: For Dogelog Player we currently do
> NOT ASSUME, although such a predicate might come later.
> In formerly Jekejeke Prolog the harness uses this.
>
> So how do we check with output to? Here is our new take:
>
> /**
> * with_text_to(A, G):
> * The predicate succeeds whenever the goal G succeeds and
> * unifies A with its text output.
> */
> % with_text_to(-Atom, +Goal)
> with_text_to(A, G) :-
> current_output(S),
> try_call_finally(
> redirect_text_output,
> G,
> fetch_text_output(S, A)).
>
> % redirect_text_output
> redirect_text_output :-
> open('memory.txt', write, S),
> set_output(S).
>
> % fetch_text_output(+Stream, -Atom)
> fetch_text_output(S, A) :-
> current_output(T),
> close(T),
> open('memory.txt', read, R),
> get_atom(R, -1, A),
> close(R),
> set_output(S).
>
> And then:
>
> /**
> * try_call_finally(T, G, F):
> * The predicate succeeds whenever G succeeds. The goal T is
> * called for the call and redo port. The goal F is called for
> * the exit, fail and error port.
> */
> % try_call_finally(+Goal, +Goal, +Goal)
> try_call_finally(T, G, F) :-
> (T; F, fail),
> '$MARK'(X),
> catch(G, E, (F, throw(E))),
> '$MARK'(Y),
> (X == Y -> !, F; (F; T, fail)).
>

This is probably not the canary in the coal mine for the
suspected bugs. One can check by himself/herself, not
a single use of fy or yfx operator:

ALE – Attribute Logic Engine
http://www.cs.toronto.edu/~gpenn/ale/files/ale.pl

Maybe I can dig out an TPTP example, currently working
with the normal test cases that circulate, that are more abstract.
The trouble maker is this here from Phil Zucker:

:- op( 500, fy, !). % universal quantifier: ![X]:
:- op( 500, fy, ?). % existential quantifier: ?[X]:
:- op( 500,xfy, :).

If you change the later into:

:- op( 500,yfx, :).

You get a difference in SWI-Prolog and SICStus Prolog:

/* SWI-Prolog (threaded, 64 bits, version 8.5.8) */
?- X = (![Y]:p(Y)), write_canonical(X), nl.
:(!([A]),p(A))
X = ![Y]:p(Y).

/* SICStus 4.7.1 (x86_64-win32-nt-4) */
?- X = (![Y]:p(Y)), write_canonical(X), nl.
!(:('.'(_953,[]),p(_953)))
X = ![Y]:p(Y) ?

Note the difference, SWI-Prolog gives :(!(...) whereas SICStus Prolog
gives !(:(...). So the same SICStus Prolog code that would use a !_
pattern somewhere in his Prolog clauses, doesn’t run in SWI-Prolog.

There are LeanTap variants that use such patterns

Basically you get a **silent error**. Everything parses
fine, the Prolog text can be prepared for execution,
your code just stops working correctly, when

migrating from SICStus Prolog to SWI-Prolog.

Mostowski Collapse schrieb am Montag, 11. April 2022 um 12:04:56 UTC+2:
> This is probably not the canary in the coal mine for the
> suspected bugs. One can check by himself/herself, not
> a single use of fy or yfx operator:
>
> ALE – Attribute Logic Engine
> http://www.cs.toronto.edu/~gpenn/ale/files/ale.pl
>
> Maybe I can dig out an TPTP example, currently working
> with the normal test cases that circulate, that are more abstract.
> The trouble maker is this here from Phil Zucker:
>
> :- op( 500, fy, !). % universal quantifier: ![X]:
> :- op( 500, fy, ?). % existential quantifier: ?[X]:
> :- op( 500,xfy, :).
>
> If you change the later into:
>
> :- op( 500,yfx, :).
>
> You get a difference in SWI-Prolog and SICStus Prolog:
>
> /* SWI-Prolog (threaded, 64 bits, version 8.5.8) */
> ?- X = (![Y]:p(Y)), write_canonical(X), nl.
> :(!([A]),p(A))
> X = ![Y]:p(Y).
>
> /* SICStus 4.7.1 (x86_64-win32-nt-4) */
> ?- X = (![Y]:p(Y)), write_canonical(X), nl.
> !(:('.'(_953,[]),p(_953)))
> X = ![Y]:p(Y) ?
>
> Note the difference, SWI-Prolog gives :(!(...) whereas SICStus Prolog
> gives !(:(...). So the same SICStus Prolog code that would use a !_
> pattern somewhere in his Prolog clauses, doesn’t run in SWI-Prolog.
>
> There are LeanTap variants that use such patterns

Suddently, in a flash of light, thanks to Mr Peter Ludemann,
my guardian angle, the good shepherd, I saw that my whole
life was a lie. Why did I become so deeply absorbed with

the parsing problem? Ok, I will stop from now on. LoL

Mostowski Collapse schrieb am Montag, 11. April 2022 um 12:17:26 UTC+2:
> Basically you get a **silent error**. Everything parses
> fine, the Prolog text can be prepared for execution,
> your code just stops working correctly, when
>
> migrating from SICStus Prolog to SWI-Prolog.

Just joking, the business is basically finished, I have now:

Dogelog Player is now at 80% of Testing its Predicates
https://twitter.com/dogelogch/status/1514036461968015362

Dogelog Player is now at 80% of Testing its Predicates
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 04:24:01 UTC+2:
> Suddently, in a flash of light, thanks to Mr Peter Ludemann,
> my guardian angle, the good shepherd, I saw that my whole
> life was a lie. Why did I become so deeply absorbed with
>
> the parsing problem? Ok, I will stop from now on. LoL
> Mostowski Collapse schrieb am Montag, 11. April 2022 um 12:17:26 UTC+2:
> > Basically you get a **silent error**. Everything parses
> > fine, the Prolog text can be prepared for execution,
> > your code just stops working correctly, when
> >
> > migrating from SICStus Prolog to SWI-Prolog.

Thats quite some news:

I see the problem corner cases as ones than can be easily avoided
through judicious operator definitions. Any DSL’s that use such cases
are asking for trouble IMO.

Do I understand you correctly. You say avoid certain operator combinations?
How would a normal end-user or DSL designer notice them?

Do they have some special characteristics? Or do you have an explicit list of
those operator combinations that should be avoided?

Here is a funny example in the wild, the authors seems not to have known
the ridgeworks rules, since he used:

% Christophe Meudec
% Eclipse 6.0 program
:- op(30, fy, [not]). % must be fy for 'not not a' expressions
:- op(30, yfx, [**, abs]). % must be left to right for 'a ** b ** c' expressions

https://github.com/echancrure/PTC-Solver/blob/f02c64925fbc06a9f2cbbef252684ebccd5bd217/source/util__post_precedence.pl#L12

Which is an attempt to model ADA programming language. The poor guy will have
quite a surprise when mirgating from ECLiPSe to SWI-Prolog:

/* ECLiPSe Prolog */
[eclipse 2]: X = (not not not 2 ** 3 ** 4), write_canonical(X), nl.
not(not(not(**(**(2, 3), 4))))

X = not not not 2 ** 3 ** 4
Yes (0.00s cpu)

And then:

/* SWI-Prolog */
?- op(30, fy, not), op(30, yfx, **).
true.

?- X = (not not not 2 ** 3 ** 4), write_canonical(X), nl.
**(**(not(not(not(2))),3),4)
X = not not not 2**3**4.

If you evaluate the two expressions with bitwise arithmetic you get different results:

[eclipse 6]: X is \(\(\((2^3)^4))).
X = -4097

[eclipse 7]: X is (\(\(\(2)))^3)^4.
X = 531441

For ADA operators:
https://www.adaic.org/resources/add_content/standards/05rm/html/RM-4-5.html

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 06:30:18 UTC+2:
> Thats quite some news:
>
> I see the problem corner cases as ones than can be easily avoided
> through judicious operator definitions. Any DSL’s that use such cases
> are asking for trouble IMO.
>
> Do I understand you correctly. You say avoid certain operator combinations?
> How would a normal end-user or DSL designer notice them?
>
> Do they have some special characteristics? Or do you have an explicit list of
> those operator combinations that should be avoided?

Woke up in the morning and my brain only produced new challenges.

I am still trying to find a case in the wild in favor of SWI-Prolog. For
example if ADA would effectively parse:

abs x ** y

As this here:

**(abs(x), y)

Then the ISO core standard is somehow not “right”, or lets say more “arbitrary” than
I tought. Which could be an interesting turn of events.

The problem with my suggested fix, using “fx” instead “fy”, it does not work when you
you want to support multiple braketless occurences of an operator.

Take the pPEG parsers rule:

op_associativityEq(fy,yfx,left).

Change it into this:

op_associativityEq(fy,yfx,left) :- current_prolog_flag(iso, false).
op_associativityEq(fy,yfx,right) :- current_prolog_flag(iso, true).

What will the pPEG parser do now? Is there also a pPEG unparser?

https://swi-prolog.discourse.group/t/parsing-text-using-a-formal-grammar/5086

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:43:16 UTC+2:
> Woke up in the morning and my brain only produced new challenges.
>
> I am still trying to find a case in the wild in favor of SWI-Prolog. For
> example if ADA would effectively parse:
>
> abs x ** y
>
> As this here:
>
> **(abs(x), y)
>
> Then the ISO core standard is somehow not “right”, or lets say more “arbitrary” than
> I tought. Which could be an interesting turn of events.
>
> The problem with my suggested fix, using “fx” instead “fy”, it does not work when you
> you want to support multiple braketless occurences of an operator.

Ok it wurks. I changed pl_parser.pl accordingly, and I now get:

?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
yfx(fy(1),2)
T = fy 1 yfx 2.

?- set_prolog_flag(iso, true).
true.

?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
fy(yfx(1,2))
T = fy 1 yfx 2.

Eh voila SWI-Prolog has become member of the ISO core standard club.
Maybe it can even apply for V.I.P. membership, because its so important?

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:44:20 UTC+2:
> Take the pPEG parsers rule:
>
> op_associativityEq(fy,yfx,left).
>
> Change it into this:
>
> op_associativityEq(fy,yfx,left) :- current_prolog_flag(iso, false).
> op_associativityEq(fy,yfx,right) :- current_prolog_flag(iso, true).
>
> What will the pPEG parser do now? Is there also a pPEG unparser?
>
> https://swi-prolog.discourse.group/t/parsing-text-using-a-formal-grammar/5086
> Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:43:16 UTC+2:
> > Woke up in the morning and my brain only produced new challenges.
> >
> > I am still trying to find a case in the wild in favor of SWI-Prolog. For
> > example if ADA would effectively parse:
> >
> > abs x ** y
> >
> > As this here:
> >
> > **(abs(x), y)
> >
> > Then the ISO core standard is somehow not “right”, or lets say more “arbitrary” than
> > I tought. Which could be an interesting turn of events.
> >
> > The problem with my suggested fix, using “fx” instead “fy”, it does not work when you
> > you want to support multiple braketless occurences of an operator.

Interestingly the standard unparser of SWI-Prolog doesn’t give a damn.
But this is another defect which I have posted about already in some thread..

aLSO who_ever wrote this code of pPEG deserves to burn in hell,
for mixing underscore and camelcase. Took me quite a while to run the query..

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 20:30:53 UTC+2:
> Ok it wurks. I changed pl_parser.pl accordingly, and I now get:
>
> ?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
> yfx(fy(1),2)
> T = fy 1 yfx 2.
>
> ?- set_prolog_flag(iso, true).
> true.
>
> ?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
> fy(yfx(1,2))
> T = fy 1 yfx 2.
>
> Eh voila SWI-Prolog has become member of the ISO core standard club.
> Maybe it can even apply for V.I.P. membership, because its so important?
> Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:44:20 UTC+2:
> > Take the pPEG parsers rule:
> >
> > op_associativityEq(fy,yfx,left).
> >
> > Change it into this:
> >
> > op_associativityEq(fy,yfx,left) :- current_prolog_flag(iso, false).
> > op_associativityEq(fy,yfx,right) :- current_prolog_flag(iso, true).
> >
> > What will the pPEG parser do now? Is there also a pPEG unparser?
> >
> > https://swi-prolog.discourse.group/t/parsing-text-using-a-formal-grammar/5086
> > Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:43:16 UTC+2:
> > > Woke up in the morning and my brain only produced new challenges.
> > >
> > > I am still trying to find a case in the wild in favor of SWI-Prolog. For
> > > example if ADA would effectively parse:
> > >
> > > abs x ** y
> > >
> > > As this here:
> > >
> > > **(abs(x), y)
> > >
> > > Then the ISO core standard is somehow not “right”, or lets say more “arbitrary” than
> > > I tought. Which could be an interesting turn of events.
> > >
> > > The problem with my suggested fix, using “fx” instead “fy”, it does not work when you
> > > you want to support multiple braketless occurences of an operator.

Maybe they should organize the ISO core standard club like here:

Platin Sponsor
Gold Sponsor
Silver Sponsor
https://www.jug.ch/sponsors.php

Then you can buy different grades of VIPness with Mamon.
Sad Story: Any poor John Doe Prolog system will be non-VIP.

Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 20:32:51 UTC+2:
> Interestingly the standard unparser of SWI-Prolog doesn’t give a damn.
> But this is another defect which I have posted about already in some thread.
>
> aLSO who_ever wrote this code of pPEG deserves to burn in hell,
> for mixing underscore and camelcase. Took me quite a while to run the query.
> Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 20:30:53 UTC+2:
> > Ok it wurks. I changed pl_parser.pl accordingly, and I now get:
> >
> > ?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
> > yfx(fy(1),2)
> > T = fy 1 yfx 2.
> >
> > ?- set_prolog_flag(iso, true).
> > true.
> >
> > ?- string_termList("fy 1 yfx 2.", [T]), write_canonical(T), nl.
> > fy(yfx(1,2))
> > T = fy 1 yfx 2.
> >
> > Eh voila SWI-Prolog has become member of the ISO core standard club.
> > Maybe it can even apply for V.I.P. membership, because its so important?
> > Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:44:20 UTC+2:
> > > Take the pPEG parsers rule:
> > >
> > > op_associativityEq(fy,yfx,left).
> > >
> > > Change it into this:
> > >
> > > op_associativityEq(fy,yfx,left) :- current_prolog_flag(iso, false).
> > > op_associativityEq(fy,yfx,right) :- current_prolog_flag(iso, true).
> > >
> > > What will the pPEG parser do now? Is there also a pPEG unparser?
> > >
> > > https://swi-prolog.discourse.group/t/parsing-text-using-a-formal-grammar/5086
> > > Mostowski Collapse schrieb am Mittwoch, 13. April 2022 um 11:43:16 UTC+2:
> > > > Woke up in the morning and my brain only produced new challenges.
> > > >
> > > > I am still trying to find a case in the wild in favor of SWI-Prolog.. For
> > > > example if ADA would effectively parse:
> > > >
> > > > abs x ** y
> > > >
> > > > As this here:
> > > >
> > > > **(abs(x), y)
> > > >
> > > > Then the ISO core standard is somehow not “right”, or lets say more “arbitrary” than
> > > > I tought. Which could be an interesting turn of events.
> > > >
> > > > The problem with my suggested fix, using “fx” instead “fy”, it does not work when you
> > > > you want to support multiple braketless occurences of an operator.

Transfering pPEG results back to C code is not self
evident. The pPEG parser could be a blessing, but it
could be also a further curse.

We don’t know what the pPEG parser does. For example
I don’t find the op_associativityEq/3 table in pl-read.c.
Where it you get it from? Also very simple examples

don’t work in the pPEG parser:

?- string_termList("(- -1).", [T]), write_canonical(T), nl.
-(-,1)
T = (-)-1.

?- X = (- -1), write_canonical(X), nl.
-(-1)
X = - -1.

I will not touch pPEG anymore, even not with tweezers,
until it comes with a test suite, in the same folder like where the
source code is housed. At least this is what Ulrich Neumerkel did

for ISO core standard prolog, and which serves as a point of orientation.
Now we have for SWI-Prolog dialect nor the pPEG dialect any point of
orientation. Its just arbitary code uploaded to the internet. Although I think

SWI-Prolog might be in a better situation. Not sure, it has plunit and maybe
it has somewhere read test cases? But it has only with_output_to/2, and
no with_input_from/2. How is parsing tested? I never did dig up some

SWI-Prolog read test cases, maybe there are some? Thats of course my fault.

Mostowski Collapse schrieb am Donnerstag, 14. April 2022 um 16:58:50 UTC+2:
> Transfering pPEG results back to C code is not self
> evident. The pPEG parser could be a blessing, but it
> could be also a further curse.
>
> We don’t know what the pPEG parser does. For example
> I don’t find the op_associativityEq/3 table in pl-read.c.
> Where it you get it from? Also very simple examples
>
> don’t work in the pPEG parser:
>
> ?- string_termList("(- -1).", [T]), write_canonical(T), nl.
> -(-,1)
> T = (-)-1.
>
> ?- X = (- -1), write_canonical(X), nl.
> -(-1)
> X = - -1.

What I could exclude as a source of error, is ordering of
the operator table itself. At least for SWI-Prolog C code it does not
have an impact, which sequence of operator definitions I use:

This sequence of op/3 calls:

?- op(9, fy, fy), op(9, yfx, yfx).
true.

?- X = (fy 1 yfx 2), write_canonical(X), nl.
yfx(fy(1),2)
X = fy 1 yfx 2.

And this sequence of op/3 calls, give the same:

?- op(9, yfx, yfx), op(9, fy, fy).
true.

?- X = (fy 1 yfx 2), write_canonical(X), nl.
yfx(fy(1),2)
X = fy 1 yfx 2.

This does not exclude the possibility, that reordering the
operator table, inside SWI-Prolog C code, wouldn’t give
another result. It only shows that op/3 cannot confuse the parser.

Here is an example where operator table ordering, respective
reduction rules ordering, influence the reduction result.
Reduction rules ordered like this:

[fy,X] ~> [fy(X)].
[X,yfx,Y] ~> [yfx(X,Y)].

?- reduce([fy,1,yfx,2],X), write_canonical(X), nl.
[yfx(fy(1),2)]
X = [fy 1 yfx 2].

Or the same reduction rules ordered like this, gives a different result:

[X,yfx,Y] ~> [yfx(X,Y)].
[fy,X] ~> [fy(X)].

?- reduce([fy,1,yfx,2],X), write_canonical(X), nl.
[fy(yfx(1,2))]
X = [fy 1 yfx 2].

The reducer code itself is here below, it has a cut (!), so its
sensitive to the reduction rule ordering:

:- op(1200,xfx,~>).

reduce(X, Y) :-
(A ~> B),
append(U, V, X),
append(A, H, V),
append(B, H, W),
append(U, W, Z), !, reduce(Z, Y).
reduce(X, X).

Mostowski Collapse schrieb am Freitag, 15. April 2022 um 00:35:26 UTC+2:
> What I could exclude as a source of error, is ordering of
> the operator table itself. At least for SWI-Prolog C code it does not
> have an impact, which sequence of operator definitions I use:
>
> This sequence of op/3 calls:
>
> ?- op(9, fy, fy), op(9, yfx, yfx).
> true.
>
> ?- X = (fy 1 yfx 2), write_canonical(X), nl.
> yfx(fy(1),2)
> X = fy 1 yfx 2.
>
> And this sequence of op/3 calls, give the same:
>
> ?- op(9, yfx, yfx), op(9, fy, fy).
> true.
>
> ?- X = (fy 1 yfx 2), write_canonical(X), nl.
> yfx(fy(1),2)
> X = fy 1 yfx 2.
>
> This does not exclude the possibility, that reordering the
> operator table, inside SWI-Prolog C code, wouldn’t give
> another result. It only shows that op/3 cannot confuse the parser.

Using a fuzzer, I find differences what SWI-Prolog native C code
considers an operator clash and what the pPEG SWIPL examples
considers an operator clash. It seems pPEG is more tolerant.

There are also some fundamental differences in what
Prolog terms the SWI-Prolog native C code builds, and what
the pPEG SWIPL example builds.

This is how I used the fuzzer:

?- between(1,100,_), random_expr(0, _, A), swi_parse(A, X),
ppeg_parse(A, Y), X \== Y, write('expr: '), write(A), write('\nswi: '),
write_canonical(X), write('\nppeg: '), write_canonical(Y), nl, nl, fail.

expr: 0 xfx fy 1 yfx 2 yfx 3
swi: syntax_error(operator_clash)
ppeg: xfx(0,yfx(yfx(fy(1),2),3))

expr: fy fx fx 0
swi: syntax_error(operator_clash)
ppeg: fy(fx(fx(0)))

expr: fy fx 0 yf yf yf
swi: yf(yf(yf(fy(fx(0)))))
ppeg: fy(yf(yf(yf(fx(0)))))

expr: fy 0 xf yfx 1 yfx 2 yf
swi: yf(yfx(yfx(fy(xf(0)),1),2))
ppeg: fy(yf(yfx(yfx(xf(0),1),2)))

false.

The fuzzer code is here:

:- op(9, xfx, xfx).
:- op(9, yfx, yfx).
:- op(9, xfy, xfy).
:- op(9, fx, fx).
:- op(9, fy, fy).
:- op(9, xf, xf).
:- op(9, yf, yf).

% random_expr(+Integer, -Integer, -Atom)
random_expr(N, M, A) :-
K is 10+N*5,
random(0, K, I),
random_action(I, N, M, A).

% random_expr(+Integer, +Integer, -Integer, -Atom)
random_action(0, N, M, A) :- !,
random_expr(N, H, B),
random_expr(H, M, C),
atom_concat(B, ' xfx ', D),
atom_concat(D, C, A).
random_action(1, N, M, A) :- !,
random_expr(N, H, B),
random_expr(H, M, C),
atom_concat(B, ' yfx ', D),
atom_concat(D, C, A).
random_action(2, N, M, A) :- !,
random_expr(N, H, B),
random_expr(H, M, C),
atom_concat(B, ' xfy ', D),
atom_concat(D, C, A).
random_action(3, N, M, A) :- !,
random_expr(N, M, B),
atom_concat('fx ', B, A).
random_action(4, N, M, A) :- !,
random_expr(N, M, B),
atom_concat('fy ', B, A).
random_action(5, N, M, A) :- !,
random_expr(N, M, B),
atom_concat(B, ' xf', A).
random_action(6, N, M, A) :- !,
random_expr(N, M, B),
atom_concat(B, ' yf', A).
random_action(_, N, M, A) :-
number_codes(N, L),
atom_codes(A, L),
M is N+1.

Mostowski Collapse schrieb am Freitag, 15. April 2022 um 12:38:29 UTC+2:
> Using a fuzzer, I find differences what SWI-Prolog native C code
> considers an operator clash and what the pPEG SWIPL examples
> considers an operator clash. It seems pPEG is more tolerant.
>
> There are also some fundamental differences in what
> Prolog terms the SWI-Prolog native C code builds, and what
> the pPEG SWIPL example builds.
>
> This is how I used the fuzzer:
>
> ?- between(1,100,_), random_expr(0, _, A), swi_parse(A, X),
> ppeg_parse(A, Y), X \== Y, write('expr: '), write(A), write('\nswi: '),
> write_canonical(X), write('\nppeg: '), write_canonical(Y), nl, nl, fail.
>
> expr: 0 xfx fy 1 yfx 2 yfx 3
> swi: syntax_error(operator_clash)
> ppeg: xfx(0,yfx(yfx(fy(1),2),3))
>
> expr: fy fx fx 0
> swi: syntax_error(operator_clash)
> ppeg: fy(fx(fx(0)))
>
> expr: fy fx 0 yf yf yf
> swi: yf(yf(yf(fy(fx(0)))))
> ppeg: fy(yf(yf(yf(fx(0)))))
>
> expr: fy 0 xf yfx 1 yfx 2 yf
> swi: yf(yfx(yfx(fy(xf(0)),1),2))
> ppeg: fy(yf(yfx(yfx(xf(0),1),2)))
>
> false.

Everybody knows that Prolog doesn't parse
(a = b = c), this is what operator icon xfx is made
for. But what is the operator icon fx made for?

Oh my god, SICStus Prolog tolerates this?

/* SICStus Prolog 4.7.1 */
?- X = (:- :- x0).
X = ((:-):-x0) ?

SWI-Prolog and Scryer Prolog are more thight:

/* Scryer Prolog */
?- X = (:- :- x0).
caught: error(syntax_error(incomplete_reduction),read_term/3:1)

/* SWI-Prolog */
?- X = (:- :- x0).
ERROR: Syntax error: Operator priority clash

Now I posted already a tight Prolog reader on SWI-Prolog
discourse. Here is it in all its glory. It doesn't handle negative
numbers, but its cute to play around with operator parsing,

like for example:

/* SICStus 4.7.1 */
?- consult('reader.p').

?- reader(T,1200,[:-,x0],[]).
T = (:-x0) ?

?- reader(T,1200,[:-,:-,x0],[]).
error(syntax_error(operator_clash),_415)

The code is only one page:

reader(X, L) -->
reader_primary(Z, L, K), reader_secondary(Z, X, L, K).

reader_primary(H, L, R) --> [A], {current_op(R, M, A), is_prefix(M, E)}, !,
{L < R -> throw(error(syntax_error(operator_clash),_)); true},
{T is R-E}, reader(Z, T), {H =.. [A,Z]}.
reader_primary(X, _, 0) --> [X].

reader_secondary(H, X, L, C) --> [A],
{current_op(R, M, A), is_infix(M, D, E), L >= R}, !,
{R-D < C -> throw(error(syntax_error(operator_clash),_)); true},
{T is R-E}, reader(Z, T),
{J =.. [A,H,Z]},
reader_secondary(J, X, L, R).
reader_secondary(H, X, L, C) --> [A],
{current_op(R, M, A), is_postfix(M, D), L >= R}, !,
{R-D < C -> throw(error(syntax_error(operator_clash),_)); true},
{J =.. [A,H]},
reader_secondary(J, X, L, R).
reader_secondary(H, H, _, _) --> [].

is_infix(xfx, 1, 1).
is_infix(yfx, 0, 1).
is_infix(xfy, 1, 0).

is_prefix(fx, 1).
is_prefix(fy, 0).

is_postfix(xf, 1).
is_postfix(yf, 0).

Mostowski Collapse schrieb am Sonntag, 17. April 2022 um 02:43:21 UTC+2:
> Everybody knows that Prolog doesn't parse
> (a = b = c), this is what operator icon xfx is made
> for. But what is the operator icon fx made for?
>
> Oh my god, SICStus Prolog tolerates this?
>
> /* SICStus Prolog 4.7.1 */
> ?- X = (:- :- x0).
> X = ((:-):-x0) ?
>
> SWI-Prolog and Scryer Prolog are more thight:
>
> /* Scryer Prolog */
> ?- X = (:- :- x0).
> caught: error(syntax_error(incomplete_reduction),read_term/3:1)
>
> /* SWI-Prolog */
> ?- X = (:- :- x0).
> ERROR: Syntax error: Operator priority clash

Holy Cow, ECLiPSe Prolog is somewhere between SWI-Prolog
and SICStus Prolog, concerning tolerating extra syntax.

SICStus Prolog, quite tolerant:

?- X = (- :- x0).
X = ((-):-x0) ?
?- X = (:- :- x0).
X = ((:-):-x0) ?

ECLIPSe Prolog, half way tolerant:

[eclipse 36]: X = (- :- x0).
X = ((-) :- x0)
[eclipse 37]: X = (:- :- x0).
syntax error: postfix/infix operator expected

SWI-Prolog, intolerant, good!!!

?- X = (- :- x0).
ERROR: Syntax error: Operator priority clash
?- X = (:- :- x0).
ERROR: Syntax error: Operator priority clash

My reader prototype sides with SWI-Prolog. Also
Dogelog Player and formerly Jekejeke Prolog side
with SWI-Prolog. Dogelog Player can be tried online:

?- X = (- :- x0).
error(syntax_error(operator_clash), [user:0])
error(syntax_error(cannot_start_term), [user:1])
?- X = (:- :- x0).
error(syntax_error(operator_clash), [user:1])
error(syntax_error(cannot_start_term), [user:2])
http://www.xlog.ch/izytab/moblet/docs/18_live/10_reference/example01/package.html

Unfortunately resyncing after an error is not yet
implemented, so there are two errors. But we got
already line numbers for Dogelog Player,

this is quite a gas!!!

Mostowski Collapse schrieb am Montag, 18. April 2022 um 23:27:20 UTC+2:
> Holy Cow, ECLiPSe Prolog is somewhere between SWI-Prolog
> and SICStus Prolog, concerning tolerating extra syntax.
>
> SICStus Prolog, quite tolerant:
>
> ?- X = (- :- x0).
> X = ((-):-x0) ?
> ?- X = (:- :- x0).
> X = ((:-):-x0) ?
> ECLIPSe Prolog, half way tolerant:
>
> [eclipse 36]: X = (- :- x0).
> X = ((-) :- x0)
> [eclipse 37]: X = (:- :- x0).
> syntax error: postfix/infix operator expected
>
> SWI-Prolog, intolerant, good!!!
>
> ?- X = (- :- x0).
> ERROR: Syntax error: Operator priority clash
> ?- X = (:- :- x0).
> ERROR: Syntax error: Operator priority clash

More proof that Logtalk is utter nonsense. What
does the Logtalk test suite even test concerning
the various "adapters" it has, like Trealla?

This is a nice gem:

$ ./tpl -v
Trealla Prolog (c) Infradig 2020-2022, v1.27.12-31-g3575df
$ ./tpl
?- X = (:- (:- x0)).
Error: operator clash, line 1
false.
?-

There is something wrong with Ulrich Neumerkels
compliance test suite, and maybe some QuickCheck
resp. Fuzzer approach is needed,

to chop of all heads of the hydra.

I am little bit behind schedule of a Fuzzer that also
does parenthesis. So this was my sixth sense. Was also
working on another front, resyncing after errors.

I found a solution today: Have a grammer that covers non-errorneous
sentences and errorneous sentences. How to do this simply?
Its more difficult to resync the tokenization, then to resync the

parsing. For parsing I found this useful, since Prolog has the
concept of terminating period. Take the very simplified
prototype posted elsewhere:

reader_secondary(H, X, L, C) --> [A],
{current_op(R, M, A), is_infix(M, D, E), L >= R}, !,
{R-D < C -> throw(error(syntax_error(operator_clash),_)); true},
{T is R-E}, reader(Z, T),
{J =.. [A,H,Z]},
reader_secondary(J, X, L, R).

It throws an exception inside an auxiliary action {}/1 of DCG. But
you can define throw//1, i.e. make throw itself a DCG non-terminal:

throw(T) --> read_sync, {throw(T)}.

And then replace the infix parsing, its only an example, works also
for all other parser errors:

reader_secondary(H, X, L, C) --> [A],
{current_op(R, M, A), is_infix(M, D, E), L >= R}, !,
({R-D < C} -> throw(error(syntax_error(operator_clash),_)); {true}),
{T is R-E}, reader(Z, T),
{J =.. [A,H,Z]},
reader_secondary(J, X, L, R).

The parser is now calling throw//1 instead of throw/1. And throw//1
can do some syncing.

Mostowski Collapse schrieb am Freitag, 29. April 2022 um 12:42:21 UTC+2:
> More proof that Logtalk is utter nonsense. What
> does the Logtalk test suite even test concerning
> the various "adapters" it has, like Trealla?
>
> This is a nice gem:
>
> $ ./tpl -v
> Trealla Prolog (c) Infradig 2020-2022, v1.27.12-31-g3575df
> $ ./tpl
> ?- X = (:- (:- x0)).
> Error: operator clash, line 1
> false.
> ?-
>
> There is something wrong with Ulrich Neumerkels
> compliance test suite, and maybe some QuickCheck
> resp. Fuzzer approach is needed,
>
> to chop of all heads of the hydra.