Elixir needs a FIFO type?

I usually just make my own zipper for that, it’s a simple 2-tuple that allows efficient ‘rear’ (and front technically) insertion as well as efficient ‘front’ (and rear technically) popping with an occasional :lists.reverse() flipping.

Yeah, the list.reverse hacks are great when you’re dealing with short queues. I’ve come across the one project now where I’m dealing with longer queues and I don’t want to do that.

(I’m assuming I’m understanding what you’re doing here… But since I’ve never actually implemented that, maybe I’m imagining it to be worse performing than it is.)

It is just a 2-tuple like:

iex> newFifo = fn -> {[], []} end
#Function<20.52032458/0 in :erl_eval.expr/5>
iex> pushFifo = fn({l,r},x) -> {l,[x|r]} end
#Function<12.52032458/2 in :erl_eval.expr/5>
iex> popFifo = fn {[f|l],r} -> {f, {l,r}}; {[], r} -> case :lists.reverse(r) do []->throw "BLARGH-EMPTY"; [f|l]->{f, {l,[]}} end end
#Function<6.52032458/1 in :erl_eval.expr/5>
iex> f = newFifo.()
{[], []}
iex> f1 = f |> pushFifo.(42) |> pushFifo.(16)
{[], [16, 42]}
iex> {result, f2} = f1 |> popFifo.()
{42, {[16], []}}
iex> {result, f3} = f2 |> popFifo.()
{16, {[], []}}
iex> {result_boom, f4} = f3 |> popFifo.()
** (throw) "BLARGH-EMPTY"

And the reverse function is VERY fast, it is not a usual bottleneck anyway even with large lists.

I ran into queue in the GenStage documentation - and as such I don’t see a big issue with using Erlang libraries directly when they are not exposed through Core Elixir (possibly adapted through a super thin wrapper tailored to the specific use case without covering the full capability).

I think Elixir developers should embrace the Erlang libraries - not hide them away.

The :queue module is the answer. It works on the same principle that @OvermindDL1 described.

Yes, I was asking about wrapping it…

I think that aside from the primitives which are already wrapped in :elixir-application, the most idiomatic way to wrap erlang modules and libraries is to use them directly.

I disagree. The native queue library cannot be used in a pipeline; its use, to me, sticks out as very non-idiomatic elixir.

I agree that :queue is not nice to pipe, and also not nice to intropect.

Its implementation itself, as a purely functional queue à la Okasaki, is wonderful.

I have used EQueue in the past, which is an Elixir wrapper around :queue.

I am unsure about my opinion of needing a queue inside of the standard library. FIFO queues are not used that often in functional programming (at least in the projects I have worked on). The most important one, the actor model message mailbox, is abstracted away from us.

I do wonder how a queue NIF would look like, though :D.

There is one serious issue with the :queue module and that is that there 3 interfaces to the module, which makes it a right mess. Keeping track of which is which is a problem. If you are going to do an elixir Queue module then pick one and stick with it.

If you do your own elixir Queue there is really no reason to interface the erlang one as the implementation part is so straight forward it is probably less code to do it yourself. I needed a queue with bounded length and found it easier to write it directly myself rather than put a wrapper around queue.