I quite agree! First it should be liat, if it is supposed to be the reverse of tail.<br><br>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 library.
<br><br>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.<br><br>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.
<br><br>Robert<br><br>P.S. Yes I know I occasionally include small jokes there are limits to what you can do.<br><br><div><span class="gmail_quote">On 14/12/2007, <b class="gmail_sendername">Anders Ramsell</b> <<a href="mailto:email@example.com">
firstname.lastname@example.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > > Anyways, queue:lait/1 should be liat/1 shouldn't it? Both in
<br> > > the doc and impl. (It is the opposite of tail. The opposite of<br> > > cons/2 is snoc/2, the opposite of head/1 is daeh/1 but<br> > > lists:reverse("tail") /= "lait").<br> >
<br> > Oh yes!!! I was tired when I wrote it, then self-blind, and<br> > nobody proofread. If I get a reason to touch the module I will<br> > add liat/1, forget about lait/1 but keep it around for backwards<br> > compatibility...
<br><br>(I'm going to stick my neck out now. Hope I don't get beheaded.)<br><br>I think the API of the queue module is a mess. Full of weird<br>names and functions that do the same thing. Quite unlike most<br>other modules in stdlib. This is a pity because this module is
<br>very useful. Or at least it could be - I'll get back to that.<br><br>If you're going to change it - change it a lot. My suggestion<br>would be something along these lines. First remove a few<br>functions.<br><br>
Function: Duplicate of:<br>------------------------<br>daeh last<br>in_r cons<br>lait init<br>snoc in<br><br>But we still have some weird names left. How do you 'init' a<br>queue by removing something from it? And out_r isn't all that
<br>beautiful either. Then we have 'head' as the opposite of 'last'.<br><br>I would rename those and a few more to get something that I think<br>look like a "consistent" naming.<br><br>Function: Rename to:
<br>---------------------<br>init drop_last<br>out_r out_last<br>head first<br>tail drop_first<br>cons in_first<br><br>Of course all the old names would have to remain for a few<br>versions for backwards compatibility reasons.
<br><br><br>Now back to what I hinted at before. The names of the API are<br>important but what they do is of course much more important and<br>the API is quite complete. But one, in my opinion, very important<br>function is missing. This fact has kept me from using this module
<br>and roll my own on more than one occasion. There is no function<br>that removes a specified item no matter where in the queue it is.<br>Sometimes you just get tired of queueing.<br><br>No matter what you think of the rest of this mail please add that
<br>function. Keeping to my own suggested names it could be called<br>'drop'. I know it can't be O(1) but that doesn't matter.<br><br>Well? Will I know get pummeled into my shoes like the noob I am<br>or do I have a point?
<br><br>/Anders<br><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:email@example.com">firstname.lastname@example.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">