If you would like to be TPTP compatible (versus v8.1.0.0),
you would need to ban this:

$ target/release/scryer-prolog -v
"v0.9.0-181-g8e9302ea"
$ target/release/scryer-prolog
?- X = hörgerät.
X = hörgerät.

So Scryer Prolog is now somewhere between TPTP
and a Prolog Unicode, neither fish nor fowl,
I cannot parse this, doesn't work in Scryer Prolog:

$ cat text.pl
text("«The Logos of Cybele is the idea that the Great Mother creates\n\
and kills everything. It is not eternity (Apollo) or the circle\n\
(Dionysus), but something that acts in her way with blind\n\
and absolute power. A form of progress: bottom-up growth.\n\
We are experiencing the final attack of Cybele, of the Great Risen\n\
Mother, with feminism, artificial intelligence, globalization,\n\
democracy, liberalism, and so on»").

I get this error:

$ target/release/scryer-prolog
?- ['text.pl'].
error(syntax_error(missing_quote),read_term/3:0).
false.

Works fine in SWI-Prolog:

?- text(X), write(X), nl, fail; true.
«The Logos of Cybele is the idea that the Great Mother creates
and kills everything. It is not eternity (Apollo) or the circle
(Dionysus), but something that acts in her way with blind
and absolute power. A form of progress: bottom-up growth.
We are experiencing the final attack of Cybele, of the Great Risen
Mother, with feminism, artificial intelligence, globalization,
democracy, liberalism, and so on»
true.

Mostowski Collapse schrieb am Mittwoch, 24. August 2022 um 15:08:40 UTC+2:
> Mostowski Collapse schrieb am Donnerstag, 11. August 2022 um 17:27:36 UTC+2:
> > Thats just your humanly ape brain acceptance curve:
> > - Resistance
> > - Denial
> > - Exploration
> > - Commitment
> If you are a slow thinker, you pass these quadrants slowly,
> maybe you never reach the end. Here is an example of a
> slow thinker, Ulrich Neumerkel, concerning Unicode:
>
> bla bla bla TPTP and bla bla bla WG21/N3146
> https://www.tptp.org/TPTP/SyntaxBNF.html#lower_alpha
> https://github.com/mthom/scryer-prolog/issues/1515#issuecomment-1225242783
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3146.html
>
> LoL

Holy Cow, Logtalk is the converse of Ciao Prolog.
Its kind of the inverted image of the library(lists)
of Ciao Prolog. What Logtalk has:

subtract([], _, []).
subtract([Head| Tail], List, Rest) :-
( memberchk(Head, List) ->
subtract(Tail, List, Rest)
; Rest = [Head| Tail2],
subtract(Tail, List, Tail2)
).

is not in Ciao Prolog. And vice versa, like
union/3, interaction/3, etc.. is missing from lists.
So if Ciao Prolog would load Logtalk it

would have everything?

Slow thinking can lead to constant pain. Like here:

And, indeed, in the case of an atom the escaping is not necessary:
?- write('foo"bar').
foo"bar true.
https://github.com/mthom/scryer-prolog/issues/1552#issuecomment-1207677642

What does "not necessary" mean. Thats nonsense.

Wouldn't it be a better and less confusing explanation that write/1
must behave as putatom/1, and everything else would be a bug,
since it has quoted(false)?

At least this is what the ISO core standard tells me:

- ISO/IEC 13211-1:1995(E), Page 100

So basically write/1 will behave, concerning atoms
as if (in DEC-10 Dialect):

[...]
write(X) :- atom(X), name(X,L), putlist(L).
[...]

putlist([X|Y]) :- put(X), putlist(Y).
putlist([]).

Mostowski Collapse schrieb am Mittwoch, 24. August 2022 um 15:10:50 UTC+2:
> If you would like to be TPTP compatible (versus v8.1.0.0),
> you would need to ban this:
>
> $ target/release/scryer-prolog -v
> "v0.9.0-181-g8e9302ea"
> $ target/release/scryer-prolog
> ?- X = hörgerät.
> X = hörgerät.
>
> So Scryer Prolog is now somewhere between TPTP
> and a Prolog Unicode, neither fish nor fowl,
> I cannot parse this, doesn't work in Scryer Prolog:
>
> $ cat text.pl
> text("«The Logos of Cybele is the idea that the Great Mother creates\n\
> and kills everything. It is not eternity (Apollo) or the circle\n\
> (Dionysus), but something that acts in her way with blind\n\
> and absolute power. A form of progress: bottom-up growth.\n\
> We are experiencing the final attack of Cybele, of the Great Risen\n\
> Mother, with feminism, artificial intelligence, globalization,\n\
> democracy, liberalism, and so on»").
>
> I get this error:
>
> $ target/release/scryer-prolog
> ?- ['text.pl'].
> error(syntax_error(missing_quote),read_term/3:0).
> false.
>
> Works fine in SWI-Prolog:
>
> ?- text(X), write(X), nl, fail; true.
> «The Logos of Cybele is the idea that the Great Mother creates
> and kills everything. It is not eternity (Apollo) or the circle
> (Dionysus), but something that acts in her way with blind
> and absolute power. A form of progress: bottom-up growth.
> We are experiencing the final attack of Cybele, of the Great Risen
> Mother, with feminism, artificial intelligence, globalization,
> democracy, liberalism, and so on»
> true.
> Mostowski Collapse schrieb am Mittwoch, 24. August 2022 um 15:08:40 UTC+2:
> > Mostowski Collapse schrieb am Donnerstag, 11. August 2022 um 17:27:36 UTC+2:
> > > Thats just your humanly ape brain acceptance curve:
> > > - Resistance
> > > - Denial
> > > - Exploration
> > > - Commitment
> > If you are a slow thinker, you pass these quadrants slowly,
> > maybe you never reach the end. Here is an example of a
> > slow thinker, Ulrich Neumerkel, concerning Unicode:
> >
> > bla bla bla TPTP and bla bla bla WG21/N3146
> > https://www.tptp.org/TPTP/SyntaxBNF.html#lower_alpha
> > https://github.com/mthom/scryer-prolog/issues/1515#issuecomment-1225242783
> > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3146.html
> >
> > LoL

Also, I don't find a putatom/1 in DEC-10 Manual from year 1982 here:

Department of Artificial Intelligence. University of Edinburgh
DECsystem-10 PROLOG USER'S MANUAL - 10 November 1982
https://userweb.fct.unl.pt/~lmp/publications/online-papers/DECsystem-10%20PROLOG%20USER%27S%20MANUAL.pdf

Where do you have an evidence, for the year 1978?

Mostowski Collapse schrieb am Mittwoch, 24. August 2022 um 20:01:15 UTC+2:
> Slow thinking can lead to constant pain. Like here:
>
> And, indeed, in the case of an atom the escaping is not necessary:
> ?- write('foo"bar').
> foo"bar true.
> https://github.com/mthom/scryer-prolog/issues/1552#issuecomment-1207677642
>
> What does "not necessary" mean. Thats nonsense.
>
> Wouldn't it be a better and less confusing explanation that write/1
> must behave as putatom/1, and everything else would be a bug,
> since it has quoted(false)?
>
> At least this is what the ISO core standard tells me:
>
> - ISO/IEC 13211-1:1995(E), Page 100
>
> So basically write/1 will behave, concerning atoms
> as if (in DEC-10 Dialect):
>
> [...]
> write(X) :- atom(X), name(X,L), putlist(L).
> [...]
>
> putlist([X|Y]) :- put(X), putlist(Y).
> putlist([]).

Slow thinking can lead to constant pain! LoL

Logtalk is writing nonsense:
Union, intersection, ... are set operations. Subtract is not.
https://github.com/LogtalkDotOrg/logtalk3/issues/150#issuecomment-1226084264

Then correcting it to:
Union, intersection, ... are set operations. Subtract is not a set only operation.

Ha Ha, when you have no clue how Prolog works. Union and
Intersection are also "not a set only operation", what ever that
means. They are in the same category like Subtract.

Come on guys, its not so difficult! sets.lgt has also subtract:

subtract(Set, [], Set) :- !.
subtract([], _, []) :- !.
subtract([Head1| Tail1], [Head2| Tail2], Difference) :-
compare(Order, Head1, Head2),
subtract(Order, Head1, Tail1, Head2, Tail2, Difference).

subtract(=, _, Tail1, _, Tail2, Difference) :-
subtract(Tail1, Tail2, Difference).
subtract(<, Head1, Tail1, Head2, Tail2, [Head1| Difference]) :-
subtract(Tail1, [Head2| Tail2], Difference).
subtract(>, Head1, Tail1, _, Tail2, Difference) :-
subtract([Head1| Tail1], Tail2, Difference).

In SWI-Prolog its clearer since there is no name overloading:

https://www.swi-prolog.org/pldoc/doc_for?object=ord_subtract/3

P.S.: Mathematically we would write P \ Q for the set difference.

https://mathworld.wolfram.com/SetDifference.html

Mostowski Collapse schrieb am Mittwoch, 24. August 2022 um 15:38:15 UTC+2:
> Holy Cow, Logtalk is the converse of Ciao Prolog.
> Its kind of the inverted image of the library(lists)
> of Ciao Prolog. What Logtalk has:
>
> subtract([], _, []).
> subtract([Head| Tail], List, Rest) :-
> ( memberchk(Head, List) ->
> subtract(Tail, List, Rest)
> ; Rest = [Head| Tail2],
> subtract(Tail, List, Tail2)
> ).
>
> is not in Ciao Prolog. And vice versa, like
> union/3, interaction/3, etc.. is missing from lists.
> So if Ciao Prolog would load Logtalk it
>
> would have everything?

These are some ultra cute graphics!

Cooperative Multitasking Visualized - Tau Prolog, 2022
http://tau-prolog.org/files/prole2022/#/4/4

Noice!

Why not load small JavaScript snippets synchronously
in the browser? This one works for me. At least
some local testing works already, its not yet deployed:

let parent = "";
let cache = {};

/**
* Load a JavaScript text synchronously.
*
* @param url The url.
*/
function cludge(url) {
/* resolve and check */
if (parent !== "")
url = new URL(url, parent).href;
let map = cache[url];
if (map !== undefined)
return map;
map = {};
cache[url] = map;

/* load and execute */
let back = parent;
try {
parent = url;
let request = new XMLHttpRequest();
request.open('GET', url, false);
request.send();
let fun = new Function("exports", "require", request.responseText);
fun(map, cludge);
} finally {
parent = back;
}
return map;
}

Have Fun!

On second though, I will not use this piece
of code, rather should work more consequently
in keeping the overal code async and the examples

async as well, so that it wont happen, that the browser
blocks. From GUI viewpoint its not so trivial
to make it async compatible. There are few tricks

needed. If there is only one action button this
works to avoid that multiple Prolog interpreter
calls are spawned:

async function main_async() {
document.getElementById("launch").disabled = true;
try {
async bla bla
} finally {
document.getElementById("launch").disabled = false;
}
}

document.getElementById("launch")
.addEventListener("click", main_async);

But if there are multiple action buttons,
more work is needed.

Mostowski Collapse schrieb:
> Why not load small JavaScript snippets synchronously
> in the browser? This one works for me. At least
> some local testing works already, its not yet deployed:
>
> let parent = "";
> let cache = {};
>
> /**
> * Load a JavaScript text synchronously.
> *
> * @param url The url.
> */
> function cludge(url) {
> /* resolve and check */
> if (parent !== "")
> url = new URL(url, parent).href;
> let map = cache[url];
> if (map !== undefined)
> return map;
> map = {};
> cache[url] = map;
>
> /* load and execute */
> let back = parent;
> try {
> parent = url;
> let request = new XMLHttpRequest();
> request.open('GET', url, false);
> request.send();
> let fun = new Function("exports", "require", request.responseText);
> fun(map, cludge);
> } finally {
> parent = back;
> }
> return map;
> }
>
> Have Fun!
>

How would the world look like, if Paul Tarau would
not have written a paper about Prolog engines years
ago, but about Prolog promisses? Is there even such

a paper already? SWI-Prolog with its await/2 is quite
advanced, they have promise objects passing created
by (:=)/2 and then can be passed to await/2. In Dogelog

player promisses are still opaque, not visible in Prolog
sphere as it is actually the case in SWI-Prolog WASM.
But the idea of enginess still sticks to the mind!

Recent version of Dogelog uses import(), this is a JavaScript
function which returns a promise. Behind this promise
is loading and evaluating JavaScript code, and I could

show how to transpile WordNet to JavaScript, and then load
it via import(). Its quite fast! But can we make it parallel
without going into engines? Maybe use this syntax

for parallel import. A list wrapped into a singleton list. Or use
some flag to control it, since a default parallel behaviour
could be too dangerous?

/* Parallel Variant Syntax of Multi-Consult ? */
?- [['foo.p', 'bar.p', 'baz.p']].

Of course engines or what Tau Prolog did with tasks and
promises, could also lead to a parallel load. Maybe can get
away with a cheaper solution, not bring tasks to Dogelog

player, only juggle with import() ?

Mostowski Collapse schrieb am Donnerstag, 6. Oktober 2022 um 21:43:06 UTC+2:
> How would the world look like, if Paul Tarau would
> not have written a paper about Prolog engines years
> ago, but about Prolog promisses? Is there even such
>
> a paper already? SWI-Prolog with its await/2 is quite
> advanced, they have promise objects passing created
> by (:=)/2 and then can be passed to await/2. In Dogelog
>
> player promisses are still opaque, not visible in Prolog
> sphere as it is actually the case in SWI-Prolog WASM.
> But the idea of enginess still sticks to the mind!

So what was rummaging in my brain. Why did I get repelled
by the idea of engines. I don’t know, or maybe I know?
Does SWI-Prolog have only this here, namely:

await(+Promise, -Result)
execution of await/2 completes when the Promise resolves
and Result is unified with the value passed to the
Promise.then() method.
https://www.swi-prolog.org/pldoc/doc_for?object=await/2

How about a new await_all/2, that takes a promise list?
What could be done with await_all/2? BTW: JavaScript
has more in stock than only await_all/2 which would correspond

to Promise.all(), there are like 1-2 other multi-waiters.

Mostowski Collapse schrieb am Donnerstag, 6. Oktober 2022 um 21:46:51 UTC+2:
> Recent version of Dogelog uses import(), this is a JavaScript
> function which returns a promise. Behind this promise
> is loading and evaluating JavaScript code, and I could
>
> show how to transpile WordNet to JavaScript, and then load
> it via import(). Its quite fast! But can we make it parallel
> without going into engines? Maybe use this syntax
>
> for parallel import. A list wrapped into a singleton list. Or use
> some flag to control it, since a default parallel behaviour
> could be too dangerous?
>
> /* Parallel Variant Syntax of Multi-Consult ? */
> ?- [['foo.p', 'bar.p', 'baz.p']].
>
> Of course engines or what Tau Prolog did with tasks and
> promises, could also lead to a parallel load. Maybe can get
> away with a cheaper solution, not bring tasks to Dogelog
>
> player, only juggle with import() ?
> Mostowski Collapse schrieb am Donnerstag, 6. Oktober 2022 um 21:43:06 UTC+2:
> > How would the world look like, if Paul Tarau would
> > not have written a paper about Prolog engines years
> > ago, but about Prolog promisses? Is there even such
> >
> > a paper already? SWI-Prolog with its await/2 is quite
> > advanced, they have promise objects passing created
> > by (:=)/2 and then can be passed to await/2. In Dogelog
> >
> > player promisses are still opaque, not visible in Prolog
> > sphere as it is actually the case in SWI-Prolog WASM.
> > But the idea of enginess still sticks to the mind!

Now asyncifying I/O of Dogelog Player for Python.
I guess we got our head around the equivalents
of our Java Surrogate async/await constructs

"Promise" and "Coroutine". The key utilities among
asyncio are asyncio.to_thread an asyncio.run_coroutine_threadsafe,
which seem toe especially made for the two use cases.

Namely what was our Java Surrogate "Promise" wrapper,
now looks like here, what a wonderful code gem:

async def console_promise(buf, stream):
try:
res = await asyncio.to_thread(blocking_readline, stream.data)
stream.buf = res
stream.pos = 0
except IOError as err:
register_signal(buf, map_stream_error(err))

def blocking_readline(data):
return data.readline()

And what was our Java Surrogate "Coroutine" wrapper,
now looks like here, what a wonderful code gem again:

def test_sys_http_server_on(args):
[...]
obj.func = lambda req, res: baby_come_back(
launch_async(clause, buf, [req, res]), loop)

def baby_come_back(coro, loop):
future = asyncio.run_coroutine_threadsafe(coro, loop)
return future.result()

LoL

But its much more complicated than what we did
for JDK 21. Also starting the HTTP server in a separate
thread is extremly frightening:

def test_http_server_listen(args):
[...]
thread = threading.Thread(target=blocking_forever, args=(obj,))
thread.start()

def blocking_forever(obj):
obj.serve_forever()

Its extremly frightening since the Thread docu warns us:

Thread-based parallelism
In CPython, due to the Global Interpreter Lock,
only one thread can execute Python code at once
https://docs.python.org/3/library/threading.html

global interpreter lock
Also, the GIL is always released when doing I/O.
Past efforts to create a “free-threaded” interpreter
have not been successful
https://docs.python.org/3/glossary.html#term-global-interpreter-lock

But still, our use of asyncio.to_thread and
asyncio.run_coroutine_threadsafe capitalizes on
that the GIL is nevertheless released during I/O,

and we don't see much issue here.

Mild Shock schrieb:
> Now asyncifying I/O of Dogelog Player for Python.
> I guess we got our head around the equivalents
> of our Java Surrogate async/await constructs
>
> "Promise" and "Coroutine". The key utilities among
> asyncio are asyncio.to_thread an asyncio.run_coroutine_threadsafe,
> which seem toe especially made for the two use cases.
>
> Namely what was our Java Surrogate "Promise" wrapper,
> now looks like here, what a wonderful code gem:
>
>
> async def console_promise(buf, stream):
>     try:
>         res = await asyncio.to_thread(blocking_readline, stream.data)
>         stream.buf = res
>         stream.pos = 0
>     except IOError as err:
>         register_signal(buf, map_stream_error(err))
>
>
> def blocking_readline(data):
>     return data.readline()
>
>
> And what was our Java Surrogate "Coroutine" wrapper,
> now looks like here, what a wonderful code gem again:
>
> def test_sys_http_server_on(args):
>    [...]
>     obj.func = lambda req, res: baby_come_back(
>             launch_async(clause, buf, [req, res]), loop)
>
>
> def baby_come_back(coro, loop):
>     future = asyncio.run_coroutine_threadsafe(coro, loop)
>     return future.result()
>
> LoL

Ha Ha, now Scyer Prolog wants also
byte friendly compact strings:

2. introduce a compact internal representation for lists of bytes,
which appear to Prolog programs as lists of characters.
https://github.com/mthom/scryer-prolog/blob/master/src/lib/crypto.pl#L867C2-L868C63

But they motivated it by security concerns,
whereas my concern was to get rid of ISO-ism
making a distinction between text and byte streams,

on the Prolog API levels. It would be all codes.

Mostowski Collapse schrieb:
> - UTF-16 native strings: Does work well with the envisioned
> "latin1" payload, the range 0..255 is encoded in one 16-bit word,
> which is two bytes, but most programming language already
> implement clever strings:
>
> JEP 254: Compact Strings
> We propose to change the internal representation of the String class
> from a UTF-16 char array to a byte array plus an encoding-flag field.
> The new String class will store characters encoded either as ISO-8859-1/
> Latin-1 (one byte per character), or as UTF-16 (two bytes per character),
> based upon the contents of the string. The encoding flag will indicate
> which encoding is used.
> https://openjdk.org/jeps/254

Now I have rewritten the Tic-Tac-Toe example
to be 100% Prolog. Originally the Tic-Tac-Toe example
was conceived as a first stab in exploring the

foreign function interface (FFI) of Dogelog Player
inside the browser to register JavaScript functions
that do all kind of stuff with the DOM and events.

But now I have library(markup) for DOM generation
and library(react) for events. So I rewrote Tic-Tac-Toe
using these utilities, reducing the amount of

JavaScript logic to zero. Tic-Tac-Toe is now 100% Prolog.

What also went down the drain abusing consult_async()
to do the game intialization, instead I am now using
perform_async(). So the code went from dangerous.

await consult_async(":- ensure_loaded('browser.p').");

dangerous because of possible file name quoting issues.
To this where the file name is a string object and doesn't
need to be Prolog encoded, because we don't invoke a Prolog

text encoded query but a Prolog term:

await perform_async(new Compound("ensure_loaded", ["browser.p"]));

In has far we should make some Hydration experiment.
What is Hydration. Its a new buzzword around the partially
obsolete design, to have first the HTML body in a broswer

doument and then at the end of the HTML body some scripts:

r/webdev - What is Hydration?
https://www.reddit.com/r/webdev/comments/xqd4i8/what_is_hydration/

The bundle end of HTML body design has usually takes
time time(html)+time(bundle). A better deisgn is unsing
async loading and the quasi-parallelism of the browser,

and load the bundle in the head if possible. The load time
is then around max(time(bundle), time(html))). which might
give better user experience. We should try the same

for our examples, load Dogelog Player in the head. But
the Prolog text loader is not yet task safe. So this might
involve some more work until we can try it.

Also we might nevertheless want to do a little hydration
when the HTML body is read, like wiring event handlers.

Mild Shock schrieb:
> Now I have rewritten the Tic-Tac-Toe example
> to be 100% Prolog. Originally the Tic-Tac-Toe example
> was conceived as a first stab in exploring the
>
> foreign function interface (FFI) of Dogelog Player
> inside the browser to register JavaScript functions
> that do all kind of stuff with the DOM and events.
>
> But now I have library(markup) for DOM generation
> and library(react) for events. So I rewrote Tic-Tac-Toe
> using these utilities, reducing the amount of
>
> JavaScript logic to zero. Tic-Tac-Toe is now 100% Prolog.

Note because of the await in front of the
perform_async() our loading doesn't create a task yet.
It will change the current load sequence. It will

only allow that tasks create before the await get
their share of work. We would need to add one of our
create_task utilities, or use the async option of a

script tag, as recommened here for MathJax v3:

/* put this in the head */
<script type="text/javascript" id="MathJax-script" async
src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js">
</script>

The async option of a script tag is described as:

"For module scripts, if the async attribute is
present then the scripts and all their dependencies
will be fetched in parallel to parsing and evaluated
as soon as they are available."
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#async

Mild Shock schrieb:
>
> What also went down the drain abusing consult_async()
> to do the game intialization, instead I am now using
> perform_async(). So the code went from dangerous.
>
>     await consult_async(":- ensure_loaded('browser.p').");
>
> dangerous because of possible file name quoting issues.
> To this where the file name is a string object and doesn't
> need to be Prolog encoded, because we don't invoke a Prolog
>
> text encoded query but a Prolog term:
>
>     await perform_async(new Compound("ensure_loaded", ["browser.p"]));
>
> In has far we should make some Hydration experiment.
> What is Hydration. Its a new buzzword around the partially
> obsolete design, to have first the HTML body in a broswer
>
> doument and then at the end of the HTML body some scripts:
>
> r/webdev - What is Hydration?
> https://www.reddit.com/r/webdev/comments/xqd4i8/what_is_hydration/
>
> The bundle end of HTML body design has usually takes
> time time(html)+time(bundle). A better deisgn is unsing
> async loading and the quasi-parallelism of the browser,
>
> and load the bundle in the head if possible. The load time
> is then around max(time(bundle), time(html))). which might
> give better user experience. We should try the same
>
> for our examples, load Dogelog Player in the head. But
> the Prolog text loader is not yet task safe. So this might
> involve some more work until we can try it.
>
> Also we might nevertheless want to do a little hydration
> when the HTML body is read, like wiring event handlers.
>
> Mild Shock schrieb:
>> Now I have rewritten the Tic-Tac-Toe example
>> to be 100% Prolog. Originally the Tic-Tac-Toe example
>> was conceived as a first stab in exploring the
>>
>> foreign function interface (FFI) of Dogelog Player
>> inside the browser to register JavaScript functions
>> that do all kind of stuff with the DOM and events.
>>
>> But now I have library(markup) for DOM generation
>> and library(react) for events. So I rewrote Tic-Tac-Toe
>> using these utilities, reducing the amount of
>>
>> JavaScript logic to zero. Tic-Tac-Toe is now 100% Prolog.
>

Corr. Typo

It will NOT change the current load sequence.

Mild Shock schrieb:
>
> Note because of the await in front of the
> perform_async() our loading doesn't create a task yet.
> It will change the current load sequence. It will
>
> only allow that tasks create before the await get
> their share of work. We would need to add one of our
> create_task utilities, or use the async option of a
>
> script tag, as recommened here for MathJax v3:
>
> /* put this in the head */
> <script type="text/javascript" id="MathJax-script" async
>   src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js">
> </script>
>
> The async option of a script tag is described as:
>
> "For module scripts, if the async attribute is
> present then the scripts and all their dependencies
> will be fetched in parallel to parsing and evaluated
> as soon as they are available."
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#async
>
> Mild Shock schrieb:
>>
>> What also went down the drain abusing consult_async()
>> to do the game intialization, instead I am now using
>> perform_async(). So the code went from dangerous.
>>
>>      await consult_async(":- ensure_loaded('browser.p').");
>>
>> dangerous because of possible file name quoting issues.
>> To this where the file name is a string object and doesn't
>> need to be Prolog encoded, because we don't invoke a Prolog
>>
>> text encoded query but a Prolog term:
>>
>>      await perform_async(new Compound("ensure_loaded", ["browser.p"]));
>>
>> In has far we should make some Hydration experiment.
>> What is Hydration. Its a new buzzword around the partially
>> obsolete design, to have first the HTML body in a broswer
>>
>> doument and then at the end of the HTML body some scripts:
>>
>> r/webdev - What is Hydration?
>> https://www.reddit.com/r/webdev/comments/xqd4i8/what_is_hydration/
>>
>> The bundle end of HTML body design has usually takes
>> time time(html)+time(bundle). A better deisgn is unsing
>> async loading and the quasi-parallelism of the browser,
>>
>> and load the bundle in the head if possible. The load time
>> is then around max(time(bundle), time(html))). which might
>> give better user experience. We should try the same
>>
>> for our examples, load Dogelog Player in the head. But
>> the Prolog text loader is not yet task safe. So this might
>> involve some more work until we can try it.
>>
>> Also we might nevertheless want to do a little hydration
>> when the HTML body is read, like wiring event handlers.
>>
>> Mild Shock schrieb:
>>> Now I have rewritten the Tic-Tac-Toe example
>>> to be 100% Prolog. Originally the Tic-Tac-Toe example
>>> was conceived as a first stab in exploring the
>>>
>>> foreign function interface (FFI) of Dogelog Player
>>> inside the browser to register JavaScript functions
>>> that do all kind of stuff with the DOM and events.
>>>
>>> But now I have library(markup) for DOM generation
>>> and library(react) for events. So I rewrote Tic-Tac-Toe
>>> using these utilities, reducing the amount of
>>>
>>> JavaScript logic to zero. Tic-Tac-Toe is now 100% Prolog.
>>
>