[E-Lang] Enough Rope... (was: An Attempted Restatement of Hydro's Semantics)

[Tyler Close]

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?).

Tyler