[erlang-questions] : : queues (previously: documentation of data structures)

[Robert Virding]

On 17/12/2007, Anders Ramsell <anders@REDACTED> 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.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071218/133e2c74/attachment.htm>