Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/refrat/refrat.tex

    r4096de0 ra188b16  
    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 : Wed Jun 22 14:18:30 2016
    14 %% Update Count     : 77
    15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    16 
    171% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    18 
    19 % inline code ©...© (copyright symbol) emacs: C-q M-)
    20 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
    21 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    22 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    23 % LaTex escape §...§ (section symbol) emacs: C-q M-'
    24 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    25 % math escape $...$ (dollar symbol)
    262
    273\documentclass[openright,twoside]{report}
    … …  
    295
    306% Latex packages used in the document.
    31 \usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
    32 \usepackage{textcomp}
    33 \usepackage[latin1]{inputenc}
    34 \usepackage{fullpage,times,comment}
    35 \usepackage{epic,eepic}
    36 \usepackage{upquote}                                                                    % switch curled `'" to straight
     7
     8\usepackage{fullpage,times}
    379\usepackage{xspace}
    38 \usepackage{varioref}                                                                   % extended references
    39 \usepackage{listings}                                                                   % format program code
    40 \usepackage[flushmargin]{footmisc}                                              % support label/reference in footnote
    41 \usepackage{latexsym}                                   % \Box glyph
    42 \usepackage{mathptmx}                                   % better math font with "times"
    43 \usepackage[usenames]{color}
     10\usepackage{varioref}
     11\usepackage{listings}
     12\usepackage{latexsym}                                   % \Box
     13\usepackage{mathptmx}                                   % better math font with "times"
    4414\usepackage[pagewise]{lineno}
    4515\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    46 \input{common}                                          % bespoke macros used in the document
    4716\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    4817\usepackage{breakurl}
    49 \renewcommand{\UrlFont}{\small\sf}
    50 
    51 \setlength{\topmargin}{-0.45in}                                                 % move running title into header
    52 \setlength{\headsep}{0.25in}
     18\urlstyle{sf}
    5319
    5420%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    5622% Names used in the document.
    5723
    58 \newcommand{\Version}{1.0.0}
    59 
    60 \newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
    61 \newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
    62 \newcommand{\R}[1]{\Textbf{#1}}
    63 \newcommand{\B}[1]{{\Textbf[blue]{#1}}}
    64 \newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
     24\newcommand{\CFA}{Cforall\xspace}               % set language text name
     25\newcommand{\CFAA}{C$\forall$\xspace}   % set language symbolic name
     26\newcommand{\CC}{C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
     27\def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
    6528
    6629%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6730
    68 \setcounter{secnumdepth}{3}                             % number subsubsections
    69 \setcounter{tocdepth}{3}                                % subsubsections in table of contents
     31% Specialized macros used in the document.
     32
     33\newcommand{\italic}[1]{\emph{\hyperpage{#1}}}
     34\newcommand{\definition}[1]{\textbf{\hyperpage{#1}}}
     35\newcommand{\see}[1]{\emph{see} #1}
     36
     37\makeatletter
     38% Define some commands that produce formatted index entries suitable for cross-references.
     39% ``\spec'' produces entries for specifications of entities.  ``\impl'' produces entries for their
     40% implementations, and ``\use'' for their uses.
     41
     42%  \newcommand{\bold}[1]{{\bf #1}}
     43%  \def\spec{\@bsphack\begingroup
     44%             \def\protect##1{\string##1\space}\@sanitize
     45%             \@wrxref{|bold}}
     46\def\impl{\@bsphack\begingroup
     47          \def\protect##1{\string##1\space}\@sanitize
     48          \@wrxref{|definition}}
     49\newcommand{\indexcode}[1]{{\lstinline$#1$}}
     50\def\use{\@bsphack\begingroup
     51         \def\protect##1{\string##1\space}\@sanitize
     52         \@wrxref{|hyperpage}}
     53\def\@wrxref#1#2{\let\thepage\relax
     54    \xdef\@gtempa{\write\@indexfile{\string
     55    \indexentry{#2@{\lstinline$#2$}#1}{\thepage}}}\endgroup\@gtempa
     56    \if@nobreak \ifvmode\nobreak\fi\fi\@esphack}
     57\makeatother
     58%\newcommand{\use}[1]{\index{#1@{\lstinline$#1$}}}
     59%\newcommand{\impl}[1]{\index{\protect#1@{\lstinline$\protect#1$}|definition}}
     60
     61\newcommand{\define}[1]{\emph{#1\/}\index{#1}}
     62\newenvironment{rationale}{%
     63  \begin{quotation}\noindent$\Box$\enspace
     64}{%
     65  \hfill\enspace$\Box$\end{quotation}
     66}%
     67\newcommand{\rewrite}{\(\Rightarrow\)}
     68\newcommand{\rewriterules}{\paragraph{Rewrite Rules}\hskip1em\par\noindent}
     69\newcommand{\examples}{\paragraph{Examples}\hskip1em\par\noindent}
     70\newcommand{\semantics}{\paragraph{Semantics}\hskip1em\par\noindent}
     71\newcommand{\constraints}{\paragraph{Constraints}\hskip1em\par\noindent}
     72\newenvironment{predefined}{%
     73  \paragraph{Predefined Identifiers}%
     74%  \begin{code}%
     75}{%
     76%  \end{code}
     77}%
     78
     79\def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]}
     80\let\endsyntax=\endtrivlist
     81\newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
     82\newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
     83\newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
     84\newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
     85\newcommand{\opt}{$_{opt}$\ }
     86
     87\renewcommand{\reftextfaceafter}{\unskip}
     88\renewcommand{\reftextfacebefore}{\unskip}
     89\renewcommand{\reftextafter}{\unskip}
     90\renewcommand{\reftextbefore}{\unskip}
     91\renewcommand{\reftextfaraway}[1]{\unskip, p.~\pageref{#1}}
     92\renewcommand{\reftextpagerange}[2]{\unskip, pp.~\pageref{#1}--\pageref{#2}}
     93\newcommand{\VRef}[2][Section]{\ifx#1\@empty\else{#1}\nobreakspace\fi\vref{#2}}
     94\newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
     95
     96% replace/adjust characters that look bad in sanserif
     97\makeatletter
     98\lst@CCPutMacro
     99\lst@ProcessOther{"2D}{\lst@ttfamily{-{}}{{\ttfamily\upshape -}}} % replace minus
     100\lst@ProcessOther{"3C}{\lst@ttfamily{<}{\texttt{<}}} % replace less than
     101\lst@ProcessOther{"3E}{\lst@ttfamily{<}{\texttt{>}}} % replace greater than
     102\lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % circumflex
     103\lst@ProcessLetter{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
     104%\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
     105\lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % lower tilde
     106\@empty\z@\@empty
     107
     108\newcommand{\Index}{\@ifstar\@sIndex\@Index}
     109\newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
     110\newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
     111\makeatother
     112
     113\lstdefinelanguage{CFA}[ANSI]{C}%
     114  {morekeywords={asm,_Atomic,catch,catchResume,choose,_Complex,context,disable,dtype,enable,
     115        fallthru,finally,forall,ftype,_Imaginary,lvalue,restrict,throw,throwResume,try,type,},
     116}
     117
     118\lstset{
     119language=CFA,
     120columns=fullflexible,
     121basicstyle=\sf\small,
     122tabsize=4,
     123xleftmargin=\parindent,
     124escapechar=@,
     125%fancyvrb=true,
     126%showtabs=true,
     127keepspaces=true,
     128showtabs=true,
     129tab=,
     130}
     131
     132\setcounter{secnumdepth}{3}     % number subsubsections
     133\setcounter{tocdepth}{3}                % subsubsections in table of contents
    70134\makeindex
    71 
    72 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    73 
    74 \title{\Huge
    75 \vspace*{1in}
    76 \CFA (\CFL) Reference Manual and Rationale
    77 }% title
    78 
    79 \author{\huge
    80 Glen Ditchfield and Peter A. Buhr
    81 }% author
    82 
    83 \date{
    84 DRAFT \\ \today
    85 }% date
    86135
    87136%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    89138\begin{document}
    90139\pagestyle{headings}
    91 % changed after setting pagestyle
    92 \renewcommand{\chaptermark}[1]{\markboth{\thechapter\quad #1}{\thechapter\quad #1}}
    93 \renewcommand{\sectionmark}[1]{\markboth{\thesection\quad #1}{\thesection\quad #1}}
     140\linenumbers                                    % comment out to turn off line numbering
     141
     142\title{\CFA (\CFAA) Reference Manual and Rationale}
     143\author{Glen Ditchfield}
     144\date{DRAFT\\\today}
     145
    94146\pagenumbering{roman}
    95 \linenumbers                                            % comment out to turn off line numbering
     147\pagestyle{plain}
    96148
    97149\maketitle
     150
     151\vspace*{\fill}
    98152\thispagestyle{empty}
    99 \vspace*{\fill}
    100153\noindent
    101154\copyright\,2015 Glen Ditchfield \\ \\
    102155\noindent
    103 This work is licensed under the Creative Commons Attribution 4.0 International License.
    104 To view a copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
     156This work is licensed under the Creative Commons Attribution 4.0 International License. To view a
     157copy of this license, visit {\small\url{http://creativecommons.org/licenses/by/4.0}}.
    105158\vspace*{1in}
    106159
    … …  
    115168\chapter*{Introduction}\addcontentsline{toc}{chapter}{Introduction}
    116169
    117 This document is a reference manual and rationale for \CFA, a polymorphic extension of the C programming language.
    118 It makes frequent reference to the {\c11} standard \cite{C11}, and occasionally compares \CFA to {\CC} \cite{C++}.
    119 
    120 The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering differs).
    121 Unfortunately, this means the manual contains more ``forward references'' than usual, making it harder to follow if the reader does not have a copy of the {\c11} standard.
    122 For a simple introduction to \CFA, see the companion document ``An Overview of \CFA''
    123 \cite{Ditchfield96:Overview}.
    124 
    125 \begin{rationale}
    126 Commentary (like this) is quoted with quads.
    127 Commentary usually deals with subtle points, the rationale behind a rule, and design decisions.
     170This document is a reference manual and rationale for \CFA, a polymorphic extension of the C
     171programming language. It makes frequent reference to the {\c11} standard \cite{ANS:C11}, and
     172occasionally compares \CFA to {\CC} \cite{c++}.
     173
     174The manual deliberately imitates the ordering of the {\c11} standard (although the section numbering
     175differs). Unfortunately, this means that the manual contains more ``forward references'' than
     176usual, and that it will be hard to follow if the reader does not have a copy of the {\c11} standard
     177near-by. For a gentle introduction to \CFA, see the companion document ``An Overview of
     178\CFA'' \cite{Ditchfield96:Overview}.
     179
     180\begin{rationale}
     181Commentary (like this) is quoted with quads. Commentary usually deals with subtle points, the
     182rationale behind a rule, and design decisions.
    128183\end{rationale}
    129184
    130185% No ``Scope'' or ``Normative references'' chapters yet.
    131 
    132 
    133186\setcounter{chapter}{2}
    134187\chapter{Terms, definitions, and symbols}
    135 
    136 Terms from the {\c11} standard used in this document have the same meaning as in the {\c11} standard.
     188Terms from the {\c11} standard used in this document have the same meaning as in the {\c11}
     189standard.
    137190
    138191% No ``Conformance'' or ``Environment'' chapters yet.
    139 
    140 
    141192\setcounter{chapter}{5}
    142193\chapter{Language}
    143 
    144 
    145194\section{Notation}
    146 The syntax notation used in this document is the same as in the {\c11} standard, with one exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'', indicates that these rules extend a previous definition, which occurs in this document or in the {\c11} standard.
     195The syntax notation used in this document is the same as is used in the {\c11} standard, with one
     196exception: ellipsis in the definition of a nonterminal, as in ``\emph{declaration:} \ldots'',
     197indicates that these rules extend a previous definition, which occurs in this document or in the
     198{\c11} standard.
    147199
    148200
    … …  
    152204\subsection{Scopes of identifiers}\index{scopes}
    153205
    154 \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 \Index{name space}, instead of hiding them.
    155 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 ©type©\use{type} or ©typedef©\use{typedef} declaration and the other is not.
    156 The outer declaration becomes \Index{visible} when the scope of the inner declaration terminates.
    157 \begin{rationale}
    158 Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope;
    159 a {\CC} program can not.
     206\CFA's scope rules differ from C's in one major respect: a declaration of an identifier may
     207overload\index{overloading} outer declarations of lexically identical identifiers in the same
     208\Index{name space}, instead of hiding them. The outer declaration is hidden if the two declarations
     209have \Index{compatible type}, or if one declares an array type and the other declares a pointer type
     210and the element type and pointed-at type are compatible, or if one has function type and the other
     211is a pointer to a compatible function type, or if one declaration is a \lstinline$type$\use{type} or
     212\lstinline$typedef$\use{typedef} declaration and the other is not.  The outer declaration becomes
     213\Index{visible} when the scope of the inner declaration terminates.
     214\begin{rationale}
     215Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same
     216scope; a {\CC} program can not.
    160217\end{rationale}
    161218
    … …  
    164221\index{linkage}
    165222
    166 \CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with external or internal linkage do not necessarily denote the same object or function.
    167 Instead, in the set of translation units and libraries that constitutes an entire program, any two instances of a particular identifier with \Index{external linkage} denote the same object or function if they have \Index{compatible type}s, 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.
    168 Within one translation unit, each instance of an identifier with \Index{internal linkage} denotes the same object or function in the same circumstances.
     223\CFA's linkage rules differ from C's in only one respect: instances of a particular identifier with
     224external or internal linkage do not necessarily denote the same object or function. Instead, in the
     225set of translation units and libraries that constitutes an entire program, any two instances of a
     226particular identifier with \Index{external linkage} denote the same object or function if they have
     227\Index{compatible type}s, or if one declares an array type and the other declares a pointer type and
     228the element type and pointed-at type are compatible, or if one has function type and the other is a
     229pointer to a compatible function type. Within one translation unit, each instance of an identifier
     230with \Index{internal linkage} denotes the same object or function in the same circumstances.
    169231Identifiers with \Index{no linkage} always denote unique entities.
    170232\begin{rationale}
    171 A \CFA program can declare an ©extern int v© and an ©extern float v©;
    172 a C program cannot.
    173 \end{rationale}
    174 
    175 
    176 \setcounter{subsection}{8}
    177 \subsection{Generic Types}
    178 
    179 
    180 \subsubsection{Semantics}
    181 
    182 \CFA provides a capability for generic types;
    183 using this capability a single "generic type generator" can be written that can represent multiple concrete type instantiations by substitution of the "type parameters" of the generic type for concrete types.
    184 Syntactically a generic type generator is represented by putting a forall specifier on a struct or union declaration, as defined in \VRef{forall}.
    185 An instantiation of the generic type is written by specifying the type parameters in parentheses after the name of the generic type generator:
    186 \begin{lstlisting}
    187 forall( otype T | sumable( T ) ) struct pair {
    188         T x;
    189         T y;
    190 };
    191 pair( int ) p = { 3, 14 };
    192 \end{lstlisting}
    193 
    194 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., ©sumable©.
    195 The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    196 
    197 Polymorphic functions may have generic types as parameters, and those generic types may use type parameters of the polymorphic function as type parameters of the generic type:
    198 \begin{lstlisting}
    199 forall( otype T ) void swap( pair(T) *p ) {
    200         T z = p->x;
    201         p->x = p->y;
    202         p->y = z;
    203 }
    204 \end{lstlisting}
    205 
    206 
    207 \subsubsection{Constraints}
    208 
    209 To avoid unduly constraining implementors, the generic type generator definition must be visible at any point where it is instantiated.
    210 Forward declarations of generic type generators are not forbidden, but the definition must be visible to instantiate the generic type.  Equivalently, instantiations of generic types are not allowed to be incomplete types.
    211 
    212 \examples
    213 \begin{lstlisting}
    214 forall( otype T ) struct A;
    215 
    216 forall( otype T ) struct B {
    217         A(T) *a;                        // legal, but cannot instantiate B(T)
    218 };
    219 
    220 B(T) x;                                 // illegal, *x.a is of an incomplete generic type
    221  
    222 forall( otype T ) struct A {
    223         B( T ) *b;
    224 };
    225 
    226 B( T ) y;                               // legal, *x.a is now of a complete generic type
    227 
    228 // box.h:
    229         forall( otype T ) struct box;
    230         forall( otype T ) box( T ) *make_box( T );
    231         forall( otype T ) void use_box( box( T ) *b );
    232        
    233 // main.c:
    234         box( int ) *b = make_box( 42 ); // illegal, definition of box not visible
    235         use_box( b );           // illegal
    236 \end{lstlisting}
    237 
     233A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$; a C
     234program cannot.
     235\end{rationale}
    238236
    239237\section{Conversions}
    240238\CFA defines situations where values of one type are automatically converted to another type.
    241 These conversions are called \define{implicit conversion}s.
    242 The programmer can request \define{explicit conversion}s using cast expressions.
     239These conversions are called \define{implicit conversion}s. The programmer can request
     240\define{explicit conversion}s using cast expressions.
    243241
    244242
    245243\subsection{Arithmetic operands}
    246 
    247 
    248 \setcounter{subsubsection}{8}
     244\setcounter{subsubsection}{7}
     245
     246
    249247\subsubsection{Safe arithmetic conversions}
    250 
    251 In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most binary arithmetic operators to convert the operands to a common type and determine the type of the operator's result.
    252 In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    253 
    254 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$.
    255 Let ©unsigned$_{mr}$© be the unsigned integer type with maximal rank.
     248In C, a pattern of conversions known as the \define{usual arithmetic conversion}s is used with most
     249binary arithmetic operators to convert the operands to a common type and determine the type of the
     250operator's result. In \CFA, these conversions play a role in overload resolution, and
     251collectively are called the \define{safe arithmetic conversion}s.
     252
     253Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion
     254rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$. Let
     255\(unsigned_{mr}\) be the unsigned integer type with maximal rank.
    256256
    257257The following conversions are \emph{direct} safe arithmetic conversions.
    … …  
    259259\item
    260260The \Index{integer promotion}s.
    261 \item
    262 For every rank $r$ greater than or equal to the rank of ©int©, conversion from ©int$_r$© to ©unsigned$_r$©.
    263 \item
    264 For every rank $r$ greater than or equal to the rank of ©int©, where ©int$_{r+1}$© exists and can represent all values of ©unsigned$_r$©, conversion from ©unsigned$_r$© to ©int$_{r+1}$©.
    265 \item
    266 Conversion from ©unsigned$_{mr}$© to ©float©.
     261
     262\item
     263For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\)
     264to \(unsigned_r\).
     265
     266\item
     267For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists
     268and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
     269
     270\item
     271Conversion from \(unsigned_{mr}\) to \lstinline$float$.
     272
    267273\item
    268274Conversion from an enumerated type to its compatible integer type.
    269 \item
    270 Conversion from ©float© to ©double©, and from ©double© to ©long double©.
    271 \item
    272 Conversion from ©float _Complex© to ©double _Complex©, and from ©double _Complex© to ©long double _Complex©.
     275
     276\item
     277Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to
     278\lstinline$long double$.
     279
     280\item
     281Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$,
     282and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
     283
    273284\begin{sloppypar}
    274285\item
    275 Conversion from ©float _Imaginary© to ©double _Imaginary©, and from ©double _Imaginary© to ©long double _Imaginary©, if the implementation supports imaginary types.
     286Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from
     287\lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the
     288implementation supports imaginary types.
    276289\end{sloppypar}
    277290\end{itemize}
    278291
    279 If type ©T© can be converted to type ©U© by a safe direct arithmetic conversion and type ©U© can be converted to type ©V© by a safe arithmetic conversion, then the conversion from ©T© to type ©V© is an \emph{indirect} safe arithmetic conversion.
    280 
    281 \begin{rationale}
    282 Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the usual arithmetic conversions, and \CFA does not include them as safe conversions.
     292If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion
     293and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then
     294the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic
     295conversion.
     296
     297\begin{rationale}
     298Note that {\c11} does not include conversion from \Index{real type}s to \Index{complex type}s in the
     299usual arithmetic conversions, and \CFA does not include them as safe conversions.
    283300\end{rationale}
    284301
    285302
    286303\subsection{Other operands}
    287 
    288 
    289304\setcounter{subsubsection}{3}
     305
     306
    290307\subsubsection{Anonymous structures and unions}
    291308\label{anon-conv}
    292309
    293 If an expression's type is a pointer to a structure or union type that has a member that is an \Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's type.
    294 The result of the conversion is a pointer to the member.
     310If an expression's type is a pointer to a structure or union type that has a member that is an
     311\Index{anonymous structure} or an \Index{anonymous union}, it can be implicitly
     312converted\index{implicit conversion} to a pointer to the anonymous structure's or anonymous union's
     313type. The result of the conversion is a pointer to the member.
    295314
    296315\examples
    … …  
    299318        int x, y;
    300319};
    301 void move_by( struct point * p1, struct point * p2 ) {§\impl{move_by}§
     320void move_by(struct point * p1, struct point * p2) {@\impl{move_by}@
    302321        p1->x += p2.x;
    303322        p1->y += p2.y;
    304323}
     324
    305325struct color_point {
    306326        enum { RED, BLUE, GREEN } color;
    307327        struct point;
    308328} cp1, cp2;
    309 move_to( &cp1, &cp2 );
    310 \end{lstlisting}
    311 Thanks to implicit conversion, the two arguments that ©move_by()© receives are pointers to ©cp1©'s second member and ©cp2©'s second member.
     329move_to(&cp1, &cp2);
     330\end{lstlisting}
     331Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
     332\lstinline$cp1$'s second member and \lstinline$cp2$'s second member.
    312333
    313334
    314335\subsubsection{Specialization}
    315 A function or value whose type is polymorphic may be implicitly converted to one whose type is \Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}.
    316 Any value that is legal for the inferred parameter may be used, including other inferred parameters.
    317 
    318 If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters in its type, then an object or function must be visible at the point of the specialization that has the same identifier as the assertion parameter and has a type that is compatible\index{compatible type} with or can be specialized to the type of the assertion parameter.
    319 The assertion parameter is bound to that object or function.
    320 
    321 The type of the specialization is the type of the original with the bound inferred parameters and the bound assertion parameters replaced by their bound values.
     336A function or value whose type is polymorphic may be implicitly converted to one whose type is
     337\Index{less polymorphic} by binding values to one or more of its \Index{inferred parameter}. Any
     338value that is legal for the inferred parameter may be used, including other inferred parameters.
     339
     340If, after the inferred parameter binding, an \Index{assertion parameter} has no inferred parameters
     341in its type, then an object or function must be visible at the point of the specialization that has
     342the same identifier as the assertion parameter and has a type that is compatible\index{compatible
     343  type} with or can be specialized to the type of the assertion parameter.  The assertion parameter
     344is bound to that object or function.
     345
     346The type of the specialization is the type of the original with the bound inferred parameters and
     347the bound assertion parameters replaced by their bound values.
    322348
    323349\examples
    324350The type
    325351\begin{lstlisting}
    326 forall( otype T, otype U ) void (*)( T, U );
     352forall( type T, type U ) void (*)( T, U );
    327353\end{lstlisting}
    328354can be specialized to (among other things)
    329355\begin{lstlisting}
    330 forall( otype T ) void (*)( T, T );             // U bound to T
    331 forall( otype T ) void (*)( T, real );  // U bound to real
    332 forall( otype U ) void (*)( real, U );  // T bound to real
     356forall( type T ) void (*)( T, T );              // U bound to T
     357forall( type T ) void (*)( T, real );   // U bound to real
     358forall( type U ) void (*)( real, U );   // T bound to real
    333359void f( real, real );                                   // both bound to real
    334360\end{lstlisting}
    … …  
    336362The type
    337363\begin{lstlisting}
    338 forall( otype T | T ?+?( T, T ) ) T (*)( T );
     364forall( type T | T ?+?( T, T )) T (*)( T );
    339365\end{lstlisting}
    340366can be specialized to (among other things)
    341367\begin{lstlisting}
    342 int (*)( int );         // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
     368int (*)( int );                                         // T bound to int, and T ?+?(T, T ) bound to int ?+?( int, int )
    343369\end{lstlisting}
    344370
    … …  
    351377a direct safe arithmetic conversion;
    352378\item
    353 from any object type or incomplete type to ©void©;
    354 \item
    355 from a pointer to any non-©void© type to a pointer to ©void©;
    356 \item
    357 from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
    358 \item
    359 from a pointer to a structure or union type to a pointer to the type of a member of the structure or union that is an \Index{anonymous structure} or an \Index{anonymous union};
    360 \item
    361 within the scope of an initialized \Index{type declaration}, conversions between a type and its implementation or between a pointer to a type and a pointer to its implementation.
     379from any object type or incomplete type to \lstinline$void$;
     380\item
     381from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
     382\item
     383from a pointer to any type to a pointer to a more qualified version of the type\index{qualified
     384type};
     385\item
     386from a pointer to a structure or union type to a pointer to the type of a member of the structure or
     387union that is an \Index{anonymous structure} or an \Index{anonymous union};
     388\item
     389within the scope of an initialized \Index{type declaration}, conversions between a type and its
     390implementation or between a pointer to a type and a pointer to its implementation.
    362391\end{itemize}
    363392
    364393Conversions that are not safe conversions are \define{unsafe conversion}s.
    365394\begin{rationale}
    366 As in C, there is an implicit conversion from ©void *© to any pointer type.
    367 This is clearly dangerous, and {\CC} does not have this implicit conversion.
    368 \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.
     395As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type. This is
     396clearly dangerous, and {\CC} does not have this implicit conversion.
     397\CFA\index{deficiencies!void * conversion} keeps it, in the interest of remaining as pure a
     398superset of C as possible, but discourages it by making it unsafe.
    369399\end{rationale}
    370400
    … …  
    372402\subsection{Conversion cost}
    373403
    374 The \define{conversion cost} of a safe\index{safe conversion} conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion costs.} is a measure of how desirable or undesirable it is.
    375 It is defined as follows.
     404The \define{conversion cost} of a safe\index{safe conversion}
     405conversion\footnote{Unsafe\index{unsafe conversion} conversions do not have defined conversion
     406costs.} is a measure of how desirable or undesirable it is. It is defined as follows.
    376407\begin{itemize}
    377408\item
    … …  
    382413
    383414\item
    384 The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions needed to make up the conversion.
     415The cost of an indirect safe arithmetic conversion is the smallest number of direct conversions
     416needed to make up the conversion.
    385417\end{itemize}
    386418
    … …  
    390422\begin{itemize}
    391423\item
    392 The cost of an implicit conversion from ©int© to ©long© is 1.
    393 The cost of an implicit conversion from ©long© to ©double© is 3, because it is defined in terms of conversions from ©long© to ©unsigned long©, then to ©float©, and then to ©double©.
    394 
    395 \item
    396 If ©int© can represent all the values of ©unsigned short©, then the cost of an implicit conversion from ©unsigned short© to ©unsigned© is 2: ©unsigned short© to ©int© to ©unsigned©.
    397 Otherwise, ©unsigned short© is converted directly to ©unsigned©, and the cost is 1.
    398 
    399 \item
    400 If ©long© can represent all the values of ©unsigned©, then the conversion cost of ©unsigned© to ©long© is 1.
    401 Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
     424The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1. The cost of an
     425implicit conversion from \lstinline$long$ to \lstinline$double$ is 3, because it is defined in terms
     426of conversions from \lstinline$long$ to \lstinline$unsigned long$, then to \lstinline$float$, and
     427then to \lstinline$double$.
     428
     429\item
     430If \lstinline$int$ can represent all the values of \lstinline$unsigned short$, then the cost of an
     431implicit conversion from \lstinline$unsigned short$ to \lstinline$unsigned$ is 2:
     432\lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$. Otherwise,
     433\lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
     434
     435\item
     436If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost
     437of \lstinline$unsigned$ to \lstinline$long$ is 1. Otherwise, the conversion is an unsafe
     438conversion, and its conversion cost is undefined.
    402439\end{itemize}
    403440
    404 
    405441\section{Lexical elements}
    406 
    407 
    408442\subsection{Keywords}
    409 
    410443\begin{syntax}
    411444\oldlhs{keyword}
    412 \rhs ©forall©
    413 \rhs ©lvalue©
    414 \rhs ©trait©
    415 \rhs ©dtype©
    416 \rhs ©ftype©
    417 \rhs ©otype©
     445        \rhs \lstinline$forall$
     446        \rhs \lstinline$lvalue$
     447        \rhs \lstinline$context$
     448        \rhs \lstinline$dtype$
     449        \rhs \lstinline$ftype$
     450        \rhs \lstinline$type$
    418451\end{syntax}
    419452
    … …  
    421454\subsection{Identifiers}
    422455
    423 \CFA allows operator \Index{overloading} by associating operators with special function identifiers.
    424 Furthermore, the constants ``©0©'' and ``©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.
    425 Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
     456\CFA allows operator \Index{overloading} by associating operators with special function
     457identifiers. Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status
     458for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them
     459as overloadable identifiers. Programmers can use these identifiers to declare functions and objects
     460that implement operators and constants for their own types.
    426461
    427462
    … …  
    431466\begin{syntax}
    432467\oldlhs{identifier}
    433 \rhs ©0©
    434 \rhs ©1©
     468\rhs \lstinline$0$
     469\rhs \lstinline$1$
    435470\end{syntax}
    436471
    437 \index{constant identifiers}\index{identifiers!for constants} The tokens ``©0©''\impl{0} and ``©1©''\impl{1} are identifiers.
    438 No other tokens defined by the rules for integer constants are considered to be identifiers.
    439 \begin{rationale}
    440 Why ``©0©'' and ``©1©''? Those integers have special status in C.
    441 All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
    442 The operations ``©&&©'', ``©||©'', and ``©!©'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    443 A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    444 
    445 In 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.
    446 However, 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.
    447 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
    448 
    449 Why \emph{just} ``©0©'' and ``©1©''? Why not other integers? No other integers have special status in C.
    450 A facility that let programmers declare specific constants---``©const Rational 12©'', for instance---would not be much of an improvement.
    451 Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    452 The complexity of such a feature doesn't seem worth the gain.
     472\index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0}
     473and ``\lstinline$1$''\impl{1} are identifiers. No other tokens defined by the rules for integer
     474constants are considered to be identifiers.
     475\begin{rationale}
     476Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C. All scalar
     477types can be incremented and decremented, which is defined in terms of adding or subtracting 1. The
     478operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any
     479scalar arguments, and are defined in terms of comparison against 0. A \nonterm{constant-expression}
     480that evaluates to 0 is effectively compatible with every pointer type.
     481
     482In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to
     483any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to
     4840 as a special case. However, user-defined arithmetic types often need the equivalent of a 1 or 0
     485for their functions or operators, polymorphic functions often need 0 and 1 constants of a type
     486matching their polymorphic parameters, and user-defined pointer-like types may need a null value.
     487Defining special constants for a user-defined type is more efficient than defining a conversion to
     488the type from \lstinline$_Bool$.
     489
     490Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers
     491have special status in C. A facility that let programmers declare specific
     492constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
     493Some facility for defining the creation of values of programmer-defined types from arbitrary integer
     494tokens would be needed. The complexity of such a feature doesn't seem worth the gain.
    453495\end{rationale}
    454496
    … …  
    456498\subsubsection{Operator identifiers}
    457499
    458 \index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the programmer-definable operator identifiers and the operations they are associated with.
    459 Functions that are declared with (or pointed at by function pointers that are declared with) these identifiers can be called by expressions that use the operator tokens and syntax, or the operator identifiers and ``function call'' syntax.
    460 The relationships between operators and function calls are discussed in descriptions of the operators.
     500\index{operator identifiers}\index{identifiers!for operators} Table \ref{opids} lists the
     501programmer-definable operator identifiers and the operations they are associated with. Functions
     502that are declared with (or pointed at by function pointers that are declared with) these identifiers
     503can be called by expressions that use the operator tokens and syntax, or the operator identifiers
     504and ``function call'' syntax. The relationships between operators and function calls are discussed
     505in descriptions of the operators.
    461506
    462507\begin{table}[hbt]
    … …  
    464509\begin{tabular}[t]{ll}
    465510%identifier & operation \\ \hline
    466 ©?[?]© & subscripting \impl{?[?]}\\
    467 ©?()© & function call \impl{?()}\\
    468 ©?++© & postfix increment \impl{?++}\\
    469 ©?--© & postfix decrement \impl{?--}\\
    470 ©++?© & prefix increment \impl{++?}\\
    471 ©--?© & prefix decrement \impl{--?}\\
    472 ©*?© & dereference \impl{*?}\\
    473 ©+?© & unary plus \impl{+?}\\
    474 ©-?© & arithmetic negation \impl{-?}\\
    475 ©~?© & bitwise negation \impl{~?}\\
    476 ©!?© & logical complement \impl{"!?}\\
    477 ©?*?© & multiplication \impl{?*?}\\
    478 ©?/?© & division \impl{?/?}\\
     511\lstinline$?[?]$ & subscripting \impl{?[?]}\\
     512\lstinline$?()$ & function call \impl{?()}\\
     513\lstinline$?++$ & postfix increment \impl{?++}\\
     514\lstinline$?--$ & postfix decrement \impl{?--}\\
     515\lstinline$++?$ & prefix increment \impl{++?}\\
     516\lstinline$--?$ & prefix decrement \impl{--?}\\
     517\lstinline$*?$ & dereference \impl{*?}\\
     518\lstinline$+?$ & unary plus \impl{+?}\\
     519\lstinline$-?$ & arithmetic negation \impl{-?}\\
     520\lstinline$~?$ & bitwise negation \impl{~?}\\
     521\lstinline$!?$ & logical complement \impl{"!?}\\
     522\lstinline$?*?$ & multiplication \impl{?*?}\\
     523\lstinline$?/?$ & division \impl{?/?}\\
    479524\end{tabular}\hfil
    480525\begin{tabular}[t]{ll}
    481526%identifier & operation \\ \hline
    482 ©?%?© & remainder \impl{?%?}\\
    483 ©?+?© & addition \impl{?+?}\\
    484 ©?-?© & subtraction \impl{?-?}\\
    485 ©?<<?© & left shift \impl{?<<?}\\
    486 ©?>>?© & right shift \impl{?>>?}\\
    487 ©?<?© & less than \impl{?<?}\\
    488 ©?<=?© & less than or equal \impl{?<=?}\\
    489 ©?>=?© & greater than or equal \impl{?>=?}\\
    490 ©?>?© & greater than \impl{?>?}\\
    491 ©?==?© & equality \impl{?==?}\\
    492 ©?!=?© & inequality \impl{?"!=?}\\
    493 ©?&?© & bitwise AND \impl{?&?}\\
     527\lstinline$?%?$ & remainder \impl{?%?}\\
     528\lstinline$?+?$ & addition \impl{?+?}\\
     529\lstinline$?-?$ & subtraction \impl{?-?}\\
     530\lstinline$?<<?$ & left shift \impl{?<<?}\\
     531\lstinline$?>>?$ & right shift \impl{?>>?}\\
     532\lstinline$?<?$ & less than \impl{?<?}\\
     533\lstinline$?<=?$ & less than or equal \impl{?<=?}\\
     534\lstinline$?>=?$ & greater than or equal \impl{?>=?}\\
     535\lstinline$?>?$ & greater than \impl{?>?}\\
     536\lstinline$?==?$ & equality \impl{?==?}\\
     537\lstinline$?!=?$ & inequality \impl{?"!=?}\\
     538\lstinline$?&?$ & bitwise AND \impl{?&?}\\
    494539\end{tabular}\hfil
    495540\begin{tabular}[t]{ll}
    496541%identifier & operation \\ \hline
    497 ©?^?© & exclusive OR \impl{?^?}\\
    498 ©?|?© & inclusive OR \impl{?"|?}\\
    499 ©?=?© & simple assignment \impl{?=?}\\
    500 ©?*=?© & multiplication assignment \impl{?*=?}\\
    501 ©?/=?© & division assignment \impl{?/=?}\\
    502 ©?%=?© & remainder assignment \impl{?%=?}\\
    503 ©?+=?© & addition assignment \impl{?+=?}\\
    504 ©?-=?© & subtraction assignment \impl{?-=?}\\
    505 ©?<<=?© & left-shift assignment \impl{?<<=?}\\
    506 ©?>>=?© & right-shift assignment \impl{?>>=?}\\
    507 ©?&=?© & bitwise AND assignment \impl{?&=?}\\
    508 ©?^=?© & exclusive OR assignment \impl{?^=?}\\
    509 ©?|=?© & inclusive OR assignment \impl{?"|=?}\\
     542\lstinline$?^?$ & exclusive OR \impl{?^?}\\
     543\lstinline$?|?$ & inclusive OR \impl{?"|?}\\
     544\lstinline$?=?$ & simple assignment \impl{?=?}\\
     545\lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\
     546\lstinline$?/=?$ & division assignment \impl{?/=?}\\
     547\lstinline$?%=?$ & remainder assignment \impl{?%=?}\\
     548\lstinline$?+=?$ & addition assignment \impl{?+=?}\\
     549\lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\
     550\lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\
     551\lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\
     552\lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\
     553\lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\
     554\lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\
    510555\end{tabular}
    511556\hfil
    … …  
    515560
    516561\begin{rationale}
    517 Operator identifiers are made up of the characters of the operator token, with question marks added to mark the positions of the arguments of operators.
    518 The question marks serve as mnemonic devices;
    519 programmers can not create new operators by arbitrarily mixing question marks and other non-alphabetic characters.
    520 Note that prefix and postfix versions of the increment and decrement operators are distinguished by the position of the question mark.
    521 \end{rationale}
    522 
    523 \begin{rationale}
    524 The use of ``©?©'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``©(i < 0)?--i:i©'' is legal in a C program, but a
    525 \CFA compiler detects a syntax error because it treats ``©?--©'' as an identifier, not as the two tokens ``©?©'' and ``©--©''.
     562Operator identifiers are made up of the characters of the operator token, with question marks added
     563to mark the positions of the arguments of operators. The question marks serve as mnemonic devices;
     564programmers can not create new operators by arbitrarily mixing question marks and other
     565non-alphabetic characters. Note that prefix and postfix versions of the increment and decrement
     566operators are distinguished by the position of the question mark.
     567\end{rationale}
     568
     569\begin{rationale}
     570The use of ``\lstinline$?$'' in identifiers means that some C programs are not \CFA programs.
     571For instance, the sequence of characters ``\lstinline$(i < 0)?--i:i$'' is legal in a C program, but
     572a \CFA compiler will detect a syntax error because it will treat ``\lstinline$?--$'' as an
     573identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
    526574\end{rationale}
    527575
    … …  
    530578\begin{itemize}
    531579\item
    532 The logical operators ``©&&©'' and ``©||©'', and the conditional operator ``©?:©''.
    533 These 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.
    534 Note that the definitions of ``©&&©'' and ``©||©'' say that they work by checking that their arguments are unequal to 0, so defining ``©!=©'' and ``©0©'' for user-defined types is enough to allow them to be used in logical expressions.
    535 
    536 \item
    537 The comma operator\index{comma expression}.
    538 It is a control-flow operator like those above.
     580The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
     581``\lstinline$?:$''. These operators do not always evaluate their operands, and hence can not be
     582properly defined by functions unless some mechanism like call-by-name is added to the language.
     583Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by
     584checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$''
     585for user-defined types is enough to allow them to be used in logical expressions.
     586
     587\item
     588The comma operator\index{comma expression}. It is a control-flow operator like those above.
    539589Changing its meaning seems pointless and confusing.
    540590
    541591\item
    542 The ``address of'' operator.
    543 It would seem useful to define a unary ``©&©'' operator that returns values of some programmer-defined pointer-like type.
    544 The problem lies with the type of the operator.
    545 Consider the expression ``©p = &x©'', where ©x© is of type ©T© and ©p© has the programmer-defined type ©T_ptr©.
    546 The expression might be treated as a call to the unary function ``©&?©''.
    547 Now what is the type of the function's parameter? It can not be ©T©, because then ©x© would be passed by value, and there is no way to create a useful pointer-like result from a value.
    548 Hence the parameter must have type ©T *©.
    549 But then the expression must be rewritten as ``©p = &?( &x )©''
     592The ``address of'' operator. It would seem useful to define a unary ``\lstinline$&$'' operator that
     593returns values of some programmer-defined pointer-like type. The problem lies with the type of the
     594operator. Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
     595\lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$. The expression
     596might be treated as a call to the unary function ``\lstinline$&?$''. Now what is the type of the
     597function's parameter? It can not be \lstinline$T$, because then \lstinline$x$ would be passed by
     598value, and there is no way to create a useful pointer-like result from a value. Hence the parameter
     599must have type \lstinline$T *$. But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
    550600---which doesn't seem like progress!
    551601
    552 The 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''.
    553 It seems simpler to define a conversion function from ©T *© to ©T_ptr©.
    554 
    555 \item
    556 The ©sizeof© operator.
    557 It is already defined for every object type, and intimately tied into the language's storage allocation model.
    558 Redefining it seems pointless.
    559 
    560 \item
    561 The ``member of'' operators ``©.©'' and ``©->©''.
    562 These are not really infix operators, since their right ``operand'' is not a value or object.
    563 
    564 \item
    565 Cast operators\index{cast expression}.
    566 Anything that can be done with an explicit cast can be done with a function call.
    567 The difference in syntax is small.
     602The rule for address-of expressions would have to be something like ``keep applying address-of
     603functions until you get one that takes a pointer argument, then use the built-in operator and
     604stop''. It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
     605
     606\item
     607The \lstinline$sizeof$ operator. It is already defined for every object type, and intimately tied
     608into the language's storage allocation model. Redefining it seems pointless.
     609
     610\item
     611The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''. These are not really infix
     612operators, since their right ``operand'' is not a value or object.
     613
     614\item
     615Cast operators\index{cast expression}. Anything that can be done with an explicit cast can be done
     616with a function call. The difference in syntax is small.
    568617\end{itemize}
    569618\end{rationale}
    … …  
    572621\section{Expressions}
    573622
    574 \CFA allows operators and identifiers to be overloaded.
    575 Hence, each expression can have a number of \define{interpretation}s, each of which has a different type.
    576 The interpretations that are potentially executable are called \define{valid interpretation}s.
    577 The set of interpretations depends on the kind of expression and on the interpretations of the subexpressions that it contains.
    578 The rules for determining the valid interpretations of an expression are discussed below for each kind of expression.
    579 Eventually the context of the outermost expression chooses one interpretation of that expression.
    580 
    581 An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or function denoted by every identifier in the expression.
    582 An expression can have some interpretations that are ambiguous and others that are unambiguous.
    583 An expression that is chosen to be executed shall not be ambiguous.
    584 
    585 The \define{best valid interpretations} are the valid interpretations that use the fewest unsafe\index{unsafe conversion} conversions.
    586 Of these, the best are those where the functions and objects involved are the least polymorphic\index{less polymorphic}.
    587 Of these, the best have the lowest total \Index{conversion cost}, including all implicit conversions in the argument expressions.
    588 Of these, the best have the highest total conversion cost for the implicit conversions
    589 (if any) applied to the argument expressions.
    590 If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous\index{ambiguous interpretation}.
    591 
    592 \begin{rationale}
    593 \CFA's rules for selecting the best interpretation are designed to allow overload resolution to mimic C's operator semantics.
    594 In C, the ``usual arithmetic conversions'' are applied to the operands of binary operators if necessary to convert the operands to types with a common real type.
    595 In \CFA, those conversions are ``safe''.
    596 The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    597 The ``lowest total expression cost'' rule chooses the proper common type.
    598 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: ©(double)-i© will be preferred to ©-(double)i©.
    599 
    600 The ``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.
    601 It also gives preference to monomorphic values (such as the ©int© ©0©) over polymorphic values (such as the \Index{null pointer} ©0©\use{0}).
    602 However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
     623\CFA allows operators and identifiers to be overloaded. Hence, each expression can have a number
     624of \define{interpretation}s, each of which has a different type. The interpretations that are
     625potentially executable are called \define{valid interpretation}s. The set of interpretations
     626depends on the kind of expression and on the interpretations of the subexpressions that it contains.
     627The rules for determining the valid interpretations of an expression are discussed below for each
     628kind of expression. Eventually the context of the outermost expression chooses one interpretation
     629of that expression.
     630
     631An \define{ambiguous interpretation} is an interpretation which does not specify the exact object or
     632function denoted by every identifier in the expression. An expression can have some interpretations
     633that are ambiguous and others that are unambiguous. An expression that is chosen to be executed
     634shall not be ambiguous.
     635
     636The \define{best valid interpretations} are the valid interpretations that use the fewest
     637unsafe\index{unsafe conversion} conversions. Of these, the best are those where the functions and
     638objects involved are the least polymorphic\index{less polymorphic}. Of these, the best have the
     639lowest total \Index{conversion cost}, including all implicit conversions in the argument
     640expressions. Of these, the best have the highest total conversion cost for the implicit conversions
     641(if any) applied to the argument expressions. If there is no single best valid interpretation, or if
     642the best valid interpretation is ambiguous, then the resulting interpretation is
     643ambiguous\index{ambiguous interpretation}.
     644
     645\begin{rationale}
     646\CFA's rules for selecting the best interpretation are designed to allow overload resolution to
     647mimic C's operator semantics. In C, the ``usual arithmetic conversions'' are applied to the
     648operands of binary operators if necessary to convert the operands to types with a common real type.
     649In \CFA, those conversions are ``safe''. The ``fewest unsafe conversions'' rule ensures that the
     650usual conversions are done, if possible. The ``lowest total expression cost'' rule chooses the
     651proper common type. The odd-looking ``highest argument conversion cost'' rule ensures that, when
     652unary expressions must be converted, conversions of function results are preferred to conversion of
     653function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
     654
     655The ``least polymorphic'' rule reduces the number of polymorphic function calls, since such
     656functions are presumably more expensive than monomorphic functions and since the more specific
     657function is presumably more appropriate. It also gives preference to monomorphic values (such as the
     658\lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
     659\lstinline$0$\use{0}). However, interpretations that call polymorphic functions are preferred to
     660interpretations that perform unsafe conversions, because those conversions potentially lose accuracy
     661or violate strong typing.
    603662
    604663There are two notable differences between \CFA's overload resolution rules and the rules for
    605 {\CC} defined in \cite{C++}.
    606 First, the result type of a function plays a role.
    607 In {\CC}, a function call must be completely resolved based on the arguments to the call in most circumstances.
    608 In \CFA, a function call may have several interpretations, each with a different result type, and the interpretations of the containing context choose among them.
    609 Second, safe conversions are used to choose among interpretations of all sorts of functions;
    610 in {\CC}, the ``usual arithmetic conversions'' are a separate set of rules that apply only to the built-in operators.
    611 \end{rationale}
    612 
    613 Expressions involving certain operators\index{operator identifiers} are considered to be equivalent to function calls.
    614 A transformation from ``operator'' syntax to ``function call'' syntax is defined by \define{rewrite rules}.
    615 Each operator has a set of predefined functions that overload its identifier.
    616 Overload resolution determines which member of the set is executed in a given expression.
    617 The functions have \Index{internal linkage} and are implicitly declared with \Index{file scope}.
    618 The predefined functions and rewrite rules are discussed below for each of these operators.
    619 \begin{rationale}
    620 Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
    621 For instance, ``©an_int + an_int©'' is equivalent to ``©?+?(an_int, an_int)©''.
    622 If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    623 If predefined functions had external linkage, this optimization would be difficult.
    624 \end{rationale}
    625 
    626 \begin{rationale}
    627 Since each subsection describes the interpretations of an expression in terms of the interpretations of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that uses one bottom-up pass over an expression tree.
    628 Such an algorithm was first described (for Ada) by Baker~\cite{Bak:overload}.
    629 It is extended here to handle polymorphic functions and arithmetic conversions.
    630 The overload resolution rules and the predefined functions have been chosen so that, in programs that do not introduce overloaded declarations, expressions will have the same meaning in C and in \CFA.
    631 \end{rationale}
    632 
    633 \begin{rationale}
    634 Expression syntax is quoted from the {\c11} standard.
    635 The syntax itself defines the precedence and associativity of operators.
    636 The sections are arranged in decreasing order of precedence, with all operators in a section having the same precedence.
     664{\CC} defined in \cite{c++}. First, the result type of a function plays a role. In {\CC}, a
     665function call must be completely resolved based on the arguments to the call in most circumstances.
     666In \CFA, a function call may have several interpretations, each with a different result type, and
     667the interpretations of the containing context choose among them. Second, safe conversions are used
     668to choose among interpretations of all sorts of functions; in {\CC}, the ``usual arithmetic
     669conversions'' are a separate set of rules that apply only to the built-in operators.
     670\end{rationale}
     671
     672Expressions involving certain operators\index{operator identifiers} are considered to be equivalent
     673to function calls. A transformation from ``operator'' syntax to ``function call'' syntax is defined
     674by \define{rewrite rules}. Each operator has a set of predefined functions that overload its
     675identifier. Overload resolution determines which member of the set is executed in a given
     676expression. The functions have \Index{internal linkage} and are implicitly declared with \Index{file
     677scope}. The predefined functions and rewrite rules are discussed below for each of these
     678operators.
     679\begin{rationale}
     680Predefined functions and constants have internal linkage because that simplifies optimization in
     681traditional compile-and-link environments. For instance, ``\lstinline$an_int + an_int$'' is
     682equivalent to ``\lstinline$?+?(an_int, an_int)$''. If integer addition has not been redefined in
     683the current scope, a compiler can generate code to perform the addition directly. If predefined
     684functions had external linkage, this optimization would be difficult.
     685\end{rationale}
     686
     687\begin{rationale}
     688Since each subsection describes the interpretations of an expression in terms of the interpretations
     689of its subexpressions, this chapter can be taken as describing an overload resolution algorithm that
     690uses one bottom-up pass over an expression tree. Such an algorithm was first described (for Ada) by
     691Baker~\cite{Bak:overload}. It is extended here to handle polymorphic functions and arithmetic
     692conversions. The overload resolution rules and the predefined functions have been chosen so that, in
     693programs that do not introduce overloaded declarations, expressions will have the same meaning in C
     694and in \CFA.
     695\end{rationale}
     696
     697\begin{rationale}
     698Expression syntax is quoted from the {\c11} standard. The syntax itself defines the precedence and
     699associativity of operators. The sections are arranged in decreasing order of precedence, with all
     700operators in a section having the same precedence.
    637701\end{rationale}
    638702
    … …  
    645709\rhs \nonterm{constant}
    646710\rhs \nonterm{string-literal}
    647 \rhs ©(© \nonterm{expression} ©)©
     711\rhs \lstinline$($ \nonterm{expression} \lstinline$)$
    648712\rhs \nonterm{generic-selection}
    649713\end{syntax}
    650714
    651 \predefined
    652 \begin{lstlisting}
    653 const int 1;§\use{1}§
    654 const int 0;§\use{0}§
    655 forall( dtype DT ) DT * const 0;
    656 forall( ftype FT ) FT * const 0;
     715\paragraph{Predefined Identifiers}%
     716\begin{lstlisting}
     717const int 1;@\use{1}@
     718const int 0;@\use{0}@
     719forall( dtype DT ) DT *const 0;
     720forall( ftype FT ) FT *const 0;
    657721\end{lstlisting}
    658722
    659723\semantics
    660 The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible} declarations of the identifier.
    661 
    662 A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
    663 The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively.
    664 The other two predefined ``©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.
     724The \Index{valid interpretation} of an \nonterm{identifier} are given by the visible\index{visible}
     725declarations of the identifier.
     726
     727A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type
     728and value defined by {\c11}. The predefined integer identifiers ``\lstinline$1$'' and
     729``\lstinline$0$'' have the integer values 1 and 0, respectively. The other two predefined
     730``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when
     731specialized\index{specialization} with a data type or function type respectively, produce a null
     732pointer of that type.
    665733
    666734A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    667735
    668736\examples
    669 The expression ©(void *)0©\use{0} specializes the (polymorphic) null pointer to a null pointer to ©void©. ©(const void *)0© does the same, and also uses a safe conversion from ©void *© to ©const void *©.
    670 In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer ©0© to a pointer.
     737The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null
     738pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe
     739conversion from \lstinline$void *$ to \lstinline$const void *$. In each case, the null pointer
     740conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
     741\lstinline$0$ to a pointer.
    671742
    672743\begin{rationale}
    673744Note that the predefined identifiers have addresses.
    674745
    675 \CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
    676 The C token ``©0©'' is an expression of type ©int© with the value ``zero'', and it \emph{also} is a null pointer constant.
    677 Similarly, ``©(void *)0© is an expression of type ©(void *)© whose value is a null pointer, and it also is a null pointer constant.
    678 However, in C, ``©(void *)(void *)0©'' is
    679 \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.
    680 
    681 \CFA handles these cases through overload resolution.
    682 The declaration
    683 \begin{lstlisting}
    684 forall( dtype DT ) DT * const 0;
    685 \end{lstlisting} means that ©0© is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
    686 The only such value is the null pointer.
    687 Therefore the type \emph{alone} is enough to identify a null pointer.
    688 Where C defines an operator with a special case for the null pointer constant, \CFA defines predefined functions with a polymorphic object parameter.
     746\CFA does not have C's concept of ``null pointer constants'', which are not typed values but
     747special strings of tokens. The C token ``\lstinline$0$'' is an expression of type \lstinline$int$
     748with the value ``zero'', and it \emph{also} is a null pointer constant. Similarly,
     749``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer,
     750and it also is a null pointer constant. However, in C, ``\lstinline$(void *)(void *)0$'' is
     751\emph{not} a null pointer constant, even though it is null-valued, a pointer, and constant! The
     752semantics of C expressions contain many special cases to deal with subexpressions that are null
     753pointer constants.
     754
     755\CFA handles these cases through overload resolution. The declaration
     756\begin{lstlisting}
     757forall( dtype DT ) DT *const 0;
     758\end{lstlisting}
     759means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any}
     760pointer-to-object type or pointer-to-incomplete type. The only such value is the null pointer.
     761Therefore the type \emph{alone} is enough to identify a null pointer. Where C defines an operator
     762with a special case for the null pointer constant, \CFA defines predefined functions with a
     763polymorphic object parameter.
    689764\end{rationale}
    690765
    … …  
    692767\subsubsection{Generic selection}
    693768
    694 \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.
    695 If a generic selection has no ©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.
     769\constraints The best interpretation of the controlling expression shall be
     770unambiguous\index{ambiguous interpretation}, and shall have type compatible with at most one of the
     771types named in its generic association list. If a generic selection has no \lstinline$default$
     772generic association, the best interpretation of its controlling expression shall have type
     773compatible with exactly one of the types named in its generic association list.
    696774
    697775\semantics
    … …  
    704782\lhs{postfix-expression}
    705783\rhs \nonterm{primary-expression}
    706 \rhs \nonterm{postfix-expression} ©[© \nonterm{expression} ©]©
    707 \rhs \nonterm{postfix-expression} ©(©
    708          \nonterm{argument-expression-list}\opt ©)©
    709 \rhs \nonterm{postfix-expression} ©.© \nonterm{identifier}
    710 \rhs \nonterm{postfix-expression} ©->© \nonterm{identifier}
    711 \rhs \nonterm{postfix-expression} ©++©
    712 \rhs \nonterm{postfix-expression} ©--©
    713 \rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©}©
    714 \rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©,© ©}©
     784\rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$
     785\rhs \nonterm{postfix-expression} \lstinline$($
     786         \nonterm{argument-expression-list}\opt \lstinline$)$
     787\rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier}
     788\rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier}
     789\rhs \nonterm{postfix-expression} \lstinline$++$
     790\rhs \nonterm{postfix-expression} \lstinline$--$
     791\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$
     792\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$
    715793\lhs{argument-expression-list}
    716794\rhs \nonterm{assignment-expression}
    717 \rhs \nonterm{argument-expression-list} ©,©
     795\rhs \nonterm{argument-expression-list} \lstinline$,$
    718796         \nonterm{assignment-expression}
    719797\end{syntax}
    … …  
    721799\rewriterules
    722800\begin{lstlisting}
    723 a[b] => ?[?]( b, a ) // if a has integer type§\use{?[?]}§
    724 a[b] => ?[?]( a, b ) // otherwise
    725 a( §\emph{arguments}§ ) => ?()( a, §\emph{arguments}§ )§\use{?()}§
    726 a++ => ?++(&( a ))§\use{?++}§
    727 a-- => ?--(&( a ))§\use{?--}§
     801a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type */@\use{?[?]}@
     802a[b] @\rewrite@ ?[?]( a, b ) // otherwise
     803a( ${\em arguments }$ ) @\rewrite@ ?()( a, ${\em arguments} )$@\use{?()}@
     804a++ @\rewrite@ ?++(&( a ))@\use{?++}@
     805a-- @\rewrite@ ?--(&( a ))@\use{?--}@
    728806\end{lstlisting}
    729807
    … …  
    731809\subsubsection{Array subscripting}
    732810
    733 \predefined
    734 \begin{lstlisting}
    735 forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );§\use{ptrdiff_t}§
    736 forall( otype T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
    737 forall( otype T ) lvalue const T ?[?]( const T *, ptrdiff_t );
    738 forall( otype T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
    739 forall( otype T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
    740 forall( otype T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
    741 forall( otype T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
    742 forall( otype T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
    743 forall( otype T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
    744 forall( otype T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
    745 forall( otype T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
    746 forall( otype T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
    747 forall( otype T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
    748 forall( otype T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
    749 forall( otype T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
    750 forall( otype T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
     811\begin{lstlisting}
     812forall( type T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
     813forall( type T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
     814forall( type T ) lvalue const T ?[?]( const T *, ptrdiff_t );
     815forall( type T ) lvalue restrict T ?[?]( restrict T *, ptrdiff_t );
     816forall( type T ) lvalue volatile T ?[?]( volatile T *, ptrdiff_t );
     817forall( type T ) lvalue _Atomic const T ?[?]( _Atomic const T *, ptrdiff_t );
     818forall( type T ) lvalue _Atomic restrict T ?[?]( _Atomic restrict T *, ptrdiff_t );
     819forall( type T ) lvalue _Atomic volatile T ?[?]( _Atomic volatile T *, ptrdiff_t );
     820forall( type T ) lvalue const restrict T ?[?]( const restrict T *, ptrdiff_t );
     821forall( type T ) lvalue const volatile T ?[?]( const volatile T *, ptrdiff_t );
     822forall( type T ) lvalue restrict volatile T ?[?]( restrict volatile T *, ptrdiff_t );
     823forall( type T ) lvalue _Atomic const restrict T ?[?]( _Atomic const restrict T *, ptrdiff_t );
     824forall( type T ) lvalue _Atomic const volatile T ?[?]( _Atomic const volatile T *, ptrdiff_t );
     825forall( type T ) lvalue _Atomic restrict volatile T ?[?]( _Atomic restrict volatile T *, ptrdiff_t );
     826forall( type T ) lvalue const restrict volatile T ?[?]( const restrict volatile T *, ptrdiff_t );
     827forall( type T ) lvalue _Atomic const restrict volatile T ?[?]( _Atomic const restrict volatile T *, ptrdiff_t );
    751828\end{lstlisting}
    752829\semantics
    753 The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    754 \begin{rationale}
    755 C defines subscripting as pointer arithmetic in a way that makes ©a[i]© and ©i[a]© equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of ©?[?]©.
    756 
    757 Subscript expressions are rewritten as function calls that pass the first parameter by value.
    758 This is somewhat unfortunate, since array-like types tend to be large.
    759 The alternative is to use the rewrite rule ``©a[b] => ?[?](&(a), b)©''.
    760 However, C semantics forbid this approach: the ©a© in ``©a[b]©'' can be an arbitrary pointer value, which does not have an address.
     830The interpretations of subscript expressions are the interpretations of the corresponding function
     831call expressions.
     832\begin{rationale}
     833C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
     834\lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the
     835number of overloadings of \lstinline$?[?]$.
     836
     837Subscript expressions are rewritten as function calls that pass the first parameter by value. This
     838is somewhat unfortunate, since array-like types tend to be large. The alternative is to use the
     839rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''. However, C semantics forbid
     840this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which
     841does not have an address.
    761842
    762843The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
    763  to qualified types} of \CFA's type system.
    764 Type qualifiers are not included in type values, so polymorphic functions that take pointers to arbitrary types often come in one flavor for each possible qualification of the pointed-at type.
     844 to qualified types} of \CFA's type system. Type qualifiers are not included in type values, so
     845polymorphic functions that take pointers to arbitrary types often come in one flavor for each
     846possible qualification of the pointed-at type.
    765847\end{rationale}
    766848
    … …  
    769851
    770852\semantics
    771 A \define{function designator} is an interpretation of an expression that has function type.
    772 The
    773 \nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    774 
    775 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 ``©?()©''.
    776 The valid interpretations of the rewritten expression are determined in the manner described below.
    777 
    778 Each combination of function designators and argument interpretations is considered.
    779 For those interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function} designators, the combination has a \Index{valid interpretation} if the function designator accepts the number of arguments given, and each argument interpretation matches the corresponding explicit parameter:
     853A \define{function designator} is an interpretation of an expression that has function type. The
     854\nonterm{postfix-expression} in a function call may have some interpretations that are function
     855designators and some that are not.
     856
     857For those interpretations of the \nonterm{postfix-expression} that are not function designators, the
     858expression is rewritten and becomes a call of a function named ``\lstinline$?()$''. The valid
     859interpretations of the rewritten expression are determined in the manner described below.
     860
     861Each combination of function designators and argument interpretations is considered. For those
     862interpretations of the \nonterm{postfix-expression} that are \Index{monomorphic function}
     863designators, the combination has a \Index{valid interpretation} if the function designator accepts
     864the number of arguments given, and each argument interpretation matches the corresponding explicit
     865parameter:
    780866\begin{itemize}
    781 \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
    782 \item if the function designator's type does not include a prototype or if the argument corresponds to ``©...©'' in a prototype, a \Index{default argument promotion} is applied to it.
     867\item
     868if the argument corresponds to a parameter in the function designator's prototype, the argument
     869interpretation must have the same type as the corresponding parameter, or be implicitly convertible
     870to the parameter's type
     871\item
     872if the function designator's type does not include a prototype or if the argument corresponds to
     873``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
    783874\end{itemize}
    784875The type of the valid interpretation is the return type of the function designator.
    785876
    786 For those combinations where the interpretation of the \nonterm{postfix-expression} is a \Index{polymorphic function} designator and the function designator accepts the number of arguments given, there shall be at least one set of \define{implicit argument}s for the implicit parameters such that
     877For those combinations where the interpretation of the \nonterm{postfix-expression} is a
     878\Index{polymorphic function} designator and the function designator accepts the number of arguments
     879given, there shall be at least one set of \define{implicit argument}s for the implicit parameters
     880such that
    787881\begin{itemize}
    788882\item
    789 If the declaration of the implicit parameter uses \Index{type-class} ©type©\use{type}, the implicit argument must be an object type;
    790 if it uses ©dtype©, the implicit argument must be an object type or an incomplete type;
    791 and if it uses ©ftype©, the implicit argument must be a function type.
    792 
    793 \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.
    794 
    795 \item the remaining explicit arguments must match the remaining explicit parameters, as described for monomorphic function designators.
    796 
    797 \item for each \Index{assertion parameter} in the function designator's type, there must be an object or function with the same identifier that is visible at the call site and whose type is compatible with or can be specialized to the type of the assertion declaration.
     883If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the
     884implicit argument must be an object type; if it uses \lstinline$dtype$, the implicit argument must
     885be an object type or an incomplete type; and if it uses \lstinline$ftype$, the implicit argument
     886must be a function type.
     887
     888\item
     889if an explicit parameter's type uses any implicit parameters, then the corresponding explicit
     890argument must have a type that is (or can be safely converted\index{safe conversion} to) the type
     891produced by substituting the implicit arguments for the implicit parameters in the explicit
     892parameter type.
     893
     894\item
     895the remaining explicit arguments must match the remaining explicit parameters, as described for
     896monomorphic function designators.
     897
     898\item
     899for each \Index{assertion parameter} in the function designator's type, there must be an object or
     900function with the same identifier that is visible at the call site and whose type is compatible with
     901or can be specialized to the type of the assertion declaration.
    798902\end{itemize}
    799 There is a valid interpretation for each such set of implicit parameters.
    800 The type of each valid interpretation is the return type of the function designator with implicit parameter values substituted for the implicit arguments.
    801 
    802 A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or any of the argument interpretations is ambiguous.
    803 
    804 Every valid interpretation whose return type is not compatible with any other valid interpretation's return type is an interpretation of the function call expression.
    805 
    806 Every set of valid interpretations that have mutually compatible\index{compatible type} result types also produces an interpretation of the function call expression.
    807 The type of the interpretation is the \Index{composite type} of the types of the valid interpretations, and the value of the interpretation is that of the \Index{best valid interpretation}.
    808 \begin{rationale}
    809 One 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}.
    810 For instance, it should be possible to replace a function ``©int f( int );©'' with ``©forall( otype T ) T f( T );©'' without affecting any calls of ©f©.
    811 
    812 \CFA\index{deficiencies!generalizability} does not fully possess this property, because \Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
     903There is a valid interpretation for each such set of implicit parameters. The type of each valid
     904interpretation is the return type of the function designator with implicit parameter values
     905substituted for the implicit arguments.
     906
     907A valid interpretation is ambiguous\index{ambiguous interpretation} if the function designator or
     908any of the argument interpretations is ambiguous.
     909
     910Every valid interpretation whose return type is not compatible with any other valid interpretation's
     911return type is an interpretation of the function call expression.
     912
     913Every set of valid interpretations that have mutually compatible\index{compatible type} result types
     914also produces an interpretation of the function call expression. The type of the interpretation is
     915the \Index{composite type} of the types of the valid interpretations, and the value of the
     916interpretation is that of the \Index{best valid interpretation}.
     917\begin{rationale}
     918One desirable property of a polymorphic programming language is \define{generalizability}: the
     919ability to replace an abstraction with a more general but equivalent abstraction without requiring
     920changes in any of the uses of the original\cite{Cormack90}. For instance, it should be possible to
     921replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( type T ) T f( T );$''
     922without affecting any calls of \lstinline$f$.
     923
     924\CFA\index{deficiencies!generalizability} does not fully possess this property, because
     925\Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
    813926Consider
    814927\begin{lstlisting}
    … …  
    817930float f;
    818931double d;
    819 f = g( f, f );          // (1)
    820 f = g( i, f );          // (2) (safe conversion to float)
    821 f = g( d, f );          // (3) (unsafe conversion to float)
    822 \end{lstlisting}
    823 If ©g© was replaced by ``©forall( otype T ) T g( T, T );©'', the first and second calls would be unaffected, but the third would change: ©f© would be converted to ©double©, and the result would be a ©double©.
    824 
    825 Another example is the function ``©void h( int *);©''.
    826 This function can be passed a ©void *© argument, but the generalization ``©forall( otype T ) void h( T *);©'' can not.
    827 In this case, ©void© is not a valid value for ©T© because it is not an object type.
    828 If unsafe conversions were allowed, ©T© could be inferred to be \emph{any} object type, which is undesirable.
     932f = g( f, f );  // (1)
     933f = g( i, f );  // (2) (safe conversion to float)
     934f = g( d, f );  // (3) (unsafe conversion to float)
     935\end{lstlisting}
     936If \lstinline$g$ was replaced by ``\lstinline$forall( type T ) T g( T, T );$'', the first and second
     937calls would be unaffected, but the third would change: \lstinline$f$ would be converted to
     938\lstinline$double$, and the result would be a \lstinline$double$.
     939
     940Another example is the function ``\lstinline$void h( int *);$''. This function can be passed a
     941\lstinline$void *$ argument, but the generalization ``\lstinline$forall( type T ) void h( T *);$''
     942can not. In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an
     943object type. If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any}
     944object type, which is undesirable.
    829945\end{rationale}
    830946
    831947\examples
    832 A function called ``©?()©'' might be part of a numerical differentiation package.
    833 \begin{lstlisting}
    834 extern otype Derivative;
     948A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
     949\begin{lstlisting}
     950extern type Derivative;
    835951extern double ?()( Derivative, double );
    836952extern Derivative derivative_of( double (*f)( double ) );
    … …  
    841957d = sin_dx( 12.9 );
    842958\end{lstlisting}
    843 Here, the only interpretation of ©sin_dx© is as an object of type ©Derivative©.
    844 For that interpretation, the function call is treated as ``©?()( sin_dx, 12.9 )©''.
    845 \begin{lstlisting}
    846 int f( long );          // (1)
    847 int f( int, int );      // (2)
     959Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$.
     960For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
     961\begin{lstlisting}
     962int f( long );          // (1) 
     963int f( int, int );      // (2) 
    848964int f( int *);          // (3)
     965
    849966int i = f( 5 );         // calls (1)
    850967\end{lstlisting}
    851 Function (1) provides a valid interpretation of ``©f( 5 )©'', using an implicit ©int© to ©long© conversion.
    852 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from ©int© to ©int *© that could be used with the third function.
    853 
    854 \begin{lstlisting}
    855 forall( otype T ) T h( T );
     968Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit
     969\lstinline$int$ to \lstinline$long$ conversion. The other functions do not, since the second
     970requires two arguments, and since there is no implicit conversion from \lstinline$int$ to
     971\lstinline$int *$ that could be used with the third function.
     972
     973\begin{lstlisting}
     974forall( type T ) T h( T );
    856975double d = h( 1.5 );
    857976\end{lstlisting}
    858 ``©1.5©'' is a ©double© constant, so ©T© is inferred to be ©double©, and the result of the function call is a ©double©.
    859 
    860 \begin{lstlisting}
    861 forall( otype T, otype U ) void g( T, U );      // (4)
    862 forall( otype T ) void g( T, T );                       // (5)
    863 forall( otype T ) void g( T, long );            // (6)
    864 void g( long, long );                                           // (7)
     977``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be
     978\lstinline$double$, and the result of the function call is a \lstinline$double$.
     979
     980\begin{lstlisting}
     981forall( type T, type U ) void g( T, U );        // (4)
     982forall( type T ) void g( T, T );                        // (5)
     983forall( type T ) void g( T, long );                     // (6)
     984void g( long, long );                                           // (7)
    865985double d;
    866986int i;
    867987int *p;
    868 g( d, d );                                                                      // calls (5)
    869 g( d, i );                                                                      // calls (6)
    870 g( i, i );                                                                      // calls (7)
    871 g( i, p );                                                                      // calls (4)
    872 \end{lstlisting}
    873 The first call has valid interpretations for all four versions of ©g©. (6) and (7) are discarded because they involve unsafe ©double©-to-©long© conversions. (5) is chosen because it is less polymorphic than (4).
    874 
    875 For the second call, (7) is again discarded.
    876 Of the remaining interpretations for (4), (5), and (6) (with ©i© converted to ©long©), (6) is chosen because it is the least polymorphic.
    877 
    878 The third call has valid interpretations for all of the functions;
    879 (7) is chosen since it is not polymorphic at all.
    880 
    881 The fourth call has no interpretation for (5), because its arguments must have compatible type. (4) is chosen because it does not involve unsafe conversions.
    882 \begin{lstlisting}
    883 forall( otype T ) T min( T, T );
     988
     989g( d, d );                      // calls (5)
     990g( d, i );                      // calls (6)
     991g( i, i );                      // calls (7)
     992g( i, p );                      // calls (4)
     993\end{lstlisting}
     994The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are
     995discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is
     996chosen because it is less polymorphic than (4).
     997
     998For the second call, (7) is again discarded. Of the remaining interpretations for (4), (5), and (6)
     999(with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least
     1000polymorphic.
     1001
     1002The third call has valid interpretations for all of the functions; (7) is chosen since it is not
     1003polymorphic at all.
     1004
     1005The fourth call has no interpretation for (5), because its arguments must have compatible type. (4)
     1006is chosen because it does not involve unsafe conversions.
     1007\begin{lstlisting}
     1008forall( type T ) T min( T, T );
    8841009double max( double, double );
    885 trait min_max( T ) {§\impl{min_max}§
     1010context min_max( T ) {@\impl{min_max}@
    8861011        T min( T, T );
    8871012        T max( T, T );
    8881013}
    889 forall( otype U | min_max( U ) ) void shuffle( U, U );
    890 shuffle( 9, 10 );
    891 \end{lstlisting}
    892 The only possibility for ©U© is ©double©, because that is the type used in the only visible ©max© function. 9 and 10 must be converted to ©double©, and ©min© must be specialized with ©T© bound to ©double©.
    893 \begin{lstlisting}
    894 extern void q( int );                                           // (8)
    895 extern void q( void * );                                        // (9)
     1014forall( type U | min_max( U ) ) void shuffle( U, U );
     1015shuffle(9, 10);
     1016\end{lstlisting}
     1017The only possibility for \lstinline$U$ is \lstinline$double$, because that is the type used in the
     1018only 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$.
     1020\begin{lstlisting}
     1021extern void q( int );           // (8)
     1022extern void q( void * );        // (9)
    8961023extern void r();
    8971024q( 0 );
    8981025r( 0 );
    8991026\end{lstlisting}
    900 The ©int 0© could be passed to (8), or the ©(void *)© \Index{specialization} of the null pointer\index{null pointer} ©0©\use{0} could be passed to (9).
    901 The former is chosen because the ©int© ©0© is \Index{less polymorphic}.
    902 For the same reason, ©int© ©0© is passed to ©r()©, even though it has \emph{no} declared parameter types.
     1027The \lstinline$int 0$ could be passed to (8), or the \lstinline$(void *)$ \Index{specialization} of
     1028the null pointer\index{null pointer} \lstinline$0$\use{0} could be passed to (9). The former is
     1029chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}. For
     1030the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has
     1031\emph{no} declared parameter types.
    9031032
    9041033
    9051034\subsubsection{Structure and union members}
    9061035
    907 \semantics In the member selection expression ``©s©.©m©'', there shall be at least one interpretation of ©s© whose type is a structure type or union type containing a member named ©m©.
    908 If two or more interpretations of ©s© have members named ©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.
    909 If an interpretation of ©s© has a member ©m© whose type is not compatible with any other ©s©'s ©m©, then the expression has an interpretation with the member's type.
    910 The expression has no other interpretations.
    911 
    912 The expression ``©p->m©'' has the same interpretations as the expression ``©(*p).m©''.
     1036\semantics In the member selection expression ``\lstinline$s$.\lstinline$m$'', there shall be at
     1037least one interpretation of \lstinline$s$ whose type is a structure type or union type containing a
     1038member named \lstinline$m$. If two or more interpretations of \lstinline$s$ have members named
     1039\lstinline$m$ with mutually compatible types, then the expression has an \Index{ambiguous
     1040interpretation} whose type is the composite type of the types of the members. If an interpretation
     1041of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
     1042\lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type. The
     1043expression has no other interpretations.
     1044
     1045The expression ``\lstinline$p->m$'' has the same interpretations as the expression
     1046``\lstinline$(*p).m$''.
    9131047
    9141048
    9151049\subsubsection{Postfix increment and decrement operators}
    9161050
    917 \predefined
    918 \begin{lstlisting}
    919 _Bool ?++( volatile _Bool * ), ?++( _Atomic volatile _Bool * );
    920 char ?++( volatile char * ), ?++( _Atomic volatile char * );
    921 signed char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * );
    922 unsigned char ?++( volatile signed char * ), ?++( _Atomic volatile signed char * );
    923 short int ?++( volatile short int * ), ?++( _Atomic volatile short int * );
    924 unsigned short int ?++( volatile unsigned short int * ), ?++( _Atomic volatile unsigned short int * );
    925 int ?++( volatile int * ), ?++( _Atomic volatile int * );
    926 unsigned int ?++( volatile unsigned int * ), ?++( _Atomic volatile unsigned int * );
    927 long int ?++( volatile long int * ), ?++( _Atomic volatile long int * );
    928 long unsigned int ?++( volatile long unsigned int * ), ?++( _Atomic volatile long unsigned int * );
    929 long long int ?++( volatile long long int * ), ?++( _Atomic volatile long long int * );
    930 long long unsigned ?++( volatile long long unsigned int * ), ?++( _Atomic volatile long long unsigned int * );
    931 float ?++( volatile float * ), ?++( _Atomic volatile float * );
    932 double ?++( volatile double * ), ?++( _Atomic volatile double * );
    933 long double ?++( volatile long double * ), ?++( _Atomic volatile long double * );
    934 
    935 forall( otype T ) T * ?++( T * restrict volatile * ), * ?++( T * _Atomic restrict volatile * );
    936 forall( otype T ) _Atomic T * ?++( _Atomic T * restrict volatile * ), * ?++( _Atomic T * _Atomic restrict volatile * );
    937 forall( otype T ) const T * ?++( const T * restrict volatile * ), * ?++( const T * _Atomic restrict volatile * );
    938 forall( otype T ) volatile T * ?++( volatile T * restrict volatile * ), * ?++( volatile T * _Atomic restrict volatile * );
    939 forall( otype T ) restrict T * ?++( restrict T * restrict volatile * ), * ?++( restrict T * _Atomic restrict volatile * );
    940 forall( otype T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
     1051\begin{lstlisting}
     1052_Bool ?++( volatile _Bool * ),
     1053        ?++( _Atomic volatile _Bool * );
     1054char ?++( volatile char * ),
     1055        ?++( _Atomic volatile char * );
     1056signed char ?++( volatile signed char * ),
     1057        ?++( _Atomic volatile signed char * );
     1058unsigned char ?++( volatile signed char * ),
     1059        ?++( _Atomic volatile signed char * );
     1060short int ?++( volatile short int * ),
     1061        ?++( _Atomic volatile short int * );
     1062unsigned short int ?++( volatile unsigned short int * ),
     1063        ?++( _Atomic volatile unsigned short int * );
     1064int ?++( volatile int * ),
     1065        ?++( _Atomic volatile int * );
     1066unsigned int ?++( volatile unsigned int * ),
     1067        ?++( _Atomic volatile unsigned int * );
     1068long int ?++( volatile long int * ),
     1069        ?++( _Atomic volatile long int * );
     1070long unsigned int ?++( volatile long unsigned int * ),
     1071        ?++( _Atomic volatile long unsigned int * );
     1072long long int ?++( volatile long long int * ),
     1073        ?++( _Atomic volatile long long int * );
     1074long long unsigned ?++( volatile long long unsigned int * ),
     1075        ?++( _Atomic volatile long long unsigned int * );
     1076float ?++( volatile float * ),
     1077        ?++( _Atomic volatile float * );
     1078double ?++( volatile double * ),
     1079        ?++( _Atomic volatile double * );
     1080long double ?++( volatile long double * ),
     1081        ?++( _Atomic volatile long double * );
     1082
     1083forall( type T ) T * ?++( T * restrict volatile * ),
     1084        * ?++( T * _Atomic restrict volatile * );
     1085
     1086forall( type T ) _Atomic T * ?++( _Atomic T * restrict volatile * ),
     1087        * ?++( _Atomic T * _Atomic restrict volatile * );
     1088
     1089forall( type T ) const T * ?++( const T * restrict volatile * ),
     1090        * ?++( const T * _Atomic restrict volatile * );
     1091
     1092forall( type T ) volatile T * ?++( volatile T * restrict volatile * ),
     1093        * ?++( volatile T * _Atomic restrict volatile * );
     1094
     1095forall( type T ) restrict T * ?++( restrict T * restrict volatile * ),
     1096        * ?++( restrict T * _Atomic restrict volatile * );
     1097
     1098forall( type T ) _Atomic const T * ?++( _Atomic const T * restrict volatile * ),
    9411099        * ?++( _Atomic const T * _Atomic restrict volatile * );
    942 forall( otype T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
     1100
     1101forall( type T ) _Atomic restrict T * ?++( _Atomic restrict T * restrict volatile * ),
    9431102        * ?++( _Atomic restrict T * _Atomic restrict volatile * );
    944 forall( otype T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
     1103
     1104forall( type T ) _Atomic volatile T * ?++( _Atomic volatile T * restrict volatile * ),
    9451105        * ?++( _Atomic volatile T * _Atomic restrict volatile * );
    946 forall( otype T ) const restrict T * ?++( const restrict T * restrict volatile * ),
     1106
     1107forall( type T ) const restrict T * ?++( const restrict T * restrict volatile * ),
    9471108        * ?++( const restrict T * _Atomic restrict volatile * );
    948 forall( otype T ) const volatile T * ?++( const volatile T * restrict volatile * ),
     1109
     1110forall( type T ) const volatile T * ?++( const volatile T * restrict volatile * ),
    9491111        * ?++( const volatile T * _Atomic restrict volatile * );
    950 forall( otype T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
     1112
     1113forall( type T ) restrict volatile T * ?++( restrict volatile T * restrict volatile * ),
    9511114        * ?++( restrict volatile T * _Atomic restrict volatile * );
    952 forall( otype T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
     1115
     1116forall( type T ) _Atomic const restrict T * ?++( _Atomic const restrict T * restrict volatile * ),
    9531117        * ?++( _Atomic const restrict T * _Atomic restrict volatile * );
    954 forall( otype T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
     1118
     1119forall( type T ) _Atomic const volatile T * ?++( _Atomic const volatile T * restrict volatile * ),
    9551120        * ?++( _Atomic const volatile T * _Atomic restrict volatile * );
    956 forall( otype T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
     1121
     1122forall( type T ) _Atomic restrict volatile T * ?++( _Atomic restrict volatile T * restrict volatile * ),
    9571123        * ?++( _Atomic restrict volatile T * _Atomic restrict volatile * );
    958 forall( otype T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
     1124
     1125forall( type T ) const restrict volatile T * ?++( const restrict volatile T * restrict volatile * ),
    9591126        * ?++( const restrict volatile T * _Atomic restrict volatile * );
    960 forall( otype T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
     1127
     1128forall( type T ) _Atomic const restrict volatile T * ?++( _Atomic const restrict volatile T * restrict volatile * ),
    9611129        * ?++( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    9621130
    963 _Bool ?--( volatile _Bool * ), ?--( _Atomic volatile _Bool * );
    964 char ?--( volatile char * ), ?--( _Atomic volatile char * );
    965 signed char ?--( volatile signed char * ), ?--( _Atomic volatile signed char * );
    966 unsigned char ?--( volatile signed char * ), ?--( _Atomic volatile signed char * );
    967 short int ?--( volatile short int * ), ?--( _Atomic volatile short int * );
    968 unsigned short int ?--( volatile unsigned short int * ), ?--( _Atomic volatile unsigned short int * );
    969 int ?--( volatile int * ), ?--( _Atomic volatile int * );
    970 unsigned int ?--( volatile unsigned int * ), ?--( _Atomic volatile unsigned int * );
    971 long int ?--( volatile long int * ), ?--( _Atomic volatile long int * );
    972 long unsigned int ?--( volatile long unsigned int * ), ?--( _Atomic volatile long unsigned int * );
    973 long long int ?--( volatile long long int * ), ?--( _Atomic volatile long long int * );
    974 long long unsigned ?--( volatile long long unsigned int * ), ?--( _Atomic volatile long long unsigned int * );
    975 float ?--( volatile float * ), ?--( _Atomic volatile float * );
    976 double ?--( volatile double * ), ?--( _Atomic volatile double * );
    977 long double ?--( volatile long double * ), ?--( _Atomic volatile long double * );
    978 
    979 forall( otype T ) T * ?--( T * restrict volatile * ), * ?--( T * _Atomic restrict volatile * );
    980 forall( otype T ) _Atomic T * ?--( _Atomic T * restrict volatile * ), * ?--( _Atomic T * _Atomic restrict volatile * );
    981 forall( otype T ) const T * ?--( const T * restrict volatile * ), * ?--( const T * _Atomic restrict volatile * );
    982 forall( otype T ) volatile T * ?--( volatile T * restrict volatile * ), * ?--( volatile T * _Atomic restrict volatile * );
    983 forall( otype T ) restrict T * ?--( restrict T * restrict volatile * ), * ?--( restrict T * _Atomic restrict volatile * );
    984 forall( otype T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
     1131_Bool ?--( volatile _Bool * ),
     1132        ?--( _Atomic volatile _Bool * );
     1133char ?--( volatile char * ),
     1134        ?--( _Atomic volatile char * );
     1135signed char ?--( volatile signed char * ),
     1136        ?--( _Atomic volatile signed char * );
     1137unsigned char ?--( volatile signed char * ),
     1138        ?--( _Atomic volatile signed char * );
     1139short int ?--( volatile short int * ),
     1140        ?--( _Atomic volatile short int * );
     1141unsigned short int ?--( volatile unsigned short int * ),
     1142        ?--( _Atomic volatile unsigned short int * );
     1143int ?--( volatile int * ),
     1144        ?--( _Atomic volatile int * );
     1145unsigned int ?--( volatile unsigned int * ),
     1146        ?--( _Atomic volatile unsigned int * );
     1147long int ?--( volatile long int * ),
     1148        ?--( _Atomic volatile long int * );
     1149long unsigned int ?--( volatile long unsigned int * ),
     1150        ?--( _Atomic volatile long unsigned int * );
     1151long long int ?--( volatile long long int * ),
     1152        ?--( _Atomic volatile long long int * );
     1153long long unsigned ?--( volatile long long unsigned int * ),
     1154        ?--( _Atomic volatile long long unsigned int * );
     1155float ?--( volatile float * ),
     1156        ?--( _Atomic volatile float * );
     1157double ?--( volatile double * ),
     1158        ?--( _Atomic volatile double * );
     1159long double ?--( volatile long double * ),
     1160        ?--( _Atomic volatile long double * );
     1161
     1162forall( type T ) T * ?--( T * restrict volatile * ),
     1163        * ?--( T * _Atomic restrict volatile * );
     1164
     1165forall( type T ) _Atomic T * ?--( _Atomic T * restrict volatile * ),
     1166        * ?--( _Atomic T * _Atomic restrict volatile * );
     1167
     1168forall( type T ) const T * ?--( const T * restrict volatile * ),
     1169        * ?--( const T * _Atomic restrict volatile * );
     1170
     1171forall( type T ) volatile T * ?--( volatile T * restrict volatile * ),
     1172        * ?--( volatile T * _Atomic restrict volatile * );
     1173
     1174forall( type T ) restrict T * ?--( restrict T * restrict volatile * ),
     1175        * ?--( restrict T * _Atomic restrict volatile * );
     1176
     1177forall( type T ) _Atomic const T * ?--( _Atomic const T * restrict volatile * ),
    9851178        * ?--( _Atomic const T * _Atomic restrict volatile * );
    986 forall( otype T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
     1179
     1180forall( type T ) _Atomic restrict T * ?--( _Atomic restrict T * restrict volatile * ),
    9871181        * ?--( _Atomic restrict T * _Atomic restrict volatile * );
    988 forall( otype T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
     1182
     1183forall( type T ) _Atomic volatile T * ?--( _Atomic volatile T * restrict volatile * ),
    9891184        * ?--( _Atomic volatile T * _Atomic restrict volatile * );
    990 forall( otype T ) const restrict T * ?--( const restrict T * restrict volatile * ),
     1185
     1186forall( type T ) const restrict T * ?--( const restrict T * restrict volatile * ),
    9911187        * ?--( const restrict T * _Atomic restrict volatile * );
    992 forall( otype T ) const volatile T * ?--( const volatile T * restrict volatile * ),
     1188
     1189forall( type T ) const volatile T * ?--( const volatile T * restrict volatile * ),
    9931190        * ?--( const volatile T * _Atomic restrict volatile * );
    994 forall( otype T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
     1191
     1192forall( type T ) restrict volatile T * ?--( restrict volatile T * restrict volatile * ),
    9951193        * ?--( restrict volatile T * _Atomic restrict volatile * );
    996 forall( otype T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
     1194
     1195forall( type T ) _Atomic const restrict T * ?--( _Atomic const restrict T * restrict volatile * ),
    9971196        * ?--( _Atomic const restrict T * _Atomic restrict volatile * );
    998 forall( otype T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
     1197
     1198forall( type T ) _Atomic const volatile T * ?--( _Atomic const volatile T * restrict volatile * ),
    9991199        * ?--( _Atomic const volatile T * _Atomic restrict volatile * );
    1000 forall( otype T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
     1200
     1201forall( type T ) _Atomic restrict volatile T * ?--( _Atomic restrict volatile T * restrict volatile * ),
    10011202        * ?--( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1002 forall( otype T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
     1203
     1204forall( type T ) const restrict volatile T * ?--( const restrict volatile T * restrict volatile * ),
    10031205        * ?--( const restrict volatile T * _Atomic restrict volatile * );
    1004 forall( otype T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
     1206
     1207forall( type T ) _Atomic const restrict volatile T * ?--( _Atomic const restrict volatile T * restrict volatile * ),
    10051208        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    10061209\end{lstlisting}
    1007 For every extended integer type ©X© there exist
     1210For every extended integer type \lstinline$X$ there exist
    10081211% Don't use predefined: keep this out of prelude.cf.
    10091212\begin{lstlisting}
    … …  
    10111214  ?--( volatile X * ), ?--( _Atomic volatile X * );
    10121215\end{lstlisting}
    1013 For every complete enumerated type ©E© there exist
     1216For every complete enumerated type \lstinline$E$ there exist
    10141217% Don't use predefined: keep this out of prelude.cf.
    10151218\begin{lstlisting}
    … …  
    10191222
    10201223\begin{rationale}
    1021 Note that ``©++©'' and ``©--©'' 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.
    1022 This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    1023 \end{rationale}
    1024 
    1025 \begin{rationale}
    1026 In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
    1027 Hence, ©void *© objects cannot be incremented.
    1028 In \CFA, the restriction follows from the use of a ©type© parameter in the predefined function definitions, as opposed to ©dtype©, since only object types can be inferred arguments corresponding to the type parameter ©T©.
     1224Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a
     1225pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald
     1226has pointed out, this forces the modified operand of such expressions to be an lvalue. This
     1227partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
     1228\end{rationale}
     1229
     1230\begin{rationale}
     1231In C, a semantic rule requires that pointer operands of increment and decrement be pointers to
     1232object types. Hence, \lstinline$void *$ objects cannot be incremented. In \CFA, the restriction
     1233follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as
     1234opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the
     1235type parameter \lstinline$T$.
    10291236\end{rationale}
    10301237
    10311238\semantics
    1032 First, each interpretation of the operand of an increment or decrement expression is considered separately.
    1033 For 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.
    1034 
    1035 For the remaining interpretations, the expression is rewritten, and the interpretations of the expression are the interpretations of the corresponding function call.
    1036 Finally, all interpretations of the expression produced for the different interpretations of the operand are combined to produce the interpretations of the expression as a whole; where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions.
     1239First, each interpretation of the operand of an increment or decrement expression is considered
     1240separately. For each interpretation that is a bit-field or is declared with the
     1241\lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the
     1242expression has one valid interpretation, with the type of the operand, and the expression is
     1243ambiguous if the operand is.
     1244
     1245For the remaining interpretations, the expression is rewritten, and the interpretations of the
     1246expression are the interpretations of the corresponding function call. Finally, all interpretations
     1247of the expression produced for the different interpretations of the operand are combined to produce
     1248the interpretations of the expression as a whole; where interpretations have compatible result
     1249types, the best interpretations are selected in the manner described for function call expressions.
    10371250
    10381251\examples
    … …  
    10441257\end{lstlisting}
    10451258\begin{sloppypar}
    1046 Since ©&(vs)© has type ©volatile short int *©, the best valid interpretation of ©vs++© calls the ©?++© function with the ©volatile short *© parameter.
    1047 ©s++© does the same, applying the safe conversion from ©short int *© to ©volatile short int *©.
    1048 Note that there is no conversion that adds an ©_Atomic© qualifier, so the ©_Atomic volatile short int© overloading does not provide a valid interpretation.
     1259Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of
     1260\lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
     1261\lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
     1262\lstinline$volatile short int *$. Note that there is no conversion that adds an \lstinline$_Atomic$
     1263qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid
     1264interpretation.
    10491265\end{sloppypar}
    10501266
    1051 There is no safe conversion from ©const short int *© to ©volatile short int *©, and no ©?++© function that accepts a ©const *© parameter, so ©cs++© has no valid interpretations.
    1052 
    1053 The best valid interpretation of ©as++© calls the ©short ?++© function with the ©_Atomic volatile short int *© parameter, applying a safe conversion to add the ©volatile© qualifier.
    1054 \begin{lstlisting}
    1055 char * const restrict volatile * restrict volatile pqpc;
    1056 pqpc++
    1057 char * * restrict volatile ppc;
    1058 ppc++;
    1059 \end{lstlisting}
    1060 Since ©&(pqpc)© has type ©char * const restrict volatile * restrict volatile *©, the best valid interpretation of ©pqpc++© calls the polymorphic ©?++© function with the ©const restrict volatile T * restrict volatile *© parameter, inferring ©T© to be ©char *©.
    1061 
    1062 ©ppc++© calls the same function, again inferring ©T© to be ©char *©, and using the safe conversions from ©T© to ©T const© ©restrict volatile©.
    1063 
    1064 \begin{rationale}
    1065 Increment and decrement expressions show up a deficiency of \CFA's type system.
    1066 There is no such thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
    1067 Therefore, there is no way to define a function that alters them, and hence no way to define increment and decrement functions for them.
    1068 As a result, the semantics of increment and decrement expressions must treat them specially.
    1069 This holds true for all of the operators that may modify such objects.
    1070 \end{rationale}
    1071 
    1072 \begin{rationale}
    1073 The polymorphic overloadings for pointer increment and decrement can be understood by considering increasingly complex types.
     1267There is no safe conversion from \lstinline$const short int *$ to \lstinline$volatile short int *$,
     1268and no \lstinline$?++$ function that accepts a \lstinline$const *$ parameter, so \lstinline$cs++$
     1269has no valid interpretations.
     1270
     1271The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the
     1272\lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the
     1273\lstinline$volatile$ qualifier.
     1274
     1275\begin{lstlisting}
     1276char * const restrict volatile * restrict volatile pqpc; pqpc++
     1277char * * restrict volatile ppc; ppc++;
     1278\end{lstlisting}
     1279Since \lstinline$&(pqpc)$ has type \lstinline$char * const restrict volatile * restrict volatile *$,
     1280the best valid interpretation of \lstinline$pqpc++$ calls the polymorphic \lstinline$?++$ function
     1281with the \lstinline$const restrict volatile T * restrict volatile *$ parameter, inferring
     1282\lstinline$T$ to be \lstinline$char *$.
     1283
     1284\begin{sloppypar}
     1285\lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$,
     1286and using the safe conversions from \lstinline$T$ to \lstinline$T const restrict volatile$.
     1287\end{sloppypar}
     1288
     1289\begin{rationale}
     1290Increment and decrement expressions show up a deficiency of \CFA's type system. There is no such
     1291thing as a pointer to a register object or bit-field\index{deficiencies!pointers to bit-fields}.
     1292Therefore, there is no way to define a function that alters them, and hence no way to define
     1293increment and decrement functions for them. As a result, the semantics of increment and decrement
     1294expressions must treat them specially. This holds true for all of the operators that may modify
     1295such objects.
     1296\end{rationale}
     1297
     1298\begin{rationale}
     1299The polymorphic overloadings for pointer increment and decrement can be understood by considering
     1300increasingly complex types.
    10741301\begin{enumerate}
    10751302\item
    1076 ``©char * p; p++;©''.
    1077 The argument to ©?++© has type ©char * *©, and the result has type ©char *©.
    1078 The expression would be valid if ©?++© were declared by
    1079 \begin{lstlisting}
    1080 forall( otype T ) T * ?++( T * * );
    1081 \end{lstlisting} with ©T© inferred to be ©char©.
    1082 
    1083 \item
    1084 ``©char *restrict volatile qp; qp++©''.
    1085 The result again has type ©char *©, but the argument now has type ©char *restrict volatile *©, so it cannot be passed to the hypothetical function declared in point 1.
    1086 Hence the actual predefined function is
    1087 \begin{lstlisting}
    1088 forall( otype T ) T * ?++( T * restrict volatile * );
    1089 \end{lstlisting} which also accepts a ©char * *© argument, because of the safe conversions that add ©volatile© and ©restrict© qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
    1090 
    1091 \item
    1092 ``©char *_Atomic ap; ap++©''.
    1093 The result again has type ©char *©, but no safe conversion adds an ©_Atomic© qualifier, so the function in point 2 is not applicable.
    1094 A separate overloading of ©?++© is required.
    1095 
    1096 \item
    1097 ``©char const volatile * pq; pq++©''.
    1098 Here the result has type ©char const volatile *©, so a new overloading is needed:
    1099 \begin{lstlisting}
    1100 forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
    1101 \end{lstlisting}
    1102 One overloading is needed for each combination of qualifiers in the pointed-at type\index{deficiencies!pointers to qualified types}.
     1303``\lstinline$char * p; p++;$''. The argument to \lstinline$?++$ has type \lstinline$char * *$, and
     1304the result has type \lstinline$char *$. The expression would be valid if \lstinline$?++$ were
     1305declared by
     1306\begin{lstlisting}
     1307forall( type T ) T * ?++( T * * );
     1308\end{lstlisting}
     1309with \lstinline$T$ inferred to be \lstinline$char$.
     1310
     1311\item
     1312``\lstinline$char *restrict volatile qp; qp++$''. The result again has type \lstinline$char *$, but
     1313the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the
     1314hypothetical function declared in point 1. Hence the actual predefined function is
     1315\begin{lstlisting}
     1316forall( type T ) T * ?++( T * restrict volatile * );
     1317\end{lstlisting}
     1318which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
     1319\lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so
     1320constant pointers cannot be incremented.)
     1321
     1322\item
     1323``\lstinline$char *_Atomic ap; ap++$''. The result again has type \lstinline$char *$, but no safe
     1324conversion adds an \lstinline$_Atomic$ qualifier, so the function in point 2 is not applicable. A
     1325separate overloading of \lstinline$?++$ is required.
     1326
     1327\item
     1328``\lstinline$char const volatile * pq; pq++$''. Here the result has type
     1329\lstinline$char const volatile *$, so a new overloading is needed:
     1330\begin{lstlisting}
     1331forall( type T ) T const volatile * ?++( T const volatile *restrict volatile * );
     1332\end{lstlisting}
     1333One overloading is needed for each combination of qualifiers in the pointed-at
     1334type\index{deficiencies!pointers to qualified types}.
    11031335 
    11041336\item
    1105 ``©float *restrict * prp; prp++©''.
    1106 The ©restrict© qualifier is handled just like ©const© and ©volatile© in the previous case:
    1107 \begin{lstlisting}
    1108 forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    1109 \end{lstlisting} with ©T© inferred to be ©float *©.
    1110 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and ©T© is not syntactically a pointer type. \CFA loosens the constraint.
     1337``\lstinline$float *restrict * prp; prp++$''. The \lstinline$restrict$ qualifier is handled just
     1338like \lstinline$const$ and \lstinline$volatile$ in the previous case:
     1339\begin{lstlisting}
     1340forall( type T ) T restrict * ?++( T restrict *restrict volatile * );
     1341\end{lstlisting}
     1342with \lstinline$T$ inferred to be \lstinline$float *$. This looks odd, because {\c11} contains a
     1343constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$
     1344is not syntactically a pointer type. \CFA loosens the constraint.
    11111345\end{enumerate}
    11121346\end{rationale}
    … …  
    11161350
    11171351\semantics
    1118 A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the compound literal.
     1352A compound literal has one interpretation, with the type given by the \nonterm{type-name} of the
     1353compound literal.
    11191354
    11201355
    … …  
    11231358\begin{syntax}
    11241359\lhs{unary-expression}
    1125         \rhs \nonterm{postfix-expression}
    1126         \rhs ©++© \nonterm{unary-expression}
    1127         \rhs ©--© \nonterm{unary-expression}
    1128         \rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1129         \rhs ©sizeof© \nonterm{unary-expression}
    1130         \rhs ©sizeof© ©(© \nonterm{type-name} ©)©
    1131 \lhs{unary-operator} one of
    1132         \rhs ©&© ©*© ©+© ©-© ©~© ©!©
     1360\rhs \nonterm{postfix-expression}
     1361\rhs \lstinline$++$ \nonterm{unary-expression}
     1362\rhs \lstinline$--$ \nonterm{unary-expression}
     1363\rhs \nonterm{unary-operator} \nonterm{cast-expression}
     1364\rhs \lstinline$sizeof$ \nonterm{unary-expression}
     1365\rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$
     1366\lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$
    11331367\end{syntax}
    11341368
    11351369\rewriterules
    11361370\begin{lstlisting}
    1137 *a      => *?( a )§\use{*?}§
    1138 +a      => +?( a )§\use{+?}§
    1139 -a      => -?( a )§\use{-?}§
    1140 ~a      => ~?( a )§\use{~?}§
    1141 !a      => !?( a )§\use{"!?}§
    1142 ++a     => ++?(&( a ))§\use{++?}§
    1143 --a     => --?(&( a ))§\use{--?}§
     1371*a      @\rewrite@ *?(a) @\use{*?}@
     1372+a      @\rewrite@ +?(a) @\use{+?}@
     1373-a      @\rewrite@ -?(a) @\use{-?}@
     1374~a      @\rewrite@ ~?(a) @\use{~?}@
     1375!a      @\rewrite@ !?(a) @\use{"!?}@
     1376++a     @\rewrite@ ++?(&(a)) @\use{++?}@
     1377--a     @\rewrite@ --?(&(a)) @\use{--?}@
    11441378\end{lstlisting}
    11451379
    … …  
    11471381\subsubsection{Prefix increment and decrement operators}
    11481382
    1149 \predefined
    1150 \begin{lstlisting}
    1151 _Bool ++?( volatile _Bool * ), ++?( _Atomic volatile _Bool * );
    1152 char ++?( volatile char * ), ++?( _Atomic volatile char * );
    1153 signed char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * );
    1154 unsigned char ++?( volatile signed char * ), ++?( _Atomic volatile signed char * );
    1155 short int ++?( volatile short int * ), ++?( _Atomic volatile short int * );
    1156 unsigned short int ++?( volatile unsigned short int * ), ++?( _Atomic volatile unsigned short int * );
    1157 int ++?( volatile int * ), ++?( _Atomic volatile int * );
    1158 unsigned int ++?( volatile unsigned int * ), ++?( _Atomic volatile unsigned int * );
    1159 long int ++?( volatile long int * ), ++?( _Atomic volatile long int * );
    1160 long unsigned int ++?( volatile long unsigned int * ), ++?( _Atomic volatile long unsigned int * );
    1161 long long int ++?( volatile long long int * ), ++?( _Atomic volatile long long int * );
    1162 long long unsigned ++?( volatile long long unsigned int * ), ++?( _Atomic volatile long long unsigned int * );
    1163 float ++?( volatile float * ), ++?( _Atomic volatile float * );
    1164 double ++?( volatile double * ), ++?( _Atomic volatile double * );
    1165 long double ++?( volatile long double * ), ++?( _Atomic volatile long double * );
    1166 
    1167 forall( otype T ) T * ++?( T * restrict volatile * ), * ++?( T * _Atomic restrict volatile * );
    1168 forall( otype T ) _Atomic T * ++?( _Atomic T * restrict volatile * ), * ++?( _Atomic T * _Atomic restrict volatile * );
    1169 forall( otype T ) const T * ++?( const T * restrict volatile * ), * ++?( const T * _Atomic restrict volatile * );
    1170 forall( otype T ) volatile T * ++?( volatile T * restrict volatile * ), * ++?( volatile T * _Atomic restrict volatile * );
    1171 forall( otype T ) restrict T * ++?( restrict T * restrict volatile * ), * ++?( restrict T * _Atomic restrict volatile * );
    1172 forall( otype T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
     1383\begin{lstlisting}
     1384_Bool ++?( volatile _Bool * ),
     1385        ++?( _Atomic volatile _Bool * );
     1386char ++?( volatile char * ),
     1387        ++?( _Atomic volatile char * );
     1388signed char ++?( volatile signed char * ),
     1389        ++?( _Atomic volatile signed char * );
     1390unsigned char ++?( volatile signed char * ),
     1391        ++?( _Atomic volatile signed char * );
     1392short int ++?( volatile short int * ),
     1393        ++?( _Atomic volatile short int * );
     1394unsigned short int ++?( volatile unsigned short int * ),
     1395        ++?( _Atomic volatile unsigned short int * );
     1396int ++?( volatile int * ),
     1397        ++?( _Atomic volatile int * );
     1398unsigned int ++?( volatile unsigned int * ),
     1399        ++?( _Atomic volatile unsigned int * );
     1400long int ++?( volatile long int * ),
     1401        ++?( _Atomic volatile long int * );
     1402long unsigned int ++?( volatile long unsigned int * ),
     1403        ++?( _Atomic volatile long unsigned int * );
     1404long long int ++?( volatile long long int * ),
     1405        ++?( _Atomic volatile long long int * );
     1406long long unsigned ++?( volatile long long unsigned int * ),
     1407        ++?( _Atomic volatile long long unsigned int * );
     1408float ++?( volatile float * ),
     1409        ++?( _Atomic volatile float * );
     1410double ++?( volatile double * ),
     1411        ++?( _Atomic volatile double * );
     1412long double ++?( volatile long double * ),
     1413        ++?( _Atomic volatile long double * );
     1414
     1415forall( type T ) T * ++?( T * restrict volatile * ),
     1416        * ++?( T * _Atomic restrict volatile * );
     1417
     1418forall( type T ) _Atomic T * ++?( _Atomic T * restrict volatile * ),
     1419        * ++?( _Atomic T * _Atomic restrict volatile * );
     1420
     1421forall( type T ) const T * ++?( const T * restrict volatile * ),
     1422        * ++?( const T * _Atomic restrict volatile * );
     1423
     1424forall( type T ) volatile T * ++?( volatile T * restrict volatile * ),
     1425        * ++?( volatile T * _Atomic restrict volatile * );
     1426
     1427forall( type T ) restrict T * ++?( restrict T * restrict volatile * ),
     1428        * ++?( restrict T * _Atomic restrict volatile * );
     1429
     1430forall( type T ) _Atomic const T * ++?( _Atomic const T * restrict volatile * ),
    11731431        * ++?( _Atomic const T * _Atomic restrict volatile * );
    1174 forall( otype T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
     1432
     1433forall( type T ) _Atomic volatile T * ++?( _Atomic volatile T * restrict volatile * ),
    11751434        * ++?( _Atomic volatile T * _Atomic restrict volatile * );
    1176 forall( otype T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
     1435
     1436forall( type T ) _Atomic restrict T * ++?( _Atomic restrict T * restrict volatile * ),
    11771437        * ++?( _Atomic restrict T * _Atomic restrict volatile * );
    1178 forall( otype T ) const volatile T * ++?( const volatile T * restrict volatile * ),
     1438
     1439forall( type T ) const volatile T * ++?( const volatile T * restrict volatile * ),
    11791440        * ++?( const volatile T * _Atomic restrict volatile * );
    1180 forall( otype T ) const restrict T * ++?( const restrict T * restrict volatile * ),
     1441
     1442forall( type T ) const restrict T * ++?( const restrict T * restrict volatile * ),
    11811443        * ++?( const restrict T * _Atomic restrict volatile * );
    1182 forall( otype T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
     1444
     1445forall( type T ) restrict volatile T * ++?( restrict volatile T * restrict volatile * ),
    11831446        * ++?( restrict volatile T * _Atomic restrict volatile * );
    1184 forall( otype T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
     1447
     1448forall( type T ) _Atomic const volatile T * ++?( _Atomic const volatile T * restrict volatile * ),
    11851449        * ++?( _Atomic const volatile T * _Atomic restrict volatile * );
    1186 forall( otype T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
     1450
     1451forall( type T ) _Atomic const restrict T * ++?( _Atomic const restrict T * restrict volatile * ),
    11871452        * ++?( _Atomic const restrict T * _Atomic restrict volatile * );
    1188 forall( otype T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
     1453
     1454forall( type T ) _Atomic restrict volatile T * ++?( _Atomic restrict volatile T * restrict volatile * ),
    11891455        * ++?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1190 forall( otype T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
     1456
     1457forall( type T ) const restrict volatile T * ++?( const restrict volatile T * restrict volatile * ),
    11911458        * ++?( const restrict volatile T * _Atomic restrict volatile * );
    1192 forall( otype T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
     1459
     1460forall( type T ) _Atomic const restrict volatile T * ++?( _Atomic const restrict volatile T * restrict volatile * ),
    11931461        * ++?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    11941462
    1195 _Bool --?( volatile _Bool * ), --?( _Atomic volatile _Bool * );
    1196 char --?( volatile char * ), --?( _Atomic volatile char * );
    1197 signed char --?( volatile signed char * ), --?( _Atomic volatile signed char * );
    1198 unsigned char --?( volatile signed char * ), --?( _Atomic volatile signed char * );
    1199 short int --?( volatile short int * ), --?( _Atomic volatile short int * );
    1200 unsigned short int --?( volatile unsigned short int * ), --?( _Atomic volatile unsigned short int * );
    1201 int --?( volatile int * ), --?( _Atomic volatile int * );
    1202 unsigned int --?( volatile unsigned int * ), --?( _Atomic volatile unsigned int * );
    1203 long int --?( volatile long int * ), --?( _Atomic volatile long int * );
    1204 long unsigned int --?( volatile long unsigned int * ), --?( _Atomic volatile long unsigned int * );
    1205 long long int --?( volatile long long int * ), --?( _Atomic volatile long long int * );
    1206 long long unsigned --?( volatile long long unsigned int * ), --?( _Atomic volatile long long unsigned int * );
    1207 float --?( volatile float * ), --?( _Atomic volatile float * );
    1208 double --?( volatile double * ), --?( _Atomic volatile double * );
    1209 long double --?( volatile long double * ), --?( _Atomic volatile long double * );
    1210 
    1211 forall( otype T ) T * --?( T * restrict volatile * ), * --?( T * _Atomic restrict volatile * );
    1212 forall( otype T ) _Atomic T * --?( _Atomic T * restrict volatile * ), * --?( _Atomic T * _Atomic restrict volatile * );
    1213 forall( otype T ) const T * --?( const T * restrict volatile * ), * --?( const T * _Atomic restrict volatile * );
    1214 forall( otype T ) volatile T * --?( volatile T * restrict volatile * ), * --?( volatile T * _Atomic restrict volatile * );
    1215 forall( otype T ) restrict T * --?( restrict T * restrict volatile * ), * --?( restrict T * _Atomic restrict volatile * );
    1216 forall( otype T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
     1463_Bool --?( volatile _Bool * ),
     1464        --?( _Atomic volatile _Bool * );
     1465char --?( volatile char * ),
     1466        --?( _Atomic volatile char * );
     1467signed char --?( volatile signed char * ),
     1468        --?( _Atomic volatile signed char * );
     1469unsigned char --?( volatile signed char * ),
     1470        --?( _Atomic volatile signed char * );
     1471short int --?( volatile short int * ),
     1472        --?( _Atomic volatile short int * );
     1473unsigned short int --?( volatile unsigned short int * ),
     1474        --?( _Atomic volatile unsigned short int * );
     1475int --?( volatile int * ),
     1476        --?( _Atomic volatile int * );
     1477unsigned int --?( volatile unsigned int * ),
     1478        --?( _Atomic volatile unsigned int * );
     1479long int --?( volatile long int * ),
     1480        --?( _Atomic volatile long int * );
     1481long unsigned int --?( volatile long unsigned int * ),
     1482        --?( _Atomic volatile long unsigned int * );
     1483long long int --?( volatile long long int * ),
     1484        --?( _Atomic volatile long long int * );
     1485long long unsigned --?( volatile long long unsigned int * ),
     1486        --?( _Atomic volatile long long unsigned int * );
     1487float --?( volatile float * ),
     1488        --?( _Atomic volatile float * );
     1489double --?( volatile double * ),
     1490        --?( _Atomic volatile double * );
     1491long double --?( volatile long double * ),
     1492        --?( _Atomic volatile long double * );
     1493
     1494forall( type T ) T * --?( T * restrict volatile * ),
     1495        * --?( T * _Atomic restrict volatile * );
     1496
     1497forall( type T ) _Atomic T * --?( _Atomic T * restrict volatile * ),
     1498        * --?( _Atomic T * _Atomic restrict volatile * );
     1499
     1500forall( type T ) const T * --?( const T * restrict volatile * ),
     1501        * --?( const T * _Atomic restrict volatile * );
     1502
     1503forall( type T ) volatile T * --?( volatile T * restrict volatile * ),
     1504        * --?( volatile T * _Atomic restrict volatile * );
     1505
     1506forall( type T ) restrict T * --?( restrict T * restrict volatile * ),
     1507        * --?( restrict T * _Atomic restrict volatile * );
     1508
     1509forall( type T ) _Atomic const T * --?( _Atomic const T * restrict volatile * ),
    12171510        * --?( _Atomic const T * _Atomic restrict volatile * );
    1218 forall( otype T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
     1511
     1512forall( type T ) _Atomic volatile T * --?( _Atomic volatile T * restrict volatile * ),
    12191513        * --?( _Atomic volatile T * _Atomic restrict volatile * );
    1220 forall( otype T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
     1514
     1515forall( type T ) _Atomic restrict T * --?( _Atomic restrict T * restrict volatile * ),
    12211516        * --?( _Atomic restrict T * _Atomic restrict volatile * );
    1222 forall( otype T ) const volatile T * --?( const volatile T * restrict volatile * ),
     1517
     1518forall( type T ) const volatile T * --?( const volatile T * restrict volatile * ),
    12231519        * --?( const volatile T * _Atomic restrict volatile * );
    1224 forall( otype T ) const restrict T * --?( const restrict T * restrict volatile * ),
     1520
     1521forall( type T ) const restrict T * --?( const restrict T * restrict volatile * ),
    12251522        * --?( const restrict T * _Atomic restrict volatile * );
    1226 forall( otype T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
     1523
     1524forall( type T ) restrict volatile T * --?( restrict volatile T * restrict volatile * ),
    12271525        * --?( restrict volatile T * _Atomic restrict volatile * );
    1228 forall( otype T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
     1526
     1527forall( type T ) _Atomic const volatile T * --?( _Atomic const volatile T * restrict volatile * ),
    12291528        * --?( _Atomic const volatile T * _Atomic restrict volatile * );
    1230 forall( otype T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
     1529
     1530forall( type T ) _Atomic const restrict T * --?( _Atomic const restrict T * restrict volatile * ),
    12311531        * --?( _Atomic const restrict T * _Atomic restrict volatile * );
    1232 forall( otype T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
     1532
     1533forall( type T ) _Atomic restrict volatile T * --?( _Atomic restrict volatile T * restrict volatile * ),
    12331534        * --?( _Atomic restrict volatile T * _Atomic restrict volatile * );
    1234 forall( otype T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
     1535
     1536forall( type T ) const restrict volatile T * --?( const restrict volatile T * restrict volatile * ),
    12351537        * --?( const restrict volatile T * _Atomic restrict volatile * );
    1236 forall( otype T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
     1538
     1539forall( type T ) _Atomic const restrict volatile T * --?( _Atomic const restrict volatile T * restrict volatile * ),
    12371540        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12381541\end{lstlisting}
    1239 For every extended integer type ©X© there exist
     1542For every extended integer type \lstinline$X$ there exist
    12401543% Don't use predefined: keep this out of prelude.cf.
    12411544\begin{lstlisting}
    … …  
    12451548        --?( _Atomic volatile X * );
    12461549\end{lstlisting}
    1247 For every complete enumerated type ©E© there exist
     1550For every complete enumerated type \lstinline$E$ there exist
    12481551% Don't use predefined: keep this out of prelude.cf.
    12491552\begin{lstlisting}
    … …  
    12551558
    12561559\semantics
    1257 The interpretations of prefix increment and decrement expressions are determined in the same way as the interpretations of postfix increment and decrement expressions.
     1560The interpretations of prefix increment and decrement expressions are
     1561determined in the same way as the interpretations of postfix increment and
     1562decrement expressions.
    12581563
    12591564
    12601565\subsubsection{Address and indirection operators}
    12611566
    1262 \predefined
    1263 \begin{lstlisting}
    1264 forall( otype T ) lvalue T *?( T * );
    1265 forall( otype T ) _Atomic lvalue T *?( _Atomic T * );
    1266 forall( otype T ) const lvalue T *?( const T * );
    1267 forall( otype T ) volatile lvalue T *?( volatile T * );
    1268 forall( otype T ) restrict lvalue T *?( restrict T * );
    1269 forall( otype T ) _Atomic const lvalue T *?( _Atomic const T * );
    1270 forall( otype T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
    1271 forall( otype T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
    1272 forall( otype T ) const volatile lvalue T *?( const volatile T * );
    1273 forall( otype T ) const restrict lvalue T *?( const restrict T * );
    1274 forall( otype T ) restrict volatile lvalue T *?( restrict volatile T * );
    1275 forall( otype T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
    1276 forall( otype T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
    1277 forall( otype T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
    1278 forall( otype T ) const restrict volatile lvalue T *?( const restrict volatile T * );
    1279 forall( otype T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
     1567\begin{lstlisting}
     1568forall( type T ) lvalue T *?( T * );
     1569forall( type T ) _Atomic lvalue T *?( _Atomic T * );
     1570forall( type T ) const lvalue T *?( const T * );
     1571forall( type T ) volatile lvalue T *?( volatile T * );
     1572forall( type T ) restrict lvalue T *?( restrict T * );
     1573forall( type T ) _Atomic const lvalue T *?( _Atomic const T * );
     1574forall( type T ) _Atomic volatile lvalue T *?( _Atomic volatile T * );
     1575forall( type T ) _Atomic restrict lvalue T *?( _Atomic restrict T * );
     1576forall( type T ) const volatile lvalue T *?( const volatile T * );
     1577forall( type T ) const restrict lvalue T *?( const restrict T * );
     1578forall( type T ) restrict volatile lvalue T *?( restrict volatile T * );
     1579forall( type T ) _Atomic const volatile lvalue T *?( _Atomic const volatile T * );
     1580forall( type T ) _Atomic const restrict lvalue T *?( _Atomic const restrict T * );
     1581forall( type T ) _Atomic restrict volatile lvalue T *?( _Atomic restrict volatile T * );
     1582forall( type T ) const restrict volatile lvalue T *?( const restrict volatile T * );
     1583forall( type T ) _Atomic const restrict volatile lvalue T *?( _Atomic const restrict volatile T * );
     1584
    12801585forall( ftype FT ) FT *?( FT * );
    12811586\end{lstlisting}
    12821587
    12831588\constraints
    1284 The operand of the unary ``©&©'' operator shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
     1589The operand of the unary ``\lstinline$&$'' operator shall have exactly one
     1590\Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    12851591
    12861592\semantics
    1287 The ``©&©'' expression has one interpretation which is of type ©T *©, where ©T© is the type of the operand.
    1288 
    1289 The interpretations of an indirection expression are the interpretations of the corresponding function call.
     1593The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where
     1594\lstinline$T$ is the type of the operand.
     1595
     1596The interpretations of an indirection expression are the interpretations of the corresponding
     1597function call.
    12901598
    12911599
    12921600\subsubsection{Unary arithmetic operators}
    12931601
    1294 \predefined
    1295 \begin{lstlisting}
    1296 int     +?( int ), -?( int ), ~?( int );
    1297 unsigned int +?( unsigned int ), -?( unsigned int ), ~?( unsigned int );
    1298 long int +?( long int ), -?( long int ), ~?( long int );
    1299 long unsigned int +?( long unsigned int ), -?( long unsigned int ), ~?( long unsigned int );
    1300 long long int +?( long long int ), -?( long long int ), ~?( long long int );
    1301 long long unsigned int +?( long long unsigned int ), -?( long long unsigned int ), ~?( long long unsigned int );
    1302 float +?( float ), -?( float );
    1303 double +?( double ), -?( double );
    1304 long double +?( long double ), -?( long double );
    1305 _Complex float +?( _Complex float ), -?( _Complex float );
    1306 _Complex double +?( _Complex double ), -?( _Complex double );
    1307 _Complex long double +?( _Complex long double ), -?( _Complex long double );
    1308 int !?( int ), !?( unsigned int ), !?( long ), !?( long unsigned int ),
    1309         !?( long long int ), !?( long long unsigned int ),
    1310         !?( float ), !?( double ), !?( long double ),
    1311         !?( _Complex float ), !?( _Complex double ), !?( _Complex long double );
     1602\begin{lstlisting}
     1603int
     1604        +?( int ),
     1605        -?( int ),
     1606        ~?( int );
     1607unsigned int
     1608        +?( unsigned int ),
     1609        -?( unsigned int ),
     1610         ~?( unsigned int );
     1611long int
     1612        +?( long int ),
     1613        -?( long int ),
     1614        ~?( long int );
     1615long unsigned int
     1616        +?( long unsigned int ),
     1617        -?( long unsigned int ),
     1618        ~?( long unsigned int );
     1619long long int
     1620        +?( long long int ),
     1621        -?( long long int ),
     1622        ~?( long long int );
     1623long long unsigned int
     1624        +?( long long unsigned int ),
     1625        -?( long long unsigned int ),
     1626        ~?( long long unsigned int );
     1627float
     1628        +?( float ),
     1629        -?( float );
     1630double
     1631        +?( double ),
     1632        -?( double );
     1633long double
     1634        +?( long double ),
     1635        -?( long double );
     1636_Complex float
     1637        +?( _Complex float ),
     1638        -?( _Complex float );
     1639_Complex double
     1640        +?( _Complex double ),
     1641        -?( _Complex double );
     1642_Complex long double
     1643        +?( _Complex long double ),
     1644        -?( _Complex long double );
     1645
     1646int !?( int ),
     1647        !?( unsigned int ),
     1648        !?( long ),
     1649        !?( long unsigned int ),
     1650        !?( long long int ),
     1651        !?( long long unsigned int ),
     1652        !?( float ),
     1653        !?( double ),
     1654        !?( long double ),
     1655        !?( _Complex float ),
     1656        !?( _Complex double ),
     1657        !?( _Complex long double );
     1658
    13121659forall( dtype DT ) int !?( const restrict volatile DT * );
    13131660forall( dtype DT ) int !?( _Atomic const restrict volatile DT * );
    13141661forall( ftype FT ) int !?( FT * );
    13151662\end{lstlisting}
    1316 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     1663For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     1664rank of \lstinline$int$ there exist
    13171665% Don't use predefined: keep this out of prelude.cf.
    13181666\begin{lstlisting}
    … …  
    13221670
    13231671\semantics
    1324 The interpretations of a unary arithmetic expression are the interpretations of the corresponding function call.
     1672The interpretations of a unary arithmetic expression are the interpretations of the corresponding
     1673function call.
    13251674
    13261675\examples
    13271676\begin{lstlisting}
    13281677long int li;
    1329 void eat_double( double );§\use{eat_double}§
    1330 eat_double(-li ); // => eat_double( -?( li ) );
    1331 \end{lstlisting}
    1332 The valid interpretations of ``©-li©'' (assuming no extended integer types exist) are
     1678void eat_double( double );@\use{eat_double}@
     1679
     1680eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
     1681\end{lstlisting}
     1682The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
    13331683\begin{center}
    1334 \begin{tabular}{llc} interpretation & result type & expression conversion cost \\
     1684\begin{tabular}{llc}
     1685interpretation & result type & expression conversion cost \\
    13351686\hline
    1336 ©-?( (int)li )©                                         & ©int©                                         & (unsafe) \\
    1337 ©-?( (unsigned)li)©                                     & ©unsigned int©                        & (unsafe) \\
    1338 ©-?( (long)li)©                                         & ©long©                                        & 0 \\
    1339 ©-?( (long unsigned int)li)©            & ©long unsigned int©           & 1 \\
    1340 ©-?( (long long int)li)©                        & ©long long int©                       & 2 \\
    1341 ©-?( (long long unsigned int)li)©       & ©long long unsigned int©      & 3 \\
    1342 ©-?( (float)li)©                                        & ©float©                                       & 4 \\
    1343 ©-?( (double)li)©                                       & ©double©                                      & 5 \\
    1344 ©-?( (long double)li)©                          & ©long double©                         & 6 \\
    1345 ©-?( (_Complex float)li)©                       & ©float©                                       & (unsafe) \\
    1346 ©-?( (_Complex double)li)©                      & ©double©                                      & (unsafe) \\
    1347 ©-?( (_Complex long double)li)©         & ©long double©                         & (unsafe) \\
     1687\lstinline$-?( (int)li )$                                       & \lstinline$int$                                       & (unsafe) \\
     1688\lstinline$-?( (unsigned)li)$                           & \lstinline$unsigned int$                      & (unsafe) \\
     1689\lstinline$-?( (long)li)$                                       & \lstinline$long$                                      & 0 \\
     1690\lstinline$-?( (long unsigned int)li)$          & \lstinline$long unsigned int$         & 1 \\
     1691\lstinline$-?( (long long int)li)$                      & \lstinline$long long int$                     & 2 \\
     1692\lstinline$-?( (long long unsigned int)li)$     & \lstinline$long long unsigned int$& 3 \\
     1693\lstinline$-?( (float)li)$                                      & \lstinline$float$                                     & 4 \\
     1694\lstinline$-?( (double)li)$                                     & \lstinline$double$                            & 5 \\
     1695\lstinline$-?( (long double)li)$                        & \lstinline$long double$                       & 6 \\
     1696\lstinline$-?( (_Complex float)li)$                     & \lstinline$float$                                     & (unsafe) \\
     1697\lstinline$-?( (_Complex double)li)$            & \lstinline$double$                            & (unsafe) \\
     1698\lstinline$-?( (_Complex long double)li)$       & \lstinline$long double$                       & (unsafe) \\
    13481699\end{tabular}
    13491700\end{center}
    1350 The valid interpretations of the ©eat_double© call, with the cost of the argument conversion and the cost of the entire expression, are
     1701The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument
     1702conversion and the cost of the entire expression, are
    13511703\begin{center}
    1352 \begin{tabular}{lcc} interpretation & argument cost & expression cost \\
     1704\begin{tabular}{lcc}
     1705interpretation & argument cost & expression cost \\
    13531706\hline
    1354 ©eat_double( (double)-?( (int)li) )©                                    & 7                     & (unsafe) \\
    1355 ©eat_double( (double)-?( (unsigned)li) )©                               & 6                     & (unsafe) \\
    1356 ©eat_double( (double)-?(li) )©                                                  & 5                     & \(0+5=5\) \\
    1357 ©eat_double( (double)-?( (long unsigned int)li) )©              & 4                     & \(1+4=5\) \\
    1358 ©eat_double( (double)-?( (long long int)li) )©                  & 3                     & \(2+3=5\) \\
    1359 ©eat_double( (double)-?( (long long unsigned int)li) )© & 2                     & \(3+2=5\) \\
    1360 ©eat_double( (double)-?( (float)li) )©                                  & 1                     & \(4+1=5\) \\
    1361 ©eat_double( (double)-?( (double)li) )©                                 & 0                     & \(5+0=5\) \\
    1362 ©eat_double( (double)-?( (long double)li) )©                    & (unsafe)      & (unsafe) \\
    1363 ©eat_double( (double)-?( (_Complex float)li) )©                 & (unsafe)      & (unsafe) \\
    1364 ©eat_double( (double)-?( (_Complex double)li) )©                & (unsafe)      & (unsafe) \\
    1365 ©eat_double( (double)-?( (_Complex long double)li) )©   & (unsafe)      & (unsafe) \\
     1707\lstinline$eat_double( (double)-?( (int)li) )$                                  & 7                     & (unsafe) \\
     1708\lstinline$eat_double( (double)-?( (unsigned)li) )$                             & 6                     & (unsafe) \\
     1709\lstinline$eat_double( (double)-?(li) )$                                                & 5                     & \(0+5=5\) \\
     1710\lstinline$eat_double( (double)-?( (long unsigned int)li) )$    & 4                     & \(1+4=5\) \\
     1711\lstinline$eat_double( (double)-?( (long long int)li) )$                & 3                     & \(2+3=5\) \\
     1712\lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2            & \(3+2=5\) \\
     1713\lstinline$eat_double( (double)-?( (float)li) )$                                & 1                     & \(4+1=5\) \\
     1714\lstinline$eat_double( (double)-?( (double)li) )$                               & 0                     & \(5+0=5\) \\
     1715\lstinline$eat_double( (double)-?( (long double)li) )$                  & (unsafe)      & (unsafe) \\
     1716\lstinline$eat_double( (double)-?( (_Complex float)li) )$               & (unsafe)      & (unsafe) \\
     1717\lstinline$eat_double( (double)-?( (_Complex double)li) )$              & (unsafe)      & (unsafe) \\
     1718\lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe)      & (unsafe) \\
    13661719\end{tabular}
    13671720\end{center}
    1368 Each has result type ©void©, so the best must be selected.
    1369 The interpretations involving unsafe conversions are discarded.
    1370 The remainder have equal expression conversion costs, so the ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is ©eat_double( (double)-?(li) )©.
    1371 
    1372 
    1373 \subsubsection[The sizeof and \_Alignof operators]{The \lstinline@sizeof@ and \lstinline@_Alignof@ operators}
     1721Each has result type \lstinline$void$, so the best must be selected. The interpretations involving
     1722unsafe conversions are discarded. The remainder have equal expression conversion costs, so the
     1723``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
     1724\lstinline$eat_double( (double)-?(li) )$.
     1725
     1726
     1727\subsubsection{The \lstinline$sizeof$ and \lstinline$_Alignof$ operators}
    13741728
    13751729\constraints
    1376 The operand of ©sizeof© or ©_Alignof© shall not be ©type©, ©dtype©, or ©ftype©.
    1377 
    1378 When the ©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 ©sizeof© or ©_Alignof© expression has one interpretation, of type ©size_t©.
    1379 
    1380 When ©sizeof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    1381 \nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    1382 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    1383 
    1384 When ©_Alignof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    1385 \nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    1386 When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    1387 \begin{rationale}
    1388 \begin{lstlisting}
    1389 otype Pair = struct { int first, second; };
     1730The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$,
     1731\lstinline$dtype$, or \lstinline$ftype$.
     1732
     1733When the \lstinline$sizeof$\use{sizeof} operator is applied to an expression, the expression shall
     1734have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall
     1735be unambiguous. \semantics A \lstinline$sizeof$ or \lstinline$_Alignof$ expression has one
     1736interpretation, of type \lstinline$size_t$.
     1737
     1738When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1739\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand. When
     1740the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the
     1741expression is not a constant expression.
     1742
     1743When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1744\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the
     1745operand. When the operand is an opaque type or an inferred type parameter\index{inferred
     1746parameter}, the expression is not a constant expression.
     1747\begin{rationale}
     1748\begin{lstlisting}
     1749type Pair = struct { int first, second; };
    13901750size_t p_size = sizeof(Pair);           // constant expression
    1391 extern otype Rational;§\use{Rational}§
     1751
     1752extern type Rational;@\use{Rational}@
    13921753size_t c_size = sizeof(Rational);       // non-constant expression
     1754
    13931755forall(type T) T f(T p1, T p2) {
    13941756        size_t t_size = sizeof(T);              // non-constant expression
    … …  
    13961758}
    13971759\end{lstlisting}
    1398 ``©sizeof Rational©'', although not statically known, is fixed.
    1399 Within ©f()©, ``©sizeof(T)©'' is fixed for each call of ©f()©, but may vary from call to call.
     1760``\lstinline$sizeof Rational$'', although not statically known, is fixed. Within \lstinline$f()$,
     1761``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
    14001762\end{rationale}
    14011763
    … …  
    14061768\lhs{cast-expression}
    14071769\rhs \nonterm{unary-expression}
    1408 \rhs ©(© \nonterm{type-name} ©)© \nonterm{cast-expression}
     1770\rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression}
    14091771\end{syntax}
    14101772
    14111773\constraints
    1412 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be ©type©, ©dtype©, or ©ftype©.
     1774The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$,
     1775\lstinline$dtype$, or \lstinline$ftype$.
    14131776
    14141777\semantics
    14151778
    1416 In a \Index{cast expression} ``©(©\nonterm{type-name}©)e©'', if
    1417 \nonterm{type-name} is the type of an interpretation of ©e©, then that interpretation is the only interpretation of the cast expression;
    1418 otherwise, ©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.
    1419 The 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.
    1420 
    1421 \begin{rationale}
    1422 Casts can be used to eliminate ambiguity in expressions by selecting interpretations of subexpressions, and to specialize polymorphic functions and values.
     1779In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
     1780\nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is
     1781the only interpretation of the cast expression; otherwise, \lstinline$e$ shall have some
     1782interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast
     1783expression is the cast of the interpretation that can be converted at the lowest cost. The cast
     1784expression's interpretation is ambiguous\index{ambiguous interpretation} if more than one
     1785interpretation can be converted at the lowest cost or if the selected interpretation is ambiguous.
     1786
     1787\begin{rationale}
     1788Casts can be used to eliminate ambiguity in expressions by selecting interpretations of
     1789subexpressions, and to specialize polymorphic functions and values.
    14231790\end{rationale}
    14241791
    … …  
    14291796\lhs{multiplicative-expression}
    14301797\rhs \nonterm{cast-expression}
    1431 \rhs \nonterm{multiplicative-expression} ©*© \nonterm{cast-expression}
    1432 \rhs \nonterm{multiplicative-expression} ©/© \nonterm{cast-expression}
    1433 \rhs \nonterm{multiplicative-expression} ©%© \nonterm{cast-expression}
     1798\rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression}
     1799\rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression}
     1800\rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression}
    14341801\end{syntax}
    14351802
    14361803\rewriterules
    14371804\begin{lstlisting}
    1438 a * b => ?*?( a, b )§\use{?*?}§
    1439 a / b => ?/?( a, b )§\use{?/?}§
    1440 a % b => ?%?( a, b )§\use{?%?}§
    1441 \end{lstlisting}
    1442 
    1443 \predefined
    1444 \begin{lstlisting}
    1445 int?*?( int, int ), ?/?( int, int ), ?%?( int, int );
    1446 unsigned int?*?( unsigned int, unsigned int ), ?/?( unsigned int, unsigned int ), ?%?( unsigned int, unsigned int );
    1447 long int?*?( long int, long int ), ?/?( long, long ), ?%?( long, long );
     1805a * b @\rewrite@ ?*?( a, b )@\use{?*?}@
     1806a / b @\rewrite@ ?/?( a, b )@\use{?/?}@
     1807a % b @\rewrite@ ?%?( a, b )@\use{?%?}@
     1808\end{lstlisting}
     1809
     1810\begin{lstlisting}
     1811int?*?( int, int ),
     1812        ?/?( int, int ),
     1813        ?%?( int, int );
     1814unsigned int?*?( unsigned int, unsigned int ),
     1815        ?/?( unsigned int, unsigned int ),
     1816        ?%?( unsigned int, unsigned int );
     1817long int?*?( long int, long int ),
     1818        ?/?( long, long ),
     1819        ?%?( long, long );
    14481820long unsigned int?*?( long unsigned int, long unsigned int ),
    1449         ?/?( long unsigned int, long unsigned int ), ?%?( long unsigned int, long unsigned int );
    1450 long long int?*?( long long int, long long int ), ?/?( long long int, long long int ),
     1821        ?/?( long unsigned int, long unsigned int ),
     1822        ?%?( long unsigned int, long unsigned int );
     1823long long int?*?( long long int, long long int ),
     1824        ?/?( long long int, long long int ),
    14511825        ?%?( long long int, long long int );
    14521826long long unsigned int ?*?( long long unsigned int, long long unsigned int ),
    1453         ?/?( long long unsigned int, long long unsigned int ), ?%?( long long unsigned int, long long unsigned int );
    1454 float?*?( float, float ), ?/?( float, float );
    1455 double?*?( double, double ), ?/?( double, double );
    1456 long double?*?( long double, long double ), ?/?( long double, long double );
    1457 _Complex float?*?( float, _Complex float ), ?/?( float, _Complex float ),
    1458         ?*?( _Complex float, float ), ?/?( _Complex float, float ),
    1459         ?*?( _Complex float, _Complex float ), ?/?( _Complex float, _Complex float );
    1460 _Complex double?*?( double, _Complex double ), ?/?( double, _Complex double ),
    1461         ?*?( _Complex double, double ), ?/?( _Complex double, double ),
    1462         ?*?( _Complex double, _Complex double ), ?/?( _Complex double, _Complex double );
    1463 _Complex long double?*?( long double, _Complex long double ), ?/?( long double, _Complex long double ),
    1464         ?*?( _Complex long double, long double ), ?/?( _Complex long double, long double ),
    1465         ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    1466 \end{lstlisting}
    1467 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     1827        ?/?( long long unsigned int, long long unsigned int ),
     1828        ?%?( long long unsigned int, long long unsigned int );
     1829float?*?( float, float ),
     1830        ?/?( float, float );
     1831double?*?( double, double ),
     1832        ?/?( double, double );
     1833long double?*?( long double, long double ),
     1834        ?/?( long double, long double );
     1835_Complex float?*?( float, _Complex float ),
     1836        ?/?( float, _Complex float ),
     1837        ?*?( _Complex float, float ),
     1838        ?/?( _Complex float, float ),
     1839        ?*?( _Complex float, _Complex float ),
     1840        ?/?( _Complex float, _Complex float );
     1841_Complex double?*?( double, _Complex double ),
     1842        ?/?( double, _Complex double ),
     1843        ?*?( _Complex double, double ),
     1844        ?/?( _Complex double, double ),
     1845        ?*?( _Complex double, _Complex double ),
     1846        ?/?( _Complex double, _Complex double );
     1847_Complex long double?*?( long double, _Complex long double ),
     1848        ?/?( long double, _Complex long double ),
     1849        ?*?( _Complex long double, long double ),
     1850        ?/?( _Complex long double, long double ),
     1851        ?*?( _Complex long double, _Complex long double ),
     1852        ?/?( _Complex long double, _Complex long double );
     1853\end{lstlisting}
     1854For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     1855rank of \lstinline$int$ there exist
    14681856% Don't use predefined: keep this out of prelude.cf.
    14691857\begin{lstlisting}
    … …  
    14721860
    14731861\begin{rationale}
    1474 {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the \Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
     1862{\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the
     1863\Index{usual arithmetic conversion}s.  Instead it specifies conversion of the result of binary
     1864operations on arguments from mixed type domains. \CFA's predefined operators match that pattern.
    14751865\end{rationale}
    14761866
    14771867\semantics
    1478 The interpretations of multiplicative expressions are the interpretations of the corresponding function call.
     1868The interpretations of multiplicative expressions are the interpretations of the corresponding
     1869function call.
    14791870
    14801871\examples
    … …  
    14821873int i;
    14831874long li;
    1484 void eat_double( double );§\use{eat_double}§
     1875void eat_double( double );@\use{eat_double}@
    14851876eat_double( li % i );
    14861877\end{lstlisting}
    1487 ``©li % i©'' is rewritten as ``©?%?(li, i )©''.
    1488 The valid interpretations of ©?%?(li, i )©, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to ©double© (assuming no extended integer types are present ) are
     1878``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''. The valid interpretations
     1879of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and
     1880the cost of converting the result to \lstinline$double$ (assuming no extended integer types are
     1881present ) are
    14891882\begin{center}
    1490 \begin{tabular}{lcc} interpretation & argument cost & result cost \\
    1491 \hline
    1492 © ?%?( (int)li, i )©                                                                            & (unsafe)      & 6     \\
    1493 © ?%?( (unsigned)li,(unsigned)i )©                                                      & (unsafe)      & 5     \\
    1494 © ?%?( li, (long)i )©                                                                           & 1                     & 4     \\
    1495 © ?%?( (long unsigned)li,(long unsigned)i )©                            & 3                     & 3     \\
    1496 © ?%?( (long long)li,(long long)i )©                                            & 5                     & 2     \\
    1497 © ?%?( (long long unsigned)li, (long long unsigned)i )©         & 7                     & 1     \\
     1883\begin{tabular}{lcc}
     1884interpretation & argument cost & result cost \\
     1885\hline
     1886\lstinline$ ?%?( (int)li, i )$                                                                          & (unsafe)      & 6     \\
     1887\lstinline$ ?%?( (unsigned)li,(unsigned)i )$                                            & (unsafe)      & 5     \\
     1888\lstinline$ ?%?(li,(long)i )$                                                                           & 1                     & 4     \\
     1889\lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$                          & 3                     & 3     \\
     1890\lstinline$ ?%?( (long long)li,(long long)i )$                                          & 5                     & 2     \\
     1891\lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$       & 7                     & 1     \\
    14981892\end{tabular}
    14991893\end{center}
    1500 The best interpretation of ©eat_double( li, i )© is ©eat_double( (double)?%?(li, (long)i ))©, which has no unsafe conversions and the lowest total cost.
    1501 
    1502 \begin{rationale}
    1503 {\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 ©int©.
    1504 If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©;
    1505 it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern;
    1506 it does not predefine ``©short ?*?( short, short )©''.
    1507 
    1508 These ``missing'' operators limit polymorphism.
    1509 Consider
    1510 \begin{lstlisting}
    1511 forall( otype T | T ?*?( T, T ) ) T square( T );
     1894The best interpretation of \lstinline$eat_double( li, i )$ is
     1895\lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the
     1896lowest total cost.
     1897
     1898\begin{rationale}
     1899{\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that
     1900belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline$int$.If
     1901\lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
     1902it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches
     1903that pattern; it does not predefine ``\lstinline$short ?*?( short, short )$''.
     1904
     1905These ``missing'' operators limit polymorphism. Consider
     1906\begin{lstlisting}
     1907forall( type T | T ?*?( T, T ) ) T square( T );
    15121908short s;
    15131909square( s );
    15141910\end{lstlisting}
    1515 Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©.
    1516 This is mildly surprising, but it follows the {\c11} operator pattern.
     1911Since \CFA does not define a multiplication operator for \lstinline$short int$,
     1912\lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
     1913\lstinline$int$. This is mildly surprising, but it follows the {\c11} operator pattern.
    15171914
    15181915A more troubling example is
    15191916\begin{lstlisting}
    1520 forall( otype T | ?*?( T, T ) ) T product( T[], int n );
     1917forall( type T | ?*?( T, T ) ) T product( T[], int n );
    15211918short sa[5];
    15221919product( sa, 5);
    15231920\end{lstlisting}
    1524 This has no valid interpretations, because \CFA has no conversion from ``array of ©short int©'' to ``array of ©int©''.
    1525 The alternatives in such situations include
     1921This has no valid interpretations, because \CFA has no conversion from ``array of
     1922\lstinline$short int$'' to ``array of \lstinline$int$''. The alternatives in such situations
     1923include
    15261924\begin{itemize}
    15271925\item
    1528 Defining monomorphic overloadings of ©product© for ©short© and the other ``small'' types.
    1529 \item
    1530 Defining ``©short ?*?( short, short )©'' within the scope containing the call to ©product©.
    1531 \item
    1532 Defining ©product© to take as an argument a conversion function from the ``small'' type to the operator's argument type.
     1926Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other
     1927``small'' types.
     1928\item
     1929Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to
     1930\lstinline$product$.
     1931\item
     1932Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to
     1933the operator's argument type.
    15331934\end{itemize}
    15341935\end{rationale}
    … …  
    15401941\lhs{additive-expression}
    15411942\rhs \nonterm{multiplicative-expression}
    1542 \rhs \nonterm{additive-expression} ©+© \nonterm{multiplicative-expression}
    1543 \rhs \nonterm{additive-expression} ©-© \nonterm{multiplicative-expression}
     1943\rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression}
     1944\rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression}
    15441945\end{syntax}
    15451946
    15461947\rewriterules
    15471948\begin{lstlisting}
    1548 a + b => ?+?( a, b )§\use{?+?}§
    1549 a - b => ?-?( a, b )§\use{?-?}§
    1550 \end{lstlisting}
    1551 
    1552 \predefined
    1553 \begin{lstlisting}
    1554 int?+?( int, int ), ?-?( int, int );
    1555 unsigned int?+?( unsigned int, unsigned int ), ?-?( unsigned int, unsigned int );
    1556 long int?+?( long int, long int ), ?-?( long int, long int );
    1557 long unsigned int?+?( long unsigned int, long unsigned int ), ?-?( long unsigned int, long unsigned int );
    1558 long long int?+?( long long int, long long int ), ?-?( long long int, long long int );
     1949a + b @\rewrite@ ?+?( a, b )@\use{?+?}@
     1950a - b @\rewrite@ ?-?( a, b )@\use{?-?}@
     1951\end{lstlisting}
     1952
     1953\begin{lstlisting}
     1954int?+?( int, int ),
     1955        ?-?( int, int );
     1956unsigned int?+?( unsigned int, unsigned int ),
     1957        ?-?( unsigned int, unsigned int );
     1958long int?+?( long int, long int ),
     1959        ?-?( long int, long int );
     1960long unsigned int?+?( long unsigned int, long unsigned int ),
     1961        ?-?( long unsigned int, long unsigned int );
     1962long long int?+?( long long int, long long int ),
     1963        ?-?( long long int, long long int );
    15591964long long unsigned int ?+?( long long unsigned int, long long unsigned int ),
    15601965        ?-?( long long unsigned int, long long unsigned int );
    1561 float?+?( float, float ), ?-?( float, float );
    1562 double?+?( double, double ), ?-?( double, double );
    1563 long double?+?( long double, long double ), ?-?( long double, long double );
    1564 _Complex float?+?( _Complex float, float ), ?-?( _Complex float, float ),
    1565         ?+?( float, _Complex float ), ?-?( float, _Complex float ),
    1566         ?+?( _Complex float, _Complex float ), ?-?( _Complex float, _Complex float );
    1567 _Complex double?+?( _Complex double, double ), ?-?( _Complex double, double ),
    1568         ?+?( double, _Complex double ), ?-?( double, _Complex double ),
    1569         ?+?( _Complex double, _Complex double ), ?-?( _Complex double, _Complex double );
    1570 _Complex long double?+?( _Complex long double, long double ), ?-?( _Complex long double, long double ),
    1571         ?+?( long double, _Complex long double ), ?-?( long double, _Complex long double ),
    1572         ?+?( _Complex long double, _Complex long double ), ?-?( _Complex long double, _Complex long double );
    1573 
    1574 forall( otype T ) T * ?+?( T *, ptrdiff_t ), * ?+?( ptrdiff_t, T * ), * ?-?( T *, ptrdiff_t );
    1575 forall( otype T ) _Atomic T * ?+?( _Atomic T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic T * ),
     1966float?+?( float, float ),
     1967        ?-?( float, float );
     1968double?+?( double, double ),
     1969        ?-?( double, double );
     1970long double?+?( long double, long double ),
     1971        ?-?( long double, long double );
     1972_Complex float?+?( _Complex float, float ),
     1973        ?-?( _Complex float, float ),
     1974        ?+?( float, _Complex float ),
     1975        ?-?( float, _Complex float ),
     1976        ?+?( _Complex float, _Complex float ),
     1977        ?-?( _Complex float, _Complex float );
     1978_Complex double?+?( _Complex double, double ),
     1979        ?-?( _Complex double, double ),
     1980        ?+?( double, _Complex double ),
     1981        ?-?( double, _Complex double ),
     1982        ?+?( _Complex double, _Complex double ),
     1983        ?-?( _Complex double, _Complex double );
     1984_Complex long double?+?( _Complex long double, long double ),
     1985        ?-?( _Complex long double, long double ),
     1986        ?+?( long double, _Complex long double ),
     1987        ?-?( long double, _Complex long double ),
     1988        ?+?( _Complex long double, _Complex long double ),
     1989        ?-?( _Complex long double, _Complex long double );
     1990
     1991forall( type T ) T
     1992        * ?+?( T *, ptrdiff_t ),
     1993        * ?+?( ptrdiff_t, T * ),
     1994        * ?-?( T *, ptrdiff_t );
     1995
     1996forall( type T ) _Atomic T
     1997        * ?+?( _Atomic T *, ptrdiff_t ),
     1998        * ?+?( ptrdiff_t, _Atomic T * ),
    15761999        * ?-?( _Atomic T *, ptrdiff_t );
    1577 forall( otype T ) const T * ?+?( const T *, ptrdiff_t ), * ?+?( ptrdiff_t, const T * ),
     2000
     2001forall( type T ) const T
     2002        * ?+?( const T *, ptrdiff_t ),
     2003        * ?+?( ptrdiff_t, const T * ),
    15782004        * ?-?( const T *, ptrdiff_t );
    1579 forall( otype T ) restrict T * ?+?( restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict T * ),
     2005
     2006forall( type T ) restrict T
     2007        * ?+?( restrict T *, ptrdiff_t ),
     2008        * ?+?( ptrdiff_t, restrict T * ),
    15802009        * ?-?( restrict T *, ptrdiff_t );
    1581 forall( otype T ) volatile T * ?+?( volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, volatile T * ),
     2010
     2011forall( type T ) volatile T
     2012        * ?+?( volatile T *, ptrdiff_t ),
     2013        * ?+?( ptrdiff_t, volatile T * ),
    15822014        * ?-?( volatile T *, ptrdiff_t );
    1583 forall( otype T ) _Atomic const T * ?+?( _Atomic const T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic const T * ),
     2015
     2016forall( type T ) _Atomic const T
     2017        * ?+?( _Atomic const T *, ptrdiff_t ),
     2018        * ?+?( ptrdiff_t, _Atomic const T * ),
    15842019        * ?-?( _Atomic const T *, ptrdiff_t );
    1585 forall( otype T ) _Atomic restrict T * ?+?( _Atomic restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic restrict T * ),
     2020
     2021forall( type T ) _Atomic restrict T
     2022        * ?+?( _Atomic restrict T *, ptrdiff_t ),
     2023        * ?+?( ptrdiff_t, _Atomic restrict T * ),
    15862024        * ?-?( _Atomic restrict T *, ptrdiff_t );
    1587 forall( otype T ) _Atomic volatile T * ?+?( _Atomic volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, _Atomic volatile T * ),
     2025
     2026forall( type T ) _Atomic volatile T
     2027        * ?+?( _Atomic volatile T *, ptrdiff_t ),
     2028        * ?+?( ptrdiff_t, _Atomic volatile T * ),
    15882029        * ?-?( _Atomic volatile T *, ptrdiff_t );
    1589 forall( otype T ) const restrict T * ?+?( const restrict T *, ptrdiff_t ), * ?+?( ptrdiff_t, const restrict T * ),
     2030
     2031forall( type T ) const restrict T
     2032        * ?+?( const restrict T *, ptrdiff_t ),
     2033        * ?+?( ptrdiff_t, const restrict T * ),
    15902034        * ?-?( const restrict T *, ptrdiff_t );
    1591 forall( otype T ) const volatile T * ?+?( const volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, const volatile T * ),
     2035
     2036forall( type T ) const volatile T
     2037        * ?+?( const volatile T *, ptrdiff_t ),
     2038        * ?+?( ptrdiff_t, const volatile T * ),
    15922039        * ?-?( const volatile T *, ptrdiff_t );
    1593 forall( otype T ) restrict volatile T * ?+?( restrict volatile T *, ptrdiff_t ), * ?+?( ptrdiff_t, restrict volatile T * ),
     2040
     2041forall( type T ) restrict volatile T
     2042        * ?+?( restrict volatile T *, ptrdiff_t ),
     2043        * ?+?( ptrdiff_t, restrict volatile T * ),
    15942044        * ?-?( restrict volatile T *, ptrdiff_t );
    1595 forall( otype T ) _Atomic const restrict T * ?+?( _Atomic const restrict T *, ptrdiff_t ),
     2045
     2046forall( type T ) _Atomic const restrict T
     2047        * ?+?( _Atomic const restrict T *, ptrdiff_t ),
    15962048        * ?+?( ptrdiff_t, _Atomic const restrict T * ),
    15972049        * ?-?( _Atomic const restrict T *, ptrdiff_t );
    1598 forall( otype T ) ptrdiff_t
     2050
     2051forall( type T ) ptrdiff_t
    15992052        * ?-?( const restrict volatile T *, const restrict volatile T * ),
    16002053        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    16012054\end{lstlisting}
    1602 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2055For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2056rank of \lstinline$int$ there exist
    16032057% Don't use predefined: keep this out of prelude.cf.
    16042058\begin{lstlisting}
    … …  
    16072061
    16082062\semantics
    1609 The interpretations of additive expressions are the interpretations of the corresponding function calls.
    1610 
    1611 \begin{rationale}
    1612 ©ptrdiff_t© is an implementation-defined identifier defined in ©<stddef.h>© that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
    1613 It 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.
    1614 The {\c11} standard uses ©size_t© in several cases where a library function takes an argument that is used as a subscript, but ©size_t© is unsuitable here because it is an unsigned type.
     2063The interpretations of additive expressions are the interpretations of the corresponding function
     2064calls.
     2065
     2066\begin{rationale}
     2067\lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that
     2068is synonymous with a signed integral type that is large enough to hold the difference between two
     2069pointers. It seems reasonable to use it for pointer addition as well. (This is technically a
     2070difference between \CFA and C, which only specifies that pointer addition uses an \emph{integral}
     2071argument.) Hence it is also used for subscripting, which is defined in terms of pointer addition.
     2072The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an
     2073argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an
     2074unsigned type.
    16152075\end{rationale}
    16162076
    … …  
    16212081\lhs{shift-expression}
    16222082\rhs \nonterm{additive-expression}
    1623 \rhs \nonterm{shift-expression} ©<<© \nonterm{additive-expression}
    1624 \rhs \nonterm{shift-expression} ©>>© \nonterm{additive-expression}
     2083\rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression}
     2084\rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression}
    16252085\end{syntax}
    16262086
    1627 \rewriterules
    1628 \begin{lstlisting}
    1629 a << b => ?<<?( a, b )§\use{?<<?}§
    1630 a >> b => ?>>?( a, b )§\use{?>>?}§
    1631 \end{lstlisting}
    1632 
    1633 \predefined
    1634 \begin{lstlisting}
    1635 int ?<<?( int, int ), ?>>?( int, int );
    1636 unsigned int ?<<?( unsigned int, int ), ?>>?( unsigned int, int );
    1637 long int ?<<?( long int, int ), ?>>?( long int, int );
    1638 long unsigned int ?<<?( long unsigned int, int ), ?>>?( long unsigned int, int );
    1639 long long int ?<<?( long long int, int ), ?>>?( long long int, int );
    1640 long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    1641 \end{lstlisting}
    1642 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2087\rewriterules \use{?>>?}%use{?<<?}
     2088\begin{lstlisting}
     2089a << b @\rewrite@ ?<<?( a, b )
     2090a >> b @\rewrite@ ?>>?( a, b )
     2091\end{lstlisting}
     2092
     2093\begin{lstlisting}
     2094int ?<<?( int, int ),
     2095         ?>>?( int, int );
     2096unsigned int ?<<?( unsigned int, int ),
     2097         ?>>?( unsigned int, int );
     2098long int ?<<?( long int, int ),
     2099         ?>>?( long int, int );
     2100long unsigned int ?<<?( long unsigned int, int ),
     2101         ?>>?( long unsigned int, int );
     2102long long int ?<<?( long long int, int ),
     2103         ?>>?( long long int, int );
     2104long long unsigned int ?<<?( long long unsigned int, int ),
     2105         ?>>?( long long unsigned int, int);
     2106\end{lstlisting}
     2107For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2108rank of \lstinline$int$ there exist
    16432109% Don't use predefined: keep this out of prelude.cf.
    16442110\begin{lstlisting}
    … …  
    16472113
    16482114\begin{rationale}
    1649 The bitwise shift operators break the usual pattern: they do not convert both operands to a common type.
    1650 The right operand only undergoes \Index{integer promotion}.
     2115The bitwise shift operators break the usual pattern: they do not convert both operands to a common
     2116type. The right operand only undergoes \Index{integer promotion}.
    16512117\end{rationale}
    16522118
    16532119\semantics
    1654 The interpretations of a bitwise shift expression are the interpretations of the corresponding function calls.
     2120The interpretations of a bitwise shift expression are the interpretations of the corresponding
     2121function calls.
    16552122
    16562123
    … …  
    16602127\lhs{relational-expression}
    16612128\rhs \nonterm{shift-expression}
    1662 \rhs \nonterm{relational-expression} ©< © \nonterm{shift-expression}
    1663 \rhs \nonterm{relational-expression} ©> © \nonterm{shift-expression}
    1664 \rhs \nonterm{relational-expression} ©<=© \nonterm{shift-expression}
    1665 \rhs \nonterm{relational-expression} ©>=© \nonterm{shift-expression}
     2129\rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression}
     2130\rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression}
     2131\rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression}
     2132\rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression}
    16662133\end{syntax}
    16672134
    1668 \rewriterules
    1669 \begin{lstlisting}
    1670 a < b => ?<?( a, b )§\use{?<?}§
    1671 a > b => ?>?( a, b )§\use{?>?}§
    1672 a <= b => ?<=?( a, b )§\use{?<=?}§
    1673 a >= b => ?>=?( a, b )§\use{?>=?}§
    1674 \end{lstlisting}
    1675 
    1676 \predefined
    1677 \begin{lstlisting}
    1678 int ?<?( int, int ), ?<=?( int, int ),
    1679         ?>?( int, int ), ?>=?( int, int );
    1680 int ?<?( unsigned int, unsigned int ), ?<=?( unsigned int, unsigned int ),
    1681         ?>?( unsigned int, unsigned int ), ?>=?( unsigned int, unsigned int );
    1682 int ?<?( long int, long int ), ?<=?( long int, long int ),
    1683         ?>?( long int, long int ), ?>=?( long int, long int );
    1684 int ?<?( long unsigned int, long unsigned ), ?<=?( long unsigned int, long unsigned ),
    1685         ?>?( long unsigned int, long unsigned ), ?>=?( long unsigned int, long unsigned );
    1686 int ?<?( long long int, long long int ), ?<=?( long long int, long long int ),
    1687         ?>?( long long int, long long int ), ?>=?( long long int, long long int );
    1688 int ?<?( long long unsigned int, long long unsigned ), ?<=?( long long unsigned int, long long unsigned ),
    1689         ?>?( long long unsigned int, long long unsigned ), ?>=?( long long unsigned int, long long unsigned );
    1690 int ?<?( float, float ), ?<=?( float, float ),
    1691         ?>?( float, float ), ?>=?( float, float );
    1692 int ?<?( double, double ), ?<=?( double, double ),
    1693         ?>?( double, double ), ?>=?( double, double );
    1694 int ?<?( long double, long double ), ?<=?( long double, long double ),
    1695         ?>?( long double, long double ), ?>=?( long double, long double );
    1696 forall( dtype DT ) int ?<?( const restrict volatile DT *, const restrict volatile DT * ),
     2135\rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
     2136\begin{lstlisting}
     2137a < b @\rewrite@ ?<?( a, b )
     2138a > b @\rewrite@ ?>?( a, b )
     2139a <= b @\rewrite@ ?<=?( a, b )
     2140a >= b @\rewrite@ ?>=?( a, b )
     2141\end{lstlisting}
     2142
     2143\begin{lstlisting}
     2144int ?<?( int, int ),
     2145        ?<=?( int, int ),
     2146        ?>?( int, int ),
     2147        ?>=?( int, int );
     2148int ?<?( unsigned int, unsigned int ),
     2149        ?<=?( unsigned int, unsigned int ),
     2150        ?>?( unsigned int, unsigned int ),
     2151        ?>=?( unsigned int, unsigned int );
     2152int ?<?( long int, long int ),
     2153        ?<=?( long int, long int ),
     2154        ?>?( long int, long int ),
     2155        ?>=?( long int, long int );
     2156int ?<?( long unsigned int, long unsigned ),
     2157        ?<=?( long unsigned int, long unsigned ),
     2158        ?>?( long unsigned int, long unsigned ),
     2159        ?>=?( long unsigned int, long unsigned );
     2160int ?<?( long long int, long long int ),
     2161        ?<=?( long long int, long long int ),
     2162        ?>?( long long int, long long int ),
     2163        ?>=?( long long int, long long int );
     2164int ?<?( long long unsigned int, long long unsigned ),
     2165        ?<=?( long long unsigned int, long long unsigned ),
     2166        ?>?( long long unsigned int, long long unsigned ),
     2167        ?>=?( long long unsigned int, long long unsigned );
     2168int ?<?( float, float ),
     2169        ?<=?( float, float ),
     2170        ?>?( float, float ),
     2171        ?>=?( float, float );
     2172int ?<?( double, double ),
     2173        ?<=?( double, double ),
     2174        ?>?( double, double ),
     2175        ?>=?( double, double );
     2176int ?<?( long double, long double ),
     2177        ?<=?( long double, long double ),
     2178        ?>?( long double, long double ),
     2179        ?>=?( long double, long double );
     2180
     2181forall( dtype DT ) int
     2182        ?<?( const restrict volatile DT *, const restrict volatile DT * ),
    16972183        ?<?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * ),
    16982184        ?<=?( const restrict volatile DT *, const restrict volatile DT * ),
    … …  
    17032189        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    17042190\end{lstlisting}
    1705 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2191For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2192rank of \lstinline$int$ there exist
    17062193% Don't use predefined: keep this out of prelude.cf.
    17072194\begin{lstlisting}
    … …  
    17132200
    17142201\semantics
    1715 The interpretations of a relational expression are the interpretations of the corresponding function call.
     2202The interpretations of a relational expression are the interpretations of the corresponding function
     2203call.
    17162204
    17172205
    … …  
    17212209\lhs{equality-expression}
    17222210\rhs \nonterm{relational-expression}
    1723 \rhs \nonterm{equality-expression} ©==© \nonterm{relational-expression}
    1724 \rhs \nonterm{equality-expression} ©!=© \nonterm{relational-expression}
     2211\rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression}
     2212\rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression}
    17252213\end{syntax}
    17262214
    17272215\rewriterules
    17282216\begin{lstlisting}
    1729 a == b => ?==?( a, b )§\use{?==?}§
    1730 a != b => ?!=?( a, b )§\use{?"!=?}§
    1731 \end{lstlisting}
    1732 
    1733 \predefined
    1734 \begin{lstlisting}
    1735 int ?==?( int, int ), ?!=?( int, int ),
    1736         ?==?( unsigned int, unsigned int ), ?!=?( unsigned int, unsigned int ),
    1737         ?==?( long int, long int ), ?!=?( long int, long int ),
    1738         ?==?( long unsigned int, long unsigned int ), ?!=?( long unsigned int, long unsigned int ),
    1739         ?==?( long long int, long long int ), ?!=?( long long int, long long int ),
    1740         ?==?( long long unsigned int, long long unsigned int ), ?!=?( long long unsigned int, long long unsigned int ),
    1741         ?==?( float, float ), ?!=?( float, float ),
    1742         ?==?( _Complex float, float ), ?!=?( _Complex float, float ),
    1743         ?==?( float, _Complex float ), ?!=?( float, _Complex float ),
    1744         ?==?( _Complex float, _Complex float ), ?!=?( _Complex float, _Complex float ),
    1745         ?==?( double, double ), ?!=?( double, double ),
    1746         ?==?( _Complex double, double ), ?!=?( _Complex double, double ),
    1747         ?==?( double, _Complex double ), ?!=?( double, _Complex double ),
    1748         ?==?( _Complex double, _Complex double ), ?!=?( _Complex double, _Complex double ),
    1749         ?==?( long double, long double ), ?!=?( long double, long double ),
    1750         ?==?( _Complex long double, long double ), ?!=?( _Complex long double, long double ),
    1751         ?==?( long double, _Complex long double ), ?!=?( long double, _Complex long double ),
    1752         ?==?( _Complex long double, _Complex long double ), ?!=?( _Complex long double, _Complex long double );
     2217a == b @\rewrite@ ?==?( a, b )@\use{?==?}@
     2218a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@
     2219\end{lstlisting}
     2220
     2221\begin{lstlisting}
     2222int ?==?( int, int ),
     2223        ?!=?( int, int ),
     2224        ?==?( unsigned int, unsigned int ),
     2225        ?!=?( unsigned int, unsigned int ),
     2226        ?==?( long int, long int ),
     2227        ?!=?( long int, long int ),
     2228        ?==?( long unsigned int, long unsigned int ),
     2229        ?!=?( long unsigned int, long unsigned int ),
     2230        ?==?( long long int, long long int ),
     2231        ?!=?( long long int, long long int ),
     2232        ?==?( long long unsigned int, long long unsigned int ),
     2233        ?!=?( long long unsigned int, long long unsigned int ),
     2234        ?==?( float, float ),
     2235        ?!=?( float, float ),
     2236        ?==?( _Complex float, float ),
     2237        ?!=?( _Complex float, float ),
     2238        ?==?( float, _Complex float ),
     2239        ?!=?( float, _Complex float ),
     2240        ?==?( _Complex float, _Complex float ),
     2241        ?!=?( _Complex float, _Complex float ),
     2242        ?==?( double, double ),
     2243        ?!=?( double, double ),
     2244        ?==?( _Complex double, double ),
     2245        ?!=?( _Complex double, double ),
     2246        ?==?( double, _Complex double ),
     2247        ?!=?( double, _Complex double ),
     2248        ?==?( _Complex double, _Complex double ),
     2249        ?!=?( _Complex double, _Complex double ),
     2250        ?==?( long double, long double ),
     2251        ?!=?( long double, long double ),
     2252        ?==?( _Complex long double, long double ),
     2253        ?!=?( _Complex long double, long double ),
     2254        ?==?( long double, _Complex long double ),
     2255        ?!=?( long double, _Complex long double ),
     2256        ?==?( _Complex long double, _Complex long double ),
     2257        ?!=?( _Complex long double, _Complex long double );
     2258
    17532259forall( dtype DT ) int
    17542260        ?==?( const restrict volatile DT *, const restrict volatile DT * ),
    … …  
    17752281        ?==?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * ),
    17762282        ?!=?( forall( dtype DT2) const DT2*, _Atomic const restrict volatile DT * );
     2283
    17772284forall( ftype FT ) int
    1778         ?==?( FT *, FT * ), ?!=?( FT *, FT * ),
    1779         ?==?( FT *, forall( ftype FT2) FT2 * ), ?!=?( FT *, forall( ftype FT2) FT2 * ),
    1780         ?==?( forall( ftype FT2) FT2*, FT * ), ?!=?( forall( ftype FT2) FT2*, FT * ),
    1781         ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    1782 \end{lstlisting}
    1783 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2285        ?==?( FT *, FT * ),
     2286        ?!=?( FT *, FT * ),
     2287        ?==?( FT *, forall( ftype FT2) FT2 * ),
     2288        ?!=?( FT *, forall( ftype FT2) FT2 * ),
     2289        ?==?( forall( ftype FT2) FT2*, FT * ),
     2290        ?!=?( forall( ftype FT2) FT2*, FT * ),
     2291        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ),
     2292        ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
     2293\end{lstlisting}
     2294For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2295rank of \lstinline$int$ there exist
    17842296% Don't use predefined: keep this out of prelude.cf.
    17852297\begin{lstlisting}
    … …  
    17892301
    17902302\begin{rationale}
    1791 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to ©void© and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
    1792 In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
     2303The polymorphic equality operations come in three styles: comparisons between pointers of compatible
     2304types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and
     2305between the \Index{null pointer} constant and pointers to any type. In the last case, a special
     2306constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA
     2307type system.
    17932308\end{rationale}
    17942309
    17952310\semantics
    1796 The interpretations of an equality expression are the interpretations of the corresponding function call.
     2311The interpretations of an equality expression are the interpretations of the corresponding function
     2312call.
    17972313
    17982314\begin{sloppypar}
    1799 The result of an equality comparison between two pointers to predefined functions or predefined values is implementation-defined.
     2315The result of an equality comparison between two pointers to predefined functions or predefined
     2316values is implementation-defined.
    18002317\end{sloppypar}
    18012318\begin{rationale}
    1802 The implementation-defined status of equality comparisons allows implementations to use one library routine to implement many predefined functions.
    1803 These optimization are particularly important when the predefined functions are polymorphic, as is the case for most pointer operations
     2319The implementation-defined status of equality comparisons allows implementations to use one library
     2320routine to implement many predefined functions. These optimization are particularly important when
     2321the predefined functions are polymorphic, as is the case for most pointer operations
    18042322\end{rationale}
    18052323
    … …  
    18102328\lhs{AND-expression}
    18112329\rhs \nonterm{equality-expression}
    1812 \rhs \nonterm{AND-expression} ©&© \nonterm{equality-expression}
     2330\rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression}
    18132331\end{syntax}
    18142332
    18152333\rewriterules
    18162334\begin{lstlisting}
    1817 a & b => ?&?( a, b )§\use{?&?}§
    1818 \end{lstlisting}
    1819 
    1820 \predefined
     2335a & b @\rewrite@ ?&?( a, b )@\use{?&?}@
     2336\end{lstlisting}
     2337
    18212338\begin{lstlisting}
    18222339int ?&?( int, int );
    … …  
    18272344long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    18282345\end{lstlisting}
    1829 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2346For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2347rank of \lstinline$int$ there exist
    18302348% Don't use predefined: keep this out of prelude.cf.
    18312349\begin{lstlisting}
    … …  
    18342352
    18352353\semantics
    1836 The interpretations of a bitwise AND expression are the interpretations of the corresponding function call.
     2354The interpretations of a bitwise AND expression are the interpretations of the corresponding
     2355function call.
    18372356
    18382357
    … …  
    18422361\lhs{exclusive-OR-expression}
    18432362\rhs \nonterm{AND-expression}
    1844 \rhs \nonterm{exclusive-OR-expression} ©^© \nonterm{AND-expression}
     2363\rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression}
    18452364\end{syntax}
    18462365
    18472366\rewriterules
    18482367\begin{lstlisting}
    1849 a ^ b => ?^?( a, b )§\use{?^?}§
    1850 \end{lstlisting}
    1851 
    1852 \predefined
     2368a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@
     2369\end{lstlisting}
     2370
    18532371\begin{lstlisting}
    18542372int ?^?( int, int );
    … …  
    18592377long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    18602378\end{lstlisting}
    1861 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2379For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2380rank of \lstinline$int$ there exist
    18622381% Don't use predefined: keep this out of prelude.cf.
    18632382\begin{lstlisting}
    … …  
    18662385
    18672386\semantics
    1868 The interpretations of a bitwise exclusive OR expression are the interpretations of the corresponding function call.
     2387The interpretations of a bitwise exclusive OR expression are the interpretations of the
     2388corresponding function call.
    18692389
    18702390
    … …  
    18742394\lhs{inclusive-OR-expression}
    18752395\rhs \nonterm{exclusive-OR-expression}
    1876 \rhs \nonterm{inclusive-OR-expression} ©|© \nonterm{exclusive-OR-expression}
     2396\rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression}
    18772397\end{syntax}
    18782398
    1879 \rewriterules
    1880 \begin{lstlisting}
    1881 a | b => ?|?( a, b )§\use{?"|?}§
    1882 \end{lstlisting}
    1883 
    1884 \predefined
     2399\rewriterules\use{?"|?}
     2400\begin{lstlisting}
     2401a | b @\rewrite@ ?|?( a, b )
     2402\end{lstlisting}
     2403
    18852404\begin{lstlisting}
    18862405int ?|?( int, int );
    … …  
    18912410long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    18922411\end{lstlisting}
    1893 For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
     2412For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the
     2413rank of \lstinline$int$ there exist
    18942414% Don't use predefined: keep this out of prelude.cf.
    18952415\begin{lstlisting}
    … …  
    18982418
    18992419\semantics
    1900 The interpretations of a bitwise inclusive OR expression are the interpretations of the corresponding function call.
     2420The interpretations of a bitwise inclusive OR expression are the interpretations of the
     2421corresponding function call.
    19012422
    19022423
    … …  
    19062427\lhs{logical-AND-expression}
    19072428\rhs \nonterm{inclusive-OR-expression}
    1908 \rhs \nonterm{logical-AND-expression} ©&&© \nonterm{inclusive-OR-expression}
     2429\rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression}
    19092430\end{syntax}
    19102431
    1911 \semantics The operands of the expression ``©a && b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b)!=0)©'', which shall both be unambiguous.
    1912 The expression has only one interpretation, which is of type ©int©.
    1913 \begin{rationale}
    1914 When the operands of a logical expression are values of built-in types, and ``©!=©'' has not been redefined for those types, the compiler can optimize away the function calls.
    1915 
    1916 A common C idiom omits comparisons to ©0© in the controlling expressions of loops and ©if© statements.
    1917 For instance, the loop below iterates as long as ©rp© points at a ©Rational© value that is non-zero.
    1918 
    1919 \begin{lstlisting}
    1920 extern otype Rational;§\use{Rational}§
    1921 extern const Rational 0;§\use{0}§
     2432\semantics The operands of the expression ``\lstinline$a && b$'' are treated as
     2433``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be
     2434unambiguous. The expression has only one interpretation, which is of type \lstinline$int$.
     2435\begin{rationale}
     2436When the operands of a logical expression are values of built-in types, and ``\lstinline$!=$'' has
     2437not been redefined for those types, the compiler can optimize away the function calls.
     2438
     2439A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
     2440\lstinline$if$ statements. For instance, the loop below iterates as long as \lstinline$rp$ points
     2441at a \lstinline$Rational$ value that is non-zero.
     2442
     2443\begin{lstlisting}
     2444extern type Rational;@\use{Rational}@
     2445extern const Rational 0;@\use{0}@
    19222446extern int ?!=?( Rational, Rational );
    19232447Rational *rp;
     2448
    19242449while ( rp && *rp ) { ... }
    19252450\end{lstlisting}
    1926 The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result.
    1927 In contrast, {\CC} would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
    1928 The conversion to ©int© would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
     2451The logical expression calls the \lstinline$Rational$ inequality operator, passing
     2452it \lstinline$*rp$ and the \lstinline$Rational 0$, and getting a 1 or 0 as a result. In
     2453contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$
     2454conversion to \lstinline$*rp$ in the equivalent situation. The conversion to \lstinline$int$ would
     2455produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was
     2456not written with this situation in mind.
    19292457\end{rationale}
    19302458
    … …  
    19352463\lhs{logical-OR-expression}
    19362464\rhs \nonterm{logical-AND-expression}
    1937 \rhs \nonterm{logical-OR-expression} ©||© \nonterm{logical-AND-expression}
     2465\rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression}
    19382466\end{syntax}
    19392467
    19402468\semantics
    19412469
    1942 The operands of the expression ``©a || b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b))!=0)©'', which shall both be unambiguous.
    1943 The expression has only one interpretation, which is of type ©int©.
     2470The operands of the expression ``\lstinline$a || b$'' are treated as ``\lstinline$(int)((a)!=0)$''
     2471and ``\lstinline$(int)((b))!=0)$'', which shall both be unambiguous. The expression has only one
     2472interpretation, which is of type \lstinline$int$.
    19442473
    19452474
    … …  
    19492478\lhs{conditional-expression}
    19502479\rhs \nonterm{logical-OR-expression}
    1951 \rhs \nonterm{logical-OR-expression} ©?© \nonterm{expression}
    1952          ©:© \nonterm{conditional-expression}
     2480\rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression}
     2481         \lstinline$:$ \nonterm{conditional-expression}
    19532482\end{syntax}
    19542483
    19552484\semantics
    1956 In the conditional expression\use{?:} ``©a?b:c©'', if the second and third operands both have an interpretation with ©void© type, then the expression has an interpretation with type ©void©, equivalent to
     2485In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and
     2486third operands both have an interpretation with \lstinline$void$ type, then the expression has an
     2487interpretation with type \lstinline$void$, equivalent to
    19572488\begin{lstlisting}
    19582489( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    19592490\end{lstlisting}
    19602491
    1961 If the second and third operands both have interpretations with non-©void© types, the expression is treated as if it were the call ``©cond((a)!=0, b, c)©'', with ©cond© declared as
    1962 \begin{lstlisting}
    1963 forall( otype T ) T cond( int, T, T );
    1964 forall( dtype D ) void * cond( int, D *, void * ), * cond( int, void *, D * );
    1965 forall( dtype D ) _atomic void * cond(
    1966         int, _Atomic D *, _Atomic void * ), * cond( int, _Atomic void *, _Atomic D * );
    1967 forall( dtype D ) const void * cond(
    1968         int, const D *, const void * ), * cond( int, const void *, const D * );
    1969 forall( dtype D ) restrict void * cond(
    1970         int, restrict D *, restrict void * ), * cond( int, restrict void *, restrict D * );
    1971 forall( dtype D ) volatile void * cond(
    1972         int, volatile D *, volatile void * ), * cond( int, volatile void *, volatile D * );
    1973 forall( dtype D ) _Atomic const void * cond(
    1974         int, _Atomic const D *, _Atomic const void * ), * cond( int, _Atomic const void *, _Atomic const D * );
    1975 forall( dtype D ) _Atomic restrict void * cond(
    1976         int, _Atomic restrict D *, _Atomic restrict void * ), * cond( int, _Atomic restrict void *, _Atomic restrict D * );
    1977 forall( dtype D ) _Atomic volatile void * cond(
    1978         int, _Atomic volatile D *, _Atomic volatile void * ), * cond( int, _Atomic volatile void *, _Atomic volatile D * );
    1979 forall( dtype D ) const restrict void * cond(
    1980         int, const restrict D *, const restrict void * ), * cond( int, const restrict void *, const restrict D * );
    1981 forall( dtype D ) const volatile void * cond(
    1982         int, const volatile D *, const volatile void * ), * cond( int, const volatile void *, const volatile D * );
    1983 forall( dtype D ) restrict volatile void * cond(
    1984         int, restrict volatile D *, restrict volatile void * ), * cond( int, restrict volatile void *, restrict volatile D * );
    1985 forall( dtype D ) _Atomic const restrict void * cond(
    1986         int, _Atomic const restrict D *, _Atomic const restrict void * ),
     2492If the second and third operands both have interpretations with non-\lstinline$void$ types, the
     2493expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'',
     2494with \lstinline$cond$ declared as
     2495\begin{lstlisting}
     2496forall( type T ) T cond( int, T, T );
     2497 
     2498forall( dtype D ) void
     2499        * cond( int, D *, void * ),
     2500        * cond( int, void *, D * );
     2501       
     2502forall( dtype D ) _atomic void
     2503        * cond( int, _Atomic D *, _Atomic void * ),
     2504        * cond( int, _Atomic void *, _Atomic D * );
     2505
     2506forall( dtype D ) const void
     2507        * cond( int, const D *, const void * ),
     2508        * cond( int, const void *, const D * );
     2509
     2510forall( dtype D ) restrict void
     2511        * cond( int, restrict D *, restrict void * ),
     2512        * cond( int, restrict void *, restrict D * );
     2513
     2514forall( dtype D ) volatile void
     2515        * cond( int, volatile D *, volatile void * ),
     2516        * cond( int, volatile void *, volatile D * );
     2517
     2518forall( dtype D ) _Atomic const void
     2519        * cond( int, _Atomic const D *, _Atomic const void * ),
     2520        * cond( int, _Atomic const void *, _Atomic const D * );
     2521
     2522forall( dtype D ) _Atomic restrict void
     2523        * cond( int, _Atomic restrict D *, _Atomic restrict void * ),
     2524        * cond( int, _Atomic restrict void *, _Atomic restrict D * );
     2525
     2526forall( dtype D ) _Atomic volatile void
     2527        * cond( int, _Atomic volatile D *, _Atomic volatile void * ),
     2528        * cond( int, _Atomic volatile void *, _Atomic volatile D * );
     2529
     2530forall( dtype D ) const restrict void
     2531        * cond( int, const restrict D *, const restrict void * ),
     2532        * cond( int, const restrict void *, const restrict D * );
     2533
     2534forall( dtype D ) const volatile void
     2535        * cond( int, const volatile D *, const volatile void * ),
     2536        * cond( int, const volatile void *, const volatile D * );
     2537
     2538forall( dtype D ) restrict volatile void
     2539        * cond( int, restrict volatile D *, restrict volatile void * ),
     2540        * cond( int, restrict volatile void *, restrict volatile D * );
     2541
     2542forall( dtype D ) _Atomic const restrict void
     2543        * cond( int, _Atomic const restrict D *, _Atomic const restrict void * ),
    19872544        * cond( int, _Atomic const restrict void *, _Atomic const restrict D * );
    1988 forall( dtype D ) _Atomic const volatile void * cond(
    1989         int, _Atomic const volatile D *, _Atomic const volatile void * ),
     2545
     2546forall( dtype D ) _Atomic const volatile void
     2547        * cond( int, _Atomic const volatile D *, _Atomic const volatile void * ),
    19902548        * cond( int, _Atomic const volatile void *, _Atomic const volatile D * );
    1991 forall( dtype D ) _Atomic restrict volatile void * cond(
    1992         int, _Atomic restrict volatile D *, _Atomic restrict volatile void * ),
    1993         * cond( int, _Atomic restrict volatile void *, _Atomic restrict volatile D * );
    1994 forall( dtype D ) const restrict volatile void * cond(
    1995         int, const restrict volatile D *, const restrict volatile void * ),
    1996         * cond( int, const restrict volatile void *, const restrict volatile D * );
    1997 forall( dtype D ) _Atomic const restrict volatile void * cond(
    1998         int, _Atomic const restrict volatile D *, _Atomic const restrict volatile void * ),
    1999         * cond( int, _Atomic const restrict volatile void *, _Atomic const restrict volatile D * );
    2000 \end{lstlisting}
    2001 
    2002 \begin{rationale}
    2003 The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and third operands have arithmetic type, and to combine the qualifiers of the second and third operands if they are pointers.
     2549
     2550forall( dtype D ) _Atomic restrict volatile void
     2551        * cond( int, _Atomic restrict volatile D *,
     2552         _Atomic restrict volatile void * ),
     2553        * cond( int, _Atomic restrict volatile void *,
     2554         _Atomic restrict volatile D * );
     2555
     2556forall( dtype D ) const restrict volatile void
     2557        * cond( int, const restrict volatile D *,
     2558         const restrict volatile void * ),
     2559        * cond( int, const restrict volatile void *,
     2560         const restrict volatile D * );
     2561
     2562forall( dtype D ) _Atomic const restrict volatile void
     2563        * cond( int, _Atomic const restrict volatile D *,
     2564         _Atomic const restrict volatile void * ),
     2565        * cond( int, _Atomic const restrict volatile void *,
     2566         _Atomic const restrict volatile D * );
     2567\end{lstlisting}
     2568
     2569\begin{rationale}
     2570The object of the above is to apply the \Index{usual arithmetic conversion}s when the second and
     2571third operands have arithmetic type, and to combine the qualifiers of the second and third operands
     2572if they are pointers.
    20042573\end{rationale}
    20052574
    … …  
    20112580rand() ? i : l;
    20122581\end{lstlisting}
    2013 The best interpretation infers the expression's type to be ©long© and applies the safe ©int©-to-©long© conversion to ©i©.
     2582The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe
     2583\lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$.
    20142584
    20152585\begin{lstlisting}
    … …  
    20182588rand() ? cip : vip;
    20192589\end{lstlisting}
    2020 The expression has type ©const volatile int *©, with safe conversions applied to the second and third operands to add ©volatile© and ©const© qualifiers, respectively.
     2590The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second
     2591and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
    20212592
    20222593\begin{lstlisting}
    20232594rand() ? cip : 0;
    20242595\end{lstlisting}
    2025 The expression has type ©const int *©, with a specialization conversion applied to ©0©.
     2596The expression has type \lstinline$const int *$, with a specialization conversion applied to
     2597\lstinline$0$.
    20262598
    20272599
    … …  
    20342606         \nonterm{assignment-expression}
    20352607\lhs{assignment-operator} one of
    2036 \rhs ©=©\ \ ©*=©\ \ ©/=©\ \ ©%=©\ \ ©+=©\ \ ©-=©\ \ ©<<=©\ \ ©>>=©\ \ ©&=©\ \ ©^=©\ \ ©|=©
     2608\rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \ 
     2609         \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$
    20372610\end{syntax}
    20382611
    20392612\rewriterules
    2040 Let ``©<-©'' be any of the assignment operators.
    2041 Then
    2042 \use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    2043 \begin{lstlisting}
    2044 a <- b => ?<-?( &( a ), b )
     2613Let ``\(\leftarrow\)'' be any of the assignment operators. Then
     2614\use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}
     2615\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
     2616\begin{lstlisting}
     2617a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b )
    20452618\end{lstlisting}
    20462619
    20472620\semantics
    2048 Each interpretation of the left operand of an assignment expression is considered separately.
    2049 For each interpretation that is a bit-field or is declared with the ©register© storage class specifier, the expression has one valid interpretation, with the type of the left operand.
    2050 The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    2051 For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
    2052 Finally, all interpretations of the expression produced for the different interpretations of the left operand are combined to produce the interpretations of the expression as a whole;
    2053 where interpretations have compatible result types, the best interpretations are selected in the manner described for function call expressions.
     2621Each interpretation of the left operand of an assignment expression is considered separately. For
     2622each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class
     2623specifier, the expression has one valid interpretation, with the type of the left operand. The
     2624right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
     2625For the remaining interpretations, the expression is rewritten, and the interpretations of the
     2626assignment expression are the interpretations of the corresponding function call. Finally, all
     2627interpretations of the expression produced for the different interpretations of the left operand are
     2628combined to produce the interpretations of the expression as a whole; where interpretations have
     2629compatible result types, the best interpretations are selected in the manner described for function
     2630call expressions.
    20542631
    20552632
    20562633\subsubsection{Simple assignment}
    20572634
    2058 \predefined
    20592635\begin{lstlisting}
    20602636_Bool
    … …  
    21162692        ?=?( volatile _Complex long double *, _Complex long double ),
    21172693        ?=?( _Atomic volatile _Complex long double *, _Atomic _Complex long double );
     2694
    21182695forall( ftype FT ) FT
    21192696        * ?=?( FT * volatile *, FT * ),
    21202697        * ?=?( FT * volatile *, forall( ftype F ) F * );
     2698
    21212699forall( ftype FT ) FT const
    21222700        * ?=?( FT const * volatile *, FT const * ),
    21232701        * ?=?( FT const * volatile *, forall( ftype F ) F * );
     2702
    21242703forall( ftype FT ) FT volatile
    21252704        * ?=?( FT volatile * volatile *, FT * ),
    21262705        * ?=?( FT volatile * volatile *, forall( ftype F ) F * );
     2706
    21272707forall( ftype FT ) FT const
    21282708        * ?=?( FT const volatile * volatile *, FT const * ),
    21292709        * ?=?( FT const volatile * volatile *, forall( ftype F ) F * );
     2710
    21302711forall( dtype DT ) DT
    21312712        * ?=?( DT * restrict volatile *, DT * ),
    … …  
    21352716        * ?=?( DT * _Atomic restrict volatile *, void * ),
    21362717        * ?=?( DT * _Atomic restrict volatile *, forall( dtype D ) D * );
     2718
    21372719forall( dtype DT ) DT _Atomic
    21382720        * ?=?( _Atomic DT * restrict volatile *, DT _Atomic * ),
    … …  
    21422724        * ?=?( _Atomic DT * _Atomic restrict volatile *, void * ),
    21432725        * ?=?( _Atomic DT * _Atomic restrict volatile *, forall( dtype D ) D * );
     2726
    21442727forall( dtype DT ) DT const
    21452728        * ?=?( DT const * restrict volatile *, DT const * ),
    … …  
    21492732        * ?=?( DT const * _Atomic restrict volatile *, void const * ),
    21502733        * ?=?( DT const * _Atomic restrict volatile *, forall( dtype D ) D * );
     2734
    21512735forall( dtype DT ) DT restrict
    21522736        * ?=?( restrict DT * restrict volatile *, DT restrict * ),
    … …  
    21562740        * ?=?( restrict DT * _Atomic restrict volatile *, void * ),
    21572741        * ?=?( restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
     2742
    21582743forall( dtype DT ) DT volatile
    21592744        * ?=?( DT volatile * restrict volatile *, DT volatile * ),
    … …  
    21632748        * ?=?( DT volatile * _Atomic restrict volatile *, void volatile * ),
    21642749        * ?=?( DT volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
     2750
    21652751forall( dtype DT ) DT _Atomic const
    21662752        * ?=?( DT _Atomic const * restrict volatile *, DT _Atomic const * ),
    … …  
    21702756        * ?=?( DT _Atomic const * _Atomic restrict volatile *, void const * ),
    21712757        * ?=?( DT _Atomic const * _Atomic restrict volatile *, forall( dtype D ) D * );
     2758
    21722759forall( dtype DT ) DT _Atomic restrict
    21732760        * ?=?( _Atomic restrict DT * restrict volatile *, DT _Atomic restrict * ),
    … …  
    21772764        * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, void * ),
    21782765        * ?=?( _Atomic restrict DT * _Atomic restrict volatile *, forall( dtype D ) D * );
     2766
    21792767forall( dtype DT ) DT _Atomic volatile
    21802768        * ?=?( DT _Atomic volatile * restrict volatile *, DT _Atomic volatile * ),
    … …  
    21842772        * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, void volatile * ),
    21852773        * ?=?( DT _Atomic volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
     2774
    21862775forall( dtype DT ) DT const restrict
    21872776        * ?=?( DT const restrict * restrict volatile *, DT const restrict * ),
    … …  
    21912780        * ?=?( DT const restrict * _Atomic restrict volatile *, void const * ),
    21922781        * ?=?( DT const restrict * _Atomic restrict volatile *, forall( dtype D ) D * );
     2782
    21932783forall( dtype DT ) DT const volatile
    21942784        * ?=?( DT const volatile * restrict volatile *, DT const volatile * ),
    … …  
    21982788        * ?=?( DT const volatile * _Atomic restrict volatile *, void const volatile * ),
    21992789        * ?=?( DT const volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
     2790
    22002791forall( dtype DT ) DT restrict volatile
    22012792        * ?=?( DT restrict volatile * restrict volatile *, DT restrict volatile * ),
    … …  
    22052796        * ?=?( DT restrict volatile * _Atomic restrict volatile *, void volatile * ),
    22062797        * ?=?( DT restrict volatile * _Atomic restrict volatile *, forall( dtype D ) D * );
     2798
    22072799forall( dtype DT ) DT _Atomic const restrict
    22082800        * ?=?( DT _Atomic const restrict * restrict volatile *,
    … …  
    22182810        * ?=?( DT _Atomic const restrict * _Atomic restrict volatile *,
    22192811         forall( dtype D ) D * );
     2812
    22202813forall( dtype DT ) DT _Atomic const volatile
    22212814        * ?=?( DT _Atomic const volatile * restrict volatile *,
    … …  
    22312824        * ?=?( DT _Atomic const volatile * _Atomic restrict volatile *,
    22322825         forall( dtype D ) D * );
     2826
    22332827forall( dtype DT ) DT _Atomic restrict volatile
    22342828        * ?=?( DT _Atomic restrict volatile * restrict volatile *,
    … …  
    22442838        * ?=?( DT _Atomic restrict volatile * _Atomic restrict volatile *,
    22452839         forall( dtype D ) D * );
     2840
    22462841forall( dtype DT ) DT const restrict volatile
    22472842        * ?=?( DT const restrict volatile * restrict volatile *,
    … …  
    22572852        * ?=?( DT const restrict volatile * _Atomic restrict volatile *,
    22582853         forall( dtype D ) D * );
     2854
    22592855forall( dtype DT ) DT _Atomic const restrict volatile
    22602856        * ?=?( DT _Atomic const restrict volatile * restrict volatile *,
    … …  
    22702866        * ?=?( DT _Atomic const restrict volatile * _Atomic restrict volatile *,
    22712867         forall( dtype D ) D * );
     2868
    22722869forall( dtype DT ) void
    22732870        * ?=?( void * restrict volatile *, DT * );
     2871
    22742872forall( dtype DT ) void const
    22752873        * ?=?( void const * restrict volatile *, DT const * );
     2874
    22762875forall( dtype DT ) void volatile
    22772876        * ?=?( void volatile * restrict volatile *, DT volatile * );
     2877
    22782878forall( dtype DT ) void const volatile
    22792879        * ?=?( void const volatile * restrict volatile *, DT const volatile * );
    22802880\end{lstlisting}
    22812881\begin{rationale}
    2282 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a ©dtype© parameter, instead of a ©type© parameter, because the left operand may be a pointer to an incomplete type.
    2283 \end{rationale}
    2284 
    2285 For every complete structure or union type ©S© there exist
     2882The pattern of overloadings for simple assignment resembles that of pointer increment and decrement,
     2883except that the polymorphic pointer assignment functions declare a \lstinline$dtype$ parameter,
     2884instead of a \lstinline$type$ parameter, because the left operand may be a pointer to an incomplete
     2885type.
     2886\end{rationale}
     2887
     2888For every complete structure or union type \lstinline$S$ there exist
    22862889% Don't use predefined: keep this out of prelude.cf.
    22872890\begin{lstlisting}
    … …  
    22892892\end{lstlisting}
    22902893
    2291 For every extended integer type ©X© there exist
     2894For every extended integer type \lstinline$X$ there exist
    22922895% Don't use predefined: keep this out of prelude.cf.
    22932896\begin{lstlisting}
    … …  
    22952898\end{lstlisting}
    22962899
    2297 For every complete enumerated type ©E© there exist
     2900For every complete enumerated type \lstinline$E$ there exist
    22982901% Don't use predefined: keep this out of prelude.cf.
    22992902\begin{lstlisting}
    … …  
    23012904\end{lstlisting}
    23022905\begin{rationale}
    2303 The right-hand argument is ©int© because enumeration constants have type ©int©.
     2906The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$.
    23042907\end{rationale}
    23052908
    23062909\semantics
    2307 The structure assignment functions provide member-wise assignment;
    2308 each non-array member and each element of each array member of the right argument is assigned to the corresponding member or element of the left argument using the assignment function defined for its type.
    2309 All other assignment functions have the same effect as the corresponding C assignment expression.
    2310 \begin{rationale}
    2311 Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
     2910The structure assignment functions provide member-wise assignment; each non-array member and each
     2911element of each array member of the right argument is assigned to the corresponding member or
     2912element of the left argument using the assignment function defined for its type. All other
     2913assignment functions have the same effect as the corresponding C assignment expression.
     2914\begin{rationale}
     2915Note that, by default, union assignment\index{deficiencies!union assignment} uses C semantics---that
     2916is, bitwise copy---even if some of the union members have programmer-defined assignment functions.
    23122917\end{rationale}
    23132918
    … …  
    23152920\subsubsection{Compound assignment}
    23162921
    2317 \predefined
    2318 \begin{lstlisting}
    2319 forall( otype T ) T
     2922\begin{lstlisting}
     2923forall( type T ) T
    23202924        * ?+=?( T * restrict volatile *, ptrdiff_t ),
    23212925        * ?-=?( T * restrict volatile *, ptrdiff_t ),
    23222926        * ?+=?( T * _Atomic restrict volatile *, ptrdiff_t ),
    23232927        * ?-=?( T * _Atomic restrict volatile *, ptrdiff_t );
    2324 forall( otype T ) T _Atomic
     2928
     2929forall( type T ) T _Atomic
    23252930        * ?+=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    23262931        * ?-=?( T _Atomic * restrict volatile *, ptrdiff_t ),
    23272932        * ?+=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t ),
    23282933        * ?-=?( T _Atomic * _Atomic restrict volatile *, ptrdiff_t );
    2329 forall( otype T ) T const
     2934
     2935forall( type T ) T const
    23302936        * ?+=?( T const * restrict volatile *, ptrdiff_t ),
    23312937        * ?-=?( T const * restrict volatile *, ptrdiff_t ),
    23322938        * ?+=?( T const * _Atomic restrict volatile *, ptrdiff_t ),
    23332939        * ?-=?( T const * _Atomic restrict volatile *, ptrdiff_t );
    2334 forall( otype T ) T restrict
     2940
     2941forall( type T ) T restrict
    23352942        * ?+=?( T restrict * restrict volatile *, ptrdiff_t ),
    23362943        * ?-=?( T restrict * restrict volatile *, ptrdiff_t ),
    23372944        * ?+=?( T restrict * _Atomic restrict volatile *, ptrdiff_t ),
    23382945        * ?-=?( T restrict * _Atomic restrict volatile *, ptrdiff_t );
    2339 forall( otype T ) T volatile
     2946
     2947forall( type T ) T volatile
    23402948        * ?+=?( T volatile * restrict volatile *, ptrdiff_t ),
    23412949        * ?-=?( T volatile * restrict volatile *, ptrdiff_t ),
    23422950        * ?+=?( T volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23432951        * ?-=?( T volatile * _Atomic restrict volatile *, ptrdiff_t );
    2344 forall( otype T ) T _Atomic const
     2952
     2953forall( type T ) T _Atomic const
    23452954        * ?+=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    23462955        * ?-=?( T _Atomic const restrict volatile *, ptrdiff_t ),
    23472956        * ?+=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t ),
    23482957        * ?-=?( T _Atomic const _Atomic restrict volatile *, ptrdiff_t );
    2349 forall( otype T ) T _Atomic restrict
     2958
     2959forall( type T ) T _Atomic restrict
    23502960        * ?+=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    23512961        * ?-=?( T _Atomic restrict * restrict volatile *, ptrdiff_t ),
    23522962        * ?+=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t ),
    23532963        * ?-=?( T _Atomic restrict * _Atomic restrict volatile *, ptrdiff_t );
    2354 forall( otype T ) T _Atomic volatile
     2964
     2965forall( type T ) T _Atomic volatile
    23552966        * ?+=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    23562967        * ?-=?( T _Atomic volatile * restrict volatile *, ptrdiff_t ),
    23572968        * ?+=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23582969        * ?-=?( T _Atomic volatile * _Atomic restrict volatile *, ptrdiff_t );
    2359 forall( otype T ) T const restrict
     2970
     2971forall( type T ) T const restrict
    23602972        * ?+=?( T const restrict * restrict volatile *, ptrdiff_t ),
    23612973        * ?-=?( T const restrict * restrict volatile *, ptrdiff_t ),
    23622974        * ?+=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    23632975        * ?-=?( T const restrict * _Atomic restrict volatile *, ptrdiff_t );
    2364 forall( otype T ) T const volatile
     2976
     2977forall( type T ) T const volatile
    23652978        * ?+=?( T const volatile * restrict volatile *, ptrdiff_t ),
    23662979        * ?-=?( T const volatile * restrict volatile *, ptrdiff_t ),
    23672980        * ?+=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23682981        * ?-=?( T const volatile * _Atomic restrict volatile *, ptrdiff_t );
    2369 forall( otype T ) T restrict volatile
     2982
     2983forall( type T ) T restrict volatile
    23702984        * ?+=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    23712985        * ?-=?( T restrict volatile * restrict volatile *, ptrdiff_t ),
    23722986        * ?+=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23732987        * ?-=?( T restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    2374 forall( otype T ) T _Atomic const restrict
     2988
     2989forall( type T ) T _Atomic const restrict
    23752990        * ?+=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    23762991        * ?-=?( T _Atomic const restrict * restrict volatile *, ptrdiff_t ),
    23772992        * ?+=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t ),
    23782993        * ?-=?( T _Atomic const restrict * _Atomic restrict volatile *, ptrdiff_t );
    2379 forall( otype T ) T _Atomic const volatile
     2994
     2995forall( type T ) T _Atomic const volatile
    23802996        * ?+=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    23812997        * ?-=?( T _Atomic const volatile * restrict volatile *, ptrdiff_t ),
    23822998        * ?+=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23832999        * ?-=?( T _Atomic const volatile * _Atomic restrict volatile *, ptrdiff_t );
    2384 forall( otype T ) T _Atomic restrict volatile
     3000
     3001forall( type T ) T _Atomic restrict volatile
    23853002        * ?+=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    23863003        * ?-=?( T _Atomic restrict volatile * restrict volatile *, ptrdiff_t ),
    23873004        * ?+=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23883005        * ?-=?( T _Atomic restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    2389 forall( otype T ) T const restrict volatile
     3006
     3007forall( type T ) T const restrict volatile
    23903008        * ?+=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    23913009        * ?-=?( T const restrict volatile * restrict volatile *, ptrdiff_t ),
    23923010        * ?+=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t ),
    23933011        * ?-=?( T const restrict volatile * _Atomic restrict volatile *, ptrdiff_t );
    2394 forall( otype T ) T _Atomic const restrict volatile
     3012
     3013forall( type T ) T _Atomic const restrict volatile
    23953014        * ?+=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    23963015        * ?-=?( T _Atomic const restrict volatile * restrict volatile *, ptrdiff_t ),
    … …  
    25623181\end{lstlisting}
    25633182
    2564 For every extended integer type ©X© there exist
     3183For every extended integer type \lstinline$X$ there exist
    25653184% Don't use predefined: keep this out of prelude.cf.
    25663185\begin{lstlisting}
    … …  
    25773196\end{lstlisting}
    25783197
    2579 For every complete enumerated type ©E© there exist
     3198For every complete enumerated type \lstinline$E$ there exist
    25803199% Don't use predefined: keep this out of prelude.cf.
    25813200\begin{lstlisting}
    … …  
    25983217\lhs{expression}
    25993218\rhs \nonterm{assignment-expression}
    2600 \rhs \nonterm{expression} ©,© \nonterm{assignment-expression}
     3219\rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression}
    26013220\end{syntax}
    26023221
    26033222\semantics
    2604 In the comma expression ``©a, b©'', the first operand is interpreted as ``©( void )(a)©'', which shall be unambiguous\index{ambiguous interpretation}.
    2605 The interpretations of the expression are the interpretations of the second operand.
     3223In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
     3224``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}. The
     3225interpretations of the expression are the interpretations of the second operand.
    26063226
    26073227
    … …  
    26183238
    26193239\constraints
    2620 If an identifier has \Index{no linkage}, there shall be no more than one declaration of the identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the same name space, except that:
     3240If an identifier has \Index{no linkage}, there shall be no more than one declaration of the
     3241identifier ( in a declarator or type specifier ) with compatible types in the same scope and in the
     3242same name space, except that:
    26213243\begin{itemize}
    2622 \item a typedef name may be redefined to denote the same type as it currently does, provided that type is not a variably modified type;
    2623 \item tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
     3244\item
     3245a typedef name may be redefined to denote the same type as it currently does, provided that type is
     3246not a variably modified type;
     3247\item
     3248tags may be redeclared as specified in section 6.7.2.3 of the {\c11} standard.
    26243249\end{itemize}
    26253250\begin{rationale}
    2626 This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow overloading.
    2627 \end{rationale}
    2628 
    2629 An identifier declared by a type declaration shall not be redeclared as a parameter in a function definition whose declarator includes an identifier list.
    2630 \begin{rationale}
    2631 This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters.
    2632 This avoids an ambiguity between old-style function declarations and new-style function prototypes:
     3251This constraint adds the phrase ``with compatible types'' to the {\c11} constraint, to allow
     3252overloading.
     3253\end{rationale}
     3254
     3255An identifier declared by a type declaration shall not be redeclared as a parameter in a function
     3256definition whose declarator includes an identifier list.
     3257\begin{rationale}
     3258This restriction echos {\c11}'s ban on the redeclaration of typedef names as parameters. This
     3259avoids an ambiguity between old-style function declarations and new-style function prototypes:
    26333260\begin{lstlisting}
    26343261void f( Complex,        // ... 3000 characters ...
    26353262void g( Complex,        // ... 3000 characters ...
    2636 int Complex;
    2637 { ... }
    2638 \end{lstlisting}
    2639 Without the rule, ©Complex© would be a type in the first case, and a parameter name in the second.
     3263int Complex; { ... }
     3264\end{lstlisting}
     3265Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the
     3266second.
    26403267\end{rationale}
    26413268
    … …  
    26563283
    26573284\semantics
    2658 \CFA extends the {\c11} definition of \define{anonymous structure} to include structure specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union specifiers with tags.
     3285\CFA extends the {\c11} definition of \define{anonymous structure} to include structure
     3286specifiers with tags, and extends the {\c11} definition of \define{anonymous union} to include union
     3287specifiers with tags.
    26593288\begin{rationale}
    26603289This extension imitates an extension in the Plan 9 C compiler \cite{Thompson90new}.
    … …  
    26633292\examples
    26643293\begin{lstlisting}
    2665 struct point {§\impl{point}§
     3294struct point {@\impl{point}@
    26663295        int x, y;
    26673296};
    2668 struct color_point {§\impl{color_point}§
     3297struct color_point {@\impl{color_point}@
    26693298        enum { RED, BLUE, GREEN } color;
    26703299        struct point;
    … …  
    26733302cp.x = 0;
    26743303cp.color = RED;
    2675 struct literal {§\impl{literal}§
     3304
     3305struct literal {@\impl{literal}@
    26763306        enum { NUMBER, STRING } tag;
    26773307        union {
    2678                 double n;
    2679                 char *s;
     3308         double n;
     3309         char *s;
    26803310        };
    26813311};
    … …  
    26893319
    26903320\setcounter{subsubsection}{4}
    2691 \subsubsection{Forall specifiers}
    2692 \label{forall}
     3321\subsubsection{Forall specifiers}\label{forall}
    26933322
    26943323\begin{syntax}
    26953324\lhs{forall-specifier}
    2696 \rhs ©forall© ©(© \nonterm{type-parameter-list} ©)©
     3325\rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
    26973326\end{syntax}
    26983327
    2699 \begin{comment}
    27003328\constraints
    2701 If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier} declares a structure or union tag, the types of the members of the structure or union shall not use any of the type identifiers declared by the \nonterm{type-parameter-list}.
    2702 \begin{rationale}
    2703 This sort of declaration is illegal because the scope of the type identifiers ends at the end of the declaration, but the scope of the structure tag does not.
    2704 \begin{lstlisting}
    2705 forall( otype T ) struct Pair { T a, b;
    2706 } mkPair( T, T ); // illegal
    2707 \end{lstlisting}
    2708 If an instance of ©struct Pair© was declared later in the current scope, what would the members' type be?
    2709 \end{rationale}
    2710 \end{comment}
     3329If the \nonterm{declaration-specifiers} of a declaration that contains a \nonterm{forall-specifier}
     3330declares a structure or union tag, the types of the members of the structure or union shall not use
     3331any of the type identifiers declared by the \nonterm{type-parameter-list}.
     3332\begin{rationale}
     3333This sort of declaration is illegal because the scope of the type identifiers ends at the end of the
     3334declaration, but the scope of the structure tag does not.
     3335\begin{lstlisting}
     3336forall( type T ) struct Pair { T a, b; } mkPair( T, T ); // illegal
     3337\end{lstlisting}
     3338If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the
     3339members' type be?
     3340\end{rationale}
    27113341
    27123342\semantics
    2713 The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    2714 
    2715 If, in the declaration ``©T D©'', ©T© contains \nonterm{forall-specifier}s and ©D© has the form
    2716 \begin{lstlisting}
    2717 D( §\normalsize\nonterm{parameter-type-list}§ )
    2718 \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 ©D©, and it is used in the type of a parameter in the following
    2719 \nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a \Index{specification} in one of the \nonterm{forall-specifier}s.
    2720 The identifiers declared by assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s of that function declarator.
    2721 
    2722 \begin{comment}
    2723 \begin{rationale}
    2724 Since every inferred parameter is used by some parameter, inference can be understood as a single bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
     3343The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type
     3344identifiers, function and object identifiers with \Index{no linkage}.
     3345
     3346If, in the declaration ``\lstinline$T D1$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
     3347\lstinline$D1$ has the form
     3348\begin{lstlisting}
     3349D( @\normalsize\nonterm{parameter-type-list}@ )
     3350\end{lstlisting}
     3351then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred
     3352parameter} of the function declarator if and only if it is not an inferred parameter of a function
     3353declarator in \lstinline$D$, and it is used in the type of a parameter in the following
     3354\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
     3355\Index{specification} in one of the \nonterm{forall-specifier}s. The identifiers declared by
     3356assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s
     3357of that function declarator.
     3358\begin{rationale}
     3359Since every inferred parameter is used by some parameter, inference can be understood as a single
     3360bottom-up pass over the expression tree, that only needs to apply local reasoning at each node.
    27253361
    27263362If this restriction were lifted, it would be possible to write
    27273363\begin{lstlisting}
    2728 forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
    2729 \end{lstlisting}
    2730 Here ©alloc()© would receive ©int© as an inferred argument, and return an ©int *©.
    2731 In general, if a call to ©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 ©T© to be bound.
    2732 
    2733 With the current restriction, ©alloc()© must be given an argument that determines ©T©:
    2734 \begin{lstlisting}
    2735 forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
    2736 \end{lstlisting}
    2737 \end{rationale}
    2738 \end{comment}
    2739 
    2740 If a function declarator is part of a function definition, its inferred parameters and assertion parameters have \Index{block scope};
    2741 otherwise, identifiers declared by assertions have a \define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
     3364forall( type T ) T * alloc( void );@\use{alloc}@
     3365int *p = alloc();
     3366\end{lstlisting}
     3367Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
     3368\lstinline$int *$. In general, if a call to \lstinline$alloc()$ is a subexpression of an expression
     3369involving polymorphic functions and overloaded identifiers, there could be considerable distance
     3370between the call and the subexpression that causes \lstinline$T$ to be bound.
     3371
     3372With the current restriction, \lstinline$alloc()$ must be given an argument that determines
     3373\lstinline$T$:
     3374\begin{lstlisting}
     3375forall( type T ) T * alloc( T initial_value );@\use{alloc}@
     3376\end{lstlisting}
     3377\end{rationale}
     3378
     3379If a function declarator is part of a function definition, its inferred parameters and assertion
     3380parameters have \Index{block scope}; otherwise, identifiers declared by assertions have a
     3381\define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
    27423382
    27433383A function type that has at least one inferred parameter is a \define{polymorphic function} type.
    2744 Function types with no inferred parameters are \define{monomorphic function} types.
    2745 One function type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the same number of inferred parameters and fewer of its explicit parameters have types that depend on an inferred parameter.
    2746 
    2747 The names of inferred parameters and the order of identifiers in forall specifiers are not relevant to polymorphic function type compatibility.
    2748 Let $f$ and $g$ be two polymorphic function types with the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$ and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s.
    2749 Let $f'$ be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$.
    2750 Then $f$ and $g$ are \Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same identifier and compatible type, and vice versa.
     3384Function types with no inferred parameters are \define{monomorphic function} types. One function
     3385type is \define{less polymorphic} than another if it has fewer inferred parameters, or if it has the
     3386same number of inferred parameters and fewer of its explicit parameters have types that depend on an
     3387inferred parameter.
     3388
     3389The names of inferred parameters and the order of identifiers in forall specifiers are not relevant
     3390to polymorphic function type compatibility. Let $f$ and $g$ be two polymorphic function types with
     3391the same number of inferred parameters, and let $f_i$ and $g_i$ be the inferred parameters of $f$
     3392and $g$ in their order of occurance in the function types' \nonterm{parameter-type-list}s. Let $f'$
     3393be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$. Then $f$ and $g$ are
     3394\Index{compatible type}s if $f'$'s and $g$'s return types and parameter lists are compatible, and if
     3395for every assertion parameter of $f'$ there is an assertion parameter in $g$ with the same
     3396identifier and compatible type, and vice versa.
    27513397
    27523398\examples
    … …  
    27543400\begin{lstlisting}
    27553401int fi( int );
    2756 forall( otype T ) T fT( T );
    2757 \end{lstlisting}
    2758 ©fi()© takes an ©int© and returns an ©int©. ©fT()© takes a ©T© and returns a ©T©, for any type ©T©.
     3402forall( type T ) T fT( T );
     3403\end{lstlisting}
     3404\lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
     3405\lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$.
    27593406\begin{lstlisting}
    27603407int (*pfi )( int ) = fi;
    2761 forall( otype T ) T (*pfT )( T ) = fT;
    2762 \end{lstlisting}
    2763 ©pfi© and ©pfT© are pointers to functions. ©pfT© is not polymorphic, but the function it points at is.
     3408forall( type T ) T (*pfT )( T ) = fT;
     3409\end{lstlisting}
     3410\lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not
     3411polymorphic, but the function it points at is.
    27643412\begin{lstlisting}
    27653413int (*fvpfi( void ))( int ) {
    27663414        return pfi;
    27673415}
    2768 forall( otype T ) T (*fvpfT( void ))( T ) {
     3416forall( type T ) T (*fvpfT( void ))( T ) {
    27693417        return pfT;
    27703418}
    27713419\end{lstlisting}
    2772 ©fvpfi()© and ©fvpfT()© are functions taking no arguments and returning pointers to functions. ©fvpfT()© is monomorphic, but the function that its return value points at is polymorphic.
    2773 \begin{lstlisting}
    2774 forall( otype T ) int ( *fTpfi( T ) )( int );
    2775 forall( otype T ) T ( *fTpfT( T ) )( T );
    2776 forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    2777 \end{lstlisting}
    2778 ©fTpfi()© is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
    2779 It could return ©pfi©. ©fTpfT()© is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    2780 ©T©, where ©T© is an inferred parameter of ©fTpfT()©.
    2781 For instance, in the expression ``©fTpfT(17)©'', ©T© is inferred to be ©int©, and the returned value would have type ©int ( * )( int )©. ``©fTpfT(17)(13)©'' and ``©fTpfT("yes")("no")©'' are legal, but ``©fTpfT(17)("no")©'' is illegal.
    2782 ©fTpfU()© is polymorphic ( in type ©T©), and returns a pointer to a function that is polymorphic ( in type ©U©). ``©f5(17)("no")©'' is a legal expression of type ©char *©.
    2783 \begin{lstlisting}
    2784 forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    2785 forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    2786 \end{lstlisting}
    2787 The functions ©f()© and ©g()© have compatible types.
    2788 Let \(f\) and \(g\) be their types;
    2789 then \(f_1\) = ©T©, \(f_2\) = ©U©, \(f_3\) = ©V©, \(g_1\)
    2790 = ©V©, \(g_2\) = ©U©, and \(g_3\) = ©W©.
    2791 Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    2792 \begin{lstlisting}
    2793 forall( otype V, otype U, otype W ) U * f( V *, U, W * const );
    2794 \end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    2795 \begin{rationale}
    2796 The word ``©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.
     3420\lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers
     3421to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points
     3422at is polymorphic.
     3423\begin{lstlisting}
     3424forall( type T ) int ( *fTpfi( T ) )( int );
     3425forall( type T ) T ( *fTpfT( T ) )( T );
     3426forall( type T, type U ) U ( *fTpfU( T ) )( U );
     3427\end{lstlisting}
     3428\lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function
     3429taking an integer and returning an integer. It could return \lstinline$pfi$. \lstinline$fTpfT()$
     3430is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     3431\lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$. For instance,
     3432in the expression ``\lstinline$fTpfT(17)$'', \lstinline$T$ is inferred to be \lstinline$int$, and
     3433the returned value would have type \lstinline$int ( * )( int )$. ``\lstinline$fTpfT(17)(13)$'' and
     3434``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
     3435\lstinline$fTpfU()$ is polymorphic ( in type \lstinline$T$), and returns a pointer to a function that
     3436is polymorphic ( in type \lstinline$U$). ``\lstinline$f5(17)("no")$'' is a legal expression of type
     3437\lstinline$char *$.
     3438\begin{lstlisting}
     3439forall( type T, type U, type V ) U * f( T *, U, V * const );
     3440forall( type U, type V, type W ) U * g( V *, U, W * const );
     3441\end{lstlisting}
     3442The functions \lstinline$f()$ and \lstinline$g()$ have compatible types. Let \(f\) and \(g\) be
     3443their types; then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
     3444= \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$. Replacing every \(f_i\)
     3445by \(g_i\) in \(f\) gives
     3446\begin{lstlisting}
     3447forall( type V, type U, type W ) U * f( V *, U, W * const );
     3448\end{lstlisting}
     3449which has a return type and parameter list that is compatible with \(g\).
     3450\begin{rationale}
     3451The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave
     3452room for inferred parameters of ordinary types in case parameterized types get added one day.
    27973453
    27983454Even without parameterized types, I might try to allow
    27993455\begin{lstlisting}
    28003456forall( int n ) int sum( int vector[n] );
    2801 \end{lstlisting} but C currently rewrites array parameters as pointer parameters, so the effects of such a change require more thought.
    2802 \end{rationale}
    2803 
    2804 \begin{rationale}
    2805 A polymorphic declaration must do two things: it must introduce type parameters, and it must apply assertions to those types.
    2806 Adding this to existing C declaration syntax and semantics was delicate, and not entirely successful.
    2807 
    2808 C depends on declaration-before-use, so a forall specifier must introduce type names before they can be used in the declaration specifiers.
    2809 This could be done by making the forall specifier part of the declaration specifiers, or by making it a new introductory clause of declarations.
    2810 
    2811 Assertions are also part of polymorphic function types, because it must be clear which functions have access to the assertion parameters declared by the assertions.
    2812 All attempts to put assertions inside an introductory clause produced complex semantics and confusing code.
    2813 Building them into the declaration specifiers could be done by placing them in the function's parameter list, or in a forall specifier that is a declaration specifier.
    2814 Assertions are also used with type parameters of specifications, and by type declarations.
    2815 For consistency's sake it seems best to attach assertions to the type declarations in forall specifiers, which means that forall specifiers must be declaration specifiers.
     3457\end{lstlisting}
     3458but C currently rewrites array parameters as pointer parameters, so the effects of such a change
     3459require more thought.
     3460\end{rationale}
     3461
     3462\begin{rationale}
     3463A polymorphic declaration must do two things: it must introduce type parameters, and it must apply
     3464assertions to those types. Adding this to existing C declaration syntax and semantics was delicate,
     3465and not entirely successful.
     3466
     3467C depends on declaration-before-use, so a forall specifier must introduce type names before they can
     3468be used in the declaration specifiers. This could be done by making the forall specifier part of
     3469the declaration specifiers, or by making it a new introductory clause of declarations.
     3470
     3471Assertions are also part of polymorphic function types, because it must be clear which functions
     3472have access to the assertion parameters declared by the assertions. All attempts to put assertions
     3473inside an introductory clause produced complex semantics and confusing code. Building them into the
     3474declaration specifiers could be done by placing them in the function's parameter list, or in a
     3475forall specifier that is a declaration specifier. Assertions are also used with type parameters of
     3476specifications, and by type declarations. For consistency's sake it seems best to attach assertions
     3477to the type declarations in forall specifiers, which means that forall specifiers must be
     3478declaration specifiers.
    28163479\end{rationale}
    28173480%HERE
    … …  
    28203483\subsection{Type qualifiers}
    28213484
    2822 \CFA defines a new type qualifier ©lvalue©\impl{lvalue}\index{lvalue}.
     3485\CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}.
    28233486\begin{syntax}
    28243487\oldlhs{type-qualifier}
    2825 \rhs ©lvalue©
     3488\rhs \lstinline$lvalue$
    28263489\end{syntax}
    28273490
    28283491\constraints
    2829 \Indexc{restrict} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
     3492\lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and
     3493pointer types whose referenced type is an object type shall not be restrict-qualified.
    28303494
    28313495\semantics
    2832 An object's type may be a restrict-qualified type parameter.
    2833 ©restrict© does not establish any special semantics in that case.
    2834 
    2835 \begin{rationale}
    2836 \CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be passed to polymorphic functions.
    2837 \end{rationale}
    2838 
    2839 ©lvalue© may be used to qualify the return type of a function type.
    2840 Let ©T© be an unqualified version of a type;
    2841 then the result of calling a function with return type ©lvalue T© is a \Index{modifiable lvalue} of type ©T©.
    2842 ©const©\use{const} and ©volatile©\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
    2843 \begin{rationale}
    2844 The ©const© and ©volatile© qualifiers can only be sensibly used to qualify the return type of a function if the ©lvalue© qualifier is also used.
    2845 \end{rationale}
    2846 
    2847 An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue;
    2848 the result of the expression is an lvalue.
    2849 
    2850 \begin{rationale}
    2851 ©lvalue© provides some of the functionality of {\CC}'s ``©T&©'' ( reference to object of type ©T©) type.
    2852 Reference types have four uses in {\CC}.
     3496An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not
     3497establish any special semantics in that case.
     3498
     3499\begin{rationale}
     3500\CFA loosens the constraint on the restrict qualifier so that restrict-qualified pointers may be
     3501passed to polymorphic functions.
     3502\end{rationale}
     3503
     3504\lstinline$lvalue$ may be used to qualify the return type of a function type. Let \lstinline$T$ be
     3505an unqualified version of a type; then the result of calling a function with return type
     3506\lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
     3507\lstinline$const$\use{const} and \lstinline$volatile$\use{volatile} qualifiers may also be added to
     3508indicate that the function result is a constant or volatile lvalue.
     3509\begin{rationale}
     3510The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the
     3511return type of a function if the \lstinline$lvalue$ qualifier is also used.
     3512\end{rationale}
     3513
     3514An {lvalue}-qualified type may be used in a \Index{cast expression} if the operand is an lvalue; the
     3515result of the expression is an lvalue.
     3516
     3517\begin{rationale}
     3518\lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to
     3519object of type \lstinline$T$) type. Reference types have four uses in {\CC}.
    28533520\begin{itemize}
    28543521\item
    2855 They are necessary for user-defined operators that return lvalues, such as ``subscript'' and ``dereference''.
    2856 
    2857 \item
    2858 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 ©with© statement.
    2859 The following {\CC} code gives an example.
     3522They are necessary for user-defined operators that return lvalues, such as ``subscript'' and
     3523``dereference''.
     3524
     3525\item
     3526A reference can be used to define an alias for a complicated lvalue expression, as a way of getting
     3527some of the functionality of the Pascal \lstinline$with$ statement. The following {\CC} code gives
     3528an example.
    28603529\begin{lstlisting}
    28613530{
    … …  
    28673536
    28683537\item
    2869 A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    2870 This is most useful for user-defined assignment operators.
    2871 In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions
     3538A reference parameter can be used to allow a function to modify an argument without forcing the
     3539caller to pass the address of the argument. This is most useful for user-defined assignment
     3540operators. In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and
     3541the two expressions
    28723542\begin{lstlisting}
    28733543a = b;
    28743544operator=( a, b );
    2875 \end{lstlisting} are equivalent.
    2876 If ©a© and ©b© are of type ©T©, then the first parameter of ©operator=© must have type ``©T&©''.
    2877 It cannot have type ©T©, because then assignment couldn't alter the variable, and it can't have type ``©T *©'', because the assignment would have to be written ``©&a = b;©''.
    2878 
    2879 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 ``©a = b;©'' is equivalent to ``©operator=(&( a), b )©''.
    2880 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 ``©&©''.
     3545\end{lstlisting}
     3546are equivalent. If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first
     3547parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''. It cannot have type
     3548\lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
     3549``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
     3550
     3551In the case of user-defined operators, this could just as well be handled by using pointer types and
     3552by changing the rewrite rules so that ``\lstinline$a = b;$'' is equivalent to
     3553``\lstinline$operator=(&( a), b )$''. Reference parameters of ``normal'' functions are Bad Things,
     3554because they remove a useful property of C function calls: an argument can only be modified by a
     3555function if it is preceded by ``\lstinline$&$''.
    28813556
    28823557\item
    28833558References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    2884 {\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
    2885 ©Thing©, the type of ©fiddle© could be either of
     3559{\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of \lstinline$a_thing$ is
     3560\lstinline$Thing$, the type of \lstinline$fiddle$ could be either of
    28863561\begin{lstlisting}
    28873562void fiddle( Thing );
    28883563void fiddle( const Thing & );
    28893564\end{lstlisting}
    2890 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 ©fiddle© the parameter is subject to the usual problems caused by aliases.
    2891 The reference form might be chosen for efficiency's sake if ©Thing©s are too large or their constructors or destructors are too expensive.
    2892 An implementation may switch between them without causing trouble for well-behaved clients.
    2893 This leaves the implementor to define ``too large'' and ``too expensive''.
     3565If the second form is used, then constructors and destructors are not invoked to create a temporary
     3566variable at the call site ( and it is bad style for the caller to make any assumptions about such
     3567things), and within \lstinline$fiddle$ the parameter is subject to the usual problems caused by
     3568aliases. The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too
     3569large or their constructors or destructors are too expensive. An implementation may switch between
     3570them without causing trouble for well-behaved clients. This leaves the implementor to define ``too
     3571large'' and ``too expensive''.
    28943572
    28953573I propose to push this job onto the compiler by allowing it to implement
    28963574\begin{lstlisting}
    28973575void fiddle( const volatile Thing );
    2898 \end{lstlisting} with call-by-reference.
    2899 Since it knows all about the size of ©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''.
     3576\end{lstlisting}
     3577with call-by-reference. Since it knows all about the size of \lstinline$Thing$s and the parameter
     3578passing mechanism, it should be able to come up with a better definition of ``too large'', and may
     3579be able to make a good guess at ``too expensive''.
    29003580\end{itemize}
    29013581
    2902 In summary, since references are only really necessary for returning lvalues, I'll only provide lvalue functions.
     3582In summary, since references are only really necessary for returning lvalues, I'll only provide
     3583lvalue functions.
    29033584\end{rationale}
    29043585
    … …  
    29073588\subsection{Initialization}
    29083589
    2909 An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the object being initialized.
    2910 An expression used in an \nonterm{initializer-list} is treated as being cast to the type of the aggregate member that it initializes.
    2911 In either case the cast must have a single unambiguous \Index{interpretation}.
     3590An expression that is used as an \nonterm{initializer} is treated as being cast to the type of the
     3591object being initialized. An expression used in an \nonterm{initializer-list} is treated as being
     3592cast to the type of the aggregate member that it initializes. In either case the cast must have a
     3593single unambiguous \Index{interpretation}.
    29123594
    29133595
    … …  
    29173599\begin{syntax}
    29183600\lhs{spec-definition}
    2919 \rhs ©spec© \nonterm{identifier}
    2920         ©(© \nonterm{type-parameter-list} ©)©
    2921         ©{© \nonterm{spec-declaration-list}\opt ©}©
     3601\rhs \lstinline$spec$ \nonterm{identifier}
     3602        \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
     3603        \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$
    29223604\lhs{spec-declaration-list}
    2923 \rhs \nonterm{spec-declaration} ©;©
    2924 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} ©;©
     3605\rhs \nonterm{spec-declaration} \lstinline$;$
     3606\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$
    29253607\lhs{spec-declaration}
    29263608\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    29273609\lhs{declarator-list}
    29283610\rhs \nonterm{declarator}
    2929 \rhs \nonterm{declarator-list} ©,© \nonterm{declarator}
     3611\rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator}
    29303612\end{syntax}
    29313613\begin{rationale}
    2932 The declarations allowed in a specification are much the same as those allowed in a structure, except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
     3614The declarations allowed in a specification are much the same as those allowed in a structure,
     3615except that bit fields are not allowed, and \Index{incomplete type}s and function types are allowed.
    29333616\end{rationale}
    29343617
    29353618\semantics
    2936 A \define{specification definition} defines a name for a \define{specification}: a parameterized collection of object and function declarations.
     3619A \define{specification definition} defines a name for a \define{specification}: a parameterized
     3620collection of object and function declarations.
    29373621
    29383622The declarations in a specification consist of the declarations in the
    29393623\nonterm{spec-declaration-list} and declarations produced by any assertions in the
    2940 \nonterm{spec-parameter-list}.
    2941 If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the composite type constructed from the two types.
     3624\nonterm{spec-parameter-list}. If the collection contains two declarations that declare the same
     3625identifier and have compatible types, they are combined into one declaration with the composite type
     3626constructed from the two types.
    29423627
    29433628
    … …  
    29493634\rhs \nonterm{assertion-list} \nonterm{assertion}
    29503635\lhs{assertion}
    2951 \rhs ©|© \nonterm{identifier} ©(© \nonterm{type-name-list} ©)©
    2952 \rhs ©|© \nonterm{spec-declaration}
     3636\rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$
     3637\rhs \lstinline$|$ \nonterm{spec-declaration}
    29533638\lhs{type-name-list}
    29543639\rhs \nonterm{type-name}
    2955 \rhs \nonterm{type-name-list} ©,© \nonterm{type-name}
     3640\rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name}
    29563641\end{syntax}
    29573642
    29583643\constraints
    2959 The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name of a specification.
    2960 The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    2961 If the
    2962 \nonterm{type-parameter} uses type-class ©type©\use{type}, the argument shall be the type name of an \Index{object type};
    2963 if it uses ©dtype©, the argument shall be the type name of an object type or an \Index{incomplete type};
    2964 and if it uses ©ftype©, the argument shall be the type name of a \Index{function type}.
     3644The \nonterm{identifier} in an assertion that is not a \nonterm{spec-declaration} shall be the name
     3645of a specification. The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for
     3646each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}. If the
     3647\nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type
     3648name of an \Index{object type}; if it uses \lstinline$dtype$, the argument shall be the type name of
     3649an object type or an \Index{incomplete type}; and if it uses \lstinline$ftype$, the argument shall
     3650be the type name of a \Index{function type}.
    29653651
    29663652\semantics
    2967 An \define{assertion} is a declaration of a collection of objects and functions, called \define{assertion parameters}.
    2968 
    2969 The assertion parameters produced by an assertion that applies the name of a specification to type arguments are found by taking the declarations specified in the specification and treating each of the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
    2970 
    2971 The collection of assertion parameters produced by the \nonterm{assertion-list} are found by combining the declarations produced by each assertion.
    2972 If the collection contains two declarations that declare the same identifier and have compatible types, they are combined into one declaration with the \Index{composite type} constructed from the two types.
     3653An \define{assertion} is a declaration of a collection of objects and functions, called
     3654\define{assertion parameters}.
     3655
     3656The assertion parameters produced by an assertion that applies the name of a specification to type
     3657arguments are found by taking the declarations specified in the specification and treating each of
     3658the specification's parameters as a synonym for the corresponding \nonterm{type-name} argument.
     3659
     3660The collection of assertion parameters produced by the \nonterm{assertion-list} are found by
     3661combining the declarations produced by each assertion. If the collection contains two declarations
     3662that declare the same identifier and have compatible types, they are combined into one declaration
     3663with the \Index{composite type} constructed from the two types.
    29733664
    29743665\examples
    29753666\begin{lstlisting}
    2976 forall( otype T | T ?*?( T, T ))§\use{?*?}§
    2977 T square( T val ) {§\impl{square}§
     3667forall( type T | T ?*?( T, T ))@\use{?*?}@
     3668T square( T val ) {@\impl{square}@
    29783669        return val + val;
    29793670}
    2980 trait summable( otype T ) {§\impl{summable}§
    2981         T ?+=?( T *, T );§\use{?+=?}§
    2982         const T 0;§\use{0}§
     3671
     3672context summable( type T ) {@\impl{summable}@
     3673        T ?+=?( T *, T );@\use{?+=?}@
     3674        const T 0;@\use{0}@
    29833675};
    2984 trait list_of( otype List, otype Element ) {§\impl{list_of}§
     3676context list_of( type List, type Element ) {@\impl{list_of}@
    29853677        Element car( List );
    29863678        List cdr( List );
    … …  
    29893681        int is_nil( List );
    29903682};
    2991 trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    2992 \end{lstlisting}
    2993 ©sum_list© contains seven declarations, which describe a list whose elements can be added up.
    2994 The assertion ``©|sum_list( i_list, int )©''\use{sum_list} produces the assertion parameters
     3683context sum_list( type List, type Element | summable( Element ) | list_of( List, Element ) ) {};
     3684\end{lstlisting}
     3685\lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added
     3686up. The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion
     3687parameters
    29953688\begin{lstlisting}
    29963689int ?+=?( int *, int );
    … …  
    30093702\lhs{type-parameter-list}
    30103703\rhs \nonterm{type-parameter}
    3011 \rhs \nonterm{type-parameter-list} ©,© \nonterm{type-parameter}
     3704\rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter}
    30123705\lhs{type-parameter}
    30133706\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    30143707\lhs{type-class}
    3015 \rhs ©type©
    3016 \rhs ©dtype©
    3017 \rhs ©ftype©
     3708\rhs \lstinline$type$
     3709\rhs \lstinline$dtype$
     3710\rhs \lstinline$ftype$
    30183711\lhs{type-declaration}
    3019 \rhs \nonterm{storage-class-specifier}\opt ©type© \nonterm{type-declarator-list} \verb|;|
     3712\rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;|
    30203713\lhs{type-declarator-list}
    30213714\rhs \nonterm{type-declarator}
    3022 \rhs \nonterm{type-declarator-list} ©,© \nonterm{type-declarator}
     3715\rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator}
    30233716\lhs{type-declarator}
    3024 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt ©=© \nonterm{type-name}
     3717\rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name}
    30253718\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    30263719\end{syntax}
    30273720
    30283721\constraints
    3029 If a type declaration has block scope, and the declared identifier has external or internal linkage, the declaration shall have no initializer for the identifier.
     3722If a type declaration has block scope, and the declared identifier has external or internal linkage,
     3723the declaration shall have no initializer for the identifier.
    30303724
    30313725\semantics
    3032 A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type name} for a type incompatible with all other types.
    3033 
    3034 An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
    3035 Identifiers declared with type-class ©type©\use{type} are \Index{object type}s;
    3036 those declared with type-class ©dtype©\use{dtype} are \Index{incomplete type}s;
    3037 and those declared with type-class ©ftype©\use{ftype} are \Index{function type}s.
    3038 The 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}.
    3039 
    3040 A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}.  The declared identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after the end of the initializer.
    3041 The type in the initializer is called the \define{implementation
    3042   type}.
    3043 Within 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.
    3044 
    3045 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier ©static©\use{static} defines an \Index{incomplete type}.
    3046 If a \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).
     3726A \nonterm{type-parameter} or a \nonterm{type-declarator} declares an identifier to be a \Index{type
     3727name} for a type incompatible with all other types.
     3728
     3729An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}. Identifiers declared
     3730with type-class \lstinline$type$\use{type} are \Index{object type}s; those declared with type-class
     3731\lstinline$dtype$\use{dtype} are \Index{incomplete type}s; and those declared with type-class
     3732\lstinline$ftype$\use{ftype} are \Index{function type}s. The identifier has \Index{block scope} that
     3733terminates at the end of the \nonterm{spec-declaration-list} or polymorphic function that contains
     3734the \nonterm{type-parameter}.
     3735
     3736A \nonterm{type-declarator} with an \Index{initializer} is a \define{type definition}.  The declared
     3737identifier is an \Index{incomplete type} within the initializer, and an \Index{object type} after
     3738the end of the initializer. The type in the initializer is called the \define{implementation
     3739  type}. Within the scope of the declaration, \Index{implicit conversion}s can be performed between
     3740the defined type and the implementation type, and between pointers to the defined type and pointers
     3741to the implementation type.
     3742
     3743A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or
     3744with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}. If a
     3745\Index{translation unit} or \Index{block} contains one or more such declarations for an identifier,
     3746it must contain exactly one definition of the identifier ( but not in an enclosed block, which would
     3747define a new type known only within that block).
    30473748\begin{rationale}
    30483749Incomplete type declarations allow compact mutually-recursive types.
    30493750\begin{lstlisting}
    3050 otype t1; // incomplete type declaration
    3051 otype t2 = struct { t1 * p; ... };
    3052 otype t1 = struct { t2 * p; ... };
    3053 \end{lstlisting}
    3054 Without them, mutual recursion could be handled by declaring mutually recursive structures, then initializing the types to those structures.
     3751type t1; // Incomplete type declaration.
     3752type t2 = struct { t1 * p; ... };
     3753type t1 = struct { t2 * p; ... };
     3754\end{lstlisting}
     3755Without them, mutual recursion could be handled by declaring mutually recursive structures, then
     3756initializing the types to those structures.
    30553757\begin{lstlisting}
    30563758struct s1;
    3057 otype t2 = struct s2 { struct s1 * p; ... };
    3058 otype t1 = struct s1 { struct s2 * p; ... };
    3059 \end{lstlisting}
    3060 This introduces extra names, and may force the programmer to cast between the types and their implementations.
    3061 \end{rationale}
    3062 
    3063 A type declaration without an initializer and with \Index{storage-class specifier} ©extern©\use{extern} is an \define{opaque type declaration}.
    3064 Opaque types are \Index{object type}s.
    3065 An opaque type is not a \nonterm{constant-expression};
    3066 neither is a structure or union that has a member whose type is not a \nonterm{constant-expression}.
    3067 Every other \Index{object type} is a \nonterm{constant-expression}.
    3068 Objects with static storage duration shall be declared with a type that is a \nonterm{constant-expression}.
    3069 \begin{rationale}
    3070 Type declarations can declare identifiers with external linkage, whereas typedef declarations declare identifiers that only exist within a translation unit.
    3071 These opaque types can be used in declarations, but the implementation of the type is not visible.
    3072 
    3073 Static objects can not have opaque types because space for them would have to be allocated at program start-up.
    3074 This is a deficiency\index{deficiencies!static opaque objects}, but I don't want to deal with ``module initialization'' code just now.
    3075 \end{rationale}
    3076 
    3077 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} ©dtype©.
    3078 An object type\index{object types} which is not a qualified version of a type is a value of type-classes ©type© and ©dtype©.
    3079 A \Index{function type} is a value of type-class ©ftype©.
    3080 \begin{rationale}
    3081 Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
    3082 
    3083 Object types are precisely the types that can be instantiated.
    3084 Type qualifiers are not included in type values because the compiler needs the information they provide at compile time to detect illegal statements or to produce efficient machine instructions.
    3085 For instance, the code that a compiler must generate to manipulate an object that has volatile-qualified type may be different from the code to manipulate an ordinary object.
    3086 
    3087 Type qualifiers are a weak point of C's type system.
    3088 Consider the standard library function ©strchr()© which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
    3089 \begin{lstlisting}
    3090 char *strchr( const char *s, int c ) {§\impl{strchr}§
     3759type t2 = struct s2 { struct s1 * p; ... };
     3760type t1 = struct s1 { struct s2 * p; ... };
     3761\end{lstlisting}
     3762This introduces extra names, and may force the programmer to cast between the types and their
     3763implementations.
     3764\end{rationale}
     3765
     3766A type declaration without an initializer and with \Index{storage-class specifier}
     3767\lstinline$extern$\use{extern} is an \define{opaque type declaration}. Opaque types are
     3768\Index{object type}s. An opaque type is not a \nonterm{constant-expression}; neither is a structure
     3769or union that has a member whose type is not a \nonterm{constant-expression}.  Every other
     3770\Index{object type} is a \nonterm{constant-expression}. Objects with static storage duration shall
     3771be declared with a type that is a \nonterm{constant-expression}.
     3772\begin{rationale}
     3773Type declarations can declare identifiers with external linkage, whereas typedef declarations
     3774declare identifiers that only exist within a translation unit. These opaque types can be used in
     3775declarations, but the implementation of the type is not visible.
     3776
     3777Static objects can not have opaque types because space for them would have to be allocated at
     3778program start-up. This is a deficiency\index{deficiencies!static opaque objects}, but I don't want
     3779to deal with ``module initialization'' code just now.
     3780\end{rationale}
     3781
     3782An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a
     3783value of \Index{type-class} \lstinline$dtype$. An object type\index{object types} which is not a
     3784qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$. A
     3785\Index{function type} is a value of type-class \lstinline$ftype$.
     3786\begin{rationale}
     3787Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which
     3788omits the identifier being declared.
     3789
     3790Object types are precisely the types that can be instantiated. Type qualifiers are not included in
     3791type values because the compiler needs the information they provide at compile time to detect
     3792illegal statements or to produce efficient machine instructions. For instance, the code that a
     3793compiler must generate to manipulate an object that has volatile-qualified type may be different
     3794from the code to manipulate an ordinary object.
     3795
     3796Type qualifiers are a weak point of C's type system. Consider the standard library function
     3797\lstinline$strchr()$ which, given a string and a character, returns a pointer to the first
     3798occurrence of the character in the string.
     3799\begin{lstlisting}
     3800char *strchr( const char *s, int c ) {@\impl{strchr}@
    30913801        char real_c = c; // done because c was declared as int.
    30923802        for ( ; *s != real_c; s++ )
    3093                 if ( *s == '\0' ) return NULL;
     3803         if ( *s == '\0' ) return NULL;
    30943804        return ( char * )s;
    30953805}
    30963806\end{lstlisting}
    3097 The parameter ©s© must be ©const char *©, because ©strchr()© might be used to search a constant string, but the return type must be ©char *©, because the result might be used to modify a non-constant string.
    3098 Hence the body must perform a cast, and ( even worse) ©strchr()© provides a type-safe way to attempt to modify constant strings.
    3099 What is needed is some way to say that ©s©'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    3100 Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
    3101 Instead, overloading can be used to define ©strchr()© for each combination of qualifiers.
    3102 \end{rationale}
    3103 
    3104 \begin{rationale}
    3105 Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a type declaration, or as the type of a structure or union member.
    3106 This prevents the declaration of types that contain each other.
    3107 \begin{lstlisting}
    3108 otype t1;
    3109 otype t2 = t1; // illegal: incomplete type t1
    3110 otype t1 = t2;
    3111 \end{lstlisting}
    3112 
    3113 The initializer in a file-scope declaration must be a constant expression.
    3114 This means type declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
     3807The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be
     3808used to search a constant string, but the return type must be \lstinline$char *$, because the result
     3809might be used to modify a non-constant string. Hence the body must perform a cast, and ( even worse)
     3810\lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings. What is needed
     3811is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has
     3812exactly the same qualifiers. Polymorphic functions do not provide a fix for this
     3813deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of
     3814type values. Instead, overloading can be used to define \lstinline$strchr()$ for each combination
     3815of qualifiers.
     3816\end{rationale}
     3817
     3818\begin{rationale}
     3819Since \Index{incomplete type}s are not type values, they can not be used as the initializer in a
     3820type declaration, or as the type of a structure or union member. This prevents the declaration of
     3821types that contain each other.
     3822\begin{lstlisting}
     3823type t1;
     3824type t2 = t1; // illegal: incomplete type t1.
     3825type t1 = t2;
     3826\end{lstlisting}
     3827
     3828The initializer in a file-scope declaration must be a constant expression. This means type
     3829declarations can not build on opaque types, which is a deficiency\index{deficiencies!nesting opaque
    31153830 types}.
    31163831\begin{lstlisting}
    3117 extern otype Huge; // extended-precision integer type
    3118 otype Rational = struct {
     3832extern type Huge; // extended-precision integer type.
     3833type Rational = struct {
    31193834        Huge numerator, denominator;    // illegal
    31203835};
    … …  
    31233838};
    31243839\end{lstlisting}
    3125 Without this restriction, \CFA might require ``module initialization'' code ( since ©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 ©Huge© and the translation that declares ©Rational©.
    3126 
    3127 A 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.
     3840Without this restriction, \CFA might require ``module initialization'' code ( since
     3841\lstinline$Rational$ has external linkage, it must be created before any other translation unit
     3842instantiates it), and would force an ordering on the initialization of the translation unit that
     3843defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
     3844
     3845A benefit of the restriction is that it prevents the declaration in separate translation units of
     3846types that contain each other, which would be hard to prevent otherwise.
    31283847\begin{lstlisting}
    31293848//  File a.c:
    31303849        extern type t1;
    3131         type t2 = struct { t1 f1; ... } // illegal
     3850        type t2 = struct { t1 f1; ... } // illegal
    31323851//  File b.c:
    31333852        extern type t2;
    3134         type t1 = struct { t2 f2; ... } // illegal
     3853        type t1 = struct { t2 f2; ... } // illegal
    31353854\end{lstlisting}
    31363855\end{rationale}
    … …  
    31383857\begin{rationale}
    31393858Since a \nonterm{type-declaration} is a \nonterm{declaration} and not a
    3140 \nonterm{struct-declaration}, type declarations can not be structure members.
    3141 The form of
    3142 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning ©type©.
    3143 Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    3144 It also side-steps the problem of type-valued expressions producing different values in different declarations.
    3145 
    3146 Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit type parameters.
    3147 This may be too restrictive, but it attempts to make compilation simpler.
    3148 Recall that when traditional C scanners read in an identifier, they look it up in the symbol table to determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token depending on what they find.
    3149 A type parameter would add a type name to the current scope.
    3150 The scope manipulations involved in parsing the declaration of a function that takes function pointer parameters and returns a function pointer may just be too complicated.
    3151 
    3152 Explicit type parameters don't seem to be very useful, anyway, because their scope would not include the return type of the function.
    3153 Consider the following attempt to define a type-safe memory allocation function.
     3859\nonterm{struct-declaration}, type declarations can not be structure members. The form of
     3860\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
     3861Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued
     3862expressions. It also side-steps the problem of type-valued expressions producing different values
     3863in different declarations.
     3864
     3865Since a type declaration is not a \nonterm{parameter-declaration}, functions can not have explicit
     3866type parameters. This may be too restrictive, but it attempts to make compilation simpler. Recall
     3867that when traditional C scanners read in an identifier, they look it up in the symbol table to
     3868determine whether or not it is a typedef name, and return a ``type'' or ``identifier'' token
     3869depending on what they find. A type parameter would add a type name to the current scope. The
     3870scope manipulations involved in parsing the declaration of a function that takes function pointer
     3871parameters and returns a function pointer may just be too complicated.
     3872
     3873Explicit type parameters don't seem to be very useful, anyway, because their scope would not include
     3874the return type of the function. Consider the following attempt to define a type-safe memory
     3875allocation function.
    31543876\begin{lstlisting}
    31553877#include <stdlib.h>
    3156 T * new( otype T ) { return ( T * )malloc( sizeof( T) ); };
    3157 ... int * ip = new( int );
    3158 \end{lstlisting}
    3159 This looks sensible, but \CFA's declaration-before-use rules mean that ``©T©'' in the function body refers to the parameter, but the ``©T©'' in the return type refers to the meaning of ©T© in the scope that contains ©new©;
    3160 it could be undefined, or a type name, or a function or variable name.
    3161 Nothing good can result from such a situation.
     3878T * new( type T ) { return ( T * )malloc( sizeof( T) ); };
     3879@\ldots@
     3880int * ip = new( int );
     3881\end{lstlisting}
     3882This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the
     3883function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the
     3884meaning of \lstinline$T$ in the scope that contains \lstinline$new$; it could be undefined, or a
     3885type name, or a function or variable name. Nothing good can result from such a situation.
    31623886\end{rationale}
    31633887
    … …  
    31653889Since type declarations create new types, instances of types are always passed by value.
    31663890\begin{lstlisting}
    3167 otype A1 = int[2];
     3891type A1 = int[2];
    31683892void f1( A1 a ) { a[0] = 0; };
    3169 otypedef int A2[2];
     3893typedef int A2[2];
    31703894void f2( A2 a ) { a[0] = 0; };
    31713895A1 v1;
    … …  
    31743898f2( v2 );
    31753899\end{lstlisting}
    3176 ©V1© is passed by value, so ©f1()©'s assignment to ©a[0]© does not modify v1.  ©V2© is converted to a pointer, so ©f2()© modifies ©v2[0]©.
     3900\lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not
     3901modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies
     3902\lstinline$v2[0]$.
    31773903
    31783904A translation unit containing the declarations
    31793905\begin{lstlisting}
    3180 extern type Complex;§\use{Complex}§ // opaque type declaration
    3181 extern float abs( Complex );§\use{abs}§
    3182 \end{lstlisting} can contain declarations of complex numbers, which can be passed to ©abs©.
    3183 Some other translation unit must implement ©Complex© and ©abs©.
    3184 That unit might contain the declarations
    3185 \begin{lstlisting}
    3186 otype Complex = struct { float re, im; };§\impl{Complex}§
    3187 Complex cplx_i = { 0.0, 1.0 };§\impl{cplx_i}§
    3188 float abs( Complex c ) {§\impl{abs( Complex )}§
     3906extern type Complex;@\use{Complex}@ // opaque type declaration.
     3907extern float abs( Complex );@\use{abs}@
     3908\end{lstlisting}
     3909can contain declarations of complex numbers, which can be passed to \lstinline$abs$. Some other
     3910translation unit must implement \lstinline$Complex$ and \lstinline$abs$. That unit might contain
     3911the declarations
     3912\begin{lstlisting}
     3913type Complex = struct { float re, im; };@\impl{Complex}@
     3914Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
     3915float abs( Complex c ) {@\impl{abs( Complex )}@
    31893916        return sqrt( c.re * c.re + c.im * c.im );
    31903917}
    31913918\end{lstlisting}
    3192 Note that ©c© is implicitly converted to a ©struct© so that its components can be retrieved.
    3193 
    3194 \begin{lstlisting}
    3195 otype Time_of_day = int;§\impl{Time_of_day}§ // seconds since midnight.
    3196 Time_of_day ?+?( Time_of_day t1, int seconds ) {§\impl{?+?}§
     3919Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can
     3920be retrieved.
     3921
     3922\begin{lstlisting}
     3923type Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
     3924Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
    31973925        return (( int)t1 + seconds ) % 86400;
    31983926}
    31993927\end{lstlisting}
    3200 ©t1© must be cast to its implementation type to prevent infinite recursion.
    3201 
    3202 \begin{rationale}
    3203 Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
    3204 In the ©Time_of_day© example, the difference is important.
    3205 Different languages have treated the distinction between the abstraction and the implementation in different ways.
     3928\lstinline$t1$ must be cast to its implementation type to prevent infinite recursion.
     3929
     3930\begin{rationale}
     3931Within the scope of a type definition, an instance of the type can be viewed as having that type or
     3932as having the implementation type. In the \lstinline$Time_of_day$ example, the difference is
     3933important. Different languages have treated the distinction between the abstraction and the
     3934implementation in different ways.
    32063935\begin{itemize}
    32073936\item
    3208 Inside a Clu cluster \cite{CLU}, the declaration of an instance states which view applies.
    3209 Two primitives called ©up© and ©down© can be used to convert between the views.
    3210 \item
    3211 The Simula class \cite{SIMULA87} is essentially a record type.
    3212 Since 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.
    3213 In {\CC}
    3214 \cite{C++}, operations on class instances include assignment and ``©&©'', which can be overloaded.
    3215 A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    3216 \item
    3217 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.
    3218 The derived subprograms are clones of the existing subprograms with the old type replaced by the derived type.
    3219 Literals and aggregates of the old type are also cloned.
     3937Inside a Clu cluster \cite{clu}, the declaration of an instance states which view applies. Two
     3938primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
     3939\item
     3940The Simula class \cite{Simula87} is essentially a record type. Since the only operations on a
     3941record are member selection and assignment, which can not be overloaded, there is never any
     3942ambiguity as to whether the abstraction or the implementation view is being used. In {\CC}
     3943\cite{c++}, operations on class instances include assignment and ``\lstinline$&$'', which can be
     3944overloaded. A ``scope resolution'' operator can be used inside the class to specify whether the
     3945abstract or implementation version of the operation should be used.
     3946\item
     3947An Ada derived type definition \cite{ada} creates a new type from an old type, and also implicitly
     3948declares derived subprograms that correspond to the existing subprograms that use the old type as a
     3949parameter type or result type. The derived subprograms are clones of the existing subprograms with
     3950the old type replaced by the derived type. Literals and aggregates of the old type are also cloned.
    32203951In other words, the abstract view provides exactly the same operations as the implementation view.
    32213952This allows the abstract view to be used in all cases.
    32223953
    3223 The derived subprograms can be replaced by programmer-specified subprograms.
    3224 This is an exception to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope.
    3225 In this case, explicit conversions between the derived type and the old type can be used.
     3954The derived subprograms can be replaced by programmer-specified subprograms. This is an exception
     3955to the normal scope rules, which forbid duplicate definitions of a subprogram in a scope. In this
     3956case, explicit conversions between the derived type and the old type can be used.
    32263957\end{itemize}
    3227 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of ©up© and ©down©.
     3958\CFA's rules are like Clu's, except that implicit conversions and
     3959conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
    32283960\end{rationale}
    32293961
    … …  
    32313963\subsubsection{Default functions and objects}
    32323964
    3233 A declaration\index{type declaration} of a type identifier ©T© with type-class ©type© implicitly declares a \define{default assignment} function ©T ?=?( T *, T )©\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    3234 \begin{rationale}
    3235 Assignment 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).
    3236 Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
    3237 If a type parameter should not have an assignment operation, ©dtype© should be used.
    3238 If 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.
    3239 \end{rationale}
    3240 
    3241 A definition\index{type definition} of a type identifier ©T© with \Index{implementation type} ©I© and type-class ©type© implicitly defines a default assignment function.
    3242 A definition\index{type definition} of a type identifier ©T© with implementation type ©I© and an assertion list implicitly defines \define{default function}s and \define{default object}s as declared by the assertion declarations.
    3243 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    3244 Their values are determined as follows:
     3965A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
     3966\lstinline$type$ implicitly declares a \define{default assignment} function
     3967\lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the
     3968identifier \lstinline$T$.
     3969\begin{rationale}
     3970Assignment is central to C's imperative programming style, and every existing C object type has
     3971assignment defined for it ( except for array types, which are treated as pointer types for purposes
     3972of assignment). Without this rule, nearly every inferred type parameter would need an accompanying
     3973assignment assertion parameter. If a type parameter should not have an assignment operation,
     3974\lstinline$dtype$ should be used. If a type should not have assignment defined, the user can define
     3975an assignment function that causes a run-time error, or provide an external declaration but no
     3976definition and thus cause a link-time error.
     3977\end{rationale}
     3978
     3979A definition\index{type definition} of a type identifier \lstinline$T$ with \Index{implementation
     3980type} \lstinline$I$ and type-class \lstinline$type$ implicitly defines a default assignment
     3981function. A definition\index{type definition} of a type identifier \lstinline$T$ with implementation
     3982type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
     3983\define{default object}s as declared by the assertion declarations. The default objects and
     3984functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$. Their
     3985values are determined as follows:
    32453986\begin{itemize}
    32463987\item
    3247 If at the definition of ©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 ©I© replaced by ©T© is compatible with the type of the default object, then the default object is initialized with that object.
    3248 Otherwise the scope of the declaration of ©T© must contain a definition of the default object.
     3988If at the definition of \lstinline$T$ there is visible a declaration of an object with the same name
     3989as the default object, and if the type of that object with all occurrence of \lstinline$I$ replaced
     3990by \lstinline$T$ is compatible with the type of the default object, then the default object is
     3991initialized with that object. Otherwise the scope of the declaration of \lstinline$T$ must contain
     3992a definition of the default object.
    32493993
    32503994\item
    3251 If at the definition of ©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 ©I© replaced by ©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.
    3252 
    3253 Otherwise, if ©I© contains exactly one anonymous member\index{anonymous member} such that at the definition of ©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 ©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.
    3254 
    3255 Otherwise the scope of the declaration of ©T© must contain a definition of the default function.
     3995If at the definition of \lstinline$T$ there is visible a declaration of a function with the same
     3996name as the default function, and if the type of that function with all occurrence of \lstinline$I$
     3997replaced by \lstinline$T$ is compatible with the type of the default function, then the default
     3998function calls that function after converting its arguments and returns the converted result.
     3999
     4000Otherwise, if \lstinline$I$ contains exactly one anonymous member\index{anonymous member} such that
     4001at the definition of \lstinline$T$ there is visible a declaration of a function with the same name
     4002as the default function, and the type of that function with all occurrences of the anonymous
     4003member's type in its parameter list replaced by \lstinline$T$ is compatible with the type of the
     4004default function, then the default function calls that function after converting its arguments and
     4005returns the result.
     4006
     4007Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default
     4008function.
    32564009\end{itemize}
    32574010\begin{rationale}
    3258 Note that a pointer to a default function will not compare as equal to a pointer to the inherited function.
    3259 \end{rationale}
    3260 
    3261 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 ©T© replaces the default function or object.
     4011Note that a pointer to a default function will not compare as equal to a pointer to the inherited
     4012function.
     4013\end{rationale}
     4014
     4015A function or object with the same type and name as a default function or object that is declared
     4016within the scope of the definition of \lstinline$T$ replaces the default function or object.
    32624017
    32634018\examples
    32644019\begin{lstlisting}
    3265 trait s( otype T ) {
     4020context s( type T ) {
    32664021        T a, b;
    3267 } struct impl { int left, right; } a = { 0, 0 };
    3268 otype Pair | s( Pair ) = struct impl;
     4022}
     4023struct impl { int left, right; } a = { 0, 0 };
     4024type Pair | s( Pair ) = struct impl;
    32694025Pair b = { 1, 1 };
    32704026\end{lstlisting}
    3271 The definition of ©Pair© implicitly defines two objects ©a© and ©b©.
    3272 ©Pair a© inherits its value from the ©struct impl a©.
    3273 The definition of ©Pair b© is compulsory because there is no ©struct impl b© to construct a value from.
    3274 \begin{lstlisting}
    3275 trait ss( otype T ) {
     4027The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
     4028\lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$. The definition of
     4029\lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value
     4030from.
     4031\begin{lstlisting}
     4032context ss( type T ) {
    32764033        T clone( T );
    32774034        void munge( T * );
    32784035}
    3279 otype Whatsit | ss( Whatsit );§\use{Whatsit}§
    3280 otype Doodad | ss( Doodad ) = struct doodad {§\use{Doodad}§
     4036type Whatsit | ss( Whatsit );@\use{Whatsit}@
     4037type Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
    32814038        Whatsit; // anonymous member
    32824039        int extra;
    … …  
    32844041Doodad clone( Doodad ) { ... }
    32854042\end{lstlisting}
    3286 The definition of ©Doodad© implicitly defines three functions:
     4043The definition of \lstinline$Doodad$ implicitly defines three functions:
    32874044\begin{lstlisting}
    32884045Doodad ?=?( Doodad *, Doodad );
    … …  
    32904047void munge( Doodad * );
    32914048\end{lstlisting}
    3292 The assignment function inherits ©struct doodad©'s assignment function because the types match when ©struct doodad©  is replaced by ©Doodad© throughout.
    3293 ©munge()© inherits ©Whatsit©'s ©munge()© because the types match when ©Whatsit© is replaced by ©Doodad© in the parameter list. ©clone()© does \emph{not} inherit ©Whatsit©'s ©clone()©: replacement in the parameter list yields ``©Whatsit clone( Doodad )©'', which is not compatible with ©Doodad©'s ©clone()©'s type.
    3294 Hence the definition of ``©Doodad clone( Doodad )©'' is necessary.
     4049The assignment function inherits \lstinline$struct doodad$'s assignment function because the types
     4050match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
     4051\lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
     4052\lstinline$Whatsit$ is replaced by \lstinline$Doodad$ in the parameter list. \lstinline$clone()$
     4053does \emph{not} inherit \lstinline$Whatsit$'s \lstinline$clone()$: replacement in the parameter
     4054list yields ``\lstinline$Whatsit clone( Doodad )$'', which is not compatible with
     4055\lstinline$Doodad$'s \lstinline$clone()$'s type. Hence the definition of
     4056``\lstinline$Doodad clone( Doodad )$'' is necessary.
    32954057
    32964058Default functions and objects are subject to the normal scope rules.
    32974059\begin{lstlisting}
    3298 otype T = ...;
    3299 T a_T = ...;            // Default assignment used.
     4060type T = @\ldots@;
     4061T a_T = @\ldots@;               // Default assignment used.
    33004062T ?=?( T *, T );
    3301 T a_T = ...;            // Programmer-defined assignment called.
     4063T a_T = @\ldots@;               // Programmer-defined assignment called.
    33024064\end{lstlisting}
    33034065\begin{rationale}
    … …  
    33064068
    33074069\begin{rationale}
    3308 The \emph{class} construct of object-oriented programming languages performs three independent functions.
    3309 It \emph{encapsulates} a data structure;
    3310 it defines a \emph{subtype} relationship, whereby instances of one class may be used in contexts that require instances of another;
    3311 and it allows one class to \emph{inherit} the implementation of another.
    3312 
    3313 In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided by specifications and assertions.
    3314 Inheritance is provided by default functions and objects.
     4070The \emph{class} construct of object-oriented programming languages performs three independent
     4071functions. It \emph{encapsulates} a data structure; it defines a \emph{subtype} relationship, whereby
     4072instances of one class may be used in contexts that require instances of another; and it allows one
     4073class to \emph{inherit} the implementation of another.
     4074
     4075In \CFA, encapsulation is provided by opaque types and the scope rules, and subtyping is provided
     4076by specifications and assertions. Inheritance is provided by default functions and objects.
    33154077\end{rationale}
    33164078
    … …  
    33234085\end{syntax}
    33244086
    3325 Many statements contain expressions, which may have more than one interpretation.
    3326 The following sections describe how the \CFA translator selects an interpretation.
    3327 In all cases the result of the selection shall be a single unambiguous \Index{interpretation}.
     4087Many statements contain expressions, which may have more than one interpretation. The following
     4088sections describe how the \CFA translator selects an interpretation. In all cases the result of the
     4089selection shall be a single unambiguous \Index{interpretation}.
    33284090
    33294091
    … …  
    33324094\begin{syntax}
    33334095\oldlhs{labeled-statement}
    3334 \rhs ©case© \nonterm{case-value-list} : \nonterm{statement}
     4096\rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement}
    33354097\lhs{case-value-list}
    33364098\rhs \nonterm{case-value}
    3337 \rhs \nonterm{case-value-list} ©,© \nonterm{case-value}
     4099\rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value}
    33384100\lhs{case-value}
    33394101\rhs \nonterm{constant-expression}
    33404102\rhs \nonterm{subrange}
    33414103\lhs{subrange}
    3342 \rhs \nonterm{constant-expression} ©~© \nonterm{constant-expression}
     4104\rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression}
    33434105\end{syntax}
    33444106
    … …  
    33534115case 1~4, 9~14, 27~32:
    33544116\end{lstlisting}
    3355 The ©case© and ©default© clauses are restricted within the ©switch© and ©choose© statements, precluding Duff's device.
     4117The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device.
    33564118
    33574119
    33584120\subsection{Expression and null statements}
    33594121
    3360 The expression in an expression statement is treated as being cast to ©void©.
     4122The expression in an expression statement is treated as being cast to \lstinline$void$.
    33614123
    33624124
    … …  
    33654127\begin{syntax}
    33664128\oldlhs{selection-statement}
    3367 \rhs ©choose© ©(© \nonterm{expression} ©)© \nonterm{statement}
     4129\rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement}
    33684130\end{syntax}
    33694131
    3370 The controlling expression ©E© in the ©switch© and ©choose© statement:
     4132The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement:
    33714133\begin{lstlisting}
    33724134switch ( E ) ...
    33734135choose ( E ) ...
    3374 \end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
     4136\end{lstlisting}
     4137may have more than one interpretation, but it shall have only one interpretation with an integral type.
    33754138An \Index{integer promotion} is performed on the expression if necessary.
    3376 The constant expressions in ©case© statements with the switch are converted to the promoted type.
     4139The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
    33774140
    33784141
    33794142\setcounter{subsubsection}{3}
    3380 \subsubsection[The choose statement]{The \lstinline@choose@ statement}
    3381 
    3382 The ©choose© statement is the same as the ©switch© statement except control transfers to the end of the ©choose© statement at a ©case© or ©default© labeled statement.
    3383 The ©fallthru© statement is used to fall through to the next ©case© or ©default© labeled statement.
     4143\subsubsection{The \lstinline$choose$ statement}
     4144
     4145The \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.
     4146The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement.
    33844147The following have identical meaning:
    33854148\begin{flushleft}
    … …  
    34064169\end{tabular}
    34074170\end{flushleft}
    3408 The ©choose© statement addresses the problem of accidental fall-through associated with the ©switch© statement.
     4171The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement.
    34094172
    34104173
    34114174\subsection{Iteration statements}
    34124175
    3413 The controlling expression ©E© in the loops
     4176The controlling expression \lstinline$E$ in the loops
    34144177\begin{lstlisting}
    34154178if ( E ) ...
    … …  
    34174180do ... while ( E );
    34184181\end{lstlisting}
    3419 is treated as ``©( int )((E)!=0)©''.
     4182is treated as ``\lstinline$( int )((E)!=0)$''.
    34204183
    34214184The statement
    34224185\begin{lstlisting}
    3423 for ( a; b; c ) ...
    3424 \end{lstlisting} is treated as
     4186for ( a; b; c ) @\ldots@
     4187\end{lstlisting}
     4188is treated as
    34254189\begin{lstlisting}
    34264190for ( ( void )( a ); ( int )(( b )!=0); ( void )( c ) ) ...
    … …  
    34324196\begin{syntax}
    34334197\oldlhs{jump-statement}
    3434 \rhs ©continue© \nonterm{identifier}\opt
    3435 \rhs ©break© \nonterm{identifier}\opt
     4198\rhs \lstinline$continue$ \nonterm{identifier}\opt
     4199\rhs \lstinline$break$ \nonterm{identifier}\opt
    34364200\rhs \ldots
    3437 \rhs ©throw© \nonterm{assignment-expression}\opt
    3438 \rhs ©throwResume© \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    3439 \lhs{at-expression} ©_At© \nonterm{assignment-expression}
     4201\rhs \lstinline$throw$ \nonterm{assignment-expression}\opt
     4202\rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     4203\lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression}
    34404204\end{syntax}
    34414205
    3442 Labeled ©continue© and ©break© allow useful but restricted control-flow that reduces the need for the ©goto© statement for exiting multiple nested control-structures.
     4206Labeled \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.
    34434207\begin{lstlisting}
    34444208L1: {                                                   // compound
    … …  
    34674231
    34684232\setcounter{subsubsection}{1}
    3469 \subsubsection[The continue statement]{The \lstinline@continue@ statement}
    3470 
    3471 The identifier in a ©continue© statement shall name a label located on an enclosing iteration statement.
    3472 
    3473 
    3474 \subsubsection[The break statement]{The \lstinline@break@ statement}
    3475 
    3476 The identifier in a ©break© statement shall name a label located on an enclosing compound, selection or iteration statement.
    3477 
    3478 
    3479 \subsubsection[The return statement]{The \lstinline@return@ statement}
    3480 
    3481 An expression in a ©return© statement is treated as being cast to the result type of the function.
    3482 
    3483 
    3484 \subsubsection[The throw statement]{The \lstinline@throw@ statement}
     4233\subsubsection{The \lstinline$continue$ statement}
     4234
     4235The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement.
     4236
     4237
     4238\subsubsection{The \lstinline$break$ statement}
     4239
     4240The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement.
     4241
     4242
     4243\subsubsection{The \lstinline$return$ statement}
     4244
     4245An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function.
     4246
     4247
     4248\subsubsection{The \lstinline$throw$ statement}
    34854249
    34864250When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution.
    34874251
    34884252
    3489 \subsubsection[The throwResume statement]{The \lstinline@throwResume@ statement}
     4253\subsubsection{The \lstinline$throwResume$ statement}
    34904254
    34914255
    … …  
    34944258\begin{syntax}
    34954259\lhs{exception-statement}
    3496 \rhs ©try© \nonterm{compound-statement} \nonterm{handler-list}
    3497 \rhs ©try© \nonterm{compound-statement} \nonterm{finally-clause}
    3498 \rhs ©try© \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
     4260\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list}
     4261\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause}
     4262\rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    34994263\lhs{handler-list}
    35004264\rhs \nonterm{handler-clause}
    3501 \rhs ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
    3502 \rhs \nonterm{handler-clause} ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
    3503 \rhs ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
    3504 \rhs \nonterm{handler-clause} ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
     4265\rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
     4266\rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
     4267\rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
     4268\rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    35054269\lhs{handler-clause}
    3506 \rhs ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    3507 \rhs \nonterm{handler-clause} ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    3508 \rhs ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    3509 \rhs \nonterm{handler-clause} ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     4270\rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
     4271\rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
     4272\rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
     4273\rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    35104274\lhs{finally-clause}
    3511 \rhs ©finally© \nonterm{compound-statement}
     4275\rhs \lstinline$finally$ \nonterm{compound-statement}
    35124276\lhs{exception-declaration}
    35134277\rhs \nonterm{type-specifier}
    … …  
    35174281\rhs \nonterm{new-abstract-declarator-tuple}
    35184282\lhs{asynchronous-statement}
    3519 \rhs ©enable© \nonterm{identifier-list} \nonterm{compound-statement}
    3520 \rhs ©disable© \nonterm{identifier-list} \nonterm{compound-statement}
     4283\rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement}
     4284\rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement}
    35214285\end{syntax}
    35224286
    … …  
    35244288
    35254289
    3526 \subsubsection[The try statement]{The \lstinline@try@ statement}
    3527 
    3528 The ©try© statement is a block with associated handlers, called a \Index{guarded block};
     4290\subsubsection{The \lstinline$try$ statement}
     4291
     4292The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block};
    35294293all other blocks are \Index{unguarded block}s.
    3530 A ©goto©, ©break©, ©return©, or ©continue© statement can be used to transfer control out of a try block or handler, but not into one.
    3531 
    3532 
    3533 \subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
    3534 
    3535 The ©enable©/©disable© statements toggle delivery of \Index{asynchronous exception}s.
     4294A \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.
     4295
     4296
     4297\subsubsection{The \lstinline$enable$/\lstinline$disable$ statements}
     4298
     4299The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s.
    35364300
    35374301
    … …  
    35434307\subsection{Predefined macro names}
    35444308
    3545 The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard.
    3546 It shall not define the macro name ©__STDC__©.
    3547 
    3548 In addition, the implementation shall define the macro name ©__CFORALL__© to be the decimal constant 1.
     4309The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
     4310\lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard. It shall not define the
     4311macro name \lstinline$__STDC__$.
     4312
     4313In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the
     4314decimal constant 1.
    35494315
    35504316
    … …  
    35564322
    35574323\section{C types}
    3558 This section gives example specifications for some groups of types that are important in the C language, in terms of the predefined operations that can be applied to those types.
     4324This section gives example specifications for some groups of types that are important in the C
     4325language, in terms of the predefined operations that can be applied to those types.
    35594326
    35604327
    35614328\subsection{Scalar, arithmetic, and integral types}
    35624329
    3563 The pointer, integral, and floating-point types are all \define{scalar types}.
    3564 All of these types can be logically negated and compared.
    3565 The assertion ``©scalar( Complex )©'' should be read as ``type ©Complex© is scalar''.
    3566 \begin{lstlisting}
    3567 trait scalar( otype T ) {§\impl{scalar}§
     4330The pointer, integral, and floating-point types are all \define{scalar types}. All of these types
     4331can be logically negated and compared. The assertion ``\lstinline$scalar( Complex )$'' should be read
     4332as ``type \lstinline$Complex$ is scalar''.
     4333\begin{lstlisting}
     4334context scalar( type T ) {@\impl{scalar}@
    35684335        int !?( T );
    35694336        int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
    … …  
    35714338\end{lstlisting}
    35724339
    3573 The integral and floating-point types are \define{arithmetic types}, which support the basic arithmetic operators.
    3574 The use of an assertion in the \nonterm{spec-parameter-list} declares that, in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are available ).
    3575 This is equivalent to inheritance of specifications.
    3576 \begin{lstlisting}
    3577 trait arithmetic( otype T | scalar( T ) ) {§\impl{arithmetic}§§\use{scalar}§
     4340The integral and floating-point types are \define{arithmetic types}, which support the basic
     4341arithmetic operators. The use of an assertion in the \nonterm{spec-parameter-list} declares that,
     4342in order to be arithmetic, a type must also be scalar ( and hence that scalar operations are
     4343available ). This is equivalent to inheritance of specifications.
     4344\begin{lstlisting}
     4345context arithmetic( type T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
    35784346        T +?( T ), -?( T );
    35794347        T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
    … …  
    35814349\end{lstlisting}
    35824350
    3583 The various flavors of ©char© and ©int© and the enumerated types make up the \define{integral types}.
    3584 \begin{lstlisting}
    3585 trait integral( otype T | arithmetic( T ) ) {§\impl{integral}§§\use{arithmetic}§
     4351The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the
     4352\define{integral types}.
     4353\begin{lstlisting}
     4354context integral( type T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
    35864355        T ~?( T );
    35874356        T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
    … …  
    35974366The only operation that can be applied to all modifiable lvalues is simple assignment.
    35984367\begin{lstlisting}
    3599 trait m_lvalue( otype T ) {§\impl{m_lvalue}§
     4368context m_lvalue( type T ) {@\impl{m_lvalue}@
    36004369        T ?=?( T *, T );
    36014370};
    … …  
    36034372
    36044373Modifiable scalar lvalues are scalars and are modifiable lvalues, and assertions in the
    3605 \nonterm{spec-parameter-list} reflect those relationships.
    3606 This is equivalent to multiple inheritance of specifications.
    3607 Scalars can also be incremented and decremented.
    3608 \begin{lstlisting}
    3609 trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {§\impl{m_l_scalar}§
    3610         T ?++( T * ), ?--( T * );§\use{scalar}§§\use{m_lvalue}§
     4374\nonterm{spec-parameter-list} reflect those relationships. This is equivalent to multiple
     4375inheritance of specifications. Scalars can also be incremented and decremented.
     4376\begin{lstlisting}
     4377context m_l_scalar( type T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
     4378        T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
    36114379        T ++?( T * ), --?( T * );
    36124380};
    36134381\end{lstlisting}
    36144382
    3615 Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3616 Note that this results in the ``inheritance'' of ©scalar© along both paths.
    3617 \begin{lstlisting}
    3618 trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
    3619         T ?/=?( T *, T ), ?*=?( T *, T );§\use{m_l_scalar}§§\use{arithmetic}§
     4383Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic. Note that this
     4384results in the ``inheritance'' of \lstinline$scalar$ along both paths.
     4385\begin{lstlisting}
     4386context m_l_arithmetic( type T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
     4387        T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
    36204388        T ?+=?( T *, T ), ?-=?( T *, T );
    36214389};
    3622 trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {§\impl{m_l_integral}§
    3623         T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );§\use{m_l_arithmetic}§
    3624         T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );§\use{integral}§
     4390
     4391context m_l_integral( type T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
     4392        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
     4393        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
    36254394};
    36264395\end{lstlisting}
    … …  
    36294398\subsection{Pointer and array types}
    36304399
    3631 Array 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 ``©a[i]©'' is equivalent to the dereferencing expression ``©(*( a+( i )))©''.
    3632 Technically, pointer arithmetic and pointer comparisons other than ``©==©'' and ``©!=©'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
    3633 Consequently, there is no need for a separate ``array type'' specification.
    3634 
    3635 Pointer types are scalar types.
    3636 Like other scalar types, they have ``©+©'' and ``©-©'' operators, but the types do not match the types of the operations in ©arithmetic©, so these operators cannot be consolidated in ©scalar©.
    3637 \begin{lstlisting}
    3638 trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
     4400Array types can barely be said to exist in {\c11}, since in most cases an array name is treated as a
     4401constant pointer to the first element of the array, and the subscript expression
     4402``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
     4403Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
     4404``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not
     4405enforce those restrictions. Consequently, there is no need for a separate ``array type''
     4406specification.
     4407
     4408Pointer types are scalar types. Like other scalar types, they have ``\lstinline$+$'' and
     4409``\lstinline$-$'' operators, but the types do not match the types of the operations in
     4410\lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
     4411\begin{lstlisting}
     4412context pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
    36394413        P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
    36404414        ptrdiff_t ?-?( P, P );
    36414415};
    3642 trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {§\impl{m_l_pointer}§
     4416
     4417context m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
    36434418        P ?+=?( P *, long int ), ?-=?( P *, long int );
    36444419        P ?=?( P *, void * );
    … …  
    36474422\end{lstlisting}
    36484423
    3649 Specifications 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.
    3650 Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
    3651 The assertion ``©|ptr_to( Safe_pointer, int )©'' should be read as ``©Safe_pointer© acts like a pointer to ©int©''.
    3652 \begin{lstlisting}
    3653 trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
    3654         lvalue T *?( P );
    3655         lvalue T ?[?]( P, long int );
     4424Specifications that define the dereference operator ( or subscript operator ) require two
     4425parameters, one for the pointer type and one for the pointed-at ( or element ) type. Different
     4426specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not
     4427included in types. The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
     4428``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
     4429\begin{lstlisting}
     4430context ptr_to( type P | pointer( P ), type T ) {@\impl{ptr_to}@@\use{pointer}@
     4431        lvalue T *?( P ); lvalue T ?[?]( P, long int );
    36564432};
    3657 trait ptr_to_const( otype P | pointer( P ), otype T ) {§\impl{ptr_to_const}§
    3658         const lvalue T *?( P );
    3659         const lvalue T ?[?]( P, long int );§\use{pointer}§
     4433
     4434context ptr_to_const( type P | pointer( P ), type T ) {@\impl{ptr_to_const}@
     4435        const lvalue T *?( P ); const lvalue T ?[?]( P, long int );@\use{pointer}@
    36604436};
    3661 trait ptr_to_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_volatile}§
    3662         volatile lvalue T *?( P );
    3663         volatile lvalue T ?[?]( P, long int );§\use{pointer}§
     4437
     4438context ptr_to_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_volatile}@
     4439        volatile lvalue T *?( P ); volatile lvalue T ?[?]( P, long int );@\use{pointer}@
    36644440};
    3665 trait ptr_to_const_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_const_volatile}§
    3666         const volatile lvalue T *?( P );§\use{pointer}§
     4441\end{lstlisting}
     4442\begin{lstlisting}
     4443context ptr_to_const_volatile( type P | pointer( P ), type T ) }@\impl{ptr_to_const_volatile}@
     4444        const volatile lvalue T *?( P );@\use{pointer}@
    36674445        const volatile lvalue T ?[?]( P, long int );
    36684446};
    36694447\end{lstlisting}
    36704448
    3671 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 ``©T *©'' can be assigned to a ``©const T *©'', a ``©volatile T *©'', and a ``©const volatile T *©''.
    3672 Again, the pointed-at type is passed in, so that assertions can connect these specifications to the ``©ptr_to©'' specifications.
    3673 \begin{lstlisting}
    3674 trait 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}§ {
     4449Assignment to pointers is more complicated than is the case with other types, because the target's
     4450type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to
     4451a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
     4452Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
     4453``\lstinline$ptr_to$'' specifications.
     4454\begin{lstlisting}
     4455context m_l_ptr_to( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ type T | ptr_to( P, T )@\use{ptr_to}@ {
    36754456        P ?=?( P *, T * );
    36764457        T * ?=?( T **, P );
    36774458};
    3678 trait 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}§) {
     4459
     4460context m_l_ptr_to_const( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ type T | ptr_to_const( P, T )@\use{ptr_to_const}@) {
    36794461        P ?=?( P *, const T * );
    36804462        const T * ?=?( const T **, P );
    36814463};
    3682 trait 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}§
     4464
     4465context m_l_ptr_to_volatile( type P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ type T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@
    36834466        P ?=?( P *, volatile T * );
    36844467        volatile T * ?=?( volatile T **, P );
    36854468};
    3686 trait 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}§
    3687                 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}§
     4469
     4470context 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}@
     4471                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}@
    36884472        P ?=?( P *, const volatile T * );
    36894473        const volatile T * ?=?( const volatile T **, P );
    … …  
    36914475\end{lstlisting}
    36924476
    3693 Note the regular manner in which type qualifiers appear in those specifications.
    3694 An 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.
    3695 \begin{lstlisting}
    3696 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 ) ) {
     4477Note the regular manner in which type qualifiers appear in those specifications. An alternative
     4478specification can make use of the fact that qualification of the pointed-at type is part of a
     4479pointer type to capture that regularity.
     4480\begin{lstlisting}
     4481context 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 ) ) {
    36974482        MyP ?=?( MyP *, CP );
    36984483        CP ?=?( CP *, MyP );
    36994484};
    37004485\end{lstlisting}
    3701 The assertion ``©| m_l_ptr_like( Safe_ptr, const int * )©'' should be read as ``©Safe_ptr© is a pointer type like ©const int *©''.
    3702 This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a ©MyP© produces an lvalue of the type that ©CP© points at, and the ``©|m_l_pointer( CP )©'' assertion provides only a weak assurance that the argument passed to ©CP© really is a pointer type.
     4486The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
     4487``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''. This specification has two
     4488defects, compared to the original four: there is no automatic assertion that dereferencing a
     4489\lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
     4490``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed
     4491to \lstinline$CP$ really is a pointer type.
    37034492
    37044493
    37054494\section{Relationships between operations}
    37064495
    3707 Different operators often have related meanings;
    3708 for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition.
    3709 Languages 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.
    3710 Completeness and consistency is left to the good taste and discretion of the programmer.
    3711 It is possible to encourage these attributes by providing generic operator functions, or member functions of abstract classes, that are defined in terms of other, related operators.
    3712 
    3713 In \CFA, polymorphic functions provide the equivalent of these generic operators, and specifications explicitly define the minimal implementation that a programmer should provide.
    3714 This section shows a few examples.
     4496Different operators often have related meanings; for instance, in C, ``\lstinline$+$'',
     4497``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
     4498Languages like {\CC} and Ada allow programmers to define operators for new types, but do not
     4499require that these relationships be preserved, or even that all of the operators be implemented.
     4500Completeness and consistency is left to the good taste and discretion of the programmer. It is
     4501possible to encourage these attributes by providing generic operator functions, or member functions
     4502of abstract classes, that are defined in terms of other, related operators.
     4503
     4504In \CFA, polymorphic functions provide the equivalent of these generic operators, and
     4505specifications explicitly define the minimal implementation that a programmer should provide. This
     4506section shows a few examples.
    37154507
    37164508
    37174509\subsection{Relational and equality operators}
    37184510
    3719 The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    3720 However, 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;
    3721 the library function ©strcmp© is an example.
    3722 
    3723 C and \CFA have an extra, non-obvious comparison operator: ``©!©'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    3724 \begin{lstlisting}
    3725 trait comparable( otype T ) {
     4511The different comparison operators have obvious relationships, but there is no obvious subset of the
     4512operations to use in the implementation of the others. However, it is usually convenient to
     4513implement a single comparison function that returns a negative integer, 0, or a positive integer if
     4514its first argument is respectively less than, equal to, or greater than its second argument; the
     4515library function \lstinline$strcmp$ is an example.
     4516
     4517C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation,
     4518returns 1 if its operand compares equal to 0, and 0 otherwise.
     4519\begin{lstlisting}
     4520context comparable( type T ) {
    37264521        const T 0;
    37274522        int compare( T, T );
    37284523}
    3729 forall( otype T | comparable( T ) ) int ?<?( T l, T r ) {
     4524
     4525forall( type T | comparable( T ) ) int ?<?( T l, T r ) {
    37304526        return compare( l, r ) < 0;
    37314527}
    37324528// ... similarly for <=, ==, >=, >, and !=.
    3733 forall( otype T | comparable( T ) ) int !?( T operand ) {
     4529
     4530forall( type T | comparable( T ) ) int !?( T operand ) {
    37344531        return !compare( operand, 0 );
    37354532}
    … …  
    37394536\subsection{Arithmetic and integer operations}
    37404537
    3741 A complete arithmetic type would provide the arithmetic operators and the corresponding assignment operators.
    3742 Of these, the assignment operators are more likely to be implemented directly, because it is usually more efficient to alter the contents of an existing object than to create and return a new one.
    3743 Similarly, a complete integral type would provide integral operations based on integral assignment operations.
    3744 \begin{lstlisting}
    3745 trait arith_base( otype T ) {
     4538A complete arithmetic type would provide the arithmetic operators and the corresponding assignment
     4539operators. Of these, the assignment operators are more likely to be implemented directly, because
     4540it is usually more efficient to alter the contents of an existing object than to create and return a
     4541new one. Similarly, a complete integral type would provide integral operations based on integral
     4542assignment operations.
     4543\begin{lstlisting}
     4544context arith_base( type T ) {
    37464545        const T 1;
    37474546        T ?+=?( T *, T ), ?-=?( T *, T ), ?*=?( T *, T ), ?/=?( T *, T );
    37484547}
    3749 forall( otype T | arith_base( T ) ) T ?+?( T l, T r ) {
     4548
     4549forall( type T | arith_base( T ) ) T ?+?( T l, T r ) {
    37504550        return l += r;
    37514551}
    3752 forall( otype T | arith_base( T ) ) T ?++( T * operand ) {
     4552
     4553forall( type T | arith_base( T ) ) T ?++( T * operand ) {
    37534554        T temporary = *operand;
    37544555        *operand += 1;
    37554556        return temporary;
    37564557}
    3757 forall( otype T | arith_base( T ) ) T ++?( T * operand ) {
     4558
     4559forall( type T | arith_base( T ) ) T ++?( T * operand ) {
    37584560        return *operand += 1;
    37594561}
    37604562// ... similarly for -, --, *, and /.
    3761 trait int_base( otype T ) {
     4563
     4564context int_base( type T ) {
    37624565        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );
    37634566        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );
    37644567}
    3765 forall( otype T | int_base( T ) ) T ?&?( T l, T r ) {
     4568
     4569forall( type T | int_base( T ) ) T ?&?( T l, T r ) {
    37664570        return l &= r;
    37674571}
    … …  
    37694573\end{lstlisting}
    37704574
    3771 Note 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 ©int_base©, ©arith_base© and ©comparable©.
    3772 Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
    3773 A truly minimal implementation of an arithmetic type might only provide ©0©, ©1©, and ©?-=?©, which would be used by polymorphic ©?+=?©, ©?*=?©, and ©?/=?© functions.
    3774 
    3775 Note also that ©short© is an integer type in C11 terms, but has no operations!
     4575Note that, although an arithmetic type would certainly provide comparison functions, and an integral
     4576type would provide arithmetic operations, there does not have to be any relationship among
     4577\lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$. Note also that these
     4578declarations provide guidance and assistance, but they do not define an absolutely minimal set of
     4579requirements. A truly minimal implementation of an arithmetic type might only provide
     4580\lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
     4581\lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
     4582
     4583Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations!
    37764584
    37774585
    … …  
    37794587Review index entries.
    37804588
    3781 Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers.
    3782 This gets into ©noalias© territory.
    3783 Qualifying anything (``©short restrict rs©'') means pointer parameters of ©?++©, etc, would need restrict qualifiers.
    3784 
    3785 Enumerated types.
    3786 Constants are not ints.
    3787 Overloading.
    3788 Definition should be ``representable as an integer type'', not ``as an int''.
    3789 C11 usual conversions freely convert to and from ordinary integer types via assignment, which works between any integer types.
    3790 Does enum Color ?*?( enum
     4589Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers. This gets
     4590into \lstinline$noalias$ territory. Qualifying anything (``\lstinline$short restrict rs$'') means
     4591pointer parameters of \lstinline$?++$, etc, would need restrict qualifiers.
     4592
     4593Enumerated types. Constants are not ints. Overloading. Definition should be ``representable as an
     4594integer type'', not ``as an int''. C11 usual conversions freely convert to and from ordinary
     4595integer types via assignment, which works between any integer types. Does enum Color ?*?( enum
    37914596Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    37924597
    3793 Operators on {,signed,unsigned} char and other small types. ©?<?© harmless;
    3794 ?*? questionable for chars.
    3795 Generic selections make these choices visible.
    3796 Safe conversion operators? Predefined ``promotion'' function?
    3797 
    3798 ©register© assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
    3799 
    3800 Don't use ©ptrdiff_t© by name in the predefineds.
    3801 
    3802 Polymorphic objects.
    3803 Polymorphic typedefs and type declarations.
     4598Operators on {,signed,unsigned} char and other small types. ?<? harmless; ?*? questionable for
     4599chars. Generic selections make these choices visible. Safe conversion operators? Predefined
     4600``promotion'' function?
     4601
     4602\lstinline$register$ assignment might be handled as assignment to a temporary with copying back and
     4603forth, but copying must not be done by assignment.
     4604
     4605Don't use ptrdiff\_t by name in the predefineds.
     4606
     4607Polymorphic objects. Polymorphic typedefs and type declarations.
    38044608
    38054609
    38064610\bibliographystyle{plain}
    3807 \bibliography{cfa}
     4611\bibliography{refrat}
    38084612
    38094613
    38104614\addcontentsline{toc}{chapter}{\indexname} % add index name to table of contents
    38114615\begin{theindex}
    3812 Italic page numbers give the location of the main entry for the referenced term.
    3813 Plain page numbers denote uses of the indexed term.
    3814 Entries for grammar non-terminals are italicized.
    3815 A typewriter font is used for grammar terminals and program identifiers.
     4616Italic page numbers give the location of the main entry for the referenced term. Plain page numbers
     4617denote uses of the indexed term. Entries for grammar non-terminals are italicized. A typewriter
     4618font is used for grammar terminals and program identifiers.
    38164619\indexspace
    38174620\input{refrat.ind}
Note: See TracChangeset for help on using the changeset viewer.