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.

Inside Novacore we could reinvent Prolog Dicts. JavaScript
has a primitive data type for Symbols, so you can call
Symbol.for(“key”), which will internalize the string, so that

you can use pointer equality on the result:

> Symbol is a built-in object whose constructor returns a symbol primitive
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

It wouldn’t match JSON usage, since the keys are not supposed
to be Symbols, only Strings. But maybe this is only superficially,
and internally they are Symbols. One could do the same for

Novacore Prolog Dicts. On the surface Novacore Prolog
Dicts would use Strings:

?- X = {"abc" : 123.45, "def": 67}.
But under the hood there would be a transition from String to Atom:

?- X = {"abc" : 123.45, "def": 67}, X =.. L.
L = [C'novacore_dict, abc, 123.45, def, 67]

The rational would be: The keys usually form a limited vocabulary.

Interestingly with the above trick, a Prolog parser can
recognize Novacore Prolog Dicts. Since it would see this
production at the head of a Novacore Prolog Dict:

novacore_dict :== "{" string ":" term ... "}"

Which is unlike the ISO core definition of “{}”, since in
ISO core there are no strings, and even a qualified call in
ISO module assumes that we have atom “:” term. So

there would be no collision with this production:

set :== "{" term "}"

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1:
> Inside Novacore we could reinvent Prolog Dicts. JavaScript
> has a primitive data type for Symbols, so you can call
> Symbol.for(“key”), which will internalize the string, so that
>
> you can use pointer equality on the result:
>
> > Symbol is a built-in object whose constructor returns a symbol primitive
> > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
>
> It wouldn’t match JSON usage, since the keys are not supposed
> to be Symbols, only Strings. But maybe this is only superficially,
> and internally they are Symbols. One could do the same for
>
> Novacore Prolog Dicts. On the surface Novacore Prolog
> Dicts would use Strings:
>
> ?- X = {"abc" : 123.45, "def": 67}.
> But under the hood there would be a transition from String to Atom:
>
> ?- X = {"abc" : 123.45, "def": 67}, X =.. L.
> L = [C'novacore_dict, abc, 123.45, def, 67]
>
> The rational would be: The keys usually form a limited vocabulary.

Currently I get an error when I use string keys:

/* SWI-Prolog 9.1.4 */
?- current_prolog_flag(double_quotes, X).
X = string.

?- X = _{"abc": 123.46, "def": 67}.
ERROR: Syntax error: key_expected
Also there is the annoying need for an underscore functor.

With string keys I could directly embed JSON?
In this case null, false and true could be easily an atom.
Thats kind of solving the constant problem from another angle.

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:56:23 UTC+1:
> Interestingly with the above trick, a Prolog parser can
> recognize Novacore Prolog Dicts. Since it would see this
> production at the head of a Novacore Prolog Dict:
>
> novacore_dict :== "{" string ":" term ... "}"
>
> Which is unlike the ISO core definition of “{}”, since in
> ISO core there are no strings, and even a qualified call in
> ISO module assumes that we have atom “:” term. So
>
> there would be no collision with this production:
>
> set :== "{" term "}"
> Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1:
> > Inside Novacore we could reinvent Prolog Dicts. JavaScript
> > has a primitive data type for Symbols, so you can call
> > Symbol.for(“key”), which will internalize the string, so that
> >
> > you can use pointer equality on the result:
> >
> > > Symbol is a built-in object whose constructor returns a symbol primitive
> > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
> >
> > It wouldn’t match JSON usage, since the keys are not supposed
> > to be Symbols, only Strings. But maybe this is only superficially,
> > and internally they are Symbols. One could do the same for
> >
> > Novacore Prolog Dicts. On the surface Novacore Prolog
> > Dicts would use Strings:
> >
> > ?- X = {"abc" : 123.45, "def": 67}.
> > But under the hood there would be a transition from String to Atom:
> >
> > ?- X = {"abc" : 123.45, "def": 67}, X =.. L.
> > L = [C'novacore_dict, abc, 123.45, def, 67]
> >
> > The rational would be: The keys usually form a limited vocabulary.

But this other angle would only work inside JSON.
There is still a problem with ordinary Prolog code, and
for example the disabled setter. If we want to avoid some

bottle neck of translating structures back and forth.

Mostowski Collapse schrieb am Samstag, 18. März 2023 um 14:01:35 UTC+1:
> Currently I get an error when I use string keys:
>
> /* SWI-Prolog 9.1.4 */
> ?- current_prolog_flag(double_quotes, X).
> X = string.
>
> ?- X = _{"abc": 123.46, "def": 67}.
> ERROR: Syntax error: key_expected
> Also there is the annoying need for an underscore functor.
>
> With string keys I could directly embed JSON?
> In this case null, false and true could be easily an atom.
> Thats kind of solving the constant problem from another angle.
> Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:56:23 UTC+1:
> > Interestingly with the above trick, a Prolog parser can
> > recognize Novacore Prolog Dicts. Since it would see this
> > production at the head of a Novacore Prolog Dict:
> >
> > novacore_dict :== "{" string ":" term ... "}"
> >
> > Which is unlike the ISO core definition of “{}”, since in
> > ISO core there are no strings, and even a qualified call in
> > ISO module assumes that we have atom “:” term. So
> >
> > there would be no collision with this production:
> >
> > set :== "{" term "}"
> > Mostowski Collapse schrieb am Samstag, 18. März 2023 um 13:55:21 UTC+1:
> > > Inside Novacore we could reinvent Prolog Dicts. JavaScript
> > > has a primitive data type for Symbols, so you can call
> > > Symbol.for(“key”), which will internalize the string, so that
> > >
> > > you can use pointer equality on the result:
> > >
> > > > Symbol is a built-in object whose constructor returns a symbol primitive
> > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
> > >
> > > It wouldn’t match JSON usage, since the keys are not supposed
> > > to be Symbols, only Strings. But maybe this is only superficially,
> > > and internally they are Symbols. One could do the same for
> > >
> > > Novacore Prolog Dicts. On the surface Novacore Prolog
> > > Dicts would use Strings:
> > >
> > > ?- X = {"abc" : 123.45, "def": 67}.
> > > But under the hood there would be a transition from String to Atom:
> > >
> > > ?- X = {"abc" : 123.45, "def": 67}, X =.. L.
> > > L = [C'novacore_dict, abc, 123.45, def, 67]
> > >
> > > The rational would be: The keys usually form a limited vocabulary.

Now I have already removed the following predicates from
Novacore, they landed in library(compat):

- numbervars/2
- subsumes/2
- subsumes_term/2

Now wonder where variant/2 would land? SWI-Prolog wants to tell me
that variant/2 might need library(compat), because of numbervars/2.
Assuming A and B have already distinct variables I get the following solution:

A =@= B :-
\+ \+ (numbervars(Ac, 0, N),
numbervars(Bc, 0, N),
Ac == Bc).
https://www.swi-prolog.org/pldoc/doc_for?object=%28%3D@%3D%29/2

On the other hand this solution gives me also a library(compat)
dependency, since its based on subsumes_term/2. Again assuming A and
B have already distinct variables I get the following solution:

A =@= B :-
subsumes_term(A, B),
subsumes_term(B, A).
https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates

Isn't there something simpler?

This is cute, has quite some different dependencies,
inspired by the use of term_variables/3 in bagof/3,
again assuming that A and B have already disjoint variables:

A =@= B :-
term_variables(A, L),
term_variables(B, R),
\+ \+ (L=R, A==B).

Can be bootstrapped from a much smaler Novacore.

Mostowski Collapse schrieb am Samstag, 13. Mai 2023 um 15:36:04 UTC+2:
> Now I have already removed the following predicates from
> Novacore, they landed in library(compat):
>
> - numbervars/2
> - subsumes/2
> - subsumes_term/2
>
> Now wonder where variant/2 would land? SWI-Prolog wants to tell me
> that variant/2 might need library(compat), because of numbervars/2.
> Assuming A and B have already distinct variables I get the following solution:
>
> A =@= B :-
> \+ \+ (numbervars(A, 0, N),
> numbervars(B, 0, N),
> A == B).
> https://www.swi-prolog.org/pldoc/doc_for?object=%28%3D@%3D%29/2
>
> On the other hand this solution gives me also a library(compat)
> dependency, since its based on subsumes_term/2. Again assuming A and
> B have already distinct variables I get the following solution:
>
> A =@= B :-
> subsumes_term(A, B),
> subsumes_term(B, A).
> https://www.complang.tuwien.ac.at/ulrich/iso-prolog/built-in_predicates
>
> Isn't there something simpler?

Now I have implemented the new open/4 options method/1,
headers/1 and body/1 also for Dogelog Player. There is a first
take that works in the browser. More platforms to follow.

Its such a thin extension, API wise, want to have it as part of
Novacore. What do other Prolog systems do? Here is what
SWI-Prolog in their offering.

- method/1: Accepts the method name in lower case,
so far I use the option with an upper case value.
- headers/1: Doesn't use our Key-Value pair format,
instead the format is Key(Value). Has separate option
for auth/1 and inside auth/1 for bearer/1.
- body/1: Not available in SWI-Prolog, must use post/1,
and post/1 accepts quite a bulk of formats.

and then I find that Trealla Prolog does something else
Signature wise:

- offers some convenience like http_post/4, http_delete/3,
bootstrapped from http_get/3.
- http_get/3 has options method/1, post/1 and header/2,
quite amazing, mostly written in 100% Prolog!
- might also support HTTPS, depends on client/5.
- this was checked into GitHub 9 months ago

and Scryer Prolog does again something else
Signature wise:

- http_open/3 had a 100% Prolog solution in 2020,
but became something else 12 months ago.
- http_open/3 has options method/1, data/1 and
request_headers/1, goes into CallHttpOpen instruction,
which then uses hyper_tls.

The new multilingual strings are also an exercise in
Novacore. There were a few issues that needed novel
Prolog solutions, to make a Novacore solution.

One problem was I didn't want to use library(format)
and format/3 to format multilingual strings when
generating error messages. This addresses more

the later multilingual strings processing than the
multilingual strings store itself. So how resolve this
paradox? Here is my take, a mini format/3 boostraped

from the Dogelog Player specific atom_split/3:

% sys_inter_polate(+Stream, +Atom, +List)
sys_inter_polate(Stream, Template, Args) :-
atom_split(Template, '~', [Head|Tail]),
put_atom(Stream, Head),
sys_zipper_output(Args, Tail, Stream).

% sys_zipper_output(+List, +List, +Stream)
sys_zipper_output([Arg|Args], [Head|Tail], Stream) :-
writeq(Stream, Arg),
put_atom(Stream, Head),
sys_zipper_output(Args, Tail, Stream).
sys_zipper_output([], [], _).

It only understands format specifier '~', but is sufficient:

/* German Text */
strings('syntax_error.singleton_var', de, 'Alleinstehende Variable(n) ~, anonyme Variable(n) (_) benutzen.').

/* English and Fallback Text */
strings('syntax_error.singleton_var', '', 'Singleton variable(s) ~, use anonymous variable(s) (_).').

LoL

Did you know that Novacore has change_arg/3?
Works for Dogelog Player and formerly Jekejeke Prolog.
It is similar like nb_linkarg/3 in SWI-Prolog.

So we can implement countall/3 in a blink:

countall(G, N) :-
functor(Holder, v, 1),
change_arg(1, Holder, 0),
(G,
arg(1, Holder, H),
J is H+1,
change_arg(1, Holder, J),
fail; true),
arg(1, Holder, N).

Works find:

?- countall(between(10,20,_), N).
N = 11.

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.
>>
>