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

[Raimo Niskanen]

Perhaps someone should write an EEP, but I think this is a small
enough change to do without one. New suggestion:

*_first and *_last perhaps did not make things better.

Nobody seems to mind the in/2 and out/1 API.

We have:
	new() -> Q
	len(Q) -> Integer
	is_empty(Q) -> true | false
	in(Item, Q1) -> Q2
	out(Q1) -> {{value,Item}, Q2} | {empty,Q1}
add:
	get(Q1) -> Item | error(badarg)
	peek(Q1) -> {value,Item} | empty
	drop(Q1) -> Q2 % Drop what get/1 and peek/1 would return
keep double ended queue API (ugly but easy to remember):
	in_r/2, out_r/1
add double ended queue API for new functions:
	get_r/1, peek_r/1, drop_r/1
add new whole-queue operation:
	filtermap(Fun, Q1) -> Q2
and perhaps:
	zf(Fun, Q1) -> Q2 % Alias for filtermap /lists joke :-/
	filter(Fun, Q1) -> Q2
	map(Fun, Q1) -> Q2
or perhaps just add:
	filter(Fun, Q1) -> Q2
since it is the only one actually asked for.


Restructure the man page to put all other functions
except to_list/1, from_list/1, split/2, join/2, and reverse/1
in a legacy section after the above recommended.



On Tue, Dec 18, 2007 at 12:07:12AM +0100, Robert Virding wrote:
> 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

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB