Comments (11)
I think c
behaviour here is consistent. The fact that c
locally defines the token to \relax
is slightly weird but TeX is TeX, and c
has done that for over 30 years and I don't think we can or should change that.
The questionable thing here is the behaviour of \tl_item:Nn
if the first argument is not expandable (which arguably should never occur as it's documented as being a tl.)
\documentclass{article}
\begin{document}
\ExplSyntaxOn
\let\foo\relax
\tl_show:e { \tl_item:Nn \foo { 1 } }
\ExplSyntaxOff
\end{document}
shows \foo
.
We could document that specifically for \tl_item:Nn
or more generally document that in functions where the N
variant is effectively a variant of an n
base function, the argument passed to the base is the first level expansion of the token (which is the token itself if that token is not expandable)
from latex3.
There is \debug_on:n
, so I don't think it's too difficult to check that token lists are indeed token lists only if debug support is turned on (with no performance penalty when debug is turned off).
from latex3.
There is
\debug_on:n
, so I don't think it's too difficult to check that token lists are indeed token lists only if debug support is turned on (with no performance penalty when debug is turned off).
That doesn't catch this particular case so we might need to adjust there
from latex3.
It should catch this case with correct implementation right? Because something that is implicitly defined by c
-type expansion would have meaning \relax
, which is not a token list (which must have meaning of a macro).
from latex3.
It seems the current convention in l3debug.dtx
is to not do checks if low-level errors will always occur.
Lines 684 to 693 in 35b5295
from latex3.
It seems the current convention in
l3debug.dtx
is to not do checks if low-level errors will always occur.
Should the convention be kept anyway? (given that it isn't too necessary to optimize for performance in debugging mode) Having more informative error message can never hurt, and the behavior of "low-level TeX" can be hard to predict.
from latex3.
@davidcarlisle Should we try to pick those up in debug mode?
from latex3.
It seems the current convention in
l3debug.dtx
is to not do checks if low-level errors will always occur.Should the convention be kept anyway? (given that it isn't too necessary to optimize for performance in debugging mode) Having more informative error message can never hurt, and the behavior of "low-level TeX" can be hard to predict.
Well at the low level we do know how things are implemented, which is the point here - for example, \int_set:Nn \l_some_undefined_int
will error, so we don't need to trap it at the macro level
from latex3.
@davidcarlisle Should we try to pick those up in debug mode?
I'd be tempted to document this as a feature, both \csname
defining the token as \relax
and \expandafter\foo\unexpandabletoken
being \foo\unexpandabletoken
are basic tex functionality used all over and to catch them in debug mode would make debug mode deviate even more from the normal flow, I'm sure it's possible but that has its own risks.
For c
, I think we should globally document that the token passed on will be locally let to \relax
if not defined previously.
I don't think there is a general notion currently of :N
being a variant of an :n
base (in fact interface3 explicitly says n
and N
pass the arguments on with no modification), which would mean that documenting specifically for \tl_item:Nn
that it is \tl_item:on
although again interface3 doesn't actually say what o
does if the token to be expanded once isn't expandable
but we could document that in that case the token is passed as-is (rather than making it an error)
from latex3.
Well at the low level we do know how things are implemented, which is the point here - for example,
\int_set:Nn \l_some_undefined_int
will error, so we don't need to trap it at the macro level
Is it? It isn't too hard to imagine cases where it doesn't lead to an error
\int_set:Nn \use_none:nn {1}
interface3 doesn't actually say what
o
does if the token to be expanded once isn't expandable but we could document that in that case the token is passed as-is (rather than making it an error)
Personally it's hard for me to imagine a case where that behavior is expected (can anyone give me one?)
If there isn't, it seems more likely to be an user error. So I don't see much advantage in making it silently eat up the error (of course the disadvantage would be that it is harder for the user to find the error), especially because we don't need to care about performance that much in debug mode.
from latex3.
Well at the low level we do know how things are implemented, which is the point here - for example,
\int_set:Nn \l_some_undefined_int
will error, so we don't need to trap it at the macro levelIs it? It isn't too hard to imagine cases where it doesn't lead to an error
\int_set:Nn \use_none:nn {1}
interface3 doesn't actually say what
o
does if the token to be expanded once isn't expandable but we could document that in that case the token is passed as-is (rather than making it an error)Personally it's hard for me to imagine a case where that behavior is expected (can anyone give me one?)
If there isn't, it seems more likely to be an user error. So I don't see much advantage in making it silently eat up the error (of course the disadvantage would be that it is harder for the user to find the error), especially because we don't need to care about performance that much in debug mode.
But that is stuff that would be a hard error even outside debug mode. Remember that what l3debug
is for is checking correctness of expl3
code, largely - so stuff that you can test for anyway isn't in scope. In your example, any simple test probing the functionality will pick up an issue.
from latex3.
Related Issues (20)
- `\prop_put_if_new:Nnn` vs `\prop_put_if_not_in:Nnn` HOT 2
- Symmetry/Consistency among fparray and intarray functions HOT 3
- \IfInstanceExistTF undefined with -dev formats HOT 2
- \iow_shell_open:Nn can't work
- Loading `expl3-generic.tex` in LuaMetaTeX fails with `expl3.lua:421: table index is nil` since TeX Live 2024 HOT 6
- l3pdf feature request: providing variants for pdf-object-related functions that expand their object name argument HOT 9
- visible spaces in l3sys-query results HOT 6
- Can't define a new fp function based on fact() HOT 1
- New iow function that respects `\showstream`
- support of CMYK colors in dvisvgm backend HOT 9
- peek_analysis_map_inline does not work for active space HOT 7
- char_generate:nn creates new text input level now? HOT 10
- (Not a bug) \tl_gset:Nx is no longer directly mapped to \xdef? HOT 5
- peek_analysis_map_inline does not unwind input level for some reason HOT 1
- Tag 2024-05-08 not merged into main branch HOT 3
- l3backend-dvips.pro not found by kpsewhich despite being present HOT 4
- `\GetDocumentCommandArgSpec` and friends cannot handle optimized m-type cmds and envs HOT 1
- Loading 'expl3.sty' aborted when I compile documentation using xelatex HOT 2
- Minor formatting in `l3prop`, `l3keys` and `l3int` doc HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from latex3.