Yaq - An Enumerable Queue for Elixir

While working on a work project, I found I needed a more Elixir-like queue versus the Erlang :queue module. So I decided to write one. I liked what I did, so I’m sharing it with others.

Yaq (Yet another queue) is a double-ended queue that supports both the Enumerable and Collectable protocols. I wanted something I could use with the pipe operator, since with my use case I found myself having to write a lot of functions to make :queue work correctly.

This is my first library I’m sharing with the community. I not only wanted a library I could use in my day job, but something I could take an opportunity to learn how to “do things right” so with regards to Elixir.

Source code is available on Github: https://github.com/NullOranje/yaq
Hex package: https://hex.pm/packages/yaq
Documentation: https://hexdocs.pm/yaq/api-reference.html

Any and all feedback is welcome.


I get a 404 for the GitHub repository.

Also from the examples in the documentation, I really do not like that its inspection shows the length of the queue but not the contents…

Oh, and I just realise, Yaq.value/0 is nil | term, term includes nil, so why is nil mentioned extra here?

Why is there no Yaq.t/1 which would allow us to specify the members types as well?


Congratulations on your first library, its a big milestone and will be much appreciated I’m sure. I’ll check it out. @NobbZ is more direct and to the point than I am and his feedback is always very valuable, if sometimes a bit abrupt.


I really should try polishing this :smiley:


Thank you for sharing your work. By the way, are there other libraries like yaq? If so, what are the main differences?

What happened to the GitHub repo?

Isn’t it interesting to know whether the passed atom may be expected to be nil or not?

What if is I want to store nil? Is that not allowed?

Sorry, in this specific case it makes no sense to me too. I thought you meant as a general rule that nil | term is useless, as term includes nil; but I thought maybe sometimes it is useful to know that the library can expect nil.
Again, in this case I don’t see why this needs to be clarified indeed.

Yes, I’m pretty sure a @typedoc would help.

Hmm, seems very similar to Qex. Have you tried that one?

1 Like

That’s my fault. The repo is public now.

This was a deliberate choice. I can show the size of the

It probably shouldn’t be.

Mostly because I’m still figuring out how typespecs work.

This is probably an artifact of some thinking. The :queue module I drew inspiration from returned an :empty atom if you tried to dequeue an empty list. I guess I didn’t like the specific atom, so I think that’s why it became a nil. My own limited knowledge probably had me explicitly describe this case.

Thinking back, I’m wondering if an atom would be a better empty queue return value.

1 Like

I did, but because it is mostly wrapper for :quque, it has some of the same issues. :quque (deliberately) does not track the size of the queue, so that is an O(N) operation, which was too slow for my use case.

1 Like

nil is just an atom, specialcased by the parser to be able to leave off the colon.

In my opinion having marker or value is deemed to fail anyway. What if is I want to insert exactly the value you use as marker?

Please use a tagged tuple or at least provide an API similar to Map get/fetch/fetch! to be able to differentiate when necessary.

Also when you say, it’s collectable and enumerable, in which direction? Is there a way to collect/enumerate in the opposite direction?


Oh I haven’t noticed that Yaq is not a wrapper around :queue, that’s interesting. Speaking of efficiency, do you plan to do some benchmarks? Would be nice to see how it performs compared to :queue.

1 Like

I’ve had this same though about using atoms as markers. It’s a pretty common pattern in Erlang/OTP from what I can see, but the scenario you describe seems likely, especially when using common atoms like :ok (or nil).

I liked your suggestion about following the get/fetch/fetch! paradigm in Map and elsewhere, so I added a couple functions to the API:

  • fetch/1 and fetch_r/1 will return the tuple {value, updated_queue} if there are elements on the front or back of the queue, respectively, or :error otherwise
  • fetch!/1 and fetch_r!/1 will return the tuple {value, updated_queue} if there are elements on the front or back of the queue, respectively, or raise Yaq.EmptyQueueError otherwise

I also added a default value specification for dequeue/2 and dequeue_r/2 to follow the pattern from get.

You can only enumerate and collect from front to back, but you can reverse the queue in constant time with Yak.reverse/1, so I think it is a fair compromise.