Why don't we have a way to append to `prop` lists? - TeX

TopAnswers TeX

Meta

Databases

TeX

Code Golf

APL

C++

.net

db<>fiddle

Java

*nix

PHP

PowerShell

Python

Rust

टेक्-मराठी

Typst

Web Client Dev

Web Server Dev

Why don't we have a way to append to `prop` lists?

add tag

निरंजन

We have functions to append to a variable, e.g., `\tl_put_right:Nn` or `\str_put_right:Nn`. Why is such a function not available for the properties stored with the `l3prop` module?
I think the question says it all. Currently I do something like following:

```
\documentclass{article}

\ExplSyntaxOn
\cs_new_protected:Npn \__prop_append:n #1 {
  \group_begin:
  \tl_clear:N \l_tmpa_tl
  \tl_clear:N \l_tmpb_tl
  \prop_get:NnN \g_tmpa_prop { test } \l_tmpa_tl
  \quark_if_no_value:NTF \l_tmpa_tl {
    \tl_set:Nn \l_tmpb_tl { #1 }
  } {
    \tl_set:Ne \l_tmpb_tl {
      \l_tmpa_tl, #1
    }
  }
  \prop_gput:NnV \g_tmpa_prop { test } \l_tmpb_tl
  \group_end:
}

\__prop_append:n { foo }
\__prop_append:n { bar }

\prop_show:N \g_tmpa_prop
\ExplSyntaxOff

\begin{document}
\end{document}
```

But it would have been better if we had a function for that. I am guessing there is some reason why it was not added in the first place. I am curious why.

Top Answer

Joseph Wright

Simply, because it's not a core feature of properties that's been required by the team. A property list is a list of keys/values. The fact that you might want to store things that are extended is secondary - at any one time, each key has an exact value.

Of course you may want to extend what is in a property list, but that's quite easy with get/add/store (I do that in `siunitx` for example). But this is not a 'central' feature, and there's no obvious performance gain from doing it in `expl3` core rather than programmers sorting what they need themselves.

@Joseph, of course one may do it on their own, but that can be applied to almost all of LaTeX3, can't it? One can do pretty much everything on their own. What I really like about LaTeX3 is that once you know the system well, you can extend it to most modules and not care about the details. E.g., one just needs to know `xx_new:x`, `xx_clear:x`, `xx_set:xx`, and stuff like that and it works in most modules. Purely (ana)logically one can predict what is available in one module and what is not. For me, this analogy broke for the `prop` module as it didn't have the appending commands that are seen in other modules. About "at any one time, each key has an exact value": I wonder why `\tl_put_right:Nn` exists then. Extending your statement about keys, the question I have is why do `tl`s can be expected to have the need for appending material? I can say the same thing you said for keys to `tl`s too, I believe. My only point is, eventhough a particular feature is secondary to the team, just for the uniformity of modules it could be a good idea to have similar functions. Unless there is any harm, of course, in providing support for secondary things.

I would need your help with the Curried code snipped below. As usual, I am stuck. ``` \group_begin: \prop_get:NnN #2 {#3} \l_tmpa_tl \exp_args:NNNne \group_end: #1 #2 {#3} { \quark_if_no_value:NF \l_tmpa_tl { \exp_not:V \l_tmpa_tl , } \exp_not:n {#4} } ``` What does `\exp_args:NNNne` do? I know the general usage of `\exp_args:`, but here it seems to be a little different. `\group_end:` doesn't have any argument, so using `\exp_args:` before it seemed a little unsemantic to me. I would like to know what this code is exactly doing.

> You get different expansion behaviour of your two code paths. My bad. Thanks for pointing it out. > Better would be \tl_set:No \l_tmpb_tl { \l_tmpa_tl, #1 } in the case \l_tmpa_tl isn’t \q_no_value. Hmm, I had read somewhere that `o` should generally be avoided. That's why I don't touch it much. But I understood what its effect would be in this example.

> As to why: Because that’s outside the usual scope for property lists. What is their general purpose? I was looking for some option to save and access some data easily. One approach was to use `tl`s, whereas one was to use property lists as shown in the example. Will property lists slow down the processing too much when compared to `tl`s?

@निरंजन, re: [your question](#question), honestly without reading your code I totally misunderstood the question... As to why: Because that's outside the usual scope for property lists. If you got a good use case you might open a feature request on the LaTeX3-github and the team will consider it, and maybe add something. Comments on your code: - You shouldn't define your macro using the `__prop`-prefix, that's reserved for the kernel's `l3prop` module and *not* your private name space. - You get different expansion behaviour of your two code paths. Better would be `\tl_set:No \l_tmpb_tl { \l_tmpa_tl, #1 }` in the case `\l_tmpa_tl` isn't `\q_no_value`. - You could get your code to be better behaved if you wanted without the need for global assignments: ``` \ExplSyntaxOn \cs_new_protected:Npn \my_prop_append:Nnn { \__my_prop_append:NNnn \prop_put:Nnn } \cs_new_protected:Npn \my_prop_gappend:Nnn { \__my_prop_append:NNnn \prop_gput:Nnn } \cs_new_protected:Npn \__my_prop_append:NNnn #1#2#3#4 { \group_begin: \prop_get:NnN #2 {#3} \l_tmpa_tl \exp_args:NNNne \group_end: #1 #2 {#3} { \quark_if_no_value:NF \l_tmpa_tl { \exp_not:V \l_tmpa_tl , } \exp_not:n {#4} } } \exp_args_generate:n { NNne } \my_prop_append:Nnn \l_tmpa_prop { test } { foo } \my_prop_append:Nnn \l_tmpa_prop { test } { bar } \group_begin: \my_prop_gappend:Nnn \g_tmpa_prop { TEST } { foo } \my_prop_gappend:Nnn \g_tmpa_prop { TEST } { bar } \group_end: \prop_show:N \l_tmpa_prop \prop_show:N \g_tmpa_prop \stop ```

1 Answer