Hi folks, I have been writing an Elm-to-Python transpiler. The first major milestone is that it has now successfully transpiled Dict.elm into a Python file called Dict.py. More importantly, the Python-side code actually works!
More details here: https://github.com/showell/elm-py/blob/master/parser/README.md
I am looking for feedback and questions. Thanks!
Thank you Steve for sharing your experience, interesting project.
I had a look at that readme file. For me, this part was the most interesting:
I want to be able to translate Elm code into Python code for things like multi-player games, where the front end runs in Elm, but I can borrow Elm code to run on the server for things like move validation (using the same types and helper functions as the front end).
I enjoy (re)using Elm code on both frontend and backend, but I did not yet understand the choice of python over javascript as compilation target.
Did you explore the approach of using the official Elm to javascript compiler and a javascript engine to execute the Elm code? Did you run into problems with this approach?
For the applications I have seen so far, biggest problems resulting from depending on a javascript engine are:
But I don’t know if these are the same problems that motivated exploring compilation to python 
The game I referred to is a pretty simple board game, so performance isn’t a big issue. It’s more about just being personally more fluent in Python than JS for certain types of coding. There is a minor AI piece to the game where I want to run some simulations to tune some heuristics, for example, and it’s mostly gonna be imperative code running loops, saving data to files, etc., all the kinda stuff I have been doing in Python for a long time. But I have some significant pieces in Elm I don’t want to rewrite manually in Python.
That’s the part that I was missing earlier. I had not noticed that you also want to integrate some code into the server, which is not written in Elm.
Before, I had only thought about backends where all persistent parts are written in Elm, and the overhead (both development and runtime) of serializing and deserializing on the boundary to non-Elm parts is much smaller.
Gary Bernhardt talks about the “Functional Core, Imperative Shell” pattern in his talk by the same name: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell
I think it’s a useful pattern, and it can be nice to have it all run in one language, without having a serialization boundary. (There’s still a minor boundary in my scheme, but it’s pretty trivial–basically, you have to call toPy and toElm when you’re switching between native Python dict/lists and the Elm-inspired persistent Dict/List instances. But it’s that simple; there’s no data formatting, no memory management concerns, etc., as the transpiled code really is just vanilla Python.)
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.