On 15/02/2010, at 11:56 AM, Philipp Stephani wrote:

>>>> - dedicated stack and queue datatypes that hide their implementation
>>> Can you go into more detail about what is deficient in l3seq for this?
>> I think we are getting at "concepts" here: something like \cs_set_eq:NN \stack_new:N \seq_new:N, ...
> Yes. This separation would perhaps be a bit clearer to the user. I read the discussion in source3 on removing \seq_put_left in favor of \seq_push, but with a stack datatype (which would be rather trivial) we would have the same situation as in C++: A deque as a container (a L3 seq is in fact similar to a deque because you can add elements at both ends, but not in the middle, as opposed to vectors and lists), and stack and queue as container adaptors. However, this is a purely design decision (Python, for example, has no dedicated stack datatype).

Ah, I see what you mean. So add l3queue and l3stack with allocation all alike l3seq, but with

\queue_push, \queue_pop == \seq_push_left, \seq_pop_right


\stack_push, \stack_pop == \seq_push_right, \seq_pop_right

Note that these pop_left and pop_right functions don't yet exist but we have been planning on implementing them, as well as normalising the names that are currently duplicated such as \seq_put_right and \seq_push. Just haven't got around to it so far. 

My personal preference is to keep the number of data structures to a minimum; we already have a fairly large number of modules and adding "queue" and "stack" doesn't make things any simpler in this regard.

Thanks again for the feedback,

-- Will