The concept of a Generator is not something that is unique to Python. Someone has taken the time in the past to write a version (using message passing) in Erlang (which was also translated to Elixir) on RosettaCode. Interestingly, as the Wikipedia Article mentions, Haskell’s lazily evaluated functions are also generators and as such the Stream that is built-in in Elixir indeed is also a generator.

Of course, in an immutable+pure language, you cannot call the same function with the same value over and over nextVal(mygen); nextVal(mygen); nextVal(mygen); and expect different results (unless you ‘cheat’ by using message passing). Indeed, when you’re working with for instance a Random Number Generator in Haskell, you have two options:

1. Call a function which takes a RNG, and returns a {randomNumber, newRNG} tuple. This is basically similar to what Enumerable does internally, which @benwilson512 talked about as well.
2. Specify that you want an infinite stream of random numbers, and take as many numbers from that stream as you need. In this case, the generator is ‘consumed’; you’ve turned in an infinite stream of numbers.

In most functional languages (including Elixir), depending on the specific situation, one of these two ways is used. The third one, ‘cheating’ using message-passing, is often too much overhead for what you want to use the generator for. Exceptions of course do exist: A GenServer that returns guaranteed-unique identifiers, for instance.

I do wonder if we can implement a generator based on fixpoint combinators as well, by the way…

Can’t we all be friends?

Every new language you learn impacts your style. Some concepts tend to stick, so naturally I want to explore how they could be replicated or what the alternatives are.

Well, at least for Enum.split/2s strictness there has been a discussion recently:

This also tackles some small bits of your “state” problem.

In elixir I do usually not expect side effects to happen, so next(s) which returns 1 on the first call and 2 on the second without rebinding s would be counterintuitive for me.

If you need a central authority handing out free ids, work items, whatever, I do think that is what GenStage has been developed for.

If you really need something as your python thingy (which involves far too much magic for me, I’d expect it to loop forever) then you need to implement it yourself. Some protocol or behaviour and a handfull of macros, and you are ready to release it on hex.

Of course I do expect a stream that has no end to run forever. Stream.run/1 is documented to evaluate the complete stream.

As well as I do expect while true {} to do nothing forever, and not to do a single nothing only when I do ask for it…

After reformatting your code, I do see a little bit better what you meant. Still I’d expect that Stream to run forever and to block that process it is run in, but of course you can ask for printing “hi” and doing an otherwise useless addition if you do know the PID of the starting process.

Thanks everyone for your thoughts.

I have currently this passing test case:

  test "generators" do
    defmodule MyGen do
      use Snakeoil.Generators

      gen "counter", x do
        yield x
        counter(x+1)
      end

      gen "two", {x, y} do
        yield x + y
        two({x+1, y + 1})
      end
    end

    pid = spawn(fn -> MyGen.counter(0) end)
    assert 0 == MyGen.next(pid)
    assert 1 == MyGen.next(pid)
    assert 2 == MyGen.next(pid)

    pid = spawn(fn -> MyGen.two({2, 3}) end)
    assert 5 == MyGen.next(pid)
    assert 7 == MyGen.next(pid)
  end

This is a toy, of course - mostly an exercise in metaprogramming. I have to admit that having optional parentheses makes things like that fun to write - but I’m not sure how fun it would be if someone did use that in their own code If i’m not mistaken, Elixir also favors explicit over implicit, which is good from me, coming over from Python land.