| ... |
... |
@@ -2206,10 +2206,10 @@ demand, used for signature inference. Therefore we place a top demand on all |
|
2206
|
2206
|
arguments.
|
|
2207
|
2207
|
|
|
2208
|
2208
|
For example, the demand transformer described by the demand signature
|
|
2209
|
|
- DmdSig (DmdType {x -> <1L>} <A><1P(L,L)>)
|
|
|
2209
|
+ DmdSig (DmdType <A><1P(L,L)>{x->1L})
|
|
2210
|
2210
|
says that when the function is applied to two arguments, it
|
|
2211
|
|
-unleashes demand 1L on the free var x, A on the first arg,
|
|
2212
|
|
-and 1P(L,L) on the second.
|
|
|
2211
|
+unleashes demand A on the first arg, 1P(L,L) on the second,
|
|
|
2212
|
+and 1L on the free var x.
|
|
2213
|
2213
|
|
|
2214
|
2214
|
If this same function is applied to one arg, all we can say is that it
|
|
2215
|
2215
|
uses x with 1L, and its arg with demand 1P(L,L).
|
| ... |
... |
@@ -2229,10 +2229,10 @@ was evaluated. Here's an example: |
|
2229
|
2229
|
|
|
2230
|
2230
|
The abstract transformer (let's call it F_e) of the if expression (let's
|
|
2231
|
2231
|
call it e) would transform an incoming (undersaturated!) head sub-demand A
|
|
2232
|
|
-into a demand type like {x-><1L>,y-><L>}<L>. In pictures:
|
|
|
2232
|
+into a demand type like <L>{x->1L,y->L}. In pictures:
|
|
2233
|
2233
|
|
|
2234
|
2234
|
SubDemand ---F_e---> DmdType
|
|
2235
|
|
- <A> {x-><1L>,y-><L>}<L>
|
|
|
2235
|
+ <A> <L>{x->1L,y->L}
|
|
2236
|
2236
|
|
|
2237
|
2237
|
Let's assume that the demand transformers we compute for an expression are
|
|
2238
|
2238
|
correct wrt. to some concrete semantics for Core. How do demand signatures fit
|
| ... |
... |
@@ -2240,7 +2240,7 @@ in? They are strange beasts, given that they come with strict rules when to |
|
2240
|
2240
|
it's sound to unleash them.
|
|
2241
|
2241
|
|
|
2242
|
2242
|
Fortunately, we can formalise the rules with Galois connections. Consider
|
|
2243
|
|
-f's strictness signature, {}<1L><L>. It's a single-point approximation of
|
|
|
2243
|
+f's strictness signature, <1L><L>. It's a single-point approximation of
|
|
2244
|
2244
|
the actual abstract transformer of f's RHS for arity 2. So, what happens is that
|
|
2245
|
2245
|
we abstract *once more* from the abstract domain we already are in, replacing
|
|
2246
|
2246
|
the incoming Demand by a simple lattice with two elements denoting incoming
|
| ... |
... |
@@ -2260,8 +2260,8 @@ With |
|
2260
|
2260
|
and F_f being the abstract transformer of f's RHS and f_f being the abstracted
|
|
2261
|
2261
|
abstract transformer computable from our demand signature simply by
|
|
2262
|
2262
|
|
|
2263
|
|
- f_f(>=2) = {}<1L><L>
|
|
2264
|
|
- f_f(<2) = multDmdType C_0N {}<1L><L>
|
|
|
2263
|
+ f_f(>=2) = <1L><L>
|
|
|
2264
|
+ f_f(<2) = multDmdType C_0N <1L><L>
|
|
2265
|
2265
|
|
|
2266
|
2266
|
where multDmdType makes a proper top element out of the given demand type.
|
|
2267
|
2267
|
|