Write while loop equivalent in elixir

An equivalent with potentially infinite running time (useful when polling an API for results in a quick Mix.install/2 script):

Stream.unfold(1, fn
  acc ->
    :timer.sleep(1_000)
    IO.puts("Waiting...")
    # TODO here: poll API and decide based on output status whether to leave or not
    if acc >= 5, do: nil, else: {acc, acc + 1}
end)
|> Stream.run()

Thanks @LostKobrakai for the inspiration, I wouldn’t have thought about Stream.unfold for this!

To add one more answer here,

I’ve created a macro while macro while | Hex

import While

total = 10

while_with total, total != 0 do
   IO.puts "hello"
   total - 1
end

IO.puts "total is #{total}"

Explanation:
The while_with binds the variable name total to both the expression total != 0 and the body. The body result (last line of body) always becomes the new value for the bound variable, like in a Enum.reduce

   IO.puts "hello"
   total - 1

Addendum:
If you’re only working with globals (or processes) you can also use the simple while without binding a name:

  import While

  ref = :counters.new(1, [:atomics])
  while :counters.get(ref 1) < 10 do
    :counters.add(ref 1, 1)
  end

  IO.puts("Current value is #{:counters.get(ref, 1)}")

Key is that the docs for Stream.take start off “Lazily takes…”, meaning elements not evaluated until requested. So it immediately returns, yes, and the return is an enumerable that will yield 16 values, and that enumerable is passed into the Enum.find? call, but the values themselves are not evaluated by the enumerable until requested, if ever.

I would understand that the “repeatedly” is infinite, but then my first guess would be that the second part “takes” 16 instances from the infinite stream and passes to the third part, which enumerates over them, or so. But it seems like backward thinking in the context.

Right - think it backwards

One good “brain hack” is to think of Enum as “the result of this will be immediately calculated and passed to the next function” and of Stream as “this will be calculated at the first occurence of Enum down the line”.

Yes, this is commonly known as “streams” or “lazy iterators”. This mean that the values will be computed only as needed and this is common pattern in languages that have “functional” feel (Haskell is lazily evaluated in general, Rust iterators are lazy by default, etc.). Even some “old” languages are getting such features (like Stream in Java).

That’s the beauty of lazy streams the original stream is actually infinite, but it only gets realized in a finite number of elements due to Stream.take and Enum.find.

Huh, that’s all so different from what I am well used to that after many years of successfully doing it for a living (using too many languages/stacks to list) I feel like I am learning programming from scratch again That’s both refreshingly challenging and intimidating at the same time. For example looking at the line, I wouldn’t guess that it will generate “only as many as needed”. Thanks.

@silverdr OK sure, here’s a non manual loop version:

Stream.repeatedly(&generate_name/0) |> Stream.take(16) |> Enum.find(&not_taken?/1)

This will return the first generated name that isn’t taken, OR quit after 16 tries. It will only generate as many names as are needed. Enumerable works great here too. Of course, you can always use manual recursion.

In a typical case I need one name, which is not yet taken…

… and I want to limit the number of checks so that if I tried - say - sixteen times and still don’t get a valid, non-yet-existing one, I can stop and notify that something’s probably wrong somewhere (namespace exhausted, misconfiguration, generator bug, etc.), instead of trying “forever”.