summaryrefslogtreecommitdiff
path: root/Master/texmf-dist/source/latex/expl3/expl3.tex
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-dist/source/latex/expl3/expl3.tex')
-rw-r--r--Master/texmf-dist/source/latex/expl3/expl3.tex753
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}
-
-
-
-
-