Elm to Python transpiler

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!

4 Likes

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:

  • Smaller address space, limited to < 32 bit with popular engines. (Is there a javascript engine without this limit?).
  • (On a decent server with several CPU cores) Limitation to a single thread reduces throughput to a fraction. (Introducing concurrent execution on the level of the Elm code should be simpler than on the level of javascript because of constraints such as immutability.)

But I don’t know if these are the same problems that motivated exploring compilation to python :man_shrugging:

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.

2 Likes

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.)

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.