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
    Commented Jul 24, 2015 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…?)
    – cgnieder
    Commented Jul 24, 2015 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
    Commented Jul 24, 2015 at 9:52
  • @ChristianHupfer No, I know nothing. This is one for Joseph or Frank or David…
    – cgnieder
    Commented Jul 24, 2015 at 9:52
  • 1
    @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
    Commented Jul 24, 2015 at 9:59

1 Answer 1


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.

  • See also tex.stackexchange.com/questions/147966/…
    – Joseph Wright
    Commented Jul 24, 2015 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
    Commented Jul 24, 2015 at 15:17
  • 1
    @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
    Commented Jul 24, 2015 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .