# Active characters let to a (non-active) character

It seems that if I \let\amp&, the alignment tab & can be replaced by \amp everywhere (e.g., in the preamble and in the body of an \halign). It is also possible to make the character & active, and give it the same meaning by \catcode\&=13 \let&\amp. It seems that that active & which has been let to the alignment tab & can be used wherever an alignment tab & was used.

This idea is quite general: we can define macro which takes a character as its argument, lets its active version to itself (with its current catcode), and finally makes the character active. This uses an \lccode trick, described by Phillipe Goutet.

\def\activate#1{\begingroup
\lccode\~=#1%
\lowercase{\endgroup \let~#1}%
\catcode#1=13\relax}


Here is an example to show that this operation does not break most uses I can think of for , &, etc. In particular, $$...$$ is still recognized, and macro parameters too. \activate & \halign{#&#\cr a&b\cr} \activate    \activate ^    \activate _
$$x^2_2 + y^2_2$$

\activate #
\def\myshow#1{\show#1}
\myshow #
\bye


So my question is: "what are the drawbacks of this approach?" It allows a fix for peeking ahead with \futurelet in alignments.

-
Might be one for c.t.t: I wonder what the real experts think! –  Joseph Wright Feb 23 '11 at 22:23
@Joseph: I remember you mentionning somewhere an "outstanding issue with \peek_ahead_... in (nested?) alignments". Could you please point me to a description of that? It would make my c.t.t. post more complete. –  Bruno Le Floch Feb 24 '11 at 12:48
The best I can offer at the moment is the siunitx source. Take a look at \siunitx_table_collect_get:, and using \peek_catcode_ignore_spaces:NTF (with appropriate values) in place of the 'by hand' version I have there at the moment. Result: lots of errors, and I think at some stage disaster (it's been a while since I tested this). –  Joseph Wright Feb 25 '11 at 22:27
@Joseph: thank you. To prevent \futurelet from triggering the construction of a cell if it hits a & or \cr, we normally use: \safebegin\futurelet\@let@token\macro, where \safebegin is \iffalse{\fi\ifnum}=0\fi and \macro starts with a \safeend, defined as \ifnum{=0}\fi. But this breaks when put in an \halign preamble (as in siunitx). –  Bruno Le Floch Feb 26 '11 at 5:34
Minimal example: set \def\safeboxalign{\safeend\vbox\bgroup\halign\bgroup##} and use the \safebegin and \safeend above. Then \halign{#\cr \safebegin \futurelet \dummy \safeboxalign \cr ABC\cr \egroup \egroup \cr} works. But now, move the \safebegin ... \safeboxalign to the preamble of the main \halign (before #). The result, \halign{\safebegin \futurelet \dummy \safeboxalign #\cr \cr ABC\cr \egroup \egroup \cr}, breaks horribly. --- OTOH, redefining \cr and an active & seems to work. –  Bruno Le Floch Feb 26 '11 at 5:37
my plan would be to have that at the very start of the TeX run. Then all delimited macros would be defined with an active & as a delimiter. Your answer still holds very true for braces: implicit braces will never be a good alternative to explicit ones. --- Another point is that I wouldn't call the preamble of an \halign "normal boxing mode": it is definitely scanning (in some weird way). –  Bruno Le Floch Mar 1 '11 at 19:07
@Bruno: I was talking about the & which separate the actual cells. The reading of the preamble is different. That is moer scanning mode. Note that & and \cr are actually catched by the TeX parser and expanded even when TeX isn't in expanding mode, which explains why \futurelet doesn't work like Hendrik expected. Defining & like you do effective hides the token from the parser until it is really expanded. –  Martin Scharrer Mar 1 '11 at 19:16
In \let\amp& \halign{(#)\amp [#]\cr ab\amp cd\cr}, the \amp is seen both in the preamble and in the body. The parser behaves in this situation in a way similar to how conditionals are treated: \def\amp{&} would not be seeen in the preamble. –  Bruno Le Floch Mar 1 '11 at 19:48