some progress

Author: thma

kiselyov.md

@@ -232,6 +232,7 @@ the previous example with two variables.
 Now the Kiselyov algorithms really start to shine. `compileEta` produces code is significantly smaller as the baseline. And `compileBulk` output is even smaller.
 
 
+
 ### The tak function
 
 ```haskell
@@ -255,13 +256,72 @@ main = tak 7 4 2
 
 In this example with four variables the trend continues. `compileEta` produces code is significantly smaller as the baseline. And `compileBulk` output now is only about 1/3 of the baseline.
 
+## Executing Bulk Combinators
+
+We have seen that Kisekyov's algorithms produce code that makes use of *Bulk Combinators* like `S4`, `B3` or `C2`. Ben Lynn defines the semantics of these combinators as follows:
+
+<img style="align:center;" src="https://latex.codecogs.com/svg.image?\begin{align*}B_{n&plus;1}&=B'B_n\\C_{n&plus;1}&=C'C_n\\S_{n&plus;1}&=S'S_n\end{align*}" />
+
+where `B'`, `C'` and `S'` defined as follows:
+
+<img style="align:center;" src="https://latex.codecogs.com/svg.image?\begin{align*}B'&=BB\\C'&=B(BC)B\\S'&=B(BS)B\end{align*}" />
+
+Ben also defines the following function that converts a combinator term with *Bulk Combinators* to a combinator term with only standard combinators:
+
+```haskell
+breakBulkLinear :: Combinator -> Int -> CL
+breakBulkLinear B n = iterate (comB' :@) (Com B) !! (n - 1)
+breakBulkLinear C n = iterate (comC' :@) (Com C) !! (n - 1)
+breakBulkLinear S n = iterate (comS' :@) (Com S) !! (n - 1)
+
+comB' :: CL
+comB' = Com B:@ Com B
+comC' :: CL
+comC' = Com B :@ (Com B :@ Com C) :@ Com B
+comS' :: CL
+comS' = Com B :@ (Com B :@ Com S) :@ Com B
+```
+
+As we have seen in the output of the `compileBulkLinear` this conversion expands the code size. To avoid this expansion of the combinator code I have implemented a solution to directly execute *Bulk Combinators*.
+
+At the moment I have only implemented it in the [Haskell-In-Haskell](https://wiki.haskell.org/wikiupload/0/0a/TMR-Issue10.pdf) inspired HHI-Reducer. Implementing it for the Graph Reduction Engine is left as an exercise for the reader ;-).
+
+```haskell
+-- | apply a CExpr of shape (CFun f) to argument x by evaluating (f x)
+infixl 0 !
+(!) :: CExpr -> CExpr -> CExpr
+(CFun f) ! x = f x
+
+-- | "link" a compiled expression into Haskell native functions.
+--   application terms will be transformed into real (!) applications
+--   combinator symbols will be replaced by their actual function definition
+link :: CombinatorDefinitions -> CExpr -> CExpr
+link definitions (CApp fun arg) = link definitions fun ! link definitions arg
+link definitions (CComb comb)   = case lookup comb definitions of
+                                    Nothing -> resolveBulk comb
+                                    Just e  -> e
+link _definitions expr          = expr
+
+
+resolveBulk :: Combinator -> CExpr
+resolveBulk (BulkCom "B" n) = iterate (comB' !) comB !! (n-1)
+resolveBulk (BulkCom "C" n) = iterate (comC' !) comC !! (n-1)
+resolveBulk (BulkCom "S" n) = iterate (comS' !) comS !! (n-1)
+
+comS :: CExpr
+comS = CFun (\f -> CFun $ \g -> CFun $ \x -> f!x!(g!x))                    -- S F G X = F X (G X)
+
+comS' :: CExpr
+comS' = CFun (\p -> CFun $ \q -> CFun $ \r -> CFun $ \s -> p!(q!s)!(r!s))  -- S' P Q R S = P (Q S) (R S)
+```
+
 
 ## performance comparison
 
 So far we have seen that for functions with more than two variables the Kiselyov algorithms generate code that is significantly smaller than optimized versions of classic bracket abstraction. 
 But what about performance? Is the code generated by the Kiselyov algorithms also faster?
 
-To answer this question i have implemented a simple benchmarking suite based on the [micro-benchmarking framework Criterion](http://www.serpentine.com/criterion/). 
+To answer this question I have set up a benchmarking suite based on the [micro-benchmarking framework Criterion](http://www.serpentine.com/criterion/). 
 
 In my suite I am testing the performance of combinations of the following components: