Following on from yesterday I think there are various other ways in which a compile-time elm-to-elm optimiser could improve the performance of Javascript code output by the Elm compiler. It goes without saying that this does not necessarily have to be done as a separate tool, it could easily be incorporated into the Elm compiler itself. It is just potentially a lower barrier for entry to do it the separate tool way. It’s also a little easier to describe. ...
In certain circles in the Elm community it is seen as more ‘Elmish’, that is more idiomatic, or more desirable to write code using functions to combine/inspect common datatypes. So this code: Maybe.withDefault 0 mInt is more desirable than the following code which uses a case expression to achieve the same end: case mInt of Nothing -> 0 Just x -> x One question that arises, is does one compile to more efficient code? Let’s test this, we can easily write the following into an elm file and compile with optimisation turned on: ...
Elm has followed many other languages in equating a file to some form of encapsulation unit, in the case of Elm this is a module, much like it is in Haskell, Java used a class. In Java it is possible to define a nested class, and in most forms of the ML family of languages (SML, O’caml) you can define nested modules. In particular there is no reason why a single file need define one and only one module. ...