From 8368283a3ecfdee8669481aef61ecb30ce167fae Mon Sep 17 00:00:00 2001 From: Danila Fedorin Date: Sat, 15 Aug 2020 01:37:57 -0700 Subject: [PATCH] Add warning about evaluation model. --- content/blog/haskell_lazy_evaluation/index.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/content/blog/haskell_lazy_evaluation/index.md b/content/blog/haskell_lazy_evaluation/index.md index 5e2ba6f..040d95a 100644 --- a/content/blog/haskell_lazy_evaluation/index.md +++ b/content/blog/haskell_lazy_evaluation/index.md @@ -103,6 +103,17 @@ needed to compute the final answer can exist, unsimplified, in the tree. Why don't we draw a few graphs to get familiar with the idea? ### Visualizing Graphs and Their Reduction +__A word of caution__: the steps presented below may significantly differ +from the actual graph reduction algorithms used by modern compilers. +In particular, this section draws a lot of ideas from Simon Peyton Jones' book, +[_Implementing functional languages: a tutorial_](https://www.microsoft.com/en-us/research/publication/implementing-functional-languages-a-tutorial/). +However, modern functional compilers (i.e. GHC) use a much more +complicated abstract machine for evaluating graph-based code, +based on -- from what I know -- the [spineless tagless G-machine](https://www.microsoft.com/en-us/research/wp-content/uploads/1992/04/spineless-tagless-gmachine.pdf). +In short, this section, in order to build intuition, walks through how a functional program +evaluated using graph reduction _may_ behave; the actual details +depend on the compiler. + Let's start with something that doesn't have anything fancy. We can take a look at the graph of the expression: