Issue #20 - special about Elm

Say what? An Elm newsletter with a special issue about... Elm? Yes, but hang with me just for a minute. I am not going to talk to you about things that Elm guide or Elm programming have written about. This issue is more about the internals of Elm or lower-level programming and API design. I think this is a fascinating topic that some people have covered.

Out of curiosity and to learn new tricks, I always look at the source code for the core library of the languages I work with, be it Elm, Python, or Go. You can learn pretty interesting things, just take a look at the source code for the Elm's String package.

Let's start with some of the detective work on Elm Runtime done by Harry Sarson:

Elm Runtime representation

In his words, the elm runtime must do three things: detect external, asynchronous events, inform the elm application about these detected events by passing it information describing the event, and perform actions as requested by the elm application. In response to that, Elm application must: update its state, instruct the runtime to perform actions, inform the runtime about which asynchronous events it should be detecting. He then goes on to research and explain what the elm/core:Elm.Kernel.Platform.initialize function does behind the scenes.

I do not have any experience with Web Assembly, but reading Brian Carroll's post about what it might take to compile Elm to Web Assembly instead of JS. Even though it is not happening in the near future, Brian takes some time to explain why. Elm has some advanced features: "they behave like values, they can be partially applied, and they can capture values from outer scopes" which are not directly available in Web Assembly. It does, however, provide some foundations to build these. Elm functions can be represented using Web Assembly functions and data structures which gets passed around the program, keeping track of partially-applied  arguments and closed-over values. It also contains the table index of  the evaluator function, which is what will eventually produce a return value. If you're keen to help or learn from the project, the code is available on Github.

Robin Heggelund Hansen has written a 5-part series on removing a List datastructure from Elm and substituting it with an Array. In the first part he explains the shortcomings of the List and some of the current problems with Array. The second part goes into the ways one can improve the shortcomings of the Array and how it can be made faster. Third part of the series talks how the Array can be made more extensible, and shows the implementation of the find function. The comparison results are questionable at the first glance and the List is still faster. But that is just an edge case. Part four is my favourite one because it talks about the API design: how you can design common API to share between different datastructures like List, Set, and Array. The fifth part talks how making the Array a default collection could reduce overhead and improve the performance. In the end Robin gives a nice overview of his work and what it might take to improve the Array.

In #issue 9 I have mentioned Julian Antonielly and his insightful post about the way core libraries are implemented. He talks about native code and goes deep into effect managers.

I encourage you to open Elm's source code and start exploring. It contains a lot of gems and would help you write better programs when you learn how certain things are done behind the scenes.

Quote of the week

A quote from Douglas Adams fits perfectly for this issue:

I think a nerd is a person who uses the telephone to talk to other  people about telephones. And a computer nerd therefore is somebody who  uses a computer in order to use a computer.
Show Comments