-
-
Notifications
You must be signed in to change notification settings - Fork 134
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
14 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
# Reified Interpreters | ||
|
||
In the previous chapter we learned about algebraic data types. In this chapter we'll learn one of their major use cases, implementing interpreters. The interpreter strategy is perhaps the most important in all of functional programming. | ||
|
||
Before discussing the code, let's talk about why we might want to implement an interpreter. Implementing an interpreter sounds like a fairly esoteric thing to do, but it forms the core for building systems that maintain the desirable properties of functional programming---compositionality and reasoning---while allowing us to have effects in our code. The central idea is to **separate description from action**. For example, imagine we're implementing a graphics library using the interpreter strategy. A description simply says what we want to draw on the screen, but critically it does not actually draw anything. The interpreter takes this description and carries out the actions described by it. As the description doesn't do anything, we can freely compose descriptions. For example, if we have a description that describes a circle, and one for a square, we can compose them by saying we should draw the circle next to the square. This creates a new description that is the composition of the two base descriptions. | ||
|
||
It may be hard to see how this works from an abstract description. We'll make it concrete in just a moment, by building an interpreter for regular expressions. We've chosen this example because regular expressions are hopefully familiar to most you, so we can concentrate on the interpreter strategy and not on the details of regular expressions. We'll them extract the general strategy from this specific example, and finally give a few pointers to learn more. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
## Regular Expressions | ||
|
||
We'll start this case study by briefly describing the usual task for regular expressions---matching text---and then take a more theoretical view. We'll then move on to implementation. | ||
|
||
Programmers mostly commonly use regular expressions for matching text. For example, if we wanted to |