LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Feb 2010 02:26:37 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
From: Philipp Stephani <[log in to unmask]>
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Transfer-Encoding: 8bit
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (19 lines)
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).

ATOM RSS1 RSS2