Skip to main content
Fixed spelling error in code snippets
Source Link
siracusa
  • 13.7k
  • 2
  • 34
  • 57

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \\\ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \\ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\\def\\#1\\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \\ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \\ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \\ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

Fixing a site bug of disappearing double backslashes: https://tex.meta.stackexchange.com/questions/7168/double-backslashes-disappear-from-code
Source Link
David Carlisle
  • 829.4k
  • 74
  • 1.7k
  • 2.6k

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \ \\ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \\ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information wasswas recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user defined-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information wass recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

With inconclusive comments, I decided to look again for an explanation in the TeXBook, but with no success. However this led to another example. In the answer to exercise 24.6 Knuth shows how to make the control sequence \cs into an implicit space using \futurelet.

\def\\#1\\{}\futurelet\cs\\ \ 

You can try this out with the minimal

\tt \def\\#1\\{}\futurelet\cs\\ \ % example a.\cs b.c \def\empty{} % Trying with an empty macro a.\empty b.c \bye 

The obvious next port of call was the original TeX source code itself. As Pascal is a typed language, my suspicion was that using delimiters in this manner, would conserve one string name.

Strings are defined in Part4, String Handling. All strings--as a matter of fact almost everything in TeX--are translated to integers and indexed. As far as TeX is concerned the name of a primitive macro or the string of an error message are no different they are all placed in str_pool.

When the original WEB system program called TANGLE processed the TEX.WEB file, it ouputted a Pascal program TEX.PAS (now it is CWEB and a C program) and also a string file called TEX.POOL which held all the strings used. The INITEX program read the latter file, where each string appeared as a two-digit decimal length followed by the string itself, and the information was recorded in TEX's string memory. INITEX would later on produce a binary format file which can subsequently be read at high speed by the TeX engine. (You can view the TEX.POOL file by searching for it in your distribution).

Given LaTeX's history, it made sense to use delimiters in this manner as it conserved one string.

I haven't looked carefully at the scanning routines for user-defined strings during normal typesetting operations i.e., without the source being passed through INITEX. In all probability the same mechanism is used and it is apparent that this will save some memory space, however little this is.

If one should use delimiters in such a manner is debatable as it tends to obscure the code and perhaps this is the reason for them being generally absent in packages. Rather two or three string names should be reserved for this purpose. If there is one exception I would make it would be for macros similar to the one Knuth defined:

 \def\\#1\ 

It has a symmetry which one could argue has a certain beauty!

Special thanks to all the people that posted comments and especially to Lev Bishop for the additional example.

rephrased some text
Source Link
yannisl
  • 121.9k
  • 35
  • 307
  • 579
Loading
Source Link
yannisl
  • 121.9k
  • 35
  • 307
  • 579
Loading