You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/_posts/2016-02-03-essence-of-scala.md
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -56,7 +56,7 @@ types `T` to terms `t` and formal _evaluation rules_ that describe how a
56
56
program is evaluated. The main difference between the Wadlerfest paper
57
57
and the prior technical report lies in the form of these evaluation
58
58
rules. The technical report uses a "big step" semantics, i.e. it
59
-
defines an abstract of interpreter that explains how terms map to
59
+
defines an interpreter that explains how terms map to
60
60
values. The Wadlerfest paper uses a more common "small step"
61
61
semantics, i.e. it explains evaluation as step-wise rewritings of
62
62
terms. To do this, it needs to restrict terms to be in [A-normal
@@ -78,8 +78,8 @@ you can have conflicting definitions. For instance you might have an abstract
78
78
type declaration in a base class with two conflicting aliases in subclasses:
79
79
80
80
trait Base { type A }
81
-
trait Sub1 { type A = String }
82
-
trait Sub2 { type A = Int }
81
+
trait Sub1 extends Base { type A = String }
82
+
trait Sub2 extends Base { type A = Int }
83
83
84
84
Now, if you combine `Sub1` and `Sub2` in one class, you get a conflict, since the type `A` is supposed to be equal to both `String` and `Int`. If you do
85
85
not detect the conflict and assume the equalities at face value you
@@ -92,7 +92,7 @@ Now, the problem is that one cannot always detect these
92
92
inconsistencies, at least not by a local analysis that does not need
93
93
to look at the whole program. What's worse, once you have an
94
94
inconsistent set of definitions you can use these definitions to
95
-
"prove" their own consistency - much like an mathematical theory that
95
+
"prove" their own consistency - much like a mathematical theory that
96
96
assumes `true = false` can "prove" every proposition including its own
97
97
correctness.
98
98
@@ -149,5 +149,5 @@ project are important.
149
149
This lets us put other constructs of the Scala language to the test,
150
150
either to increase our confidence that they are indeed sound, or
151
151
to show that they are unsound. In my next blog I will
152
-
present some of the things we have discovered by that exercise.
152
+
present some of the issues we have discovered by that exercise.
0 commit comments