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…?) – cgnieder 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… – cgnieder Jul 24 '15 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 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.

| improve this answer | |
  • 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
  • 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 Jul 24 '15 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.