I am going through Streams in Dave Thomas’s book and here I am having difficulties in understanding the following program.
For, example what is receive
in sleep
function and why to use it?
What is after
in sleep function?
How this whole program is executed?
Why Dave Thomas suddenly jumped to such a complex program just after explaining the basics of Stream.
defmodule Countdown do
# sleep mode
def sleep(seconds) do
receive do
after
seconds * 1000 -> nil
end
end
def say(text) do
spawn(fn -> :os.cmd('say #{text}') end)
end
def timer do
Stream.resource(
# start of next minute or number of seconds in a minute
fn ->
{_h, _m, s} = :erlang.time()
60 - s - 1
end,
# wait for the next second
fn
0 ->
{:halt, 0}
count ->
sleep(1)
{[inspect(count)], count - 1}
end,
# nothing to deallocate
fn _ -> nil end
)
end
end
I don’t see require
in the sleep
function. Did you mean “receive”?
ohh yes, its a typo. I mean receive
I think you will get a better picture of how receive
works when reading the chapter on Processes (chap 15), in the meantime you can just consider that this is a way of sleeping.
He could probably as well have used the built-in function :timer.sleep/1
, e.g. seconds |> :timer.seconds() |> :timer.sleep()
.
The use of receive
here is not very clear about the intent, but it is basically listening for a message that is never going to come (no call to send
anywhere) with a timeout of seconds
, after which it returns.
2 Likes
Thats pretty good explanation. Also the Stream.resource function is very confusing as one function pass data to another and thats how it traverse. Is it important to learn it at this stage or it’s too early to dive deep into it ?
It works that way not because there’s no send
– other processes could send messages – but because there’s no “matching clause” for receive
.
Indeed, thank you for the correction
I meant to say “it isn’t trying to actually receive anything, and isn’t sending anything either, just relying on the timeout as a way to implement the sleep”.
While it might not be necessary to “dive deep”, it is probably helpful to understand what exists, what is possible, and you can always come back to it once you need it. The example from the doc might give you a good idea as well.
As stated in the intro, this book is “not a top-to-bottom reference guide”, don’t look at it as a checklist of things you “have to” know, but as a guide to explore the language
1 Like
Thanks a lot … Is there any reference book for Elixir
I suppose it depends what you are looking for, it is a bit hard for me to answer. Maybe this list might help?
If I had to recommend myself, I would suggest starting with the official Getting Started guide and check Elixir School as well.
A great way to explore different parts of the language through practice could be Elixir-koans.
And if you are planning to use Elixir for web development, the Phoenix official guide and Programming Phoenix are fantastic.
All those resources are free (except the book) and should help you get started, check what works best for you. Past some point nothing beats practicing on some real projects IMHO (and the official documentation will be a tremendous help once you do). And you can always come back at Programming Elixir later for a deeper dive into the concepts.
2 Likes
Streams, Enums and the functional idioms can be hard to memorize. My advice is to not worry too much about memorizing every function, but learn one everytime you solve a new problem. When I was learning F#, I started with map, reduce and filter only. Then, everytime i solve a problem, I would consult the list of functions, and see if any of them applied. Sometimes I’d miss out things I could do, but that’s ok.
Now when I am learning Elixir, I do the same thing. Also, you can always come here and ask for improvements
4 Likes
Thats some very good recourses. Thanks
Its seems like you understood my exact problem and thats a great advice. Thats very true, when i am solving a problem i have many Enum functions in mind but just get confuse which one to apply and which not. I think it will come with practice and with time.