55a65a1 · elk · git.iko.soy

git.iko.soy/elk

Fix some typos

Fix https://github.com/elm-lang/elm-compiler/issues/1677 Fix https://github.com/elm-lang/elm-compiler/issues/1675 Fix https://github.com/elm-lang/elm-compiler/issues/1674 Thanks @mfeineis!

commit55a65a190750671f8ec3dc455855a6d6554f96ec authorEvan Czaplicki <evancz@users.noreply.github.com> dateTue 6 Mar 2018, 14:40 (9 years ago) parent70cedd3

3 files changed+3−3

compare with master

unifiedsplit

compiler/src/Reporting/Error/Canonicalize.hs+1−1 compiler/src/Reporting/Error/Type.hs+1−1 docs/hints/implicit-casts.md+1−1

compiler/src/Reporting/Error/Canonicalize.hs+1−1

@@ -410,7 +410,7 @@ toReport source err =

410410 ,

411411 case map H.text suggestions of

412412 [] ->

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?"

414414

415415 [alt] ->

416416 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 =

658658 H.reflow $

659659 case subContext of

660660 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:"

662662

663663 TypedCaseBranch index ->

664664 "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

3737

3838So 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?!

3939

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.

4141

4242 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.

4343