At Knipster, I write Javascript, JSX, Elm, Java, Objective C, Groovy, and Bash on a daily basis. The only language which makes me code in a joyful state of mind is Elm.
Nonetheless, it comes with two issues which are not well documented and which can ruin your day if you don’t know them. It is worth noting that those are known compiler’s bug rather than language’s flaws.
#1 Name shadowing
Due to a compiler’s bug, the variable shadowing in an inner scope won’t be caught and can cause runtime exceptions.
See this example on Ellie:
In the above code, the variable newModel at line 40 is not defined. It compiles but fails at runtime with Uncaught TypeError: Cannot read property 'name' of undefined.
Here’s the offending code:
|
1 2 3 4 5 6 7 |
newModel = doAnUpdate "one" { name = "zero" } |> (\updatedModel -> -- it compiles, but `newModel` -- is undefined here! doAnUpdate "two" newModel ) |
It is remarkable that the compiler correctly warns you against a simpler recursive type, like in:
|
1 2 |
newModel = doAnUpdate "one" newModel |
Which gives:
|
1 2 3 |
BAD RECURSION Line 17, Column 9 newModel is defined directly in terms of itself, causing an infinite loop. |
#2 Reserved JS words are aliased in records
This a subtle yet very annoying bug since it affects Javascript interoperability. It has been already reported on Github.
Try to run the following example on Ellie:
The Model has a field named static, and that’s the way we use it inside Elm. We can update and read it without problems.
But what happens if we send it through a port?
The static field became $static! It means that whatever I’m going to do on the JS side of the application, I’ll get undefined when trying to access a field which was guaranteed to be always a string.
Share your thoughts