Please try them out and let me know if you run into anything odd! There should be no observable changes from 0.19.1 or 0.19.2. Maybe a little faster.
The goal of putting out these pre-release binaries is so that we can find any little mistakes before Monday. I was sad that there was a little row/column issue in 0.19.2 that I missed, so hopefully we can find anything like that!
I have a blog post written about it, and I plan to publish it next week, ideally on Monday. The point of 0.19.3 is to get us to the “precise primitives” part of the feature map, and unlock the two pathways needed for “Acadia alignment”.
Can I ask what’s planned in the “improved type inference” item on the left side of the graph?
Why: We’re currently working with Jeroen on (me: unblocking via a type inference library, Jeroen: actually implementing) an elm-review autofix for missing type annotations, and we’ve hit (details) one of the rank = N bugs. Would be nice to know whether to sidestep the bug (eg. by making the autofix all-or-nothing for a given top-level declaration) or whether waiting for a compiler fix would make sense.
Might be worth trying this against the typechecker of Guida - previously I have seen it correctly type similar things where Elm compiler either inferred the wrong type or crashed on rank = N.
The improved type inference is focused on speed and quality of record error messages, so I would not expect it to change the [rank = N] cases.
I believe some of the [rank = N] issues are caused by adding annotations to inner let expressions but not the outer declaration. There is something in how rigid type variables are shared in such cases.
I do not think that’s 100% of cases though, and although some people have suggested techniques that are explicitly recommended against by the designer of the algorithm, I have not yet seen a “correct” identification of the root cause in these other cases.
This may be of interest, although it really needs to be extracted into an SSCCE and examined more carefully. But this is the one piece of code that I know of, which is mistyped, but does not fail type checking by the Elm compiler. The guida compiler does detect the mistyping. So it strongly suggests that this is a test case for a real typing bug in the Elm compiler.
Not sure exactly if its even related to rank=N, I just have a suspicion it might be. But more confident that it does at least indicate some bug in inference. The reason I am not more certain is that the type checker is conceptually quite hard to understand, and the way the code is optimized with translation into a set of constraints and a solver makes it even harder to grasp. So it needs your level of genius, Evan.
Funny thing is, that @deciojf managed to fix this bug whilst translating the code from Haskell to Elm, but I believe he did so without meaning to. It was a mistranslation error that yielded the bug fix!
module Main exposing (main)
import Html
f b =
g b
g b =
if b then
let
n =
f False
in
Just (String.toUpper n)
else
Nothing
main =
Html.text (Maybe.withDefault "" (f True))
If we inline n, instead of defining it in the let block, the compiler does catch the typing error. This is what makes me think its related to rank=N, because it needs un-annotated value in a let block to get the error:
g b =
if b then
Just (String.toUpper (f False))
else
Nothing
I just put up a fresh batch of binaries. There was a little bug with the new cycle error messages that @jfmengels found, and it should be fixed in the latest binaries.
