[erlang-questions] : : queues (previously: documentation of data structures)
Tue Dec 18 00:07:12 CET 2007
On 17/12/2007, Anders Ramsell <> wrote:
> > Proposed new API (along the lines of Anders Ramsell's suggestion:
> > Introduce the notion of a first .. last order in the queue.
> > Elements normally enters the first end and exits the last end.
> Well, it does look a lot better than what we have today, but it
> seems "backwards". I do think you enter a queue at the end.
> Actually the only operations on a "queue" I tend to use is
> (avoiding API names altogether) these:
I agree, the head or front of the queue is where the oldest or next member
in line is, and the end or tail is where the most recent or last element.
- create a queue
> - add element to queue (which is then last in queue)
> - remove first element from queue for processing (waited the longest)
> - remove element from queue (no longer relevant)
I could imagine that you would also like to "peek" at the first element
without removing it.
The purpose being handling resources in the order they arrive
> with the extra constraint that some resources "go away" before
> it's their turn.
The question is if you add too many functions in the API for doing non-queue
like operations to the queue if you have a queue left. You could en up with
a more general sequence structure. What have people actually asked for?
That said, I'm sure the other operations also could be very useful
> in certain circumstances. And even though I beleive that what you
> call "delete(Item, Q1) -> Q2" is what I called 'drop' (and I'd
> still like that one added very much) I don't think the queue
> module should house a wide variety of "list like" funtions.
You could probably need some list like traversing functions as the internal
structure is supposed to be hidden. For example drop could be replaced with
a more general filter function.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions