MIME-Version: 1.0
References: <CACKZBPU39WashARzg94y3YLNM=H78kNaD7ojskwGCOAej-mSGQ@mail.gmail.com>
            <51ECE2AC.7020806@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CACKZBPVV7hkeQYOP328fVYNOPpwc9zTiQF1hKJ1bUDzJMp+Mqw@mail.gmail.com>
Date:         Mon, 22 Jul 2013 10:06:24 +0200
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: Michiel Helvensteijn <mhelvens@GMAIL.COM>
Subject: Re: Propagation of 'global'ness
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <51ECE2AC.7020806@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On Mon, Jul 22, 2013 at 9:43 AM, Joseph Wright
<joseph.wright@morningstar2.co.uk> 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.

--
www.mhelvens.net