Just dont use it for DCG. This here is much more better:

p --> q; r.
?- listing.

p(_0, _1) :- q(_0, _1); r(_0, _1).
true.

Works in Dogelog like that:
http://www.xlog.ch/izytab/moblet/en/docs/18_live/10_reference/example01/package.html

Rational: Ever tried to convert some ordinary code into
DCG? With (;)/2 reflected as (;)/4 in DCG, this is easy.
Just replace (:-)/2 by (-->)/2.

But now the DCG draft wants people to also change (;)/2
into (|)/4. What a nonsense, since (,)/2 reflects into (,)/4,
(->)/2 reflects into (->)/2 and !/0 reflects into !/2.

With the Dogelog approach all ISO control construct
reflect without any need for renaming. You can leave '|'
untouched and use it for TPTP Syntax side by side

with DCG. On the other hand the DCG Draft wants an
exception for the (;)/2 and reflect it into (|)/2, causing
infinitely many nonsense problems.

See also:

% operator definitions (TPTP syntax)

:- op( 500, fy, ~). % negation
:- op(1000, xfy, &). % conjunction
:- op(1100, xfy, '|'). % disjunction
:- op(1110, xfy, =>). % implication

https://www.philipzucker.com/javascript-automated-proving/

Now have drummed for DCG usage for the web. Only to notice that
the DCG Draft has made everything to make this not work. My point
of departure was Phil Zuckers mixture of Prolog and JavaScript.

I always thought there is an overselling of Prolog DCG. But somehow
there is an underselling when doing web stuff. Phil Zuckers example
using JavaScript for pretty printing is the worst thing I have ever

seen. If you search a proof tree via Prolog and then use JavaScript
to render it, you generate a hell of Problems:

- You need to assume some JavaScript representation of
the Prolog terms. In the case of Phil Zucker the TauProlog
this is just an arbitarily designed API. There is no such
standard for such APIs.
→ Your code is not portable.

- You need to do stuff in JavaScript that Prolog is much
better suited for. Like doing text generation, proof filtering
etc…, I wouldn’t want to do this in JavaScript.
→ Your code is not concise.

- When doing stuff in Prolog you have automatically
some flexible indexing, like first argument indexing. Also
Prolog has additional garbage collection. Things not
available in JavaScript.
→ Your code is not efficient.

- It might be prohibitive to call repeatedly Prolog
predicates during JavaScript rendering. So that
you might implement stuff twice, in Prolog and
in JavaScript.
→ Your code is not single source.

- What else?

Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:32:54 UTC+1:
> Just dont use it for DCG. This here is much more better:
>
> p --> q; r.
> ?- listing.
>
> p(_0, _1) :- q(_0, _1); r(_0, _1).
> true.
>
> Works in Dogelog like that:
> http://www.xlog.ch/izytab/moblet/en/docs/18_live/10_reference/example01/package.html
>
> Rational: Ever tried to convert some ordinary code into
> DCG? With (;)/2 reflected as (;)/4 in DCG, this is easy.
> Just replace (:-)/2 by (-->)/2.
>
> But now the DCG draft wants people to also change (;)/2
> into (|)/4. What a nonsense, since (,)/2 reflects into (,)/4,
> (->)/2 reflects into (->)/2 and !/0 reflects into !/2.
>
> With the Dogelog approach all ISO control construct
> reflect without any need for renaming. You can leave '|'
> untouched and use it for TPTP Syntax side by side
>
> with DCG. On the other hand the DCG Draft wants an
> exception for the (;)/2 and reflect it into (|)/2, causing
> infinitely many nonsense problems.
>
> See also:
>
> % operator definitions (TPTP syntax)
>
> :- op( 500, fy, ~). % negation
> :- op(1000, xfy, &). % conjunction
> :- op(1100, xfy, '|'). % disjunction
> :- op(1110, xfy, =>). % implication
>
> https://www.philipzucker.com/javascript-automated-proving/

Using DCG is not mandatory. You could also imagine a Prolog
only solution where this DCG here:

p --> ['foo bar'], q.

Is replaced by old CGI style web service:

p :- write('foo bar'), q.

You could also use something similar for client side, like Tau-
Prolog not only server side like for SWI-Prolog. Performance
depends on the stream that write/1 will use.

On the server side you could write into a buffer, and then serve
a HTTP request with a known length, or directly write into the
HTTP response socket and deliver the result chunked.

What I observed is that DCG is more handy for debugging. In
CGI style write/1, when you use it in the Prolog debugger, in
some console based debugger, the write/1 will constantly

flood the console, making it practically impossible
to sensibly debug the thingy.

Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:45:19 UTC+1:
> Now have drummed for DCG usage for the web. Only to notice that
> the DCG Draft has made everything to make this not work. My point
> of departure was Phil Zuckers mixture of Prolog and JavaScript.
>
> I always thought there is an overselling of Prolog DCG. But somehow
> there is an underselling when doing web stuff. Phil Zuckers example
> using JavaScript for pretty printing is the worst thing I have ever
>
> seen. If you search a proof tree via Prolog and then use JavaScript
> to render it, you generate a hell of Problems:
>
> - You need to assume some JavaScript representation of
> the Prolog terms. In the case of Phil Zucker the TauProlog
> this is just an arbitarily designed API. There is no such
> standard for such APIs.
> → Your code is not portable.
>
> - You need to do stuff in JavaScript that Prolog is much
> better suited for. Like doing text generation, proof filtering
> etc…, I wouldn’t want to do this in JavaScript.
> → Your code is not concise.
>
> - When doing stuff in Prolog you have automatically
> some flexible indexing, like first argument indexing. Also
> Prolog has additional garbage collection. Things not
> available in JavaScript.
> → Your code is not efficient.
>
> - It might be prohibitive to call repeatedly Prolog
> predicates during JavaScript rendering. So that
> you might implement stuff twice, in Prolog and
> in JavaScript.
> → Your code is not single source.
>
> - What else?
> Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:32:54 UTC+1:
> > Just dont use it for DCG. This here is much more better:
> >
> > p --> q; r.
> > ?- listing.
> >
> > p(_0, _1) :- q(_0, _1); r(_0, _1).
> > true.
> >
> > Works in Dogelog like that:
> > http://www.xlog.ch/izytab/moblet/en/docs/18_live/10_reference/example01/package.html
> >
> > Rational: Ever tried to convert some ordinary code into
> > DCG? With (;)/2 reflected as (;)/4 in DCG, this is easy.
> > Just replace (:-)/2 by (-->)/2.
> >
> > But now the DCG draft wants people to also change (;)/2
> > into (|)/4. What a nonsense, since (,)/2 reflects into (,)/4,
> > (->)/2 reflects into (->)/2 and !/0 reflects into !/2.
> >
> > With the Dogelog approach all ISO control construct
> > reflect without any need for renaming. You can leave '|'
> > untouched and use it for TPTP Syntax side by side
> >
> > with DCG. On the other hand the DCG Draft wants an
> > exception for the (;)/2 and reflect it into (|)/2, causing
> > infinitely many nonsense problems.
> >
> > See also:
> >
> > % operator definitions (TPTP syntax)
> >
> > :- op( 500, fy, ~). % negation
> > :- op(1000, xfy, &). % conjunction
> > :- op(1100, xfy, '|'). % disjunction
> > :- op(1110, xfy, =>). % implication
> >
> > https://www.philipzucker.com/javascript-automated-proving/

I dont know yet how much legacy will be destroyed by
adopting (;)/2 and only (;)/2. If I remember well some
Prolog system support both (|)/2 and (;)/2 in DCG?

Not sure. And not sure what the experts say.
Typically (|)/2 is rather rare, because for DCG there
is not so much the idiom as seen in syntax docu:

p --> "foo"
| "bar"
| "baz".

Since we want to parse something, and return
something. So although a syntax docu might read
as in the above, practically this often turns into:

p(ast1) --> "foo".
p(ast2) --> "bar".
p(ast3) --> "baz".

The DCG disjunction disappears!

Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:48:40 UTC+1:
> Using DCG is not mandatory. You could also imagine a Prolog
> only solution where this DCG here:
>
> p --> ['foo bar'], q.
>
> Is replaced by old CGI style web service:
>
> p :- write('foo bar'), q.
>
> You could also use something similar for client side, like Tau-
> Prolog not only server side like for SWI-Prolog. Performance
> depends on the stream that write/1 will use.
>
> On the server side you could write into a buffer, and then serve
> a HTTP request with a known length, or directly write into the
> HTTP response socket and deliver the result chunked.
>
> What I observed is that DCG is more handy for debugging. In
> CGI style write/1, when you use it in the Prolog debugger, in
> some console based debugger, the write/1 will constantly
>
> flood the console, making it practically impossible
> to sensibly debug the thingy.
> Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:45:19 UTC+1:
> > Now have drummed for DCG usage for the web. Only to notice that
> > the DCG Draft has made everything to make this not work. My point
> > of departure was Phil Zuckers mixture of Prolog and JavaScript.
> >
> > I always thought there is an overselling of Prolog DCG. But somehow
> > there is an underselling when doing web stuff. Phil Zuckers example
> > using JavaScript for pretty printing is the worst thing I have ever
> >
> > seen. If you search a proof tree via Prolog and then use JavaScript
> > to render it, you generate a hell of Problems:
> >
> > - You need to assume some JavaScript representation of
> > the Prolog terms. In the case of Phil Zucker the TauProlog
> > this is just an arbitarily designed API. There is no such
> > standard for such APIs.
> > → Your code is not portable.
> >
> > - You need to do stuff in JavaScript that Prolog is much
> > better suited for. Like doing text generation, proof filtering
> > etc…, I wouldn’t want to do this in JavaScript.
> > → Your code is not concise.
> >
> > - When doing stuff in Prolog you have automatically
> > some flexible indexing, like first argument indexing. Also
> > Prolog has additional garbage collection. Things not
> > available in JavaScript.
> > → Your code is not efficient.
> >
> > - It might be prohibitive to call repeatedly Prolog
> > predicates during JavaScript rendering. So that
> > you might implement stuff twice, in Prolog and
> > in JavaScript.
> > → Your code is not single source.
> >
> > - What else?
> > Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 21:32:54 UTC+1:
> > > Just dont use it for DCG. This here is much more better:
> > >
> > > p --> q; r.
> > > ?- listing.
> > >
> > > p(_0, _1) :- q(_0, _1); r(_0, _1).
> > > true.
> > >
> > > Works in Dogelog like that:
> > > http://www.xlog.ch/izytab/moblet/en/docs/18_live/10_reference/example01/package.html
> > >
> > > Rational: Ever tried to convert some ordinary code into
> > > DCG? With (;)/2 reflected as (;)/4 in DCG, this is easy.
> > > Just replace (:-)/2 by (-->)/2.
> > >
> > > But now the DCG draft wants people to also change (;)/2
> > > into (|)/4. What a nonsense, since (,)/2 reflects into (,)/4,
> > > (->)/2 reflects into (->)/2 and !/0 reflects into !/2.
> > >
> > > With the Dogelog approach all ISO control construct
> > > reflect without any need for renaming. You can leave '|'
> > > untouched and use it for TPTP Syntax side by side
> > >
> > > with DCG. On the other hand the DCG Draft wants an
> > > exception for the (;)/2 and reflect it into (|)/2, causing
> > > infinitely many nonsense problems.
> > >
> > > See also:
> > >
> > > % operator definitions (TPTP syntax)
> > >
> > > :- op( 500, fy, ~). % negation
> > > :- op(1000, xfy, &). % conjunction
> > > :- op(1100, xfy, '|'). % disjunction
> > > :- op(1110, xfy, =>). % implication
> > >
> > > https://www.philipzucker.com/javascript-automated-proving/

Here is a little educational parser called Birdy. Joseph Vidal-Rosset might
use it in his prover web site? It understands xfy and fy only, very primitiv.
Advantage, Birdy accepts lower and upper case as atom:

/* Welcome to SWI-Prolog (threaded, 64 bits, version 8.5.1) */

?- parse('p=>(q=>p)', T), write_canonical(T), nl.
=>(p,=>(q,p))

?- parse('P=>(Q=>P)', T), write_canonical(T), nl.
=>('P',=>('Q','P'))

?- parse('p=>p|q=>(q=> ~ ~r&s)', T), write_canonical(T), nl.
=>(p,=>('|'(p,q),=>(q,&(~(~(r)),s))))

Thats the code of Birdy:

:- set_prolog_flag(double_quotes, codes).

oper(500, fy, ~).
oper(1000, xfy, &).
oper(1100, xfy, '|').
oper(1110, xfy, =>).

parse(A, T) :-
atom_codes(A, C),
tokens(L, C, []),
term(T, 1200, L, []).

term(X, L) --> factor(Y), rest(Y, L, X).

rest(Y, L, S) --> [atom(X)], {oper(M, xfy, X)}, {M =< L}, !,
term(Z, M), {T =.. [X,Y,Z]}, rest(T, L, S).
rest(Y, _, Y) --> [].

factor(X) --> [lpar], !, term(X, 1200), [rpar].
factor(Z) --> [atom(X)], {oper(L, fy, X)}, !,
term(Y, L), {Z =.. [X,Y]}.
factor(X) --> [atom(X)].

This belongs also to Birdy, the tokenizer:

tokens([X|L]) --> token(X), !, tokens(L).
tokens([]) --> [].

token(F) --> " ", !, token(F).
token(atom(A)) --> alpha(X), !, alphanums(L), {atom_codes(A, [X|L])}.
token(atom(A)) --> sym(X), !, syms(L), {atom_codes(A, [X|L])}.
token(lpar) --> "(", !.
token(rpar) --> ")".

alphanums([X|L]) --> alpha(X), !, alphanums(L).
alphanums([X|L]) --> num(X), !, alphanums(L).
alphanums([]) --> [].

alpha(X) --> [X], {0'a =< X, X =< 0'z}, !.
alpha(X) --> [X], {0'A =< X, X =< 0'Z}, !.
alpha(X) --> [X], {member(X, "_")}.

num(X) --> [X], {0'0 =< X, X =< 0'9}, !.

syms([X|L]) --> sym(X), !, syms(L).
syms([]) --> [].

sym(X) --> [X], {member(X, "<=>&|~")}.

Why do such a thing? Well it gets interesting, since we could now
add quantifier parsing, which is not available in ordinary Prolog. We
could also extend it by automatically for example mapping Unicode
→ into ASCII =>.

Mostowski Collapse schrieb am Dienstag, 11. Januar 2022 um 23:55:49 UTC+1:
> Here is a little educational parser called Birdy. Joseph Vidal-Rosset might
> use it in his prover web site? It understands xfy and fy only, very primitiv.
> Advantage, Birdy accepts lower and upper case as atom:
>
> /* Welcome to SWI-Prolog (threaded, 64 bits, version 8.5.1) */
>
> ?- parse('p=>(q=>p)', T), write_canonical(T), nl.
> =>(p,=>(q,p))
>
> ?- parse('P=>(Q=>P)', T), write_canonical(T), nl.
> =>('P',=>('Q','P'))
>
> ?- parse('p=>p|q=>(q=> ~ ~r&s)', T), write_canonical(T), nl.
> =>(p,=>('|'(p,q),=>(q,&(~(~(r)),s))))
>
> Thats the code of Birdy:
>
> :- set_prolog_flag(double_quotes, codes).
>
> oper(500, fy, ~).
> oper(1000, xfy, &).
> oper(1100, xfy, '|').
> oper(1110, xfy, =>).
>
> parse(A, T) :-
> atom_codes(A, C),
> tokens(L, C, []),
> term(T, 1200, L, []).
>
> term(X, L) --> factor(Y), rest(Y, L, X).
>
> rest(Y, L, S) --> [atom(X)], {oper(M, xfy, X)}, {M =< L}, !,
> term(Z, M), {T =.. [X,Y,Z]}, rest(T, L, S).
> rest(Y, _, Y) --> [].
>
> factor(X) --> [lpar], !, term(X, 1200), [rpar].
> factor(Z) --> [atom(X)], {oper(L, fy, X)}, !,
> term(Y, L), {Z =.. [X,Y]}.
> factor(X) --> [atom(X)].

Ok I made a further version, which in summary adresses
two issues with the default Prolog parser:

- Upper Case: The new tokenizer should not classify upper
case tokens into Prolog variables, instead they should
simply go into Prolog atoms.

- Solo Characters: The new tokenizer should have a larger
class of solo character tokens, this is more comfortable
for prefix operators.

See also:

Prolog Operator Syntax in One Page
https://twitter.com/dogelogch/status/1481227386939183107

Prolog Operator Syntax in One Page
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb am Dienstag, 11. Januar 2022 um 23:58:01 UTC+1:
> This belongs also to Birdy, the tokenizer:
>
> tokens([X|L]) --> token(X), !, tokens(L).
> tokens([]) --> [].
>
> token(F) --> " ", !, token(F).
> token(atom(A)) --> alpha(X), !, alphanums(L), {atom_codes(A, [X|L])}.
> token(atom(A)) --> sym(X), !, syms(L), {atom_codes(A, [X|L])}.
> token(lpar) --> "(", !.
> token(rpar) --> ")".
>
> alphanums([X|L]) --> alpha(X), !, alphanums(L).
> alphanums([X|L]) --> num(X), !, alphanums(L).
> alphanums([]) --> [].
>
> alpha(X) --> [X], {0'a =< X, X =< 0'z}, !.
> alpha(X) --> [X], {0'A =< X, X =< 0'Z}, !.
> alpha(X) --> [X], {member(X, "_")}.
>
> num(X) --> [X], {0'0 =< X, X =< 0'9}, !.
>
> syms([X|L]) --> sym(X), !, syms(L).
> syms([]) --> [].
>
> sym(X) --> [X], {member(X, "<=>&|~")}.
>
> Why do such a thing? Well it gets interesting, since we could now
> add quantifier parsing, which is not available in ordinary Prolog. We
> could also extend it by automatically for example mapping Unicode
> → into ASCII =>.
> Mostowski Collapse schrieb am Dienstag, 11. Januar 2022 um 23:55:49 UTC+1:
> > Here is a little educational parser called Birdy. Joseph Vidal-Rosset might
> > use it in his prover web site? It understands xfy and fy only, very primitiv.
> > Advantage, Birdy accepts lower and upper case as atom:
> >
> > /* Welcome to SWI-Prolog (threaded, 64 bits, version 8.5.1) */
> >
> > ?- parse('p=>(q=>p)', T), write_canonical(T), nl.
> > =>(p,=>(q,p))
> >
> > ?- parse('P=>(Q=>P)', T), write_canonical(T), nl.
> > =>('P',=>('Q','P'))
> >
> > ?- parse('p=>p|q=>(q=> ~ ~r&s)', T), write_canonical(T), nl.
> > =>(p,=>('|'(p,q),=>(q,&(~(~(r)),s))))
> >
> > Thats the code of Birdy:
> >
> > :- set_prolog_flag(double_quotes, codes).
> >
> > oper(500, fy, ~).
> > oper(1000, xfy, &).
> > oper(1100, xfy, '|').
> > oper(1110, xfy, =>).
> >
> > parse(A, T) :-
> > atom_codes(A, C),
> > tokens(L, C, []),
> > term(T, 1200, L, []).
> >
> > term(X, L) --> factor(Y), rest(Y, L, X).
> >
> > rest(Y, L, S) --> [atom(X)], {oper(M, xfy, X)}, {M =< L}, !,
> > term(Z, M), {T =.. [X,Y,Z]}, rest(T, L, S).
> > rest(Y, _, Y) --> [].
> >
> > factor(X) --> [lpar], !, term(X, 1200), [rpar].
> > factor(Z) --> [atom(X)], {oper(L, fy, X)}, !,
> > term(Y, L), {Z =.. [X,Y]}.
> > factor(X) --> [atom(X)].

BTW: I have already a prototype in the pipeline that can do
quantifiers. But unfortunately not yet in the TPTP syntax.
Also not in the TPTP syntax with my modification.

But its relatively easy to add quantifier syntax to such
a parser/unparser. For example I added, so the idea is
that a quantifier has novel associativity icon fzy:

oper(!, fzy, 500).
oper(?, fzy, 500).

The parser needs only this additional clause:

factor(T) --> [atom(X)], {oper(X, fzy, M)}, !,
term(Y, 0), term(Z, M), {T =.. [X,Y,Z]}.

The unparser needs only this additional clause:

show(T, L) --> {T =.. [X, Y, Z], oper(X, fzy, M)}, !,
needs(L, M, '('),
[X], show(Y, 0), [' '], show(Z, M),
needs(L, M, ')').

Eh voilà the following works:

?- parse('!x p=>?x p', X).
X = =>(!(x, p), ?(x, p)).

?- unparse(=>(!(x, p), ?(x, p)), X).
X = '!x p=>?x p'.

?- parse('!x(p=>q)=>!x p=>!x q', X).
X = =>(!(x, =>(p, q)), =>(!(x, p), !(x, q))).

?- unparse(=>(!(x, =>(p, q)), =>(!(x, p), !(x, q))), X).
X = '!x (p=>q)=>!x p=>!x q'.

They are on par with prefix operators, so I assume they are
solo characters, which I did arrange in the tokenizer, and I
can then omit spaces around them.

Mostowski Collapse schrieb am Mittwoch, 12. Januar 2022 um 12:58:21 UTC+1:
> Ok I made a further version, which in summary adresses
> two issues with the default Prolog parser:
>
> - Upper Case: The new tokenizer should not classify upper
> case tokens into Prolog variables, instead they should
> simply go into Prolog atoms.
>
> - Solo Characters: The new tokenizer should have a larger
> class of solo character tokens, this is more comfortable
> for prefix operators.
>
> See also:
>
> Prolog Operator Syntax in One Page
> https://twitter.com/dogelogch/status/1481227386939183107
>
> Prolog Operator Syntax in One Page
> https://www.facebook.com/groups/dogelog
> Mostowski Collapse schrieb am Dienstag, 11. Januar 2022 um 23:58:01 UTC+1:
> > This belongs also to Birdy, the tokenizer:
> >
> > tokens([X|L]) --> token(X), !, tokens(L).
> > tokens([]) --> [].
> >
> > token(F) --> " ", !, token(F).
> > token(atom(A)) --> alpha(X), !, alphanums(L), {atom_codes(A, [X|L])}.
> > token(atom(A)) --> sym(X), !, syms(L), {atom_codes(A, [X|L])}.
> > token(lpar) --> "(", !.
> > token(rpar) --> ")".
> >
> > alphanums([X|L]) --> alpha(X), !, alphanums(L).
> > alphanums([X|L]) --> num(X), !, alphanums(L).
> > alphanums([]) --> [].
> >
> > alpha(X) --> [X], {0'a =< X, X =< 0'z}, !.
> > alpha(X) --> [X], {0'A =< X, X =< 0'Z}, !.
> > alpha(X) --> [X], {member(X, "_")}.
> >
> > num(X) --> [X], {0'0 =< X, X =< 0'9}, !.
> >
> > syms([X|L]) --> sym(X), !, syms(L).
> > syms([]) --> [].
> >
> > sym(X) --> [X], {member(X, "<=>&|~")}.
> >
> > Why do such a thing? Well it gets interesting, since we could now
> > add quantifier parsing, which is not available in ordinary Prolog. We
> > could also extend it by automatically for example mapping Unicode
> > → into ASCII =>.
> > Mostowski Collapse schrieb am Dienstag, 11. Januar 2022 um 23:55:49 UTC+1:
> > > Here is a little educational parser called Birdy. Joseph Vidal-Rosset might
> > > use it in his prover web site? It understands xfy and fy only, very primitiv.
> > > Advantage, Birdy accepts lower and upper case as atom:
> > >
> > > /* Welcome to SWI-Prolog (threaded, 64 bits, version 8.5.1) */
> > >
> > > ?- parse('p=>(q=>p)', T), write_canonical(T), nl.
> > > =>(p,=>(q,p))
> > >
> > > ?- parse('P=>(Q=>P)', T), write_canonical(T), nl.
> > > =>('P',=>('Q','P'))
> > >
> > > ?- parse('p=>p|q=>(q=> ~ ~r&s)', T), write_canonical(T), nl.
> > > =>(p,=>('|'(p,q),=>(q,&(~(~(r)),s))))
> > >
> > > Thats the code of Birdy:
> > >
> > > :- set_prolog_flag(double_quotes, codes).
> > >
> > > oper(500, fy, ~).
> > > oper(1000, xfy, &).
> > > oper(1100, xfy, '|').
> > > oper(1110, xfy, =>).
> > >
> > > parse(A, T) :-
> > > atom_codes(A, C),
> > > tokens(L, C, []),
> > > term(T, 1200, L, []).
> > >
> > > term(X, L) --> factor(Y), rest(Y, L, X).
> > >
> > > rest(Y, L, S) --> [atom(X)], {oper(M, xfy, X)}, {M =< L}, !,
> > > term(Z, M), {T =.. [X,Y,Z]}, rest(T, L, S).
> > > rest(Y, _, Y) --> [].
> > >
> > > factor(X) --> [lpar], !, term(X, 1200), [rpar].
> > > factor(Z) --> [atom(X)], {oper(L, fy, X)}, !,
> > > term(Y, L), {Z =.. [X,Y]}.
> > > factor(X) --> [atom(X)].

Ok, there is a first prototype integrating the one page
Prolog operator syntax code, with the MathJax renderer.
The idea is simple, add a column to the table oper/3:

oper(~, fy, 800, '\\neg ').
oper(&, xfy, 1000, ' \\land ').
oper('|', xfy, 1100, ' \\lor ').
oper(=>, xfy, 1200, ' \\implies ').

See also:

Latex Bliss from Prolog Operator Syntax
https://twitter.com/dogelogch/status/1481360427636375554

Latex Bliss from Prolog Operator Syntax
https://www.facebook.com/groups/dogelog

Now having fun with an output switch, can do:

?- parse('∀x ∃y f(x) = y', F).
F = !(:([_0 = x], ?(:([_1 = y], f(_0) = _1)))).

?- unparse(!(:([A = x], ?(:([B = y], f(A) = B)))), unicode, T).
T = '∀x ∃y f(x) = y'.

?- unparse(!(:([A = x], ?(:([B = y], f(A) = B)))), latex, T).
T = '\\forall x\\, \\exists y\\, \\mathup{f}(x) = y'.

The LaTeX DCG result can be used inside a browser via MathJax.
But with the novel operator type fzy, that is used under the hood,
I am also solving another problem, not only LaTeX output.

The other problem that is also solved is dealing with input and output
of formulas that contain quantifiers. The library is now called
Formula Interlingua Library (FIL).

See also:

Formula Interlingua from Prolog Operator Syntax
https://twitter.com/dogelogch/status/1482536744872521732

Formula Interlingua from Prolog Operator Syntax
https://www.facebook.com/groups/dogelog

Mostowski Collapse schrieb am Mittwoch, 12. Januar 2022 um 21:47:49 UTC+1:
> Ok, there is a first prototype integrating the one page
> Prolog operator syntax code, with the MathJax renderer.
> The idea is simple, add a column to the table oper/3:
>
> oper(~, fy, 800, '\\neg ').
> oper(&, xfy, 1000, ' \\land ').
> oper('|', xfy, 1100, ' \\lor ').
> oper(=>, xfy, 1200, ' \\implies ').
>
> See also:
>
> Latex Bliss from Prolog Operator Syntax
> https://twitter.com/dogelogch/status/1481360427636375554
>
> Latex Bliss from Prolog Operator Syntax
> https://www.facebook.com/groups/dogelog

Adding MathJax to your web site is very simple,
bypassing the now outdated and not widely
supported MathML. MathJax notes the following

problems with MathML:

> CommonHTML and not MathML is MathJax’s primary output
> mode since MathJax version 2.6. Its major advantage is its
> quality, consistency, and the fact that its output is independent
> of the browser, operating system, and user environment.
> HTML Support — MathJax 3.2 documentation
> https://docs.mathjax.org/en/latest/output/html.html

This worked for me:

- Step 1: Load the MathJax library. Load the CommonHTML
output processor (chtml), that renders your mathematics
using HTML with CSS styling:

<script src="http://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js"
id="MathJax-script" async=""> </script>

- Step 2: Make the MathJax library load some stuff by itself.
This is a little cludge, not sure what would be the official
approach here, this loads bussproof:

<p>\begin{prooftree} \end{prooftree}</p>

- Step 3: Notify MathJax library if you have DOM changes. Not
needed after browser page load, only for user interaction. Do
this JavaScript when you are finished doing updates:

MathJax.typeset();

Mostowski Collapse schrieb am Sonntag, 16. Januar 2022 um 13:25:57 UTC+1:
> Now having fun with an output switch, can do:
>
> ?- parse('∀x ∃y f(x) = y', F).
> F = !(:([_0 = x], ?(:([_1 = y], f(_0) = _1)))).
>
> ?- unparse(!(:([A = x], ?(:([B = y], f(A) = B)))), unicode, T).
> T = '∀x ∃y f(x) = y'.
>
> ?- unparse(!(:([A = x], ?(:([B = y], f(A) = B)))), latex, T).
> T = '\\forall x\\, \\exists y\\, \\mathup{f}(x) = y'.
>
> The LaTeX DCG result can be used inside a browser via MathJax.
> But with the novel operator type fzy, that is used under the hood,
> I am also solving another problem, not only LaTeX output.
>
> The other problem that is also solved is dealing with input and output
> of formulas that contain quantifiers. The library is now called
> Formula Interlingua Library (FIL).
>
> See also:
>
> Formula Interlingua from Prolog Operator Syntax
> https://twitter.com/dogelogch/status/1482536744872521732
>
> Formula Interlingua from Prolog Operator Syntax
> https://www.facebook.com/groups/dogelog
> Mostowski Collapse schrieb am Mittwoch, 12. Januar 2022 um 21:47:49 UTC+1:
> > Ok, there is a first prototype integrating the one page
> > Prolog operator syntax code, with the MathJax renderer.
> > The idea is simple, add a column to the table oper/3:
> >
> > oper(~, fy, 800, '\\neg ').
> > oper(&, xfy, 1000, ' \\land ').
> > oper('|', xfy, 1100, ' \\lor ').
> > oper(=>, xfy, 1200, ' \\implies ').
> >
> > See also:
> >
> > Latex Bliss from Prolog Operator Syntax
> > https://twitter.com/dogelogch/status/1481360427636375554
> >
> > Latex Bliss from Prolog Operator Syntax
> > https://www.facebook.com/groups/dogelog

Currently picking up the topic again. Seems I don't run
into problems when abandoning (|)/2 and favoring (;)/2 for DCG.

Its rather the rule to have (;)/2 and the exception
to have (|)/2. Take this example:

p --> q;r.
p --> q|r.

Just out of curriousity checked TauProlog, it barks
at the operator (|)/2, but does (;)/2:

error parsing program: error(syntax_error(. or operator
expected),[line(3),column(7),found(|)])
?- listing(p/2).
p(_1,_3) :- (q(_1,_2);r(_1,_3)),_2=_3.

And then checked SWI-Prolog. It does both operators:

?- listing(p/2).
p(A, B) :-
( q(A, B)
; r(A, B)
).
p(A, B) :-
( q(A, B)
; r(A, B)
).

So they both have (;)/2 as DCG disjunction.
Thats nice.

Mostowski Collapse schrieb am Montag, 10. Januar 2022 um 22:15:21 UTC+1:
> I dont know yet how much legacy will be destroyed by
> adopting (;)/2 and only (;)/2. If I remember well some
> Prolog system support both (|)/2 and (;)/2 in DCG?
>
> Not sure. And not sure what the experts say.
> Typically (|)/2 is rather rare, because for DCG there
> is not so much the idiom as seen in syntax docu:
>
> p --> "foo"
> | "bar"
> | "baz".
>
> Since we want to parse something, and return
> something. So although a syntax docu might read
> as in the above, practically this often turns into:
>
> p(ast1) --> "foo".
> p(ast2) --> "bar".
> p(ast3) --> "baz".
>
> The DCG disjunction disappears!

Some of the best kept secrets in Prolog. How to make a parser
that can parse TPTP Syntax? Here is the problem:

:- op( 600, fy, !).
prove(F, C, I) :- norm(F, C, G), iter(G, 0, C, I), !.

Hell breaks loose, and a naive Prolog parser wants me to write the
cut with parenthesis (!). But SWI-Prolog doesn't need that.

What is the magic potion that does this feat?

See also:
https://github.com/mthom/scryer-prolog/issues/1289

For example in formerly Jekejeke Prolog and in Dogelog I can
also parse the same. Because I do have additional rules to the
following operator escaping that is suggested:

(!)

I added these operator escapes, the ')' escaping is only a special
case of it, the general routine does the following:

% read_prefix(-Term, +Integer, +Integer, +Integer, +Quad, -Quad)
read_prefix(A, A, _, _, _) --> current_token(T), {is_stopper(T)}, !.
read_prefix(H, A, L, R, E) -->
{L < R -> throw(error(syntax_error(operator_clash), _)); true},
{T is R-E}, read(Z, T), {H =.. [A, Z]}.
% is_stopper(+Term)
is_stopper(',').
is_stopper('|').
is_stopper(')'). %%% Covers the usual ( op ) and more %%%%
is_stopper(']').
is_stopper('}').
is_stopper('.').

Its open source and 100% pure Prolog:
http://pages.xlog.ch/littab/doclet/docs/05_devel/transpiler/loader.html

Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:23:10 UTC+1:
> Some of the best kept secrets in Prolog. How to make a parser
> that can parse TPTP Syntax? Here is the problem:
>
> :- op( 600, fy, !).
> prove(F, C, I) :- norm(F, C, G), iter(G, 0, C, I), !.
>
> Hell breaks loose, and a naive Prolog parser wants me to write the
> cut with parenthesis (!). But SWI-Prolog doesn't need that.
>
> What is the magic potion that does this feat?
>
> See also:
> https://github.com/mthom/scryer-prolog/issues/1289

SWI-Prolog might have yet another heuristic, this is genuine
Dogelog player. But its a quite useful heuristic. Here you see
how the ',' stopper together with the ')' stopper does a little more.

I can for example parse the following in Dogelog player:

?- X = (-, -).
X = (-, -).
http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html

SWI-Prolog adds some parenthesis around - during writing, but
this is not necessary, when it can parse it without, why should it
write it with? Formerly Jekejeke Prolog and Dogelog cover this

case also during writing. On the other hand Scryer Prolog gives me:

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

Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:26:12 UTC+1:
> For example in formerly Jekejeke Prolog and in Dogelog I can
> also parse the same. Because I do have additional rules to the
> following operator escaping that is suggested:
>
> (!)
>
> I added these operator escapes, the ')' escaping is only a special
> case of it, the general routine does the following:
>
> % read_prefix(-Term, +Integer, +Integer, +Integer, +Quad, -Quad)
> read_prefix(A, A, _, _, _) --> current_token(T), {is_stopper(T)}, !.
> read_prefix(H, A, L, R, E) -->
> {L < R -> throw(error(syntax_error(operator_clash), _)); true},
> {T is R-E}, read(Z, T), {H =.. [A, Z]}.
> % is_stopper(+Term)
> is_stopper(',').
> is_stopper('|').
> is_stopper(')'). %%% Covers the usual ( op ) and more %%%%
> is_stopper(']').
> is_stopper('}').
> is_stopper('.').
>
> Its open source and 100% pure Prolog:
> http://pages.xlog.ch/littab/doclet/docs/05_devel/transpiler/loader.html
> Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:23:10 UTC+1:
> > Some of the best kept secrets in Prolog. How to make a parser
> > that can parse TPTP Syntax? Here is the problem:
> >
> > :- op( 600, fy, !).
> > prove(F, C, I) :- norm(F, C, G), iter(G, 0, C, I), !.
> >
> > Hell breaks loose, and a naive Prolog parser wants me to write the
> > cut with parenthesis (!). But SWI-Prolog doesn't need that.
> >
> > What is the magic potion that does this feat?
> >
> > See also:
> > https://github.com/mthom/scryer-prolog/issues/1289

In general I think its good that SWI-Prolog pioneers a little bit
more than what is usually considered Prolog syntax. The only
problem is that Prolog has no “Living Standard” project,

unlike for example HTML.
https://html.spec.whatwg.org/

Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:30:28 UTC+1:
> SWI-Prolog might have yet another heuristic, this is genuine
> Dogelog player. But its a quite useful heuristic. Here you see
> how the ',' stopper together with the ')' stopper does a little more.
>
> I can for example parse the following in Dogelog player:
>
> ?- X = (-, -).
> X = (-, -).
> http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html
>
> SWI-Prolog adds some parenthesis around - during writing, but
> this is not necessary, when it can parse it without, why should it
> write it with? Formerly Jekejeke Prolog and Dogelog cover this
>
> case also during writing. On the other hand Scryer Prolog gives me:
>
> ?- X = (-, -).
> caught: error(syntax_error(incomplete_reduction),read_term/3:1)
> Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:26:12 UTC+1:
> > For example in formerly Jekejeke Prolog and in Dogelog I can
> > also parse the same. Because I do have additional rules to the
> > following operator escaping that is suggested:
> >
> > (!)
> >
> > I added these operator escapes, the ')' escaping is only a special
> > case of it, the general routine does the following:
> >
> > % read_prefix(-Term, +Integer, +Integer, +Integer, +Quad, -Quad)
> > read_prefix(A, A, _, _, _) --> current_token(T), {is_stopper(T)}, !.
> > read_prefix(H, A, L, R, E) -->
> > {L < R -> throw(error(syntax_error(operator_clash), _)); true},
> > {T is R-E}, read(Z, T), {H =.. [A, Z]}.
> > % is_stopper(+Term)
> > is_stopper(',').
> > is_stopper('|').
> > is_stopper(')'). %%% Covers the usual ( op ) and more %%%%
> > is_stopper(']').
> > is_stopper('}').
> > is_stopper('.').
> >
> > Its open source and 100% pure Prolog:
> > http://pages.xlog.ch/littab/doclet/docs/05_devel/transpiler/loader.html
> > Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 01:23:10 UTC+1:
> > > Some of the best kept secrets in Prolog. How to make a parser
> > > that can parse TPTP Syntax? Here is the problem:
> > >
> > > :- op( 600, fy, !).
> > > prove(F, C, I) :- norm(F, C, G), iter(G, 0, C, I), !.
> > >
> > > Hell breaks loose, and a naive Prolog parser wants me to write the
> > > cut with parenthesis (!). But SWI-Prolog doesn't need that.
> > >
> > > What is the magic potion that does this feat?
> > >
> > > See also:
> > > https://github.com/mthom/scryer-prolog/issues/1289

It is extremly trivial as the is_stopper/1 source code shows,
it can be verbalized as follows:

/**
* Dont use the grammar production prefix_op term, when term is
* anyway no term determined by looking at the current token.
*/
And when in doubt, you can just try it online:

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

http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html

I have the impression many Prolog systems have it or had it, and maybe
it slipped the ISO core standard or the Ulrich Neumerkel test cases, otherwise
I cannot explain how mode declarations such as append(+, +, -)

were/are handled? The is_stopper/1 doesn't change when something is a
prefix operator, its a conservative extension concerning the accepted
sentences by the language grammar.

It only changes when something is not a prefix operator. It produces
less many errors, i.e. the cryptic incomplete_reduction error by Scryer
Prolog goes away. It does so in a very simple and efficient way, not

needing some extra look ahead or complicated algorithm.

Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 10:48:07 UTC+1:
> It is extremly trivial as the is_stopper/1 source code shows,
> it can be verbalized as follows:
>
> /**
> * Dont use the grammar production prefix_op term, when term is
> * anyway no term determined by looking at the current token.
> */
> And when in doubt, you can just try it online:
>
> ?- X = (- - a), write_canonical(X), nl.
> -(-(a))
> X = - -a.
> ?- X = (- - -), write_canonical(X), nl.
> -(-(-))
> X = - - - .
>
> http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html

The main challenge for Dogelog player was only to write a tokenizer
that plays into the hands of the parser, so that is_stopper/1 works
as desired. Note that I also have is_stopper('|'). This is consistent with:

?- X = '|'.
X = '|'.

?- X = | .
error(syntax_error(cannot_start_term), _0)
http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html

So there is some special handling of ',' and '|' already in the
tokenizer. For example the bare | is tokenized as '|' whereas
the quoted '|' is tokenized as atom('|').

Conceptually the same happens now in Dogelog player
and formerly Jekejeke Prolog, although Jekejeke Prolog does it
in Java, whereas Dogelog player does it in Prolog itself,

since also the tokenizer is 100% Prolog. So you could lookup
this part as well and find it "specified" in Prolog. Or lookup
some other Prolog or non-Prolog implementation.

Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 10:49:58 UTC+1:
> I have the impression many Prolog systems have it or had it, and maybe
> it slipped the ISO core standard or the Ulrich Neumerkel test cases, otherwise
> I cannot explain how mode declarations such as append(+, +, -)
>
> were/are handled? The is_stopper/1 doesn't change when something is a
> prefix operator, its a conservative extension concerning the accepted
> sentences by the language grammar.
>
> It only changes when something is not a prefix operator. It produces
> less many errors, i.e. the cryptic incomplete_reduction error by Scryer
> Prolog goes away. It does so in a very simple and efficient way, not
>
> needing some extra look ahead or complicated algorithm.
> Mostowski Collapse schrieb am Mittwoch, 23. Februar 2022 um 10:48:07 UTC+1:
> > It is extremly trivial as the is_stopper/1 source code shows,
> > it can be verbalized as follows:
> >
> > /**
> > * Dont use the grammar production prefix_op term, when term is
> > * anyway no term determined by looking at the current token.
> > */
> > And when in doubt, you can just try it online:
> >
> > ?- X = (- - a), write_canonical(X), nl.
> > -(-(a))
> > X = - -a.
> > ?- X = (- - -), write_canonical(X), nl.
> > -(-(-))
> > X = - - - .
> >
> > http://www.xlog.ch/izytab/doclet/docs/18_live/10_reference/example01/package.html

I got just new interest in the issue of a living standard.
I found more evidence that Prolog systems or Prolog
related languages implement something more elaborate

than what a certain interpretation of the ISO core standard
would gives. New use case, the Mercury language state
variables notation, which uses ! prefix:

main(!IO) :-
io.write_string("The 100th prime is ", !IO),
X = prime(100),
io.write_int(X, !IO),
io.nl(!IO).
https://www.mercurylang.org/information/doc-latest/mercury_ref/State-variables.html#State-variables

Bringing the above to Prolog, you will possibly get scolded by
the ISO core standard orthodoxy fighters. As soon as ! is a prefix,
according to the orthodoxy fighters, whos names I do not want to

mention, you have to write (!) in your ordinary code, for the ordinary cut.

So there is a new study object, SWI-Prolog parser/scanner
reverse engineered into partially pPEG and manual Prolog code.

https://github.com/ridgeworks/pPEGpl/tree/main/Examples/SWIP-grammar

It becomes now apparent why SWI-Prolog is quite some dialect.
A lot of Prolog coding! Cudos. Trying to understand the example.

Historical backround why I am asking. The old DEC-10 Prolog
manual had a DCG specification of the Prolog syntax, which can
be turned into a direct Prolog parser, unless maybe when the

dialect is too far away. And pPEG can be more directly realized by
using DCG (\+)/1 for the non consuming features of pPEG and
by using DCG (!)/0 for the commited choice features of pPEG,

making pPEG anyway a rip-off of DCG. So I would imagine
a transpiler from pPEG to DCG, a path that was not chosen,
possibly because more complex threaded state.

Mostowski Collapse schrieb am Donnerstag, 3. März 2022 um 16:51:56 UTC+1:
> I got just new interest in the issue of a living standard.
> I found more evidence that Prolog systems or Prolog
> related languages implement something more elaborate
>
> than what a certain interpretation of the ISO core standard
> would gives. New use case, the Mercury language state
> variables notation, which uses ! prefix:
>
> main(!IO) :-
> io.write_string("The 100th prime is ", !IO),
> X = prime(100),
> io.write_int(X, !IO),
> io.nl(!IO).
> https://www.mercurylang.org/information/doc-latest/mercury_ref/State-variables.html#State-variables
>
> Bringing the above to Prolog, you will possibly get scolded by
> the ISO core standard orthodoxy fighters. As soon as ! is a prefix,
> according to the orthodoxy fighters, whos names I do not want to
>
> mention, you have to write (!) in your ordinary code, for the ordinary cut.

But putting aside how pPEG was implement. It is not
fully used. The SWIPL example uses the formal grammar
only for tokenization? Or something between tokenization

and parsing. Then something interesting happens in a second
pass and a separate Prolog text, not anymore pPEG based, the
parsed expression is flattened and then rebuilt again only then

using operators priority. So pPEG was not chosen to parse
the SWIPL dialect itself directly?

Mostowski Collapse schrieb am Samstag, 5. März 2022 um 03:21:23 UTC+1:
> So there is a new study object, SWI-Prolog parser/scanner
> reverse engineered into partially pPEG and manual Prolog code.
>
> https://github.com/ridgeworks/pPEGpl/tree/main/Examples/SWIP-grammar
>
> It becomes now apparent why SWI-Prolog is quite some dialect.
> A lot of Prolog coding! Cudos. Trying to understand the example.
>
> Historical backround why I am asking. The old DEC-10 Prolog
> manual had a DCG specification of the Prolog syntax, which can
> be turned into a direct Prolog parser, unless maybe when the
>
> dialect is too far away. And pPEG can be more directly realized by
> using DCG (\+)/1 for the non consuming features of pPEG and
> by using DCG (!)/0 for the commited choice features of pPEG,
>
> making pPEG anyway a rip-off of DCG. So I would imagine
> a transpiler from pPEG to DCG, a path that was not chosen,
> possibly because more complex threaded state.
> Mostowski Collapse schrieb am Donnerstag, 3. März 2022 um 16:51:56 UTC+1:
> > I got just new interest in the issue of a living standard.
> > I found more evidence that Prolog systems or Prolog
> > related languages implement something more elaborate
> >
> > than what a certain interpretation of the ISO core standard
> > would gives. New use case, the Mercury language state
> > variables notation, which uses ! prefix:
> >
> > main(!IO) :-
> > io.write_string("The 100th prime is ", !IO),
> > X = prime(100),
> > io.write_int(X, !IO),
> > io.nl(!IO).
> > https://www.mercurylang.org/information/doc-latest/mercury_ref/State-variables.html#State-variables
> >
> > Bringing the above to Prolog, you will possibly get scolded by
> > the ISO core standard orthodoxy fighters. As soon as ! is a prefix,
> > according to the orthodoxy fighters, whos names I do not want to
> >
> > mention, you have to write (!) in your ordinary code, for the ordinary cut.

Such 100% Prolog tokenizers and parsers are quite interesting. One could
attempt a multi-Prolog that can read various dialects of Prolog systems.
But if you would do that, you would possibly choose some

framework and model all Prolog system dialects in this framework?
Become independent of the other Prolog systems and its other
plattform. On the other hand one could of course spawn the other

Prolog system, consut there and call some listing/1 or write_canonical/1
to get the Prolog text. Wasn’t Logtalk working on a package exchange.
A package could have a tag in which dialect it is implemented and

a multi-Prolog could act accordingly.

Living standard Prolog systems could also solve the package
exchange problem. The packages would not have a dialect tag,
the Prolog system would be polyglott enough to understand

a more flexible Prolog syntax. For example SWI-Prolog allows me to do,
something that is often used in TPTP syntax:

/* SWI-Prolog (threaded, 64 bits, version 8.5.1) */
?- [user].
p(A :- B) :- q(A), r(B).
^D

In another Prolog system this is not accepted:

/* TauProlog 0.3.2 (beta) */

/* In Program Textarea */
p(A :- B) :- q(A), r(B).

/* Press Reconsult program */
error parsing program: error(syntax_error(, or ) expected),[line(2),column(4),found(:-)])

But from reading Rick Workman reverse engineering of
SWI-Prolog dialect, I have now indeed an idea how this happens.
I guess I could try an according modification for the Dogelog player,

so that Dogelog player would be another living standard Prolog system.
Currently Dogelog player is already polyglott in some other corners of
the Prolog syntax, but not yet in this corner.

Mostowski Collapse schrieb am Samstag, 5. März 2022 um 22:42:40 UTC+1:
> Such 100% Prolog tokenizers and parsers are quite interesting. One could
> attempt a multi-Prolog that can read various dialects of Prolog systems.
> But if you would do that, you would possibly choose some
>
> framework and model all Prolog system dialects in this framework?
> Become independent of the other Prolog systems and its other
> plattform. On the other hand one could of course spawn the other
>
> Prolog system, consut there and call some listing/1 or write_canonical/1
> to get the Prolog text. Wasn’t Logtalk working on a package exchange.
> A package could have a tag in which dialect it is implemented and
>
> a multi-Prolog could act accordingly.

But this syntax enhancement will possibly not come in
release 0.9.8, too much other stuff to do. Also if Rick Workmans
reverse engineering where end-to-end grammarly specified,

also using some grammar notation for the operator
building phase, it would be easier to asses from paper
reading allone whether some ideas work or not,

currently its not end-to-end gammarly specified, we find:

properties such as precedence and associativity are part of the
semantics and will be addressed in post-parsing semantic analysis.
https://github.com/ridgeworks/pPEGpl/tree/main/Examples/SWIP-grammar

But usually this is not called semantics. If your operator building
pass turns surface S op T into op(S,T) thats not really semantics,
although some communities might like to call it so.

Specifications that are more grammarly are:

DEC-10 Prolog Manual (1982 University of Edinburgh, Dept of Artificial Intelligence)
https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/doc/intro/prolog.doc

Tau Prolog
http://tau-prolog.org/files/doc/grammar-specification.pdf

ISO Core Standard
Have to recheck how it casts the operator building...

Mostowski Collapse schrieb am Sonntag, 6. März 2022 um 12:49:17 UTC+1:
> Living standard Prolog systems could also solve the package
> exchange problem. The packages would not have a dialect tag,
> the Prolog system would be polyglott enough to understand
>
> a more flexible Prolog syntax. For example SWI-Prolog allows me to do,
> something that is often used in TPTP syntax:
>
> /* SWI-Prolog (threaded, 64 bits, version 8.5.1) */
> ?- [user].
> p(A :- B) :- q(A), r(B).
> ^D
>
> In another Prolog system this is not accepted:
>
> /* TauProlog 0.3.2 (beta) */
>
> /* In Program Textarea */
> p(A :- B) :- q(A), r(B).
>
> /* Press Reconsult program */
> error parsing program: error(syntax_error(, or ) expected),[line(2),column(4),found(:-)])
>
> But from reading Rick Workman reverse engineering of
> SWI-Prolog dialect, I have now indeed an idea how this happens.
> I guess I could try an according modification for the Dogelog player,
>
> so that Dogelog player would be another living standard Prolog system.
> Currently Dogelog player is already polyglott in some other corners of
> the Prolog syntax, but not yet in this corner.
> Mostowski Collapse schrieb am Samstag, 5. März 2022 um 22:42:40 UTC+1:
> > Such 100% Prolog tokenizers and parsers are quite interesting. One could
> > attempt a multi-Prolog that can read various dialects of Prolog systems..
> > But if you would do that, you would possibly choose some
> >
> > framework and model all Prolog system dialects in this framework?
> > Become independent of the other Prolog systems and its other
> > plattform. On the other hand one could of course spawn the other
> >
> > Prolog system, consut there and call some listing/1 or write_canonical/1
> > to get the Prolog text. Wasn’t Logtalk working on a package exchange.
> > A package could have a tag in which dialect it is implemented and
> >
> > a multi-Prolog could act accordingly.