LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Mon, 22 Jul 2013 10:06:24 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Message-ID: <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=ISO-8859-1
From: Michiel Helvensteijn <[log in to unmask]>
Parts/Attachments: text/plain (34 lines)
On Mon, Jul 22, 2013 at 9:43 AM, Joseph Wright
<[log in to unmask]> wrote:

> Certainly see a point here, but on the other hand I'm not a fan of
> encouraging more and more data structures. Writing a full data structure
> module is non-trivial: in most cases, I'd expect people to be using
> combinations of the existing ones in an ad-hoc fashion for their purpose.

That doesn't sound like someone who is creating a programming language. :-)

Abstraction is the word. There are so many useful data structures out
there that you haven't even touched upon in the libraries yet. Graphs,
trees, priority queues, sets, multisets, tables, ... One can never
predict what a programming language will be used for.

If you see a future in expl3 you should expect it to grow, and outside
developers to be a part of that. If you don't provide these kinds of
facilities, others will. That's the nature of TeX. Just look at
etoolbox, etc. Being more flexible will probably give you more control
in the long run.

>> Note that `\tl_sset:NNx` and `\tl_sput_right:NNx` are now spelled out
>> in their proper place, so the reader doesn't have to go back and forth
>> to understand what's going on. There is no need for auxiliary
>> functions and errors of omission are unlikely, since omitting #1 would
>> lead to an error.
> One of the reasons we decided against auto-detection

Auto-detection is not a bad idea, but it was not part of my original suggestion.