# Array functionality in TeX?

I've been using LaTeX for a while, but only recently I made myself a mission to create a class. I needed to learn the details of TeX, and I couldn't find answers to some of my questions. One of them is:

How can I implement a dynamically allocated array in TeX? One of the environments I defined takes a single parameter such as {1234}. I need to split this into characters, which can be done this way. Then I need to list the numbers such that array=[1,2,3,4].

Then I want to loop the elements of this array and place a single-row tabular environment with i columns for each i in the array.

To make things clearer, here's is my purpose. One will define a choices environment such that:

\begin{choices}{32}
\choice ch1
\choice ch2
\choice ch3
\choice ch4
\choice ch5
\end{choices}


is going to create multiple choices in two rows, 3 for the first and 2 for the second (3+2=5):

A) ch1  B) ch2  C) ch3
D) ch4  E) ch5


This notation is going to help create more flexible choices, with a maximum number of 9 choices per line.

For small-scale arrays, the usual solution is to use a \csname-based approach

\expandafter\def\csname my@array@1\endcsname{content-for-key-1}


which can then be read back just using

\csname my@array@1\endcsname


Depending on the use case, you may of course want to have the index as a LaTeX counter or TeX count

\csname my@array@\the\my@array@index\endcsname


Historically, the problem with this approach was that you could run out of space in the hash table for new csnames: TeX used to be 'small' compared with today. Thus the LaTeX3 team have explored storing all of an array using a single name: currently this is how the prop data type in expl3 is implemented.

There is also a question about the performance of TeX's hash algorithm. It's not a particularly efficient one, so collisions are quite common, at least in theory. Thus making the hash table too big might at least in principal impair performance. However, as discussed in How to implement (low-level) arrays in TeX the practical outcome here is not too bad, so I would not be too concerned about it. The only thing you might want to do is avoid numerical keys.