Can SWI-Tinker use a library(markup) [Streamable DOM]?

[j4n_bur53]

How difficult would it be to bring a library(markup) to SWI-Tinker.
I asked something similar already in the past. In particular
I asked whether the SWI-Prolog streams allow piggy backing

and filtering. The predicate tag/2 would bypass the filtering,
and use the underlying stream of piggy backing. And the predicate
write/1 would use filtering, namely XML escaping. Take this test:

test :-
    tag('<font color="red">'), 
    write('Hello'), 
    tag('</font>'), 
    write(' '), 
    tag('<font color="blue">'), 
    write('World!'),
    tag('</font>'), nl.

Result with SWI-Tinker:

Result with Dogelog Player:

Advantage of such a browser interface:

• The interface is Hypertext Markup (HTML), which also covers
  Scalable Vector Graphics Markup (SVG), it will not enlarge the
  footprint of your Playground. Its all functionality from the
  browser, you trivially extend the DOM during writing.

• The interface can be made interactive. With little effort, in
  my case an additional library(react), it is demonstrateable
  to have button clicks etc… handled by pure Prolog callbacks.
  You can even do animation, games, etc.. with pure Prolog.

• We don’t need lower or higher level MVC, the DOM is the
  model, not a logical one, more a physical one, especially in the
  case of SVG, but you can still use CSS for more flexiblity.

• Things like my library(plot) from Dogelog Player would work
  in SWI-Thinker. And vice versa if some stuff would arrive on
  SWI-Thinker side, it would also work in Dogelog Player.

• I have much more like only library(plot). I use a library(vector)
  trivially bootstrapped from library(markup) which provides some
  ways to deal with SVG viewports in a scalable way. You can do
  educational stuff like library(turtle) as in Python:

Turtle Programming in Python
https://www.geeksforgeeks.org/turtle-programming-python/

• What I didn’t manage to try yet, is measuring the text size,
  and do some more advanced layout, like for example the
  Tau Prolog graphical tracer. What I also didn’t try yet
  is shadow DOM, which would allow to create widgets.

• I don’t know how the idea relates to PCE, does it have some
  markup language at all? With library(markup) you get a table-
  mode and a plot-mode, all based on XML, which probably
  drives Emacs Cultists completely nuts.

• The library(markup) also works headless, you can use it to
  generate files such as HTML reports, SVG graphics, etc.. etc..
  This needs a little extra Prolog code in the library and some help
  by the streams to do the HTML layout indentation.

• Disclaimer: I didn’t look into Trealla, Scryer or Ciao, what they
  support in this respect. I only had a look at SWISH and their
  concept of answer substitutions filters. I find this too restrictive,
  already the library(turtle) cannot be done in this setting.

• Credits: Mainly go to Tau-Prolog, which had somewhere a HTML
  writer integration. But the present library(markup) is an improvement
  on this HTML writer by the piggy backing design. Unfortunately
  at this moment https://www.tau-prolog.org/ is not savely reachable.

• What else…?

[jan]

Adding markdown is probably quite simple, except that, as is, PlDoc is not included and the markdown parser is part of PlDoc. I still wonder whether or not to include PlDoc and the documentation. It is quit big.

@j4n_bur53

test :-
    tag('<font color="red">'), 
    write('Hello'), 

This works:

test :-
    html([ font(color(red), 'Hello'),
           ' ',
           font(color(blue), 'World!')
         ]).

I think that is a more elegant and controlled way to include HTML (and SVG, JavaScript, etc.) I thought one could use a little trick like this:

tag(Tag) :-
    tinker_query(Q),
    _ := Q.answer.insertAdjacentHTML("beforeend", #Tag).

But, it turns out that it completes the HTML, so tag('<font color="red">') inserts <font color="red"></font>, making it rather useless. You may see some trick. tinker_query/1 gives you the JavaScript object representing the current query and .answer gives you the <div> for the current answer. Next, you can do whatever JavaScript allows you to do. write/1 and friends to user_output write to the WASM output handler, which decodes ANSI escape sequences and normally adds one or more <span> elements to the current answer.

As is, I think you can do simulations, interaction, etc. There may be a way to achieve a Tau/Dodgelog compatible interface. I thought insertAdjacentHTML() would allow for that, but apparently no. There could be another trick?

I think it is worthwhile to look into htmx. While designed as client/server, it may provide a nice way to build local Prolog applications if we can bypass the client/server interaction and call Prolog locally instead.

[jan]

@j4n_bur53

Such things are not covered by library(markup),

Which library are we talking about? I looked at Tau, but I can’t find it (quickly).

@j4n_bur53

You cannot swap content with it. With library(react) you can swap content.

Same question. And yes, htmx would be for interaction. I’ve become to like this library quite a bit for writing interactive web applications in Prolog. I’d imagine something like below. That seems a lot more practical than having to use e.g. Tau’s DOM manipulation and bind/4.

<button hx-call="clicked(me)" hx-swap="outerHTML">
    Click Me
  </button>

I’ve been thinking about supporting tag/1. It is fairly simple along the lines you outlined. Can be done entirely from Prolog, but a lot simpler and more robust with some small additions to the tinker.js code. I think it is a bad design as it easily leads to invalid HTML due to errors, failure, etc. I don’t see any advantage over html/1 as now provided in Tinker, which does ensure safe injection of arbitrary DOM elements. It can deal with arbitrary Prolog code. For example, this prints the output of mygoal/1 in bold:

 ?- html(b('~@'-[mygoal])).

Still, if there are libraries that can be reused by adding support for tag/1, it is worth it. So, where are they?

[jan]

These are all useful observations, but without access to library(react), not even knowing what exactly it does, this is meaningless for discussion on a public forum. If you are willing to share these libraries under an accepted open source license I’m happy to discuss adjustments to make them work together with the SWI-Prolog WASM version.

And yes, for htmx the idea would be to see whether it is possible to use the library and hack it to bypass the fetch() and replace it with a direct call to the embedded Prolog system. I have no clue whether or not that is feasible. JavaScript is quite flexible though

[j4n_bur53]

(Nothing of importance)

[jan]

Could you please stop deleting all your posts. There were at least two useful pointers, links to your libraries and an explanation on how tag/1 could be implemented.

I’m happy to have a discussion about tag/1 vs html/1 as it now appears in Tinker. If you delete the relevant pointers, there is not much point.

[j4n_bur53]

(Nothing of importance)

[jan]

@j4n_bur53

Its just a silly stack machine, using the DOM itself as a stack,

Thanks. It is now fairly clear how it works.

@j4n_bur53

The SWI-WASM button click example is relatively easy to do:

Yes, but is it any better than the SWI-WASM version? Note that the old was a bit strange mixture of Tau-Prolog library(dom) and Prolog calling JavaScript. I’ve updated the example and implemented two versions, one using the (now completed) Tau-Prolog library(dom) and one using exclusive direct calls to JavaScript from Prolog. The page now also shows the sources, making it a bit easier to understand.

@j4n_bur53

The compiled closure [E]>>foo(E) gets disconnected when the button is reclaimed, for example when the page is reloaded or the output region with the button is cleared. Disconnected objects, that are not anymore reachable, do get garbage collected by the JavaScript native garbage collector.

The old bind/4 implementation used a hack to work around the fact that callbacks are based on strings. I now use a more elegant approach which does not store anything into the Prolog database, so JavaScript GC can do its job.

What I’m looking for is a convincing example where your tag/1+write/1 is clearly better. Please with (pointers to) the source …

[jan]

@j4n_bur53

Tau Prolog has also unbind/2

The current library(dom) supports all that is documented in https://tau-prolog.org/documentation#prolog, except unbind/3, i.e., unbinding a call to a specific goal. Not sure how to do that yet. I somehow need to map the goal onto the JavaScript function for that.

@j4n_bur53

This is a
demonstration of non-inverted programming, the wait/3 version versus
so called inverted programming, the bind/3 version here, in the browse

After a bit of hacking, this works in SWI-Tinker. You can also abort this. Probably this needs some more wrapping. Also html/1 should get some variation that returns a DOM node, so we can combine it with DOM manipulation and the Tau library(dom).

run :-
    html(button(id(run), click)),
    Button := document.getElementById("run"),
    loop(Button).

loop(Button) :-
    Promise := prolog.promise_event(Button, "click"),
    await(Promise, _Event),
    _:= Button.insertAdjacentText("beforeend", " and again"),
    loop(Button).

@j4n_bur53

Here is again a summary of the library(markup) requirements,
I tried to boil down the mini paragraphs into one liners:

I cannot do much with “Should be able to do library(X)” Otherwise I think Tau-like DOM manipulation with some comfortable way to create DOM elements gets you a long way. The same idea should work for SVG as well. The Tau library is missing some stuff though, such as querySelector[All], remove/toggle classes, etc. I’m unsure about coverage by Prolog predicates vs. calling JavaScript directly. Prolog predicates look nicer, but in the end you are replicating the whole JavaScript DOM API in predicates and when you use JavaScript directly you can profit from the widely available resources for JavaScript, both in terms of programmers knowing it and documentation/tutorials/books/… So, possibly DOM oriented Prolog predicates should be limited to things that are Prolog specific, such as binding an event to a Prolog predicate.

@j4n_bur53

I have no clue what your, i.e. SWI-WASMs, business needs are…

I don’t know either. For now, it is mostly for the fun

[j4n_bur53]

(Nothing of importance)

[jan]

@j4n_bur53

But I am still trying to find more “universal” approaches that rely more on streams.

I don’t really recognise streams as a more universal approach. Moving around, pushing and popping tags, etc. seems rather fragile to me. What about a little non-determinism that causes pushes and pops not to match? Or failures, exceptions, etc? I prefer the term-representation of the DOM as used by html//1 and the WASM library predicate html/1. Currently, that is translated into an HTML string that is used with innerHTML, but that need not be the case. You can also make the translation to HTML more direct, i.e., by translating it to a DOM structure using JavaScript. Or, if there is an existing DOM you can do a smart update. I think I want some library predicates that create a DOM element, replace the content of a DOM element or add to the content of a DOM element using this Prolog representation. I think this approach is more robust and provides a more high-level interface than tag/write style of streams.

@j4n_bur53

/* from SWI Tinker highlight.pl */
refresh_all :-
    clear_highlight,
    highlight_all.

/* uses CodeMirror clearMarks, mark etc.. */

This is an old remain (removed). For a bit longer file it resulted in a noticeable clear and reappear of the highlight and is slow. So, the current version uses an array of highlight markers and the next marking phase compares the new marks with the array. If the marks in the array match new new mark requests nothing is changed. Otherwise we delete the old mark and create a new one. This makes the refresh faster and removes the flicker effect.

[jan]

It remains a bit hard to discuss when you talk about libraries for which you once posted a link (If I recall correctly) that you deleted and that I couldn’t find in a reasonable time using Google.

Your (again deleted) claim that html//1 “has extremly bad publicity” is rather new to me. I’ve seen that it confuses people. Using DCGs for serialization is unfortunately something that few people are familiar with The idea to represent a DOM tree as a Prolog term is also used by Ciao’s HTML framework AFAIK and, IMO, still the most sensible approach. Details can of course be criticized.

I don’t see the problem. html//1 is an abstract specification for generating an HTML document of, if you wish, a DOM tree. I just did a little experiment and in less than half an hour I wrote a prototype that uses the JavaScript DOM manipulation to make html//1 generate a list of HTMLElement instances. I’m curious how it performs compared to generating a HTML source text.

[j4n_bur53]

(Nothing of importance)

[jan]

@j4n_bur53

Source 1 (SWI - Dialect):

True, you cannot get the same DOM easily. This would be my code:

chat([], _) :- !.
chat(L, F) :- maybe(0.5), !,
   G is 1-F, 
   chat(L, G).
chat([X|Y], F) :-
   write_word(X,F), write(' '), flush_output, 
   random(A), B is 0.1+A/5, sleep(B),
   chat(Y, F).

write_word(X,0) :-
    write(X).
write_word(X,1) :-
    html(b(X)).

test :- T = 'The quick brown fox jumps over the lazy \c
 dog. The quick brown fox jumps over \c
 the lazy dog.\n', atomic_list_concat(L, ' ', T), chat(L,0).

This works fine, but it creates multiple <b>word</b> nodes rather than a single for consecutive bold words. You should be able to get that using what I have in mind, but the code will be a little different. Note that your code suffers from exactly what I was worrying about: you need an ugly conditional statement to add a final </b>

[jan]

@j4n_bur53

Seems we are still not yet on the same plane. Just imagine a chat
bot like ChatGPT, throttling for usability and emitting a bullet list:

Indeed. Well, I think I understand more or less your design. Although, your claim it would take 4 years to properly implement and test it remains weird. It looks like max a page of code given what there is. Mainly make the Tinker output handler aware of the state machine. In fact, using insertAdjacentText() to some designated node may be a better choice than the current insert of a <span> into a designated node, at least when doing many small writes.

But, where you stated at some point that your design is a two stage design that guarantees a consistent DOM, all your examples do not show that and show situations that easily leave the state engine in state where subsequent output produces unintended results. Luckily modern browsers are quite relaxed about unbalanced tags, but still.

The code below works in my internal version of Tinker. The names and details are unsettled, show/1 is not a good name. The idea is though that create//1 is the same as html//1, but it returns a list of HTMLElement objects. show/1 just calls phrase(create(Input), Elements) and then adds the elements to the current answer (each Tinker Query instance has its own answers). create//1 takes the same input as html//1, with one addition: it allows for Var=Node, which creates Node and binds Var to the HTMLElement created. This construct can be embedded anywhere in the create//1 input. That allows you to get access to nodes without having to use id="ID" and getElementById().

The loop now does the two steps explicitly. That will be handled by a single call later, e.g., append_html(UL, li(['List item', I]). I’m struggling with the names and how to relate this to Tau’s library(dom) and SWI’s library(http/html_write) (or not).

bullets(L,H) :-
    show(UL=ul([])),
    forall(between(L,H,I),
       	   (  phrase(create(li(['List item', I])), [LI]),
              _ := UL.appendChild(LI),
              sleep(1)
           )).

With some utilities to empty a node, remove a node, etc. I think you get something that is pretty comfortable in managing the DOM and never messes up the dom as there is no global state in some hidden state engine.

[j4n_bur53]

(post deleted by author)

[j4n_bur53]

(post deleted by author)

[j4n_bur53]

Now I tried the recent release 9.3.22 of SWI-Prolog which claims:

@jan

Extended library(dom) to fully implement the same library as found in Tau-Prolog.

But somehow “HTML Writer” is missing. What Tau-Prolog
called internally Streamable DOM. This here works:

setup :-
    body(Body),
    create('div', Elem),
    set_attr(Elem, #id, #writeme),
    append_child(Body, Elem).

Unfortunately this here doesn’t work, the example given by José
Antonio Riaza Valverde in this GitHub issue discussion:

output :-
    get_by_id(writeme, WriteMe),
    open(WriteMe, write, Stream),
    write(Stream, hello),
    write(Stream, world).

I get this error in SWI-Tinker:

open/[3,4] doesn’t recognize the js_HTMLDivElement, and does
not provide a raw write stream on it.

[j4n_bur53]

(post deleted by author)

[jan]

@j4n_bur53

get_by_id(writeme, WriteMe),
    open(WriteMe, write, Stream),

It is not in the public predicates of Tau’s library(dom), but an extension of its open/3 implementation. We can implement this in Prolog by wrapping open/3 and using Prolog implemented streams (SWI-Prolog -- library(prolog_stream): A stream with Prolog callbacks).

It seems poor design to me as it makes it very easy to inject invalid HTML. Your tag/1 + write/1 is a better design, though I think it is still not a good match for Prolog.