Changeset 1048b31


Ignore:
Timestamp:
May 2, 2016, 3:28:16 PM (6 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
1b7ea43
Parents:
1f6e009 (diff), e945826 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' into global-init

Files:
14 added
3 deleted
49 edited
2 moved

Legend:

Unmodified
Added
Removed
  • doc/refrat/Makefile

    r1f6e009 r1048b31  
    11## Define the appropriate configuration variables.
    22
    3 Macros =
    4 TeXLIB = .:${Macros}:
     3TeXLIB = .:../bibliography/:../LaTeXmacros/:
    54LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex
    6 BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex
     5BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
    76
    87## Define the text source files.
     
    4443        dvips $< -o $@
    4544
    46 ${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex ${basename ${DOCUMENT}}.bib
     45${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
     46                ../LaTeXmacros/common.tex ../LaTeXmacros/indexstyle ../bibliography/cfa.bib
    4747        # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
    4848        if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi
     
    5454        -${BibTeX} ${basename $@}
    5555        # Make index from *.aux entries and input index at end of document
    56         makeindex -s indexstyle ${basename $@}.idx
     56        makeindex -s ../LaTeXmacros/indexstyle ${basename $@}.idx
    5757        ${LaTeX} ${basename $@}.tex
    5858        # Run again to get index title into table of contents
  • doc/refrat/refrat.tex

    r1f6e009 r1048b31  
     1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
     2%%
     3%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
     4%%
     5%% The contents of this file are covered under the licence agreement in the
     6%% file "LICENCE" distributed with Cforall.
     7%%
     8%% refrat.tex --
     9%%
     10%% Author           : Peter A. Buhr
     11%% Created On       : Wed Apr  6 14:52:25 2016
     12%% Last Modified By : Peter A. Buhr
     13%% Last Modified On : Sat Apr 30 13:45:40 2016
     14%% Update Count     : 29
     15%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     16
    117% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
     18
     19% red highlighting ®...® (registered trademark sumbol)
     20% blue highlighting ©...© (copyright symbol)
     21% latex escape §...§ (section symbol)
     22% keyword escape ¶...¶ (pilcrow symbol)
     23% math escape $...$ (dollar symbol)
    224
    325\documentclass[openright,twoside]{report}
     
    527
    628% Latex packages used in the document.
    7 
    829\usepackage{fullpage,times}
    930\usepackage{xspace}
     
    1132\usepackage{listings}
    1233\usepackage{comment}
    13 \usepackage{latexsym}                                   % \Box
    14 \usepackage{mathptmx}                                   % better math font with "times"
     34\usepackage{latexsym}                                   % \Box
     35\usepackage{mathptmx}                                   % better math font with "times"
    1536\usepackage[pagewise]{lineno}
    1637\renewcommand{\linenumberfont}{\scriptsize\sffamily}
     
    2142%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2243
    23 % Names used in the document.
    24 
    25 \newcommand{\CFA}{C$\forall$\xspace}    % set language symbolic name
    26 \newcommand{\CFL}{Cforall\xspace}               % set language text name
    27 \newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
    28 \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
     44% Bespoke macros used in the document.
     45\input{common}
    2946
    3047%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    3148
    32 % Bespoke macros used in the document.
    33 
    34 \makeatletter
    35 % allow escape sequence in lstinline
    36 %\usepackage{etoolbox}
    37 %\patchcmd{\lsthk@TextStyle}{\let\lst@DefEsc\@empty}{}{}{\errmessage{failed to patch}}
    38 
    39 \renewcommand\small{%
    40    \@setfontsize\small{8.5}{11}%
    41    \abovedisplayskip 8.5pt \@plus 3pt \@minus 4pt
    42    \abovedisplayshortskip \z@ \@plus 2pt
    43    \belowdisplayshortskip 4pt \@plus 2pt \@minus 2pt
    44    \def\@listi{\leftmargin\leftmargini
    45                \topsep 4pt \@plus 2pt \@minus 2pt
    46                \parsep 2pt \@pluspt \@minuspt
    47                \itemsep \parsep}%
    48    \belowdisplayskip \abovedisplayskip
    49 }
    50 \usepackage{relsize}            % must be after change to small
    51 
    52 \renewcommand{\labelitemi}{{\raisebox{0.25ex}{\footnotesize$\bullet$}}}
    53 \renewenvironment{itemize}{\begin{list}{\labelitemi}{\topsep=5pt\itemsep=5pt\parsep=0pt}}{\end{list}}
    54 
    55 %  Reduce size of chapter/section titles
    56 \def\@makechapterhead#1{%
    57   \vspace*{50\p@}%
    58   {\parindent \z@ \raggedright \normalfont
    59     \ifnum \c@secnumdepth >\m@ne
    60         \large\bfseries \@chapapp\space \thechapter
    61         \par\nobreak
    62         \vskip 5\p@
    63     \fi
    64     \interlinepenalty\@M
    65     \Large \bfseries #1\par\nobreak
    66     \vskip 50\p@
    67   }}
    68 \def\@makeschapterhead#1{%
    69   \vspace*{50\p@}%
    70   {\parindent \z@ \raggedright
    71     \normalfont
    72     \interlinepenalty\@M
    73     \Large \bfseries  #1\par\nobreak
    74     \vskip 50\p@
    75   }}
    76 \renewcommand\section{\@startsection{section}{1}{\z@}{-3.0ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\large\bfseries}}
    77 \renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    78 \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    79 \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}{-2.0ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries}}
    80 
    81 % index macros
    82 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
    83 \newcommand{\definition}[1]{\textbf{\hyperpage{#1}}}
    84 \newcommand{\see}[1]{\emph{see} #1}
    85 
    86 % Define some commands that produce formatted index entries suitable for cross-references.
    87 % ``\spec'' produces entries for specifications of entities.  ``\impl'' produces entries for their
    88 % implementations, and ``\use'' for their uses.
    89 
    90 %  \newcommand{\bold}[1]{{\bf #1}}
    91 %  \def\spec{\@bsphack\begingroup
    92 %             \def\protect##1{\string##1\space}\@sanitize
    93 %             \@wrxref{|bold}}
    94 \def\impl{\@bsphack\begingroup
    95           \def\protect##1{\string##1\space}\@sanitize
    96           \@wrxref{|definition}}
    97 \newcommand{\indexcode}[1]{{\lstinline$#1$}}
    98 \def\use{\@bsphack\begingroup
    99          \def\protect##1{\string##1\space}\@sanitize
    100          \@wrxref{|hyperpage}}
    101 \def\@wrxref#1#2{\let\thepage\relax
    102     \xdef\@gtempa{\write\@indexfile{\string
    103     \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa
    104     \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
    105 %\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}}
    106 %\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
    107 
    108 % inline text and lowercase index: \Index{inline and lowercase index text}
    109 % inline text and as-in index: \Index[as-is index text]{inline text}
    110 % inline text but index with different as-is text: \Index[index text]{inline text}
    111 \newcommand{\Index}{\@ifstar\@sIndex\@Index}
    112 \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    113 \newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
    114 \makeatother
    115 
    116 % blocks and titles
    117 \newenvironment{rationale}{%
    118   \begin{quotation}\noindent$\Box$\enspace
    119 }{%
    120   \hfill\enspace$\Box$\end{quotation}
    121 }%
    122 \newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    123 \newcommand{\rewrite}{\(\Rightarrow\)}
    124 \newcommand{\rewriterules}{\paragraph{Rewrite Rules}~\par\noindent}
    125 \newcommand{\examples}{\paragraph{Examples}~\par\noindent}
    126 \newcommand{\semantics}{\paragraph{Semantics}~\par\noindent}
    127 \newcommand{\constraints}{\paragraph{Constraints}~\par\noindent}
    128 \newcommand{\predefined}{\paragraph{Predefined Identifiers}~\par\noindent}
    129 
    130 % BNF macros
    131 \def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]}
    132 \let\endsyntax=\endtrivlist
    133 \newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
    134 \newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
    135 \newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
    136 \newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
    137 \newcommand{\opt}{$_{opt}$\ }
    138 
    139 % adjust varioref package with default "section" and "page" titles, and optional title with faraway page numbers
    140 % \VRef{label} => Section 2.7, \VPageref{label} => page 17
    141 % \VRef[Figure]{label} => Figure 3.4, \VPageref{label} => page 17
    142 \renewcommand{\reftextfaceafter}{\unskip}
    143 \renewcommand{\reftextfacebefore}{\unskip}
    144 \renewcommand{\reftextafter}{\unskip}
    145 \renewcommand{\reftextbefore}{\unskip}
    146 \renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}}
    147 \renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}}
    148 \newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}}
    149 \newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
    150 
    151 % CFA based on ANSI C
    152 \lstdefinelanguage{CFA}[ANSI]{C}%
    153 {morekeywords={asm,_Alignas,_Alignof,_At,_Atomic,_Bool,catch,catchResume,choose,_Complex,trait,disable,dtype,enable,
    154         fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,lvalue,_Noreturn,otype,restrict,_Static_assert,
    155         _Thread_local,throw,throwResume,try,},
    156 }%
    157 
    158 \lstset{
    159 language=CFA,
    160 columns=flexible,
    161 basicstyle=\sf\relsize{-1},
    162 tabsize=4,
    163 xleftmargin=\parindent,
    164 escapechar=@,
    165 keepspaces=true,
    166 showstringspaces=false,
    167 showlines=true,
    168 }%
    169 
    170 \makeatletter
    171 % replace/adjust listings characters that look bad in sanserif
    172 \lst@CCPutMacro
    173 \lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus
    174 \lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than
    175 \lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than
    176 \lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % replace circumflex
    177 \lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
    178 \lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % replace tilde
    179 %\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
    180 \@empty\z@\@empty
    181 \makeatother
    182 
    183 \setcounter{secnumdepth}{3}     % number subsubsections
    184 \setcounter{tocdepth}{3}                % subsubsections in table of contents
     49\setcounter{secnumdepth}{3}                             % number subsubsections
     50\setcounter{tocdepth}{3}                                % subsubsections in table of contents
    18551\makeindex
    18652
     
    18955\begin{document}
    19056\pagestyle{headings}
    191 \linenumbers                                    % comment out to turn off line numbering
     57\linenumbers                                            % comment out to turn off line numbering
    19258
    19359\title{\Huge
     60\vspace*{1in}
    19461\CFA (\CFL) Reference Manual and Rationale
    19562}% title
     
    22693
    22794This document is a reference manual and rationale for \CFA, a polymorphic extension of the C programming language.
    228 It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and occasionally compares \CFA to {\CC} \cite{c++}.
     95It makes frequent reference to the {\c11} standard \cite{C11}, and occasionally compares \CFA to {\CC} \cite{C++}.
    22996
    23097The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering differs).
     
    264131\CFA's scope rules differ from C's in one major respect: a declaration of an identifier may overload\index{overloading} outer declarations of lexically identical identifiers in the same
    265132\Index{name space}, instead of hiding them.
    266 The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
    267 \lstinline$typedef$\use{typedef} declaration and the other is not.  The outer declaration becomes
     133The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline@type@\use{type} or
     134\lstinline@typedef@\use{typedef} declaration and the other is not.  The outer declaration becomes
    268135\Index{visible} when the scope of the inner declaration terminates.
    269136\begin{rationale}
    270 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same scope;
     137Hence, a \CFA program can declare an \lstinline@int v@ and a \lstinline@float v@ in the same scope;
    271138a {\CC} program can not.
    272139\end{rationale}
     
    282149Identifiers with \Index{no linkage} always denote unique entities.
    283150\begin{rationale}
    284 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$;
     151A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;
    285152a C program cannot.
    286153\end{rationale}
     
    305172\end{lstlisting}
    306173
    307 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline$sumable$.
     174The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline@sumable@.
    308175The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    309176
     
    366233In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    367234
    368 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
    369 Let \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
     235Let \lstinline@int$_r$@ and \lstinline@unsigned$_r$@ be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
     236Let \lstinline@unsigned$_{mr}$@ be the unsigned integer type with maximal rank.
    370237
    371238The following conversions are \emph{direct} safe arithmetic conversions.
     
    374241The \Index{integer promotion}s.
    375242\item
    376 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) to \(unsigned_r\).
    377 \item
    378 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
    379 \item
    380 Conversion from \(unsigned_{mr}\) to \lstinline$float$.
     243For every rank $r$ greater than or equal to the rank of \lstinline@int@, conversion from \lstinline@int$_r$@ to \lstinline@unsigned$_r$@.
     244\item
     245For every rank $r$ greater than or equal to the rank of \lstinline@int@, where \lstinline@int$_{r+1}$@ exists and can represent all values of \lstinline@unsigned$_r$@, conversion from \lstinline@unsigned$_r$@ to \lstinline@int$_{r+1}$@.
     246\item
     247Conversion from \lstinline@unsigned$_{mr}$@ to \lstinline@float@.
    381248\item
    382249Conversion from an enumerated type to its compatible integer type.
    383250\item
    384 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to \lstinline$long double$.
    385 \item
    386 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
     251Conversion from \lstinline@float@ to \lstinline@double@, and from \lstinline@double@ to \lstinline@long double@.
     252\item
     253Conversion from \lstinline@float _Complex@ to \lstinline@double _Complex@, and from \lstinline@double _Complex@ to \lstinline@long double _Complex@.
    387254\begin{sloppypar}
    388255\item
    389 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the implementation supports imaginary types.
     256Conversion from \lstinline@float _Imaginary@ to \lstinline@double _Imaginary@, and from \lstinline@double _Imaginary@ to \lstinline@long double _Imaginary@, if the implementation supports imaginary types.
    390257\end{sloppypar}
    391258\end{itemize}
    392259
    393 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic conversion.
     260If type \lstinline@T@ can be converted to type \lstinline@U@ by a safe direct arithmetic conversion and type \lstinline@U@ can be converted to type \lstinline@V@ by a safe arithmetic conversion, then the conversion from \lstinline@T@ to type \lstinline@V@ is an \emph{indirect} safe arithmetic conversion.
    394261
    395262\begin{rationale}
     
    414281        int x, y;
    415282};
    416 void move_by( struct point * p1, struct point * p2 ) {@\impl{move_by}@
     283void move_by( struct point * p1, struct point * p2 ) {§\impl{move_by}§
    417284        p1->x += p2.x;
    418285        p1->y += p2.y;
     
    424291move_to( &cp1, &cp2 );
    425292\end{lstlisting}
    426 Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
    427 \lstinline$cp1$'s second member and \lstinline$cp2$'s second member.
     293Thanks to implicit conversion, the two arguments that \lstinline@move_by()@ receives are pointers to
     294\lstinline@cp1@'s second member and \lstinline@cp2@'s second member.
    428295
    429296
     
    467334a direct safe arithmetic conversion;
    468335\item
    469 from any object type or incomplete type to \lstinline$void$;
    470 \item
    471 from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
     336from any object type or incomplete type to \lstinline@void@;
     337\item
     338from a pointer to any non-\lstinline@void@ type to a pointer to \lstinline@void@;
    472339\item
    473340from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     
    480347Conversions that are not safe conversions are \define{unsafe conversion}s.
    481348\begin{rationale}
    482 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type.
     349As in C, there is an implicit conversion from \lstinline@void *@ to any pointer type.
    483350This is clearly dangerous, and {\CC} does not have this implicit conversion.
    484351\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a superset of C as possible, but discourages it by making it unsafe.
     
    506373\begin{itemize}
    507374\item
    508 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1.
    509 The cost of an implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and then to \lstinline$double$.
    510 
    511 \item
    512 If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
    513 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$.
    514 Otherwise, \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
    515 
    516 \item
    517 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost of \lstinline$unsigned$ to \lstinline$long$ is 1.
     375The cost of an implicit conversion from \lstinline@int@ to \lstinline@long@ is 1.
     376The cost of an implicit conversion from \lstinline@long@ to \lstinline@double@ is 3, because it is defined in terms of conversions from \lstinline@long@ to \lstinline@unsigned long@, then to \lstinline@float@, and then to \lstinline@double@.
     377
     378\item
     379If \lstinline@int@ can represent all the values of \lstinline@unsigned short@, then the cost of an implicit conversion from \lstinline@unsigned short@ to \lstinline@unsigned@ is 2:
     380\lstinline@unsigned short@ to \lstinline@int@ to \lstinline@unsigned@.
     381Otherwise, \lstinline@unsigned short@ is converted directly to \lstinline@unsigned@, and the cost is 1.
     382
     383\item
     384If \lstinline@long@ can represent all the values of \lstinline@unsigned@, then the conversion cost of \lstinline@unsigned@ to \lstinline@long@ is 1.
    518385Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    519386\end{itemize}
     
    523390\begin{syntax}
    524391\oldlhs{keyword}
    525         \rhs \lstinline$forall$
    526         \rhs \lstinline$lvalue$
    527         \rhs \lstinline$trait$
    528         \rhs \lstinline$dtype$
    529         \rhs \lstinline$ftype$
    530         \rhs \lstinline$type$
     392        \rhs \lstinline@forall@
     393        \rhs \lstinline@lvalue@
     394        \rhs \lstinline@trait@
     395        \rhs \lstinline@dtype@
     396        \rhs \lstinline@ftype@
     397        \rhs \lstinline@otype@
    531398\end{syntax}
    532399
     
    535402
    536403\CFA allows operator \Index{overloading} by associating operators with special function identifiers.
    537 Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
     404Furthermore, the constants ``\lstinline@0@'' and ``\lstinline@1@'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
    538405Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    539406
     
    544411\begin{syntax}
    545412\oldlhs{identifier}
    546 \rhs \lstinline$0$
    547 \rhs \lstinline$1$
     413\rhs \lstinline@0@
     414\rhs \lstinline@1@
    548415\end{syntax}
    549416
    550 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} and ``\lstinline$1$''\impl{1} are identifiers.
     417\index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline@0@''\impl{0} and ``\lstinline@1@''\impl{1} are identifiers.
    551418No other tokens defined by the rules for integer constants are considered to be identifiers.
    552419\begin{rationale}
    553 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C.
     420Why ``\lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.
    554421All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
    555 The operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
     422The operations ``\lstinline@&&@'', ``\lstinline@||@'', and ``\lstinline@!@'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    556423A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    557424
    558425In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case.
    559426However, user-defined arithmetic types often need the equivalent of a 1 or 0 for their functions or operators, polymorphic functions often need 0 and 1 constants of a type matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
    560 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline$_Bool$.
    561 
    562 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers have special status in C.
    563 A facility that let programmers declare specific constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
     427Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
     428
     429Why \emph{just} ``\lstinline@0@'' and ``\lstinline@1@''? Why not other integers? No other integers have special status in C.
     430A facility that let programmers declare specific constants---``\lstinline@const Rational 12@'', for instance---would not be much of an improvement.
    564431Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    565432The complexity of such a feature doesn't seem worth the gain.
     
    577444\begin{tabular}[t]{ll}
    578445%identifier & operation \\ \hline
    579 \lstinline$?[?]$ & subscripting \impl{?[?]}\\
    580 \lstinline$?()$ & function call \impl{?()}\\
    581 \lstinline$?++$ & postfix increment \impl{?++}\\
    582 \lstinline$?--$ & postfix decrement \impl{?--}\\
    583 \lstinline$++?$ & prefix increment \impl{++?}\\
    584 \lstinline$--?$ & prefix decrement \impl{--?}\\
    585 \lstinline$*?$ & dereference \impl{*?}\\
    586 \lstinline$+?$ & unary plus \impl{+?}\\
    587 \lstinline$-?$ & arithmetic negation \impl{-?}\\
    588 \lstinline$~?$ & bitwise negation \impl{~?}\\
    589 \lstinline$!?$ & logical complement \impl{"!?}\\
    590 \lstinline$?*?$ & multiplication \impl{?*?}\\
    591 \lstinline$?/?$ & division \impl{?/?}\\
     446\lstinline@?[?]@ & subscripting \impl{?[?]}\\
     447\lstinline@?()@ & function call \impl{?()}\\
     448\lstinline@?++@ & postfix increment \impl{?++}\\
     449\lstinline@?--@ & postfix decrement \impl{?--}\\
     450\lstinline@++?@ & prefix increment \impl{++?}\\
     451\lstinline@--?@ & prefix decrement \impl{--?}\\
     452\lstinline@*?@ & dereference \impl{*?}\\
     453\lstinline@+?@ & unary plus \impl{+?}\\
     454\lstinline@-?@ & arithmetic negation \impl{-?}\\
     455\lstinline@~?@ & bitwise negation \impl{~?}\\
     456\lstinline@!?@ & logical complement \impl{"!?}\\
     457\lstinline@?*?@ & multiplication \impl{?*?}\\
     458\lstinline@?/?@ & division \impl{?/?}\\
    592459\end{tabular}\hfil
    593460\begin{tabular}[t]{ll}
    594461%identifier & operation \\ \hline
    595 \lstinline$?%?$ & remainder \impl{?%?}\\
    596 \lstinline$?+?$ & addition \impl{?+?}\\
    597 \lstinline$?-?$ & subtraction \impl{?-?}\\
    598 \lstinline$?<<?$ & left shift \impl{?<<?}\\
    599 \lstinline$?>>?$ & right shift \impl{?>>?}\\
    600 \lstinline$?<?$ & less than \impl{?<?}\\
    601 \lstinline$?<=?$ & less than or equal \impl{?<=?}\\
    602 \lstinline$?>=?$ & greater than or equal \impl{?>=?}\\
    603 \lstinline$?>?$ & greater than \impl{?>?}\\
    604 \lstinline$?==?$ & equality \impl{?==?}\\
    605 \lstinline$?!=?$ & inequality \impl{?"!=?}\\
    606 \lstinline$?&?$ & bitwise AND \impl{?&?}\\
     462\lstinline@?%?@ & remainder \impl{?%?}\\
     463\lstinline@?+?@ & addition \impl{?+?}\\
     464\lstinline@?-?@ & subtraction \impl{?-?}\\
     465\lstinline@?<<?@ & left shift \impl{?<<?}\\
     466\lstinline@?>>?@ & right shift \impl{?>>?}\\
     467\lstinline@?<?@ & less than \impl{?<?}\\
     468\lstinline@?<=?@ & less than or equal \impl{?<=?}\\
     469\lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
     470\lstinline@?>?@ & greater than \impl{?>?}\\
     471\lstinline@?==?@ & equality \impl{?==?}\\
     472\lstinline@?!=?@ & inequality \impl{?"!=?}\\
     473\lstinline@?&?@ & bitwise AND \impl{?&?}\\
    607474\end{tabular}\hfil
    608475\begin{tabular}[t]{ll}
    609476%identifier & operation \\ \hline
    610 \lstinline$?^?$ & exclusive OR \impl{?^?}\\
    611 \lstinline$?|?$ & inclusive OR \impl{?"|?}\\
    612 \lstinline$?=?$ & simple assignment \impl{?=?}\\
    613 \lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\
    614 \lstinline$?/=?$ & division assignment \impl{?/=?}\\
    615 \lstinline$?%=?$ & remainder assignment \impl{?%=?}\\
    616 \lstinline$?+=?$ & addition assignment \impl{?+=?}\\
    617 \lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\
    618 \lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\
    619 \lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\
    620 \lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\
    621 \lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\
    622 \lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\
     477\lstinline@?^?@ & exclusive OR \impl{?^?}\\
     478\lstinline@?|?@ & inclusive OR \impl{?"|?}\\
     479\lstinline@?=?@ & simple assignment \impl{?=?}\\
     480\lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
     481\lstinline@?/=?@ & division assignment \impl{?/=?}\\
     482\lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
     483\lstinline@?+=?@ & addition assignment \impl{?+=?}\\
     484\lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
     485\lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
     486\lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
     487\lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
     488\lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
     489\lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
    623490\end{tabular}
    624491\hfil
     
    635502
    636503\begin{rationale}
    637 The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but a
    638 \CFA compiler detects a syntax error because it treats ``\lstinline$?--$'' as an identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
     504The use of ``\lstinline@?@'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline@(i < 0)?--i:i@'' is legal in a C program, but a
     505\CFA compiler detects a syntax error because it treats ``\lstinline@?--@'' as an identifier, not as the two tokens ``\lstinline@?@'' and ``\lstinline@--@''.
    639506\end{rationale}
    640507
     
    643510\begin{itemize}
    644511\item
    645 The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
    646 ``\lstinline$?:$''.
     512The logical operators ``\lstinline@&&@'' and ``\lstinline@||@'', and the conditional operator
     513``\lstinline@?:@''.
    647514These operators do not always evaluate their operands, and hence can not be properly defined by functions unless some mechanism like call-by-name is added to the language.
    648 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' for user-defined types is enough to allow them to be used in logical expressions.
     515Note that the definitions of ``\lstinline@&&@'' and ``\lstinline@||@'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline@!=@'' and ``\lstinline@0@'' for user-defined types is enough to allow them to be used in logical expressions.
    649516
    650517\item
     
    655522\item
    656523The ``address of'' operator.
    657 It would seem useful to define a unary ``\lstinline$&$'' operator that returns values of some programmer-defined pointer-like type.
     524It would seem useful to define a unary ``\lstinline@&@'' operator that returns values of some programmer-defined pointer-like type.
    658525The problem lies with the type of the operator.
    659 Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
    660 \lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$.
    661 The expression might be treated as a call to the unary function ``\lstinline$&?$''.
    662 Now what is the type of the function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by value, and there is no way to create a useful pointer-like result from a value.
    663 Hence the parameter must have type \lstinline$T *$.
    664 But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
     526Consider the expression ``\lstinline@p = &x@'', where \lstinline@x@ is of type
     527\lstinline@T@ and \lstinline@p@ has the programmer-defined type \lstinline@T_ptr@.
     528The expression might be treated as a call to the unary function ``\lstinline@&?@''.
     529Now what is the type of the function's parameter? It can not be \lstinline@T@, because then \lstinline@x@ would be passed by value, and there is no way to create a useful pointer-like result from a value.
     530Hence the parameter must have type \lstinline@T *@.
     531But then the expression must be rewritten as ``\lstinline@p = &?( &x )@''
    665532---which doesn't seem like progress!
    666533
    667534The rule for address-of expressions would have to be something like ``keep applying address-of functions until you get one that takes a pointer argument, then use the built-in operator and stop''.
    668 It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
    669 
    670 \item
    671 The \lstinline$sizeof$ operator.
     535It seems simpler to define a conversion function from \lstinline@T *@ to \lstinline@T_ptr@.
     536
     537\item
     538The \lstinline@sizeof@ operator.
    672539It is already defined for every object type, and intimately tied into the language's storage allocation model.
    673540Redefining it seems pointless.
    674541
    675542\item
    676 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''.
     543The ``member of'' operators ``\lstinline@.@'' and ``\lstinline@->@''.
    677544These are not really infix operators, since their right ``operand'' is not a value or object.
    678545
     
    711578The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    712579The ``lowest total expression cost'' rule chooses the proper common type.
    713 The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
     580The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline@(double)-i@ will be preferred to \lstinline@-(double)i@.
    714581
    715582The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such functions are presumably more expensive than monomorphic functions and since the more specific function is presumably more appropriate.
    716583It also gives preference to monomorphic values (such as the
    717 \lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
    718 \lstinline$0$\use{0}).
     584\lstinline@int@ \lstinline@0@) over polymorphic values (such as the \Index{null pointer}
     585\lstinline@0@\use{0}).
    719586However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    720587
    721588There are two notable differences between \CFA's overload resolution rules and the rules for
    722 {\CC} defined in \cite{c++}.
     589{\CC} defined in \cite{C++}.
    723590First, the result type of a function plays a role.
    724591In {\CC}, a function call must be completely resolved based on the arguments to the call in most circumstances.
     
    736603\begin{rationale}
    737604Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
    738 For instance, ``\lstinline$an_int + an_int$'' is equivalent to ``\lstinline$?+?(an_int, an_int)$''.
     605For instance, ``\lstinline@an_int + an_int@'' is equivalent to ``\lstinline@?+?(an_int, an_int)@''.
    739606If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    740607If predefined functions had external linkage, this optimization would be difficult.
     
    762629\rhs \nonterm{constant}
    763630\rhs \nonterm{string-literal}
    764 \rhs \lstinline$($ \nonterm{expression} \lstinline$)$
     631\rhs \lstinline@(@ \nonterm{expression} \lstinline@)@
    765632\rhs \nonterm{generic-selection}
    766633\end{syntax}
     
    768635\predefined
    769636\begin{lstlisting}
    770 const int 1;@\use{1}@
    771 const int 0;@\use{0}@
     637const int 1;§\use{1}§
     638const int 0;§\use{0}§
    772639forall( dtype DT ) DT * const 0;
    773640forall( ftype FT ) FT * const 0;
     
    778645
    779646A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
    780 The predefined integer identifiers ``\lstinline$1$'' and ``\lstinline$0$'' have the integer values 1 and 0, respectively.
    781 The other two predefined ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
     647The predefined integer identifiers ``\lstinline@1@'' and ``\lstinline@0@'' have the integer values 1 and 0, respectively.
     648The other two predefined ``\lstinline@0@'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
    782649
    783650A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    784651
    785652\examples
    786 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe conversion from \lstinline$void *$ to \lstinline$const void *$.
     653The expression \lstinline@(void *)0@\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline@void@. \lstinline@(const void *)0@ does the same, and also uses a safe conversion from \lstinline@void *@ to \lstinline@const void *@.
    787654In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    788 \lstinline$0$ to a pointer.
     655\lstinline@0@ to a pointer.
    789656
    790657\begin{rationale}
     
    792659
    793660\CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
    794 The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ with the value ``zero'', and it \emph{also} is a null pointer constant.
     661The C token ``\lstinline@0@'' is an expression of type \lstinline@int@ with the value ``zero'', and it \emph{also} is a null pointer constant.
    795662Similarly,
    796 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, and it also is a null pointer constant.
    797 However, in C, ``\lstinline$(void *)(void *)0$'' is
     663``\lstinline@(void *)0@ is an expression of type \lstinline@(void *)@ whose value is a null pointer, and it also is a null pointer constant.
     664However, in C, ``\lstinline@(void *)(void *)0@'' is
    798665\emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The semantics of C expressions contain many special cases to deal with subexpressions that are null pointer constants.
    799666
     
    802669\begin{lstlisting}
    803670forall( dtype DT ) DT * const 0;
    804 \end{lstlisting} means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
     671\end{lstlisting} means that \lstinline@0@ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
    805672The only such value is the null pointer.
    806673Therefore the type \emph{alone} is enough to identify a null pointer.
     
    812679
    813680\constraints The best interpretation of the controlling expression shall be unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the types named in its generic association list.
    814 If a generic selection has no \lstinline$default$ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
     681If a generic selection has no \lstinline@default@ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
    815682
    816683\semantics
     
    823690\lhs{postfix-expression}
    824691\rhs \nonterm{primary-expression}
    825 \rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$
    826 \rhs \nonterm{postfix-expression} \lstinline$($
    827          \nonterm{argument-expression-list}\opt \lstinline$)$
    828 \rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier}
    829 \rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier}
    830 \rhs \nonterm{postfix-expression} \lstinline$++$
    831 \rhs \nonterm{postfix-expression} \lstinline$--$
    832 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$
    833 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$
     692\rhs \nonterm{postfix-expression} \lstinline@[@ \nonterm{expression} \lstinline@]@
     693\rhs \nonterm{postfix-expression} \lstinline@(@
     694         \nonterm{argument-expression-list}\opt \lstinline@)@
     695\rhs \nonterm{postfix-expression} \lstinline@.@ \nonterm{identifier}
     696\rhs \nonterm{postfix-expression} \lstinline@->@ \nonterm{identifier}
     697\rhs \nonterm{postfix-expression} \lstinline@++@
     698\rhs \nonterm{postfix-expression} \lstinline@--@
     699\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@}@
     700\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@,@ \lstinline@}@
    834701\lhs{argument-expression-list}
    835702\rhs \nonterm{assignment-expression}
    836 \rhs \nonterm{argument-expression-list} \lstinline$,$
     703\rhs \nonterm{argument-expression-list} \lstinline@,@
    837704         \nonterm{assignment-expression}
    838705\end{syntax}
     
    840707\rewriterules
    841708\begin{lstlisting}
    842 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type@\use{?[?]}@
    843 a[b] @\rewrite@ ?[?]( a, b ) // otherwise
    844 a( @\emph{arguments}@ ) @\rewrite@ ?()( a, @\emph{arguments}@ )@\use{?()}@
    845 a++ @\rewrite@ ?++(&( a ))@\use{?++}@
    846 a-- @\rewrite@ ?--(&( a ))@\use{?--}@
     709a[b] §\rewrite§ ?[?]( b, a ) // if a has integer type§\use{?[?]}§
     710a[b] §\rewrite§ ?[?]( a, b ) // otherwise
     711a( §\emph{arguments}§ ) §\rewrite§ ?()( a, §\emph{arguments}§ )§\use{?()}§
     712a++ §\rewrite§ ?++(&( a ))§\use{?++}§
     713a-- §\rewrite§ ?--(&( a ))§\use{?--}§
    847714\end{lstlisting}
    848715
     
    852719\predefined
    853720\begin{lstlisting}
    854 forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
     721forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );§\use{ptrdiff_t}§
    855722forall( otype T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
    856723forall( otype T ) lvalue const T ?[?]( const T *, ptrdiff_t );
     
    872739The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    873740\begin{rationale}
    874 C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
    875 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline$?[?]$.
     741C defines subscripting as pointer arithmetic in a way that makes \lstinline@a[i]@ and
     742\lstinline@i[a]@ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline@?[?]@.
    876743
    877744Subscript expressions are rewritten as function calls that pass the first parameter by value.
    878745This is somewhat unfortunate, since array-like types tend to be large.
    879 The alternative is to use the rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''.
    880 However, C semantics forbid this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which does not have an address.
     746The alternative is to use the rewrite rule ``\lstinline@a[b]@ \rewrite \lstinline@?[?](&(a), b)@''.
     747However, C semantics forbid this approach: the \lstinline@a@ in ``\lstinline@a[b]@'' can be an arbitrary pointer value, which does not have an address.
    881748
    882749The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
     
    893760\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    894761
    895 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline$?()$''.
     762For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline@?()@''.
    896763The valid interpretations of the rewritten expression are determined in the manner described below.
    897764
     
    901768\item if the argument corresponds to a parameter in the function designator's prototype, the argument interpretation must have the same type as the corresponding parameter, or be implicitly convertible to the parameter's type
    902769\item if the function designator's type does not include a prototype or if the argument corresponds to
    903 ``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
     770``\lstinline@...@'' in a prototype, a \Index{default argument promotion} is applied to it.
    904771\end{itemize}
    905772The type of the valid interpretation is the return type of the function designator.
     
    909776\begin{itemize}
    910777\item
    911 If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the implicit argument must be an object type;
    912 if it uses \lstinline$dtype$, the implicit argument must be an object type or an incomplete type;
    913 and if it uses \lstinline$ftype$, the implicit argument must be a function type.
     778If the declaration of the implicit parameter uses \Index{type-class} \lstinline@type@\use{type}, the implicit argument must be an object type;
     779if it uses \lstinline@dtype@, the implicit argument must be an object type or an incomplete type;
     780and if it uses \lstinline@ftype@, the implicit argument must be a function type.
    914781
    915782\item if an explicit parameter's type uses any implicit parameters, then the corresponding explicit argument must have a type that is (or can be safely converted\index{safe conversion} to) the type produced by substituting the implicit arguments for the implicit parameters in the explicit parameter type.
     
    930797\begin{rationale}
    931798One desirable property of a polymorphic programming language is \define{generalizability}: the ability to replace an abstraction with a more general but equivalent abstraction without requiring changes in any of the uses of the original\cite{Cormack90}.
    932 For instance, it should be possible to replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( otype T ) T f( T );$'' without affecting any calls of \lstinline$f$.
     799For instance, it should be possible to replace a function ``\lstinline@int f( int );@'' with ``\lstinline@forall( otype T ) T f( T );@'' without affecting any calls of \lstinline@f@.
    933800
    934801\CFA\index{deficiencies!generalizability} does not fully possess this property, because
     
    944811f = g( d, f );          // (3) (unsafe conversion to float)
    945812\end{lstlisting}
    946 If \lstinline$g$ was replaced by ``\lstinline$forall( otype T ) T g( T, T );$'', the first and second calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
    947 \lstinline$double$, and the result would be a \lstinline$double$.
    948 
    949 Another example is the function ``\lstinline$void h( int *);$''.
     813If \lstinline@g@ was replaced by ``\lstinline@forall( otype T ) T g( T, T );@'', the first and second calls would be unaffected, but the third would change: \lstinline@f@ would be converted to
     814\lstinline@double@, and the result would be a \lstinline@double@.
     815
     816Another example is the function ``\lstinline@void h( int *);@''.
    950817This function can be passed a
    951 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( otype T ) void h( T *);$'' can not.
    952 In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an object type.
    953 If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} object type, which is undesirable.
     818\lstinline@void *@ argument, but the generalization ``\lstinline@forall( otype T ) void h( T *);@'' can not.
     819In this case, \lstinline@void@ is not a valid value for \lstinline@T@ because it is not an object type.
     820If unsafe conversions were allowed, \lstinline@T@ could be inferred to be \emph{any} object type, which is undesirable.
    954821\end{rationale}
    955822
    956823\examples
    957 A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
     824A function called ``\lstinline@?()@'' might be part of a numerical differentiation package.
    958825\begin{lstlisting}
    959826extern otype Derivative;
     
    966833d = sin_dx( 12.9 );
    967834\end{lstlisting}
    968 Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$.
    969 For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
     835Here, the only interpretation of \lstinline@sin_dx@ is as an object of type \lstinline@Derivative@.
     836For that interpretation, the function call is treated as ``\lstinline@?()( sin_dx, 12.9 )@''.
    970837\begin{lstlisting}
    971838int f( long );          // (1)
     
    974841int i = f( 5 );         // calls (1)
    975842\end{lstlisting}
    976 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit \lstinline$int$ to \lstinline$long$ conversion.
    977 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline$int$ to \lstinline$int *$ that could be used with the third function.
     843Function (1) provides a valid interpretation of ``\lstinline@f( 5 )@'', using an implicit \lstinline@int@ to \lstinline@long@ conversion.
     844The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline@int@ to \lstinline@int *@ that could be used with the third function.
    978845
    979846\begin{lstlisting}
     
    981848double d = h( 1.5 );
    982849\end{lstlisting}
    983 ``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be
    984 \lstinline$double$, and the result of the function call is a \lstinline$double$.
     850``\lstinline@1.5@'' is a \lstinline@double@ constant, so \lstinline@T@ is inferred to be
     851\lstinline@double@, and the result of the function call is a \lstinline@double@.
    985852
    986853\begin{lstlisting}
     
    997864g( i, p );                      // calls (4)
    998865\end{lstlisting}
    999 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is chosen because it is less polymorphic than (4).
     866The first call has valid interpretations for all four versions of \lstinline@g@. (6) and (7) are discarded because they involve unsafe \lstinline@double@-to-\lstinline@long@ conversions. (5) is chosen because it is less polymorphic than (4).
    1000867
    1001868For the second call, (7) is again discarded.
    1002 Of the remaining interpretations for (4), (5), and (6) (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least polymorphic.
     869Of the remaining interpretations for (4), (5), and (6) (with \lstinline@i@ converted to \lstinline@long@), (6) is chosen because it is the least polymorphic.
    1003870
    1004871The third call has valid interpretations for all of the functions;
     
    1009876forall( otype T ) T min( T, T );
    1010877double max( double, double );
    1011 trait min_max( T ) {@\impl{min_max}@
     878trait min_max( T ) {§\impl{min_max}§
    1012879        T min( T, T );
    1013880        T max( T, T );
     
    1016883shuffle( 9, 10 );
    1017884\end{lstlisting}
    1018 The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the only visible \lstinline$max$ function. 9 and 10 must be converted to \lstinline$double$, and
    1019 \lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$.
     885The only possibility for \lstinline@U@ is \lstinline@double@, because that is the type used in the only visible \lstinline@max@ function. 9 and 10 must be converted to \lstinline@double@, and
     886\lstinline@min@ must be specialized with \lstinline@T@ bound to \lstinline@double@.
    1020887\begin{lstlisting}
    1021888extern void q( int );           // (8)
     
    1025892r( 0 );
    1026893\end{lstlisting}
    1027 The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9).
    1028 The former is chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}.
    1029 For the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has \emph{no} declared parameter types.
     894The \lstinline@int 0@ could be passed to (8), or the \lstinline@(void *)@ \Index{specialization} of the null pointer\index{null pointer} \lstinline@0@\use{0} could be passed to (9).
     895The former is chosen because the \lstinline@int@ \lstinline@0@ is \Index{less polymorphic}.
     896For the same reason, \lstinline@int@ \lstinline@0@ is passed to \lstinline@r()@, even though it has \emph{no} declared parameter types.
    1030897
    1031898
    1032899\subsubsection{Structure and union members}
    1033900
    1034 \semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a member named \lstinline$m$.
    1035 If two or more interpretations of \lstinline$s$ have members named
    1036 \lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
    1037 If an interpretation of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
    1038 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type.
     901\semantics In the member selection expression ``\lstinline@s@.\lstinline@m@'', there shall be at least one interpretation of \lstinline@s@ whose type is a structure type or union type containing a member named \lstinline@m@.
     902If two or more interpretations of \lstinline@s@ have members named
     903\lstinline@m@ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
     904If an interpretation of \lstinline@s@ has a member \lstinline@m@ whose type is not compatible with any other
     905\lstinline@s@'s \lstinline@m@, then the expression has an interpretation with the member's type.
    1039906The expression has no other interpretations.
    1040907
    1041 The expression ``\lstinline$p->m$'' has the same interpretations as the expression
    1042 ``\lstinline$(*p).m$''.
     908The expression ``\lstinline@p->m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.
    1043909
    1044910
     
    11351001        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    11361002\end{lstlisting}
    1137 For every extended integer type \lstinline$X$ there exist
     1003For every extended integer type \lstinline@X@ there exist
    11381004% Don't use predefined: keep this out of prelude.cf.
    11391005\begin{lstlisting}
     
    11411007  ?--( volatile X * ), ?--( _Atomic volatile X * );
    11421008\end{lstlisting}
    1143 For every complete enumerated type \lstinline$E$ there exist
     1009For every complete enumerated type \lstinline@E@ there exist
    11441010% Don't use predefined: keep this out of prelude.cf.
    11451011\begin{lstlisting}
     
    11491015
    11501016\begin{rationale}
    1151 Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
     1017Note that ``\lstinline@++@'' and ``\lstinline@--@'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
    11521018This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    11531019\end{rationale}
     
    11551021\begin{rationale}
    11561022In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
    1157 Hence, \lstinline$void *$ objects cannot be incremented.
    1158 In \CFA, the restriction follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the type parameter \lstinline$T$.
     1023Hence, \lstinline@void *@ objects cannot be incremented.
     1024In \CFA, the restriction follows from the use of a \lstinline@type@ parameter in the predefined function definitions, as opposed to \lstinline@dtype@, since only object types can be inferred arguments corresponding to the type parameter \lstinline@T@.
    11591025\end{rationale}
    11601026
    11611027\semantics
    11621028First, each interpretation of the operand of an increment or decrement expression is considered separately.
    1163 For each interpretation that is a bit-field or is declared with the
    1164 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is.
     1029For each interpretation that is a bit-field or is declared with the \Indexc{register}\index{storage-class specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is.
    11651030
    11661031For the remaining interpretations, the expression is rewritten, and the interpretations of the expression are the interpretations of the corresponding function call.
     
    11751040\end{lstlisting}
    11761041\begin{sloppypar}
    1177 Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of
    1178 \lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
    1179 \lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
    1180 \lstinline$volatile short int *$.
    1181 Note that there is no conversion that adds an \lstinline$_Atomic$ qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid interpretation.
     1042Since \lstinline@&(vs)@ has type \lstinline@volatile short int *@, the best valid interpretation of
     1043\lstinline@vs++@ calls the \lstinline@?++@ function with the \lstinline@volatile short *@ parameter.
     1044\lstinline@s++@ does the same, applying the safe conversion from \lstinline@short int *@ to \lstinline@volatile short int *@.
     1045Note that there is no conversion that adds an \lstinline@_Atomic@ qualifier, so the \lstinline@_Atomic volatile short int@ overloading does not provide a valid interpretation.
    11821046\end{sloppypar}
    11831047
    1184 There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$, and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$ has no valid interpretations.
    1185 
    1186 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the \lstinline$volatile$ qualifier.
     1048There is no safe conversion from \lstinline@const short int *@ to \lstinline@volatile short int *@, and no \lstinline@?++@ function that accepts a \lstinline@const *@ parameter, so \lstinline@cs++@ has no valid interpretations.
     1049
     1050The best valid interpretation of \lstinline@as++@ calls the \lstinline@short ?++@ function with the \lstinline@_Atomic volatile short int *@ parameter, applying a safe conversion to add the \lstinline@volatile@ qualifier.
    11871051\begin{lstlisting}
    11881052char * const restrict volatile * restrict volatile pqpc;
     
    11911055ppc++;
    11921056\end{lstlisting}
    1193 Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$, the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring \lstinline$T$ to be \lstinline$char *$.
    1194 
    1195 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, and using the safe conversions from \lstinline$T$ to \lstinline$T const$ \lstinline$restrict volatile$.
     1057Since \lstinline@&(pqpc)@ has type \lstinline@char * const restrict volatile * restrict volatile *@, the best valid interpretation of \lstinline@pqpc++@ calls the polymorphic \lstinline@?++@ function with the \lstinline@const restrict volatile T * restrict volatile *@ parameter, inferring \lstinline@T@ to be \lstinline@char *@.
     1058
     1059\lstinline@ppc++@ calls the same function, again inferring \lstinline@T@ to be \lstinline@char *@, and using the safe conversions from \lstinline@T@ to \lstinline@T const@ \lstinline@restrict volatile@.
    11961060
    11971061\begin{rationale}
     
    12071071\begin{enumerate}
    12081072\item
    1209 ``\lstinline$char * p; p++;$''.
    1210 The argument to \lstinline$?++$ has type \lstinline$char * *$, and the result has type \lstinline$char *$.
    1211 The expression would be valid if \lstinline$?++$ were declared by
     1073``\lstinline@char * p; p++;@''.
     1074The argument to \lstinline@?++@ has type \lstinline@char * *@, and the result has type \lstinline@char *@.
     1075The expression would be valid if \lstinline@?++@ were declared by
    12121076\begin{lstlisting}
    12131077forall( otype T ) T * ?++( T * * );
    1214 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$char$.
    1215 
    1216 \item
    1217 ``\lstinline$char *restrict volatile qp; qp++$''.
    1218 The result again has type \lstinline$char *$, but the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the hypothetical function declared in point 1.
     1078\end{lstlisting} with \lstinline@T@ inferred to be \lstinline@char@.
     1079
     1080\item
     1081``\lstinline@char *restrict volatile qp; qp++@''.
     1082The result again has type \lstinline@char *@, but the argument now has type \lstinline@char *restrict volatile *@, so it cannot be passed to the hypothetical function declared in point 1.
    12191083Hence the actual predefined function is
    12201084\begin{lstlisting}
    12211085forall( otype T ) T * ?++( T * restrict volatile * );
    1222 \end{lstlisting} which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
    1223 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
    1224 
    1225 \item
    1226 ``\lstinline$char *_Atomic ap; ap++$''.
    1227 The result again has type \lstinline$char *$, but no safe conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable.
    1228 A separate overloading of \lstinline$?++$ is required.
    1229 
    1230 \item
    1231 ``\lstinline$char const volatile * pq; pq++$''.
     1086\end{lstlisting} which also accepts a \lstinline@char * *@ argument, because of the safe conversions that add
     1087\lstinline@volatile@ and \lstinline@restrict@ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
     1088
     1089\item
     1090``\lstinline@char *_Atomic ap; ap++@''.
     1091The result again has type \lstinline@char *@, but no safe conversion adds an \lstinline@_Atomic@ qualifier, so the function in point 2 is not applicable.
     1092A separate overloading of \lstinline@?++@ is required.
     1093
     1094\item
     1095``\lstinline@char const volatile * pq; pq++@''.
    12321096Here the result has type
    1233 \lstinline$char const volatile *$, so a new overloading is needed:
     1097\lstinline@char const volatile *@, so a new overloading is needed:
    12341098\begin{lstlisting}
    12351099forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     
    12381102 
    12391103\item
    1240 ``\lstinline$float *restrict * prp; prp++$''.
    1241 The \lstinline$restrict$ qualifier is handled just like \lstinline$const$ and \lstinline$volatile$ in the previous case:
     1104``\lstinline@float *restrict * prp; prp++@''.
     1105The \lstinline@restrict@ qualifier is handled just like \lstinline@const@ and \lstinline@volatile@ in the previous case:
    12421106\begin{lstlisting}
    12431107forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    1244 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$float *$.
    1245 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$ is not syntactically a pointer type. \CFA loosens the constraint.
     1108\end{lstlisting} with \lstinline@T@ inferred to be \lstinline@float *@.
     1109This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline@T@ is not syntactically a pointer type. \CFA loosens the constraint.
    12461110\end{enumerate}
    12471111\end{rationale}
     
    12591123\lhs{unary-expression}
    12601124\rhs \nonterm{postfix-expression}
    1261 \rhs \lstinline$++$ \nonterm{unary-expression}
    1262 \rhs \lstinline$--$ \nonterm{unary-expression}
     1125\rhs \lstinline@++@ \nonterm{unary-expression}
     1126\rhs \lstinline@--@ \nonterm{unary-expression}
    12631127\rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1264 \rhs \lstinline$sizeof$ \nonterm{unary-expression}
    1265 \rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$
    1266 \lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$
     1128\rhs \lstinline@sizeof@ \nonterm{unary-expression}
     1129\rhs \lstinline@sizeof@ \lstinline@(@ \nonterm{type-name} \lstinline@)@
     1130\lhs{unary-operator} one of \rhs \lstinline@&@ \lstinline@*@ \lstinline@+@ \lstinline@-@ \lstinline@~@ \lstinline@!@
    12671131\end{syntax}
    12681132
    12691133\rewriterules
    12701134\begin{lstlisting}
    1271 *a      @\rewrite@ *?( a ) @\use{*?}@
    1272 +a      @\rewrite@ +?( a ) @\use{+?}@
    1273 -a      @\rewrite@ -?( a ) @\use{-?}@
    1274 ~a      @\rewrite@ ~?( a ) @\use{~?}@
    1275 !a      @\rewrite@ !?( a ) @\use{"!?}@
    1276 ++a     @\rewrite@ ++?(&( a )) @\use{++?}@
    1277 --a     @\rewrite@ --?(&( a )) @\use{--?}@
     1135*a      §\rewrite§ *?( a ) §\use{*?}§
     1136+a      §\rewrite§ +?( a ) §\use{+?}§
     1137-a      §\rewrite§ -?( a ) §\use{-?}§
     1138~a      §\rewrite§ ~?( a ) §\use{~?}§
     1139!a      §\rewrite§ !?( a ) §\use{"!?}§
     1140++a     §\rewrite§ ++?(&( a )) §\use{++?}§
     1141--a     §\rewrite§ --?(&( a )) §\use{--?}§
    12781142\end{lstlisting}
    12791143
     
    13711235        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    13721236\end{lstlisting}
    1373 For every extended integer type \lstinline$X$ there exist
     1237For every extended integer type \lstinline@X@ there exist
    13741238% Don't use predefined: keep this out of prelude.cf.
    13751239\begin{lstlisting}
     
    13791243        --?( _Atomic volatile X * );
    13801244\end{lstlisting}
    1381 For every complete enumerated type \lstinline$E$ there exist
     1245For every complete enumerated type \lstinline@E@ there exist
    13821246% Don't use predefined: keep this out of prelude.cf.
    13831247\begin{lstlisting}
     
    14161280
    14171281\constraints
    1418 The operand of the unary ``\lstinline$&$'' operator shall have exactly one
     1282The operand of the unary ``\lstinline@&@'' operator shall have exactly one
    14191283\Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    14201284
    14211285\semantics
    1422 The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where
    1423 \lstinline$T$ is the type of the operand.
     1286The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where
     1287\lstinline@T@ is the type of the operand.
    14241288
    14251289The interpretations of an indirection expression are the interpretations of the corresponding function call.
     
    14501314forall( ftype FT ) int !?( FT * );
    14511315\end{lstlisting}
    1452 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1316For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    14531317% Don't use predefined: keep this out of prelude.cf.
    14541318\begin{lstlisting}
     
    14631327\begin{lstlisting}
    14641328long int li;
    1465 void eat_double( double );@\use{eat_double}@
    1466 eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
    1467 \end{lstlisting}
    1468 The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
     1329void eat_double( double );§\use{eat_double}§
     1330eat_double(-li ); // §\rewrite§ eat_double( -?( li ) );
     1331\end{lstlisting}
     1332The valid interpretations of ``\lstinline@-li@'' (assuming no extended integer types exist) are
    14691333\begin{center}
    14701334\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    14711335\hline
    1472 \lstinline$-?( (int)li )$                                       & \lstinline$int$                                       & (unsafe) \\
    1473 \lstinline$-?( (unsigned)li)$                           & \lstinline$unsigned int$                      & (unsafe) \\
    1474 \lstinline$-?( (long)li)$                                       & \lstinline$long$                                      & 0 \\
    1475 \lstinline$-?( (long unsigned int)li)$          & \lstinline$long unsigned int$         & 1 \\
    1476 \lstinline$-?( (long long int)li)$                      & \lstinline$long long int$                     & 2 \\
    1477 \lstinline$-?( (long long unsigned int)li)$     & \lstinline$long long unsigned int$& 3 \\
    1478 \lstinline$-?( (float)li)$                                      & \lstinline$float$                                     & 4 \\
    1479 \lstinline$-?( (double)li)$                                     & \lstinline$double$                            & 5 \\
    1480 \lstinline$-?( (long double)li)$                        & \lstinline$long double$                       & 6 \\
    1481 \lstinline$-?( (_Complex float)li)$                     & \lstinline$float$                                     & (unsafe) \\
    1482 \lstinline$-?( (_Complex double)li)$            & \lstinline$double$                            & (unsafe) \\
    1483 \lstinline$-?( (_Complex long double)li)$       & \lstinline$long double$                       & (unsafe) \\
     1336\lstinline@-?( (int)li )@                                       & \lstinline@int@                                       & (unsafe) \\
     1337\lstinline@-?( (unsigned)li)@                           & \lstinline@unsigned int@                      & (unsafe) \\
     1338\lstinline@-?( (long)li)@                                       & \lstinline@long@                                      & 0 \\
     1339\lstinline@-?( (long unsigned int)li)@          & \lstinline@long unsigned int@         & 1 \\
     1340\lstinline@-?( (long long int)li)@                      & \lstinline@long long int@                     & 2 \\
     1341\lstinline@-?( (long long unsigned int)li)@     & \lstinline@long long unsigned int@& 3 \\
     1342\lstinline@-?( (float)li)@                                      & \lstinline@float@                                     & 4 \\
     1343\lstinline@-?( (double)li)@                                     & \lstinline@double@                            & 5 \\
     1344\lstinline@-?( (long double)li)@                        & \lstinline@long double@                       & 6 \\
     1345\lstinline@-?( (_Complex float)li)@                     & \lstinline@float@                                     & (unsafe) \\
     1346\lstinline@-?( (_Complex double)li)@            & \lstinline@double@                            & (unsafe) \\
     1347\lstinline@-?( (_Complex long double)li)@       & \lstinline@long double@                       & (unsafe) \\
    14841348\end{tabular}
    14851349\end{center}
    1486 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument conversion and the cost of the entire expression, are
     1350The valid interpretations of the \lstinline@eat_double@ call, with the cost of the argument conversion and the cost of the entire expression, are
    14871351\begin{center}
    14881352\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    14891353\hline
    1490 \lstinline$eat_double( (double)-?( (int)li) )$                                  & 7                     & (unsafe) \\
    1491 \lstinline$eat_double( (double)-?( (unsigned)li) )$                             & 6                     & (unsafe) \\
    1492 \lstinline$eat_double( (double)-?(li) )$                                                & 5                     & \(0+5=5\) \\
    1493 \lstinline$eat_double( (double)-?( (long unsigned int)li) )$    & 4                     & \(1+4=5\) \\
    1494 \lstinline$eat_double( (double)-?( (long long int)li) )$                & 3                     & \(2+3=5\) \\
    1495 \lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2            & \(3+2=5\) \\
    1496 \lstinline$eat_double( (double)-?( (float)li) )$                                & 1                     & \(4+1=5\) \\
    1497 \lstinline$eat_double( (double)-?( (double)li) )$                               & 0                     & \(5+0=5\) \\
    1498 \lstinline$eat_double( (double)-?( (long double)li) )$                  & (unsafe)      & (unsafe) \\
    1499 \lstinline$eat_double( (double)-?( (_Complex float)li) )$               & (unsafe)      & (unsafe) \\
    1500 \lstinline$eat_double( (double)-?( (_Complex double)li) )$              & (unsafe)      & (unsafe) \\
    1501 \lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe)      & (unsafe) \\
     1354\lstinline@eat_double( (double)-?( (int)li) )@                                  & 7                     & (unsafe) \\
     1355\lstinline@eat_double( (double)-?( (unsigned)li) )@                             & 6                     & (unsafe) \\
     1356\lstinline@eat_double( (double)-?(li) )@                                                & 5                     & \(0+5=5\) \\
     1357\lstinline@eat_double( (double)-?( (long unsigned int)li) )@    & 4                     & \(1+4=5\) \\
     1358\lstinline@eat_double( (double)-?( (long long int)li) )@                & 3                     & \(2+3=5\) \\
     1359\lstinline@eat_double( (double)-?( (long long unsigned int)li) )@& 2            & \(3+2=5\) \\
     1360\lstinline@eat_double( (double)-?( (float)li) )@                                & 1                     & \(4+1=5\) \\
     1361\lstinline@eat_double( (double)-?( (double)li) )@                               & 0                     & \(5+0=5\) \\
     1362\lstinline@eat_double( (double)-?( (long double)li) )@                  & (unsafe)      & (unsafe) \\
     1363\lstinline@eat_double( (double)-?( (_Complex float)li) )@               & (unsafe)      & (unsafe) \\
     1364\lstinline@eat_double( (double)-?( (_Complex double)li) )@              & (unsafe)      & (unsafe) \\
     1365\lstinline@eat_double( (double)-?( (_Complex long double)li) )@ & (unsafe)      & (unsafe) \\
    15021366\end{tabular}
    15031367\end{center}
    1504 Each has result type \lstinline$void$, so the best must be selected.
     1368Each has result type \lstinline@void@, so the best must be selected.
    15051369The interpretations involving unsafe conversions are discarded.
    15061370The remainder have equal expression conversion costs, so the
    15071371``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    1508 \lstinline$eat_double( (double)-?(li) )$.
    1509 
    1510 
    1511 \subsubsection{The \lstinline$sizeof$ and \lstinline$_Alignof$ operators}
     1372\lstinline@eat_double( (double)-?(li) )@.
     1373
     1374
     1375\subsubsection[The sizeof and \_Alignof operators]{The \lstinline@sizeof@ and \lstinline@_Alignof@ operators}
    15121376
    15131377\constraints
    1514 The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$,
    1515 \lstinline$dtype$, or \lstinline$ftype$.
    1516 
    1517 When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one interpretation, of type \lstinline$size_t$.
    1518 
    1519 When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1378The operand of \lstinline@sizeof@ or \lstinline@_Alignof@ shall not be \lstinline@type@, \lstinline@dtype@, or \lstinline@ftype@.
     1379
     1380When the \lstinline@sizeof@\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline@sizeof@ or \lstinline@_Alignof@ expression has one interpretation, of type \lstinline@size_t@.
     1381
     1382When \lstinline@sizeof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
    15201383\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    15211384When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    15221385
    1523 When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1386When \lstinline@_Alignof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
    15241387\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    15251388When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     
    15281391otype Pair = struct { int first, second; };
    15291392size_t p_size = sizeof(Pair);           // constant expression
    1530 extern otype Rational;@\use{Rational}@
     1393extern otype Rational;§\use{Rational}§
    15311394size_t c_size = sizeof(Rational);       // non-constant expression
    15321395forall(type T) T f(T p1, T p2) {
     
    15351398}
    15361399\end{lstlisting}
    1537 ``\lstinline$sizeof Rational$'', although not statically known, is fixed.
    1538 Within \lstinline$f()$,
    1539 ``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
     1400``\lstinline@sizeof Rational@'', although not statically known, is fixed.
     1401Within \lstinline@f()@,
     1402``\lstinline@sizeof(T)@'' is fixed for each call of \lstinline@f()@, but may vary from call to call.
    15401403\end{rationale}
    15411404
     
    15461409\lhs{cast-expression}
    15471410\rhs \nonterm{unary-expression}
    1548 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression}
     1411\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \nonterm{cast-expression}
    15491412\end{syntax}
    15501413
    15511414\constraints
    1552 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$,
    1553 \lstinline$dtype$, or \lstinline$ftype$.
     1415The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline@type@,
     1416\lstinline@dtype@, or \lstinline@ftype@.
    15541417
    15551418\semantics
    15561419
    1557 In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
    1558 \nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is the only interpretation of the cast expression;
    1559 otherwise, \lstinline$e$ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
     1420In a \Index{cast expression} ``\lstinline@(@\nonterm{type-name}\lstinline@)e@'', if
     1421\nonterm{type-name} is the type of an interpretation of \lstinline@e@, then that interpretation is the only interpretation of the cast expression;
     1422otherwise, \lstinline@e@ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
    15601423The cast expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
    15611424
     
    15701433\lhs{multiplicative-expression}
    15711434\rhs \nonterm{cast-expression}
    1572 \rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression}
    1573 \rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression}
    1574 \rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression}
     1435\rhs \nonterm{multiplicative-expression} \lstinline@*@ \nonterm{cast-expression}
     1436\rhs \nonterm{multiplicative-expression} \lstinline@/@ \nonterm{cast-expression}
     1437\rhs \nonterm{multiplicative-expression} \lstinline@%@ \nonterm{cast-expression}
    15751438\end{syntax}
    15761439
    15771440\rewriterules
    15781441\begin{lstlisting}
    1579 a * b @\rewrite@ ?*?( a, b )@\use{?*?}@
    1580 a / b @\rewrite@ ?/?( a, b )@\use{?/?}@
    1581 a % b @\rewrite@ ?%?( a, b )@\use{?%?}@
     1442a * b §\rewrite§ ?*?( a, b )§\use{?*?}§
     1443a / b §\rewrite§ ?/?( a, b )§\use{?/?}§
     1444a % b §\rewrite§ ?%?( a, b )§\use{?%?}§
    15821445\end{lstlisting}
    15831446
     
    16061469        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    16071470\end{lstlisting}
    1608 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1471For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    16091472% Don't use predefined: keep this out of prelude.cf.
    16101473\begin{lstlisting}
     
    16241487int i;
    16251488long li;
    1626 void eat_double( double );@\use{eat_double}@
     1489void eat_double( double );§\use{eat_double}§
    16271490eat_double( li % i );
    16281491\end{lstlisting}
    1629 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''.
    1630 The valid interpretations of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline$double$ (assuming no extended integer types are present ) are
     1492``\lstinline@li % i@'' is rewritten as ``\lstinline@?%?(li, i )@''.
     1493The valid interpretations of \lstinline@?%?(li, i )@, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline@double@ (assuming no extended integer types are present ) are
    16311494\begin{center}
    16321495\begin{tabular}{lcc} interpretation & argument cost & result cost \\
    16331496\hline
    1634 \lstinline$ ?%?( (int)li, i )$                                                                          & (unsafe)      & 6     \\
    1635 \lstinline$ ?%?( (unsigned)li,(unsigned)i )$                                            & (unsafe)      & 5     \\
    1636 \lstinline$ ?%?( li, (long)i )$                                                                         & 1                     & 4     \\
    1637 \lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$                          & 3                     & 3     \\
    1638 \lstinline$ ?%?( (long long)li,(long long)i )$                                          & 5                     & 2     \\
    1639 \lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$       & 7                     & 1     \\
     1497\lstinline@ ?%?( (int)li, i )@                                                                          & (unsafe)      & 6     \\
     1498\lstinline@ ?%?( (unsigned)li,(unsigned)i )@                                            & (unsafe)      & 5     \\
     1499\lstinline@ ?%?( li, (long)i )@                                                                         & 1                     & 4     \\
     1500\lstinline@ ?%?( (long unsigned)li,(long unsigned)i )@                          & 3                     & 3     \\
     1501\lstinline@ ?%?( (long long)li,(long long)i )@                                          & 5                     & 2     \\
     1502\lstinline@ ?%?( (long long unsigned)li, (long long unsigned)i )@       & 7                     & 1     \\
    16401503\end{tabular}
    16411504\end{center}
    1642 The best interpretation of \lstinline$eat_double( li, i )$ is
    1643 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the lowest total cost.
    1644 
    1645 \begin{rationale}
    1646 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
    1647 \lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
    1648 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches that pattern;
    1649 it does not predefine ``\lstinline$short ?*?( short, short )$''.
     1505The best interpretation of \lstinline@eat_double( li, i )@ is
     1506\lstinline@eat_double( (double)?%?(li, (long)i ))@, which has no unsafe conversions and the lowest total cost.
     1507
     1508\begin{rationale}
     1509{\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline@int@.If
     1510\lstinline@s@ is a \lstinline@short int@, ``\lstinline@s *s@'' does not have type \lstinline@short int@;
     1511it is treated as ``\lstinline@( (int)s ) * ( (int)s )@'', and has type \lstinline@int@. \CFA matches that pattern;
     1512it does not predefine ``\lstinline@short ?*?( short, short )@''.
    16501513
    16511514These ``missing'' operators limit polymorphism.
     
    16561519square( s );
    16571520\end{lstlisting}
    1658 Since \CFA does not define a multiplication operator for \lstinline$short int$,
    1659 \lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
    1660 \lstinline$int$.
     1521Since \CFA does not define a multiplication operator for \lstinline@short int@,
     1522\lstinline@square( s )@ is treated as \lstinline@square( (int)s )@, and the result has type
     1523\lstinline@int@.
    16611524This is mildly surprising, but it follows the {\c11} operator pattern.
    16621525
     
    16681531\end{lstlisting}
    16691532This has no valid interpretations, because \CFA has no conversion from ``array of
    1670 \lstinline$short int$'' to ``array of \lstinline$int$''.
     1533\lstinline@short int@'' to ``array of \lstinline@int@''.
    16711534The alternatives in such situations include
    16721535\begin{itemize}
    16731536\item
    1674 Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other
     1537Defining monomorphic overloadings of \lstinline@product@ for \lstinline@short@ and the other
    16751538``small'' types.
    16761539\item
    1677 Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to
    1678 \lstinline$product$.
    1679 \item
    1680 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
     1540Defining ``\lstinline@short ?*?( short, short )@'' within the scope containing the call to
     1541\lstinline@product@.
     1542\item
     1543Defining \lstinline@product@ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    16811544\end{itemize}
    16821545\end{rationale}
     
    16881551\lhs{additive-expression}
    16891552\rhs \nonterm{multiplicative-expression}
    1690 \rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression}
    1691 \rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression}
     1553\rhs \nonterm{additive-expression} \lstinline@+@ \nonterm{multiplicative-expression}
     1554\rhs \nonterm{additive-expression} \lstinline@-@ \nonterm{multiplicative-expression}
    16921555\end{syntax}
    16931556
    16941557\rewriterules
    16951558\begin{lstlisting}
    1696 a + b @\rewrite@ ?+?( a, b )@\use{?+?}@
    1697 a - b @\rewrite@ ?-?( a, b )@\use{?-?}@
     1559a + b §\rewrite§ ?+?( a, b )§\use{?+?}§
     1560a - b §\rewrite§ ?-?( a, b )§\use{?-?}§
    16981561\end{lstlisting}
    16991562
     
    17481611        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    17491612\end{lstlisting}
    1750 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1613For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    17511614% Don't use predefined: keep this out of prelude.cf.
    17521615\begin{lstlisting}
     
    17581621
    17591622\begin{rationale}
    1760 \lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
     1623\lstinline@ptrdiff_t@ is an implementation-defined identifier defined in \lstinline@<stddef.h>@ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
    17611624It seems reasonable to use it for pointer addition as well. (This is technically a difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral} argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
    1762 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an unsigned type.
     1625The {\c11} standard uses \lstinline@size_t@ in several cases where a library function takes an argument that is used as a subscript, but \lstinline@size_t@ is unsuitable here because it is an unsigned type.
    17631626\end{rationale}
    17641627
     
    17691632\lhs{shift-expression}
    17701633\rhs \nonterm{additive-expression}
    1771 \rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression}
    1772 \rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression}
     1634\rhs \nonterm{shift-expression} \lstinline@<<@ \nonterm{additive-expression}
     1635\rhs \nonterm{shift-expression} \lstinline@>>@ \nonterm{additive-expression}
    17731636\end{syntax}
    17741637
    17751638\rewriterules \use{?>>?}%use{?<<?}
    17761639\begin{lstlisting}
    1777 a << b @\rewrite@ ?<<?( a, b )
    1778 a >> b @\rewrite@ ?>>?( a, b )
     1640a << b §\rewrite§ ?<<?( a, b )
     1641a >> b §\rewrite§ ?>>?( a, b )
    17791642\end{lstlisting}
    17801643
     
    17881651long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    17891652\end{lstlisting}
    1790 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1653For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    17911654% Don't use predefined: keep this out of prelude.cf.
    17921655\begin{lstlisting}
     
    18081671\lhs{relational-expression}
    18091672\rhs \nonterm{shift-expression}
    1810 \rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression}
    1811 \rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression}
    1812 \rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression}
    1813 \rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression}
     1673\rhs \nonterm{relational-expression} \lstinline@< @ \nonterm{shift-expression}
     1674\rhs \nonterm{relational-expression} \lstinline@> @ \nonterm{shift-expression}
     1675\rhs \nonterm{relational-expression} \lstinline@<=@ \nonterm{shift-expression}
     1676\rhs \nonterm{relational-expression} \lstinline@>=@ \nonterm{shift-expression}
    18141677\end{syntax}
    18151678
    18161679\rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
    18171680\begin{lstlisting}
    1818 a < b @\rewrite@ ?<?( a, b )
    1819 a > b @\rewrite@ ?>?( a, b )
    1820 a <= b @\rewrite@ ?<=?( a, b )
    1821 a >= b @\rewrite@ ?>=?( a, b )
     1681a < b §\rewrite§ ?<?( a, b )
     1682a > b §\rewrite§ ?>?( a, b )
     1683a <= b §\rewrite§ ?<=?( a, b )
     1684a >= b §\rewrite§ ?>=?( a, b )
    18221685\end{lstlisting}
    18231686
     
    18511714        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    18521715\end{lstlisting}
    1853 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1716For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    18541717% Don't use predefined: keep this out of prelude.cf.
    18551718\begin{lstlisting}
     
    18691732\lhs{equality-expression}
    18701733\rhs \nonterm{relational-expression}
    1871 \rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression}
    1872 \rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression}
     1734\rhs \nonterm{equality-expression} \lstinline@==@ \nonterm{relational-expression}
     1735\rhs \nonterm{equality-expression} \lstinline@!=@ \nonterm{relational-expression}
    18731736\end{syntax}
    18741737
    18751738\rewriterules
    18761739\begin{lstlisting}
    1877 a == b @\rewrite@ ?==?( a, b )@\use{?==?}@
    1878 a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@
     1740a == b §\rewrite§ ?==?( a, b )§\use{?==?}§
     1741a != b §\rewrite§ ?!=?( a, b )§\use{?"!=?}§
    18791742\end{lstlisting}
    18801743
     
    19291792        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    19301793\end{lstlisting}
    1931 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1794For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    19321795% Don't use predefined: keep this out of prelude.cf.
    19331796\begin{lstlisting}
     
    19371800
    19381801\begin{rationale}
    1939 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
     1802The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline@void@ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
    19401803In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    19411804\end{rationale}
     
    19581821\lhs{AND-expression}
    19591822\rhs \nonterm{equality-expression}
    1960 \rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression}
     1823\rhs \nonterm{AND-expression} \lstinline@&@ \nonterm{equality-expression}
    19611824\end{syntax}
    19621825
    19631826\rewriterules
    19641827\begin{lstlisting}
    1965 a & b @\rewrite@ ?&?( a, b )@\use{?&?}@
     1828a & b §\rewrite§ ?&?( a, b )§\use{?&?}§
    19661829\end{lstlisting}
    19671830
     
    19751838long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    19761839\end{lstlisting}
    1977 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1840For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    19781841% Don't use predefined: keep this out of prelude.cf.
    19791842\begin{lstlisting}
     
    19901853\lhs{exclusive-OR-expression}
    19911854\rhs \nonterm{AND-expression}
    1992 \rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression}
     1855\rhs \nonterm{exclusive-OR-expression} \lstinline@^@ \nonterm{AND-expression}
    19931856\end{syntax}
    19941857
    19951858\rewriterules
    19961859\begin{lstlisting}
    1997 a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@
     1860a ^ b §\rewrite§ ?^?( a, b )§\use{?^?}§
    19981861\end{lstlisting}
    19991862
     
    20071870long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    20081871\end{lstlisting}
    2009 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1872For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    20101873% Don't use predefined: keep this out of prelude.cf.
    20111874\begin{lstlisting}
     
    20221885\lhs{inclusive-OR-expression}
    20231886\rhs \nonterm{exclusive-OR-expression}
    2024 \rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression}
     1887\rhs \nonterm{inclusive-OR-expression} \lstinline@|@ \nonterm{exclusive-OR-expression}
    20251888\end{syntax}
    20261889
    20271890\rewriterules\use{?"|?}
    20281891\begin{lstlisting}
    2029 a | b @\rewrite@ ?|?( a, b )
     1892a | b §\rewrite§ ?|?( a, b )
    20301893\end{lstlisting}
    20311894
     
    20391902long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    20401903\end{lstlisting}
    2041 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1904For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    20421905% Don't use predefined: keep this out of prelude.cf.
    20431906\begin{lstlisting}
     
    20541917\lhs{logical-AND-expression}
    20551918\rhs \nonterm{inclusive-OR-expression}
    2056 \rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression}
     1919\rhs \nonterm{logical-AND-expression} \lstinline@&&@ \nonterm{inclusive-OR-expression}
    20571920\end{syntax}
    20581921
    2059 \semantics The operands of the expression ``\lstinline$a && b$'' are treated as
    2060 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be unambiguous.
    2061 The expression has only one interpretation, which is of type \lstinline$int$.
    2062 \begin{rationale}
    2063 When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has not been redefined for those types, the compiler can optimize away the function calls.
    2064 
    2065 A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
    2066 \lstinline$if$ statements.
    2067 For instance, the loop below iterates as long as \lstinline$rp$ points at a \lstinline$Rational$ value that is non-zero.
    2068 
    2069 \begin{lstlisting}
    2070 extern otype Rational;@\use{Rational}@
    2071 extern const Rational 0;@\use{0}@
     1922\semantics The operands of the expression ``\lstinline@a && b@'' are treated as
     1923``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b)!=0)@'', which shall both be unambiguous.
     1924The expression has only one interpretation, which is of type \lstinline@int@.
     1925\begin{rationale}
     1926When the operands of a logical expression are values of built-in types, and ``\lstinline@!=@'' has not been redefined for those types, the compiler can optimize away the function calls.
     1927
     1928A common C idiom omits comparisons to \lstinline@0@ in the controlling expressions of loops and
     1929\lstinline@if@ statements.
     1930For instance, the loop below iterates as long as \lstinline@rp@ points at a \lstinline@Rational@ value that is non-zero.
     1931
     1932\begin{lstlisting}
     1933extern otype Rational;§\use{Rational}§
     1934extern const Rational 0;§\use{0}§
    20721935extern int ?!=?( Rational, Rational );
    20731936Rational *rp;
    20741937while ( rp && *rp ) { ... }
    20751938\end{lstlisting}
    2076 The logical expression calls the \lstinline$Rational$ inequality operator, passing it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result.
    2077 In contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$ conversion to \lstinline$*rp$ in the equivalent situation.
    2078 The conversion to \lstinline$int$ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
     1939The logical expression calls the \lstinline@Rational@ inequality operator, passing it \lstinline@*rp@ and the \lstinline@Rational 0@, and getting a 1 or 0 as a result.
     1940In contrast, {\CC} would apply a programmer-defined \lstinline@Rational@-to-\lstinline@int@ conversion to \lstinline@*rp@ in the equivalent situation.
     1941The conversion to \lstinline@int@ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
    20791942\end{rationale}
    20801943
     
    20851948\lhs{logical-OR-expression}
    20861949\rhs \nonterm{logical-AND-expression}
    2087 \rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression}
     1950\rhs \nonterm{logical-OR-expression} \lstinline@||@ \nonterm{logical-AND-expression}
    20881951\end{syntax}
    20891952
    20901953\semantics
    20911954
    2092 The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous.
    2093 The expression has only one interpretation, which is of type \lstinline$int$.
     1955The operands of the expression ``\lstinline@a || b@'' are treated as ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b))!=0)@'', which shall both be unambiguous.
     1956The expression has only one interpretation, which is of type \lstinline@int@.
    20941957
    20951958
     
    20991962\lhs{conditional-expression}
    21001963\rhs \nonterm{logical-OR-expression}
    2101 \rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression}
    2102          \lstinline$:$ \nonterm{conditional-expression}
     1964\rhs \nonterm{logical-OR-expression} \lstinline@?@ \nonterm{expression}
     1965         \lstinline@:@ \nonterm{conditional-expression}
    21031966\end{syntax}
    21041967
    21051968\semantics
    2106 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and third operands both have an interpretation with \lstinline$void$ type, then the expression has an interpretation with type \lstinline$void$, equivalent to
     1969In the conditional expression\use{?:} ``\lstinline@a?b:c@'', if the second and third operands both have an interpretation with \lstinline@void@ type, then the expression has an interpretation with type \lstinline@void@, equivalent to
    21071970\begin{lstlisting}
    21081971( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    21091972\end{lstlisting}
    21101973
    2111 If the second and third operands both have interpretations with non-\lstinline$void$ types, the expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', with \lstinline$cond$ declared as
     1974If the second and third operands both have interpretations with non-\lstinline@void@ types, the expression is treated as if it were the call ``\lstinline@cond((a)!=0, b, c)@'', with \lstinline@cond@ declared as
    21121975\begin{lstlisting}
    21131976forall( otype T ) T cond( int, T, T );
     
    21612024rand() ? i : l;
    21622025\end{lstlisting}
    2163 The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe
    2164 \lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$.
     2026The best interpretation infers the expression's type to be \lstinline@long@ and applies the safe
     2027\lstinline@int@-to-\lstinline@long@ conversion to \lstinline@i@.
    21652028
    21662029\begin{lstlisting}
     
    21692032rand() ? cip : vip;
    21702033\end{lstlisting}
    2171 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
     2034The expression has type \lstinline@const volatile int *@, with safe conversions applied to the second and third operands to add \lstinline@volatile@ and \lstinline@const@ qualifiers, respectively.
    21722035
    21732036\begin{lstlisting}
    21742037rand() ? cip : 0;
    21752038\end{lstlisting}
    2176 The expression has type \lstinline$const int *$, with a specialization conversion applied to
    2177 \lstinline$0$.
     2039The expression has type \lstinline@const int *@, with a specialization conversion applied to
     2040\lstinline@0@.
    21782041
    21792042
     
    21862049         \nonterm{assignment-expression}
    21872050\lhs{assignment-operator} one of
    2188 \rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \ 
    2189          \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$
     2051\rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@-=@\ \ 
     2052         \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@|=@
    21902053\end{syntax}
    21912054
     
    21962059\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    21972060\begin{lstlisting}
    2198 a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b )
     2061a §$\leftarrow$§ b §\rewrite§ ?§$\leftarrow$§?( &( a ), b )
    21992062\end{lstlisting}
    22002063
    22012064\semantics
    22022065Each interpretation of the left operand of an assignment expression is considered separately.
    2203 For each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
     2066For each interpretation that is a bit-field or is declared with the \lstinline@register@ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
    22042067The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    22052068For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     
    24342297\end{lstlisting}
    24352298\begin{rationale}
    2436 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter, instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete type.
    2437 \end{rationale}
    2438 
    2439 For every complete structure or union type \lstinline$S$ there exist
     2299The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline@dtype@ parameter, instead of a \lstinline@type@ parameter, because the left operand may be a pointer to an incomplete type.
     2300\end{rationale}
     2301
     2302For every complete structure or union type \lstinline@S@ there exist
    24402303% Don't use predefined: keep this out of prelude.cf.
    24412304\begin{lstlisting}
     
    24432306\end{lstlisting}
    24442307
    2445 For every extended integer type \lstinline$X$ there exist
     2308For every extended integer type \lstinline@X@ there exist
    24462309% Don't use predefined: keep this out of prelude.cf.
    24472310\begin{lstlisting}
     
    24492312\end{lstlisting}
    24502313
    2451 For every complete enumerated type \lstinline$E$ there exist
     2314For every complete enumerated type \lstinline@E@ there exist
    24522315% Don't use predefined: keep this out of prelude.cf.
    24532316\begin{lstlisting}
     
    24552318\end{lstlisting}
    24562319\begin{rationale}
    2457 The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$.
     2320The right-hand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.
    24582321\end{rationale}
    24592322
     
    27162579\end{lstlisting}
    27172580
    2718 For every extended integer type \lstinline$X$ there exist
     2581For every extended integer type \lstinline@X@ there exist
    27192582% Don't use predefined: keep this out of prelude.cf.
    27202583\begin{lstlisting}
     
    27312594\end{lstlisting}
    27322595
    2733 For every complete enumerated type \lstinline$E$ there exist
     2596For every complete enumerated type \lstinline@E@ there exist
    27342597% Don't use predefined: keep this out of prelude.cf.
    27352598\begin{lstlisting}
     
    27522615\lhs{expression}
    27532616\rhs \nonterm{assignment-expression}
    2754 \rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression}
     2617\rhs \nonterm{expression} \lstinline@,@ \nonterm{assignment-expression}
    27552618\end{syntax}
    27562619
    27572620\semantics
    2758 In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
    2759 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}.
     2621In the comma expression ``\lstinline@a, b@'', the first operand is interpreted as
     2622``\lstinline@( void )(a)@'', which shall be unambiguous\index{ambiguous interpretation}.
    27602623The interpretations of the expression are the interpretations of the second operand.
    27612624
     
    27922655{ ... }
    27932656\end{lstlisting}
    2794 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the second.
     2657Without the rule, \lstinline@Complex@ would be a type in the first case, and a parameter name in the second.
    27952658\end{rationale}
    27962659
     
    28182681\examples
    28192682\begin{lstlisting}
    2820 struct point {@\impl{point}@
     2683struct point {§\impl{point}§
    28212684        int x, y;
    28222685};
    2823 struct color_point {@\impl{color_point}@
     2686struct color_point {§\impl{color_point}§
    28242687        enum { RED, BLUE, GREEN } color;
    28252688        struct point;
     
    28282691cp.x = 0;
    28292692cp.color = RED;
    2830 struct literal {@\impl{literal}@
     2693struct literal {§\impl{literal}§
    28312694        enum { NUMBER, STRING } tag;
    28322695        union {
     
    28492712\begin{syntax}
    28502713\lhs{forall-specifier}
    2851 \rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
     2714\rhs \lstinline@forall@ \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
    28522715\end{syntax}
    28532716
     
    28612724} mkPair( T, T ); // illegal
    28622725\end{lstlisting}
    2863 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the members' type be?
     2726If an instance of \lstinline@struct Pair@ was declared later in the current scope, what would the members' type be?
    28642727\end{rationale}
    28652728\end{comment}
     
    28682731The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    28692732
    2870 If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
    2871 \lstinline$D$ has the form
    2872 \begin{lstlisting}
    2873 D( @\normalsize\nonterm{parameter-type-list}@ )
    2874 \end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline$D$, and it is used in the type of a parameter in the following
     2733If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forall-specifier}s and
     2734\lstinline@D@ has the form
     2735\begin{lstlisting}
     2736D( §\normalsize\nonterm{parameter-type-list}§ )
     2737\end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline@D@, and it is used in the type of a parameter in the following
    28752738\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    28762739\Index{specification} in one of the \nonterm{forall-specifier}s.
     
    28832746If this restriction were lifted, it would be possible to write
    28842747\begin{lstlisting}
    2885 forall( otype T ) T * alloc( void );@\use{alloc}@ int *p = alloc();
    2886 \end{lstlisting}
    2887 Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
    2888 \lstinline$int *$.
    2889 In general, if a call to \lstinline$alloc()$ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline$T$ to be bound.
    2890 
    2891 With the current restriction, \lstinline$alloc()$ must be given an argument that determines
    2892 \lstinline$T$:
    2893 \begin{lstlisting}
    2894 forall( otype T ) T * alloc( T initial_value );@\use{alloc}@
     2748forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
     2749\end{lstlisting}
     2750Here \lstinline@alloc()@ would receive \lstinline@int@ as an inferred argument, and return an
     2751\lstinline@int *@.
     2752In general, if a call to \lstinline@alloc()@ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline@T@ to be bound.
     2753
     2754With the current restriction, \lstinline@alloc()@ must be given an argument that determines
     2755\lstinline@T@:
     2756\begin{lstlisting}
     2757forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
    28952758\end{lstlisting}
    28962759\end{rationale}
     
    29172780forall( otype T ) T fT( T );
    29182781\end{lstlisting}
    2919 \lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
    2920 \lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$.
     2782\lstinline@fi()@ takes an \lstinline@int@ and returns an \lstinline@int@. \lstinline@fT()@ takes a
     2783\lstinline@T@ and returns a \lstinline@T@, for any type \lstinline@T@.
    29212784\begin{lstlisting}
    29222785int (*pfi )( int ) = fi;
    29232786forall( otype T ) T (*pfT )( T ) = fT;
    29242787\end{lstlisting}
    2925 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not polymorphic, but the function it points at is.
     2788\lstinline@pfi@ and \lstinline@pfT@ are pointers to functions. \lstinline@pfT@ is not polymorphic, but the function it points at is.
    29262789\begin{lstlisting}
    29272790int (*fvpfi( void ))( int ) {
     
    29322795}
    29332796\end{lstlisting}
    2934 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points at is polymorphic.
     2797\lstinline@fvpfi()@ and \lstinline@fvpfT()@ are functions taking no arguments and returning pointers to functions. \lstinline@fvpfT()@ is monomorphic, but the function that its return value points at is polymorphic.
    29352798\begin{lstlisting}
    29362799forall( otype T ) int ( *fTpfi( T ) )( int );
     
    29382801forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    29392802\end{lstlisting}
    2940 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
    2941 It could return \lstinline$pfi$. \lstinline$fTpfT()$ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    2942 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$.
    2943 For instance, in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
    2944 ``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
    2945 \lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
    2946 \lstinline$char *$.
     2803\lstinline@fTpfi()@ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2804It could return \lstinline@pfi@. \lstinline@fTpfT()@ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2805\lstinline@T@, where \lstinline@T@ is an inferred parameter of \lstinline@fTpfT()@.
     2806For instance, in the expression ``\lstinline@fTpfT(17)@'', \lstinline@T@ is inferred to be \lstinline@int@, and the returned value would have type \lstinline@int ( * )( int )@. ``\lstinline@fTpfT(17)(13)@'' and
     2807``\lstinline@fTpfT("yes")("no")@'' are legal, but ``\lstinline@fTpfT(17)("no")@'' is illegal.
     2808\lstinline@fTpfU()@ is polymorphic ( in type \lstinline@T@), and returns a pointer to a function that is polymorphic ( in type \lstinline@U@). ``\lstinline@f5(17)("no")@'' is a legal expression of type
     2809\lstinline@char *@.
    29472810\begin{lstlisting}
    29482811forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    29492812forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    29502813\end{lstlisting}
    2951 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types.
     2814The functions \lstinline@f()@ and \lstinline@g()@ have compatible types.
    29522815Let \(f\) and \(g\) be their types;
    2953 then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
    2954 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$.
     2816then \(f_1\) = \lstinline@T@, \(f_2\) = \lstinline@U@, \(f_3\) = \lstinline@V@, \(g_1\)
     2817= \lstinline@V@, \(g_2\) = \lstinline@U@, and \(g_3\) = \lstinline@W@.
    29552818Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    29562819\begin{lstlisting}
     
    29582821\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    29592822\begin{rationale}
    2960 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
     2823The word ``\lstinline@type@'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
    29612824
    29622825Even without parameterized types, I might try to allow
     
    29842847\subsection{Type qualifiers}
    29852848
    2986 \CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}.
     2849\CFA defines a new type qualifier \lstinline@lvalue@\impl{lvalue}\index{lvalue}.
    29872850\begin{syntax}
    29882851\oldlhs{type-qualifier}
    2989 \rhs \lstinline$lvalue$
     2852\rhs \lstinline@lvalue@
    29902853\end{syntax}
    29912854
    29922855\constraints
    2993 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
     2856\Indexc{restrict} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
    29942857
    29952858\semantics
    2996 An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not establish any special semantics in that case.
     2859An object's type may be a restrict-qualified type parameter.
     2860\lstinline@restrict@ does not establish any special semantics in that case.
    29972861
    29982862\begin{rationale}
     
    30002864\end{rationale}
    30012865
    3002 \lstinline$lvalue$ may be used to qualify the return type of a function type.
    3003 Let \lstinline$T$ be an unqualified version of a type;
     2866\lstinline@lvalue@ may be used to qualify the return type of a function type.
     2867Let \lstinline@T@ be an unqualified version of a type;
    30042868then the result of calling a function with return type
    3005 \lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
    3006 \lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
    3007 \begin{rationale}
    3008 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline$lvalue$ qualifier is also used.
     2869\lstinline@lvalue T@ is a \Index{modifiable lvalue} of type \lstinline@T@.
     2870\lstinline@const@\use{const} and \lstinline@volatile@\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     2871\begin{rationale}
     2872The \lstinline@const@ and \lstinline@volatile@ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline@lvalue@ qualifier is also used.
    30092873\end{rationale}
    30102874
     
    30132877
    30142878\begin{rationale}
    3015 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to object of type \lstinline$T$) type.
     2879\lstinline@lvalue@ provides some of the functionality of {\CC}'s ``\lstinline@T&@'' ( reference to object of type \lstinline@T@) type.
    30162880Reference types have four uses in {\CC}.
    30172881\begin{itemize}
    30182882\item
    3019 They are necessary for user-defined operators that return lvalues, such as ``subscript'' and
    3020 ``dereference''.
    3021 
    3022 \item
    3023 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline$with$ statement.
     2883They are necessary for user-defined operators that return lvalues, such as ``subscript'' and ``dereference''.
     2884
     2885\item
     2886A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline@with@ statement.
    30242887The following {\CC} code gives an example.
    30252888\begin{lstlisting}
     
    30342897A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    30352898This is most useful for user-defined assignment operators.
    3036 In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and the two expressions
     2899In {\CC}, plain assignment is done by a function called ``\lstinline@operator=@'', and the two expressions
    30372900\begin{lstlisting}
    30382901a = b;
    30392902operator=( a, b );
    30402903\end{lstlisting} are equivalent.
    3041 If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''.
     2904If \lstinline@a@ and \lstinline@b@ are of type \lstinline@T@, then the first parameter of \lstinline@operator=@ must have type ``\lstinline@T&@''.
    30422905It cannot have type
    3043 \lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
    3044 ``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
    3045 
    3046 In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
    3047 ``\lstinline$operator=(&( a), b )$''.
    3048 Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline$&$''.
     2906\lstinline@T@, because then assignment couldn't alter the variable, and it can't have type
     2907``\lstinline@T *@'', because the assignment would have to be written ``\lstinline@&a = b;@''.
     2908
     2909In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline@a = b;@'' is equivalent to
     2910``\lstinline@operator=(&( a), b )@''.
     2911Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline@&@''.
    30492912
    30502913\item
    30512914References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    3052 {\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of \lstinline$a_thing$ is
    3053 \lstinline$Thing$, the type of \lstinline$fiddle$ could be either of
     2915{\CC} function call ``\lstinline@fiddle( a_thing )@'', where the type of \lstinline@a_thing@ is
     2916\lstinline@Thing@, the type of \lstinline@fiddle@ could be either of
    30542917\begin{lstlisting}
    30552918void fiddle( Thing );
    30562919void fiddle( const Thing & );
    30572920\end{lstlisting}
    3058 If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by aliases.
    3059 The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too large or their constructors or destructors are too expensive.
     2921If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline@fiddle@ the parameter is subject to the usual problems caused by aliases.
     2922The reference form might be chosen for efficiency's sake if \lstinline@Thing@s are too large or their constructors or destructors are too expensive.
    30602923An implementation may switch between them without causing trouble for well-behaved clients.
    30612924This leaves the implementor to define ``too large'' and ``too expensive''.
     
    30652928void fiddle( const volatile Thing );
    30662929\end{lstlisting} with call-by-reference.
    3067 Since it knows all about the size of \lstinline$Thing$s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
     2930Since it knows all about the size of \lstinline@Thing@s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
    30682931\end{itemize}
    30692932
     
    30852948\begin{syntax}
    30862949\lhs{spec-definition}
    3087 \rhs \lstinline$spec$ \nonterm{identifier}
    3088         \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
    3089         \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$
     2950\rhs \lstinline@spec@ \nonterm{identifier}
     2951        \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
     2952        \lstinline@{@ \nonterm{spec-declaration-list}\opt \lstinline@}@
    30902953\lhs{spec-declaration-list}
    3091 \rhs \nonterm{spec-declaration} \lstinline$;$
    3092 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$
     2954\rhs \nonterm{spec-declaration} \lstinline@;@
     2955\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline@;@
    30932956\lhs{spec-declaration}
    30942957\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    30952958\lhs{declarator-list}
    30962959\rhs \nonterm{declarator}
    3097 \rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator}
     2960\rhs \nonterm{declarator-list} \lstinline@,@ \nonterm{declarator}
    30982961\end{syntax}
    30992962\begin{rationale}
     
    31172980\rhs \nonterm{assertion-list} \nonterm{assertion}
    31182981\lhs{assertion}
    3119 \rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$
    3120 \rhs \lstinline$|$ \nonterm{spec-declaration}
     2982\rhs \lstinline@|@ \nonterm{identifier} \lstinline@(@ \nonterm{type-name-list} \lstinline@)@
     2983\rhs \lstinline@|@ \nonterm{spec-declaration}
    31212984\lhs{type-name-list}
    31222985\rhs \nonterm{type-name}
    3123 \rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name}
     2986\rhs \nonterm{type-name-list} \lstinline@,@ \nonterm{type-name}
    31242987\end{syntax}
    31252988
     
    31282991The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    31292992If the
    3130 \nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type name of an \Index{object type};
    3131 if it uses \lstinline$dtype$, the argument shall be the type name of an object type or an \Index{incomplete type};
    3132 and if it uses \lstinline$ftype$, the argument shall be the type name of a \Index{function type}.
     2993\nonterm{type-parameter} uses type-class \lstinline@type@\use{type}, the argument shall be the type name of an \Index{object type};
     2994if it uses \lstinline@dtype@, the argument shall be the type name of an object type or an \Index{incomplete type};
     2995and if it uses \lstinline@ftype@, the argument shall be the type name of a \Index{function type}.
    31332996
    31342997\semantics
     
    31433006\examples
    31443007\begin{lstlisting}
    3145 forall( otype T | T ?*?( T, T ))@\use{?*?}@
    3146 T square( T val ) {@\impl{square}@
     3008forall( otype T | T ?*?( T, T ))§\use{?*?}§
     3009T square( T val ) {§\impl{square}§
    31473010        return val + val;
    31483011}
    3149 trait summable( otype T ) {@\impl{summable}@
    3150         T ?+=?( T *, T );@\use{?+=?}@
    3151         const T 0;@\use{0}@
     3012trait summable( otype T ) {§\impl{summable}§
     3013        T ?+=?( T *, T );§\use{?+=?}§
     3014        const T 0;§\use{0}§
    31523015};
    3153 trait list_of( otype List, otype Element ) {@\impl{list_of}@
     3016trait list_of( otype List, otype Element ) {§\impl{list_of}§
    31543017        Element car( List );
    31553018        List cdr( List );
     
    31603023trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    31613024\end{lstlisting}
    3162 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added up.
    3163 The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion parameters
     3025\lstinline@sum_list@ contains seven declarations, which describe a list whose elements can be added up.
     3026The assertion ``\lstinline@|sum_list( i_list, int )@''\use{sum_list} produces the assertion parameters
    31643027\begin{lstlisting}
    31653028int ?+=?( int *, int );
     
    31783041\lhs{type-parameter-list}
    31793042\rhs \nonterm{type-parameter}
    3180 \rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter}
     3043\rhs \nonterm{type-parameter-list} \lstinline@,@ \nonterm{type-parameter}
    31813044\lhs{type-parameter}
    31823045\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    31833046\lhs{type-class}
    3184 \rhs \lstinline$type$
    3185 \rhs \lstinline$dtype$
    3186 \rhs \lstinline$ftype$
     3047\rhs \lstinline@type@
     3048\rhs \lstinline@dtype@
     3049\rhs \lstinline@ftype@
    31873050\lhs{type-declaration}
    3188 \rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;|
     3051\rhs \nonterm{storage-class-specifier}\opt \lstinline@type@ \nonterm{type-declarator-list} \verb|;|
    31893052\lhs{type-declarator-list}
    31903053\rhs \nonterm{type-declarator}
    3191 \rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator}
     3054\rhs \nonterm{type-declarator-list} \lstinline@,@ \nonterm{type-declarator}
    31923055\lhs{type-declarator}
    3193 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name}
     3056\rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline@=@ \nonterm{type-name}
    31943057\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    31953058\end{syntax}
     
    32023065
    32033066An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
    3204 Identifiers declared with type-class \lstinline$type$\use{type} are \Index{object type}s;
     3067Identifiers declared with type-class \lstinline@type@\use{type} are \Index{object type}s;
    32053068those declared with type-class
    3206 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s;
     3069\lstinline@dtype@\use{dtype} are \Index{incomplete type}s;
    32073070and those declared with type-class
    3208 \lstinline$ftype$\use{ftype} are \Index{function type}s.
     3071\lstinline@ftype@\use{ftype} are \Index{function type}s.
    32093072The identifier has \Index{block scope} that terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains the \nonterm{type-parameter}.
    32103073
     
    32143077Within the scope of the declaration, \Index{implicit conversion}s can be performed between the defined type and the implementation type, and between pointers to the defined type and pointers to the implementation type.
    32153078
    3216 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}.
     3079A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline@static@\use{static} defines an \Index{incomplete type}.
    32173080If a
    32183081\Index{translation unit} or \Index{block} contains one or more such declarations for an identifier, it must contain exactly one definition of the identifier ( but not in an enclosed block, which would define a new type known only within that block).
     
    32343097
    32353098A type declaration without an initializer and with \Index{storage-class specifier}
    3236 \lstinline$extern$\use{extern} is an \define{opaque type declaration}.
     3099\lstinline@extern@\use{extern} is an \define{opaque type declaration}.
    32373100Opaque types are
    32383101\Index{object type}s.
     
    32493112\end{rationale}
    32503113
    3251 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline$dtype$.
    3252 An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$.
     3114An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline@dtype@.
     3115An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline@type@ and \lstinline@dtype@.
    32533116A
    3254 \Index{function type} is a value of type-class \lstinline$ftype$.
     3117\Index{function type} is a value of type-class \lstinline@ftype@.
    32553118\begin{rationale}
    32563119Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     
    32623125Type qualifiers are a weak point of C's type system.
    32633126Consider the standard library function
    3264 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
    3265 \begin{lstlisting}
    3266 char *strchr( const char *s, int c ) {@\impl{strchr}@
     3127\lstinline@strchr()@ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
     3128\begin{lstlisting}
     3129char *strchr( const char *s, int c ) {§\impl{strchr}§
    32673130        char real_c = c; // done because c was declared as int.
    32683131        for ( ; *s != real_c; s++ )
     
    32713134}
    32723135\end{lstlisting}
    3273 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be used to search a constant string, but the return type must be \lstinline$char *$, because the result might be used to modify a non-constant string.
     3136The parameter \lstinline@s@ must be \lstinline@const char *@, because \lstinline@strchr()@ might be used to search a constant string, but the return type must be \lstinline@char *@, because the result might be used to modify a non-constant string.
    32743137Hence the body must perform a cast, and ( even worse)
    3275 \lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings.
    3276 What is needed is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has exactly the same qualifiers.
     3138\lstinline@strchr()@ provides a type-safe way to attempt to modify constant strings.
     3139What is needed is some way to say that \lstinline@s@'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    32773140Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
    3278 Instead, overloading can be used to define \lstinline$strchr()$ for each combination of qualifiers.
     3141Instead, overloading can be used to define \lstinline@strchr()@ for each combination of qualifiers.
    32793142\end{rationale}
    32803143
     
    33013164\end{lstlisting}
    33023165Without this restriction, \CFA might require ``module initialization'' code ( since
    3303 \lstinline$Rational$ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
     3166\lstinline@Rational@ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline@Huge@ and the translation that declares \lstinline@Rational@.
    33043167
    33053168A benefit of the restriction is that it prevents the declaration in separate translation units of types that contain each other, which would be hard to prevent otherwise.
     
    33183181\nonterm{struct-declaration}, type declarations can not be structure members.
    33193182The form of
    3320 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
     3183\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.
    33213184Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    33223185It also side-steps the problem of type-valued expressions producing different values in different declarations.
     
    33333196#include <stdlib.h>
    33343197T * new( otype T ) { return ( T * )malloc( sizeof( T) ); };
    3335 @\ldots@ int * ip = new( int );
    3336 \end{lstlisting}
    3337 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the meaning of \lstinline$T$ in the scope that contains \lstinline$new$;
     3198§\ldots§ int * ip = new( int );
     3199\end{lstlisting}
     3200This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline@T@'' in the function body refers to the parameter, but the ``\lstinline@T@'' in the return type refers to the meaning of \lstinline@T@ in the scope that contains \lstinline@new@;
    33383201it could be undefined, or a type name, or a function or variable name.
    33393202Nothing good can result from such a situation.
     
    33523215f2( v2 );
    33533216\end{lstlisting}
    3354 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies \lstinline$v2[0]$.
     3217\lstinline@V1@ is passed by value, so \lstinline@f1()@'s assignment to \lstinline@a[0]@ does not modify v1.  \lstinline@V2@ is converted to a pointer, so \lstinline@f2()@ modifies \lstinline@v2[0]@.
    33553218
    33563219A translation unit containing the declarations
    33573220\begin{lstlisting}
    3358 extern type Complex;@\use{Complex}@ // opaque type declaration
    3359 extern float abs( Complex );@\use{abs}@
    3360 \end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline$abs$.
    3361 Some other translation unit must implement \lstinline$Complex$ and \lstinline$abs$.
     3221extern type Complex;§\use{Complex}§ // opaque type declaration
     3222extern float abs( Complex );§\use{abs}§
     3223\end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline@abs@.
     3224Some other translation unit must implement \lstinline@Complex@ and \lstinline@abs@.
    33623225That unit might contain the declarations
    33633226\begin{lstlisting}
    3364 otype Complex = struct { float re, im; };@\impl{Complex}@
    3365 Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
    3366 float abs( Complex c ) {@\impl{abs( Complex )}@
     3227otype Complex = struct { float re, im; };§\impl{Complex}§
     3228Complex cplx_i = { 0.0, 1.0 };§\impl{cplx_i}§
     3229float abs( Complex c ) {§\impl{abs( Complex )}§
    33673230        return sqrt( c.re * c.re + c.im * c.im );
    33683231}
    33693232\end{lstlisting}
    3370 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can be retrieved.
    3371 
    3372 \begin{lstlisting}
    3373 otype Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
    3374 Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
     3233Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@ so that its components can be retrieved.
     3234
     3235\begin{lstlisting}
     3236otype Time_of_day = int;§\impl{Time_of_day}§ // seconds since midnight.
     3237Time_of_day ?+?( Time_of_day t1, int seconds ) {§\impl{?+?}§
    33753238        return (( int)t1 + seconds ) % 86400;
    33763239}
    33773240\end{lstlisting}
    3378 \lstinline$t1$ must be cast to its implementation type to prevent infinite recursion.
     3241\lstinline@t1@ must be cast to its implementation type to prevent infinite recursion.
    33793242
    33803243\begin{rationale}
    33813244Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
    3382 In the \lstinline$Time_of_day$ example, the difference is important.
     3245In the \lstinline@Time_of_day@ example, the difference is important.
    33833246Different languages have treated the distinction between the abstraction and the implementation in different ways.
    33843247\begin{itemize}
    33853248\item
    3386 Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies.
    3387 Two primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
    3388 \item
    3389 The Simula class \cite{Simula87} is essentially a record type.
     3249Inside a Clu cluster \cite{CLU}, the declaration of an instance states which view applies.
     3250Two primitives called \lstinline@up@ and \lstinline@down@ can be used to convert between the views.
     3251\item
     3252The Simula class \cite{SIMULA87} is essentially a record type.
    33903253Since the only operations on a record are member selection and assignment, which can not be overloaded, there is never any ambiguity as to whether the abstraction or the implementation view is being used.
    33913254In {\CC}
    3392 \cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be overloaded.
     3255\cite{C++}, operations on class instances include assignment and ``\lstinline@&@'', which can be overloaded.
    33933256A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    33943257\item
    3395 An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly declares derived subprograms that correspond to the existing subprograms that use the old type as a parameter type or result type.
     3258An Ada derived type definition \cite{Ada} creates a new type from an old type, and also implicitly declares derived subprograms that correspond to the existing subprograms that use the old type as a parameter type or result type.
    33963259The derived subprograms are clones of the existing subprograms with the old type replaced by the derived type.
    33973260Literals and aggregates of the old type are also cloned.
     
    34033266In this case, explicit conversions between the derived type and the old type can be used.
    34043267\end{itemize}
    3405 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
     3268\CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline@up@ and \lstinline@down@.
    34063269\end{rationale}
    34073270
     
    34093272\subsubsection{Default functions and objects}
    34103273
    3411 A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
    3412 \lstinline$type$ implicitly declares a \define{default assignment} function
    3413 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3274A declaration\index{type declaration} of a type identifier \lstinline@T@ with type-class
     3275\lstinline@type@ implicitly declares a \define{default assignment} function
     3276\lstinline@T ?=?( T *, T )@\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
    34143277\begin{rationale}
    34153278Assignment is central to C's imperative programming style, and every existing C object type has assignment defined for it ( except for array types, which are treated as pointer types for purposes of assignment).
    34163279Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
    34173280If a type parameter should not have an assignment operation,
    3418 \lstinline$dtype$ should be used.
     3281\lstinline@dtype@ should be used.
    34193282If a type should not have assignment defined, the user can define an assignment function that causes a run-time error, or provide an external declaration but no definition and thus cause a link-time error.
    34203283\end{rationale}
    34213284
    3422 A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment function.
    3423 A definition\index{type definition} of a type identifier \lstinline$T$ with implementation type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
     3285A definition\index{type definition} of a type identifier \lstinline@T@ with \Index{implementation type} \lstinline@I@ and type-class \lstinline@type@ implicitly defines a default assignment function.
     3286A definition\index{type definition} of a type identifier \lstinline@T@ with implementation type \lstinline@I@ and an assertion list implicitly defines \define{default function}s and
    34243287\define{default object}s as declared by the assertion declarations.
    3425 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3288The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
    34263289Their values are determined as follows:
    34273290\begin{itemize}
    34283291\item
    3429 If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default object, then the default object is initialized with that object.
    3430 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default object.
     3292If at the definition of \lstinline@T@ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default object, then the default object is initialized with that object.
     3293Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default object.
    34313294
    34323295\item
    3433 If at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline$I$ replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
    3434 
    3435 Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline$T$ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
    3436 
    3437 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default function.
     3296If at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
     3297
     3298Otherwise, if \lstinline@I@ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
     3299
     3300Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default function.
    34383301\end{itemize}
    34393302\begin{rationale}
     
    34413304\end{rationale}
    34423305
    3443 A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline$T$ replaces the default function or object.
     3306A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline@T@ replaces the default function or object.
    34443307
    34453308\examples
     
    34513314Pair b = { 1, 1 };
    34523315\end{lstlisting}
    3453 The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
    3454 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$.
     3316The definition of \lstinline@Pair@ implicitly defines two objects \lstinline@a@ and \lstinline@b@.
     3317\lstinline@Pair a@ inherits its value from the \lstinline@struct impl a@.
    34553318The definition of
    3456 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value from.
     3319\lstinline@Pair b@ is compulsory because there is no \lstinline@struct impl b@ to construct a value from.
    34573320\begin{lstlisting}
    34583321trait ss( otype T ) {
     
    34603323        void munge( T * );
    34613324}
    3462 otype Whatsit | ss( Whatsit );@\use{Whatsit}@
    3463 otype Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
     3325otype Whatsit | ss( Whatsit );§\use{Whatsit}§
     3326otype Doodad | ss( Doodad ) = struct doodad {§\use{Doodad}§
    34643327        Whatsit; // anonymous member
    34653328        int extra;
     
    34673330Doodad clone( Doodad ) { ... }
    34683331\end{lstlisting}
    3469 The definition of \lstinline$Doodad$ implicitly defines three functions:
     3332The definition of \lstinline@Doodad@ implicitly defines three functions:
    34703333\begin{lstlisting}
    34713334Doodad ?=?( Doodad *, Doodad );
     
    34733336void munge( Doodad * );
    34743337\end{lstlisting}
    3475 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
    3476 \lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
    3477 \lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$ does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
    3478 \lstinline$Doodad$'s \lstinline$clone()$'s type.
     3338The assignment function inherits \lstinline@struct doodad@'s assignment function because the types match when \lstinline@struct doodad@ is replaced by \lstinline@Doodad@ throughout.
     3339\lstinline@munge()@ inherits \lstinline@Whatsit@'s \lstinline@munge()@ because the types match when
     3340\lstinline@Whatsit@ is replaced by \lstinline@Doodad@ in the parameter list. \lstinline@clone()@ does \emph{not} inherit \lstinline@Whatsit@'s \lstinline@clone()@: replacement in the parameter list yields ``\lstinline@Whatsit clone( Doodad )@'', which is not compatible with
     3341\lstinline@Doodad@'s \lstinline@clone()@'s type.
    34793342Hence the definition of
    3480 ``\lstinline$Doodad clone( Doodad )$'' is necessary.
     3343``\lstinline@Doodad clone( Doodad )@'' is necessary.
    34813344
    34823345Default functions and objects are subject to the normal scope rules.
    34833346\begin{lstlisting}
    3484 otype T = @\ldots@;
    3485 T a_T = @\ldots@;               // Default assignment used.
     3347otype T = §\ldots§;
     3348T a_T = §\ldots§;               // Default assignment used.
    34863349T ?=?( T *, T );
    3487 T a_T = @\ldots@;               // Programmer-defined assignment called.
     3350T a_T = §\ldots§;               // Programmer-defined assignment called.
    34883351\end{lstlisting}
    34893352\begin{rationale}
     
    35183381\begin{syntax}
    35193382\oldlhs{labeled-statement}
    3520 \rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement}
     3383\rhs \lstinline@case@ \nonterm{case-value-list} : \nonterm{statement}
    35213384\lhs{case-value-list}
    35223385\rhs \nonterm{case-value}
    3523 \rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value}
     3386\rhs \nonterm{case-value-list} \lstinline@,@ \nonterm{case-value}
    35243387\lhs{case-value}
    35253388\rhs \nonterm{constant-expression}
    35263389\rhs \nonterm{subrange}
    35273390\lhs{subrange}
    3528 \rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression}
     3391\rhs \nonterm{constant-expression} \lstinline@~@ \nonterm{constant-expression}
    35293392\end{syntax}
    35303393
     
    35393402case 1~4, 9~14, 27~32:
    35403403\end{lstlisting}
    3541 The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device.
     3404The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@ statements, precluding Duff's device.
    35423405
    35433406
    35443407\subsection{Expression and null statements}
    35453408
    3546 The expression in an expression statement is treated as being cast to \lstinline$void$.
     3409The expression in an expression statement is treated as being cast to \lstinline@void@.
    35473410
    35483411
     
    35513414\begin{syntax}
    35523415\oldlhs{selection-statement}
    3553 \rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement}
     3416\rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@ \nonterm{statement}
    35543417\end{syntax}
    35553418
    3556 The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement:
     3419The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@ statement:
    35573420\begin{lstlisting}
    35583421switch ( E ) ...
     
    35603423\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    35613424An \Index{integer promotion} is performed on the expression if necessary.
    3562 The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
     3425The constant expressions in \lstinline@case@ statements with the switch are converted to the promoted type.
    35633426
    35643427
    35653428\setcounter{subsubsection}{3}
    3566 \subsubsection{The \lstinline$choose$ statement}
    3567 
    3568 The \lstinline$choose$ statement is the same as the \lstinline$switch$ statement except control transfers to the end of the \lstinline$choose$ statement at a \lstinline$case$ or \lstinline$default$ labeled statement.
    3569 The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement.
     3429\subsubsection[The choose statement]{The \lstinline@choose@ statement}
     3430
     3431The \lstinline@choose@ statement is the same as the \lstinline@switch@ statement except control transfers to the end of the \lstinline@choose@ statement at a \lstinline@case@ or \lstinline@default@ labeled statement.
     3432The \lstinline@fallthru@ statement is used to fall through to the next \lstinline@case@ or \lstinline@default@ labeled statement.
    35703433The following have identical meaning:
    35713434\begin{flushleft}
     
    35923455\end{tabular}
    35933456\end{flushleft}
    3594 The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement.
     3457The \lstinline@choose@ statement addresses the problem of accidental fall-through associated with the \lstinline@switch@ statement.
    35953458
    35963459
    35973460\subsection{Iteration statements}
    35983461
    3599 The controlling expression \lstinline$E$ in the loops
     3462The controlling expression \lstinline@E@ in the loops
    36003463\begin{lstlisting}
    36013464if ( E ) ...
    36023465while ( E ) ...
    36033466do ... while ( E );
    3604 \end{lstlisting} is treated as ``\lstinline$( int )((E)!=0)$''.
     3467\end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''.
    36053468
    36063469The statement
    36073470\begin{lstlisting}
    3608 for ( a; b; c ) @\ldots@
     3471for ( a; b; c ) §\ldots§
    36093472\end{lstlisting} is treated as
    36103473\begin{lstlisting}
     
    36173480\begin{syntax}
    36183481\oldlhs{jump-statement}
    3619 \rhs \lstinline$continue$ \nonterm{identifier}\opt
    3620 \rhs \lstinline$break$ \nonterm{identifier}\opt
     3482\rhs \lstinline@continue@ \nonterm{identifier}\opt
     3483\rhs \lstinline@break@ \nonterm{identifier}\opt
    36213484\rhs \ldots
    3622 \rhs \lstinline$throw$ \nonterm{assignment-expression}\opt
    3623 \rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    3624 \lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression}
     3485\rhs \lstinline@throw@ \nonterm{assignment-expression}\opt
     3486\rhs \lstinline@throwResume@ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     3487\lhs{at-expression} \lstinline@_At@ \nonterm{assignment-expression}
    36253488\end{syntax}
    36263489
    3627 Labeled \lstinline$continue$ and \lstinline$break$ allow useful but restricted control-flow that reduces the need for the \lstinline$goto$ statement for exiting multiple nested control-structures.
     3490Labeled \lstinline@continue@ and \lstinline@break@ allow useful but restricted control-flow that reduces the need for the \lstinline@goto@ statement for exiting multiple nested control-structures.
    36283491\begin{lstlisting}
    36293492L1: {                                                   // compound
     
    36523515
    36533516\setcounter{subsubsection}{1}
    3654 \subsubsection{The \lstinline$continue$ statement}
    3655 
    3656 The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement.
    3657 
    3658 
    3659 \subsubsection{The \lstinline$break$ statement}
    3660 
    3661 The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement.
    3662 
    3663 
    3664 \subsubsection{The \lstinline$return$ statement}
    3665 
    3666 An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function.
    3667 
    3668 
    3669 \subsubsection{The \lstinline$throw$ statement}
     3517\subsubsection[The continue statement]{The \lstinline@continue@ statement}
     3518
     3519The identifier in a \lstinline@continue@ statement shall name a label located on an enclosing iteration statement.
     3520
     3521
     3522\subsubsection[The break statement]{The \lstinline@break@ statement}
     3523
     3524The identifier in a \lstinline@break@ statement shall name a label located on an enclosing compound, selection or iteration statement.
     3525
     3526
     3527\subsubsection[The return statement]{The \lstinline@return@ statement}
     3528
     3529An expression in a \lstinline@return@ statement is treated as being cast to the result type of the function.
     3530
     3531
     3532\subsubsection[The throw statement]{The \lstinline@throw@ statement}
    36703533
    36713534When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution.
    36723535
    36733536
    3674 \subsubsection{The \lstinline$throwResume$ statement}
     3537\subsubsection[The throwResume statement]{The \lstinline@throwResume@ statement}
    36753538
    36763539
     
    36793542\begin{syntax}
    36803543\lhs{exception-statement}
    3681 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list}
    3682 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause}
    3683 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
     3544\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list}
     3545\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{finally-clause}
     3546\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    36843547\lhs{handler-list}
    36853548\rhs \nonterm{handler-clause}
    3686 \rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3687 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3688 \rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3689 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
     3549\rhs \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3550\rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3551\rhs \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3552\rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    36903553\lhs{handler-clause}
    3691 \rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3692 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3693 \rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3694 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
     3554\rhs \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3555\rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3556\rhs \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3557\rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    36953558\lhs{finally-clause}
    3696 \rhs \lstinline$finally$ \nonterm{compound-statement}
     3559\rhs \lstinline@finally@ \nonterm{compound-statement}
    36973560\lhs{exception-declaration}
    36983561\rhs \nonterm{type-specifier}
     
    37023565\rhs \nonterm{new-abstract-declarator-tuple}
    37033566\lhs{asynchronous-statement}
    3704 \rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement}
    3705 \rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement}
     3567\rhs \lstinline@enable@ \nonterm{identifier-list} \nonterm{compound-statement}
     3568\rhs \lstinline@disable@ \nonterm{identifier-list} \nonterm{compound-statement}
    37063569\end{syntax}
    37073570
     
    37093572
    37103573
    3711 \subsubsection{The \lstinline$try$ statement}
    3712 
    3713 The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block};
     3574\subsubsection[The try statement]{The \lstinline@try@ statement}
     3575
     3576The \lstinline@try@ statement is a block with associated handlers, called a \Index{guarded block};
    37143577all other blocks are \Index{unguarded block}s.
    3715 A \lstinline$goto$, \lstinline$break$, \lstinline$return$, or \lstinline$continue$ statement can be used to transfer control out of a try block or handler, but not into one.
    3716 
    3717 
    3718 \subsubsection{The \lstinline$enable$/\lstinline$disable$ statements}
    3719 
    3720 The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s.
     3578A \lstinline@goto@, \lstinline@break@, \lstinline@return@, or \lstinline@continue@ statement can be used to transfer control out of a try block or handler, but not into one.
     3579
     3580
     3581\subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
     3582
     3583The \lstinline@enable@/\lstinline@disable@ statements toggle delivery of \Index{asynchronous exception}s.
    37213584
    37223585
     
    37283591\subsection{Predefined macro names}
    37293592
    3730 The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
    3731 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard.
    3732 It shall not define the macro name \lstinline$__STDC__$.
    3733 
    3734 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the decimal constant 1.
     3593The implementation shall define the macro names \lstinline@__LINE__@, \lstinline@__FILE__@,
     3594\lstinline@__DATE__@, and \lstinline@__TIME__@, as in the {\c11} standard.
     3595It shall not define the macro name \lstinline@__STDC__@.
     3596
     3597In addition, the implementation shall define the macro name \lstinline@__CFORALL__@ to be the decimal constant 1.
    37353598
    37363599
     
    37493612The pointer, integral, and floating-point types are all \define{scalar types}.
    37503613All of these types can be logically negated and compared.
    3751 The assertion ``\lstinline$scalar( Complex )$'' should be read as ``type \lstinline$Complex$ is scalar''.
    3752 \begin{lstlisting}
    3753 trait scalar( otype T ) {@\impl{scalar}@
     3614The assertion ``\lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@ is scalar''.
     3615\begin{lstlisting}
     3616trait scalar( otype T ) {§\impl{scalar}§
    37543617        int !?( T );
    37553618        int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
     
    37613624This is equivalent to inheritance of specifications.
    37623625\begin{lstlisting}
    3763 trait arithmetic( otype T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
     3626trait arithmetic( otype T | scalar( T ) ) {§\impl{arithmetic}§§\use{scalar}§
    37643627        T +?( T ), -?( T );
    37653628        T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
     
    37673630\end{lstlisting}
    37683631
    3769 The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the
     3632The various flavors of \lstinline@char@ and \lstinline@int@ and the enumerated types make up the
    37703633\define{integral types}.
    37713634\begin{lstlisting}
    3772 trait integral( otype T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
     3635trait integral( otype T | arithmetic( T ) ) {§\impl{integral}§§\use{arithmetic}§
    37733636        T ~?( T );
    37743637        T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
     
    37843647The only operation that can be applied to all modifiable lvalues is simple assignment.
    37853648\begin{lstlisting}
    3786 trait m_lvalue( otype T ) {@\impl{m_lvalue}@
     3649trait m_lvalue( otype T ) {§\impl{m_lvalue}§
    37873650        T ?=?( T *, T );
    37883651};
     
    37943657Scalars can also be incremented and decremented.
    37953658\begin{lstlisting}
    3796 trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
    3797         T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
     3659trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {§\impl{m_l_scalar}§
     3660        T ?++( T * ), ?--( T * );§\use{scalar}§§\use{m_lvalue}§
    37983661        T ++?( T * ), --?( T * );
    37993662};
     
    38013664
    38023665Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3803 Note that this results in the ``inheritance'' of \lstinline$scalar$ along both paths.
    3804 \begin{lstlisting}
    3805 trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
    3806         T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
     3666Note that this results in the ``inheritance'' of \lstinline@scalar@ along both paths.
     3667\begin{lstlisting}
     3668trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
     3669        T ?/=?( T *, T ), ?*=?( T *, T );§\use{m_l_scalar}§§\use{arithmetic}§
    38073670        T ?+=?( T *, T ), ?-=?( T *, T );
    38083671};
    3809 trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
    3810         T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
    3811         T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
     3672trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {§\impl{m_l_integral}§
     3673        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );§\use{m_l_arithmetic}§
     3674        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );§\use{integral}§
    38123675};
    38133676\end{lstlisting}
     
    38173680
    38183681Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a constant pointer to the first element of the array, and the subscript expression
    3819 ``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
    3820 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
    3821 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
     3682``\lstinline@a[i]@'' is equivalent to the dereferencing expression ``\lstinline@(*( a+( i )))@''.
     3683Technically, pointer arithmetic and pointer comparisons other than ``\lstinline@==@'' and
     3684``\lstinline@!=@'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
    38223685Consequently, there is no need for a separate ``array type'' specification.
    38233686
    38243687Pointer types are scalar types.
    3825 Like other scalar types, they have ``\lstinline$+$'' and
    3826 ``\lstinline$-$'' operators, but the types do not match the types of the operations in
    3827 \lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
    3828 \begin{lstlisting}
    3829 trait pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
     3688Like other scalar types, they have ``\lstinline@+@'' and
     3689``\lstinline@-@'' operators, but the types do not match the types of the operations in
     3690\lstinline@arithmetic@, so these operators cannot be consolidated in \lstinline@scalar@.
     3691\begin{lstlisting}
     3692trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
    38303693        P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
    38313694        ptrdiff_t ?-?( P, P );
    38323695};
    3833 trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
     3696trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {§\impl{m_l_pointer}§
    38343697        P ?+=?( P *, long int ), ?-=?( P *, long int );
    38353698        P ?=?( P *, void * );
     
    38403703Specifications that define the dereference operator ( or subscript operator ) require two parameters, one for the pointer type and one for the pointed-at ( or element ) type.
    38413704Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
    3842 The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
    3843 ``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
    3844 \begin{lstlisting}
    3845 trait ptr_to( type P | pointer( P ), otype T ) {@\impl{ptr_to}@@\use{pointer}@
     3705The assertion ``\lstinline@|ptr_to( Safe_pointer, int )@'' should be read as
     3706``\lstinline@Safe_pointer@ acts like a pointer to \lstinline@int@''.
     3707\begin{lstlisting}
     3708trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
    38463709        lvalue T *?( P );
    38473710        lvalue T ?[?]( P, long int );
    38483711};
    3849 trait ptr_to_const( type P | pointer( P ), otype T ) {@\impl{ptr_to_const}@
     3712trait ptr_to_const( otype P | pointer( P ), otype T ) {§\impl{ptr_to_const}§
    38503713        const lvalue T *?( P );
    3851         const lvalue T ?[?]( P, long int );@\use{pointer}@
     3714        const lvalue T ?[?]( P, long int );§\use{pointer}§
    38523715};
    3853 trait ptr_to_volatile( type P | pointer( P ), otype T ) }@\impl{ptr_to_volatile}@
     3716trait ptr_to_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_volatile}§
    38543717        volatile lvalue T *?( P );
    3855         volatile lvalue T ?[?]( P, long int );@\use{pointer}@
     3718        volatile lvalue T ?[?]( P, long int );§\use{pointer}§
    38563719};
    3857 trait ptr_to_const_volatile( type P | pointer( P ), otype T ) }@\impl{ptr_to_const_volatile}@
    3858         const volatile lvalue T *?( P );@\use{pointer}@
     3720trait ptr_to_const_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_const_volatile}§
     3721        const volatile lvalue T *?( P );§\use{pointer}§
    38593722        const volatile lvalue T ?[?]( P, long int );
    38603723};
    38613724\end{lstlisting}
    38623725
    3863 Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
     3726Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline@T *@'' can be assigned to a ``\lstinline@const T *@'', a ``\lstinline@volatile T *@'', and a ``\lstinline@const volatile T *@''.
    38643727Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    3865 ``\lstinline$ptr_to$'' specifications.
    3866 \begin{lstlisting}
    3867 trait m_l_ptr_to( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ otype T | ptr_to( P, T )@\use{ptr_to}@ {
     3728``\lstinline@ptr_to@'' specifications.
     3729\begin{lstlisting}
     3730trait m_l_ptr_to( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to}§ otype T | ptr_to( P, T )§\use{ptr_to}§ {
    38683731        P ?=?( P *, T * );
    38693732        T * ?=?( T **, P );
    38703733};
    3871 trait m_l_ptr_to_const( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ otype T | ptr_to_const( P, T )@\use{ptr_to_const}@) {
     3734trait m_l_ptr_to_const( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to_const}§ otype T | ptr_to_const( P, T )§\use{ptr_to_const}§) {
    38723735        P ?=?( P *, const T * );
    38733736        const T * ?=?( const T **, P );
    38743737};
    3875 trait m_l_ptr_to_volatile( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ otype T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@
     3738trait m_l_ptr_to_volatile( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to_volatile}§ otype T | ptr_to_volatile( P, T )) {§\use{ptr_to_volatile}§
    38763739        P ?=?( P *, volatile T * );
    38773740        volatile T * ?=?( volatile T **, P );
    38783741};
    3879 trait m_l_ptr_to_const_volatile( type P | ptr_to_const_volatile( P ),@\use{ptr_to_const_volatile}@@\impl{m_l_ptr_to_const_volatile}@
    3880                 type T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {@\use{m_l_ptr_to_const}@@\use{m_l_ptr_to_volatile}@
     3742trait m_l_ptr_to_const_volatile( otype P | ptr_to_const_volatile( P ),§\use{ptr_to_const_volatile}§§\impl{m_l_ptr_to_const_volatile}§
     3743                otype T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {§\use{m_l_ptr_to_const}§§\use{m_l_ptr_to_volatile}§
    38813744        P ?=?( P *, const volatile T * );
    38823745        const volatile T * ?=?( const volatile T **, P );
     
    38873750An alternative specification can make use of the fact that qualification of the pointed-at type is part of a pointer type to capture that regularity.
    38883751\begin{lstlisting}
    3889 trait m_l_ptr_like( type MyP | m_l_pointer( MyP ),@\use{m_l_pointer}@@\impl{m_l_ptr_like}@ type CP | m_l_pointer( CP ) ) {
     3752trait m_l_ptr_like( type MyP | m_l_pointer( MyP ),§\use{m_l_pointer}§§\impl{m_l_ptr_like}§ type CP | m_l_pointer( CP ) ) {
    38903753        MyP ?=?( MyP *, CP );
    38913754        CP ?=?( CP *, MyP );
    38923755};
    38933756\end{lstlisting}
    3894 The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
    3895 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''.
     3757The assertion ``\lstinline@| m_l_ptr_like( Safe_ptr, const int * )@'' should be read as
     3758``\lstinline@Safe_ptr@ is a pointer type like \lstinline@const int *@''.
    38963759This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a
    3897 \lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
    3898 ``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed to \lstinline$CP$ really is a pointer type.
     3760\lstinline@MyP@ produces an lvalue of the type that \lstinline@CP@ points at, and the
     3761``\lstinline@|m_l_pointer( CP )@'' assertion provides only a weak assurance that the argument passed to \lstinline@CP@ really is a pointer type.
    38993762
    39003763
     
    39023765
    39033766Different operators often have related meanings;
    3904 for instance, in C, ``\lstinline$+$'',
    3905 ``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
     3767for instance, in C, ``\lstinline@+@'',
     3768``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition.
    39063769Languages like {\CC} and Ada allow programmers to define operators for new types, but do not require that these relationships be preserved, or even that all of the operators be implemented.
    39073770Completeness and consistency is left to the good taste and discretion of the programmer.
     
    39163779The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    39173780However, it is usually convenient to implement a single comparison function that returns a negative integer, 0, or a positive integer if its first argument is respectively less than, equal to, or greater than its second argument;
    3918 the library function \lstinline$strcmp$ is an example.
    3919 
    3920 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
     3781the library function \lstinline@strcmp@ is an example.
     3782
     3783C and \CFA have an extra, non-obvious comparison operator: ``\lstinline@!@'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    39213784\begin{lstlisting}
    39223785trait comparable( otype T ) {
     
    39673830
    39683831Note that, although an arithmetic type would certainly provide comparison functions, and an integral type would provide arithmetic operations, there does not have to be any relationship among
    3969 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$.
     3832\lstinline@int_base@, \lstinline@arith_base@ and \lstinline@comparable@.
    39703833Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
    3971 A truly minimal implementation of an arithmetic type might only provide
    3972 \lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
    3973 \lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
    3974 
    3975 Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations!
     3834A truly minimal implementation of an arithmetic type might only provide \lstinline@0@, \lstinline@1@, and \lstinline@?-=?@, which would be used by polymorphic \lstinline@?+=?@, \lstinline@?*=?@, and \lstinline@?/=?@ functions.
     3835
     3836Note also that \lstinline@short@ is an integer type in C11 terms, but has no operations!
    39763837
    39773838
     
    39803841
    39813842Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers.
    3982 This gets into \lstinline$noalias$ territory.
    3983 Qualifying anything (``\lstinline$short restrict rs$'') means pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
     3843This gets into \lstinline@noalias@ territory.
     3844Qualifying anything (``\lstinline@short restrict rs@'') means pointer parameters of \lstinline@?++@, etc, would need restrict qualifiers.
    39843845
    39853846Enumerated types.
     
    39913852Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    39923853
    3993 Operators on {,signed,unsigned} char and other small types. ?<? harmless;
     3854Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@ harmless;
    39943855?*? questionable for chars.
    39953856Generic selections make these choices visible.
     
    39973858``promotion'' function?
    39983859
    3999 \lstinline$register$ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
    4000 
    4001 Don't use ptrdiff\_t by name in the predefineds.
     3860\lstinline@register@ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
     3861
     3862Don't use \lstinline@ptrdiff_t@ by name in the predefineds.
    40023863
    40033864Polymorphic objects.
     
    40063867
    40073868\bibliographystyle{plain}
    4008 \bibliography{refrat}
     3869\bibliography{cfa}
    40093870
    40103871
  • doc/user/Makefile

    r1f6e009 r1048b31  
    11## Define the appropriate configuration variables.
    22
    3 TeXLIB = .::
     3TeXLIB = .:../bibliography/:../LaTeXmacros/:
    44LaTeX  = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex
    5 BibTeX = BSTINPUTS=${TeXLIB} && export BSTINPUTS && bibtex
     5BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
    66
    77## Define the text source files.
     
    1212
    1313FIGURES = ${addsuffix .tex, \
     14Cdecl \
    1415}
    1516
     
    4344        dvips $< -o $@
    4445
    45 ${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex ${basename ${DOCUMENT}}.bib /usr/local/bibliographies/pl.bib
     46${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
     47                ../LaTeXmacros/common.tex ../LaTeXmacros/indexstyle ../bibliography/cfa.bib
    4648        # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run.
    4749        if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi
     
    5355        -${BibTeX} ${basename $@}
    5456        # Make index from *.aux entries and input index at end of document
    55         makeindex -s indexstyle ${basename $@}.idx
     57        makeindex -s ../LaTeXmacros/indexstyle ${basename $@}.idx
    5658        ${LaTeX} ${basename $@}.tex
    5759        # Run again to get index title into table of contents
  • doc/user/user.tex

    r1f6e009 r1048b31  
     1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
     2%%
     3%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
     4%%
     5%% The contents of this file are covered under the licence agreement in the
     6%% file "LICENCE" distributed with Cforall.
     7%%
     8%% user.tex --
     9%%
     10%% Author           : Peter A. Buhr
     11%% Created On       : Wed Apr  6 14:53:29 2016
     12%% Last Modified By : Peter A. Buhr
     13%% Last Modified On : Sat Apr 30 13:54:32 2016
     14%% Update Count     : 221
     15%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     16
    117% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
     18
     19% red highlighting ®...® (registered trademark sumbol)
     20% blue highlighting ©...© (copyright symbol)
     21% latex escape §...§ (section symbol)
     22% keyword escape ¶...¶ (pilcrow symbol)
     23% math escape $...$ (dollar symbol)
    224
    325\documentclass[openright,twoside]{article}
     
    527
    628% Latex packages used in the document.
    7 
     29\usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
     30\usepackage{textcomp}
     31\usepackage[latin1]{inputenc}
     32\usepackage{upquote}
    833\usepackage{fullpage,times}
     34\usepackage{epic,eepic}
    935\usepackage{xspace}
    1036\usepackage{varioref}
     
    1238\usepackage{footmisc}
    1339\usepackage{comment}
    14 \usepackage{latexsym}                                   % \Box
    15 \usepackage{mathptmx}                                   % better math font with "times"
     40\usepackage{latexsym}                                   % \Box
     41\usepackage{mathptmx}                                   % better math font with "times"
    1642\usepackage[pagewise]{lineno}
    1743\renewcommand{\linenumberfont}{\scriptsize\sffamily}
     
    2248%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2349
     50% Bespoke macros used in the document.
     51\input{common}
     52
     53%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     54
    2455% Names used in the document.
    2556
    26 \newcommand{\CFA}{C$\forall$\xspace}    % set language symbolic name
    27 \newcommand{\CFL}{Cforall\xspace}               % set language text name
    28 \newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
    29 \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
     57\newcommand{\Version}{1.0.0}
    3058\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
    3159
    3260%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    3361
    34 % Bespoke macros used in the document.
    35 
    36 \makeatletter
    37 % allow escape sequence in lstinline
    38 %\usepackage{etoolbox}
    39 %\patchcmd{\lsthk@TextStyle}{\let\lst@DefEsc\@empty}{}{}{\errmessage{failed to patch}}
    40 
    41 \renewcommand\small{%
    42    \@setfontsize\small{8.5}{11}%
    43    \abovedisplayskip 8.5pt \@plus 3pt \@minus 4pt
    44    \abovedisplayshortskip \z@ \@plus 2pt
    45    \belowdisplayshortskip 4pt \@plus 2pt \@minus 2pt
    46    \def\@listi{\leftmargin\leftmargini
    47                \topsep 4pt \@plus 2pt \@minus 2pt
    48                \parsep 2pt \@pluspt \@minuspt
    49                \itemsep \parsep}%
    50    \belowdisplayskip \abovedisplayskip
    51 }
    52 \usepackage{relsize}            % must be after change to small
    53 
    54 \renewcommand{\labelitemi}{{\raisebox{0.25ex}{\footnotesize$\bullet$}}}
    55 \renewenvironment{itemize}{\begin{list}{\labelitemi}{\topsep=5pt\itemsep=5pt\parsep=0pt}}{\end{list}}
    56 
    57 %  Reduce size of section titles
    58 \renewcommand\section{\@startsection{section}{1}{\z@}{-3.0ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\large\bfseries}}
    59 \renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    60 \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    61 \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}{-2.0ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries}}
    62 
    63 % index macros
    64 \newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
    65 \newcommand{\definition}[1]{\textbf{\hyperpage{#1}}}
    66 \newcommand{\see}[1]{\emph{see} #1}
    67 
    68 % Define some commands that produce formatted index entries suitable for cross-references.
    69 % ``\spec'' produces entries for specifications of entities.  ``\impl'' produces entries for their
    70 % implementations, and ``\use'' for their uses.
    71 
    72 %  \newcommand{\bold}[1]{{\bf #1}}
    73 %  \def\spec{\@bsphack\begingroup
    74 %             \def\protect##1{\string##1\space}\@sanitize
    75 %             \@wrxref{|bold}}
    76 \def\impl{\@bsphack\begingroup
    77           \def\protect##1{\string##1\space}\@sanitize
    78           \@wrxref{|definition}}
    79 \newcommand{\indexcode}[1]{{\lstinline$#1$}}
    80 \def\use{\@bsphack\begingroup
    81          \def\protect##1{\string##1\space}\@sanitize
    82          \@wrxref{|hyperpage}}
    83 \def\@wrxref#1#2{\let\thepage\relax
    84     \xdef\@gtempa{\write\@indexfile{\string
    85     \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa
    86     \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
    87 %\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}}
    88 %\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
    89 
    90 % inline text and lowercase index: \Index{inline and lowercase index text}
    91 % inline text and as-in index: \Index[as-is index text]{inline text}
    92 % inline text but index with different as-is text: \Index[index text]{inline text}
    93 \newcommand{\Index}{\@ifstar\@sIndex\@Index}
    94 \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    95 \newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
    96 
    97 \newcommand{\newtermFontInline}{\emph}
    98 \newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
    99 \newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    100 \newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
    101 \makeatother
    102 
    103 % blocks and titles
    104 \newenvironment{quote2}{%
    105         \list{}{\lstset{resetmargins=true}\leftmargin=\parindent\rightmargin\leftmargin}%
    106         \item\relax
    107 }{%
    108         \endlist
    109 }% quote2
    110 \newenvironment{rationale}{%
    111   \begin{quotation}\noindent$\Box$\enspace
    112 }{%
    113   \hfill\enspace$\Box$\end{quotation}
    114 }%
    115 \newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    116 \newcommand{\rewrite}{\(\Rightarrow\)}
    117 \newcommand{\rewriterules}{\paragraph{Rewrite Rules}~\par\noindent}
    118 \newcommand{\examples}{\paragraph{Examples}~\par\noindent}
    119 \newcommand{\semantics}{\paragraph{Semantics}~\par\noindent}
    120 \newcommand{\constraints}{\paragraph{Constraints}~\par\noindent}
    121 \newcommand{\predefined}{\paragraph{Predefined Identifiers}~\par\noindent}
    122 
    123 % BNF macros
    124 \def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]}
    125 \let\endsyntax=\endtrivlist
    126 \newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
    127 \newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
    128 \newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
    129 \newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
    130 \newcommand{\opt}{$_{opt}$\ }
    131 
    132 % adjust varioref package with default "section" and "page" titles, and optional title with faraway page numbers
    133 % \VRef{label} => Section 2.7, \VPageref{label} => page 17
    134 % \VRef[Figure]{label} => Figure 3.4, \VPageref{label} => page 17
    135 \renewcommand{\reftextfaceafter}{\unskip}
    136 \renewcommand{\reftextfacebefore}{\unskip}
    137 \renewcommand{\reftextafter}{\unskip}
    138 \renewcommand{\reftextbefore}{\unskip}
    139 \renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}}
    140 \renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}}
    141 \newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}}
    142 \newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
    143 
    144 % Go programming language
    145 \lstdefinelanguage{Golang}%
    146   {morekeywords=[1]{package,import,func,type,struct,return,defer,panic, recover,select,var,const,iota,},%
    147    morekeywords=[2]{string,uint,uint8,uint16,uint32,uint64,int,int8,int16, int32,int64,
    148                 bool,float32,float64,complex64,complex128,byte,rune,uintptr, error,interface},%
    149    morekeywords=[3]{map,slice,make,new,nil,len,cap,copy,close,true,false, delete,append,real,imag,complex,chan,},%
    150    morekeywords=[4]{for,break,continue,range,goto,switch,case,fallthrough,if, else,default,},%
    151    morekeywords=[5]{Println,Printf,Error,},%
    152    sensitive=true,%
    153    morecomment=[l]{//},%
    154    morecomment=[s]{/*}{*/},%
    155    morestring=[b]',%
    156    morestring=[b]",%
    157    morestring=[s]{`}{`},%
    158 }
    159 
    160 % CFA based on ANSI C
    161 \lstdefinelanguage{CFA}[ANSI]{C}%
    162 {morekeywords={asm,_Alignas,_Alignof,_At,_Atomic,_Bool,catch,catchResume,choose,_Complex,trait,disable,dtype,enable,
    163         fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,lvalue,_Noreturn,otype,restrict,_Static_assert,
    164         _Thread_local,throw,throwResume,try,},
    165 }%
    166 
    167 \lstset{
    168 language=CFA,
    169 columns=flexible,
    170 basicstyle=\sf\relsize{-1},
    171 tabsize=4,
    172 xleftmargin=\parindent,
    173 escapechar=@,
    174 mathescape=true,
    175 keepspaces=true,
    176 showstringspaces=false,
    177 showlines=true,
    178 }%
    179 
    180 \makeatletter
    181 % replace/adjust listings characters that look bad in sanserif
    182 \lst@CCPutMacro
    183 \lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus
    184 \lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than
    185 \lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than
    186 \lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % replace circumflex
    187 \lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
    188 \lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % replace tilde
    189 %\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
    190 \@empty\z@\@empty
    191 \makeatother
    192 
    193 \setcounter{secnumdepth}{3}     % number subsubsections
    194 \setcounter{tocdepth}{3}                % subsubsections in table of contents
     62\setcounter{secnumdepth}{3}                             % number subsubsections
     63\setcounter{tocdepth}{3}                                % subsubsections in table of contents
    19564\makeindex
    19665
     
    19968\begin{document}
    20069\pagestyle{headings}
    201 \linenumbers                                    % comment out to turn off line numbering
     70\linenumbers                                            % comment out to turn off line numbering
    20271
    20372\title{\Huge
     
    21382}% author
    21483\date{
    215 DRAFT\\\today
     84DRAFT \\
     85\today
    21686}% date
    21787
     
    241111
    242112\CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed an as evolutionary step forward from the C programming language.
    243 The syntax of the \CFA language builds from that of C, and should look immediately familiar to C programmers.
     113The syntax of the \CFA language builds from C, and should look immediately familiar to C programmers.
    244114% Any language feature that is not described here can be assumed to be using the standard C11 syntax.
    245 \CFA has added many modern programming-language features, which directly leads to increased safety and productivity, while maintaining interoperability with existing C programs, and maintaining C-like performance.
     115\CFA adds many modern programming-language features, which directly leads to increased safety and productivity, while maintaining interoperability with existing C programs and achieving C performance.
    246116Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global garbage-collection.
    247117The primary new features include parametric-polymorphism routines and types, exceptions, concurrency, and modules.
     
    254124New programs can be written in \CFA using a combination of C and \CFA features.
    255125\CC had a similar goal 30 years ago, but has struggled over the intervening time to incorporate modern programming-language features because of early design choices.
    256 \CFA has 30 years of hindsight and a much cleaner starting point than \CC.
     126\CFA has 30 years of hindsight and clean starting point.
    257127
    258128Like \CC, there may be both an old and new ways to achieve the same effect.
     
    279149\end{quote2}
    280150Both programs output the same result.
    281 While the \CFA I/O looks similar to the \CC style of output, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
     151While the \CFA I/O looks similar to the \CC output style, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
    282152
    283153This document is a reference manual for the \CFA programming language, targeted at \CFA programmers.
    284 Implementers may also refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
     154Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
    285155In its current state, this document covers the intended core features of the language.
    286156Changes to the syntax and additional features are expected to be included in later revisions.
     
    294164The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \CC approach of object-oriented extensions to the C type-system.
    295165A first implementation of the core Cforall language was created~\cite{Bilson03,Esteves04}, but at the time there was little interesting in extending C, so work did not continue.
    296 As the saying goes, ``What goes around, comes around'', and there is now renewed interest in the C programming language, so the \CFA project has been restarted.
    297 
    298 
    299 \section{Motivation: Why fix C?}
     166As the saying goes, ``What goes around, comes around'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
     167
     168
     169\section{Why fix C?}
    300170
    301171Even with all its problems, C is a very popular programming language because it allows writing software at virtually any level in a computer system without restriction.
     
    314184Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
    315185These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
    316 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be complete rewritten.
     186As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
    317187These costs can be prohibitive for many companies with a large software base in C/\CC, and many programmers that require retraining to a new programming language.
    318188
     
    331201This feature allows users of \CFA to take advantage of the existing panoply of C libraries from inside their \CFA code.
    332202In fact, one of the biggest issues for any new programming language is establishing a minimum level of library code to support a large body of activities.
    333 Programming-language developers often state that adequate library support costs many times more than designing and implementing the language itself.
     203Programming-language developers often state that adequate library support takes more work than designing and implementing the language itself.
    334204Like \CC, \CFA starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
    335205
     
    338208Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
    339209\begin{lstlisting}
     210char abs( char );
    340211extern "C" {
    341 #include <stdlib.h>                     // provide C prototype for integer "abs" routine
     212int abs( int );                         // use default C routine for int
    342213} // extern "C"
    343 
    344 char abs( char );
    345 long int abs( long int );       // @{\CFA}@ overload name "abs" for other types
     214long int abs( long int );
    346215long long int abs( long long int );
    347216float abs( float );
     
    360229The name ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
    361230Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
    362 The time savings and safety of using one name uniformly versus @N@ unique names should not be underestimated.
    363 
    364 
    365 \section{Compiling \CFA}
     231The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
     232
     233
     234\section[Compiling CFA Program]{Compiling \CFA Program}
    366235
    367236The command \lstinline@cfa@ is used to compile \CFA program(s).
    368 This command works like the GNU \lstinline@gcc@ command, e.g.:
    369 \begin{lstlisting}
    370 cfa [ gcc-options ] C/@{\CFA}@-files [ assembler/loader-files ]
    371 \end{lstlisting}
    372 The following additional option is available:
     237This command works like the GNU \lstinline@gcc@\index{gcc} command, e.g.:
     238\begin{lstlisting}
     239cfa [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
     240\end{lstlisting}
     241\indexc{cfa}\index{compilation!cfa@\lstinline$cfa$}
     242By default, \CFA programs having the following \lstinline@gcc@ flags turned on:
    373243\begin{description}
    374 \item
    375 \hspace*{-4pt}\lstinline@-CFA@
     244\item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{\lstinline$-std=gnu99$}}
     245The 1999 C standard plus GNU extensions.
     246\item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{\lstinline$-fgnu89-¶inline¶$}}
     247Use the traditional GNU semantics for inline routines in C99 mode.
     248\end{description}
     249The following new \CFA option is available:
     250\begin{description}
     251\item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{\lstinline$-CFA$}}
    376252Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
    377253\end{description}
    378254
     255The following preprocessor variables are available:
     256\begin{description}
     257\item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{\lstinline$__CFA__$}}
     258is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
     259The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
     260Hence, the need to have three variables for the major, minor and patch version number.}
     261
     262\item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{\lstinline$__CFA_MINOR__$}}
     263is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
     264
     265\item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@\lstinline$__CFA_PATCH__$}
     266is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
     267
     268\item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@\lstinline$__CFORALL__$}
     269is always available during preprocessing and it has no value.
     270\end{description}
     271
     272These preprocessor variables allow conditional compilation of programs that must work differently in these situations.
     273For example, to toggle between C and \CFA extensions, using the following:
     274\begin{lstlisting}
     275#ifndef __CFORALL__
     276#include <stdio.h>                      // C header file
     277#else
     278#include <fstream>                      // §\CFA{}§ header file
     279#endif
     280\end{lstlisting}
     281which conditionally includes the correct header file, if the program is compiled using \lstinline@gcc@ or \lstinline@cfa@.
     282
    379283
    380284\section{Underscores in Constants}
     
    382286Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
    383287\begin{lstlisting}
    384 2_147_483_648;                          // decimal constant
     2882®_®147®_®483®_®648;                            // decimal constant
    38528956_ul;                                          // decimal unsigned long constant
    3862900_377;                                          // octal constant
     
    408312the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
    409313\end{enumerate}
    410 It is significantly easier to read and type long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
     314It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
    411315This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java.
    412316
     
    417321C declaration syntax is notoriously confusing and error prone.
    418322For example, many C programmers are confused by a declaration as simple as:
    419 \begin{lstlisting}
    420 int *x[ 10 ]
    421 \end{lstlisting}
    422 Is this a pointer to an array of 10 integers or an array of 10 pointers to integers?
     323\begin{quote2}
     324\begin{tabular}{@{}ll@{}}
     325\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
     326int *x[ 5 ]
     327\end{lstlisting}
     328&
     329\raisebox{-0.75\totalheight}{\input{Cdecl}}
     330\end{tabular}
     331\end{quote2}
     332Is this an array of 5 pointers to integers or a pointer to an array of 5 integers?
    423333Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
    424334For example, a routine returning a pointer to an array of integers is defined and used in the following way:
    425335\begin{lstlisting}
    426 int (*f())[ 10 ] {...};
    427 ... (*f())[ 3 ] += 1;           // definition mimics usage
     336int (*f())[ 5 ] {...};  // definition mimics usage
     337... (*f())[ 3 ] += 1;
    428338\end{lstlisting}
    429339Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
     
    434344The only exception is bit field specification, which always appear to the right of the base type.
    435345C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
    436 Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
    437 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
    438 e.g.:
    439 \begin{lstlisting}
    440 x;                                      // int x
    441 *y;                                     // int *y
    442 f( p1, p2 );            // int f( int p1, int p2 );
    443 f( p1, p2 ) {}          // int f( int p1, int p2 ) {}
    444 \end{lstlisting}
    445346
    446347In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
     
    451352\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
    452353\begin{lstlisting}
    453 * int x, y;
     354®* int x, y;®
    454355\end{lstlisting}
    455356&
     
    464365\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
    465366\begin{lstlisting}
    466 [ 10 ] int z;
    467 [ 10 ] * char w;
    468 * [ 10 ] double v;
     367[ 5 ] int z;
     368[ 5 ] * char w;
     369* [ 5 ] double v;
    469370struct s {
    470 int f0:3;
     371        int f0:3;
    471372        * int f1;
    472         [ 10 ] * int f2;
     373        [ 5 ] * int f2;
    473374};
    474375\end{lstlisting}
    475376&
    476377\begin{lstlisting}
    477 int z[ 10 ];
    478 char *w[ 10 ];
    479 double (*v)[ 10 ];
     378int z[ 5 ];
     379char *w[ 5 ];
     380double (*v)[ 5 ];
    480381struct s {
    481382        int f0:3;
    482383        int *f1;
    483         int *f2[ 10 ]
     384        int *f2[ 5 ]
    484385};
    485386\end{lstlisting}
    486387&
    487388\begin{lstlisting}
    488 // array of 10 integers
    489 // array of 10 pointers to char
    490 // pointer to array of 10 doubles
     389// array of 5 integers
     390// array of 5 pointers to char
     391// pointer to array of 5 doubles
    491392
    492393// common bit field syntax
     
    497398\end{tabular}
    498399\end{quote2}
    499 
    500 As stated above, the two styles of declaration may appear together in the same block.
    501 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
    502 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
    503 In general, mixing declaration styles in a routine or even a translation unit is not recommended, as it makes a program more difficult to read.
    504 Therefore, it is suggested that an entire translation unit be written in one declaration style or the other.
    505400
    506401All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
     
    510405\begin{lstlisting}
    511406const * const int x;
    512 const * [ 10 ] const int y;
     407const * [ 5 ] const int y;
    513408\end{lstlisting}
    514409&
    515410\begin{lstlisting}
    516411int const * const x;
    517 const int (* const y)[ 10 ]
     412const int (* const y)[ 5 ]
    518413\end{lstlisting}
    519414&
    520415\begin{lstlisting}
    521416// const pointer to const integer
    522 // const pointer to array of 10 const integers
     417// const pointer to array of 5 const integers
    523418\end{lstlisting}
    524419\end{tabular}
     
    530425\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
    531426\begin{lstlisting}
    532 extern [ 10 ] int x;
     427extern [ 5 ] int x;
    533428static * const int y;
    534429\end{lstlisting}
    535430&
    536431\begin{lstlisting}
    537 int extern x[ 10 ];
     432int extern x[ 5 ];
    538433const int static *y;
    539434\end{lstlisting}
    540435&
    541436\begin{lstlisting}
    542 // externally visible array of 10 integers
     437// externally visible array of 5 integers
    543438// internally visible pointer to constant int
    544439\end{lstlisting}
    545440\end{tabular}
    546441\end{quote2}
     442
     443Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
     444At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
     445e.g.:
     446\begin{lstlisting}
     447x;                                              // int x
     448*y;                                             // int *y
     449f( p1, p2 );                    // int f( int p1, int p2 );
     450f( p1, p2 ) {}                  // int f( int p1, int p2 ) {}
     451\end{lstlisting}
     452
     453As stated above, the two styles of declaration may appear together in the same block.
     454Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
     455Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
    547456
    548457
     
    555464\begin{lstlisting}
    556465y = (* int)x;
    557 i = sizeof([ 10 ] * int);
     466i = sizeof([ 5 ] * int);
    558467\end{lstlisting}
    559468&
    560469\begin{lstlisting}
    561470y = (int *)x;
    562 i = sizeof(int *[ 10 ]);
     471i = sizeof(int *[ 5 ]);
    563472\end{lstlisting}
    564473\end{tabular}
     
    571480The point of the new syntax is to allow returning multiple values from a routine~\cite{CLU,Galletly96}, e.g.:
    572481\begin{lstlisting}
    573 [ int o1, int o2, char o3 ] f( int i1, char i2, char i3 ) {
    574         @\emph{routine body}@
     482®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
     483        §\emph{routine body}§
    575484}
    576485\end{lstlisting}
     
    583492Declaration qualifiers can only appear at the start of a routine definition, e.g.:
    584493\begin{lstlisting}
    585 extern [ int x ] g( int y ) {}
     494extern [ int x ] g( int y ) {§\,§}
    586495\end{lstlisting}
    587496Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
    588497in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    589498\begin{lstlisting}
    590 [ ] g();                                        // no input or output parameters
     499[§\,§] g();                                             // no input or output parameters
    591500[ void ] g( void );                     // no input or output parameters
    592501\end{lstlisting}
     
    600509\CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
    601510\begin{lstlisting}
    602 int (*f(x))[ 10 ] int x; {}
    603 \end{lstlisting}
    604 The string ``\lstinline@int (*f(x))[ 10 ]@'' declares a K\&R style routine of type returning a pointer to an array of 10 integers, while the string ``\lstinline@[ 10 ] int x@'' declares a \CFA style parameter x of type array of 10 integers.
     511int (*f(x))[ 5 ] int x; {}
     512\end{lstlisting}
     513The string ``\lstinline@int (*f(x))[ 5 ]@'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``\lstinline@[ 5 ] int x@'' declares a \CFA style parameter x of type array of 5 integers.
    605514Since the strings overlap starting with the open bracket, \lstinline@[@, there is an ambiguous interpretation for the string.
    606515As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
     
    621530\begin{lstlisting}
    622531#define ptoa( n, d ) int (*n)[ d ]
    623 int f( ptoa(p,10) ) ...         // expands to int f( int (*p)[ 10 ] )
    624 [ int ] f( ptoa(p,10) ) ...     // expands to [ int ] f( int (*p)[ 10 ] )
     532int f( ptoa(p,5) ) ...          // expands to int f( int (*p)[ 5 ] )
     533[ int ] f( ptoa(p,5) ) ...      // expands to [ int ] f( int (*p)[ 5 ] )
    625534\end{lstlisting}
    626535Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
     
    639548Because the value in the return variable is automatically returned when a \CFA routine terminates, the \lstinline@return@ statement \emph{does not} contain an expression, as in:
    640549\begin{lstlisting}
    641 [ int x ] f() {
     550®[ int x ]® f() {
    642551        ... x = 0; ... x = y; ...
    643         return; // implicitly return x
     552        ®return;® // implicitly return x
    644553}
    645554\end{lstlisting}
     
    697606for example, the following is incorrect:
    698607\begin{lstlisting}
    699 * [ int x ] f () fp;            // routine name ``f'' is not allowed
     608* [ int x ] f () fp;            // routine name "f" is not allowed
    700609\end{lstlisting}
    701610
     
    703612\section{Named and Default Arguments}
    704613
    705 Named and default arguments~\cite{Hardgrave76}.\footnote{
     614Named and default arguments~\cite{Hardgrave76}\footnote{
    706615Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
    707616are two mechanisms to simplify routine call.
     
    864773\subsection{Type Nesting}
    865774
    866 C allows \Index{type nesting}, but the nested types are hoisted\index{type!hoisting} (refactored) into the enclosing scope.
     775\CFA allows \Index{type nesting}, and type qualification of the nested types, where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
    867776\begin{quote2}
    868777\begin{tabular}{@{}l@{\hspace{30pt}}l|l@{}}
     
    919828
    920829int fred() {
    921         s.t.c = S.R;
    922         struct S.T t = { S.R, 1, 2 };
    923         enum S.C c;
    924         union S.T.U u;
     830        s.t.c = ®S.®R;  // type qualification
     831        struct ®S.®T t = { ®S.®R, 1, 2 };
     832        enum ®S.®C c;
     833        union ®S.T.®U u;
    925834}
    926835\end{lstlisting}
    927836\end{tabular}
    928837\end{quote2}
    929 
    930 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
    931 Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
    932 Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
     838In the left example in C, types \lstinline@C@, \lstinline@U@ and \lstinline@T@ are implicitly hoisted outside of type \lstinline@S@ into the containing block scope.
     839In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``\lstinline@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``\lstinline@::@''.
    933840
    934841
     
    943850which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than.
    944851\begin{lstlisting}
    945 const unsigned int size = 10;
    946 int a[size];
    947 
    948 qsort( a, size );               // ascending order using built in ?<?
    949 {                                               // descending order by local redefinition
    950         int ?<?( int a, int b ) { return a > b; } // nested routine
    951         qsort( a, size );
    952 }
    953 \end{lstlisting}
    954 
    955 
    956 \section{Incompatible}
    957 
    958 The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
    959 
    960 \begin{enumerate}
    961 \item
    962 Change type of character literal \lstinline@int@ to \lstinline@char@.
    963 This change allows overloading differentiation argument type matching, e.g.:
    964 \begin{lstlisting}
    965 int function( int i );
    966 int function( char c );
    967 function( 'x' );
    968 \end{lstlisting}
    969 It is preferable that this call match the second version of function rather than the first. \\
    970 Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
    971 \begin{lstlisting}
    972 sizeof('x') == sizeof(int)
    973 \end{lstlisting}
    974 will not work the same as C++ programs. \\
    975 Difficulty of converting: Simple. \\
    976 How widely used: Programs which depend upon sizeof('x') are probably rare.
    977 
    978 \item
    979 Change: String literals made \lstinline@const@ \\
    980 The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
    981 The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
    982 Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
    983 Effect on original feature: Change to semantics of well-defined feature. \\
    984 Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
    985 The most common cases are handled by a new but deprecated standard conversion:
    986 \begin{lstlisting}
    987 char* p = "abc"; // valid in C, deprecated in C++
    988 char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
    989 \end{lstlisting}
    990 How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
    991 
    992 \item
    993 Change: C++ does not have \emph{tentative definitions} as in C.
    994 E.g., at file scope,
    995 \begin{lstlisting}
    996 int i;
    997 int i;
    998 \end{lstlisting}
    999 is valid in C, invalid in C++.
    1000 This makes it impossible to define mutually referential file-local static
    1001 objects, if initializers are restricted to the syntactic forms of C. For example,
    1002 \begin{lstlisting}
    1003 struct X { int i; struct X *next; };
    1004 static struct X a;
    1005 static struct X b = { 0, &a };
    1006 static struct X a = { 1, &b };
    1007 \end{lstlisting}
    1008 Rationale: This avoids having different initialization rules for builtin types and userdefined types.
    1009 Effect on original feature: Deletion of semantically welldefined feature. \\
    1010 Difficulty of converting: Semantic transformation.
    1011 In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
    1012 How widely used: Seldom.
    1013 
    1014 \item
    1015 Change: A struct is a scope in C++, not in C
    1016 Rationale: Class scope is crucial to C++, and a struct is a class.
    1017 Effect on original feature: Change to semantics of well-defined feature.
    1018 Difficulty of converting: Semantic transformation.
    1019 How widely used: C programs use struct extremely frequently, but the change is only noticeable when
    1020 struct, enumeration, or enumerator names are referred to outside the struct. The latter is probably
    1021 rare.
    1022 
    1023 \item
    1024 Change: In C++, the name of a nested class is local to its enclosing class.
    1025 In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
    1026 Example:
    1027 \begin{lstlisting}
    1028 struct X {
    1029 struct Y { /* ... */ } y;
    1030 };
    1031 struct Y yy; // valid C, invalid C++
    1032 \end{lstlisting}
    1033 Rationale: C++ classes have member functions which require that classes establish scopes. The C rule
    1034 would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
    1035 locality within a class. A coherent set of scope rules for C++ based on the C rule would be very
    1036 complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples
    1037 involving nested or local functions.
    1038 Effect on original feature: Change of semantics of welldefined
    1039 feature.
    1040 Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of
    1041 the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing
    1042 struct is defined. Example:
    1043 \begin{lstlisting}
    1044 struct Y; // struct Y and struct X are at the same scope
    1045 struct X {
    1046 struct Y { /* ... */ } y;
    1047 };
    1048 \end{lstlisting}
    1049 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of
    1050 the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of
    1051 the difference in scope rules, which is documented in 3.3.
    1052 How widely used: Seldom.
    1053 \end{enumerate}
     852const unsigned int size = 5;
     853int ia[size];
     854...                                             // assign values to array ia
     855qsort( ia, size );              // sort ascending order using builtin ?<?
     856{
     857        ®int ?<?( int x, int y ) { return x > y; }® // nested routine
     858        qsort( ia, size );      // sort descending order by local redefinition
     859}
     860\end{lstlisting}
     861
     862Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
     863the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
     864The following program in undefined in \CFA (and \lstinline@gcc@\index{gcc})
     865\begin{lstlisting}
     866[* [int]( int )] foo() {                // int (*foo())( int )
     867        int ®i® = 7;
     868        int bar( int p ) {
     869                ®i® += 1;                                       // dependent on local variable
     870                sout | ®i® | endl;
     871        }
     872        return bar;                                     // undefined because of local dependence
     873}
     874int main() {
     875        * [int](int) fp = foo();        // int (*fp)(int)
     876    sout | fp( 3 ) | endl;
     877}
     878\end{lstlisting}
     879because
     880
     881Currently, there are no \Index{lambda} expressions, i.e., unnamed routines because routine names are very important to properly select the correct routine.
    1054882
    1055883
     
    1061889The general syntax of a tuple is:
    1062890\begin{lstlisting}
    1063 [ $\emph{exprlist}$ ]
     891[ §\emph{exprlist}§ ]
    1064892\end{lstlisting}
    1065893where \lstinline@$\emph{exprlist}$@ is a list of one or more expressions separated by commas.
     
    1081909The general syntax of a tuple type is:
    1082910\begin{lstlisting}
    1083 [ @\emph{typelist}@ ]
     911[ §\emph{typelist}§ ]
    1084912\end{lstlisting}
    1085913where \lstinline@$\emph{typelist}$@ is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
     
    1089917[ double, double, double ]
    1090918[ * int, int * ]                // mix of CFA and ANSI
    1091 [ * [ 10 ] int, * * char, * [ [ int, int ] ] (int, int) ]
     919[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
    1092920\end{lstlisting}
    1093921Like tuples, tuple types may be nested, such as \lstinline@[ [ int, int ], int ]@, which is a 2-element tuple type whose first element is itself a tuple type.
     
    11851013First the right-hand tuple is flattened and then the values are assigned individually.
    11861014Flattening is also performed on tuple types.
    1187 For example, the type \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type lstinline@[ int, int, int, int ]@.
     1015For example, the type \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type \lstinline@[ int, int, int, int ]@.
    11881016
    11891017A \newterm{structuring coercion} is the opposite of flattening;
     
    12111039Mass assignment has the following form:
    12121040\begin{lstlisting}
    1213 [ @\emph{lvalue}@, ..., @\emph{lvalue}@ ] = @\emph{expr}@;
    1214 \end{lstlisting}
    1215 The left-hand side is a tuple of \lstinline@$\emph{lvalues}$@, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
     1041[ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§;
     1042\end{lstlisting}
     1043The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
    12161044\lstinline@$\emph{expr}$@ is any standard arithmetic expression.
    12171045Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
     
    12501078Multiple assignment has the following form:
    12511079\begin{lstlisting}
    1252 [ @\emph{lvalue}@, . . ., @\emph{lvalue}@ ] = [ @\emph{expr}@, . . ., @\emph{expr}@ ];
    1253 \end{lstlisting}
    1254 The left-hand side is a tuple of \lstinline@$\emph{lvalues}$@, and the right-hand side is a tuple of \lstinline@$\emph{expr}$@s.
    1255 Each \lstinline@$\emph{expr}$@ appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \lstinline@$\emph{lvalues}$@ on the left-hand side of the statement using parallel semantics for each assignment.
     1080[ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];
     1081\end{lstlisting}
     1082The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s.
     1083Each \emph{expr} appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment.
    12561084An example of multiple assignment is:
    12571085\begin{lstlisting}
     
    12901118Cascade assignment has the following form:
    12911119\begin{lstlisting}
    1292 @\emph{tuple}@ = @\emph{tuple}@ = ... = @\emph{tuple}@;
     1120§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
    12931121\end{lstlisting}
    12941122and it has the same parallel semantics as for mass and multiple assignment.
     
    13081136Its general form is:
    13091137\begin{lstlisting}
    1310 @\emph{expr}@ . [ @\emph{fieldlist}@ ]
    1311 @\emph{expr}@ -> [ @\emph{fieldlist}@ ]
    1312 \end{lstlisting}
    1313 \lstinline@$\emph{expr}$@ is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
    1314 Each element of \lstinline@$\emph{ fieldlist}$@ is an element of the record specified by \lstinline@$\emph{expr}$@.
     1138§\emph{expr}§ . [ §\emph{fieldlist}§ ]
     1139§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
     1140\end{lstlisting}
     1141\emph{expr} is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
     1142Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    13151143A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
    13161144the following:
     
    13521180\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
    13531181\begin{lstlisting}
    1354 L1: for ( ... ) {
    1355         L2: for ( ... ) {
    1356                 L3: for ( ... ) {
    1357                         ... break L1; ...
    1358                         ... break L2; ...
    1359                         ... break L3; // or break
     1182®L1:® for ( ... ) {
     1183        ®L2:® for ( ... ) {
     1184                ®L3:® for ( ... ) {
     1185                        ... break ®L1®; ...
     1186                        ... break ®L2®; ...
     1187                        ... break ®L3®; // or break
    13601188                }
    13611189        }
     
    13821210\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
    13831211\begin{lstlisting}
    1384 L1: for ( ... ) {
    1385         L2: for ( ... ) {
    1386                 L3: for ( ... ) {
    1387                         ... continue L1; ...
    1388                         ... continue L2; ...
    1389                         ... continue L3; ...
     1212®L1®: for ( ... ) {
     1213        ®L2®: for ( ... ) {
     1214                ®L3®: for ( ... ) {
     1215                        ... continue ®L1®; ...
     1216                        ... continue ®L2®; ...
     1217                        ... continue ®L3®; ...
    13901218
    13911219                }
     
    16231451\begin{lstlisting}
    16241452switch ( i ) {
    1625   case 1, 3, 5:
     1453  ®case 1, 3, 5®:
    16261454        ...
    1627   case 2, 4, 6:
     1455  ®case 2, 4, 6®:
    16281456        ...
    16291457}
     
    16341462  case 1: case 3 : case 5:
    16351463        ...
    1636   case 2: case 4 : case 6: /* even values */
     1464  case 2: case 4 : case 6:
    16371465        ...
    16381466}
     
    16551483\begin{lstlisting}
    16561484switch ( i ) {
    1657   case 1~5
     1485  ®case 1~5:®
    16581486        ...
    1659   case 10~15
     1487  ®case 10~15:®
    16601488        ...
    16611489}
     
    16721500&
    16731501\begin{lstlisting}
     1502
    16741503// 1, 2, 3, 4, 5
    16751504
     
    21681997
    21691998
    2170 \section{Generics }
     1999\section{Auto Type-Inferencing}
     2000
     2001Auto type-inferencing occurs in a declaration where a variable's type is inferred from its initialization expression type.
     2002\begin{quote2}
     2003\begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
     2004\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{\lstinline@gcc@}\index{gcc} \\
     2005\begin{lstlisting}
     2006
     2007auto j = 3.0 * 4;
     2008int i;
     2009auto k = i;
     2010\end{lstlisting}
     2011&
     2012\begin{lstlisting}
     2013#define expr 3.0 * i
     2014typeof(expr) j = expr;
     2015int i;
     2016typeof(i) k = i;
     2017\end{lstlisting}
     2018&
     2019\begin{lstlisting}
     2020
     2021// use type of initialization expression
     2022
     2023// use type of primary variable
     2024\end{lstlisting}
     2025\end{tabular}
     2026\end{quote2}
     2027The two important capabilities are:
     2028\begin{itemize}
     2029\item
     2030preventing having to determine or write out long generic types,
     2031\item
     2032ensure secondary variables, related to a primary variable, always have the same type.
     2033\end{itemize}
     2034
     2035In \CFA, \lstinline@typedef@ provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
     2036\lstinline@gcc@ provides \lstinline@typeof@ to declare a secondary variable from a primary variable.
     2037\CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
     2038Only for overloaded routines with the same return type is variable type-inferencing possible.
     2039Finally, \lstinline@auto@ presents the programming problem of tracking down a type when the type is actually needed.
     2040For example, given
     2041\begin{lstlisting}
     2042auto j = ®...®
     2043\end{lstlisting}
     2044and the need to write a routine to compute using \lstinline@j@
     2045\begin{lstlisting}
     2046void rtn( ®...® parm );
     2047rtn( j );
     2048\end{lstlisting}
     2049A programmer must work backwards to determine the type of \lstinline@j@'s initialization expression, reconstructing the possibly long generic type-name.
     2050In this situation, having the type name or a short alias is very useful.
     2051
     2052There is also the conundrum in type inferencing of when to \emph{\Index{brand}} a type.
     2053That is, when is the type of the variable more important than the type of its initialization expression.
     2054For example, if a change is made in an initialization expression, it can cause hundreds or thousands of cascading type changes and/or errors.
     2055At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
     2056
     2057Given \lstinline@typedef@ and \lstinline@typeof@ in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
     2058Should a significant need arise, this feature can be revisited.
     2059
     2060
     2061\section{Generics}
    21712062
    21722063\CFA supports parametric polymorphism to allow users to define generic functions and types.
     
    23682259
    23692260        try {
    2370         throw 13;
     2261                throw 13;
    23712262        }
    23722263        catch(int e) {
    2373         printf(.caught an exception: %d\n., e);
     2264                printf(.caught an exception: %d\n., e);
    23742265        }
    23752266\end{lstlisting}
     
    24572348
    24582349
    2459 \section{I/O Library}
    2460 \label{s:IOLibrary}
    2461 
    2462 The goal for \CFA I/O is to make I/O as simple as possible for the general case, while fully supporting polmorphism and user defined types in a consistent way.
    2463 The general case is printing out a sequence of variables separated by whitespace.
    2464 \begin{lstlisting}
    2465 int x = 0, y = 1, z = 2;
    2466 sout | x | y | z | endl;
    2467 
    2468 cout << x << " " << y << " " << z << endl;
    2469 \end{lstlisting}
    2470 The \CC form takes almost twice as many characters.
    2471 
    2472 The logical-or operator is used because it is the lowest priority overloadable operator, other than assignment.
    2473 Therefore, most output expressions do not require parenthesis.
    2474 \begin{lstlisting}
    2475 int x = 0, y = 1, z = 2;
    2476 sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
    2477 
    2478 cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
    2479 \end{lstlisting}
    2480 
    2481 Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, although data flows in the opposite direction.
    2482 
    2483 \begin{figure}
    2484 \begin{lstlisting}[mathescape=off]
    2485 #include <fstream>
    2486 
    2487 int main() {
    2488         char c;
    2489         short int si;
    2490         unsigned short int usi;
    2491         int i;
    2492         unsigned int ui;
    2493         long int li;
    2494         unsigned long int uli;
    2495         long long int lli;
    2496         unsigned long long int ulli;
    2497         float f;
    2498         double d;
    2499         long double ld;
    2500         float _Complex fc;
    2501         double _Complex dc;
    2502         long double _Complex ldc;
    2503         char s1[10], s2[10];
    2504 
    2505         ifstream in;
    2506         open( &in, "read.data", "r" );
    2507 
    2508         &in | &c
    2509                 | &si | &usi | &i | &ui | &li | &uli | &lli | &ulli
    2510                 | &f | &d | &ld
    2511                 | &fc | &dc | &ldc
    2512                 | str( s1 ) | str( s2, 10 );
    2513 
    2514         sout | c | ' ' | endl
    2515                  | si | usi | i | ui | li | uli | lli | ulli | endl
    2516                  | f | d | ld | endl
    2517                  | f | "" | d | "" | ld | endl;
    2518 
    2519         sepSet( sout, ", $" );
    2520         sout | fc | dc | ldc | endl
    2521                  | sepOn | s1 | sepOff | s2 | endl
    2522                  | s1 | "" | s2 | endl;
    2523 }
    2524 
    2525 $ cat read.data
    2526 A 1 2 3 4 5 6 7 8 1.1 1.2 1.3 1.1+2.3 1.1-2.3 1.1-2.3 abc xyz
    2527 $ a.out
    2528 A
    2529 1 2 3 4 5 6 7 8
    2530 1.1 1.2 1.3
    2531 1.11.21.3
    2532 1.1+2.3i, $1.1-2.3i, $1.1-2.3i
    2533 , $abcxyz
    2534 abcxyz
    2535 \end{lstlisting}
    2536 \end{figure}
    2537 
    2538 
    2539 \section{Standard Library}
    2540 \label{s:StandardLibrary}
    2541 
    2542 The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitly polymorphic versions.
    2543 
    2544 
    2545 \subsection{malloc}
    2546 
    2547 \begin{lstlisting}
    2548 forall( otype T ) T * malloc( void );
    2549 forall( otype T ) T * malloc( char fill );
    2550 forall( otype T ) T * malloc( T * ptr, size_t size );
    2551 forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
    2552 forall( otype T ) T * calloc( size_t size );
    2553 forall( otype T ) T * realloc( T * ptr, size_t size );
    2554 forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
    2555 
    2556 forall( otype T ) T * aligned_alloc( size_t alignment );
    2557 forall( otype T ) T * memalign( size_t alignment );             // deprecated
    2558 forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
    2559 
    2560 forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
    2561 forall( otype T ) T * memset( T * ptr );                                // remove when default value available
    2562 \end{lstlisting}
    2563 
    2564 
    2565 \subsection{ato/strto}
    2566 
    2567 \begin{lstlisting}
    2568 int ato( const char * ptr );
    2569 unsigned int ato( const char * ptr );
    2570 long int ato( const char * ptr );
    2571 unsigned long int ato( const char * ptr );
    2572 long long int ato( const char * ptr );
    2573 unsigned long long int ato( const char * ptr );
    2574 float ato( const char * ptr );
    2575 double ato( const char * ptr );
    2576 long double ato( const char * ptr );
    2577 float _Complex ato( const char * ptr );
    2578 double _Complex ato( const char * ptr );
    2579 long double _Complex ato( const char * ptr );
    2580 
    2581 int strto( const char * sptr, char ** eptr, int base );
    2582 unsigned int strto( const char * sptr, char ** eptr, int base );
    2583 long int strto( const char * sptr, char ** eptr, int base );
    2584 unsigned long int strto( const char * sptr, char ** eptr, int base );
    2585 long long int strto( const char * sptr, char ** eptr, int base );
    2586 unsigned long long int strto( const char * sptr, char ** eptr, int base );
    2587 float strto( const char * sptr, char ** eptr );
    2588 double strto( const char * sptr, char ** eptr );
    2589 long double strto( const char * sptr, char ** eptr );
    2590 float _Complex strto( const char * sptr, char ** eptr );
    2591 double _Complex strto( const char * sptr, char ** eptr );
    2592 long double _Complex strto( const char * sptr, char ** eptr );
    2593 \end{lstlisting}
    2594 
    2595 
    2596 \subsection{bsearch/qsort}
    2597 
    2598 \begin{lstlisting}
    2599 forall( otype T | { int ?<?( T, T ); } )
    2600 T * bsearch( const T key, const T * arr, size_t dimension );
    2601 
    2602 forall( otype T | { int ?<?( T, T ); } )
    2603 void qsort( const T * arr, size_t dimension );
    2604 \end{lstlisting}
    2605 
    2606 
    2607 \subsection{abs}
    2608 
    2609 \begin{lstlisting}
    2610 char abs( char );
    2611 extern "C" {
    2612 int abs( int );         // use default C routine for int
    2613 } // extern
    2614 long int abs( long int );
    2615 long long int abs( long long int );
    2616 float abs( float );
    2617 double abs( double );
    2618 long double abs( long double );
    2619 float _Complex abs( float _Complex );
    2620 double _Complex abs( double _Complex );
    2621 long double _Complex abs( long double _Complex );
    2622 \end{lstlisting}
    2623 
    2624 
    2625 \subsection{random}
    2626 
    2627 \begin{lstlisting}
    2628 void randseed( long int s );
    2629 char random();
    2630 int random();
    2631 unsigned int random();
    2632 long int random();
    2633 unsigned long int random();
    2634 float random();
    2635 double random();
    2636 float _Complex random();
    2637 double _Complex random();
    2638 long double _Complex random();
    2639 \end{lstlisting}
    2640 
    2641 
    2642 \subsection{min/max/swap}
    2643 
    2644 \begin{lstlisting}
    2645 forall( otype T | { int ?<?( T, T ); } )
    2646 T min( const T t1, const T t2 );
    2647 
    2648 forall( otype T | { int ?>?( T, T ); } )
    2649 T max( const T t1, const T t2 );
    2650 
    2651 forall( otype T )
    2652 void swap( T * t1, T * t2 );
    2653 \end{lstlisting}
     2350\section{Syntactic Anomalies}
     2351
     2352The number 0 and 1 are treated specially in \CFA, and can be redefined as variables.
     2353One syntactic anomaly is when a field in an structure is names 0 or 1:
     2354\begin{lstlisting}
     2355struct S {
     2356        int 0, 1;
     2357} s;
     2358\end{lstlisting}
     2359The problem occurs in accesing these fields using the selection operation ``\lstinline@.@'':
     2360\begin{lstlisting}
     2361s.0 = 0;        // ambiguity with floating constant .0
     2362s.1 = 1;        // ambiguity with floating constant .1
     2363\end{lstlisting}
     2364To make this work, a space is required after the field selection:
     2365\begin{lstlisting}
     2366®s.§\textvisiblespace§0® = 0;
     2367®s.§\textvisiblespace§1® = 1;
     2368\end{lstlisting}
     2369While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
     2370Like the \CC lexical problem with closing template-syntax, e.g, \lstinline@Foo<Bar<int®>>®@, this issue can be solved with a more powerful lexer/parser.
     2371
     2372There are several ambiguous cases with operator identifiers, e.g., \lstinline@int *?*?()@, where the string \lstinline@*?*?@ can be lexed as \lstinline@*@/\lstinline@?*?@ or \lstinline@*?@/\lstinline@*?@.
     2373Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., \lstinline@*i@, users will be annoyed if they cannot do this with respect to operator identifiers.
     2374Even with this special hack, there are 5 general cases that cannot be handled.
     2375The first case is for the function-call identifier \lstinline@?()@:
     2376\begin{lstlisting}
     2377int *§\textvisiblespace§?()();  // declaration: space required after '*'
     2378*§\textvisiblespace§?()();              // expression: space required after '*'
     2379\end{lstlisting}
     2380Without the space, the string \lstinline@*?()@ is ambiguous without N character look ahead;
     2381it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument/parameter list.
     2382
     2383The 4 remaining cases occur in expressions:
     2384\begin{lstlisting}
     2385i++§\textvisiblespace§?i:0;             // space required before '?'
     2386i--§\textvisiblespace§?i:0;             // space required before '?'
     2387i§\textvisiblespace§?++i:0;             // space required after '?'
     2388i§\textvisiblespace§?--i:0;             // space required after '?'
     2389\end{lstlisting}
     2390In the first two cases, the string \lstinline@i++?@ is ambiguous, where this string can be lexed as \lstinline@i@ / \lstinline@++?@ or \lstinline@i++@ / \lstinline@?@;
     2391it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
     2392In the second two cases, the string \lstinline@?++x@ is ambiguous, where this string can be lexed as \lstinline@?++@ / \lstinline@x@ or \lstinline@?@ / y\lstinline@++x@;
     2393it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
    26542394
    26552395
     
    26762416
    26772417task creates a type with implicit locking, separate stack, and a thread
     2418
    26782419
    26792420\subsection{Monitors}
     
    35763317
    35773318
    3578 \subsection{Comparing Key Features of \CFA}
     3319\subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
    35793320
    35803321
     
    37753516\multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}}   \\
    37763517\hline
    3777 \begin{lstlisting}
     3518\begin{lstlisting}[boxpos=t]
    37783519extern "C" {
    37793520#include <sys/types.h>
     
    37823523}
    37833524size_t fileSize( const char *path ) {
    3784         stat s;
     3525        struct stat s;
    37853526        stat(path, &s);
    37863527        return s.st_size;
     
    37883529\end{lstlisting}
    37893530&
    3790 \begin{lstlisting}
     3531\begin{lstlisting}[boxpos=t]
    37913532/*
    37923533#cgo
     
    38073548\end{lstlisting}
    38083549&
    3809 \begin{lstlisting}
     3550\begin{lstlisting}[boxpos=t]
    38103551use libc::{c_int, size_t};
    3811 
    3812 // The following declarations are
    38133552// translated from sys/stat.h
    38143553#[repr(C)]
     
    38183557        ...
    38193558}
    3820 
    38213559#[link(name = "libc")]
    38223560extern {
     
    38243562        buf: *mut stat_t) -> c_int;
    38253563}
    3826 
    38273564fn fileSize(path: *const u8) -> size_t
    38283565{
    38293566        unsafe {
    3830         let mut buf: stat_t = uninit();
    3831         stat(path, &mut buf);
    3832         buf.st_size
     3567                let mut buf: stat_t = uninit();
     3568                stat(path, &mut buf);
     3569                buf.st_size
    38333570        }
    38343571}
     
    39533690
    39543691
    3955 \subsubsection{Modules/Packages}
     3692\begin{comment}
     3693\subsubsection{Modules / Packages}
    39563694
    39573695\begin{lstlisting}
     
    40323770}
    40333771\end{lstlisting}
     3772\end{comment}
     3773
    40343774
    40353775\subsubsection{Parallel Tasks}
     
    41873927\end{flushleft}
    41883928
     3929\lstset{basicstyle=\sf\relsize{-1}}
     3930
     3931
    41893932\subsection{Summary of Language Comparison}
    41903933
    41913934
    4192 \subsubsection{\CC}
     3935\subsubsection[C++]{\CC}
    41933936
    41943937\CC is a general-purpose programming language.
     
    42553998
    42563999
     4000\appendix
     4001
     4002
     4003\section{Incompatible}
     4004
     4005The following incompatibles exist between C and \CFA, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
     4006
     4007\begin{enumerate}
     4008\item
     4009Change type of character literal \lstinline@int@ to \lstinline@char@.
     4010This change allows overloading differentiation argument type matching, e.g.:
     4011\begin{lstlisting}
     4012int function( int i );
     4013int function( char c );
     4014function( 'x' );
     4015\end{lstlisting}
     4016It is preferable that this call match the second version of function rather than the first. \\
     4017Effect on original feature: Change to semantics of well-defined feature. ISO C programs which depend on
     4018\begin{lstlisting}
     4019sizeof('x') == sizeof(int)
     4020\end{lstlisting}
     4021will not work the same as C++ programs. \\
     4022Difficulty of converting: Simple. \\
     4023How widely used: Programs which depend upon sizeof('x') are probably rare.
     4024
     4025\item
     4026Change: String literals made \lstinline@const@ \\
     4027The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
     4028The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
     4029Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
     4030Effect on original feature: Change to semantics of well-defined feature. \\
     4031Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
     4032The most common cases are handled by a new but deprecated standard conversion:
     4033\begin{lstlisting}
     4034char* p = "abc"; // valid in C, deprecated in C++
     4035char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
     4036\end{lstlisting}
     4037How widely used: Programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are probably rare.
     4038
     4039\item
     4040Change: C++ does not have \emph{tentative definitions} as in C.
     4041E.g., at file scope,
     4042\begin{lstlisting}
     4043int i;
     4044int i;
     4045\end{lstlisting}
     4046is valid in C, invalid in C++.
     4047This makes it impossible to define mutually referential file-local static
     4048objects, if initializers are restricted to the syntactic forms of C. For example,
     4049\begin{lstlisting}
     4050struct X { int i; struct X *next; };
     4051static struct X a;
     4052static struct X b = { 0, &a };
     4053static struct X a = { 1, &b };
     4054\end{lstlisting}
     4055Rationale: This avoids having different initialization rules for builtin types and userdefined types.
     4056Effect on original feature: Deletion of semantically welldefined feature. \\
     4057Difficulty of converting: Semantic transformation.
     4058In C++, the initializer for one of a set of mutuallyreferential filelocal static objects must invoke a function call to achieve the initialization.
     4059How widely used: Seldom.
     4060
     4061\item
     4062Change: A struct is a scope in C++, not in C \\
     4063Rationale: Class scope is crucial to C++, and a struct is a class. \\
     4064Effect on original feature: Change to semantics of well-defined feature. \\
     4065Difficulty of converting: Semantic transformation. \\
     4066How widely used: C programs use struct extremely frequently, but the change is only noticeable when struct, enumeration, or enumerator names are referred to outside the struct.
     4067The latter is probably rare.
     4068
     4069\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
     4070Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
     4071Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
     4072
     4073\item
     4074Change: In C++, the name of a nested class is local to its enclosing class.
     4075In C the name of the nested class belongs to the same scope as the name of the outermost enclosing class
     4076Example:
     4077\begin{lstlisting}
     4078struct X {
     4079struct Y { /* ... */ } y;
     4080};
     4081struct Y yy; // valid C, invalid C++
     4082\end{lstlisting}
     4083Rationale: C++ classes have member functions which require that classes establish scopes.
     4084The C rule would leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining locality within a class. A coherent set of scope rules for C++ based on the C rule would be very complicated and C++ programmers would be unable to predict reliably the meanings of nontrivial examples involving nested or local functions.
     4085Effect on original feature: Change of semantics of welldefined feature.
     4086Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
     4087\begin{lstlisting}
     4088struct Y; // struct Y and struct X are at the same scope
     4089struct X {
     4090struct Y { /* ... */ } y;
     4091};
     4092\end{lstlisting}
     4093All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.
     4094Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
     4095How widely used: Seldom.
     4096\end{enumerate}
     4097
     4098
     4099\section{I/O Library}
     4100\label{s:IOLibrary}
     4101\index{input/output library}
     4102
     4103The goal for \CFA I/O is to make I/O as simple as possible for the general case, while fully supporting polmorphism and user defined types in a consistent way.
     4104The general case is printing out a sequence of variables separated by whitespace.
     4105\begin{quote2}
     4106\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
     4107\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{\CC}}      \\
     4108\begin{lstlisting}
     4109int x = 0, y = 1, z = 2;
     4110®sout® ®|® x ®|® y ®|® z ®| endl®;
     4111\end{lstlisting}
     4112&
     4113\begin{lstlisting}
     4114
     4115cout << x << " " << y << " " << z << endl;
     4116\end{lstlisting}
     4117\end{tabular}
     4118\end{quote2}
     4119The \CFA form is half as many characters, and is similar to \Index{Python} I/O with respect to implicit separators.
     4120
     4121The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment.
     4122Therefore, fewer output expressions require parenthesis.
     4123\begin{quote2}
     4124\begin{tabular}{@{}ll@{}}
     4125\textbf{\CFA:}
     4126&
     4127\begin{lstlisting}
     4128sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
     4129\end{lstlisting}
     4130\\
     4131\textbf{\CC:}
     4132&
     4133\begin{lstlisting}
     4134cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
     4135\end{lstlisting}
     4136\end{tabular}
     4137\end{quote2}
     4138Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, although data flows in the opposite direction.
     4139
     4140The implicit seperator\index{I/O separator} character (space/blank) is a separator not a terminator.
     4141The rules for implicitly adding the separator are:
     4142\begin{enumerate}
     4143\item
     4144A seperator does not appear at the start or end of a line.
     4145\begin{lstlisting}[belowskip=0pt]
     4146sout | 1 | 2 | 3 | endl;
     4147\end{lstlisting}
     4148\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     41491 2 3
     4150\end{lstlisting}
     4151\item
     4152A seperator does not appear before or after a character literal or variable.
     4153\begin{lstlisting}
     4154sout | '1' | '2' | '3' | endl;
     4155123
     4156\end{lstlisting}
     4157\item
     4158A seperator does not appear before or after a null (empty) C string
     4159\begin{lstlisting}
     4160sout | 1 | "" | 2 | "" | 3 | endl;
     4161123
     4162\end{lstlisting}
     4163which is a local mechanism to disable insertion of the separator character.
     4164\item
     4165A seperator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{$£¥¡¿«@
     4166%$
     4167\begin{lstlisting}[mathescape=off]
     4168sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
     4169\end{lstlisting}
     4170%$
     4171\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4172x (1 x [2 x {3 x $4 x £5 x ¥6 x ¡7 x ¿8 x «9
     4173\end{lstlisting}
     4174%$
     4175\item
     4176A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline@,.:;!?)]}%¢»@
     4177\begin{lstlisting}[belowskip=0pt]
     4178sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
     4179         | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
     4180\end{lstlisting}
     4181\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     41821, x 2. x 3: x 4; x 5! x 6? x 7) x 8] x 9} x 10% x 11¢ 12»
     4183\end{lstlisting}
     4184\item
     4185A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@
     4186\begin{lstlisting}[belowskip=0pt]
     4187sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
     4188\end{lstlisting}
     4189\begin{lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
     4190x`1`x'2'x"3"x x 4 x x   1       x
     4191\end{lstlisting}
     4192\end{enumerate}
     4193The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
     4194\begin{lstlisting}[mathescape=off,belowskip=0pt]
     4195sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
     4196\end{lstlisting}
     4197\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4198 1 2 3
     4199\end{lstlisting}
     4200\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4201sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
     4202\end{lstlisting}
     4203\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     420412 3
     4205\end{lstlisting}
     4206\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4207sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
     4208\end{lstlisting}
     4209\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4210123
     4211\end{lstlisting}
     4212\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4213sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
     4214\end{lstlisting}
     4215\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     42161 23
     4217\end{lstlisting}
     4218\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
     4219sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
     4220\end{lstlisting}
     4221\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     4222 1 2 3
     4223\end{lstlisting}
     4224\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
     4225sepSet( sout, ", $" );                                          // change separator from " " to ", $"
     4226sout | 1 | 2 | 3 | endl;
     4227\end{lstlisting}
     4228%$
     4229\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]
     42301, $2, $3
     4231\end{lstlisting}
     4232%$
     4233\begin{comment}
     4234#include <fstream>
     4235
     4236int main() {
     4237        int x = 3, y = 5, z = 7;
     4238        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
     4239        sout | 1 | 2 | 3 | endl;
     4240        sout | '1' | '2' | '3' | endl;
     4241        sout | 1 | "" | 2 | "" | 3 | endl;
     4242        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
     4243        sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
     4244                 | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
     4245        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl;
     4246        sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
     4247        sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
     4248        sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
     4249        sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
     4250        sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
     4251        sepSet( sout, ", $" );                                          // change separator from " " to ", $"
     4252        sout | 1 | 2 | 3 | endl;
     4253
     4254}
     4255
     4256// Local Variables: //
     4257// tab-width: 4 //
     4258// End: //
     4259\end{comment}
     4260%$
     4261
     4262
     4263\section{Standard Library}
     4264\label{s:StandardLibrary}
     4265
     4266The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitly polymorphic versions.
     4267
     4268
     4269\subsection{malloc}
     4270
     4271\begin{lstlisting}
     4272forall( otype T ) T * malloc( void );§\indexc{malloc}§
     4273forall( otype T ) T * malloc( char fill );
     4274forall( otype T ) T * malloc( T * ptr, size_t size );
     4275forall( otype T ) T * malloc( T * ptr, size_t size, unsigned char fill );
     4276forall( otype T ) T * calloc( size_t nmemb );§\indexc{calloc}§
     4277forall( otype T ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
     4278forall( otype T ) T * realloc( T * ptr, size_t size, unsigned char fill );
     4279
     4280forall( otype T ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
     4281forall( otype T ) T * memalign( size_t alignment );             // deprecated
     4282forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
     4283
     4284forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
     4285forall( otype T ) T * memset( T * ptr );                                // remove when default value available
     4286\end{lstlisting}
     4287
     4288
     4289\subsection{ato / strto}
     4290
     4291\begin{lstlisting}
     4292int ato( const char * ptr );§\indexc{ato}§
     4293unsigned int ato( const char * ptr );
     4294long int ato( const char * ptr );
     4295unsigned long int ato( const char * ptr );
     4296long long int ato( const char * ptr );
     4297unsigned long long int ato( const char * ptr );
     4298float ato( const char * ptr );
     4299double ato( const char * ptr );
     4300long double ato( const char * ptr );
     4301float _Complex ato( const char * ptr );
     4302double _Complex ato( const char * ptr );
     4303long double _Complex ato( const char * ptr );
     4304
     4305int strto( const char * sptr, char ** eptr, int base );
     4306unsigned int strto( const char * sptr, char ** eptr, int base );
     4307long int strto( const char * sptr, char ** eptr, int base );
     4308unsigned long int strto( const char * sptr, char ** eptr, int base );
     4309long long int strto( const char * sptr, char ** eptr, int base );
     4310unsigned long long int strto( const char * sptr, char ** eptr, int base );
     4311float strto( const char * sptr, char ** eptr );
     4312double strto( const char * sptr, char ** eptr );
     4313long double strto( const char * sptr, char ** eptr );
     4314float _Complex strto( const char * sptr, char ** eptr );
     4315double _Complex strto( const char * sptr, char ** eptr );
     4316long double _Complex strto( const char * sptr, char ** eptr );
     4317\end{lstlisting}
     4318
     4319
     4320\subsection{bsearch / qsort}
     4321
     4322\begin{lstlisting}
     4323forall( otype T | { int ?<?( T, T ); } )
     4324T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§
     4325
     4326forall( otype T | { int ?<?( T, T ); } )
     4327void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
     4328\end{lstlisting}
     4329
     4330
     4331\subsection{abs}
     4332
     4333\begin{lstlisting}
     4334char abs( char );§\indexc{abs}§
     4335int abs( int );
     4336long int abs( long int );
     4337long long int abs( long long int );
     4338float abs( float );
     4339double abs( double );
     4340long double abs( long double );
     4341float abs( float _Complex );
     4342double abs( double _Complex );
     4343long double abs( long double _Complex );
     4344\end{lstlisting}
     4345
     4346
     4347\subsection{random}
     4348
     4349\begin{lstlisting}
     4350void rand48seed( long int s );§\indexc{rand48seed}§
     4351char rand48();§\indexc{rand48}§
     4352int rand48();
     4353unsigned int rand48();
     4354long int rand48();
     4355unsigned long int rand48();
     4356float rand48();
     4357double rand48();
     4358float _Complex rand48();
     4359double _Complex rand48();
     4360long double _Complex rand48();
     4361\end{lstlisting}
     4362
     4363
     4364\subsection{min / max / swap}
     4365
     4366\begin{lstlisting}
     4367forall( otype T | { int ?<?( T, T ); } )
     4368T min( const T t1, const T t2 );§\indexc{min}§
     4369
     4370forall( otype T | { int ?>?( T, T ); } )
     4371T max( const T t1, const T t2 );§\indexc{max}§
     4372
     4373forall( otype T )
     4374void swap( T * t1, T * t2 );§\indexc{swap}§
     4375\end{lstlisting}
     4376
     4377
     4378\section{Math Library}
     4379\label{s:Math Library}
     4380
     4381The goal of the \CFA math-library is to wrap many of the existing C math library-routines that are explicitly polymorphic into implicitly polymorphic versions.
     4382
     4383
     4384\subsection{General}
     4385
     4386\begin{lstlisting}
     4387float fabs( float );§\indexc{fabs}§
     4388double fabs( double );
     4389long double fabs( long double );
     4390float cabs( float _Complex );
     4391double cabs( double _Complex );
     4392long double cabs( long double _Complex );
     4393
     4394float ?%?( float, float );§\indexc{fmod}§
     4395float fmod( float, float );
     4396double ?%?( double, double );
     4397double fmod( double, double );
     4398long double ?%?( long double, long double );
     4399long double fmod( long double, long double );
     4400
     4401float remainder( float, float );§\indexc{remainder}§
     4402double remainder( double, double );
     4403long double remainder( long double, long double );
     4404
     4405[ int, float ] remquo( float, float );§\indexc{remquo}§
     4406float remquo( float, float, int * );
     4407[ int, double ] remquo( double, double );
     4408double remquo( double, double, int * );
     4409[ int, long double ] remquo( long double, long double );
     4410long double remquo( long double, long double, int * );
     4411
     4412[ int, float ] div( float, float );                                             // alternative name for remquo
     4413float div( float, float, int * );§\indexc{div}§
     4414[ int, double ] div( double, double );
     4415double div( double, double, int * );
     4416[ int, long double ] div( long double, long double );
     4417long double div( long double, long double, int * );
     4418
     4419float fma( float, float, float );§\indexc{fma}§
     4420double fma( double, double, double );
     4421long double fma( long double, long double, long double );
     4422
     4423float fdim( float, float );§\indexc{fdim}§
     4424double fdim( double, double );
     4425long double fdim( long double, long double );
     4426
     4427float nan( const char * );§\indexc{nan}§
     4428double nan( const char * );
     4429long double nan( const char * );
     4430\end{lstlisting}
     4431
     4432
     4433\subsection{Exponential}
     4434
     4435\begin{lstlisting}
     4436float exp( float );§\indexc{exp}§
     4437double exp( double );
     4438long double exp( long double );
     4439float _Complex exp( float _Complex );
     4440double _Complex exp( double _Complex );
     4441long double _Complex exp( long double _Complex );
     4442
     4443float exp2( float );§\indexc{exp2}§
     4444double exp2( double );
     4445long double exp2( long double );
     4446float _Complex exp2( float _Complex );
     4447double _Complex exp2( double _Complex );
     4448long double _Complex exp2( long double _Complex );
     4449
     4450float expm1( float );§\indexc{expm1}§
     4451double expm1( double );
     4452long double expm1( long double );
     4453
     4454float log( float );§\indexc{log}§
     4455double log( double );
     4456long double log( long double );
     4457float _Complex log( float _Complex );
     4458double _Complex log( double _Complex );
     4459long double _Complex log( long double _Complex );
     4460
     4461float log2( float );§\indexc{log2}§
     4462double log2( double );
     4463long double log2( long double );
     4464float _Complex log2( float _Complex );
     4465double _Complex log2( double _Complex );
     4466long double _Complex log2( long double _Complex );
     4467
     4468float log10( float );§\indexc{log10}§
     4469double log10( double );
     4470long double log10( long double );
     4471float _Complex log10( float _Complex );
     4472double _Complex log10( double _Complex );
     4473long double _Complex log10( long double _Complex );
     4474
     4475float log1p( float );§\indexc{log1p}§
     4476double log1p( double );
     4477long double log1p( long double );
     4478
     4479int ilogb( float );§\indexc{ilogb}§
     4480int ilogb( double );
     4481int ilogb( long double );
     4482
     4483float logb( float );§\indexc{logb}§
     4484double logb( double );
     4485long double logb( long double );
     4486\end{lstlisting}
     4487
     4488
     4489\subsection{Power}
     4490
     4491\begin{lstlisting}
     4492float sqrt( float );§\indexc{sqrt}§
     4493double sqrt( double );
     4494long double sqrt( long double );
     4495float _Complex sqrt( float _Complex );
     4496double _Complex sqrt( double _Complex );
     4497long double _Complex sqrt( long double _Complex );
     4498
     4499float cbrt( float );§\indexc{cbrt}§
     4500double cbrt( double );
     4501long double cbrt( long double );
     4502
     4503float hypot( float, float );§\indexc{hypot}§
     4504double hypot( double, double );
     4505long double hypot( long double, long double );
     4506
     4507float pow( float, float );§\indexc{pow}§
     4508double pow( double, double );
     4509long double pow( long double, long double );
     4510float _Complex pow( float _Complex, float _Complex );
     4511double _Complex pow( double _Complex, double _Complex );
     4512long double _Complex pow( long double _Complex, long double _Complex );
     4513\end{lstlisting}
     4514
     4515
     4516\subsection{Trigonometric}
     4517
     4518\begin{lstlisting}
     4519float sin( float );§\indexc{sin}§
     4520double sin( double );
     4521long double sin( long double );
     4522float _Complex sin( float _Complex );
     4523double _Complex sin( double _Complex );
     4524long double _Complex sin( long double _Complex );
     4525
     4526float cos( float );§\indexc{cos}§
     4527double cos( double );
     4528long double cos( long double );
     4529float _Complex cos( float _Complex );
     4530double _Complex cos( double _Complex );
     4531long double _Complex cos( long double _Complex );
     4532
     4533float tan( float );§\indexc{tan}§
     4534double tan( double );
     4535long double tan( long double );
     4536float _Complex tan( float _Complex );
     4537double _Complex tan( double _Complex );
     4538long double _Complex tan( long double _Complex );
     4539
     4540float asin( float );§\indexc{asin}§
     4541double asin( double );
     4542long double asin( long double );
     4543float _Complex asin( float _Complex );
     4544double _Complex asin( double _Complex );
     4545long double _Complex asin( long double _Complex );
     4546
     4547float acos( float );§\indexc{acos}§
     4548double acos( double );
     4549long double acos( long double );
     4550float _Complex acos( float _Complex );
     4551double _Complex acos( double _Complex );
     4552long double _Complex acos( long double _Complex );
     4553
     4554float atan( float );§\indexc{atan}§
     4555double atan( double );
     4556long double atan( long double );
     4557float _Complex atan( float _Complex );
     4558double _Complex atan( double _Complex );
     4559long double _Complex atan( long double _Complex );
     4560
     4561float atan2( float, float );§\indexc{atan2}§
     4562double atan2( double, double );
     4563long double atan2( long double, long double );
     4564
     4565float atan( float, float );                                                             // alternative name for atan2
     4566double atan( double, double );§\indexc{atan}§
     4567long double atan( long double, long double );
     4568\end{lstlisting}
     4569
     4570
     4571\subsection{Hyperbolic}
     4572
     4573\begin{lstlisting}
     4574float sinh( float );§\indexc{sinh}§
     4575double sinh( double );
     4576long double sinh( long double );
     4577float _Complex sinh( float _Complex );
     4578double _Complex sinh( double _Complex );
     4579long double _Complex sinh( long double _Complex );
     4580
     4581float cosh( float );§\indexc{cosh}§
     4582double cosh( double );
     4583long double cosh( long double );
     4584float _Complex cosh( float _Complex );
     4585double _Complex cosh( double _Complex );
     4586long double _Complex cosh( long double _Complex );
     4587
     4588float tanh( float );§\indexc{tanh}§
     4589double tanh( double );
     4590long double tanh( long double );
     4591float _Complex tanh( float _Complex );
     4592double _Complex tanh( double _Complex );
     4593long double _Complex tanh( long double _Complex );
     4594
     4595float asinh( float );§\indexc{asinh}§
     4596double asinh( double );
     4597long double asinh( long double );
     4598float _Complex asinh( float _Complex );
     4599double _Complex asinh( double _Complex );
     4600long double _Complex asinh( long double _Complex );
     4601
     4602float acosh( float );§\indexc{acosh}§
     4603double acosh( double );
     4604long double acosh( long double );
     4605float _Complex acosh( float _Complex );
     4606double _Complex acosh( double _Complex );
     4607long double _Complex acosh( long double _Complex );
     4608
     4609float atanh( float );§\indexc{atanh}§
     4610double atanh( double );
     4611long double atanh( long double );
     4612float _Complex atanh( float _Complex );
     4613double _Complex atanh( double _Complex );
     4614long double _Complex atanh( long double _Complex );
     4615\end{lstlisting}
     4616
     4617
     4618\subsection{Error / Gamma}
     4619
     4620\begin{lstlisting}
     4621float erf( float );§\indexc{erf}§
     4622double erf( double );
     4623long double erf( long double );
     4624float _Complex erf( float _Complex );
     4625double _Complex erf( double _Complex );
     4626long double _Complex erf( long double _Complex );
     4627
     4628float erfc( float );§\indexc{erfc}§
     4629double erfc( double );
     4630long double erfc( long double );
     4631float _Complex erfc( float _Complex );
     4632double _Complex erfc( double _Complex );
     4633long double _Complex erfc( long double _Complex );
     4634
     4635float lgamma( float );§\indexc{lgamma}§
     4636double lgamma( double );
     4637long double lgamma( long double );
     4638float lgamma( float, int * );
     4639double lgamma( double, int * );
     4640long double lgamma( long double, int * );
     4641
     4642float tgamma( float );§\indexc{tgamma}§
     4643double tgamma( double );
     4644long double tgamma( long double );
     4645\end{lstlisting}
     4646
     4647
     4648\subsection{Nearest Integer}
     4649
     4650\begin{lstlisting}
     4651float floor( float );§\indexc{floor}§
     4652double floor( double );
     4653long double floor( long double );
     4654
     4655float ceil( float );§\indexc{ceil}§
     4656double ceil( double );
     4657long double ceil( long double );
     4658
     4659float trunc( float );§\indexc{trunc}§
     4660double trunc( double );
     4661long double trunc( long double );
     4662
     4663float rint( float );§\indexc{rint}§
     4664long double rint( long double );
     4665long int rint( float );
     4666long int rint( double );
     4667long int rint( long double );
     4668long long int rint( float );
     4669long long int rint( double );
     4670long long int rint( long double );
     4671
     4672long int lrint( float );§\indexc{lrint}§
     4673long int lrint( double );
     4674long int lrint( long double );
     4675long long int llrint( float );
     4676long long int llrint( double );
     4677long long int llrint( long double );
     4678
     4679float nearbyint( float );§\indexc{nearbyint}§
     4680double nearbyint( double );
     4681long double nearbyint( long double );
     4682
     4683float round( float );§\indexc{round}§
     4684long double round( long double );
     4685long int round( float );
     4686long int round( double );
     4687long int round( long double );
     4688long long int round( float );
     4689long long int round( double );
     4690long long int round( long double );
     4691
     4692long int lround( float );§\indexc{lround}§
     4693long int lround( double );
     4694long int lround( long double );
     4695long long int llround( float );
     4696long long int llround( double );
     4697long long int llround( long double );
     4698\end{lstlisting}
     4699
     4700
     4701\subsection{Manipulation}
     4702
     4703\begin{lstlisting}
     4704float copysign( float, float );§\indexc{copysign}§
     4705double copysign( double, double );
     4706long double copysign( long double, long double );
     4707
     4708float frexp( float, int * );§\indexc{frexp}§
     4709double frexp( double, int * );
     4710long double frexp( long double, int * );
     4711
     4712float ldexp( float, int );§\indexc{ldexp}§
     4713double ldexp( double, int );
     4714long double ldexp( long double, int );
     4715
     4716[ float, float ] modf( float );§\indexc{modf}§
     4717float modf( float, float * );
     4718[ double, double ] modf( double );
     4719double modf( double, double * );
     4720[ long double, long double ] modf( long double );
     4721long double modf( long double, long double * );
     4722
     4723float nextafter( float, float );§\indexc{nextafter}§
     4724double nextafter( double, double );
     4725long double nextafter( long double, long double );
     4726
     4727float nexttoward( float, long double );§\indexc{nexttoward}§
     4728double nexttoward( double, long double );
     4729long double nexttoward( long double, long double );
     4730
     4731float scalbn( float, int );§\indexc{scalbn}§
     4732double scalbn( double, int );
     4733long double scalbn( long double, int );
     4734
     4735float scalbln( float, long int );§\indexc{scalbln}§
     4736double scalbln( double, long int );
     4737long double scalbln( long double, long int );
     4738\end{lstlisting}
     4739
     4740
     4741\section{Rational Numbers}
     4742\label{s:RationalNumbers}
     4743
     4744Rational numbers are numbers written as a ratio, i.e., as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
     4745When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
     4746
     4747\begin{lstlisting}
     4748// implementation
     4749struct Rational {§\indexc{Rational}§
     4750        long int numerator, denominator;                                        // invariant: denominator > 0
     4751}; // Rational
     4752
     4753// constants
     4754extern struct Rational 0;
     4755extern struct Rational 1;
     4756
     4757// constructors
     4758Rational rational();
     4759Rational rational( long int n );
     4760Rational rational( long int n, long int d );
     4761
     4762// getter/setter for numerator/denominator
     4763long int numerator( Rational r );
     4764long int numerator( Rational r, long int n );
     4765long int denominator( Rational r );
     4766long int denominator( Rational r, long int d );
     4767
     4768// comparison
     4769int ?==?( Rational l, Rational r );
     4770int ?!=?( Rational l, Rational r );
     4771int ?<?( Rational l, Rational r );
     4772int ?<=?( Rational l, Rational r );
     4773int ?>?( Rational l, Rational r );
     4774int ?>=?( Rational l, Rational r );
     4775
     4776// arithmetic
     4777Rational -?( Rational r );
     4778Rational ?+?( Rational l, Rational r );
     4779Rational ?-?( Rational l, Rational r );
     4780Rational ?*?( Rational l, Rational r );
     4781Rational ?/?( Rational l, Rational r );
     4782
     4783// conversion
     4784double widen( Rational r );
     4785Rational narrow( double f, long int md );
     4786
     4787// I/O
     4788forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * );
     4789forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational );
     4790\end{lstlisting}
     4791
     4792
    42574793\bibliographystyle{plain}
    4258 \bibliography{/usr/local/bibliographies/pl.bib}
     4794\bibliography{cfa}
    42594795
    42604796
  • src/CodeGen/CodeGenerator.cc

    r1f6e009 r1048b31  
    455455
    456456        void CodeGenerator::visit( UntypedOffsetofExpr *offsetofExpr ) {
    457                 assert( false );
     457                assert( false && "UntypedOffsetofExpr should not reach code generation" );
    458458        }
    459459
     
    464464                output << ", " << mangleName( offsetofExpr->get_member() );
    465465                output << ")";
     466        }
     467
     468        void CodeGenerator::visit( OffsetPackExpr *offsetPackExpr ) {
     469                assert( false && "OffsetPackExpr should not reach code generation" );
    466470        }
    467471