BTW the real number quotient is this real number:

1267650600228229401496703205376 /
762385119722780192080867194597 =
1.66274310375991431383116365048...

Was using microsoft calculator desk accessory. But
maybe should do more testing of this new Python
mode trick. Nasty test cases might lure everywhere.

Mostowski Collapse schrieb am Mittwoch, 26. Oktober 2022 um 16:01:01 UTC+2:
> Here is a trick to force Python compatibility mode, I guess
> works for SWI-Prolog 8.5.20 which has improved rational
> number rounding? Thats the incorrectly rounded result:
>
> /* incorrectly rounded of the real number quotient */
> ?- X is 1267650600228229401496703205376 /
> 762385119722780192080867194597.
> X = 1.662743103759914.
> Now do switch on Python compatibility mode, and
> watch the result getting correctly rounded:
>
> /* Use this combo for Python compatibility:
> prefer_rationals=true,
> max_rational_size=0,
> max_rational_size_action=float */
> ?- set_prolog_flag(prefer_rationals, true).
> true.
>
> ?- set_prolog_flag(max_rational_size, 0).
> true.
>
> ?- set_prolog_flag(max_rational_size_action, float).
> true.
>
> /* Correctly rounded of the real number quotient, via
> detour over rational numbers, which are correctly
> rounded since release 8.5.20 of SWI-Prolog? */
> ?- X is 1267650600228229401496703205376 /
> 762385119722780192080867194597.
> X = 1.6627431037599143.

My latest take on msb/2, in case a Prolog system
doesn't have this built-in. Some hi lo search:

% msb(+Integer, -Integer)
msb(0, N) :- !, N = -1.
msb(X, N) :-
msb(X, 1, N).

% msb(+Integer, +Integer, -Integer)
msb(X, H, N) :-
X < (1<<H), !,
L is H>>1,
msb(X, L, H, N).
msb(X, H, N) :-
J is H<<1,
msb(X, J, N).

% msb(+Integer, +Integer, +Integer, -Integer)
msb(_, L, H, N) :- L+1 =:= H, !,
N = L.
msb(X, L, H, N) :- M is (L+H) >> 1,
X < (1<<M), !,
msb(X, L, M, N).
msb(X, L, H, N) :- M is (L+H) >> 1,
msb(X, M, H, N).

But it is not a replacement for the real thing.
An msb/1 evaluable function still performs better.

So when will all Prolog system have these basic
evaluable functions and predicates?

msb/1: Return most significant bit of an integer
lsb/1: Return least significant bit of an integer
testbit/2: Succeed if bit of integer is set, otherwise fail.
divmod/4: Succeed with div and mod.

Scryer Prolog doesn't have these built-ins. So emulating
them makes it utterly slow. Using the hi lo approach for msb:

/* Scryer Prolog 0.9.1 WSL2 */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% CPU time: 4.240s
% CPU time: 5.621s
% CPU time: 7.718s
% true.

But it seems that bigints are not that fast, with ECLiPSe Prolog
which does not have these built-ins the hi lo isn't that bad:

/* ECLiPSe Prolog 7.1.12 Windows */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time_eclipse((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
0.904113500000676 sec
1.78132879998884 sec
1.56477859998995 sec

The best is always SWI-Prolog. It picks up trends and provides
functionallity so that the end-user can profit:

/* SWI-Prolog 8.5.20 Windows GMP */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% 8,699,603 inferences, 0.875 CPU in 0.879 seconds (100% CPU, 9942403 Lips)
% 7,952,250 inferences, 1.047 CPU in 1.064 seconds (98% CPU, 7596179 Lips)
% 3,771,657 inferences, 0.656 CPU in 0.673 seconds (97% CPU, 5747287 Lips)
true.

Whats wrong with the other Prolog systems, such as Scryer
Prolog and ECLiPSe Prolog that don't provide these built-ins?

Are they in a comatose sleeping beauty sleep?

Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:21:11 UTC+1:
> My latest take on msb/2, in case a Prolog system
> doesn't have this built-in. Some hi lo search:
>
> % msb(+Integer, -Integer)
> msb(0, N) :- !, N = -1.
> msb(X, N) :-
> msb(X, 1, N).
>
> % msb(+Integer, +Integer, -Integer)
> msb(X, H, N) :-
> X < (1<<H), !,
> L is H>>1,
> msb(X, L, H, N).
> msb(X, H, N) :-
> J is H<<1,
> msb(X, J, N).
>
> % msb(+Integer, +Integer, +Integer, -Integer)
> msb(_, L, H, N) :- L+1 =:= H, !,
> N = L.
> msb(X, L, H, N) :- M is (L+H) >> 1,
> X < (1<<M), !,
> msb(X, L, M, N).
> msb(X, L, H, N) :- M is (L+H) >> 1,
> msb(X, M, H, N).
>
> But it is not a replacement for the real thing.
> An msb/1 evaluable function still performs better.

The best I can do for Dogelog Player, concerning
msb/1 and the JavaScript platform. Just imagine
the speed if JavaScript would have a real msb/1
or bitlength/1, so that we don't need this nonsense?

function bigint_msb(alpha) {
alpha = alpha.toString(16);
return 31 - Math.clz32(hexvalue(alpha.codePointAt(0))) + (alpha.length - 1)*4;
}

This is a known problem that bigint has no msb/1 or
bitlength/1 in JavaScript as of now. Nevertheless I now
easily beat Scryer Prolog even with Dogelog Player.
Comparing to the hi lo search msb I get these results:

/* Dogelog Player 1.0.3 Windows nodeJS */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% Wall 4136 ms, gc 10 ms, 2539128 lips
% Wall 4346 ms, gc 104 ms, 2219962 lips
% Wall 3876 ms, gc 88 ms, 1180529 lips
true.

Also unlike Scryer Prolog, for larger bigints, i.e. 8192
the timing doesn't go up, it rather goes down. Probably some
alternative bigint multiplication methods etc.. kick in for
larger bigints, and they are missing in Scryer Prolog for

the Rust based bigints? They are still in its fancy? Also
Scryer Prolog would fare better if it had a native msb/1.

Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:31:28 UTC+1:
> Scryer Prolog doesn't have these built-ins. So emulating
> them makes it utterly slow. Using the hi lo approach for msb:
>
> /* Scryer Prolog 0.9.1 WSL2 */
> ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> % CPU time: 4.240s
> % CPU time: 5.621s
> % CPU time: 7.718s
> % true.

The effect that computation gets faster for larger bigint
is also seen for Python, when I use the PyPy interpreter.
I guess it has also to do with the effort needed to

promote a smallint to a bigint, either before an operation
or after an operation. Another speculation would be, that
the bigint operations slow down the frequency of my

Dogelog Player garbage collection, since this frequency
is not yet adaptive. But the larger bit test case even
beats Scryer Prolog, now beaten by Python/PyPy:
/* Dogelog Player 1.0.3 Windows PyPy */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% Wall 18696 ms, gc 799 ms, 561771 lips
% Wall 12737 ms, gc 730 ms, 757550 lips
% Wall 7126 ms, gc 339 ms, 642182 lips
true.

The 7126 ms (Dogelog Player on PyPy) compared to the
7.718s (Scryer Prolog) is ca. 10% faster. I never though
that Dogelog Prolog on the Python platform could do

that, since Python is rather annonyingly slow.

Mostowski Collapse schrieb am Donnerstag, 17. November 2022 um 15:08:51 UTC+1:
> The best I can do for Dogelog Player, concerning
> msb/1 and the JavaScript platform. Just imagine
> the speed if JavaScript would have a real msb/1
> or bitlength/1, so that we don't need this nonsense?
>
> function bigint_msb(alpha) {
> alpha = alpha.toString(16);
> return 31 - Math.clz32(hexvalue(alpha.codePointAt(0))) + (alpha.length - 1)*4;
> }
>
> This is a known problem that bigint has no msb/1 or
> bitlength/1 in JavaScript as of now. Nevertheless I now
> easily beat Scryer Prolog even with Dogelog Player.
> Comparing to the hi lo search msb I get these results:
>
> /* Dogelog Player 1.0.3 Windows nodeJS */
> ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> % Wall 4136 ms, gc 10 ms, 2539128 lips
> % Wall 4346 ms, gc 104 ms, 2219962 lips
> % Wall 3876 ms, gc 88 ms, 1180529 lips
> true.
>
> Also unlike Scryer Prolog, for larger bigints, i.e. 8192
> the timing doesn't go up, it rather goes down. Probably some
> alternative bigint multiplication methods etc.. kick in for
> larger bigints, and they are missing in Scryer Prolog for
>
> the Rust based bigints? They are still in its fancy? Also
> Scryer Prolog would fare better if it had a native msb/1.
> Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:31:28 UTC+1:
> > Scryer Prolog doesn't have these built-ins. So emulating
> > them makes it utterly slow. Using the hi lo approach for msb:
> >
> > /* Scryer Prolog 0.9.1 WSL2 */
> > ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> > time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> > % CPU time: 4.240s
> > % CPU time: 5.621s
> > % CPU time: 7.718s
> > % true.

I guess its time to talk about DOM APIs inside Prolog,
and making them mature and portable. I am planning
to adopt the Tau Prolog DOM API.

But I have two DOM APIs in mind:

- Stateless DOM API: Basically Tau Prolog is a stateless
DOM API. All API calls have all the necessary parameters,
there is nothing implicit right?

- Statefull DOM API: On the other hand so far, in Dogelog
Player, I have used a statefull DOM API. With a notion
of cursor, you can imagine Turtle graphics, only the Turtle

is not a Turtle with location and orientation, but a node
somewhere in a DOM tree.

My plan is to give the Statefull DOM API a new try, but
bootstrapping it from the a Stateless DOM API. Eh voila
I am already banging my head:

DOM API: How get last child efficiently?
https://github.com/tau-prolog/tau-prolog/issues/340

Ha Ha ChatGPT is trolling me. You can search last_child
in Tau Prolog current GitHub, not a single find.

https://github.com/tau-prolog/tau-prolog/search?q=last_child

Or try this:

:- use_module(library(dom)).
?- last_child(foo, bar).
uncaught exception: error(existence_error(procedure,last_child/2),top_level/0)

Nevertheless ChatGPT halucinates something perfectly plausible:

Q: How get DOM last child in Tau Prolog programming language.

A: In Tau Prolog, you can use the built-in predicate
"last_child/2" to get the last child of a DOM element.

The predicate takes two arguments:

The DOM element for which you want to get
the last child (the parent element)
A variable that will be bound to the last child element

Example usage:

Copy code
last_child(parent_element, LastChild),
You have to unify the parent element with a variable
that has been initialized as a DOM element .

Please note that my knowledge cut off on Tau-Prolog is
from 2021 and this predicates could be deprecated or
changed so I recommend to check in the documentation
of the library you're using or check the version of
Tau-Prolog you're working with.

LoL

Mostowski Collapse schrieb am Mittwoch, 11. Januar 2023 um 21:45:30 UTC+1:
> I guess its time to talk about DOM APIs inside Prolog,
> and making them mature and portable. I am planning
> to adopt the Tau Prolog DOM API.
>
> But I have two DOM APIs in mind:
>
> - Stateless DOM API: Basically Tau Prolog is a stateless
> DOM API. All API calls have all the necessary parameters,
> there is nothing implicit right?
>
> - Statefull DOM API: On the other hand so far, in Dogelog
> Player, I have used a statefull DOM API. With a notion
> of cursor, you can imagine Turtle graphics, only the Turtle
>
> is not a Turtle with location and orientation, but a node
> somewhere in a DOM tree.
>
> My plan is to give the Statefull DOM API a new try, but
> bootstrapping it from the a Stateless DOM API. Eh voila
> I am already banging my head:
>
> DOM API: How get last child efficiently?
> https://github.com/tau-prolog/tau-prolog/issues/340

Looks like Ciao Prolog Playground totally
forgot about some library(dom)? Nada?

Is it more harder to make library(dom) for
a WASM based Prolog than a JavaScript based

Prolog? What about SWI-Prolog WASM?

An other can of worms format/2, related to DOM generation.
The Prolog community could standardisize it voluntarily
without the need of the ISO body. Just have a common place,

where somebody puts up a kind of specification document.
Something like a format/2 Prolog Enhancement Proposals (PEP).
Why look into format/2 ? Because Tau Prolog suggests funny stuff:

add_item(Item, Count) :-
...
format(Stream, "~a (~d)", [Item, Count]),
...

Web development with Tau Prolog - Riazaa
https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf

Mostlikely the above is not a very optimal idea, since
there are so many other issues in DOM text generation,
like XML Escape or URL Encoding. But nevertheless

worth investigating as a means for DOM text generation.

A middle ground could be to standardisized only float formatting.
So that there are some primitives that do float formatting,
and various string interpolations and portraying could be

bootstrapped from it. I find some rudimentaries here from ROK:

float_codes(Float, Codes, Format) :-
% like number_codes/2 but only for floats
http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm

So the standardisation would takle what the ‘%’ operator can
do in Python, when the left argument is a string and the right
argument is a float. But there is much to be demanded, what

if the right argument is an integer, especially a bigint and not
a smallint, a bigint that cannot be converted to float. So ROKs
take is a little outdated, since is not bigint aware.

Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:56:46 UTC+1:
> An other can of worms format/2, related to DOM generation.
> The Prolog community could standardisize it voluntarily
> without the need of the ISO body. Just have a common place,
>
> where somebody puts up a kind of specification document.
> Something like a format/2 Prolog Enhancement Proposals (PEP).
> Why look into format/2 ? Because Tau Prolog suggests funny stuff:
>
> add_item(Item, Count) :-
> ...
> format(Stream, "~a (~d)", [Item, Count]),
> ...
>
> Web development with Tau Prolog - Riazaa
> https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf
>
> Mostlikely the above is not a very optimal idea, since
> there are so many other issues in DOM text generation,
> like XML Escape or URL Encoding. But nevertheless
>
> worth investigating as a means for DOM text generation.

SWI-Prolog is currently bigint aware:

?- format("abc ~2f def", [123123123123123123123]).
abc 123123123123123123123.00 def

?- format("abc ~2f def", [123123123123123123123.0]).
abc 123123123123123126272.00 def

Trealla Prolog doesn’t tolerate integer:

?- format("abc ~2f def", [123123123123123123123]).
error(type_error(float,123123123123123123123),format/2).

Scryer Prolog does sometimes nonsense for float:

?- format("abc ~2f def", [123123123123123123123.0]).
abc 1.23 def true.

Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:58:12 UTC+1:
> A middle ground could be to standardisized only float formatting.
> So that there are some primitives that do float formatting,
> and various string interpolations and portraying could be
>
> bootstrapped from it. I find some rudimentaries here from ROK:
>
> float_codes(Float, Codes, Format) :-
> % like number_codes/2 but only for floats
> http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm
>
> So the standardisation would takle what the ‘%’ operator can
> do in Python, when the left argument is a string and the right
> argument is a float. But there is much to be demanded, what
>
> if the right argument is an integer, especially a bigint and not
> a smallint, a bigint that cannot be converted to float. So ROKs
> take is a little outdated, since is not bigint aware.
> Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:56:46 UTC+1:
> > An other can of worms format/2, related to DOM generation.
> > The Prolog community could standardisize it voluntarily
> > without the need of the ISO body. Just have a common place,
> >
> > where somebody puts up a kind of specification document.
> > Something like a format/2 Prolog Enhancement Proposals (PEP).
> > Why look into format/2 ? Because Tau Prolog suggests funny stuff:
> >
> > add_item(Item, Count) :-
> > ...
> > format(Stream, "~a (~d)", [Item, Count]),
> > ...
> >
> > Web development with Tau Prolog - Riazaa
> > https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf
> >
> > Mostlikely the above is not a very optimal idea, since
> > there are so many other issues in DOM text generation,
> > like XML Escape or URL Encoding. But nevertheless
> >
> > worth investigating as a means for DOM text generation.

My conclusion, to reach the level of SWI-Prolog,
a number_codes with a format parameters is needed, and
not a float_codes that is restricted to floats.

With a number_codes that also accepts integers, it will go
smooth to also format integers, as SWI-Prolog does.
On my side I started defining a new built-in:

atom_number(-Atom, +Atom, +Integer, +Number)

The above built-in takes a slightly different turn, not codes
but atom is the currency for number conversion. The
input atom is ‘f’ or ‘e’, and the input integer is the requested

precision. But it is currently too stupid for bigint, working on it.

Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:58:12 UTC+1:
> A middle ground could be to standardisized only float formatting.
> So that there are some primitives that do float formatting,
> and various string interpolations and portraying could be
>
> bootstrapped from it. I find some rudimentaries here from ROK:
>
> float_codes(Float, Codes, Format) :-
> % like number_codes/2 but only for floats
> http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm
>
> So the standardisation would takle what the ‘%’ operator can
> do in Python, when the left argument is a string and the right
> argument is a float. But there is much to be demanded, what
>
> if the right argument is an integer, especially a bigint and not
> a smallint, a bigint that cannot be converted to float. So ROKs
> take is a little outdated, since is not bigint aware.
> Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:56:46 UTC+1:
> > An other can of worms format/2, related to DOM generation.
> > The Prolog community could standardisize it voluntarily
> > without the need of the ISO body. Just have a common place,
> >
> > where somebody puts up a kind of specification document.
> > Something like a format/2 Prolog Enhancement Proposals (PEP).
> > Why look into format/2 ? Because Tau Prolog suggests funny stuff:
> >
> > add_item(Item, Count) :-
> > ...
> > format(Stream, "~a (~d)", [Item, Count]),
> > ...
> >
> > Web development with Tau Prolog - Riazaa
> > https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf
> >
> > Mostlikely the above is not a very optimal idea, since
> > there are so many other issues in DOM text generation,
> > like XML Escape or URL Encoding. But nevertheless
> >
> > worth investigating as a means for DOM text generation.

PEPs are probably anyway a dead end. Best would be if Prolog
systems were designed around a Novacore. So atom_number/4
would probably fit into a **Novacore**, but format/[2,3] not.

format/[2,3] would have a pure Prolog implementation, that
can be shared across Prolog systems. Same for locales, a pure
Prolog implementation, or some Semantic Net from ChatGPT.

LoL

Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 11:01:03 UTC+1:
> My conclusion, to reach the level of SWI-Prolog,
> a number_codes with a format parameters is needed, and
> not a float_codes that is restricted to floats.
>
> With a number_codes that also accepts integers, it will go
> smooth to also format integers, as SWI-Prolog does.
> On my side I started defining a new built-in:
>
> atom_number(-Atom, +Atom, +Integer, +Number)
>
> The above built-in takes a slightly different turn, not codes
> but atom is the currency for number conversion. The
> input atom is ‘f’ or ‘e’, and the input integer is the requested
>
> precision. But it is currently too stupid for bigint, working on it.
> Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:58:12 UTC+1:
> > A middle ground could be to standardisized only float formatting.
> > So that there are some primitives that do float formatting,
> > and various string interpolations and portraying could be
> >
> > bootstrapped from it. I find some rudimentaries here from ROK:
> >
> > float_codes(Float, Codes, Format) :-
> > % like number_codes/2 but only for floats
> > http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm
> >
> > So the standardisation would takle what the ‘%’ operator can
> > do in Python, when the left argument is a string and the right
> > argument is a float. But there is much to be demanded, what
> >
> > if the right argument is an integer, especially a bigint and not
> > a smallint, a bigint that cannot be converted to float. So ROKs
> > take is a little outdated, since is not bigint aware.
> > Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:56:46 UTC+1:
> > > An other can of worms format/2, related to DOM generation.
> > > The Prolog community could standardisize it voluntarily
> > > without the need of the ISO body. Just have a common place,
> > >
> > > where somebody puts up a kind of specification document.
> > > Something like a format/2 Prolog Enhancement Proposals (PEP).
> > > Why look into format/2 ? Because Tau Prolog suggests funny stuff:
> > >
> > > add_item(Item, Count) :-
> > > ...
> > > format(Stream, "~a (~d)", [Item, Count]),
> > > ...
> > >
> > > Web development with Tau Prolog - Riazaa
> > > https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf
> > >
> > > Mostlikely the above is not a very optimal idea, since
> > > there are so many other issues in DOM text generation,
> > > like XML Escape or URL Encoding. But nevertheless
> > >
> > > worth investigating as a means for DOM text generation.

Thats a defect of Markus Triskas library(format).
The defect is found in Scryer Prolog:

?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
foo p(A,B) bar q(B,C) baz

?- format("foo ~w bar", [p(A,B)]), format(" ~w baz", [q(B,C)]), nl.
foo p(A,B) bar q(A,B) baz

One should be able to chop up format/[2,3]. Other
Prolog systems are able to do that. Either with small
variable gensym or with large variable gensym:

/* Trealla, Jekejeke etc.. --> small variable gensym */
?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
foo p(_0, _1) bar q(_1, _2) baz

?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
foo p(_0, _1) bar q(_1, _2) baz

/* SWI-Prolog, Dogelog etc.. --> large variable gensym */
?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
foo p(_23041, _23042) bar q(_23042, _23043) baz

?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
foo p(_25699, _25700) bar q(_25700, _25701) baz

I don't know whether Trealla and Jekejeke use the
same gensym strategy, but phenotype is similar.
Same for the genotype of SWI-Prolog and Dogelog,

mostlikely not the same realization under the hood,
but similar outcome again.

Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 13:49:28 UTC+1:
> PEPs are probably anyway a dead end. Best would be if Prolog
> systems were designed around a Novacore. So atom_number/4
> would probably fit into a **Novacore**, but format/[2,3] not.
>
> format/[2,3] would have a pure Prolog implementation, that
> can be shared across Prolog systems. Same for locales, a pure
> Prolog implementation, or some Semantic Net from ChatGPT.
>
> LoL
> Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 11:01:03 UTC+1:
> > My conclusion, to reach the level of SWI-Prolog,
> > a number_codes with a format parameters is needed, and
> > not a float_codes that is restricted to floats.
> >
> > With a number_codes that also accepts integers, it will go
> > smooth to also format integers, as SWI-Prolog does.
> > On my side I started defining a new built-in:
> >
> > atom_number(-Atom, +Atom, +Integer, +Number)
> >
> > The above built-in takes a slightly different turn, not codes
> > but atom is the currency for number conversion. The
> > input atom is ‘f’ or ‘e’, and the input integer is the requested
> >
> > precision. But it is currently too stupid for bigint, working on it.
> > Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:58:12 UTC+1:
> > > A middle ground could be to standardisized only float formatting.
> > > So that there are some primitives that do float formatting,
> > > and various string interpolations and portraying could be
> > >
> > > bootstrapped from it. I find some rudimentaries here from ROK:
> > >
> > > float_codes(Float, Codes, Format) :-
> > > % like number_codes/2 but only for floats
> > > http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm
> > >
> > > So the standardisation would takle what the ‘%’ operator can
> > > do in Python, when the left argument is a string and the right
> > > argument is a float. But there is much to be demanded, what
> > >
> > > if the right argument is an integer, especially a bigint and not
> > > a smallint, a bigint that cannot be converted to float. So ROKs
> > > take is a little outdated, since is not bigint aware.
> > > Mostowski Collapse schrieb am Freitag, 13. Januar 2023 um 10:56:46 UTC+1:
> > > > An other can of worms format/2, related to DOM generation.
> > > > The Prolog community could standardisize it voluntarily
> > > > without the need of the ISO body. Just have a common place,
> > > >
> > > > where somebody puts up a kind of specification document.
> > > > Something like a format/2 Prolog Enhancement Proposals (PEP).
> > > > Why look into format/2 ? Because Tau Prolog suggests funny stuff:
> > > >
> > > > add_item(Item, Count) :-
> > > > ...
> > > > format(Stream, "~a (~d)", [Item, Count]),
> > > > ...
> > > >
> > > > Web development with Tau Prolog - Riazaa
> > > > https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf
> > > >
> > > > Mostlikely the above is not a very optimal idea, since
> > > > there are so many other issues in DOM text generation,
> > > > like XML Escape or URL Encoding. But nevertheless
> > > >
> > > > worth investigating as a means for DOM text generation.

It seems that Tau Prolog has a hickup somewhere:

?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
uncaught exception: error(instantiation_error,fabricate_var_name/3)

https://github.com/tau-prolog/tau-prolog/issues/342

Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 00:03:10 UTC+1:
> Thats a defect of Markus Triskas library(format).
> The defect is found in Scryer Prolog:
>
> ?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
> foo p(A,B) bar q(B,C) baz
>
> ?- format("foo ~w bar", [p(A,B)]), format(" ~w baz", [q(B,C)]), nl.
> foo p(A,B) bar q(A,B) baz
>
> One should be able to chop up format/[2,3]. Other
> Prolog systems are able to do that. Either with small
> variable gensym or with large variable gensym:
>
> /* Trealla, Jekejeke etc.. --> small variable gensym */
> ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> foo p(_0, _1) bar q(_1, _2) baz
>
> ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> foo p(_0, _1) bar q(_1, _2) baz
>
> /* SWI-Prolog, Dogelog etc.. --> large variable gensym */
> ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> foo p(_23041, _23042) bar q(_23042, _23043) baz
>
> ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> foo p(_25699, _25700) bar q(_25700, _25701) baz
>
> I don't know whether Trealla and Jekejeke use the
> same gensym strategy, but phenotype is similar.
> Same for the genotype of SWI-Prolog and Dogelog,
>
> mostlikely not the same realization under the hood,
> but similar outcome again.

Interesting find, hooking into Java printf gives:

?- catch(printf('abc %s def', []), error(E,_), true).
Error: Unknown template: representation_error('Format specifier ''%s''')
/* java.util.MissingFormatArgumentException extends IllegalFormatException */
?- catch(printf('abc %s def', [p,q]), error(E,_), true).
abc p def

So too many arguments are tolerated. On the other
hand SWI-Prolog does check too many arguments:

?- catch(format('abc ~w def', []), error(E,_), true).
E = format('not enough arguments').

?- catch(format('abc ~w def', [p,q]), error(E,_), true).
E = format('too many arguments').

Oki Doki

Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 00:07:06 UTC+1:
> It seems that Tau Prolog has a hickup somewhere:
> ?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
> uncaught exception: error(instantiation_error,fabricate_var_name/3)
>
> https://github.com/tau-prolog/tau-prolog/issues/342
> Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 00:03:10 UTC+1:
> > Thats a defect of Markus Triskas library(format).
> > The defect is found in Scryer Prolog:
> >
> > ?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
> > foo p(A,B) bar q(B,C) baz
> >
> > ?- format("foo ~w bar", [p(A,B)]), format(" ~w baz", [q(B,C)]), nl.
> > foo p(A,B) bar q(A,B) baz
> >
> > One should be able to chop up format/[2,3]. Other
> > Prolog systems are able to do that. Either with small
> > variable gensym or with large variable gensym:
> >
> > /* Trealla, Jekejeke etc.. --> small variable gensym */
> > ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> > foo p(_0, _1) bar q(_1, _2) baz
> >
> > ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> > foo p(_0, _1) bar q(_1, _2) baz
> >
> > /* SWI-Prolog, Dogelog etc.. --> large variable gensym */
> > ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> > foo p(_23041, _23042) bar q(_23042, _23043) baz
> >
> > ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> > foo p(_25699, _25700) bar q(_25700, _25701) baz
> >
> > I don't know whether Trealla and Jekejeke use the
> > same gensym strategy, but phenotype is similar.
> > Same for the genotype of SWI-Prolog and Dogelog,
> >
> > mostlikely not the same realization under the hood,
> > but similar outcome again.

Interesting find, Ciao Prologs does sometimes boxing:

/* Ciao Prolog 1.22.0 */
?- format('abc ~w def', [p]). %%% no-boxing exception [_]
abc p def

?- format('abc ~w def', p).
abc p def

I guess this makes the format/2 predicate a little brittle,
when used to print lists. One cannot distinguish [p] and
p in the output, not sure whether is a tolerable flaw?

It is tolerable in as far as there exists a work around. The
work around is to avoid boxing when there is only
one item to print:

?- format('abc ~w def', [[p]]).
abc [p] def

?- format('abc ~w def', [p]).
abc p def

So when you are Pavlov’s dog and have learned to use
and enjoy Ciao Prologs feature, because of some positive
feedback where it works, you have to unlearn this feature

nevertheless, which needs the administration of electric
shocks to the programmer.

Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 09:49:25 UTC+1:
> Interesting find, hooking into Java printf gives:
>
> ?- catch(printf('abc %s def', []), error(E,_), true).
> Error: Unknown template: representation_error('Format specifier ''%s''')
> /* java.util.MissingFormatArgumentException extends IllegalFormatException */
> ?- catch(printf('abc %s def', [p,q]), error(E,_), true).
> abc p def
>
> So too many arguments are tolerated. On the other
> hand SWI-Prolog does check too many arguments:
>
> ?- catch(format('abc ~w def', []), error(E,_), true).
> E = format('not enough arguments').
>
> ?- catch(format('abc ~w def', [p,q]), error(E,_), true).
> E = format('too many arguments').
>
> Oki Doki
> Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 00:07:06 UTC+1:
> > It seems that Tau Prolog has a hickup somewhere:
> > ?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
> > uncaught exception: error(instantiation_error,fabricate_var_name/3)
> >
> > https://github.com/tau-prolog/tau-prolog/issues/342
> > Mostowski Collapse schrieb am Dienstag, 17. Januar 2023 um 00:03:10 UTC+1:
> > > Thats a defect of Markus Triskas library(format).
> > > The defect is found in Scryer Prolog:
> > >
> > > ?- format("foo ~w bar ~w baz", [p(A,B),q(B,C)]), nl.
> > > foo p(A,B) bar q(B,C) baz
> > >
> > > ?- format("foo ~w bar", [p(A,B)]), format(" ~w baz", [q(B,C)]), nl.
> > > foo p(A,B) bar q(A,B) baz
> > >
> > > One should be able to chop up format/[2,3]. Other
> > > Prolog systems are able to do that. Either with small
> > > variable gensym or with large variable gensym:
> > >
> > > /* Trealla, Jekejeke etc.. --> small variable gensym */
> > > ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> > > foo p(_0, _1) bar q(_1, _2) baz
> > >
> > > ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> > > foo p(_0, _1) bar q(_1, _2) baz
> > >
> > > /* SWI-Prolog, Dogelog etc.. --> large variable gensym */
> > > ?- format('foo ~w bar ~w baz', [p(A,B),q(B,C)]), nl.
> > > foo p(_23041, _23042) bar q(_23042, _23043) baz
> > >
> > > ?- format('foo ~w bar', [p(A,B)]), format(' ~w baz', [q(B,C)]), nl.
> > > foo p(_25699, _25700) bar q(_25700, _25701) baz
> > >
> > > I don't know whether Trealla and Jekejeke use the
> > > same gensym strategy, but phenotype is similar.
> > > Same for the genotype of SWI-Prolog and Dogelog,
> > >
> > > mostlikely not the same realization under the hood,
> > > but similar outcome again.

We are now exploring file systems with novacore.
And here and then we have a couple of primitives
and then do some bootstrapping. It currently lands

in library(random) until we find a better place:

% directory_member(+Atom, -Atom)
directory_member(F, N) :-
directory_files(F, L),
member(N, L).

% ensure_directory(+Atom)
ensure_directory(F) :-
file_exists(F),
file_property(F, type(directory)),
!.
ensure_directory(F) :-
make_directory(F).

Guess what, finding semantic and support of
directory_files/2, file_exists/1 and file_property/2
is already non trivial.

We are now exploring file systems with novacore.
And here and then we have a couple of primitives
and then do some bootstrapping. It currently lands

in library(random) until we find a better place:

% directory_member(+Atom, -Atom)
directory_member(F, N) :-
directory_files(F, L),
member(N, L).

% ensure_directory(+Atom)
ensure_directory(F) :-
file_exists(F),
file_property(F, type(directory)),
!.
ensure_directory(F) :-
make_directory(F).

Guess what, finding semantic and support of
directory_files/2, file_exists/1 and file_property/2
is already non trivial.

LogNonsenseTalk with its brainwash is totally
useless. This here is already wrong:

file_exists(File) :-
absolute_file_name(File, ExpandedPath),
{exists_file(ExpandedPath)}.

https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/os/os.lgt

Becaue for example exists_file/1 in SWI-Prolog
means exists regular file. But file_exists/1

should mean exists file of any type. Just
lookup what GNU Prolog provides. In OS lingua

file means often regular, directory, etc..

Mild Shock schrieb:
> We are now exploring file systems with novacore.
> And here and then we have a couple of primitives
> and then do some bootstrapping. It currently lands
>
> in library(random) until we find a better place:
>
> % directory_member(+Atom, -Atom)
> directory_member(F, N) :-
>    directory_files(F, L),
>    member(N, L).
>
> % ensure_directory(+Atom)
> ensure_directory(F) :-
>    file_exists(F),
>    file_property(F, type(directory)),
>    !.
> ensure_directory(F) :-
>    make_directory(F).
>
> Guess what, finding semantic and support of
> directory_files/2, file_exists/1 and file_property/2
> is already non trivial.
>

You see the OS jargon meaning in directory_member/2
which is bootstrapped from directory_files/2.

directory_files/2 should of course list any files
inside the directory, regular, directory, etc..

not only regular files. So "files" means any
file of type regular, directory, etc..

Mild Shock schrieb:
>
> LogNonsenseTalk with its brainwash is totally
> useless. This here is already wrong:
>
> file_exists(File) :-
>     absolute_file_name(File, ExpandedPath),
>     {exists_file(ExpandedPath)}.
>
> https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/os/os.lgt
>
> Becaue for example exists_file/1 in SWI-Prolog
> means exists regular file. But file_exists/1
>
> should mean exists file of any type. Just
> lookup what GNU Prolog provides. In OS lingua
>
> file means often regular, directory, etc..
>
> Mild Shock schrieb:
>> We are now exploring file systems with novacore.
>> And here and then we have a couple of primitives
>> and then do some bootstrapping. It currently lands
>>
>> in library(random) until we find a better place:
>>
>> % directory_member(+Atom, -Atom)
>> directory_member(F, N) :-
>>     directory_files(F, L),
>>     member(N, L).
>>
>> % ensure_directory(+Atom)
>> ensure_directory(F) :-
>>     file_exists(F),
>>     file_property(F, type(directory)),
>>     !.
>> ensure_directory(F) :-
>>     make_directory(F).
>>
>> Guess what, finding semantic and support of
>> directory_files/2, file_exists/1 and file_property/2
>> is already non trivial.
>>
>