6

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?

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
XZS
  • 2,953
  • There's the roadmap in interface3.pdf that \array... is to be added, so the answer is no, at the moment ;-) –  Jul 24 '15 at 09:22
  • @ChristianHupfer you probably refer to the roadmap of the floating point module l3fp? (Or do you mean something in https://github.com/latex3/svn-mirror, l3db maybe…?) – cgnieder Jul 24 '15 at 09: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 –  Jul 24 '15 at 09:52
  • @ChristianHupfer No, I know nothing. This is one for Joseph or Frank or David… – cgnieder Jul 24 '15 at 09: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 ;-) –  Jul 24 '15 at 09:59
  • \prop_put:Nnn, \prop_get:NnN and \prop_item:Nn? – Manuel Jul 24 '15 at 10:37
  • @ChristianHupfer What clemens means is that you pointed to the l3fp roadmap, which is not the roadmap of expl3, and which has nothing to do with an implementation of an array in TeX, it does not mean that \array… is to be added. It's just another possible use inside l3fp macros. – Manuel Jul 24 '15 at 10:39
  • @Manuel: Well, you're right as always and I am completely wrong, as always, apparently ;-) –  Jul 24 '15 at 10:42
  • @ChristianHupfer Not necessarily, I just think that's what clemens meant. May be in the future we can implement arrays through l3fp. – Manuel Jul 24 '15 at 10:44
  • @Manuel: And that's why added l3fp as a reply to clemens' comment –  Jul 24 '15 at 10:53
  • @Manuel l3prop poses an interesting alternative. As it is intended for general-purpose mapping, I assume it would introduce much less overhead. Can it store arbitrary tokens, including macros and definitions, as values? – XZS Jul 24 '15 at 11:30
  • @XZS A separate question :-) prop data is built on tl data, and so can happily contain anything. – Joseph Wright Jul 24 '15 at 15:22

1 Answers1

6

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
  • 259,911
  • 34
  • 706
  • 1,036
  • See also http://tex.stackexchange.com/questions/147966/how-to-implement-low-level-arrays-in-tex – 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
  • 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