\expanded (was: Misleading cs names?)
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
Hello, On Sun, Dec 09, 2007 at 08:14:31PM +0100, Morten Høgholm wrote:
Usually the x expansion meant "uses \edef" and so they were all non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have functions doing full expansion like \numexpr and friends and \pdfstrcmp (does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me: the notes from the Oldenburg meeting mentions an \expanded primitive: \expanded <general text> Expandable command returning the full expansion of the tokens in <general text>. So since this pretty much exists inside \pdfstrcmp as it is now, it could go into pdfTeX 1.50 and we would be free of these problems. Except of course, \expanded is already used a lot in ConTeXt with different semantics.
Any opinions from the ConTeXt/pdfTeX people here?
I miss "\expanded", too.
A workaround for a \detokenize with expanded argument:
\pdfunescapehex{\pdfunescapehex{...}}
For LuaTeX \pdf(|un)escapehex are defined in package `pdftexcmds':
\pdf@unescapehex and \pdf@escapehex, both are expandable.
Disadvantages of the workaround:
* slower
* no <general text>, but macro argument
* detokenization happens.
But I assume, you want only expansion, not detokenization?
(then the latter can be achieved by
\detokenize\expandafter{\expanded{...}})
Biggest problem is probably a good name:
a) \expanded would be a nice name, but it clashes with ConTeXt.
I remember trouble with \unexpanded :-(
b) It would belong to e-TeX, but there isn't a e-TeX prefix:
\etexexpanded or \etexexpand
c) pdfTeX's convention with prefix "\pdf" (see \pdfstrcmp, \pdfescape*):
\pdfexpanded or \pdfexpand
d) longer names
My preference is c) to avoid trouble with macro name clashes.
I can live with a), then my package etexcmds would get a
new macro \etex@expanded.
Yours sincerely
Heiko
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Heiko Oberdiek wrote:
Hello,
On Sun, Dec 09, 2007 at 08:14:31PM +0100, Morten Høgholm wrote:
Usually the x expansion meant "uses \edef" and so they were all non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have functions doing full expansion like \numexpr and friends and \pdfstrcmp (does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me: the notes from the Oldenburg meeting mentions an \expanded primitive: \expanded <general text> Expandable command returning the full expansion of the tokens in <general text>. So since this pretty much exists inside \pdfstrcmp as it is now, it could go into pdfTeX 1.50 and we would be free of these problems. Except of course, \expanded is already used a lot in ConTeXt with different semantics.
Any opinions from the ConTeXt/pdfTeX people here?
well, \protected also existed in context before etex had it (and probably a few more) if \expanded is added as primitive i would probably \let the primitive to something else then the main problem that i see is that the 'context' \expanded is a user command so they would get confused if they want to use the primitive
Biggest problem is probably a good name: a) \expanded would be a nice name, but it clashes with ConTeXt. I remember trouble with \unexpanded :-( b) It would belong to e-TeX, but there isn't a e-TeX prefix: \etexexpanded or \etexexpand c) pdfTeX's convention with prefix "\pdf" (see \pdfstrcmp, \pdfescape*): \pdfexpanded or \pdfexpand d) longer names
My preference is c) to avoid trouble with macro name clashes. I can live with a), then my package etexcmds would get a new macro \etex@expanded.
we think (also speaking for taco) that \expanded as new primitive name is okay; the \pdfprefixed ones already are adding ugliness and we should avoid unnatural primitive names in context we'll deal with it somehow, after all, there are already clashes and since there is no such primitive, users don't expect it as such and when needed, they can deal with \primitive\expanded in general, adding new primitives with clashing names is only a problem for cross macropackage usage, but this can be dealt with since there is not that much shared (my experience is that the biggest problem is not in primitive usage but in catcode and lccode mess) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Heiko Oberdiek wrote:
Hello,
On Sun, Dec 09, 2007 at 08:14:31PM +0100, Morten Høgholm wrote:
Usually the x expansion meant "uses \edef" and so they were all non-expandable. But now that we have pdfeTeX'ed the l3 kernel, we have functions doing full expansion like \numexpr and friends and \pdfstrcmp (does \edef on both arguments) used in \tlist_if_eq:xxTF. This reminds me: the notes from the Oldenburg meeting mentions an \expanded primitive: \expanded <general text> Expandable command returning the full expansion of the tokens in <general text>. So since this pretty much exists inside \pdfstrcmp as it is now, it could
Can someone please post an example of intended use in the l3 kernel in "plain"-style, just so I understand the usage?
Any opinions from the ConTeXt/pdfTeX people here?
ConTeXt's \expanded macro expands its argument fully except for the very first item in it, which is handy for macros that need expanded arguments, so I assume the actual goals are very similar. Its definition is essentially this: \def\expanded#1{\edef\lastexpanded{\noexpand#1}\lastexpanded} With the new primitive, it could be rewritten as: \let\normalexpanded\expanded \def\expanded{\afterassignment\doexpanded\let\next=} \def\doexpanded{\normalexpanded\bgroup\noexpand}
Biggest problem is probably a good name: a) \expanded would be a nice name, but it clashes with ConTeXt. I remember trouble with \unexpanded :-( b) It would belong to e-TeX, but there isn't a e-TeX prefix: \etexexpanded or \etexexpand c) pdfTeX's convention with prefix "\pdf" (see \pdfstrcmp, \pdfescape*): \pdfexpanded or \pdfexpand d) longer names
My preference is c) to avoid trouble with macro name clashes. I can live with a), then my package etexcmds would get a new macro \etex@expanded.
Hans and I think a) would be fine. c) is somewhat silly as it is not related to pdftex, and also a) combines nicely with the already present \unexpanded. Best wishes, Taco
![](https://secure.gravatar.com/avatar/d70a3c337395642ea2431da028ce65fe.jpg?s=120&d=mm&r=g)
On Mon, 10 Dec 2007 11:44:34 +0100, Taco Hoekwater wrote: Hi Taco,
the notes from the Oldenburg meeting mentions an \expanded primitive: \expanded <general text> Expandable command returning the full expansion of the tokens in <general text>. So since this pretty much exists inside \pdfstrcmp as it is now, it could
Can someone please post an example of intended use in the l3 kernel in "plain"-style, just so I understand the usage?
I would assume the following should be equivalent except for the latter being expandable. \def\cmd#1{\edef\tempa{#1}\expandafter\cmd\expandafter{\tempa}} \def\cmd#1{\expandafter\cmd\expandafter{\expanded{#1}}}
ConTeXt's \expanded macro expands its argument fully except for the very first item in it, which is handy for macros that need expanded arguments, so I assume the actual goals are very similar.
Yes, I think so too.
a) \expanded would be a nice name, but it clashes with ConTeXt. I remember trouble with \unexpanded :-(
Hans and I think a) would be fine. c) is somewhat silly as it is not related to pdftex, and also a) combines nicely with the already present \unexpanded.
a) is what I was hoping for. :-) -- Morten
![](https://secure.gravatar.com/avatar/cdac1bce4ec96619cde73d2f2be4e66d.jpg?s=120&d=mm&r=g)
Morten Høgholm
I would assume the following should be equivalent except for the latter being expandable.
\def\cmd#1{\edef\tempa{#1}\expandafter\cmd\expandafter{\tempa}}
\def\cmd#1{\expandafter\cmd\expandafter{\expanded{#1}}}
No. The former would complain about isolated # tokens in #1 (and collapse double ones). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
![](https://secure.gravatar.com/avatar/d70a3c337395642ea2431da028ce65fe.jpg?s=120&d=mm&r=g)
On Mon, 10 Dec 2007 17:33:14 +0100, David Kastrup wrote:
Morten Høgholm
writes: I would assume the following should be equivalent except for the latter being expandable.
\def\cmd#1{\edef\tempa{#1}\expandafter\cmd\expandafter{\tempa}}
\def\cmd#1{\expandafter\cmd\expandafter{\expanded{#1}}}
No. The former would complain about isolated # tokens in #1 (and collapse double ones).
Ah yes (and sorry for the silly example above - it's really remarkably bad). You comment reminded me of something I added to l3tlp.dtx under the entry: r594 | morten | 2007-06-10 23:32:58 +0200 (Sun, 10 Jun 2007) | 2 lines Tried to make functions treat hash marks as uniform as possible % A word of warning is appropriate here: Token list pointers are % implemented as macros and as such currently inherit some of the % peculiarities of how \TeX\ handles "#"s in the argument of % macros. In particular, the following actions are legal % \begin{verbatim} % \tlp_set:Nn \l_tmpa_tlp{##1} % \tlp_put_right:Nn \l_tmpa_tlp{##2} % \tlp_set:No \l_tmpb_tlp{\l_tmpa_tlp ##3} % \end{verbatim} % |x| type expansions where macros being expanded contain |#|s do not % work and will not work until there is an |\expanded| primitive in % the engine. If you want them to work you must double |#|s another % level. All the more reason for \expanded... 'night, -- Morten
![](https://secure.gravatar.com/avatar/d8110a8a8a97be0803549ea5ee2e638b.jpg?s=120&d=mm&r=g)
2007/12/10, Taco Hoekwater
Biggest problem is probably a good name: a) \expanded would be a nice name, but it clashes with ConTeXt. I remember trouble with \unexpanded :-( b) It would belong to e-TeX, but there isn't a e-TeX prefix: \etexexpanded or \etexexpand c) pdfTeX's convention with prefix "\pdf" (see \pdfstrcmp, \pdfescape*): \pdfexpanded or \pdfexpand d) longer names
My preference is c) to avoid trouble with macro name clashes. I can live with a), then my package etexcmds would get a new macro \etex@expanded.
Hans and I think a) would be fine. c) is somewhat silly as it is not related to pdftex, and also a) combines nicely with the already present \unexpanded.
I agree. A patch is welcome. :-) Best Martin
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Mon, Dec 10, 2007 at 01:26:14PM +0100, Martin Schröder wrote:
2007/12/10, Taco Hoekwater
: Biggest problem is probably a good name: a) \expanded would be a nice name, [...]
Hans and I think a) would be fine. [...]
I agree. A patch is welcome. :-)
Patch 885.
Yours sincerely
Heiko
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Heiko Oberdiek wrote:
On Mon, Dec 10, 2007 at 01:26:14PM +0100, Martin Schröder wrote:
2007/12/10, Taco Hoekwater
: Biggest problem is probably a good name: a) \expanded would be a nice name, [...] Hans and I think a) would be fine. [...] I agree. A patch is welcome. :-)
Patch 885.
I suspect there will be a problem with
\setvalue{begin\expanded{\getvalue{relax}}}
but have not time to delve into that right now.
I suspect this, because \directlua in luatex has similar
problems wrt. the 'current string', and I had to do
introduce a variable to save that, like this:
procedure conv_toks;
u:str_number;
{...}
u:=0;
if str_start_macro(str_ptr)
![](https://secure.gravatar.com/avatar/c4fb1aecd98bbaa9856f8c421db294e0.jpg?s=120&d=mm&r=g)
On Tue, Dec 11, 2007 at 05:54:42PM +0100, Taco Hoekwater wrote:
Heiko Oberdiek wrote:
Patch 885.
I suspect there will be a problem with
\setvalue{begin\expanded{\getvalue{relax}}}
but have not time to delve into that right now.
I suspect this, because \directlua in luatex has similar problems wrt. the 'current string', and I had to do introduce a variable to save that, like this:
procedure conv_toks; u:str_number; {...}
u:=0; if str_start_macro(str_ptr)
0 then begin if str_ptr=u+1 then decr(str_ptr) else begin {copy old string to the top location} i:=0; str_room(length(u)); while i
In pdfTeX 1.40.5 all the primitives (\pdfstrcmp, \pdfescape*, ...)
are surrounded by save_cur_string and restore_cur_string. They
do quite similar:
@dsave_cur_string==if str_start[str_ptr]
![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Heiko Oberdiek wrote: Glad to hear you already had that covered. There are not many primitives in this category left in luatex, but I will import that code near-automatically in the next merge anyway. (luatex is still pdftex 1.40.3) Best wishes, Taco
participants (6)
-
David Kastrup
-
Hans Hagen
-
Heiko Oberdiek
-
Martin Schröder
-
Morten Høgholm
-
Taco Hoekwater