# Elm to Python transpiler

**URL:** <https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784>\
**Category:** Show and Tell\
**Created:** [December 4, 2019, 8:40pm UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784 "2019-12-04T20:40:00Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![showell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/showell/32/2647_2.png) [@showell](https://discourse.elm-lang.org/u/showell)\
**Post date:** [December 4, 2019, 8:40pm UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/1 "2019-12-04T20:40:00Z")

</div>

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](https://github.com/showell/elm-py/blob/master/parser/README.md)

I am looking for feedback and questions. Thanks!

---

<div class="post-metadata">

**Author:** ![Viir](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/viir/32/4103_2.png) [@Viir](https://discourse.elm-lang.org/u/Viir)\
**Post date:** [December 4, 2019, 9:28pm UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/2 "2019-12-04T21:28:41Z")

</div>

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 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![showell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/showell/32/2647_2.png) [@showell](https://discourse.elm-lang.org/u/showell)\
**Post date:** [December 4, 2019, 9:51pm UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/3 "2019-12-04T21:51:23Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Viir](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/viir/32/4103_2.png) [@Viir](https://discourse.elm-lang.org/u/Viir)\
**Post date:** [December 5, 2019, 9:08am UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/4 "2019-12-05T09:08:57Z")

</div>

> [@showell](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![showell](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/showell/32/2647_2.png) [@showell](https://discourse.elm-lang.org/u/showell)\
**Post date:** [December 5, 2019, 10:39am UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/5 "2019-12-05T10:39:52Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [December 15, 2019, 10:39am UTC](https://discourse.elm-lang.org/t/elm-to-python-transpiler/4784/6 "2019-12-15T10:39:54Z")

</div>

Closed on December 15, 2019, 10:39am UTC

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