Make PyScript an optionally typed language

[almarklein]

@almarklein commented on Fri Sep 08 2017

This is sortof a spinoff from #377. If the transpiler knows all the types of the code, then generating the JavaScript for it is much easier, and it can find errors earlier. This would probably be implemented by doing type inference (editing the AST) in a step right before transpiling it to JS. Some advantages:

• The transpiler code would be easier (unless typing is optional).
• The generated JS code would be more concise and easier to read.
• Speed, by saving a lot of function calls that we now add, most notable for adding (because Python can add strings).
• Avoid some of the PyScript glitches (#332).
• The compiler can "keep track" of what arrays are really tuples, and thus prevent mutations to them.

If we take it a little further, we can also get rid of some of JS' more profound limitations, as inspired by Elm:

• When calling a function that can return null/None, ensure that the code checks for this.
• The compiler can verify what values an object has (e.g. events), and so prevent undefined (i.e. a variant of Elm Records).
• We could even get rid of Exceptions altogether, and have functions that can fail return a "Result object" that must be checked.

There are some difficulties with the last point though, thinking in particular about array indexing. When accessing an array in Elm, it returns a result object that has to be checked before the value can be used. In Rust, accessing an array out of bounds will even panic (i.e. abort the process). Checking the value from each array index seems awfully verbose, so this approach only makes sense if the compiler is smart enough to know that indexes are within bounds in most cases (e.g. by knowing the size of the array and the max possible value of the index variable), so that the user does not have to make the check. But that sounds like quite a lot of work.

Another consideration is whether typing is mandatory or optional. Mandatory typing makes the compiler easier, but it means that all code that is used in PyScript must be typed. It also means a slightly higher learning curve. However, with type inference, one typically only has to annotate the input variables, so it should not be that bad.

When PyScript would be fully typed, compiling (parts) to WASM will be much easier, if it makes sense in the future.

---

@JohnLunzer commented on Fri Sep 08 2017

I recently wrote a single function to recursively print out lists of lists, dicts (value) of dicts, lists of dicts or dicts (values) of lists. Each line needs to print slightly differently depending on whether it is an item in a list or a dict's key, value pair. Because Python is dynamically typed and I didn't need to specify the type of the input, I could make a single function, treePrinter.

For that matter, with static typing, you have to either disallow arrays of multiple types (which I think is a hallmark feature in Python), create a collection datatype, or create some iterable base class which becomes the declared type of such arrays.

What I'm describing is simply the one of the side effects of using a statically typed language vs a dynamically typed one, and it changes how you design your code (which as you said changes the learning curve).

For a language called PyScript it would be a rude awakening to Pythonistas to find out it was a statically typed language.

I am always in favor of design decisions that simplify a codebase (even if it means giving features). Additionally the speed and less verbose compiled JS are also large considerations.

Basically it sounds like moving PyScript more in the direction of Cython, which I think would make it less Pythonic.

Tough call. As a user, I would say make static typing optional to still get the benefits on the JS side. As a developer I would go for the simplest option, mandatory static typing.

---

@almarklein commented on Sat Sep 09 2017

Thanks, you make a really good point. I guess its tempting (from a developer point of view) to go for mandatory typing, but I'm with you that it will impose quite severe constraints to what users can do with PyScript.

Perhaps, optionally typing does not have to be that much more complex. At the moment, PyScipt sorta tries to strike a balance between performance and Pythonic-ness; these two goals are sometimes in conflict. Having optional typing could allow us to be much more Pythonic, at the cost of speed, unless the transpiler knows about the types, in which case the JS will be really fast.