diff options
Diffstat (limited to 'Master/texmf-dist/source/latex/expl3/expl3.tex')
-rw-r--r-- | Master/texmf-dist/source/latex/expl3/expl3.tex | 753 |
1 files changed, 0 insertions, 753 deletions
diff --git a/Master/texmf-dist/source/latex/expl3/expl3.tex b/Master/texmf-dist/source/latex/expl3/expl3.tex deleted file mode 100644 index 8d9e1880667..00000000000 --- a/Master/texmf-dist/source/latex/expl3/expl3.tex +++ /dev/null @@ -1,753 +0,0 @@ -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% based on version for the TUGboat proceedings -% Copyright 1997--98 David Carlisle, Chris Rowley, Frank Mittelbach -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% $Id: expl3.tex 246 2004-11-11 08:20:37Z mittelba $ -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\documentclass{article} - -\usepackage{shortvrb} -\MakeShortVerb{\|} - -% A couple of \provide.. so document runs with -% both ltugproc and ltxguide classes -% -\providecommand \m [1]{$\langle$\textit{#1}$\rangle$} -%\providecommand \netaddress {\date} -\providecommand \acro [1]{\textsc{\MakeLowercase{#1}}} -\providecommand \ie {i.e.,~} -\providecommand \eg {e.g.,~} - -\hyphenation{para-meters para-meter} -% I have found at least 3 other hyphenations of this in various refs, -% but I did also find this, which is my personal favourite ---chris - -\hyphenation{ignore ignored ignores} - -\begin{document} - -\title{The \LaTeX3 Programming Language---\\ -a proposed system for \TeX\ macro programming} - - -\author{\copyright~David Carlisle, Chris Rowley and\\ Frank Mittelbach\\ -\LaTeX3 project\\ -\texttt{latex-l@urz.uni-heidelberg.de}} - - -\maketitle - -\begin{abstract} - -This paper gives s brief introduction to a new set of programming -conventions that have been designed to meet the requirements of -implementing large scale \TeX\ macro programming projects such as -\LaTeX. - -The main features of the system described are: -\begin{itemize} -\item classification of the macros (or, in \LaTeX{} terminology, - commands) into \LaTeX{} functions and \LaTeX{} parameters, and also - into modules containing related commands; -\item a systematic naming scheme based on these - classifications; -\item a simple mechanism for controlling the expansion of a function's -arguments. -\end{itemize} -A system such as this is being used experimentally as the basis for -\TeX{} programming within the \LaTeX3 project. -Note that the language is not intended for either -document mark-up or style specification. - -This paper is based on a talk given by David Carlisle in San -Francisco, July 1997, but it describes the work of several people: -principally - Frank Mittelbach and - Denys Duchier, -together with - Johannes Braams, - David Carlisle, - Michael Downes, - Alan Jeffrey, - Chris Rowley and - Rainer Sch\"opf. -\end{abstract} - -\vspace{4pt} - - -\section{Introduction} - -This paper describes the conventions for a \TeX-based programming -language which is intended to provide a more consistent and rational -environment for the construction of large scale systems, such as -\LaTeX, using \TeX{} macros. - -Variants of this language have been in use by The \LaTeX3 Project Team -since around 1990 but the syntax specification to be outlined here -should \emph{not} be considered final. This is an experimental -language thus many aspects, such as the syntax conventions and naming -schemes, may (and probably will) change as more experience is gained -with using the language in practice. - -The next section shows where this language fits into a complete -\TeX-based document processing system. We then describe the major -features of the syntactic structure of command names, including the -argument specification syntax used in function names. - -The practical ideas behind this argument syntax will be explained, -together with the semantics of the expansion control mechanism and the -interface used to define variant forms of functions. The paper also -discusses some advantages of the syntax for parameter names. - -As we shall demonstrate, the use of a structured naming scheme and of -variant forms for functions greatly improves the readability of the -code and hence also its reliability. Moreover, experience has shown -that the longer command names which result from the new syntax do not -make the process of \emph{writing} code significantly harder -(especially when using a reasonably intelligent editor). - -The final section gives some details of our plans to distribute parts -of this system during the next year. -More general information concerning the work of the \LaTeX3 Project -can be found in~\cite{tub:MR98-1}. - - -\section{Languages and interfaces} -\label{sec:langs} - -It is possible to identify several distinct languages related to the -various interfaces that are needed in a \TeX-based document processing -system. This section looks at those we consider most important for -the \LaTeX3 system. - -\begin{description} -\item[Document mark-up] This comprises those commands (often called tags) - that are to embedded in the document (the |.tex| file). - - It is generally accepted that such mark-up should be essentially - \emph{declarative}. - It may be traditional \TeX-based mark-up such as - \LaTeXe, as described in~\cite{A-W:LLa94} and~\cite{A-W:GMS94}, - or a mark-up language defined via \acro{SGML} or \acro{XML}. - - One problem with more traditional \TeX\ coding conventions (as - described in~\cite{A-W:K-TB}) is that the names and syntax of \TeX's - primitive formatting commands are ingeniously designed to be - `natural' when used directly by the author as document mark-up or in - macros. Ironically, the ubiquity (and widely recognised - superiority) of logical mark-up has meant that such explicit - formatting commands are almost never needed in documents or in - author-defined macros. Thus they are used almost exclusively by - \TeX{} programmers to define higher-level commands; and their - idiosyncratic syntax is not at all popular with this community. - Moreover, many of them have names that could be very useful as - document mark-up tags were they not pre-empted as primitives (\eg - |\box| or |\special|). - -\item[Designer interface] This relates a (human) typographic - designer's specification for a document to a program that `formats - the document'. It should ideally use a declarative language that - facilitates expression of the relationship and spacing rules specified - for the layout of the various document elements. - - This language is not embedded in document text and it will be very - different in form to the document mark-up language. For - \acro{SGML}-based systems the \acro{DSSSL} language may come to play - this role. For \LaTeX, this level was almost completely missing - from \LaTeX2.09; \LaTeXe\ made some improvements in this area but it - is still the case that implementing a design specification in - \LaTeX\ requires far more `low-level' coding than is acceptable. -\item[Programmer interface] - This language is the implementation - language within which the basic typesetting functionality is - implemented, building upon the primitives of \TeX\ (or a - successor program). - It may also be used to implement the previous - two languages `within' \TeX, as in the current \LaTeX\ system. -\end{description} - -Only the last of these three interfaces is covered by this paper, -which describes a system aimed at providing a suitable basis for -coding large scale projects in \TeX{} (but this should not preclude its -use for smaller projects). Its main distinguishing features are -summarised here. - -\begin{itemize} -\item A consistent naming scheme for all commands, including \TeX\ - primitives. -\item The classification of commands as \LaTeX{} functions or \LaTeX{} - parameters, and also their division into modules according to their - functionality. -\item A simple mechanism for controlling argument expansion. -\item Provision of a set of core \LaTeX{} functions that is sufficient - for handling programming constructs such as queues, sets, - stacks, property lists. -\item A \TeX{} programming environment in which, for example, all - white space is ignored. -\end{itemize} - -\section{The naming scheme} -\label{sec:scheme} - -The naming conventions for this programming language distinguish -between \textit{functions} and \textit{parameters}. Functions can have -arguments and they are executed. Parameters can be assigned values -and they are used in arguments to functions; they are not directly -executed but are manipulated by mutator and accessor functions. -Functions and parameters with a related functionality (for example -accessing counters, or manipulating token-lists, etc.)\ are collected -together into a -\textit{module}. - - -Note that all these terms are only \LaTeX{} terminology and are not, -for example, intended to indicate that the commands have these -properties when considered in the context of basic \TeX{} or in any -more general programming context. - - -\subsection{Examples} -\label{sec:ex} - -Before giving the details of the naming scheme, here are a few typical -examples to indicate the flavour of the scheme; first some parameter -names. -\begin{quote} -|\l_tmpa_box| is a local parameter (hence the~|l_| prefix) -corresponding to a box register.\\ -|\g_tmpa_int| is a global parameter (hence the~|g_| prefix) -corresponding to an integer register (\ie a \TeX{} count register).\\ -|\c_empty_toks| -is the constant~(|c_|) token register parameter that is for ever empty. -\end{quote} -Now here is an example of a typical function name. - -|\seq_push:Nn| is the function which puts the token list specified by -its second argument onto the stack specified by its first argument. -The different natures of the two arguments are indicated by the~|:Nn| -suffix. The first argument must be a single token which `names' -the stack parameter: such single-token arguments are denoted~|N|. -The second argument is a normal \TeX\ `undelimited argument', which -may either be a single token or a balanced, brace-delimited token -list (which we shall here call a \textit{braced token list}): the~|n| -denotes such a `normal' argument form. - -|\seq_push:cn| would be similar to the above, but in this case the~|c| -means that the stack-name is specified in the first argument by a -token list that expands, using |\csname...|, to a control sequence that -is the \emph{name} of the stack parameter. - -\noindent -The names of these two functions also indicate that they are in the -module called |seq|. - - -\subsection{Formal syntax of the conventions} -\label{sec:namesyn} - -We shall now look in more detail at the syntax of these names.\\ -The syntax of parameter names is as follows: - \begin{quote} - |\|\m{access}|_|\m{module}|_|\m{description}|_|\m{type} - \end{quote} -The syntax of function names is as follows: - \begin{quote} - |\|\m{module}|_|\m{description}|:|\m{arg-spec} - \end{quote} - - -\subsection{Modules and descriptions} -\label{sec:modules} - -The syntax of all names contains -\begin{quote} - \m{module} and \m{description}: -\end{quote} -these both give information about the command. - -A \textit{module} is a collection of -closely related functions and parameters. -Typical module names include~|int| for integer parameters -and related functions,~|seq| for sequences and~|box| for boxes. - -Packages providing new programming functionality will add new modules -as needed; the programmer can choose any unused name, consisting -of letters only, for a module. - -The \textit{description} gives more detailed information about the -function or parameter, and provides a unique name for it. It should -consist of letters and, possibly,~|_|~characters. - -\subsection{Parameters: access and type} -\label{sec:parms} - -The \m{access} part of the name describes how the parameter can be -accessed. Parameters are primarily classified as local, global or -constant (there are further, more technical, classes). This -\textit{access} type appears as a code at the beginning of the name; -the codes used include: -\begin{itemize} -\item[\bf c] - constants (global parameters whose value should not be changed); -\item[\bf g] - parameters whose value should only be set globally; -\item[\bf l] - parameters whose value should only be set locally. -\end{itemize} - -The \m{type} will normally (except when introducing a new data-type) -be in the list of available \textit{data-types}; these include the -primitive \TeX\ data-types, such as the various registers, but to -these will be added data-types built within the \LaTeX{} programming -system. - -Here are some typical data-type names: -\begin{description} -\item[int] integer-valued count register; -\item[toks] token register; -\item[box] box register; -\item[fint] `Fake-integer': (or fake-counter) a data type created to - avoid problems with the limited number of available count registers - in (standard) \TeX; -\item[seq] `sequence': a data-type used to implement lists - (with access at both ends) and stacks; -\item[plist] property list -\end{description} -When the \m{type} and \m{module} are identical (as often happens in -the more basic modules) the \m{module} part is often omitted for -aesthetic reasons. - - -\subsection{Functions: argument specifications} -\label{sec:args} - - Function names end with an \m{arg-spec} after a colon. This - gives an indication of the types of argument that a function takes, - and provides a convenient method of naming similar functions that - differ only in their argument forms (see the next section for - examples). - - The \m{arg-spec} consists of a (possibly empty) list of characters, - each denoting one argument of the function. It is important to - understand that `argument' here refers to the effective argument of - the \LaTeX{} function, not to an argument at the \TeX-level. Indeed, - the top level \TeX\ macro that has this name typically has no - arguments. This is an extension of the existing \LaTeX\ convention - where one says that |\section| has an optional argument and a - mandatory argument, whereas the \TeX\ macro |\section| actually has - zero parameters at the \TeX\ level, it merely calls an internal \LaTeX\ - command which in turn calls others that look ahead for star forms and - optional arguments. - -The list of possible argument specifiers includes the following. -\begin{itemize} -\item[\bf n] Unexpanded token or braced token list.\\ - This is a standard \TeX\ undelimited macro argument. -\item[\bf o] One-level-expanded token or braced token list.\\ - This means that the argument is expanded one level, as by - |\expandafter|, and the expansion is passed to the function as a braced - token list. Note that if the original argument is a braced - token list then only the first token in that list is expanded. -\item[\bf x] Fully-expanded token or braced token list.\\ - This means that the argument is expanded as in the replacement text of - an~|\edef|, and the expansion is passed to the function as a - braced token list. -\item[\bf c] Character string used as a command name.\\ The argument (a - token or braced token list) must, when fully expanded, produce a - sequence of characters which is then used to construct a command - name (via~|\csname|, |\endcsname|). This command name is the single - token that is passed to the function as the argument. -\item[\bf N] Single token (unlike~|n|, the argument must \emph{not} be - surrounded by braces).\\ - A typical example of a command taking an~|N| - argument is~|\def|, in which the command being defined must be - unbraced. - \item[\bf O] One-level-expanded single token (unbraced).\\ - As for~|o|, the one-level expansion is passed (as a - braced token list) to the function. - \item[\bf X] Fully-expanded single token (unbraced).\\ - As for~|x|, the full expansion is passed (as a - braced token list) to the function. - \item[\bf C] Character string used as a command name - then one-level expanded.\\ - The form of the argument is exactly as for~|c|, but the - resulting token is then expanded one level (as for~|O|), and - the expansion is passed to the function as a braced token list. - \item[\bf p] Primitive \TeX\ parameter specification.\\ - This can be something simple like~|#1#2#3|, but may use arbitrary - delimited argument syntax such as: |#1,#2\q_stop#3|. - \item[\bf T,F\hspace{-10pt}] - \hspace{10pt}% - These are special cases of~|n| arguments, used for the - true and false code in conditional commands. -\end{itemize} -There are two other specifiers with more general meanings: -\begin{itemize} -\item[\bf D] This means: \textbf{Do not use}. This special case is used - for \TeX\ primitives and other commands that are provided for use - only while bootstrapping the \LaTeX\ kernel. If the \TeX\ primitive - needs to be used in other contexts it will be given an alternative, - more appropriate, name with a useful argument specification. The - argument syntax of these is often weird, in the sense described next. - \item[\bf w] This means that the argument syntax is `weird' in that it - does not follow any standard rule. It is used for functions with - arguments that take non standard forms: examples are \TeX-level - delimited arguments and the boolean tests needed after certain - primitive |\if|\ldots\ commands. -\end{itemize} - - -\section{Expansion control} -\label{sec:exp} - -\subsection{Simpler means better} -\label{sec;simpler} - -Anyone who programs in \TeX\ is frustratingly familiar with the -problem of arranging that arguments to functions are suitably expanded -before the function is called. To illustrate how expansion control -can bring instant relief to this problem we shall consider two -examples copied from \texttt{latex.ltx}. - -\begin{verbatim} - \global - \expandafter - \expandafter - \expandafter - \let - \expandafter - \reserved@a - \csname \curr@fontshape \endcsname -\end{verbatim} -This first piece of code is in essence simply a -global |\let|. However, the token to be defined is obtained by -expanding |\reserved@a| one level; and, worse, the token to which it -is to be let is obtained by fully expanding |\curr@fontshape| and then -using the characters produced by that expansion to construct a command -name. The result is a mess of interwoven |\expandafter| and~|\csname| -beloved of all \TeX\ programmers, and the code is essentially -unreadable. - -Using the conventions and functionality outlined here, the task would -be achieved with code such as this: -\begin{verbatim} - \glet:Oc \g_reserved_a_tlp - \l_current_font_shape_tlp -\end{verbatim} -The command |\glet:Oc| is a global~|\let| that expands its -first argument once, and generates a command name out of its second -argument, before making the definition. This produces code that -is far more readable and more likely to be correct first time. - -Here is the second example. -\begin{verbatim} - \expandafter - \in@ - \csname sym#3% - \expandafter - \endcsname - \expandafter - {% - \group@list}% -\end{verbatim} -This piece of code is part of the definition of another function. It -first produces two things: a token list, by expanding |\group@list| once; -and a token whose name comes from~`|sym#3|'. Then the function~|\in@| -is called and this tests if its first argument occurs in the token list -of its second argument. - -Again we can improve enormously on the code. First we shall rename -the function~|\in@| according to our conventions. A function such as -this but taking two normal `\texttt{n}' arguments might reasonably be -named |\seq_test_in:nn|; thus the variant function we need will be -defined with the appropriate argument types and its name will be -|\seq_test_in:cO|. Now this code fragment will be simply: -\begin{verbatim} - \seq_test_in:cO {sym#3} \l_group_seq -\end{verbatim} -Note that, in addition to the lack of |\expandafter|, the space after -the~|}| will be silently ignored since all white space is ignored in -this programming environment. - - -\subsection{New functions from old} -\label{sec:newfunc} - -For many common functions the \LaTeX3 kernel will provide variants -with a range of argument forms, and similarly it is expected that -extension packages providing new functions will make them available in -the all the commonly needed forms. - -However, there will be occasions where it is necessary to construct a -new such variant form; therefore the expansion module provides a -straightforward mechanism for the creation of functions with any -required argument type, starting from a function that takes `normal' -\TeX\ undelimited arguments. - -To illustrate this let us suppose you have a `base function' -|\demo_cmd:nnn| that takes three normal arguments, and that you need -to construct the variant |\demo_cmd:cnx|, for which the first argument -is used to construct the \emph{name} of a command, whilst the third -argument must be fully expanded before being passed to -|\demo_cmd:nnn|. -To produce the variant form from the base form, simply use this: -\begin{verbatim} - \exp_def_form:nnn {demo_cmd} {nnn} {cnx} -\end{verbatim} -This defines the variant form so that you can then write, for example: -\begin{verbatim} - \demo_cmd:cnx {abc} {pq} {\rst \xyz } -\end{verbatim} -rather than \ldots\ well, something like this! -\begin{verbatim} - \def \tempa {{pq}}% - \edef \tempb {\rst \xyz}% - \expandafter - \demo@cmd - \csname abc% - \expandafter - \expandafter - \expandafter - \endcsname - \expandafter - \tempa - \expandafter - {% - \tempb - }% -\end{verbatim} - -Another example: you may wish to declare a function -|\demo_cmd_b:xcxcx|, a variant of an existing function -|\demo_cmd_b:nnnnn|, that fully -expands arguments 1,~3 and~5, and produces commands to pass as -arguments 2 and~4 using~|\csname|. -The definition you need is simply -\begin{verbatim} - \exp_def_form:nnn - {demo_cmd_b} {nnnnn} {xcxcx} -\end{verbatim} - -This extension mechanism is written so that if the same new form of -some existing command is implemented by two extension packages then the -two definitions will be identical and thus no conflict will occur. - - -\section{Parameter assignments and accessor functions} -\label{sec:access} - -\subsection{Checking assignments} -\label{sec:check} - -One of the advantages of having a consistent scheme is that the system -can provide more extensive error-checking and debugging facilities. -For example, an accessor function that makes a \emph{global} -assignment of a value to a parameter can check that it is not passed -the name of a \emph{local} parameter as that argument: it does this by -checking that the name starts with~|\g_|. - -Such checking is probably too slow for normal use, but the code can -have hooks built in that allow a format to be made in which all -functions perform this kind of check. - -A typical section of the source% -\footnote{This code uses the \textsf{docstrip} -system described in~\cite{A-W:GMS94}, Section~14.3.} -for such code might look like this -(recall that all white space is ignored): - -\begin{verbatim} - %<*!check> - \let_new:NN - \toks_gset:Nn \tex_global:D - %</!check> - %<*check> - \def_new:Npn - \toks_gset:Nn #1 - { - \chk_global:N #1 - \tex_global:D #1 - } - %</check> -\end{verbatim} -In the above code the function |\toks_gset:Nn| takes a single -token~(|N|) specifying a token register, and globally sets it to the -value passed in the second argument. - -A typical use of it would be: -\begin{verbatim} - \toks_gset \g_xxx_toks {<some value>} -\end{verbatim} -In the normal definition, |\toks_gset| can be simply~|\let| -to~|\global| because the primitive \TeX{} token register does not -require any explicit assignment function: -this is done by the |%<*!check>| code above. - -The alternative definition first checks that the argument -passed as~|#1| is the name of a global parameter and raises an error -if it is not. It does this by taking apart the command name passed -as~|#1| and checking that it starts~|\g_|. - -\subsection{Consistency} -\label{sec:cons} - -The primitive \TeX\ syntax for register assignments has a very minimal -syntax and, apart from box functions, there are no explicit functions -for assigning values to these registers. - -This makes it impossible to implement alternative data-types with a -syntax that is both consistent and at all similar to the syntax for -the primitives; moreover, it encourages a coding style that is very -error prone. - -As in the |\toks_gset:Nn| example given above, all \LaTeX\ data-types -are provided with explicit functions for assignment and for use, even -when these have essentially empty definitions. This allows for better -error-checking as described above; it also allows the construction of -further data-types with a similar interface, even when the -implementation of the associated functions is very complex. - -For example, the `fake-counter' (\texttt{fint}) data-type mentioned -above will appear at the \LaTeX{} programming level to be exactly like -the data-type based on primitive count registers; however, internally -it makes no use of count registers. Typical functions in this module -are illustrated here. - -\begin{verbatim} -\fint_new:N \l_tmpa_fint -\end{verbatim} -This declares the local parameter |\l_example_fint| as a fake-counter. - -\begin{verbatim} -\fint_add:Nn \l_example_fint \c_thirty_two -\end{verbatim} -This increments the value of this fake-counter by 32. - - -\section{The experimental distribution} -\label{sec:dist} - -The initial implementations of a \LaTeX\ programming language using -this kind of syntax remain unreleased (and not completely functional); -they partly pre-date \LaTeXe! The planned distribution will provide a -subset of the functionality of those implementations, in the form of -packages to be used on top of \LaTeXe. - -The intention is to allow experienced \TeX\ programmers to experiment -with the system and to comment on the interface. This means that -\textbf{\itshape the interface will change}. No part of this system, -including the name of anything, should be relied upon as being -available in a later release. Please do \emph{experiment} with these -packages, but do \emph{not} use them for code that you expect to keep -unchanged over a long period. - -In view of the intended experimental use for this distribution we -shall, in the first instance, produce only a few modules for use with -\LaTeXe. These will set up the conventions and the basic functionality -of, for example, the expansion mechanism; they will also implement some -of the basic programming constructs, such as token-lists and sequences. -They are intended only to give a flavour of the code: the full \LaTeX3 -kernel will provide a very rich set of programming constructs so that -packages can efficiently share code, in contrast with the situation in -the current \LaTeX\ where every large package must implement its own -version of queues, stacks, etc., as necessary. - -In the first release of this experimental system at least the -following modules will be distributed. -\begin{description} -\item[l3names] This sets up the basic naming scheme and renames all -the \TeX\ primitives. If it is loaded with the option -\texttt{[removeoldnames]} then the old primitive names such as~|\box| -become \emph{undefined} and are thus available for user -definition. Caution: use of this option will certainly break existing -\TeX\ code! - -\item [l3basics] -This contains the basic definition modules used -by the other packages. - -\item[l3chk] A module that provides functionality comparable to -\LaTeX's |\newcommand| and |\renewcommand|, and also the extra level of -checking described above in section~\ref{sec:check}. - -\item[l3tlp] -This implements a basic data-type, called a \textit{token-list -pointer}, used for storing named token lists: these are essentially -\TeX{} macros with no arguments. - -\item[l3expan] This is the argument expansion module discussed above. - -\item[l3quark] A `quark' is a command that is defined to expand to -itself! Therefore they must never be expanded as this will generate -infinite recursion; they do however have many uses, \eg as -special markers and delimiters within code. - -\item[l3seq] -This implements data-types such as queues and stacks. - -\item[l3prop] -This implements the data-type for `property lists' that are used, in -particular, for storing key/value pairs. - -\item[l3int] -This implements the integer and `fake integer' data-types. - -\item[l3toks] -A data-type corresponding to \TeX's primitive token registers. - -\item[l3io] -A module providing low level input and output functions. - -\item[l3precom] -A `pre-compilation' module that provides functions dealing with pointer -creation and handling, and using external files to record the state of the current -definitions. -\end{description} -This distribution will also contain the \LaTeX\ source for the latest -version of this document, a docstrip install file and three small test -files. - - -In later releases we plan to add further modules and a full-fledged -example of the use of the new language: a proto-type implementation -for the ideas described in the article `Language Information in -Structured Documents: A Model for Mark-up and -Rendering'~\cite{tub:MR98-2}. - -\begin{thebibliography}{1} - -\bibitem{A-W:K-TB} -Donald E Knuth -\newblock {\em The {\TeX}book}. -\newblock Addison-Wesley, Reading, Massachusetts, 1984. - -\bibitem{A-W:GMS94} -Goossens, Mittelbach and Samarin. -\newblock {\em The {\LaTeX} Companion}. -\newblock Addison-Wesley, Reading, Massachusetts, 1994. - -\bibitem{A-W:LLa94} -Leslie Lamport. -\newblock {\em {\LaTeX:} A Document Preparation System}. -\newblock Addison-Wesley, Reading, Massachusetts, second edition, 1994. - -\bibitem{tub:MR98-1} -Frank Mittelbach and Chris Rowley. -\newblock The {\LaTeX3} Project. -\newblock {\em {TUG}boat}, ????? ??? 1998. - -\bibitem{tub:MR98-2} -Frank Mittelbach and Chris Rowley. -\newblock Language Information in -Structured Documents: A Model for Mark-up and Rendering. -\newblock {\em {TUG}boat}, ????? ??? 1998. - -\end{thebibliography} - -\end{document} - - - - - |