Support for compiling functions to WASM

[almarklein]

@almarklein commented on Thu May 25 2017

Instead of transpiling to JavaScript, we could compile to WASM. This would make PyScript a language that is really fast, we can support ndarrays, and a safer language that fails hard when it does (unlike JS's undefined for nonexisting attributes).

This will be really hard if you want to make it feel fully like Python. But if you make it a typed language (i.e. requiring the user to use Python's type annotations) it should be possible to statically compile it. Even then it will be a lot of work though. Probably too much, but we should at least consider it.

---

@almarklein commented on Tue May 30 2017

Maybe targeting WASM is a bit of a long shot, but in this line of thought, we can consider an Elm-like approach, by making PyScript more type-aware so that we can prevent errors at compile time.

---

@afidegnum commented on Sat Jun 24 2017

I second that! i have been reading elm but pyscript is a new groundbreaker

---

@almarklein commented on Thu Sep 07 2017

As mentioned many times, a major problem with PyScript is that it looks like Python, but is really JavaScript. I wonder whether this is a problem because its not Python, or because it is worse than Python, by which I mean that JS is a language with no compile time checks so more errors at runtime. Or worse, without runtime errors (e.g. attribute access) causing the code to behave in unpredictable ways, or runtime errors in other places.

I suspect that if PyScript would catch most errors at compile time, the fact that its not Python would not be that bad. Compiling to WASM is one option, but we could also just compile to JS and do type checking. The main idea is to fail early instead of later. Elm even promises to have no runtime exceptions.

This somewhat relates to #367, which proposes to have classes that are instantiated either in Python or JS. We could force the JS classes to be typed.

---

@almarklein commented on Thu Sep 07 2017

An example that just popped to mind is properties that are tuples. In Python these are immutable, so you need to make a copy to change them. In JS these are a list, and one can mutate the value and then set it, but Flexx will then not detect that the value has changed. I've seen this go wrong several times.

---

@almarklein commented on Thu Sep 07 2017

BTW, if PyScript would target WASM instead of JS, there would be some pretty interesting implications, because WASM can (eventually) run anywhere ... For instance, one can write code to do performance critical stuff (e.g. image processing) which you could run inside the Python process.

---

@ivoflipse commented on Thu Sep 07 2017

Beeware's Batavia approach also seems interesting https://github.com/pybee/batavia

Instead of writing an interpreter or transpiler, execute the Python bytecode from JS.

---

@almarklein commented on Fri Sep 08 2017

Yes, it's interesting, but really really slow :)

---

@almarklein commented on Tue Feb 06 2018

Letting PyScript target WASM is not a good idea. I changed the title to reflect a more achievable goal: to support writing specific functions that run in WASM. This will likely be done by compiling typed Python to WASM. Windel is already working on something like this in the PPCI project (which, btw, may also support executing WASM in Python at some point).

The purpose would be to write compute-intensive (but otherwise relatively simple) in a way that can run faster than we can in Python/JS.

[almarklein]

In response to https://twitter.com/mark__land/status/1040547580193714176, maybe if https://github.com/RustPython/RustPython becomes a thing :)

[Mec-iS]

i think the most reliable and future-proof build model at the moment can be

Python > AssemblyScript > WebAssembly

1. it improves performance in the client
2. it takes JS out of the picture