# Does expl3 have arrays?

There is \seq_item:Nn to get an arbitrary item from a sequence. As far as I understand, this works by iterating the sequence items, discarding until the requested item is found, which seems not very efficient.

Is there a data structure in expl3 that instead is more array-like in the terms that a single element can be directly accessed? This is something that before expl3 would have been done by defining macros for each "array item" like

\expandafter\def\csname \arrayname \itemnumber\endcsname{\arrayelement}


Not very difficult to translate to expl3 syntax, but perhaps it is already there?

• There's the roadmap in interface3.pdf that \array... is to be added, so the answer is no, at the moment ;-) – user31729 Jul 24 '15 at 9:22
• @ChristianHupfer you probably refer to the roadmap of the floating point module l3fp? (Or do you mean something in github.com/latex3/svn-mirror, l3db maybe…?) – clemens Jul 24 '15 at 9:50
• @clemens: I think it's l3fp. I did not check further. If you know more on the (plans) of array syntax etc. in l3 go ahead – user31729 Jul 24 '15 at 9:52
• @ChristianHupfer No, I know nothing. This is one for Joseph or Frank or David… – clemens Jul 24 '15 at 9:52
• @clemens: You're one of the most frequent users of l3, apart from egreg, of course, but I think you should participate in the development of it. I just managed to write a cs with \cs_new:Nn recently ;-) – user31729 Jul 24 '15 at 9:59

Currently, expl3 provides the prop data type for key-value type addressing

\prop_put:Nnn \l_tmpa_prop { a } { data-for-a }
\tl_set:Nx \l_tmpa_tl { \prop_get:Nn  \l_tmpa_prop { a } }
\tl_show:N \l_tmpa_tl % "data-for-a"


At present, this is also implemented using a single underlying macro so extraction in an expandable way has to iterate over the content. A none-expandable accessor function is available and is faster

\prop_get:NnN  \l_tmpa_prop { a } \l_tmpa_tl


The team have discussed alternative implementations here. As you note, for random access a hash table based approach is faster. However, that comes at the cost of issues with doing mappings (requiring a linked list implementation) and copying the data types (which then requires a mapping).

We are considering providing a generalised object data type, which will then be extensible by (low-level) module authors. However, at present if you need a data structure optimised for random access you will need to build it yourself.

• – Joseph Wright Jul 24 '15 at 15:00
• Wasn't Bruno asking a few weeks ago about how to use \fontdimens as a numer array? Is that related to this? – Manuel Jul 24 '15 at 15:17
• @Manuel \fontdimen arrays are clever, and Bruno, Will and I talked about them at TUG2015. However, you can only (efficiently) store numerical data that way, indexed by a number. Good for some things but rather specialised. We may well use it for selected internal stuff. – Joseph Wright Jul 24 '15 at 15:20