[E-Lang] Enough Rope... (was: An Attempted Restatement of
Mon, 02 Apr 2001 16:28:16 +0100
At 06:05 AM 4/2/01 -0700, Mark S. Miller wrote:
>At 04:26 AM Monday 4/2/01, Tyler Close wrote:
> >In this message, you seem to be attempting to merge the concepts of a queue
> >and a multiset.
>Yes, into the afore-mentioned indexable immutable list, with an expectation
>of a rope-like implementation for list-like uses, and possibly supplemented
>by an internal hash table for membership testing, or any other lookup by
>element. I believe this can replace the FIFO and LIFO Queues and the
>Initializer, as previously mentioned, and, with an optional internal hash
>table, the unordered multiset as well.
Well, I'm pretty sure that there are some major problems with implementing
the beast that you are talking about, but let's ignore that for now.
You are proposing a new data structure that is not a queue, stack, map or
set, but some combination of these. This is plausible, but I think you have
to justify it. Please show me a scenario where this thingy accomplishes a
task that cannot be accomplished using one of the [ queue, stack, map, set ].
I consider text strings to be a special case, so your example cannot be
text manipulation. (There are lots of interesting things that you might
want to do with text, hence the need for the Ent. Most of these operations
don't seem to occur with generalized collections of objects.)
Basically, I want to make sure we need this thing before we consider
building it. I understand the Queue presents a fairly limited interface,
but this interface can be implemented with very low overhead and I am not
sure that a more powerful interface is needed.
It is also very useful for the collection to know that it is a stack or
queue, so that the client code doesn't have to have this knowledge (ie: Do
I call pushFront or pushBack?).