IO works with a bunch of Haskell
The Beginning of the Haskell Series
In this article we will focus on you . You are all spinning around Haskell's pile and strive to open a present. In the end, the gifts themselves do not open.
Someone should open the first gift.
If a bunch of Haskell does not interact with the outside world, then you do not need to open gifts. Therefore, only IO functions will do this. It is not always obvious what particular gift the function will open. Therefore we will look at the elementary evaluate . Which asks you ...
... just open the gift.
If you got a primitive value, then that's it. But can get a gift certificate (designer):
Will you open gifts on it? Despite your fervent desire, the answer is no. evaluate asks you to open only one gift. And if it’s already open, you don’t need to do anything at all.
Although we open only one gift, a lot of things can happen. I wrote about this in the last article. Any IO (side effect) can be executed ...
Side effects allow you to peek at the order of calculations. After all, if you run the program in the usual way, then we will not see when the gift opens. But if you ask the spirit to scream when it is disturbed, we will know about it. In fact, this is exactly what Debug.Trace does !
There are other ways to learn how calculations are progressing. The gift may explode if it is mined. Mines are also called “bottom” (logical contradiction).
Perhaps the explosion was caused by undefined or error "Foobar" .
Boom.
')
We finish with practical advice. As we have seen, you can be sure that the gift is open, only if you explicitly ask about it in IO. Otherwise, the spirit can deceive you. After all, you can not directly see a bunch of Haskell, so there is no direct way to find out whether the gift is open or not.
If you are not sure that thunk is calculated, attach a trace to it. And if the spirits are lazy behind your back, the trace will not work.
But more often you will still see a trace, although later than you expect (spirits are lazy, but they will someday do their work). It can be useful to exit the program ahead of time or print the completed stages of the calculations.
Last time: Calculation in a Haskell heap
Next time: Implementing Haskell Heap on Python, v1
Comment. Contrary to what I said earlier, theoretically nothing prevents you from doing thunk on the heap in any order: this is called a speculative calculation . In addition, IO actions themselves can be thunk, which corresponds to the transfer of value ( IO a ) without its real “sweep”. But since I’m not here for the monad, I’m just not going to pay attention to gifts with IO actions — everything works the same way, only one more level of indirection is added. And finally, the endless cycles are also considered bottom, but the picture in which the opening of the gift lasts until the end of the centuries is not as exciting as an exploding gift.
In this article we will focus on you . You are all spinning around Haskell's pile and strive to open a present. In the end, the gifts themselves do not open.
Someone should open the first gift.
If a bunch of Haskell does not interact with the outside world, then you do not need to open gifts. Therefore, only IO functions will do this. It is not always obvious what particular gift the function will open. Therefore we will look at the elementary evaluate . Which asks you ...
... just open the gift.
If you got a primitive value, then that's it. But can get a gift certificate (designer):
Will you open gifts on it? Despite your fervent desire, the answer is no. evaluate asks you to open only one gift. And if it’s already open, you don’t need to do anything at all.
Tip: If you want to calculate more, create a gift with the spirit that does the work for you! Often they give such an example of lazy IO computing of evaluate (length xs) . But don’t worry much if you don’t understand it yet: I haven’t yet told you how to create gifts!
Although we open only one gift, a lot of things can happen. I wrote about this in the last article. Any IO (side effect) can be executed ...
Side effects allow you to peek at the order of calculations. After all, if you run the program in the usual way, then we will not see when the gift opens. But if you ask the spirit to scream when it is disturbed, we will know about it. In fact, this is exactly what Debug.Trace does !
There are other ways to learn how calculations are progressing. The gift may explode if it is mined. Mines are also called “bottom” (logical contradiction).
Perhaps the explosion was caused by undefined or error "Foobar" .
Boom.
')
We finish with practical advice. As we have seen, you can be sure that the gift is open, only if you explicitly ask about it in IO. Otherwise, the spirit can deceive you. After all, you can not directly see a bunch of Haskell, so there is no direct way to find out whether the gift is open or not.
If you are not sure that thunk is calculated, attach a trace to it. And if the spirits are lazy behind your back, the trace will not work.
But more often you will still see a trace, although later than you expect (spirits are lazy, but they will someday do their work). It can be useful to exit the program ahead of time or print the completed stages of the calculations.
Last time: Calculation in a Haskell heap
Next time: Implementing Haskell Heap on Python, v1
Comment. Contrary to what I said earlier, theoretically nothing prevents you from doing thunk on the heap in any order: this is called a speculative calculation . In addition, IO actions themselves can be thunk, which corresponds to the transfer of value ( IO a ) without its real “sweep”. But since I’m not here for the monad, I’m just not going to pay attention to gifts with IO actions — everything works the same way, only one more level of indirection is added. And finally, the endless cycles are also considered bottom, but the picture in which the opening of the gift lasts until the end of the centuries is not as exciting as an exploding gift.
Source: https://habr.com/ru/post/118837/
All Articles