[erlang-questions] : : queues (previously: documentation of data structures)
Mon Dec 17 09:53:45 CET 2007
On Sun, Dec 16, 2007 at 10:02:56PM +0100, Robert Virding wrote:
> I quite agree! First it should be liat, if it is supposed to be the reverse
> of tail.
> Then I also agree even more that the whole naming of the functions in the
> queue module sucks. It was probably originally taken from Okasaki who uses a
> subset of it in a chapter of his book. I personally think it can only be
> considered as a form of "in joke" which is really only comprehensible to
> people who know the terminology and as such is not suitable for a general
Well for me it was not a joke, but perhaps for the original writer.
I just got the module in my lap and found it had two incomplete
APIs, so I completed them both. It was probably then the joke
ceased to be funny. And I also mis-spelled the liat/1 function.
Sorry about that again.
Yet another API (that does not refer to Okasaki, but has telling names)
is perhaps inevitable. And I can understand why that requested drop/2
function is needed, but if speed is not that important, and if
a drop/2 is there a keydrop/2 is bound to be requested, why not
make it a drop/2 or delete/2 that takes a predicate?
And then foreach/2 and lots of other functions from
the lists module will be requested.
If speed is not important at all you can of course do
Q1 = queue:from_list([X || X <- queue:to_list(Q0), X =/= Y]
> I find it easier and faster to rewrite the code than try and remember the
> functions names if I need a queue. The algorithm is basically quite simple
> and neat.
> Rewrite the module with good names for the API and make sure to drop the old
> names from the documentation to make sure they don't spread, though they
> will have to be kept for BC. Get out a new version ASAP.
> P.S. Yes I know I occasionally include small jokes there are limits to what
> you can do.
> On 14/12/2007, Anders Ramsell <> wrote:
> > > > Anyways, queue:lait/1 should be liat/1 shouldn't it? Both in
> > > > the doc and impl. (It is the opposite of tail. The opposite of
> > > > cons/2 is snoc/2, the opposite of head/1 is daeh/1 but
> > > > lists:reverse("tail") /= "lait").
> > >
> > > Oh yes!!! I was tired when I wrote it, then self-blind, and
> > > nobody proofread. If I get a reason to touch the module I will
> > > add liat/1, forget about lait/1 but keep it around for backwards
> > > compatibility...
> > (I'm going to stick my neck out now. Hope I don't get beheaded.)
> > I think the API of the queue module is a mess. Full of weird
> > names and functions that do the same thing. Quite unlike most
> > other modules in stdlib. This is a pity because this module is
> > very useful. Or at least it could be - I'll get back to that.
> > If you're going to change it - change it a lot. My suggestion
> > would be something along these lines. First remove a few
> > functions.
> > Function: Duplicate of:
> > ------------------------
> > daeh last
> > in_r cons
> > lait init
> > snoc in
> > But we still have some weird names left. How do you 'init' a
> > queue by removing something from it? And out_r isn't all that
> > beautiful either. Then we have 'head' as the opposite of 'last'.
> > I would rename those and a few more to get something that I think
> > look like a "consistent" naming.
> > Function: Rename to:
> > ---------------------
> > init drop_last
> > out_r out_last
> > head first
> > tail drop_first
> > cons in_first
> > Of course all the old names would have to remain for a few
> > versions for backwards compatibility reasons.
> > Now back to what I hinted at before. The names of the API are
> > important but what they do is of course much more important and
> > the API is quite complete. But one, in my opinion, very important
> > function is missing. This fact has kept me from using this module
> > and roll my own on more than one occasion. There is no function
> > that removes a specified item no matter where in the queue it is.
> > Sometimes you just get tired of queueing.
> > No matter what you think of the rest of this mail please add that
> > function. Keeping to my own suggested names it could be called
> > 'drop'. I know it can't be O(1) but that doesn't matter.
> > Well? Will I know get pummeled into my shoes like the noob I am
> > or do I have a point?
> > /Anders
> > _______________________________________________
> > erlang-questions mailing list
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions