Yaq - An Enumerable Queue for Elixir

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.

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.

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?

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.

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.

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

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

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.

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

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?