8639484 · lynxjs-elm/compiler

git.iko.soy/lynxjs-elm/compiler

Merge pull request #1991 from jfmengels/typo-fixing

Typo fixing in the hint documents

commit86394845e215ff019b4c6a5d8420998e7eb04887 authorEvan Czaplicki <evancz@users.noreply.github.com> dateMon 28 Oct 2019, 12:57 (7 years ago) parent7a32a3a 678fc8e

7 files changed+10−12

compare with master

unifiedsplit

hints/bad-recursion.md+1−1 hints/comparing-custom-types.md+1−1 hints/comparing-records.md+3−3 hints/implicit-casts.md+1−1 hints/import-cycles.md+1−1 hints/recursive-alias.md+2−2 hints/type-annotations.md+1−3

hints/bad-recursion.md+1−1

@@ -10,7 +10,7 @@ There are two problems that will lead you here, both of them pretty tricky:

1010

1111## No Mutation

1212

13−Languages like JavaScript let you “reassign” variables. When you say `x = x + 1` it means: whatever `x` was pointing to, have it point to `x + 1` instead. This called *mutating* a variable. All values are immutable in Elm, so reassigning variables does not make any sense! Okay, so what *should* `x = x + 1` mean in Elm?

13+Languages like JavaScript let you “reassign” variables. When you say `x = x + 1` it means: whatever `x` was pointing to, have it point to `x + 1` instead. This is called *mutating* a variable. All values are immutable in Elm, so reassigning variables does not make any sense! Okay, so what *should* `x = x + 1` mean in Elm?

1414

1515Well, what does it mean with functions? In Elm, we write recursive functions like this:

1616

hints/comparing-custom-types.md+1−1

@@ -54,7 +54,7 @@ add info (Table nextId dict) =

5454 )

5555```

5656

57−There are a couple nice thing about this approach:

57+There are a couple nice things about this approach:

5858

59591. The only way to get a new `User.Id` is to `add` information to a `User.Table`.

60602. All the operations on a `User.Table` are explicit. Does it make sense to remove users? To merge two tables together? Are there any special details to consider in those cases? This will always be captured explicitly in the interface of the `User` module.

hints/comparing-records.md+3−3

@@ -7,7 +7,7 @@ This page aims to catalog these scenarios and offer alternative paths that can g

88## Sorting Records

10−Say we want a `view` function that can show a list of students sorted by different characterists.

10+Say we want a `view` function that can show a list of students sorted by different characteristics.

1111

1212We could create something like this:

1313

@@ -23,7 +23,7 @@ type alias Student =

2323type Order = Name | Age | GPA

2424

2525viewStudents : Order -> List Student -> Html msg

26−viewStudents order studentns =

26+viewStudents order students =

2727 let

2828 orderlyStudents =

2929 case order of

@@ -54,7 +54,7 @@ type alias Student =

5454 }

5555

5656viewStudents : Order -> List Student -> Html msg

57−viewStudents order studentns =

57+viewStudents order students =

5858 let

5959 orderlyStudents =

6060 case order of

hints/implicit-casts.md+1−1

@@ -41,7 +41,7 @@ So for any ML-family language designed before Scala, it is safe to assume that i

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

44−This user data may be confounded by the fact that Scala allows quite extensive conversions, not just from `Int` to `Float`, but I think it is worth taking seriously nonetheless. So it is _possible_, but it is has tradeoffs.

44+This user data may be confounded by the fact that Scala allows quite extensive conversions, not just from `Int` to `Float`, but I think it is worth taking seriously nonetheless. So it is _possible_, but it has tradeoffs.

4545

4646

4747## Conclusion

hints/import-cycles.md+1−1

@@ -55,7 +55,7 @@ type alias User =

5555 }

5656```

5757

58−Notice that the `Comment` type alias is defined in terms of the `User` type alias and vice versa. Having recursive type aliases like this does not work! That problem is described in depth [here](recursive-alias), but the quick takeaway is that one `type alias` needs to become a `type` to break the recursion. So let’s try again:

58+Notice that the `Comment` type alias is defined in terms of the `User` type alias and vice versa. Having recursive type aliases like this does not work! That problem is described in depth [here](recursive-alias.md), but the quick takeaway is that one `type alias` needs to become a `type` to break the recursion. So let’s try again:

5959

6060```elm

6161module BadCombination2 exposing (..)

hints/recursive-alias.md+2−2

@@ -39,7 +39,7 @@ It is much easier to write down `Person` in a type, and then it will just expand

3939

4040## Recursive type aliases?

4141

42−Okay, so lets say you have some type that may contain itself. In Elm, a common example of this is a comment that might have subcomments:

42+Okay, so let's say you have some type that may contain itself. In Elm, a common example of this is a comment that might have subcomments:

4343

4444```elm

4545type alias Comment =

@@ -102,7 +102,7 @@ type Comment =

102102 }

103103```

104104

105−Now lets say you want to register an upvote on a comment:

105+Now let's say you want to register an upvote on a comment:

106106

107107```elm

108108upvote : Comment -> Comment

hints/type-annotations.md+1−3

@@ -8,7 +8,7 @@ This document is going to outline the various things that can go wrong and show

99## Annotation vs. Definition

1010

11−The most common issue is with user-defined type variables that are too general. So lets say you have defined a function like this:

11+The most common issue is with user-defined type variables that are too general. So let's say you have defined a function like this:

1212

1313```elm

1414addPair : (a, a) -> a

@@ -58,5 +58,3 @@ filter isOkay list =

5858This case is very unfortunate because all the type annotations are correct, but there is a detail of how type inference works right now that **user-defined type variables are not shared between annotations**. This can lead to probably the worst type error messages we have because the problem here is that `a` in the outer annotation does not equal `a` in the inner annotation.

5959

6060For now the best route is to leave off the inner annotation. It is unfortunate, and hopefully we will be able to do a nicer thing in future releases.

61−

62−"""