{'fraction_non_alphanumeric': 0.02236024844720497, 'fraction_numerical': 0.004968944099378882, 'mean_word_length': 5.367588932806324, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Chapter 2. Background

This chapter discusses background information pertinent to the research discussed in the remainder of the book. Section 2.1 defines the problem area addressed by the research: combinator graph reduction of lazy functional programs. Section 2.2 discusses previous research on combinator reduction methods of program execution. Section 2.3 outlines the approach used for research presented in later chapters, focus-ing on the TIGRE abstract machine for combinator graph reduction. The problem area of interest is the efficient execution of lazy functional programs using combinator graph reduction. Since this method of program execution is not well known, Appendix A has been provided as a brief tutorial on the main concepts. Functional programs are built by pairing expressions into applications. Each expression may be a function or value, and the result of each pairing may also be a function or a value. Functional programming languages may be contrasted with more conventional, imperative, programming languages by the fact that functional programs preserve referential transparency (i.e., expressions have no side effects and depend only on values returned from subexpressions), and hence lack an assignable program state. 5 Lazy functional programming languages are further distinguished from imperative languages by the fact that they employ lazy (or, more precisely, nonstrict) evaluation of parameters by default. Lazy evaluation (sometimes called normal order evaluation, although this term does not precisely characterize the notion of lazy evaluation) is a call-by-need para