WASM wait for user input

[LyzardKing]

I’m trying to build an interactive “expert system” in an html page with the wasm version of swi-prolog.

I have a textbox for the user input (that would normally come from the console), and a button to submit the text message.

I can write to the html page, and I can use bind/4 to add click events on the button, but is there a way I can suspend prolog until the value is read from the textbox?

Here is a snippet from my code.
add_message simply prints strings on screen, nothing more.
In the read_and_continue I can print the data read form the textbox, but ask_user does not wait for read_and_continue to end.

ask_user(Question)  :-
	get_by_id(submit, Button),
	add_message(expert_message, P),
	bind(Button, click, _, read_and_continue(Question)).

[jan]

Good question. I think the answer is in creating a promise that waits for the (click) event and then use await/2. There are several code snippets on stack overflow for waiting for an event using a Promise. If you also want to process other stuff you should probably make sure that this “thread” runs in is own engine using Prolog.forEach() with the {engine: true} option as you find it (only) in the very latest (9.3.20) release.

So far, Prolog+WASM+JavaScript was mostly limited to using callbacks. With JavaScript Promise and Prolog engines we have something similar to JavaScript async functions. No example code and experience though. Please give it a try and share your experience!

[LyzardKing]

I tried (copying some strange javascript code from stackoverflow for the js part).
The issue is if I run it with swipl-wasm I get the error in the picture. I’m not sure about what the input window is…

My understanding is that the prolog part should be something like this:

ask_user(P, Proof, Trace)  :-
	get_by_id(submit, Button),
	add_message(expert_message, P),
	FP := waitForClick(),
	await(FP, Text),
	_ := console.log(Text).

If I remove the last three lines I can print stuff to the html page (that is what add_message does).

waitForClick is the javascript code that adds the promise to the button click, and returns the value read from the input.

I’m sure I’m missing something obvious

[jan]

The system error points at a GC error. Most likely caused by something fishy in JavaScript that wraps the WASM kernel.

Can you turn this into a reproducible thing we can run?

[LyzardKing]

Sure. I made a few changes and included everything in the html file (prolog script included).
I’m not particularly familiar with Javascript, so that might very well be where the issue is.

This is basically the tweety code, with the addition of a user query tied to the html form.
The user is supposed to enter yes/no in the textfield.

expert.html

[jan]

Sorry for the delay. There are two issues.

• There are two singleton variables. Apparently something goes wrong reporting these, causing the GC system error. If you fix these, you get a little further.
• To run the query, you use Prolog.query().once(). But, this is synchronous. If you want async programming (which you need if you want to use Promises), you need Prolog.forEach(). That returns a promise, so you either need to add .then(...) or put it in an async function and add await.

With these two fixes it prints the answer to the question in the console, so that step works. I didn’t look at the rest.

Up to me is why printing compilation warnings leads to problems …

[jan]

@jan

Up to me is why printing compilation warnings leads to problems …

Fixed that one. Loading your original program in the latest version now gives this in the console, which looks pretty adequate to me.

swipl-web.js:9 Warning: /script/1:79:
swipl-web.js:9 Warning:    Singleton variables: [Button]
swipl-web.js:9 Warning: /script/1:109:
swipl-web.js:9 Warning:    Singleton variables: [C]
expert.html:182 Consulted
swipl-web.js:9 await/2 is only allowed in Prolog.forEach() queries
```

[LyzardKing]

Thanks Jan!
Now it works. I hadn’t realized how the forEach worked.

There are still a few things to fix with more complex question/answering systems, but I can work with it now!

I’m basically re-implementing parts of the webconsole pack for an expert system.

(I’m sure there are better ways to go about doing this…)

[jan]

@LyzardKing

(I’m sure there are better ways to go about doing this…)

Probably. We should probably have a closer look at other browser based Prolog systems such as Tau Prolog. Note there seem to be three ways for Prolog in the browser:

• Build it all in JavaScript (e.g., Tau)
• Compile to WASM. As is, WASM is synchronous unless you compile it as async code, but Emscripten says there is a high price both wrt size and performance. WASM engine support seems to be on the way, which may change things. If not, we have two options
  • Put Prolog in a web worker and communicate with it using messages. That is what e.g. Ciao does (AFAIK)
  • Support yield from the VM, so you can return to the browser event loop, optionally wait for something and resume. That is what SWI-Prolog does.

The first and last allows quite direct manipulation of the DOM, something which is a lot harder when using a web worker. These two result (I think) in a different approach for integrating Prolog into the browser.

At least, that is my current understanding. I’m not a browser/JavaScript/WASM expert though. If I missed some useful path, I’d be glad to hear.

[LyzardKing]

I’m no browser/javascript expert either. Far from it in fact.

I’m mainly trying to use it for simple demonstrations of user interaction aimed at students.
I have to admit that I’d also like something more robust to come out of this, but that’s a long term plan…

[j4n_bur53]

Somehow this is an old Problem, isn’t it? There was a prototype of
Web Prolog by @torbjorn.lager which even showcased a working
terminal! Maybe from some library? But I don’t find it anymore…

I was playing with the new WAM shell. The announcement says:

@jan

Make get_single_char/1, read/1,2 and read_term/2,3 read from the
browser when the input stream is user_input.

I tried a query [user]. Is this supposed to work? A ask dialog
appears, I entered “foo(bar).” pressed ok and then entered
“end_of_file.” and pressed ok. And then I pressed cancel:

But the result is only:

[jan]

@j4n_bur53

I tried a query [user]. Is this supposed to work?

Nope. That should probably be disabled. We could hook it by hooking read_clause/3. Probably there is a better alternative by showing an editor inline, but why not just create a new file and load that? So, I think the most sensible thing is to display a message hinting at that.

In general, all predicate that read from user_input must be hooked. I now do that by wrapping the predicate using wrap_predicate/4. The wrapper uses one of the low-level yields or creates a JavaScript Promise to get the required info from the user and uses await/2 to wait for it.

[jan]

@j4n_bur53

The screen splitting is an additional use case

Spit what into what?

@j4n_bur53

Also I didn’t expect the ask dialog, rather some inline reading.
This was a feature of the Prolog console I saw at @torbjorn.lager .

@j4n_bur53

Most programming languages come nowadasys
with a proper web console, the screen splitting is less often seen in
programming languages as a first encounter. This is what you get in Python

That is possible if you run SWI-Prolog as a web worker and use messages to talk to “terminal” in the browser. That is what Ciao does (AFAIK). I guess you can do the same using SWI-Prolog’s WASM binary. The SWI-Prolog playground runs in main browser task though. That implies it has to yield for anything that requires synchronous input. The advantage is that you can create a much nicer user experience and even allow the user to interact with the browser (we could add a JavaScript editor as well ). The disadvantage is that you need to redefine all predicates that read from user_input. If you don’t, you get this input prompt from Emscripten (not sure where this is defined).

Pushed a version that blocks ?- [user]. with a message and adds dealing with the terminal code extension for hyperlinks, such that many messages from Prolog result in clickable links, including errors and warnings from loading files.

[j4n_bur53]

@jan

There is of course still a lot to wish for. It is becoming a usable
tool though. Please try it out. Better yet, improve it!

Yes, something else, how can I make multi-line input? I find that read(X)
doesn’t show as an ask pop-up. But somehow multi-line input is not supported:

Normal Console:

WASM Shell:

[jan]

As yet, that is not supported. The plan is to replace the simple <input> with a CodeMirror based editor as it is used in SWISH. That can also reuse completion, etc. I’m still a bit unsure where this should go. I created a tentative TODO at swipl-devel/src/wasm/demos/shell/README.md at 4de058d21bffd41b26059e3a8cc92b8cb4e6360f · SWI-Prolog/swipl-devel · GitHub

[torbjorn.lager]

Hi Jan!

I personally think that Prolog in a web worker and JavaScript communicating with it using messages is the approach that every system that wants to be on the Web should take. I appreciate that it might be slower than direct manipulation of the DOM from Prolog, but is seems to me that is should be fast enough for most purposes. Perhaps a PIP for this is called for? It should be possible to agree on a protocol that might be standardized.

It seems to me that building a large and complex end-user application on top of it all will often require adopting a JavaScript framework of some kind, and if done in a commercial project, programmers that know their ways around it. And who knows, in a perhaps not too distant future, the front-end might be written by an AI - check out Bolt (at https://bolt.new) for an example of such a system. In this future, perhaps all one needs to do is to feed such as system with a description of dedicated web-worker protocol and instructions for how it should be used for the target application.

Ideally of course, a Prolog system might support both the web-worker approach and the DOM-manipulation approach, but I think code for the latter should be in the form of system-dependent libraries until the Prolog community can agree on how it should be done.

Those are my €0.02.

[torbjorn.lager]

You may well be right, I haven’t looked at this in detail. But I find it hard to believe that something like that would be impossible to implement.

[torbjorn.lager]

One reason I opted for a very traditional Prolog REPL in my Web Prolog proposal is that I saw this as the only reasonable way to present examples (in tutorials, papers and my (still forthcoming) book – examples showing how to do interactive programming in Web Prolog.

When implementing the REPL in the Web Prolog PoC (at GitHub - Web-Prolog/swi-web-prolog: A proof-of-concept SWI-Prolog implementation of Web Prolog), I found that I could make good use of JQuery Terminal (https://terminal.jcubic.pl). Towards the end of this file is where I used it:

web-client/apps/swish/index.html

(I know, I’m not much of JavaScript programmer…).

What is convenient with such a package is that it provides us with a history function, handling of key presses, etc. There might be other, more modern packages. Google finds GitHub - xtermjs/xterm.js: A terminal for the web and javascript-terminal - npm for example.

[LyzardKing]

The discussion here is very interesting, although the direction is different from what I had in mind originally.
My goal was to replicate something like the webconsole pack (Pack webconsole -- prolog/webconsole.pl), not as a terminal, rather as a way to build end user facing question/answering systems.

I’m not a js/html developer by any stretch, but my idea was to write it in a way that was generic enough that it could then easily be expanded with some web framework.

As an example I can currently create simple web forms, with the default input classes (text, number, date, …), but this is agnostic with regards to the specific extra javascript/css/html in the web page.

Part of this is to show students that they can develop an expert system (like the one in the Bratko book). I think it helps students to see that they can interact with the program they wrote on a webpage. The code can then be run from the terminal, or from a webpage, but the prolog rules remain the same.

[jan]

@torbjorn.lager

I personally think that Prolog in a web worker and JavaScript communicating with it using messages is the approach that every system that wants to be on the Web should take.

I guess that is technically possible using the current JavaScript+WASM version of SWI-Prolog. I have little interest in it though. You can make the interaction so much better by exploiting HTML5

@torbjorn.lager

It seems to me that building a large and complex end-user application on top of it all will often require adopting a JavaScript framework of some kind

So far, the PoC shell is pure JavaScript. I think that is enough. The only serious external dependency is the CodeMirror editor. I think the currently monolithic JavaScript file must be reorganised in a set of classes and files, such that components can be swapped easily.

@LyzardKing

My goal was to replicate something like the webconsole pack (Pack webconsole – prolog/webconsole.pl), not as a terminal, rather as a way to build end user facing question/answering systems.

Notably for educational purposes it might be an idea to add a library to the current shell that allows for creating UI widgets inline and wait for them. This would be some hybrid between using the plain browser version without the shell to create an application (for example @PaulBrownMagic’s CBG Chords demo and a plain text version.

I’m still unsure about the role of the browser version compared to SWISH. SWISH has a lot of good things and has proven to be valuable both for education and real applications. Typically these two use cases use different features of SWISH though. For education it is main a combination of notebooks and small programs. Real applications typically use its shared access to large resources and its API to support external tooling. One of the nice things about the browser version is that it can deal with state, (visual) simulation and is not limited by the sandbox.