git.iko.soy/elk
on master help sign in
Fix some typos
55a65a1Evan Czaplicki
compiler/src/Reporting/Error/Canonicalize.hs+1−1
compare with master
unifiedsplit
@@ -410,7 +410,7 @@ toReport source err =
410 ,
410 ,
411 case map H.text suggestions of
411 case map H.text suggestions of
412 [] ->
412 [] ->
413− "I cannot find an super similar exposed names. Maybe it is private?"
413+ "I cannot find any super similar exposed names. Maybe it is private?"
414
414
415 [alt] ->
415 [alt] ->
416 H.fillSep ["Maybe","you","want",H.dullyellow alt,"instead?"]
416 H.fillSep ["Maybe","you","want",H.dullyellow alt,"instead?"]
compiler/src/Reporting/Error/Type.hs+1−1
@@ -658,7 +658,7 @@ toExprReport source localizer exprRegion category tipe expected =
658 H.reflow $
658 H.reflow $
659 case subContext of
659 case subContext of
660 TypedIfBranch index ->
660 TypedIfBranch index ->
661− "Something is off with the " <> H.ordinalize (Index.toHuman index) <> " branch of this `if` experssion:"
661+ "Something is off with the " <> H.ordinalize (Index.toHuman index) <> " branch of this `if` expression:"
662
662
663 TypedCaseBranch index ->
663 TypedCaseBranch index ->
664 "Something is off with the " <> H.ordinalize (Index.toHuman index) <> " branch of this `case` expression:"
664 "Something is off with the " <> H.ordinalize (Index.toHuman index) <> " branch of this `case` expression:"
docs/hints/implicit-casts.md+1−1
@@ -37,7 +37,7 @@ For decades, the problem was that nobody could figure out how to combine type in
37
37
38So for any ML-family language designed before Scala, it is safe to assume that implicit conversions just was not an option. Okay, but what about Elm?! It comes after Scala, so why not do it like them?!
38So for any ML-family language designed before Scala, it is safe to assume that implicit conversions just was not an option. Okay, but what about Elm?! It comes after Scala, so why not do it like them?!
39
39
40− 1. You pay performance cost to mix to mix type inference and implicit conversions. At least as far as anyone knows, it defeats an optimization that is crucial to getting _reliably_ good performance. It is fine in most cases, but it can be a real issue in very large code bases.
40+ 1. You pay performance cost to mix type inference and implicit conversions. At least as far as anyone knows, it defeats an optimization that is crucial to getting _reliably_ good performance. It is fine in most cases, but it can be a real issue in very large code bases.
41
41
42 2. Based on experience reports from Scala users, it seemed like the convenience was not worth the hidden cost. Yes, you can convert `n` in `(n + 1.5)` and everything is nice, but when you are in larger programs that are sparsely annotated, it can be quite difficult to figure out what is going on.
42 2. Based on experience reports from Scala users, it seemed like the convenience was not worth the hidden cost. Yes, you can convert `n` in `(n + 1.5)` and everything is nice, but when you are in larger programs that are sparsely annotated, it can be quite difficult to figure out what is going on.
43
43