| ... |
... |
@@ -14,7 +14,7 @@ generation. |
|
14
|
14
|
-}
|
|
15
|
15
|
|
|
16
|
16
|
module GHC.Stg.Syntax (
|
|
17
|
|
- StgKind(getStgKind), typeStgKind, stgKindPrimRep, stgKindPrimRep1,
|
|
|
17
|
+ StgKind(getStgKind), typeStgKind, stgKindPrimRep, stgKindPrimRep1,
|
|
18
|
18
|
stgKindPrimRepU, isUnboxedTupleStgKind, isLiftedTypeStgKind,
|
|
19
|
19
|
|
|
20
|
20
|
StgFArgType(..),
|
| ... |
... |
@@ -81,12 +81,12 @@ import GHC.Types.CostCentre ( CostCentreStack ) |
|
81
|
81
|
import GHC.Core ( AltCon )
|
|
82
|
82
|
import GHC.Core.DataCon
|
|
83
|
83
|
import GHC.Core.TyCon ( PrimRep(..), PrimOrVoidRep(..), TyCon )
|
|
84
|
|
-import GHC.Core.Type
|
|
85
|
|
- ( Type,
|
|
86
|
|
- tyConAppTyCon,
|
|
87
|
|
- typeKind,
|
|
88
|
|
- isUnboxedTupleKind,
|
|
89
|
|
- kindRep_maybe,
|
|
|
84
|
+import GHC.Core.Type
|
|
|
85
|
+ ( Type,
|
|
|
86
|
+ tyConAppTyCon,
|
|
|
87
|
+ typeKind,
|
|
|
88
|
+ isUnboxedTupleKind,
|
|
|
89
|
+ kindRep_maybe,
|
|
90
|
90
|
isLiftedRuntimeRep )
|
|
91
|
91
|
import GHC.Core.Ppr( {- instances -} )
|
|
92
|
92
|
|
| ... |
... |
@@ -95,11 +95,11 @@ import GHC.Types.Id |
|
95
|
95
|
import GHC.Types.Tickish ( StgTickish )
|
|
96
|
96
|
import GHC.Types.Var.Set
|
|
97
|
97
|
import GHC.Types.Literal ( Literal, literalType )
|
|
98
|
|
-import GHC.Types.RepType
|
|
99
|
|
- ( typePrimRep,
|
|
100
|
|
- typePrimRep1,
|
|
101
|
|
- typePrimRepU,
|
|
102
|
|
- typePrimRep_maybe,
|
|
|
98
|
+import GHC.Types.RepType
|
|
|
99
|
+ ( typePrimRep,
|
|
|
100
|
+ typePrimRep1,
|
|
|
101
|
+ typePrimRepU,
|
|
|
102
|
+ typePrimRep_maybe,
|
|
103
|
103
|
kindPrimRep,
|
|
104
|
104
|
kindPrimRep1,
|
|
105
|
105
|
kindPrimRep_maybe,
|
| ... |
... |
@@ -169,7 +169,7 @@ There are two reasons for wanting a coarser type system: |
|
169
|
169
|
another language might not be compatible with GHC's type system. In such a
|
|
170
|
170
|
case the kind system is often still compatible because it is so much coarser.
|
|
171
|
171
|
Examples of such projects are:
|
|
172
|
|
-
|
|
|
172
|
+
|
|
173
|
173
|
- agda2stg: https://github.com/noughtmare/agda2stg
|
|
174
|
174
|
- external-stg-interpreter: https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter
|
|
175
|
175
|
|
| ... |
... |
@@ -189,7 +189,7 @@ There are two reasons for wanting a coarser type system: |
|
189
|
189
|
Left _ -> r <------------- NB
|
|
190
|
190
|
Right _ -> error "urk"
|
|
191
|
191
|
|
|
192
|
|
- See Note [Case 2: CSEing case binders] for the full details of this
|
|
|
192
|
+ See Note [Case 2: CSEing case binders] for the full details of this
|
|
193
|
193
|
optimization.
|
|
194
|
194
|
|
|
195
|
195
|
This is not type-safe in Core, but it is kind-safe in STG. So, using
|
| ... |
... |
@@ -200,6 +200,23 @@ Note that the kinds do not always accurately reflect the final runtime |
|
200
|
200
|
representation. For example, on the JS backend the kind 'TYPE Int64Rep'
|
|
201
|
201
|
might eventually be rewritten to 'TYPE (TupleRep [Int32Rep,Int32Rep])'
|
|
202
|
202
|
because there is no 64 bit integer type in JS.
|
|
|
203
|
+
|
|
|
204
|
+Consequences:
|
|
|
205
|
+
|
|
|
206
|
+* STG Lint checks for kind-correctness, not type-correctness.
|
|
|
207
|
+
|
|
|
208
|
+ - In an appplication, check that that kind of the argument matches the kind expected by the function
|
|
|
209
|
+ - In a let-binding check that the kind of the binder matches the kind of the RHS.
|
|
|
210
|
+ - etc
|
|
|
211
|
+
|
|
|
212
|
+ (It would be good to check these claims are true of STG Lint!)
|
|
|
213
|
+
|
|
|
214
|
+* In practice, each Id still contains its Type; but only the Kind of that type is used in STG onwards.
|
|
|
215
|
+ Some places still use DataCon which also still contains a reference to its type.
|
|
|
216
|
+
|
|
|
217
|
+* We define a newtype StgKind to distinguish it from Type which Kind is otherwise equal to.
|
|
|
218
|
+
|
|
|
219
|
+* What else?
|
|
203
|
220
|
-}
|
|
204
|
221
|
|
|
205
|
222
|
{-
|