| Author |
Message |
< Erlang questions mailing list ~ : : queues (previously: documentation of data structures) |
| Guest |
 Posted: Mon Dec 17, 2007 8:57 am |
 |
|
|
Guest
|
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
> library.
>
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]
and such.
> 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.
>
> Robert
>
> P.S. Yes I know I occasionally include small jokes there are limits to what
> you can do.
>
> On 14/12/2007, Anders Ramsell <anders@theheartofgold.org> 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
> > erlang-questions@erlang.org
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Dec 17, 2007 11:33 am |
|
|
|
Guest
|
If changing the names of daeh, in_r, lait, snoc, init, out_r, head, tail
and cons, why not change them all?
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.
Regular (forward) direction:
put(Item, Q1) -> Q2
put_first(Item, Q1) -> Q2
get(Q) -> Item
get_last(Q) -> Item
drop(Q1) -> Q2
drop_last(Q1) -> Q2
So put/2 is an alias for put_first/2,
get/1 is an alias for get_last/1
and drop/1 is an alias for drop_last/1.
Goofy (backward) direction:
put_last(Item, Q1) -> Q2
get_first(Q) -> Item
drop_first(Q1) -> Q2
Inspection:
is_empty(Q) -> Bool
len(Q) -> Length
Creation and conversion:
new() -> Q
from_list(List) -> Q
to_list(Q) -> List
Operations:
join(Q1, Q2) -> Q3
split(N, Q1) -> {Q2, Q3}
Questionables (so list-like there will be no end to it...):
delete(Item, Q1) -> Q2
should it be
delete(fun/1, Q1) -> Q2
or
zf(fun/1, Q1) -> Q2
aka
filtermap(fun/1, Q1) -> Q2
or maybe
search(fun/1, Q) -> {Position,Item} | false
delete(Position, Q1) -> Q2
where search/2 could be replaced with
fold(fun/2, Q, Start) -> Term
I also aim to add new(Q1) -> Q2 that converts to a new queue format
containing length so on a converteed queue len/1 is O(1), but
once you have called new/1 you can not code downgrade or send nor
save a queue term to be understood by an older node.
One can also consider to rename the whole module to deq, but that name
should perhaps be reserved for a large and complicated all operations
O(1) double ended queue according to Kaplan/Tarjan...
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
> library.
>
> 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.
>
> Robert
>
> P.S. Yes I know I occasionally include small jokes there are limits to what
> you can do.
>
> On 14/12/2007, Anders Ramsell <anders@theheartofgold.org> 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?
You sure do have point.
> >
> > /Anders
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@erlang.org
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Dec 17, 2007 1:07 pm |
|
|
|
Guest
|
I intrepid Raimo proposal as being FIFO.
You add to the beginning(put/2 or put_first/2), removing from the
end(get/1 or get_last/1).
First item will be last in list even if new element is added, therefor
first in will be first out.
(Unless you use put_last.)
I don't see any point in arguing over:
* "Add to beginning and remove from end" or
* "Add to end and remove from beginning"
It will still be a FIFO or did I miss something?
Regards
Andreas Hillqvist
2007/12/17, Andras Georgy Bekes <bekesa@sch.bme.hu>:
> > Elements normally enters the first end and exits the last end.
> >
> > Regular (forward) direction:
> >
> > put_first(Item, Q1) -> Q2
> > get_last(Q) -> Item
>
> A queue is "FIFO" (First In First Out), so the first element is the one
> that entered the queue first, and that will leave the queue first.
>
> Your proposal is the opposite of this. Why?
>
> Georgy
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| rvirding |
| Posted: Mon Dec 17, 2007 11:10 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
On 17/12/2007, Anders Ramsell <anders@theheartofgold.org (anders@theheartofgold.org)> wrote:Quote: > 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.
Quote: - 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.
Quote: 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?
Quote: 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
Post recived from mailinglist |
|
|
| Back to top |
   
|
| Guest |
| Posted: Tue Dec 18, 2007 3:16 pm |
|
|
|
Guest
|
I propose use stack like perl terminology:
pop x push
unshift x shift
unshift -> Q -> pop
shift <- Q <- push
On 12/17/07, Raimo Niskanen <raimo+erlang-questions@erix.ericsson.se> wrote:
> If changing the names of daeh, in_r, lait, snoc, init, out_r, head, tail
> and cons, why not change them all?
>
> 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.
>
> Regular (forward) direction:
>
> put(Item, Q1) -> Q2
> put_first(Item, Q1) -> Q2
> get(Q) -> Item
> get_last(Q) -> Item
> drop(Q1) -> Q2
> drop_last(Q1) -> Q2
>
> So put/2 is an alias for put_first/2,
> get/1 is an alias for get_last/1
> and drop/1 is an alias for drop_last/1.
>
> Goofy (backward) direction:
>
> put_last(Item, Q1) -> Q2
> get_first(Q) -> Item
> drop_first(Q1) -> Q2
>
> Inspection:
>
> is_empty(Q) -> Bool
> len(Q) -> Length
>
> Creation and conversion:
>
> new() -> Q
> from_list(List) -> Q
> to_list(Q) -> List
>
> Operations:
>
> join(Q1, Q2) -> Q3
> split(N, Q1) -> {Q2, Q3}
>
> Questionables (so list-like there will be no end to it...):
>
> delete(Item, Q1) -> Q2
> should it be
> delete(fun/1, Q1) -> Q2
> or
> zf(fun/1, Q1) -> Q2
> aka
> filtermap(fun/1, Q1) -> Q2
> or maybe
> search(fun/1, Q) -> {Position,Item} | false
> delete(Position, Q1) -> Q2
> where search/2 could be replaced with
> fold(fun/2, Q, Start) -> Term
>
> I also aim to add new(Q1) -> Q2 that converts to a new queue format
> containing length so on a converteed queue len/1 is O(1), but
> once you have called new/1 you can not code downgrade or send nor
> save a queue term to be understood by an older node.
>
> One can also consider to rename the whole module to deq, but that name
> should perhaps be reserved for a large and complicated all operations
> O(1) double ended queue according to Kaplan/Tarjan...
>
>
>
> 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
> > library.
> >
> > 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.
> >
> > Robert
> >
> > P.S. Yes I know I occasionally include small jokes there are limits to what
> > you can do.
> >
> > On 14/12/2007, Anders Ramsell <anders@theheartofgold.org> 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?
>
> You sure do have point.
>
>
>
> > >
> > > /Anders
> > >
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions@erlang.org
> > > http://www.erlang.org/mailman/listinfo/erlang-questions
> > >
>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@erlang.org
> > http://www.erlang.org/mailman/listinfo/erlang-questions
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
--
--Hynek (Pichi) Vychodil
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| wuji |
| Posted: Tue Sep 18, 2012 7:11 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
security plan which, I believe, will provide both reassurance and and cheap replica *beep* and a powerful deterrent."In addition to the Rapier and High-Velocity
batteries, the government will also station a Royal Navy helicopter helicopter [h4]replica designer *beep*[/h4] helicopter carrier in the River Thames and station Royal Air
jets and army helicopters nearby.Residents of the Fred Wigg Tower Tower discount designer *beep* Tower and the Tower Hamlets, which will host High-Velocity missiles,
expressed concern about the batteries when the government made a a [h2]designer replica *beep*[/h2] a test deployment of the missiles atop their buildings in
May. "I'm not sure I can sleep in a house house [h3]cheap designer *beep*[/h3] house knowing there are missiles on the roof," journalist and
Hamlets resident Brian Whelan told ABC News in May.Said Secretary Secretary [h1]authentic jordans[/h1] Secretary Hammond, "A small number of activists object to the
of these defensive measures and a legal challenge to the the cheap jordans the Government's decision to deploy ... has been initiated. The
of Defense will defend these proceedings vigorously and is confident confident [h3]cheap designer *beep*[/h3] confident of defeating them."Additional anti-aircraft missile batteries are in place |
|
|
| Back to top |
|
| mbtshoes88 |
| Posted: Wed Sep 19, 2012 9:16 am |
|
|
|
User
Joined: 18 Sep 2012
Posts: 30
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
