@cfr We don't remove stuff fro the code, but if we deprecate we remove the docs

@Skillmon The function token_case_meaning:Nn tests the meaning of a single token. How can that possibly replace a function that compares a token list with a collection of other token lists?

@Gaussler \tl_case:Nn -> the first arg is also a single token

@JosephWright Well, possibly (the documentation is gone). I thought it compared a token list against the contents of the n argument. Why is there no function that does that? I know I can use \str_case, but why do I have to treat the token lists as strings?

@JosephWright I mean, if \l_my_token_list_tl is a token list, then \tl_case:Nn \l_my_token_list_tl { {...}{...} {...}{...} } looks like a very logical case syntax

@JosephWright What if I want a case version of \tl_if_eq:nnTF?

@Gaussler I don't understand. Say you have \l_my_a_tl which expands to 'foo' and then you have \l_my_b_tl which expands also to 'foo', how do you want to compare these to other than via their meaning (which is 'foo')?

@JasperHabicht Ah, sorry, I thought that it compared the tokens to see if they were equal without expanding them first

@JasperHabicht That does not change the fact that I think it’s natural to have a \tl_case:nnTF which compares two token lists inside the first two arguments

@JasperHabicht Similarly to \str_case:nnTF, but without converting them into strings

@Gaussler but ultimately converting to strings is the safe thing. What would be your use case?

@yo' My use case is extremely simple. I have a CV with a lot of out-of-five ratings of my competencies. It needs to print those ratings in terms of whole and half circles. I could use floating point calculations, but that would just slow everything down. So to keep things fast and simple, I just compare the value of the input to every half-integer in the list 0, 0.5, 1, ..., 5. Currently, I use \str_case:nnTF, but find it kinda unnatural to have to convert it to strings

@Gaussler If you only use digits and fullstop, you are dealing with a sort of string (everything is catcode 12 except for spaces) anyways. The conversion won't change anything really here.

@JasperHabicht Right

^^ What Jasper says. Comparing as str is probably simply even safer than as tl

Hah, programming in TeX so that the result stays fully expandable is a whole new level of brain training …but since it often requires clever use of TeX‘s argument delimitation techniques, I suspect that it also is quite fast

@Gaussler I don't think there is any expandable way to comare tl without looping through each character one at a time it would be much more complicated than str compare which is just \pdfstrcmp more or less.

@Gaussler but why don't you simply compare the values numerically \ifdim#1pt=2.5pt ...\fi checks if #1 is 2.5

@DavidCarlisle As I said, I considered string manipulations to be faster than performing anything involving floating point calculations. After all, the value is only ever of the form 0, 0.5, 1, 1.5, 2, ..., 5`

@Gaussler there are no floating point calculations in \ifdim

@DavidCarlisle Okay, then maybe that’s a fast alternative to the string comparisons

@Gaussler unless you have a few hundred thousand of these things it's unlikely to make any measurable difference either way

@DavidCarlisle I don’t, but I compile it hundreds of times a day, which is why I starting doing microoptimizations

@Gaussler because there never was a \tl_case:nn but only a \tl_case:Nn which expected single token list variables for each case (so something like \tl_case:Nn \l_tmpa_tl { \l_my_cases_A_tl { <code A> } \l_my_cases_B_tl { <code B> } ... }.

@Gaussler because \tl_case:Nn was fully expandable, just like \str_case:nn, but \tl_case:nn couldn't ever be fully expandable.

@Gaussler nothing stops you from creating such command (under a different module prefix), but be aware that you can't do that fully expandable with the same precision as \token_case_meaning:Nn. There are things that can't be told apart expandably. If you want to you can also try to persuade me adding something like this to etl.

@DavidCarlisle The only real culprit is that while in TeX, direct comparison of non-integer numbers is reasonably safe, it's not so much in many other situations, so it can be fairly considered a bad practice.

@Gaussler You can only do the token-based comparison with an assignment, whereas the string one doesn't need that - practically, almost always one wants to compare the string not token content

@DavidCarlisle depends on the string length (for these it's really no difference).

@JasperHabicht that really depends... You can do horribly inefficient things in TeX's mouth just to get something running expandably that could be way faster and better implemented unexpandably (\tl_if_eq:nnTF is one such thing -- I know what I'm talking about, I implemented it fully expandable)

@Skillmon Well, in certain cases this might be true. I think, I won't try to build an expadable JSON parser (although that might be possible). But I have a "validator" for JSON numbers (which are a tiny bit different from what l3fp accepts) in the package which I wanted to make expandable (in order to have a _p variant of the conditional). And it was fun to do that.

So, as long as it does not become awkwardly complicated, it is fine, I guess. It is just another way of thinking. That's what I mean.

More like "the TeX way" ... probably

@JasperHabicht I'd have implemented the fully expandable JSON parser :P For reference see etl, expkv, and my PR against l3sort.dtx :)

@Skillmon But! I wanted to make things easy for the user. So, I wanted to have everythng stored in a property list. And \prop_put is not expandable. So why making things complicated?

@JasperHabicht fun? :)

But maybe I will review large parts of the code one day ... It works for now and it reasoably quick. So that's enough for now

Sure =D

Or maybe a few long days with lots of spare time

@yo' well yes (check what company I work for in the day job:-) but these are really integer calculations, TeX doesn't do floating point.

@DavidCarlisle until Bruno

@Skillmon true (and some hidden non exposed glue operations:-)

@DavidCarlisle "these floats aren't floats" sounds to me a a bit like "this sensor/button isn't safety-critical" or "this password isn't important" :-)

@yo' well there is a difference between fixed point and floating point arithmetic, that's why they have different names, even if both start with f and 1.5 might be a literal value for either.

@yo' As far as I have understood it (this might be wrong), integers are used as long as decisions are being made. For example, where to break lines in a paragraph. Then, when the packing of the paragraph is done, there might be float calculations going on for the glue.

@mickep yes (but in classic tex only in places where you can not unbox and see the caluclations, to ensure bitwise portability in results) if only there was a primitive that gave you access to the stretched glue size....

@DavidCarlisle Indeed, somebody should suggest such a feature. :P

Amazing, I just compared a random tblr exampe with about 500 rows with v2024A that is currently on CTAN and with the most recent versison of the .sty on GitHub. Result: about 25s > about 7s! This is a huge improvement!

@JasperHabicht Sounds promising!

@mickep blame Bruno

@Skillmon ^^^^

@DavidCarlisle time to implement my egreg plan (expandable <something with g indicating speed> regular expressions)

(though I doubt it'd turn out faster than l3regex)

@Skillmon use luatex and patterns not regex ?

@DavidCarlisle where's the fun in that?

@DavidCarlisle Yes, Jianrui removed the regex stuff ...

@JasperHabicht much overdue. I never looked into the code too much and thought there was good use of them. I was a bit disappointed that one of the most often called regex based functions was merely a space trimmer.

@Skillmon Right, some of the regex in there was not really needed. But I am unsure what was done now. I just helped with a tikz library recently, so I know about some other improvements

@JasperHabicht David posted a link to the commits a while back. It was starred so you should find it.

But what I found was that the code also needs a revision regarding the naming of token variables. But this is now also addressed

Well, looking at the large number of issues, I am impressed that Jianrui does much of this on their own it seems ... chapeau!

github.com/lvjr/tabularray/issues/553 <-

@JasperHabicht That's great news!

@DavidCarlisle (and maybe @JosephWright and @egreg) is relying on \dim_new:N \l_my_dim being a dimen register an implementation detail or not? I think it's not documented that way and I'd not say that using syntax such as \l_my_dim = 13pt is correct L3 code, so my opinion would be no. And I'd not use \@defaultunitsset on an L3 dimen as well...

What would be fine, imho, would be \@defaultunitsset\@tempdimc{#1}{pt} \dim_set:Nn \l_my_dim { \@tempdimc }, that's only using documented features of l3dim and some 2e macro.

(the poor variable name \l_my_dim aside)

@Skillmon well yes but if writing a 2e package pure l3 code is tricky you have to interface somewhere. I'd agree though it would be clearer to use a 2e named dimen, or give \@defaultunitsset an l3 definition or even just an l3 name and assert that it's using low level code but works. that is depending what the use case is, you might not need that double setting, just use the 2e dimen

@DavidCarlisle well yes, if that's fine for the use case I'd also just use the 2e dimen. It's more a question of if your life depended on it and your code should be as correct as possible, how would you do that for an L3 dim. Anyway, I'm getting my beauty sleep now, good night!

@JosephWright I just realised that l3fp doesn't understand the true<unit>s. (aahhh, I wanted to go to bed, now off for real!)

@Skillmon oh if my life depended on it I'd use context of course.