Difficulty Understanding Program

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 :+1:
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 :slightly_smiling_face:

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. :wink:

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 :slight_smile:

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.