latex3 icon indicating copy to clipboard operation
latex3 copied to clipboard

Wishlist: Implementation of \cs_use:c

Open Vidabe opened this issue 6 years ago • 10 comments

I think that it might come in handy to have a \cs_use:c command (which would work equivalent to \tl_use:c and friends) as the disadvantage of \use:c is that it doesn't check if the command exists at all.

The main reason for my request is that I alway make the mistake of thinking "\tl_use:c checks if the variable exists so \use:c does too" which always leads to a bit of debugging as I (mistakenly) rely on the (non-existent) error-checking.

Vidabe avatar Jan 08 '19 17:01 Vidabe

This seems like a reasonable argument to me to differentiate between \use:c and \cs_use:c...

wspr avatar Jan 09 '19 04:01 wspr

Te issue though is that variables have to be declared but cs's don't: \cs_set:Npn without \cs_new:Npn is entirely valid. So I'm not sure we can have 100% consistency here.

josephwright avatar Jan 09 '19 13:01 josephwright

Why is that an issue? Isn’t it orthogonal to the case at hand? I’m not sure, incidentally, why we couldn't have a \cs_new:N to precede \cs_set…

To me the request is simply that \cs_use:c would be a useful command to have (presumably to catch typos or incorrect code logic).

wspr avatar Jan 09 '19 16:01 wspr

No! Or rather, not quite. To both Joseph and Will !

The issues is:

  1. The command \cs_if_exist_use:c does exists (sic) already so there is no need to add this functionality.

  2. \cs . . . commands/control sequences are for creating and manipulating functions (mostly fully expandable). \tl . . . commands/control sequences are for creating manipulating arbitrary token lists. The fact that some functions are implemented at a lower-level by the same TeX-level functionality (\def, \let etc.) must not be make you think that they are at all similar at the LaTeX3 programming level. I know that this is a difficult brain-adjustment for ancient TeX hackers like me, but I am slowly getting there

  3. Mostly aimed at fellow Team members: look again at the \use . . . functions in Sections 4.4 and 4.5. As I have written previously elsewhere, these should all,start with a module name.

  4. Further analysis suggests that, for all except one, this module should be \tl_ . The exception is (surprise!?) \use:c , which should be
    \cs_use:c Just think about how different this one is from all the others. Please!

car222222 avatar Jan 10 '19 05:01 car222222

IMO the proposed \cs_use:c with a check isn’t the same as \cs_if_exist_use:c — what I (and the OP I suspect) would find useful is a command which throws an error if I haven’t defined the csname.

Since \tl_use:(N/c) throws an error, I think it’s consistent to have a \cs_use:(N/c) that does too.

On the rest of the \use_ commands… sure, they don’t have a module, so they’re a bit weird, but I don’t think we gain much from chasing consistency here. On the fact that \use:c is different from the others — well, maybe just that one should be slowly deprecated?

wspr avatar Jan 10 '19 14:01 wspr

Yes, Will, I see the distinction. But I still think that \use:c must be renamed as \cs_use:c.

So the error message version would need a new name, maybe \cs_use_or_error:c .

But, as Joseph wrote, there is still no valid comparison with \tl . . . commands.

I agree that if \use:c is weeded out, all we need to do is to explain that \use . . . always refers to doing things with token lists (I.e. the tl_ is omitted from their names).

car222222 avatar Jan 10 '19 15:01 car222222

Apologies for the late reply (and for possible broken english; I am tired). But yes, as Will said, the idea is to catch typos and incorrect logic (but mostly typos) and having a \use:c command which enforces that the csname exists. It is for cases where I know that the csname has to exist. I wonder if it would also help to write a bit of cleaner code, as it would theoretically "enforce" people to define commands via \cs_new first before they use them in \cs_set. (not quite sure if I understand the problem) (of course \use:c would still exist).

I also don't think that the existence of \cs_if_exist_use:c is a good reason to not implement it. Using the same argument I could propose that \int_incr:N should be deleted as one could simply write \int_add:Nn \cs { 1 } (same for int_decr:N ), or that there is no need for \str_clear_new:N as it is just a shortcut for \str_if_exist:NTF in combination with \str_new:N and \str_clear:N. Or -- a more general example -- there is no need for C (and others) to allow the syntax ++int if one could (and can) simply write int = int + 1. But being able to write++int is just much more handy then the alternative (at least as someone who writes in Fortran I imagine it to be more handy).

Renaming \use:c to \cs_use:c will probably create more confusion, as the parallels to the likes of \tl_clear:c would be (wrongly) more obvious. Maybe something like \use_as_cs:c? It would show that it does something with tokens (like the other \use commands) and that it creates a command sequence. And the command with error checking would be \use_as_cs_or_error:c ? Bit clunky, but it would work.

Vidabe avatar Jan 10 '19 17:01 Vidabe

FWIW I've started implementing some of the changes outlined in some broader discussion around this issue. I'll make it public for discussion once I've ironed out some wrinkles and checked for more consistency across variables.

wspr avatar Jan 14 '19 06:01 wspr

I suspect that there are almost no uses of \use:c that could not be replaced by a checking-for-existence \cs_use:c, or by \exp_not:c.

So we could imagine deprecating \use:c.

blefloch avatar Jan 14 '19 13:01 blefloch

I just realised I am now years behind trying to complete this change. I got stalled when my pull request no longer cleanly merged :) I will try to get back to this as a priority...

wspr avatar Feb 13 '21 11:02 wspr