This is a patch release. Everything is the same, just slightly better!
The main changes are:
import Dom | |
import Dom.Scroll | |
import Html exposing (..) | |
import Html.App as App | |
import Html.Attributes exposing (..) | |
import Html.Events exposing (..) | |
import Process | |
import Task | |
import WebSocket |
Result of running these benchmarks on Chrome 45.0.2454.101
These numbers seem to be pretty consistent on Blink-based browsers (Chrome and Opera) but are more like 20% to 50% improvements on FireFox, Safari, and IE. I am not sure how to explain that, so take these numbers more as an indicator of “Elm is generating faster code across the board” as opposed to “Elm is 10x faster!”
Here is one of the changes I needed to make in package.elm-lang.org.
The issue was that the code was relying on linkQualified
to always get a non-empty string as the token
argument. While it is true that that will happen for the foreseeable future, I took this as an opportunity to do a more serious refactor so that the code was nicer and if it ever breaks in the future it will give me a very specific message.
linkQualified : List String -> String -> Text.Text
linkQualified modules token =
case List.reverse (String.split "." token) of
I personally like to have discussions in the spirit of the Socratic method. Instead of declaring my opinion, I ask a relevant question. How about this situation? What about this case? This has two possible outcomes.
In both cases, it could have been a conflict, egos crashing together. But by asking questions, it becomes a collaboration to find the best answer. Even the simple act of asking a question in the first place says, "I care what you have to say, we can agree on this." That said, I have noticed that it is definitely still possible for things to go wrong within this framework. How can this happen?
There was a passage from [The
import Window | |
import Color | |
floatify : (Int,Int) -> (Float,Float) | |
floatify (x,y) = | |
(toFloat x, toFloat y) | |
scene (w,h) = | |
flow down | |
[ container (floor w) (floor (h / 2)) middle (asText "blue") |
If Elm community is going to begin referring to "union types" instead of "algebraic data types" we should think about how that will work in practice. What discussions will we have? Will we find ourselves in awkward spots trying to explain things?
The following question/answer pairs simulate things I'd expect to see in a world of "union types". The pairs are grouped by what background I expect the questions to come from so we know the subtext. I have also added some meta comments in italic to explain my phrasing.
One thing to consider is that a lot of learners will not have a person to ask, so the path to arriving at these answers needs to be easy if you are just searching online.
Theme: exploring and using elm-html
I want us to make some cool stuff together. First, I think it will be fun, but I think we may begin to learn interesting ways to improve and extend elm-html so that we can all be more productive.
Goal: a consistent style throughout all Elm projects that is easy to read and produces clean diffs to make debugging easier. This means valuing regularity and simplicity over cleverness.
Keep it under 80 characters. Going over is not the end of the world, but consider refactoring before you decide a line really must be longer.
With the upcoming improvements to elm-server
and elm-get
, it is becoming clear that the names of the various command line tools do not actually match what they do. This is a proposal of how to sort this out.
I propose that the typical workflow will include the following tools:
elm-repl
- exactly the same as beforeelm-reactor
- combination of elm-server
and the debugger