@@ -38,7 +38,7 @@ for full-spectrum dependent types.
38
38
39
39
Scala's semantics have up until now been richer than its syntax. The only singleton types which are
40
40
currently _ directly_ expressible are those of the form ` p.type ` where ` p ` is a path pointing to a
41
- value of some subtype of ` AnyRef ` . Interally the Scala compiler also represents singleton types for
41
+ value of some subtype of ` AnyRef ` . Internally the Scala compiler also represents singleton types for
42
42
individual values of subtypes of ` AnyVal ` , such as ` Int ` or values of type ` String ` which don't
43
43
correspond to paths. These types are inferred in some circumstances, notably as the types of ` final `
44
44
vals. Their primary purpose has been to represent compile time constants (see [ 6.24 Constant
@@ -49,13 +49,13 @@ The types here correspond to _literal_ values (ie. values which programmers can
49
49
terms, see [ 1.3
50
50
Literals] ( http://scala-lang.org/files/archive/spec/2.12/01-lexical-syntax.html#literals ) ) such as
51
51
` 23 ` , ` true ` or ` "foo" ` of the larger non-singleton types they inhabit (` Int ` , ` Boolean ` or ` String `
52
- respectively). However, there is no suface syntax to express these types.
52
+ respectively). However, there is no surface syntax to express these types.
53
53
54
54
As we will see in the motivation section of the proposal below, singleton types corresponding to
55
55
literal values (henceforth _ literal types_ ) have many important uses and are already widely used in
56
56
many important Scala libraries. The lack of first class syntax for literal types has forced library
57
57
authors to use the experimental Scala macro system to provide a means to express them. Whilst this
58
- has proved to be extremely successful, it has poor ergonimics (although this can typically be hidden
58
+ has proved to be extremely successful, it has poor ergonomics (although this can typically be hidden
59
59
from library _ users_ ) and is not portable -- because Scala macros in general and the mechanisms used
60
60
to expose literal types to Scala programmes in particular depend on internal implementation details
61
61
of the current Scala compiler.
0 commit comments