# Blocking operations in the WASM version (JavaScript expertise needed) **URL:** \ **Category:** Help!\ **Tags:** javascript, wasm, browser, async\ **Created:** [August 4, 2022, 4:07pm UTC](https://swi-prolog.discourse.group/t/blocking-operations-in-the-wasm-version-javascript-expertise-needed/5655 "2022-08-04T16:07:51Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [August 6, 2022, 11:27am UTC](https://swi-prolog.discourse.group/t/blocking-operations-in-the-wasm-version-javascript-expertise-needed/5655/16 "2022-08-06T11:27:54Z")
> [@rla](#): > > Some time ago I started working on TypeScript support for FLI (prolog.js converted to TypeScript) and packaging up the SWI WebAssembly version to NPM. Typing support would make FLI a bit more tolerable for JS developers and make it easier to build top-level interface on top of it. NPM would make distribution and integration with Node and frontend (Webpack etc.) much easier. Sounds good. For now my emphasis is on the low level. I definitely need support to get the high level right. > [@rla](#): > > Using FLI is way too low level indeed. Maybe the term representation could be ported from JPL interface to JS using similar classes. I have had discussions with @ericzinda on a new general JSON representation for Prolog terms. The idea is to create something where the terms you normally like to transfer (lists, strings, numbers, objects) come pretty natural, but the representation has escapes that allow for faithful round trip of arbitrary Prolog terms. > [@anon95304481](#): > > there is no async/await in the shell.html code, so the auto-yield would not land in the browser top-level, One thing at a time 🙂 Auto yield is in the planning and probably fairly easy. Roughly means doing the same as calling js\_yield/2 automatically each Nth increment of the _inference counter_. A more serious problem is that yielding from any position in the VM is probably not that easy and that is what would be required to yield for debugger interactions. Another complication is that in the current design there is a significant number of places where Prolog is called through C, e.g., C → Prolog → C → Prolog → … Yielding from there would require a general mechanism to yield in C. Does that exist? It _might_ be possible using stack copying? You need to think outside the C standard, so even if it can work for C, can it work for WASM? As I see it now, auto-yielding will surely be added. Hopefully yield for the debugger is possible. If not we have two alternatives: a debugger as meta-interpreter or a debugger based on recording the actions and replaying them. Possibly some of the C → Prolog → C → Prolog calls can be avoided or we can extend the C in the middle to save/restore its state such that we can yield through the callback. --- _[View the full topic](https://swi-prolog.discourse.group/t/blocking-operations-in-the-wasm-version-javascript-expertise-needed/5655)._