FP 14 - Interactive Programming
ฝัง
- เผยแพร่เมื่อ 6 พ.ย. 2024
- This lecture shows how Haskell can be used to write interactive programs. We start by explaining the problem of handling interaction in a pure language, present the solution that is adopted in Haskell, introduce a range of primitives and derived functions for interactive programming, and conclude by developing a simple hangman game.
Course playlist: tinyurl.com/has...
I'm a bit confused by this video. My understanding, correct me if i am wrong, is that IO is a specific kind of monad which can be thought of as a container or some kind of variation on some `a`. Here the variation is that instead of being an `a`, it's a recipe on how to obtain `a`. This means that IO a is still pure and there are no side effects occuring during evaluation and this lets you modify the recipe in all sorts of ways before you finally execute the program, where the interpreter finally executes the side effects of whatever the final recipe is.
This also means that because it's just a recipe, after the execution of the recipe you do have access to `a` but even before execution, you could've modified the `a` in the recipe by using something like fmap on it.
And because of this i think the "eval" in REPL is really eval and execution right? Since eval turns an expression into a value and a value of IO a is just a recipe
Well, you could have planned how to process the ˋaˋ. The value doesn't exist until the ˋIO aˋ action completes.
In practical terms, evaluation and execution do get intertwined, as a result of laziness. The runtime will need results from execution to determine what portions of the recipe/plan/program require evaluation. From a theoretical standpoint you can indeed view your program as a full (possibly infinite) flowchart in the form of one IO action.
The REPL does indeed both evaluate and execute; in fact, to do the Print step it appends a print action, so there's execution with any given expression. In principle it uses the type of each command to select «case command of IO () -> command; IO _ -> command >>= print; _ -> print command».
If you'd like to get a deeper understanding of the I/O monad, I can highly recommend the "Tackling the Awkward Squad" paper, which gives an operational semantics for I/O and various other impure features: www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf
@@haskellhutt thank you, I'll read the paper. I guess the main thing I am confused about is you mentioning how these are impure features but i thought the entire idea of a monad is that it still keeps everybody pure and any function involving it is still a pure function because no actual side effects are ran upon evaluation. Evaluating an expression to a value of IO a is still pure because all you get back is the recipe right?
Yes, that's correct.
Today I learned hSetEcho is standard. Still a minor oddity how threadDelay isn't.