[NTG-pdftex] \expanded

Joseph Wright joseph.wright at morningstar2.co.uk
Thu May 17 08:30:24 CEST 2018

On 17/05/2018 00:12, Ross Moore wrote:
> Hi Karl, and others.
>
> On May 17, 2018, at 8:57 AM, Karl Berry <karl at freefriends.org<mailto:karl at freefriends.org>> wrote:
>
> Doing a grep on /usr/local/texlive/2018/texmf-dist/tex/, I see \expanded
> is used in a couple oberdiek packages, context, and mathspec. I did not
> try to figure out if the mathspec usage is compatible. It might be worth
> notifying its author at some point as a courtesy. FWIW ...
>
>
> Is  \expanded  really equivalent to that  xelatex  definition below:
>
> xelatex/mathspec/mathspec.sty:129:\providecommand\expanded[1]{\edef\@tempa{#1}\@tempa}
>
> It seems to me that it should be, but maybe there is actually a slight difference.
> So it would be nice to see some practical applications;
> e.g., where a package author had a specific desire, or absolute need (?),
> to avoid going via a temporary container-like macro such as  \@tempa  above.
>
> Otherwise, why the need for this as a primitive?
> Convenience only, is not normally a good enough reason to add a primitive.

Hello Ross,

The primitive definition differs from the \edef version in that

- It does not double # tokens
- It is expandable

The latter is the big thing, and the reason the team have asked that
this long-standing suggestion be added to engines. At present, if you
want to arrange for 'function-like' behaviour, you can use \romannumeral
to expand material

\def\foo#1{\expandafter\fooaux\romannumeral-q#1 }

which will work but only up to the first non-expandable item in #1 (and
also looses any leading spaces). The result is that if you wish to write
expandable functions which are themselves expandable, you need to be
careful in how everything is constructed such that nothing is 'output'
until all processing is done. That often comes with a code complexity
and performance cost, and is not always achievable. (See the various
'f-type expandable' functions in expl3.)

An \expanded primitive makes it much more convenient to create such
approaches, and matches the expansion carried out by e.g. \pdfstrcmp.
For the work of the team in expl3, this would significantly aid
consistency and allow more 'easy' expandable programming. The code
addition is also small compared with many other 'new' (post-e-TeX)
primitives, and \expanded is already present in LuaTeX. As such, we hope
that the request can be actioned: we will make similar requests for
XeTeX and (u)pTeX, such that all major engines have the functionality.

Regards,

Joseph
`