MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <6EBBC8A1-0CB0-451D-AF0A-3EF2A41C0B52@YAHOO.DE>
            <3C45FBBF-D0F3-4C13-919D-AF69C8A6A808@gmail.com>
            <4B7895BF.2080805@morningstar2.co.uk>
            <C6758156-AE89-4B72-802C-F3F1B6DDD730@yahoo.de>
Message-ID:  <19321.15221.189622.454675@morse.mittelbach-online.de>
Date:         Mon, 15 Feb 2010 13:17:57 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: Assorted suggestions pt. 1
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <C6758156-AE89-4B72-802C-F3F1B6DDD730@yahoo.de>
Precedence: list
Status: R

Philipp Stephani writes:

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

at some point in time there has been a separate stack module but we decided
not to keep that separation. As mentioned it is largely a design/philosophical
question and I think we should leave it as it is.

frank
 >