Property list 'implicit behavior changed', perhaps a better error message needed. (edited) about latex3

[blefloch]

Even that is too slow in a normal TeX run, but we could add something like that to the l3debug code.

[davidcarlisle]

Thanks for your understanding, sorry for the lack of notice about this change. The check was always supposed to be there the fact that it just got enabled on this release was due to a refactoring hence the lack of advance warning. see for example the comments at lvjr/tabularray#474
Yes the error message will be improved.

[muzimuzhi]

This is caused by wrong usage, not a bug.

In short, to clear a property list variable, \tl_set:Nn <property list var> {} was executed instead of \prop_clear:N <property list var>. Then, when the same property list variable is passed to \prop_gput:Nnn, an error

! Use of \__prop_put_linked:wnnN doesn't match its definition.

was thrown.

A slightly simpler example:

\documentclass{article}

\ExplSyntaxOn
\prop_new:N \l__test_activity_prop

\cs_new_protected:Npn \__test_get_prop:nnN #1#2#3
  {
    \prop_get:cnNF {#1}{#2}#3 {\tl_set:Nn #3 {}}
  }

\NewDocumentCommand{\Tcheckdef}{mmm}{
  \__test_get_prop:nnN
    {l__test_activity_prop} {chkmarked} \l__ufrgscca_check_prop
  \prop_gput:Nnn \l__ufrgscca_check_prop {#1}{\__ufrgscca_checkedbox:~\ #3}
  % ...
}
\ExplSyntaxOff

\Tcheckdef{Lx1Cx2}{xOKorientador}{Aprov. p/Aval.}

\begin{document}
\end{document}

In \Tcheckdef, the #3 of \__test_get_prop:nnN is always \l__ufrgscca_check_prop. Then with

\cs_new_protected:Npn \__test_get_prop:nnN #1#2#3
  {
    \prop_get:cnNF {#1}{#2}#3 {\tl_set:Nn #3 {}}
  }

the false branch of \prop_get:cnNF becomes \tl_set:Nn \l__ufrgscca_check_prop {}, which is wrong usage.

[alceu-frigeri]

Sorry for the noise. I ended finding out it was my mistake/error.

Better said,
Had the new property list behavior, enforcing that a property list has to be defined before use (which is a sound approach), be the 'original behavior', I would have caught my code typo long ago. :/

Though, it would be nice to have a better error message, like property ... is not a valid prop instead of the rather cryptic \__prop_put_linked:wnnN doesn't match its definition.

[josephwright]

@blefloch has added f17418a to allow errors to be avoided: I'll aim to get that to CTAN later today or tomorrow.

[blefloch]

I'm not totally sure this is the same problem as the other packages, so I'm not sure that my latest prop changes fix that. Can someone make an MWE? I'm busy fixing a different bug.

[josephwright]

@blefloch No, this is a different thing

[blefloch]

What confuses me is that the behavior should already been strange before.
@alceu-frigeri can you easily make a minimal example like \prop_new:N \l_whatever_prop etc.? showing the bug. I'd like to compare the behavior with earlier versions to the new behavior.

[blefloch]

We have a long-standing issue of how to allow nested seq or prop. Currently there is no documented way of doing that, so storing props as items as if they were simply token lists, and restoring them afterwards using \tl_set:Nn is not really supported. If you want to do something similar using only documented interfaces, you would have to use the slower \prop_to_keyval:N to turn the inner prop into a key-value list, and store that as an item in the larger data structure, then to convert it back to a prop use \prop_set_from_keyval:Nn.

[alceu-frigeri]

Hi,
I was working on it....

as @muzimuzhi notice the 'mishandling' of a property list. Which was what I meant when I mentioned a typo on the code (wrong property key name when recovering a stored property list).

Anyway, a smaller verstion:

\documentclass{article}

\ExplSyntaxOn



%%%%%%%
%%%%%%% This is a minimal working example

\prop_new:N \l__check_prop

\prop_new:N \l__test_prop

\prop_put_from_keyval:Nn \l__test_prop
  {
    chkmarked = ,      %%% Though to be a placeholder
  }

%%%%%%% My original error was in the line below, it should be chkmark and not checkmarked
%%%%%%%
\prop_put:NnV \l__test_prop {checkmarked} \c_empty_prop  %% <== Should be chkmarked

\cs_new_protected:Npn \__get_prop:nnN #1#2#3
  {
    \prop_get:cnNF {#1}{#2}#3 {\tl_set:Nn #3 {}}  %% The final nail in the coffin, if the key doesn't exist
  }


%%% Not needed for this MWE
\cs_new_protected:Npn \__put_prop:nnn #1#2#3
  {
    \prop_put:cnn {#1}{#2}{#3}
  }
\cs_generate_variant:Nn \__put_prop:nnn {nnV}


\NewDocumentCommand{\Tcheckdef}{mmm}{
  \__get_prop:nnN {l__test_prop}{chkmarked}\l__check_prop  
%  \prop_show:N \l__check_prop   %% this 'easily' recognizes it
  \prop_gput:Nnn \l__check_prop {#1}{some:~\ #3}
  \__put_prop:nnV {l__test_prop}{chkmarked}\l__check_prop
}



\ExplSyntaxOff

\Tcheckdef{L1C2}{OK}{Aval.}


\begin{document}

so it is...
\end{document}

The origin of my mistake:

1. I first initialized a property list with an empty key 'chkmarked'.
2. then I pushed an empty property list \c_empty_prop on the wrong key 'checkmarked'
3. Finally I recovered said key/property in an temporary property list::
   big caveats, the routine recovering the key would set, via \tl_set:Nn the receiving variable to a empty token list in case the key wasn't found

As said, my own fault. the only surprise (now) is that it was working at all, before the last kernel update. a temporary property list was, mistakenly initialized with an empty token list, and it was possible to handle it as if it were a proper property list, that's why I never caught the err before.

EDIT: in the Tcheckdef macro. the \prop_show:N easily recognizes that the property list was an invalid one.

[alceu-frigeri]

We have a long-standing issue of how to allow nested seq or prop. Currently there is no documented way of doing that, so storing props as items as if they were simply token lists, and restoring them afterwards using \tl_set:Nn is not really supported. If you want to do something similar using only documented interfaces, you would have to use the slower \prop_to_keyval:N to turn the inner prop into a key-value list, and store that as an item in the larger data structure, then to convert it back to a prop use \prop_set_from_keyval:Nn.

I see, but, I hope that 'implicit' behavior, never changes (otherwise it would be a bad month for me....
I made extensive use of it, with rather large property lists, all nested up. (not forgetting I'm also storing sequence lists, to speed up a few things).

[blefloch]

An even more minimal example is \prop_put:Nnn \l_tmpa_tl { a } { b } with an empty token list \l_tmpa_tl, which used to "work" in the sense that it made a change to the token list \l_tmpa_tl and didn't blow up, but now blows up with the error message you got. It's hard to see what could be done to catch such problems, but maybe someone has an idea?

[alceu-frigeri]

I'm certainly no expert on the kernel, but, I think \__kernel_chk_tl_type:NnnTF does the trick (well, at least when calling \prop_show:N, for instance).
But, I do see that could be a big performance hit.

EDIT: On the other hand, each data type (token lists, property lists, sequences...), if I'm not mistaken, has it's own set of of scan marks, wouldn't it be relatively easy to just check if the variable being passed away does (at least) have the correct ones?

[alceu-frigeri]

That would be really nice, I mean, having in l3debug, an option like check-types (or something) that would enforce not just that variables were previously declared but that their structure is the expected one.
That would go a long way helping find such an error like mine above.