| ... |
... |
@@ -108,8 +108,55 @@ import GHC.Builtin.Types.Prim |
|
108
|
108
|
smallArrayPrimTyCon,
|
|
109
|
109
|
smallMutableArrayPrimTyCon )
|
|
110
|
110
|
|
|
|
111
|
+-- This is a newtype because it is important to distinguish it from Type which
|
|
|
112
|
+-- Kind is otherwise equal to.
|
|
|
113
|
+-- See Note [Kinds in STG]
|
|
111
|
114
|
newtype StgKind = MkStgKind { getStgKind :: Kind }
|
|
112
|
115
|
|
|
|
116
|
+{-
|
|
|
117
|
+Note [Kinds in STG]
|
|
|
118
|
+~~~~~~~~~~~~~~~~~~~
|
|
|
119
|
+
|
|
|
120
|
+Whereas Core is type-annotated, STG is kind-annotated.
|
|
|
121
|
+
|
|
|
122
|
+Just as many different values may have a single type, so many different
|
|
|
123
|
+types may have a single kind. So kinds are a "coarser approximation" to the
|
|
|
124
|
+values being manipulated; and that is what we want in STG.
|
|
|
125
|
+
|
|
|
126
|
+There are two reasons for this:
|
|
|
127
|
+
|
|
|
128
|
+(1) It is easier for third party projects to compile to STG. The type system of
|
|
|
129
|
+ another language might not be compatible with GHC's type system. In such a
|
|
|
130
|
+ case the kind system is often still compatible because it is so much coarser.
|
|
|
131
|
+ Example projects are Jaro Reinders' agda2stg and Csaba Hruska's external-stg.
|
|
|
132
|
+
|
|
|
133
|
+(2) It allows for more aggressive optimizations. In STG we may do
|
|
|
134
|
+ type-incorrect things that are kind-correct. For example consider
|
|
|
135
|
+ the following function:
|
|
|
136
|
+
|
|
|
137
|
+ f :: Either a b -> Either a c
|
|
|
138
|
+ f = \x -> case x of r
|
|
|
139
|
+ Left x -> Left x
|
|
|
140
|
+ Right _ -> error "urk"
|
|
|
141
|
+
|
|
|
142
|
+ We would want to avoid reallocating the 'Left' constructor:
|
|
|
143
|
+
|
|
|
144
|
+ f :: Either a b -> Either a c
|
|
|
145
|
+ f = \x -> case x of r
|
|
|
146
|
+ Left _ -> r <------------- NB
|
|
|
147
|
+ Right _ -> error "urk"
|
|
|
148
|
+
|
|
|
149
|
+ This is not type-safe in Core, but it is kind-safe in STG. So, using
|
|
|
150
|
+ the coarser notion of kinds in STG allows us to do more aggressive
|
|
|
151
|
+ optimizations. Note, however, that we do not implement any such
|
|
|
152
|
+ optimizations yet.
|
|
|
153
|
+
|
|
|
154
|
+Note that the kinds do not always accurately reflect the final runtime
|
|
|
155
|
+representation. For example, on the JS backend the kind 'TYPE Int64Rep'
|
|
|
156
|
+might eventually be rewritten to 'TYPE (TupleRep [Int32Rep,Int32Rep])'
|
|
|
157
|
+because there is no 64 bit integer type in JS.
|
|
|
158
|
+-}
|
|
|
159
|
+
|
|
113
|
160
|
{-
|
|
114
|
161
|
************************************************************************
|
|
115
|
162
|
* *
|