25.3 Extended User Interface

  25.3.1 The addescribetype and addefinetype commands
  25.3.2 The addefinename command
  25.3.3 The admacro and adassertion commands

This part of the user interface is again divided into two parts.

  1. Commands that are automatically generated by some script. The arguments of those commands are extracted from the actual Aldor code and placed at the beginning of the corresponding +++ description. In ALLPROSE the script tools/addaldortypedef.pl.nw is responsible for this generation.
  2. Commands that appear rarely, but might be interesting for documentation writers.

25.3.1 The addescribetype and addefinetype commands

The command addefinetype should not be used by library documentation writers because these commands will be added automatically by the ALLPROSE script tools/addaldortypedef.pl.nw. The command addescribetype, however, is intended for cases when a code part that contains the definition of a type comes later than the documentation for that type. In order to be able to use adthistype, instead of adtype{CURRENTTYPENAME}, one has to initialize adthistype via addescribetype.

addescribetype should be used for cases where functions of a domain or category appear before the domain or category code is mentioned explicitly. Therefore, addescribetype helps to avoid to mention the optional type parameter in adname explicitly.

Note that neither of the commands result in any output in the running text.

As can be seen from the code below, adthistypename holds the current name of the type. This command, however, is not intended to be used by library documentation writers. It solely serves an internal purpose of aldordoc to have the current type name available when it is not given as an optional parameter in adname.

276extended user interface 276  (247)  279a
\newcommand{\addescribetype}[1]{% no optional argument
  \gdef\adthistypename{#1}%
  \gdef\adthisname{}%
}
\newcommand{\addefinetype}[1]{%
  \hypertarget{dt:#1}{}%
  \label{!#1}%
  \index{#1@\protect\adcodefont{#1}|defineTermPage}%
  \addescribetype{#1}%
}

25.3.2 The addefinename command

The command addefinename should usually not be used by library documentation writers, because these commands (with appropriate arguments) will be added automatically by the ALLPROSE script tools/addaldortypedef.pl.nw. Exceptions are places where functions are implemented in a domain and package and no explicit export of that function is given in the category part of the domain definition.

Consider, for example, the following piece from a literate Aldor program. Adding addefinename is for =, because there is no place where ALLPROSE will add addefinename{=: (%, %) -> Boolean} automatically. For foo, however, the definition in the chunk <<exports: MyDom>> and the preceding +++ environment trigger ALLPROSE to automatically generate addefinename{foo: % -> Integer} right after the \begin{+++}.

<<dom: MyDom>>=  
MyDom: PrimitiveType with {  
  <<exports: MyDom>>  
} == add {  
  Rep == ...  
  <<implementaton: MyDom>>  
}  
@  
...  
\begin{+++}  
  ...  
\end{+++}  
<<exports: MyDom>>=  
foo: % -> Integer  
@  
...  
<<implementation: MyDom>>=  
foo(x: %): Integer == ...  
@  
...  
\addefinename{=: (%, %) -> Boolean}  
<<implementation: MyDom>>=  
(x: %) = (y: %): Boolean == ...  
@

The command addefinename will print nothing in text, but define or re-define the command adthisname. It makes sense not to print anything, since the command is added automatically to the text at a place where the documentation for that function or constant appears in a ++ or +++ description. The arguments are exactly as those of adname. See also adinternaldefinename.

25.3.3 The admacro and adassertion commands

The commands admacro and adassertion are provided in order to be able to document implementation details. These commands are not very interesting to be used in ++ descriptions.

ToDo 14 In fact, one cannot use addefinemacro and addefineassertion, because the definition of macros and assertions cannot be documented via ++ descriptions.
They are used like
\admacro{NAME}  
\adassertion{NAME}

where the argument NAME is set in typewriter mode. Additionally, NAME must also follow the naming Convention 26 of types.

279aextended user interface 276+   (247)  276  279b
\newcommand{\admacro}{\adtype}
\newcommand{\adassertion}{\adtype}

In contrast to addefinetype (which is not meant for documentation writers but rather will be generated automatically into the documentation) the commands addefinemacro and addefineassertion must be used at the place where the macro or assertion is defined. They are not automatically generated and, therefore, typeset in the running text. The reason for not generating these commands by a script is that there might be a macro or assertion defined at several places and one only wants to refer to one of them.

279bextended user interface 276+   (247)  279a
\newcommand{\addefinemacro}{\addefineterm}
\newcommand{\addefineassertion}{\addefineterm}
\makeatother
\newcommand{\addefineterm}[1]{% auxiliary command
  \defineterm[\adcodefont{#1}]{#1@\protect\adcodefont{#1}}
}
\makeatletter

There can be several occurrences of these commands in the text if, for example, some macros with the same name are locally defined in different files. In this case the hyperlink will just refer to one of these definitions. With an appropriate color setting through the MAKE target colored in Makefile.nw, it is, however, possible to figure out the definition places from the index. Set the style for the defineterm and useterm commands (from the rhxterm LATEX package) through defineTermStyle and useTermStyle. For example,

\def\defineTermStyle{\textcolor{red}}

shows the page numbers in the index of where a defineterm command appears in red.