Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
References: <6EBBC8A1-0CB0-451D-AF0A-3EF2A41C0B52@YAHOO.DE>
            <3C45FBBF-D0F3-4C13-919D-AF69C8A6A808@gmail.com>
            <4B7895BF.2080805@morningstar2.co.uk>
Content-Transfer-Encoding: 8bit
Message-ID:  <C6758156-AE89-4B72-802C-F3F1B6DDD730@yahoo.de>
Date:         Mon, 15 Feb 2010 02:26:37 +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: Philipp Stephani <st_philipp@YAHOO.DE>
Subject: Re: Assorted suggestions pt. 1
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4B7895BF.2080805@morningstar2.co.uk>
Precedence: list
Status: R

Am 15.02.2010 um 01:30 schrieb Joseph Wright:

>>> - key-value option processing with l3keys
>> 
>> What's missing?
> 
> Perhaps Phillip has not seen l3keys2e.

Indeed. Thanks a lot for the hint.

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