Changeset 1b7ea43


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

Merge branch 'master' into global-init

Files:
8 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r1048b31 r1b7ea43  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Apr 30 13:52:12 2016
    14 %% Update Count     : 41
     13%% Last Modified On : Wed May  4 08:01:10 2016
     14%% Update Count     : 54
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    132132% blocks and titles
    133133\newcommand{\define}[1]{\emph{#1\/}\index{#1}}
    134 \newcommand{\rewrite}{\(\Rightarrow\)}
    135134\newcommand{\rewriterules}{\paragraph{Rewrite Rules}~\par\noindent}
    136135\newcommand{\examples}{\paragraph{Examples}~\par\noindent}
     
    144143\newcommand{\lhs}[1]{\par{\emph{#1:}}\index{#1@{\emph{#1}}|italic}}
    145144\newcommand{\rhs}{\hfil\break\hbox{\hskip1in}}
    146 \newcommand{\oldlhs}[1]{\emph{#1: \ldots}\index{#1@{\emph{#1}}|italic}}
     145\newcommand{\oldlhs}[1]{\emph{#1: \dots}\index{#1@{\emph{#1}}|italic}}
    147146\newcommand{\nonterm}[1]{\emph{#1\/}\index{#1@{\emph{#1}}|italic}}
    148147\newcommand{\opt}{$_{opt}$\ }
     
    200199belowskip=2pt,
    201200moredelim=**[is][\color{red}]{®}{®}, % red highlighting
    202 moredelim=**[is][\color{blue}]{©}{©}, % blue highlighting
     201% moredelim=**[is][\color{blue}]{¢}{¢}, % blue highlighting
    203202moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % temporarily turn off keywords
    204203% literate={\\`}{\raisebox{0.3ex}{\ttfamily\upshape \hspace*{-2pt}`}}1, % escape \`, otherwise used for red highlighting
     204literate={...}{{$\dots$}}1 {<-}{{$\leftarrow$}}1 {=>}{{$\Rightarrow$}}1,
    205205}%
     206
     207\lstMakeShortInline©    % single-character for \lstinline
    206208
    207209\makeatletter
  • doc/refrat/refrat.tex

    r1048b31 r1b7ea43  
    1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2 %%
     1%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%``%%
    32%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
    43%%
     
    1110%% Created On       : Wed Apr  6 14:52:25 2016
    1211%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Apr 30 13:45:40 2016
    14 %% Update Count     : 29
     12%% Last Modified On : Tue May  3 18:00:28 2016
     13%% Update Count     : 64
    1514%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1615
    1716% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    1817
    19 % red highlighting ®...® (registered trademark sumbol)
    20 % blue highlighting ©...© (copyright symbol)
    21 % latex escape §...§ (section symbol)
    22 % keyword escape ¶...¶ (pilcrow symbol)
     18% inline code ©...© (copyright symbol) emacs: C-q M-)
     19% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
     20% latex escape §...§ (section symbol) emacs: C-q M-'
     21% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    2322% math escape $...$ (dollar symbol)
    2423
     
    2726
    2827% Latex packages used in the document.
     28\usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
     29\usepackage{textcomp}
     30\usepackage[latin1]{inputenc}
     31\usepackage{upquote}
    2932\usepackage{fullpage,times}
     33\usepackage{epic,eepic}
    3034\usepackage{xspace}
    3135\usepackage{varioref}
     
    4751%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    4852
     53% Names used in the document.
     54
     55\newcommand{\Version}{1.0.0}
     56
     57%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     58
    4959\setcounter{secnumdepth}{3}                             % number subsubsections
    5060\setcounter{tocdepth}{3}                                % subsubsections in table of contents
     
    129139\subsection{Scopes of identifiers}\index{scopes}
    130140
    131 \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
    132 \Index{name space}, instead of hiding them.
    133 The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline@type@\use{type} or
    134 \lstinline@typedef@\use{typedef} declaration and the other is not.  The outer declaration becomes
    135 \Index{visible} when the scope of the inner declaration terminates.
    136 \begin{rationale}
    137 Hence, a \CFA program can declare an \lstinline@int v@ and a \lstinline@float v@ in the same scope;
     141\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.
     142The 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.
     143The outer declaration becomes \Index{visible} when the scope of the inner declaration terminates.
     144\begin{rationale}
     145Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope;
    138146a {\CC} program can not.
    139147\end{rationale}
     
    144152
    145153\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.
    146 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
    147 \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.
     154Instead, 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.
    148155Within one translation unit, each instance of an identifier with \Index{internal linkage} denotes the same object or function in the same circumstances.
    149156Identifiers with \Index{no linkage} always denote unique entities.
    150157\begin{rationale}
    151 A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;
     158A \CFA program can declare an ©extern int v© and an ©extern float v©;
    152159a C program cannot.
    153160\end{rationale}
     
    172179\end{lstlisting}
    173180
    174 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline@sumable@.
     181The 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©.
    175182The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    176183
     
    220227\CFA defines situations where values of one type are automatically converted to another type.
    221228These conversions are called \define{implicit conversion}s.
    222 The programmer can request
    223 \define{explicit conversion}s using cast expressions.
     229The programmer can request \define{explicit conversion}s using cast expressions.
    224230
    225231
     
    233239In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    234240
    235 Let \lstinline@int$_r$@ and \lstinline@unsigned$_r$@ be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
    236 Let \lstinline@unsigned$_{mr}$@ be the unsigned integer type with maximal rank.
     241Let ©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$.
     242Let ©unsigned$_{mr}$© be the unsigned integer type with maximal rank.
    237243
    238244The following conversions are \emph{direct} safe arithmetic conversions.
     
    241247The \Index{integer promotion}s.
    242248\item
    243 For every rank $r$ greater than or equal to the rank of \lstinline@int@, conversion from \lstinline@int$_r$@ to \lstinline@unsigned$_r$@.
    244 \item
    245 For every rank $r$ greater than or equal to the rank of \lstinline@int@, where \lstinline@int$_{r+1}$@ exists and can represent all values of \lstinline@unsigned$_r$@, conversion from \lstinline@unsigned$_r$@ to \lstinline@int$_{r+1}$@.
    246 \item
    247 Conversion from \lstinline@unsigned$_{mr}$@ to \lstinline@float@.
     249For every rank $r$ greater than or equal to the rank of ©int©, conversion from ©int$_r$© to ©unsigned$_r$©.
     250\item
     251For 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}$©.
     252\item
     253Conversion from ©unsigned$_{mr}$© to ©float©.
    248254\item
    249255Conversion from an enumerated type to its compatible integer type.
    250256\item
    251 Conversion from \lstinline@float@ to \lstinline@double@, and from \lstinline@double@ to \lstinline@long double@.
    252 \item
    253 Conversion from \lstinline@float _Complex@ to \lstinline@double _Complex@, and from \lstinline@double _Complex@ to \lstinline@long double _Complex@.
     257Conversion from ©float© to ©double©, and from ©double© to ©long double©.
     258\item
     259Conversion from ©float _Complex© to ©double _Complex©, and from ©double _Complex© to ©long double _Complex©.
    254260\begin{sloppypar}
    255261\item
    256 Conversion from \lstinline@float _Imaginary@ to \lstinline@double _Imaginary@, and from \lstinline@double _Imaginary@ to \lstinline@long double _Imaginary@, if the implementation supports imaginary types.
     262Conversion from ©float _Imaginary© to ©double _Imaginary©, and from ©double _Imaginary© to ©long double _Imaginary©, if the implementation supports imaginary types.
    257263\end{sloppypar}
    258264\end{itemize}
    259265
    260 If type \lstinline@T@ can be converted to type \lstinline@U@ by a safe direct arithmetic conversion and type \lstinline@U@ can be converted to type \lstinline@V@ by a safe arithmetic conversion, then the conversion from \lstinline@T@ to type \lstinline@V@ is an \emph{indirect} safe arithmetic conversion.
     266If 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.
    261267
    262268\begin{rationale}
     
    272278\label{anon-conv}
    273279
    274 If an expression's type is a pointer to a structure or union type that has a member that is an
    275 \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.
     280If 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.
    276281The result of the conversion is a pointer to the member.
    277282
     
    291296move_to( &cp1, &cp2 );
    292297\end{lstlisting}
    293 Thanks to implicit conversion, the two arguments that \lstinline@move_by()@ receives are pointers to
    294 \lstinline@cp1@'s second member and \lstinline@cp2@'s second member.
     298Thanks to implicit conversion, the two arguments that ©move_by()© receives are pointers to ©cp1©'s second member and ©cp2©'s second member.
    295299
    296300
     
    334338a direct safe arithmetic conversion;
    335339\item
    336 from any object type or incomplete type to \lstinline@void@;
    337 \item
    338 from a pointer to any non-\lstinline@void@ type to a pointer to \lstinline@void@;
     340from any object type or incomplete type to ©void©;
     341\item
     342from a pointer to any non-©void© type to a pointer to ©void©;
    339343\item
    340344from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     
    347351Conversions that are not safe conversions are \define{unsafe conversion}s.
    348352\begin{rationale}
    349 As in C, there is an implicit conversion from \lstinline@void *@ to any pointer type.
     353As in C, there is an implicit conversion from ©void *© to any pointer type.
    350354This is clearly dangerous, and {\CC} does not have this implicit conversion.
    351355\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.
     
    373377\begin{itemize}
    374378\item
    375 The cost of an implicit conversion from \lstinline@int@ to \lstinline@long@ is 1.
    376 The cost of an implicit conversion from \lstinline@long@ to \lstinline@double@ is 3, because it is defined in terms of conversions from \lstinline@long@ to \lstinline@unsigned long@, then to \lstinline@float@, and then to \lstinline@double@.
    377 
    378 \item
    379 If \lstinline@int@ can represent all the values of \lstinline@unsigned short@, then the cost of an implicit conversion from \lstinline@unsigned short@ to \lstinline@unsigned@ is 2:
    380 \lstinline@unsigned short@ to \lstinline@int@ to \lstinline@unsigned@.
    381 Otherwise, \lstinline@unsigned short@ is converted directly to \lstinline@unsigned@, and the cost is 1.
    382 
    383 \item
    384 If \lstinline@long@ can represent all the values of \lstinline@unsigned@, then the conversion cost of \lstinline@unsigned@ to \lstinline@long@ is 1.
     379The cost of an implicit conversion from ©int© to ©long© is 1.
     380The 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©.
     381
     382\item
     383If ©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©.
     384Otherwise, ©unsigned short© is converted directly to ©unsigned©, and the cost is 1.
     385
     386\item
     387If ©long© can represent all the values of ©unsigned©, then the conversion cost of ©unsigned© to ©long© is 1.
    385388Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    386389\end{itemize}
     
    390393\begin{syntax}
    391394\oldlhs{keyword}
    392         \rhs \lstinline@forall@
    393         \rhs \lstinline@lvalue@
    394         \rhs \lstinline@trait@
    395         \rhs \lstinline@dtype@
    396         \rhs \lstinline@ftype@
    397         \rhs \lstinline@otype@
     395        \rhs ©forall©
     396        \rhs ©lvalue©
     397        \rhs ©trait©
     398        \rhs ©dtype©
     399        \rhs ©ftype©
     400        \rhs ©otype©
    398401\end{syntax}
    399402
     
    402405
    403406\CFA allows operator \Index{overloading} by associating operators with special function identifiers.
    404 Furthermore, the constants ``\lstinline@0@'' and ``\lstinline@1@'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
     407Furthermore, 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.
    405408Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    406409
     
    411414\begin{syntax}
    412415\oldlhs{identifier}
    413 \rhs \lstinline@0@
    414 \rhs \lstinline@1@
     416\rhs ©0©
     417\rhs ©1©
    415418\end{syntax}
    416419
    417 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline@0@''\impl{0} and ``\lstinline@1@''\impl{1} are identifiers.
     420\index{constant identifiers}\index{identifiers!for constants} The tokens ``©0©''\impl{0} and ``©1©''\impl{1} are identifiers.
    418421No other tokens defined by the rules for integer constants are considered to be identifiers.
    419422\begin{rationale}
    420 Why ``\lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.
     423Why ``©0©'' and ``©1©''? Those integers have special status in C.
    421424All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
    422 The operations ``\lstinline@&&@'', ``\lstinline@||@'', and ``\lstinline@!@'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
     425The operations ``©&&©'', ``©||©'', and ``©!©'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    423426A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    424427
    425428In 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.
    426429However, 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.
    427 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
    428 
    429 Why \emph{just} ``\lstinline@0@'' and ``\lstinline@1@''? Why not other integers? No other integers have special status in C.
    430 A facility that let programmers declare specific constants---``\lstinline@const Rational 12@'', for instance---would not be much of an improvement.
     430Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
     431
     432Why \emph{just} ``©0©'' and ``©1©''? Why not other integers? No other integers have special status in C.
     433A facility that let programmers declare specific constants---``©const Rational 12©'', for instance---would not be much of an improvement.
    431434Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    432435The complexity of such a feature doesn't seem worth the gain.
     
    444447\begin{tabular}[t]{ll}
    445448%identifier & operation \\ \hline
    446 \lstinline@?[?]@ & subscripting \impl{?[?]}\\
    447 \lstinline@?()@ & function call \impl{?()}\\
    448 \lstinline@?++@ & postfix increment \impl{?++}\\
    449 \lstinline@?--@ & postfix decrement \impl{?--}\\
    450 \lstinline@++?@ & prefix increment \impl{++?}\\
    451 \lstinline@--?@ & prefix decrement \impl{--?}\\
    452 \lstinline@*?@ & dereference \impl{*?}\\
    453 \lstinline@+?@ & unary plus \impl{+?}\\
    454 \lstinline@-?@ & arithmetic negation \impl{-?}\\
    455 \lstinline@~?@ & bitwise negation \impl{~?}\\
    456 \lstinline@!?@ & logical complement \impl{"!?}\\
    457 \lstinline@?*?@ & multiplication \impl{?*?}\\
    458 \lstinline@?/?@ & division \impl{?/?}\\
     449©?[?]© & subscripting \impl{?[?]}\\
     450©?()© & function call \impl{?()}\\
     451©?++© & postfix increment \impl{?++}\\
     452©?--© & postfix decrement \impl{?--}\\
     453©++?© & prefix increment \impl{++?}\\
     454©--?© & prefix decrement \impl{--?}\\
     455©*?© & dereference \impl{*?}\\
     456©+?© & unary plus \impl{+?}\\
     457©-?© & arithmetic negation \impl{-?}\\
     458©~?© & bitwise negation \impl{~?}\\
     459©!?© & logical complement \impl{"!?}\\
     460©?*?© & multiplication \impl{?*?}\\
     461©?/?© & division \impl{?/?}\\
    459462\end{tabular}\hfil
    460463\begin{tabular}[t]{ll}
    461464%identifier & operation \\ \hline
    462 \lstinline@?%?@ & remainder \impl{?%?}\\
    463 \lstinline@?+?@ & addition \impl{?+?}\\
    464 \lstinline@?-?@ & subtraction \impl{?-?}\\
    465 \lstinline@?<<?@ & left shift \impl{?<<?}\\
    466 \lstinline@?>>?@ & right shift \impl{?>>?}\\
    467 \lstinline@?<?@ & less than \impl{?<?}\\
    468 \lstinline@?<=?@ & less than or equal \impl{?<=?}\\
    469 \lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
    470 \lstinline@?>?@ & greater than \impl{?>?}\\
    471 \lstinline@?==?@ & equality \impl{?==?}\\
    472 \lstinline@?!=?@ & inequality \impl{?"!=?}\\
    473 \lstinline@?&?@ & bitwise AND \impl{?&?}\\
     465©?%?© & remainder \impl{?%?}\\
     466©?+?© & addition \impl{?+?}\\
     467©?-?© & subtraction \impl{?-?}\\
     468©?<<?© & left shift \impl{?<<?}\\
     469©?>>?© & right shift \impl{?>>?}\\
     470©?<?© & less than \impl{?<?}\\
     471©?<=?© & less than or equal \impl{?<=?}\\
     472©?>=?© & greater than or equal \impl{?>=?}\\
     473©?>?© & greater than \impl{?>?}\\
     474©?==?© & equality \impl{?==?}\\
     475©?!=?© & inequality \impl{?"!=?}\\
     476©?&?© & bitwise AND \impl{?&?}\\
    474477\end{tabular}\hfil
    475478\begin{tabular}[t]{ll}
    476479%identifier & operation \\ \hline
    477 \lstinline@?^?@ & exclusive OR \impl{?^?}\\
    478 \lstinline@?|?@ & inclusive OR \impl{?"|?}\\
    479 \lstinline@?=?@ & simple assignment \impl{?=?}\\
    480 \lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
    481 \lstinline@?/=?@ & division assignment \impl{?/=?}\\
    482 \lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
    483 \lstinline@?+=?@ & addition assignment \impl{?+=?}\\
    484 \lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
    485 \lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
    486 \lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
    487 \lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
    488 \lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
    489 \lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
     480©?^?© & exclusive OR \impl{?^?}\\
     481©?|?© & inclusive OR \impl{?"|?}\\
     482©?=?© & simple assignment \impl{?=?}\\
     483©?*=?© & multiplication assignment \impl{?*=?}\\
     484©?/=?© & division assignment \impl{?/=?}\\
     485©?%=?© & remainder assignment \impl{?%=?}\\
     486©?+=?© & addition assignment \impl{?+=?}\\
     487©?-=?© & subtraction assignment \impl{?-=?}\\
     488©?<<=?© & left-shift assignment \impl{?<<=?}\\
     489©?>>=?© & right-shift assignment \impl{?>>=?}\\
     490©?&=?© & bitwise AND assignment \impl{?&=?}\\
     491©?^=?© & exclusive OR assignment \impl{?^=?}\\
     492©?|=?© & inclusive OR assignment \impl{?"|=?}\\
    490493\end{tabular}
    491494\hfil
     
    502505
    503506\begin{rationale}
    504 The use of ``\lstinline@?@'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline@(i < 0)?--i:i@'' is legal in a C program, but a
    505 \CFA compiler detects a syntax error because it treats ``\lstinline@?--@'' as an identifier, not as the two tokens ``\lstinline@?@'' and ``\lstinline@--@''.
     507The 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
     508\CFA compiler detects a syntax error because it treats ``©?--©'' as an identifier, not as the two tokens ``©?©'' and ``©--©''.
    506509\end{rationale}
    507510
     
    510513\begin{itemize}
    511514\item
    512 The logical operators ``\lstinline@&&@'' and ``\lstinline@||@'', and the conditional operator
    513 ``\lstinline@?:@''.
     515The logical operators ``©&&©'' and ``©||©'', and the conditional operator ``©?:©''.
    514516These 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.
    515 Note that the definitions of ``\lstinline@&&@'' and ``\lstinline@||@'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline@!=@'' and ``\lstinline@0@'' for user-defined types is enough to allow them to be used in logical expressions.
     517Note 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.
    516518
    517519\item
     
    522524\item
    523525The ``address of'' operator.
    524 It would seem useful to define a unary ``\lstinline@&@'' operator that returns values of some programmer-defined pointer-like type.
     526It would seem useful to define a unary ``©&©'' operator that returns values of some programmer-defined pointer-like type.
    525527The problem lies with the type of the operator.
    526 Consider the expression ``\lstinline@p = &x@'', where \lstinline@x@ is of type
    527 \lstinline@T@ and \lstinline@p@ has the programmer-defined type \lstinline@T_ptr@.
    528 The expression might be treated as a call to the unary function ``\lstinline@&?@''.
    529 Now what is the type of the function's parameter? It can not be \lstinline@T@, because then \lstinline@x@ would be passed by value, and there is no way to create a useful pointer-like result from a value.
    530 Hence the parameter must have type \lstinline@T *@.
    531 But then the expression must be rewritten as ``\lstinline@p = &?( &x )@''
     528Consider the expression ``©p = &x©'', where ©x© is of type ©T© and ©p© has the programmer-defined type ©T_ptr©.
     529The expression might be treated as a call to the unary function ``©&?©''.
     530Now 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.
     531Hence the parameter must have type ©T *©.
     532But then the expression must be rewritten as ``©p = &?( &x )©''
    532533---which doesn't seem like progress!
    533534
    534535The 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''.
    535 It seems simpler to define a conversion function from \lstinline@T *@ to \lstinline@T_ptr@.
    536 
    537 \item
    538 The \lstinline@sizeof@ operator.
     536It seems simpler to define a conversion function from ©T *© to ©T_ptr©.
     537
     538\item
     539The ©sizeof© operator.
    539540It is already defined for every object type, and intimately tied into the language's storage allocation model.
    540541Redefining it seems pointless.
    541542
    542543\item
    543 The ``member of'' operators ``\lstinline@.@'' and ``\lstinline@->@''.
     544The ``member of'' operators ``©.©'' and ``©->©''.
    544545These are not really infix operators, since their right ``operand'' is not a value or object.
    545546
     
    578579The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    579580The ``lowest total expression cost'' rule chooses the proper common type.
    580 The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline@(double)-i@ will be preferred to \lstinline@-(double)i@.
     581The 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©.
    581582
    582583The ``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.
    583 It also gives preference to monomorphic values (such as the
    584 \lstinline@int@ \lstinline@0@) over polymorphic values (such as the \Index{null pointer}
    585 \lstinline@0@\use{0}).
     584It also gives preference to monomorphic values (such as the ©int© ©0©) over polymorphic values (such as the \Index{null pointer} ©0©\use{0}).
    586585However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    587586
     
    603602\begin{rationale}
    604603Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
    605 For instance, ``\lstinline@an_int + an_int@'' is equivalent to ``\lstinline@?+?(an_int, an_int)@''.
     604For instance, ``©an_int + an_int©'' is equivalent to ``©?+?(an_int, an_int)©''.
    606605If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    607606If predefined functions had external linkage, this optimization would be difficult.
     
    629628\rhs \nonterm{constant}
    630629\rhs \nonterm{string-literal}
    631 \rhs \lstinline@(@ \nonterm{expression} \lstinline@)@
     630\rhs ©(© \nonterm{expression} ©)©
    632631\rhs \nonterm{generic-selection}
    633632\end{syntax}
     
    645644
    646645A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
    647 The predefined integer identifiers ``\lstinline@1@'' and ``\lstinline@0@'' have the integer values 1 and 0, respectively.
    648 The other two predefined ``\lstinline@0@'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
     646The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively.
     647The 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.
    649648
    650649A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    651650
    652651\examples
    653 The expression \lstinline@(void *)0@\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline@void@. \lstinline@(const void *)0@ does the same, and also uses a safe conversion from \lstinline@void *@ to \lstinline@const void *@.
    654 In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    655 \lstinline@0@ to a pointer.
     652The 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 *©.
     653In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer ©0© to a pointer.
    656654
    657655\begin{rationale}
     
    659657
    660658\CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
    661 The C token ``\lstinline@0@'' is an expression of type \lstinline@int@ with the value ``zero'', and it \emph{also} is a null pointer constant.
    662 Similarly,
    663 ``\lstinline@(void *)0@ is an expression of type \lstinline@(void *)@ whose value is a null pointer, and it also is a null pointer constant.
    664 However, in C, ``\lstinline@(void *)(void *)0@'' is
     659The C token ``©0©'' is an expression of type ©int© with the value ``zero'', and it \emph{also} is a null pointer constant.
     660Similarly, ``©(void *)0© is an expression of type ©(void *)© whose value is a null pointer, and it also is a null pointer constant.
     661However, in C, ``©(void *)(void *)0©'' is
    665662\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.
    666663
     
    669666\begin{lstlisting}
    670667forall( dtype DT ) DT * const 0;
    671 \end{lstlisting} means that \lstinline@0@ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
     668\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.
    672669The only such value is the null pointer.
    673670Therefore the type \emph{alone} is enough to identify a null pointer.
     
    679676
    680677\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.
    681 If a generic selection has no \lstinline@default@ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
     678If 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.
    682679
    683680\semantics
     
    690687\lhs{postfix-expression}
    691688\rhs \nonterm{primary-expression}
    692 \rhs \nonterm{postfix-expression} \lstinline@[@ \nonterm{expression} \lstinline@]@
    693 \rhs \nonterm{postfix-expression} \lstinline@(@
    694          \nonterm{argument-expression-list}\opt \lstinline@)@
    695 \rhs \nonterm{postfix-expression} \lstinline@.@ \nonterm{identifier}
    696 \rhs \nonterm{postfix-expression} \lstinline@->@ \nonterm{identifier}
    697 \rhs \nonterm{postfix-expression} \lstinline@++@
    698 \rhs \nonterm{postfix-expression} \lstinline@--@
    699 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@}@
    700 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@,@ \lstinline@}@
     689\rhs \nonterm{postfix-expression} ©[© \nonterm{expression} ©]©
     690\rhs \nonterm{postfix-expression} ©(©
     691         \nonterm{argument-expression-list}\opt ©)©
     692\rhs \nonterm{postfix-expression} ©.© \nonterm{identifier}
     693\rhs \nonterm{postfix-expression} ©->© \nonterm{identifier}
     694\rhs \nonterm{postfix-expression} ©++©
     695\rhs \nonterm{postfix-expression} ©--©
     696\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©}©
     697\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©,© ©}©
    701698\lhs{argument-expression-list}
    702699\rhs \nonterm{assignment-expression}
    703 \rhs \nonterm{argument-expression-list} \lstinline@,@
     700\rhs \nonterm{argument-expression-list} ©,©
    704701         \nonterm{assignment-expression}
    705702\end{syntax}
     
    707704\rewriterules
    708705\begin{lstlisting}
    709 a[b] §\rewrite§ ?[?]( b, a ) // if a has integer type§\use{?[?]}§
    710 a[b] §\rewrite§ ?[?]( a, b ) // otherwise
    711 a( §\emph{arguments}§ ) §\rewrite§ ?()( a, §\emph{arguments}§ )§\use{?()}§
    712 a++ §\rewrite§ ?++(&( a ))§\use{?++}§
    713 a-- §\rewrite§ ?--(&( a ))§\use{?--}§
     706a[b] => ?[?]( b, a ) // if a has integer type§\use{?[?]}§
     707a[b] => ?[?]( a, b ) // otherwise
     708a( §\emph{arguments}§ ) => ?()( a, §\emph{arguments}§ )§\use{?()}§
     709a++ => ?++(&( a ))§\use{?++}§
     710a-- => ?--(&( a ))§\use{?--}§
    714711\end{lstlisting}
    715712
     
    739736The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    740737\begin{rationale}
    741 C defines subscripting as pointer arithmetic in a way that makes \lstinline@a[i]@ and
    742 \lstinline@i[a]@ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline@?[?]@.
     738C 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 ©?[?]©.
    743739
    744740Subscript expressions are rewritten as function calls that pass the first parameter by value.
    745741This is somewhat unfortunate, since array-like types tend to be large.
    746 The alternative is to use the rewrite rule ``\lstinline@a[b]@ \rewrite \lstinline@?[?](&(a), b)@''.
    747 However, C semantics forbid this approach: the \lstinline@a@ in ``\lstinline@a[b]@'' can be an arbitrary pointer value, which does not have an address.
     742The alternative is to use the rewrite rule ``©a[b] => ?[?](&(a), b)©''.
     743However, C semantics forbid this approach: the ©a© in ``©a[b]©'' can be an arbitrary pointer value, which does not have an address.
    748744
    749745The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
     
    760756\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    761757
    762 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline@?()@''.
     758For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``©?()©''.
    763759The valid interpretations of the rewritten expression are determined in the manner described below.
    764760
     
    767763\begin{itemize}
    768764\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
    769 \item if the function designator's type does not include a prototype or if the argument corresponds to
    770 ``\lstinline@...@'' in a prototype, a \Index{default argument promotion} is applied to it.
     765\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.
    771766\end{itemize}
    772767The type of the valid interpretation is the return type of the function designator.
    773768
    774 For those combinations where the interpretation of the \nonterm{postfix-expression} is a
    775 \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
     769For 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
    776770\begin{itemize}
    777771\item
    778 If the declaration of the implicit parameter uses \Index{type-class} \lstinline@type@\use{type}, the implicit argument must be an object type;
    779 if it uses \lstinline@dtype@, the implicit argument must be an object type or an incomplete type;
    780 and if it uses \lstinline@ftype@, the implicit argument must be a function type.
     772If the declaration of the implicit parameter uses \Index{type-class} ©type©\use{type}, the implicit argument must be an object type;
     773if it uses ©dtype©, the implicit argument must be an object type or an incomplete type;
     774and if it uses ©ftype©, the implicit argument must be a function type.
    781775
    782776\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.
     
    797791\begin{rationale}
    798792One 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}.
    799 For instance, it should be possible to replace a function ``\lstinline@int f( int );@'' with ``\lstinline@forall( otype T ) T f( T );@'' without affecting any calls of \lstinline@f@.
    800 
    801 \CFA\index{deficiencies!generalizability} does not fully possess this property, because
    802 \Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
     793For 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©.
     794
     795\CFA\index{deficiencies!generalizability} does not fully possess this property, because \Index{unsafe conversion} are not done when arguments are passed to polymorphic parameters.
    803796Consider
    804797\begin{lstlisting}
     
    811804f = g( d, f );          // (3) (unsafe conversion to float)
    812805\end{lstlisting}
    813 If \lstinline@g@ was replaced by ``\lstinline@forall( otype T ) T g( T, T );@'', the first and second calls would be unaffected, but the third would change: \lstinline@f@ would be converted to
    814 \lstinline@double@, and the result would be a \lstinline@double@.
    815 
    816 Another example is the function ``\lstinline@void h( int *);@''.
    817 This function can be passed a
    818 \lstinline@void *@ argument, but the generalization ``\lstinline@forall( otype T ) void h( T *);@'' can not.
    819 In this case, \lstinline@void@ is not a valid value for \lstinline@T@ because it is not an object type.
    820 If unsafe conversions were allowed, \lstinline@T@ could be inferred to be \emph{any} object type, which is undesirable.
     806If ©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©.
     807
     808Another example is the function ``©void h( int *);©''.
     809This function can be passed a ©void *© argument, but the generalization ``©forall( otype T ) void h( T *);©'' can not.
     810In this case, ©void© is not a valid value for ©T© because it is not an object type.
     811If unsafe conversions were allowed, ©T© could be inferred to be \emph{any} object type, which is undesirable.
    821812\end{rationale}
    822813
    823814\examples
    824 A function called ``\lstinline@?()@'' might be part of a numerical differentiation package.
     815A function called ``©?()©'' might be part of a numerical differentiation package.
    825816\begin{lstlisting}
    826817extern otype Derivative;
     
    833824d = sin_dx( 12.9 );
    834825\end{lstlisting}
    835 Here, the only interpretation of \lstinline@sin_dx@ is as an object of type \lstinline@Derivative@.
    836 For that interpretation, the function call is treated as ``\lstinline@?()( sin_dx, 12.9 )@''.
     826Here, the only interpretation of ©sin_dx© is as an object of type ©Derivative©.
     827For that interpretation, the function call is treated as ``©?()( sin_dx, 12.9 )©''.
    837828\begin{lstlisting}
    838829int f( long );          // (1)
     
    841832int i = f( 5 );         // calls (1)
    842833\end{lstlisting}
    843 Function (1) provides a valid interpretation of ``\lstinline@f( 5 )@'', using an implicit \lstinline@int@ to \lstinline@long@ conversion.
    844 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline@int@ to \lstinline@int *@ that could be used with the third function.
     834Function (1) provides a valid interpretation of ``©f( 5 )©'', using an implicit ©int© to ©long© conversion.
     835The 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.
    845836
    846837\begin{lstlisting}
     
    848839double d = h( 1.5 );
    849840\end{lstlisting}
    850 ``\lstinline@1.5@'' is a \lstinline@double@ constant, so \lstinline@T@ is inferred to be
    851 \lstinline@double@, and the result of the function call is a \lstinline@double@.
     841``©1.5©'' is a ©double© constant, so ©T© is inferred to be ©double©, and the result of the function call is a ©double©.
    852842
    853843\begin{lstlisting}
    854844forall( otype T, otype U ) void g( T, U );      // (4)
    855845forall( otype T ) void g( T, T );                       // (5)
    856 forall( otype T ) void g( T, long );                    // (6)
     846forall( otype T ) void g( T, long );            // (6)
    857847void g( long, long );                                           // (7)
    858848double d;
    859849int i;
    860850int *p;
    861 g( d, d );                      // calls (5)
    862 g( d, i );                      // calls (6)
    863 g( i, i );                      // calls (7)
    864 g( i, p );                      // calls (4)
    865 \end{lstlisting}
    866 The first call has valid interpretations for all four versions of \lstinline@g@. (6) and (7) are discarded because they involve unsafe \lstinline@double@-to-\lstinline@long@ conversions. (5) is chosen because it is less polymorphic than (4).
     851g( d, d );                                                                      // calls (5)
     852g( d, i );                                                                      // calls (6)
     853g( i, i );                                                                      // calls (7)
     854g( i, p );                                                                      // calls (4)
     855\end{lstlisting}
     856The 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).
    867857
    868858For the second call, (7) is again discarded.
    869 Of the remaining interpretations for (4), (5), and (6) (with \lstinline@i@ converted to \lstinline@long@), (6) is chosen because it is the least polymorphic.
     859Of the remaining interpretations for (4), (5), and (6) (with ©i© converted to ©long©), (6) is chosen because it is the least polymorphic.
    870860
    871861The third call has valid interpretations for all of the functions;
     
    883873shuffle( 9, 10 );
    884874\end{lstlisting}
    885 The only possibility for \lstinline@U@ is \lstinline@double@, because that is the type used in the only visible \lstinline@max@ function. 9 and 10 must be converted to \lstinline@double@, and
    886 \lstinline@min@ must be specialized with \lstinline@T@ bound to \lstinline@double@.
    887 \begin{lstlisting}
    888 extern void q( int );           // (8)
    889 extern void q( void * );        // (9)
     875The 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©.
     876\begin{lstlisting}
     877extern void q( int );                                           // (8)
     878extern void q( void * );                                        // (9)
    890879extern void r();
    891880q( 0 );
    892881r( 0 );
    893882\end{lstlisting}
    894 The \lstinline@int 0@ could be passed to (8), or the \lstinline@(void *)@ \Index{specialization} of the null pointer\index{null pointer} \lstinline@0@\use{0} could be passed to (9).
    895 The former is chosen because the \lstinline@int@ \lstinline@0@ is \Index{less polymorphic}.
    896 For the same reason, \lstinline@int@ \lstinline@0@ is passed to \lstinline@r()@, even though it has \emph{no} declared parameter types.
     883The ©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).
     884The former is chosen because the ©int© ©0© is \Index{less polymorphic}.
     885For the same reason, ©int© ©0© is passed to ©r()©, even though it has \emph{no} declared parameter types.
    897886
    898887
    899888\subsubsection{Structure and union members}
    900889
    901 \semantics In the member selection expression ``\lstinline@s@.\lstinline@m@'', there shall be at least one interpretation of \lstinline@s@ whose type is a structure type or union type containing a member named \lstinline@m@.
    902 If two or more interpretations of \lstinline@s@ have members named
    903 \lstinline@m@ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
    904 If an interpretation of \lstinline@s@ has a member \lstinline@m@ whose type is not compatible with any other
    905 \lstinline@s@'s \lstinline@m@, then the expression has an interpretation with the member's type.
     890\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©.
     891If 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.
     892If 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.
    906893The expression has no other interpretations.
    907894
    908 The expression ``\lstinline@p->m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.
     895The expression ``©p->m©'' has the same interpretations as the expression ``©(*p).m©''.
    909896
    910897
     
    1001988        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1002989\end{lstlisting}
    1003 For every extended integer type \lstinline@X@ there exist
     990For every extended integer type ©X© there exist
    1004991% Don't use predefined: keep this out of prelude.cf.
    1005992\begin{lstlisting}
     
    1007994  ?--( volatile X * ), ?--( _Atomic volatile X * );
    1008995\end{lstlisting}
    1009 For every complete enumerated type \lstinline@E@ there exist
     996For every complete enumerated type ©E© there exist
    1010997% Don't use predefined: keep this out of prelude.cf.
    1011998\begin{lstlisting}
     
    10151002
    10161003\begin{rationale}
    1017 Note that ``\lstinline@++@'' and ``\lstinline@--@'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
     1004Note 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.
    10181005This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    10191006\end{rationale}
     
    10211008\begin{rationale}
    10221009In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
    1023 Hence, \lstinline@void *@ objects cannot be incremented.
    1024 In \CFA, the restriction follows from the use of a \lstinline@type@ parameter in the predefined function definitions, as opposed to \lstinline@dtype@, since only object types can be inferred arguments corresponding to the type parameter \lstinline@T@.
     1010Hence, ©void *© objects cannot be incremented.
     1011In \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©.
    10251012\end{rationale}
    10261013
     
    10401027\end{lstlisting}
    10411028\begin{sloppypar}
    1042 Since \lstinline@&(vs)@ has type \lstinline@volatile short int *@, the best valid interpretation of
    1043 \lstinline@vs++@ calls the \lstinline@?++@ function with the \lstinline@volatile short *@ parameter.
    1044 \lstinline@s++@ does the same, applying the safe conversion from \lstinline@short int *@ to \lstinline@volatile short int *@.
    1045 Note that there is no conversion that adds an \lstinline@_Atomic@ qualifier, so the \lstinline@_Atomic volatile short int@ overloading does not provide a valid interpretation.
     1029Since ©&(vs)© has type ©volatile short int *©, the best valid interpretation of ©vs++© calls the ©?++© function with the ©volatile short *© parameter.
     1030©s++© does the same, applying the safe conversion from ©short int *© to ©volatile short int *©.
     1031Note that there is no conversion that adds an ©_Atomic© qualifier, so the ©_Atomic volatile short int© overloading does not provide a valid interpretation.
    10461032\end{sloppypar}
    10471033
    1048 There is no safe conversion from \lstinline@const short int *@ to \lstinline@volatile short int *@, and no \lstinline@?++@ function that accepts a \lstinline@const *@ parameter, so \lstinline@cs++@ has no valid interpretations.
    1049 
    1050 The best valid interpretation of \lstinline@as++@ calls the \lstinline@short ?++@ function with the \lstinline@_Atomic volatile short int *@ parameter, applying a safe conversion to add the \lstinline@volatile@ qualifier.
     1034There 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.
     1035
     1036The 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.
    10511037\begin{lstlisting}
    10521038char * const restrict volatile * restrict volatile pqpc;
     
    10551041ppc++;
    10561042\end{lstlisting}
    1057 Since \lstinline@&(pqpc)@ has type \lstinline@char * const restrict volatile * restrict volatile *@, the best valid interpretation of \lstinline@pqpc++@ calls the polymorphic \lstinline@?++@ function with the \lstinline@const restrict volatile T * restrict volatile *@ parameter, inferring \lstinline@T@ to be \lstinline@char *@.
    1058 
    1059 \lstinline@ppc++@ calls the same function, again inferring \lstinline@T@ to be \lstinline@char *@, and using the safe conversions from \lstinline@T@ to \lstinline@T const@ \lstinline@restrict volatile@.
     1043Since ©&(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 *©.
     1044
     1045©ppc++© calls the same function, again inferring ©T© to be ©char *©, and using the safe conversions from ©T© to ©T const© ©restrict volatile©.
    10601046
    10611047\begin{rationale}
     
    10711057\begin{enumerate}
    10721058\item
    1073 ``\lstinline@char * p; p++;@''.
    1074 The argument to \lstinline@?++@ has type \lstinline@char * *@, and the result has type \lstinline@char *@.
    1075 The expression would be valid if \lstinline@?++@ were declared by
     1059``©char * p; p++;©''.
     1060The argument to ©?++© has type ©char * *©, and the result has type ©char *©.
     1061The expression would be valid if ©?++© were declared by
    10761062\begin{lstlisting}
    10771063forall( otype T ) T * ?++( T * * );
    1078 \end{lstlisting} with \lstinline@T@ inferred to be \lstinline@char@.
    1079 
    1080 \item
    1081 ``\lstinline@char *restrict volatile qp; qp++@''.
    1082 The result again has type \lstinline@char *@, but the argument now has type \lstinline@char *restrict volatile *@, so it cannot be passed to the hypothetical function declared in point 1.
     1064\end{lstlisting} with ©T© inferred to be ©char©.
     1065
     1066\item
     1067``©char *restrict volatile qp; qp++©''.
     1068The 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.
    10831069Hence the actual predefined function is
    10841070\begin{lstlisting}
    10851071forall( otype T ) T * ?++( T * restrict volatile * );
    1086 \end{lstlisting} which also accepts a \lstinline@char * *@ argument, because of the safe conversions that add
    1087 \lstinline@volatile@ and \lstinline@restrict@ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
    1088 
    1089 \item
    1090 ``\lstinline@char *_Atomic ap; ap++@''.
    1091 The result again has type \lstinline@char *@, but no safe conversion adds an \lstinline@_Atomic@ qualifier, so the function in point 2 is not applicable.
    1092 A separate overloading of \lstinline@?++@ is required.
    1093 
    1094 \item
    1095 ``\lstinline@char const volatile * pq; pq++@''.
    1096 Here the result has type
    1097 \lstinline@char const volatile *@, so a new overloading is needed:
     1072\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.)
     1073
     1074\item
     1075``©char *_Atomic ap; ap++©''.
     1076The result again has type ©char *©, but no safe conversion adds an ©_Atomic© qualifier, so the function in point 2 is not applicable.
     1077A separate overloading of ©?++© is required.
     1078
     1079\item
     1080``©char const volatile * pq; pq++©''.
     1081Here the result has type ©char const volatile *©, so a new overloading is needed:
    10981082\begin{lstlisting}
    10991083forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     
    11021086 
    11031087\item
    1104 ``\lstinline@float *restrict * prp; prp++@''.
    1105 The \lstinline@restrict@ qualifier is handled just like \lstinline@const@ and \lstinline@volatile@ in the previous case:
     1088``©float *restrict * prp; prp++©''.
     1089The ©restrict© qualifier is handled just like ©const© and ©volatile© in the previous case:
    11061090\begin{lstlisting}
    11071091forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    1108 \end{lstlisting} with \lstinline@T@ inferred to be \lstinline@float *@.
    1109 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline@T@ is not syntactically a pointer type. \CFA loosens the constraint.
     1092\end{lstlisting} with ©T© inferred to be ©float *©.
     1093This 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.
    11101094\end{enumerate}
    11111095\end{rationale}
     
    11231107\lhs{unary-expression}
    11241108\rhs \nonterm{postfix-expression}
    1125 \rhs \lstinline@++@ \nonterm{unary-expression}
    1126 \rhs \lstinline@--@ \nonterm{unary-expression}
     1109\rhs ©++© \nonterm{unary-expression}
     1110\rhs ©--© \nonterm{unary-expression}
    11271111\rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1128 \rhs \lstinline@sizeof@ \nonterm{unary-expression}
    1129 \rhs \lstinline@sizeof@ \lstinline@(@ \nonterm{type-name} \lstinline@)@
    1130 \lhs{unary-operator} one of \rhs \lstinline@&@ \lstinline@*@ \lstinline@+@ \lstinline@-@ \lstinline@~@ \lstinline@!@
     1112\rhs ©sizeof© \nonterm{unary-expression}
     1113\rhs ©sizeof© ©(© \nonterm{type-name} ©)©
     1114\lhs{unary-operator} one of \rhs ©&© ©*© ©+© ©-© ©~© ©!©
    11311115\end{syntax}
    11321116
    11331117\rewriterules
    11341118\begin{lstlisting}
    1135 *a      §\rewrite§ *?( a ) §\use{*?}§
    1136 +a      §\rewrite§ +?( a ) §\use{+?}§
    1137 -a      §\rewrite§ -?( a ) §\use{-?}§
    1138 ~a      §\rewrite§ ~?( a ) §\use{~?}§
    1139 !a      §\rewrite§ !?( a ) §\use{"!?}§
    1140 ++a     §\rewrite§ ++?(&( a )) §\use{++?}§
    1141 --a     §\rewrite§ --?(&( a )) §\use{--?}§
     1119*a      => *?( a )§\use{*?}§
     1120+a      => +?( a )§\use{+?}§
     1121-a      => -?( a )§\use{-?}§
     1122~a      => ~?( a )§\use{~?}§
     1123!a      => !?( a )§\use{"!?}§
     1124++a     => ++?(&( a ))§\use{++?}§
     1125--a     => --?(&( a ))§\use{--?}§
    11421126\end{lstlisting}
    11431127
     
    12351219        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12361220\end{lstlisting}
    1237 For every extended integer type \lstinline@X@ there exist
     1221For every extended integer type ©X© there exist
    12381222% Don't use predefined: keep this out of prelude.cf.
    12391223\begin{lstlisting}
     
    12431227        --?( _Atomic volatile X * );
    12441228\end{lstlisting}
    1245 For every complete enumerated type \lstinline@E@ there exist
     1229For every complete enumerated type ©E© there exist
    12461230% Don't use predefined: keep this out of prelude.cf.
    12471231\begin{lstlisting}
     
    12801264
    12811265\constraints
    1282 The operand of the unary ``\lstinline@&@'' operator shall have exactly one
    1283 \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
     1266The operand of the unary ``©&©'' operator shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    12841267
    12851268\semantics
    1286 The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where
    1287 \lstinline@T@ is the type of the operand.
     1269The ``©&©'' expression has one interpretation which is of type ©T *©, where ©T© is the type of the operand.
    12881270
    12891271The interpretations of an indirection expression are the interpretations of the corresponding function call.
     
    13141296forall( ftype FT ) int !?( FT * );
    13151297\end{lstlisting}
    1316 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1298For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    13171299% Don't use predefined: keep this out of prelude.cf.
    13181300\begin{lstlisting}
     
    13281310long int li;
    13291311void eat_double( double );§\use{eat_double}§
    1330 eat_double(-li ); // §\rewrite§ eat_double( -?( li ) );
    1331 \end{lstlisting}
    1332 The valid interpretations of ``\lstinline@-li@'' (assuming no extended integer types exist) are
     1312eat_double(-li ); // => eat_double( -?( li ) );
     1313\end{lstlisting}
     1314The valid interpretations of ``©-li©'' (assuming no extended integer types exist) are
    13331315\begin{center}
    13341316\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    13351317\hline
    1336 \lstinline@-?( (int)li )@                                       & \lstinline@int@                                       & (unsafe) \\
    1337 \lstinline@-?( (unsigned)li)@                           & \lstinline@unsigned int@                      & (unsafe) \\
    1338 \lstinline@-?( (long)li)@                                       & \lstinline@long@                                      & 0 \\
    1339 \lstinline@-?( (long unsigned int)li)@          & \lstinline@long unsigned int@         & 1 \\
    1340 \lstinline@-?( (long long int)li)@                      & \lstinline@long long int@                     & 2 \\
    1341 \lstinline@-?( (long long unsigned int)li)@     & \lstinline@long long unsigned int@& 3 \\
    1342 \lstinline@-?( (float)li)@                                      & \lstinline@float@                                     & 4 \\
    1343 \lstinline@-?( (double)li)@                                     & \lstinline@double@                            & 5 \\
    1344 \lstinline@-?( (long double)li)@                        & \lstinline@long double@                       & 6 \\
    1345 \lstinline@-?( (_Complex float)li)@                     & \lstinline@float@                                     & (unsafe) \\
    1346 \lstinline@-?( (_Complex double)li)@            & \lstinline@double@                            & (unsafe) \\
    1347 \lstinline@-?( (_Complex long double)li)@       & \lstinline@long double@                       & (unsafe) \\
     1318©-?( (int)li )©                                         & ©int©                                         & (unsafe) \\
     1319©-?( (unsigned)li)©                                     & ©unsigned int©                        & (unsafe) \\
     1320©-?( (long)li)©                                         & ©long©                                        & 0 \\
     1321©-?( (long unsigned int)li)©            & ©long unsigned int©           & 1 \\
     1322©-?( (long long int)li)©                        & ©long long int©                       & 2 \\
     1323©-?( (long long unsigned int)li)©       & ©long long unsigned int©      & 3 \\
     1324©-?( (float)li)©                                        & ©float©                                       & 4 \\
     1325©-?( (double)li)©                                       & ©double©                                      & 5 \\
     1326©-?( (long double)li)©                          & ©long double©                         & 6 \\
     1327©-?( (_Complex float)li)©                       & ©float©                                       & (unsafe) \\
     1328©-?( (_Complex double)li)©                      & ©double©                                      & (unsafe) \\
     1329©-?( (_Complex long double)li)©         & ©long double©                         & (unsafe) \\
    13481330\end{tabular}
    13491331\end{center}
    1350 The valid interpretations of the \lstinline@eat_double@ call, with the cost of the argument conversion and the cost of the entire expression, are
     1332The valid interpretations of the ©eat_double© call, with the cost of the argument conversion and the cost of the entire expression, are
    13511333\begin{center}
    13521334\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    13531335\hline
    1354 \lstinline@eat_double( (double)-?( (int)li) )@                                  & 7                     & (unsafe) \\
    1355 \lstinline@eat_double( (double)-?( (unsigned)li) )@                             & 6                     & (unsafe) \\
    1356 \lstinline@eat_double( (double)-?(li) )@                                                & 5                     & \(0+5=5\) \\
    1357 \lstinline@eat_double( (double)-?( (long unsigned int)li) )@    & 4                     & \(1+4=5\) \\
    1358 \lstinline@eat_double( (double)-?( (long long int)li) )@                & 3                     & \(2+3=5\) \\
    1359 \lstinline@eat_double( (double)-?( (long long unsigned int)li) )@& 2            & \(3+2=5\) \\
    1360 \lstinline@eat_double( (double)-?( (float)li) )@                                & 1                     & \(4+1=5\) \\
    1361 \lstinline@eat_double( (double)-?( (double)li) )@                               & 0                     & \(5+0=5\) \\
    1362 \lstinline@eat_double( (double)-?( (long double)li) )@                  & (unsafe)      & (unsafe) \\
    1363 \lstinline@eat_double( (double)-?( (_Complex float)li) )@               & (unsafe)      & (unsafe) \\
    1364 \lstinline@eat_double( (double)-?( (_Complex double)li) )@              & (unsafe)      & (unsafe) \\
    1365 \lstinline@eat_double( (double)-?( (_Complex long double)li) )@ & (unsafe)      & (unsafe) \\
     1336©eat_double( (double)-?( (int)li) )©                                    & 7                     & (unsafe) \\
     1337©eat_double( (double)-?( (unsigned)li) )©                               & 6                     & (unsafe) \\
     1338©eat_double( (double)-?(li) )©                                                  & 5                     & \(0+5=5\) \\
     1339©eat_double( (double)-?( (long unsigned int)li) )©              & 4                     & \(1+4=5\) \\
     1340©eat_double( (double)-?( (long long int)li) )©                  & 3                     & \(2+3=5\) \\
     1341©eat_double( (double)-?( (long long unsigned int)li) )© & 2                     & \(3+2=5\) \\
     1342©eat_double( (double)-?( (float)li) )©                                  & 1                     & \(4+1=5\) \\
     1343©eat_double( (double)-?( (double)li) )©                                 & 0                     & \(5+0=5\) \\
     1344©eat_double( (double)-?( (long double)li) )©                    & (unsafe)      & (unsafe) \\
     1345©eat_double( (double)-?( (_Complex float)li) )©                 & (unsafe)      & (unsafe) \\
     1346©eat_double( (double)-?( (_Complex double)li) )©                & (unsafe)      & (unsafe) \\
     1347©eat_double( (double)-?( (_Complex long double)li) )©   & (unsafe)      & (unsafe) \\
    13661348\end{tabular}
    13671349\end{center}
    1368 Each has result type \lstinline@void@, so the best must be selected.
     1350Each has result type ©void©, so the best must be selected.
    13691351The interpretations involving unsafe conversions are discarded.
    1370 The remainder have equal expression conversion costs, so the
    1371 ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    1372 \lstinline@eat_double( (double)-?(li) )@.
     1352The remainder have equal expression conversion costs, so the ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is ©eat_double( (double)-?(li) )©.
    13731353
    13741354
     
    13761356
    13771357\constraints
    1378 The operand of \lstinline@sizeof@ or \lstinline@_Alignof@ shall not be \lstinline@type@, \lstinline@dtype@, or \lstinline@ftype@.
    1379 
    1380 When the \lstinline@sizeof@\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline@sizeof@ or \lstinline@_Alignof@ expression has one interpretation, of type \lstinline@size_t@.
    1381 
    1382 When \lstinline@sizeof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1358The operand of ©sizeof© or ©_Alignof© shall not be ©type©, ©dtype©, or ©ftype©.
     1359
     1360When 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©.
     1361
     1362When ©sizeof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13831363\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    13841364When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    13851365
    1386 When \lstinline@_Alignof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1366When ©_Alignof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13871367\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    13881368When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     
    13981378}
    13991379\end{lstlisting}
    1400 ``\lstinline@sizeof Rational@'', although not statically known, is fixed.
    1401 Within \lstinline@f()@,
    1402 ``\lstinline@sizeof(T)@'' is fixed for each call of \lstinline@f()@, but may vary from call to call.
     1380``©sizeof Rational©'', although not statically known, is fixed.
     1381Within ©f()©, ``©sizeof(T)©'' is fixed for each call of ©f()©, but may vary from call to call.
    14031382\end{rationale}
    14041383
     
    14091388\lhs{cast-expression}
    14101389\rhs \nonterm{unary-expression}
    1411 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \nonterm{cast-expression}
     1390\rhs ©(© \nonterm{type-name} ©)© \nonterm{cast-expression}
    14121391\end{syntax}
    14131392
    14141393\constraints
    1415 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline@type@,
    1416 \lstinline@dtype@, or \lstinline@ftype@.
     1394The \nonterm{type-name} in a \nonterm{cast-expression} shall not be ©type©, ©dtype©, or ©ftype©.
    14171395
    14181396\semantics
    14191397
    1420 In a \Index{cast expression} ``\lstinline@(@\nonterm{type-name}\lstinline@)e@'', if
    1421 \nonterm{type-name} is the type of an interpretation of \lstinline@e@, then that interpretation is the only interpretation of the cast expression;
    1422 otherwise, \lstinline@e@ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
     1398In a \Index{cast expression} ``©(©\nonterm{type-name}©)e©'', if
     1399\nonterm{type-name} is the type of an interpretation of ©e©, then that interpretation is the only interpretation of the cast expression;
     1400otherwise, ©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.
    14231401The 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.
    14241402
     
    14331411\lhs{multiplicative-expression}
    14341412\rhs \nonterm{cast-expression}
    1435 \rhs \nonterm{multiplicative-expression} \lstinline@*@ \nonterm{cast-expression}
    1436 \rhs \nonterm{multiplicative-expression} \lstinline@/@ \nonterm{cast-expression}
    1437 \rhs \nonterm{multiplicative-expression} \lstinline@%@ \nonterm{cast-expression}
     1413\rhs \nonterm{multiplicative-expression} ©*© \nonterm{cast-expression}
     1414\rhs \nonterm{multiplicative-expression} ©/© \nonterm{cast-expression}
     1415\rhs \nonterm{multiplicative-expression} ©%© \nonterm{cast-expression}
    14381416\end{syntax}
    14391417
    14401418\rewriterules
    14411419\begin{lstlisting}
    1442 a * b §\rewrite§ ?*?( a, b )§\use{?*?}§
    1443 a / b §\rewrite§ ?/?( a, b )§\use{?/?}§
    1444 a % b §\rewrite§ ?%?( a, b )§\use{?%?}§
     1420a * b => ?*?( a, b )§\use{?*?}§
     1421a / b => ?/?( a, b )§\use{?/?}§
     1422a % b => ?%?( a, b )§\use{?%?}§
    14451423\end{lstlisting}
    14461424
     
    14691447        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    14701448\end{lstlisting}
    1471 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1449For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    14721450% Don't use predefined: keep this out of prelude.cf.
    14731451\begin{lstlisting}
     
    14761454
    14771455\begin{rationale}
    1478 {\c11} does not include conversions from the \Index{real type}s to \Index{complex type}s in the
    1479 \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.
     1456{\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.
    14801457\end{rationale}
    14811458
     
    14901467eat_double( li % i );
    14911468\end{lstlisting}
    1492 ``\lstinline@li % i@'' is rewritten as ``\lstinline@?%?(li, i )@''.
    1493 The valid interpretations of \lstinline@?%?(li, i )@, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline@double@ (assuming no extended integer types are present ) are
     1469``©li % i©'' is rewritten as ``©?%?(li, i )©''.
     1470The 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
    14941471\begin{center}
    14951472\begin{tabular}{lcc} interpretation & argument cost & result cost \\
    1496 \hline 
    1497 \lstinline@ ?%?( (int)li, i )@                                                                          & (unsafe)      & 6     \\
    1498 \lstinline@ ?%?( (unsigned)li,(unsigned)i )@                                            & (unsafe)      & 5     \\
    1499 \lstinline@ ?%?( li, (long)i )@                                                                         & 1                     & 4     \\
    1500 \lstinline@ ?%?( (long unsigned)li,(long unsigned)i )@                          & 3                     & 3     \\
    1501 \lstinline@ ?%?( (long long)li,(long long)i )@                                          & 5                     & 2     \\
    1502 \lstinline@ ?%?( (long long unsigned)li, (long long unsigned)i )@       & 7                     & 1     \\
     1473\hline
     1474© ?%?( (int)li, i )©                                                                            & (unsafe)      & 6     \\
     1475© ?%?( (unsigned)li,(unsigned)i )©                                                      & (unsafe)      & 5     \\
     1476© ?%?( li, (long)i )©                                                                           & 1                     & 4     \\
     1477© ?%?( (long unsigned)li,(long unsigned)i )©                            & 3                     & 3     \\
     1478© ?%?( (long long)li,(long long)i )©                                            & 5                     & 2     \\
     1479© ?%?( (long long unsigned)li, (long long unsigned)i )©         & 7                     & 1     \\
    15031480\end{tabular}
    15041481\end{center}
    1505 The best interpretation of \lstinline@eat_double( li, i )@ is
    1506 \lstinline@eat_double( (double)?%?(li, (long)i ))@, which has no unsafe conversions and the lowest total cost.
    1507 
    1508 \begin{rationale}
    1509 {\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline@int@.If
    1510 \lstinline@s@ is a \lstinline@short int@, ``\lstinline@s *s@'' does not have type \lstinline@short int@;
    1511 it is treated as ``\lstinline@( (int)s ) * ( (int)s )@'', and has type \lstinline@int@. \CFA matches that pattern;
    1512 it does not predefine ``\lstinline@short ?*?( short, short )@''.
     1482The best interpretation of ©eat_double( li, i )© is ©eat_double( (double)?%?(li, (long)i ))©, which has no unsafe conversions and the lowest total cost.
     1483
     1484\begin{rationale}
     1485{\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©.
     1486If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©;
     1487it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern;
     1488it does not predefine ``©short ?*?( short, short )©''.
    15131489
    15141490These ``missing'' operators limit polymorphism.
     
    15191495square( s );
    15201496\end{lstlisting}
    1521 Since \CFA does not define a multiplication operator for \lstinline@short int@,
    1522 \lstinline@square( s )@ is treated as \lstinline@square( (int)s )@, and the result has type
    1523 \lstinline@int@.
     1497Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©.
    15241498This is mildly surprising, but it follows the {\c11} operator pattern.
    15251499
     
    15301504product( sa, 5);
    15311505\end{lstlisting}
    1532 This has no valid interpretations, because \CFA has no conversion from ``array of
    1533 \lstinline@short int@'' to ``array of \lstinline@int@''.
     1506This has no valid interpretations, because \CFA has no conversion from ``array of ©short int©'' to ``array of ©int©''.
    15341507The alternatives in such situations include
    15351508\begin{itemize}
    15361509\item
    1537 Defining monomorphic overloadings of \lstinline@product@ for \lstinline@short@ and the other
    1538 ``small'' types.
    1539 \item
    1540 Defining ``\lstinline@short ?*?( short, short )@'' within the scope containing the call to
    1541 \lstinline@product@.
    1542 \item
    1543 Defining \lstinline@product@ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
     1510Defining monomorphic overloadings of ©product© for ©short© and the other ``small'' types.
     1511\item
     1512Defining ``©short ?*?( short, short )©'' within the scope containing the call to ©product©.
     1513\item
     1514Defining ©product© to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    15441515\end{itemize}
    15451516\end{rationale}
     
    15511522\lhs{additive-expression}
    15521523\rhs \nonterm{multiplicative-expression}
    1553 \rhs \nonterm{additive-expression} \lstinline@+@ \nonterm{multiplicative-expression}
    1554 \rhs \nonterm{additive-expression} \lstinline@-@ \nonterm{multiplicative-expression}
     1524\rhs \nonterm{additive-expression} ©+© \nonterm{multiplicative-expression}
     1525\rhs \nonterm{additive-expression} ©-© \nonterm{multiplicative-expression}
    15551526\end{syntax}
    15561527
    15571528\rewriterules
    15581529\begin{lstlisting}
    1559 a + b §\rewrite§ ?+?( a, b )§\use{?+?}§
    1560 a - b §\rewrite§ ?-?( a, b )§\use{?-?}§
     1530a + b => ?+?( a, b )§\use{?+?}§
     1531a - b => ?-?( a, b )§\use{?-?}§
    15611532\end{lstlisting}
    15621533
     
    16111582        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    16121583\end{lstlisting}
    1613 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1584For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16141585% Don't use predefined: keep this out of prelude.cf.
    16151586\begin{lstlisting}
     
    16211592
    16221593\begin{rationale}
    1623 \lstinline@ptrdiff_t@ is an implementation-defined identifier defined in \lstinline@<stddef.h>@ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
     1594©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.
    16241595It 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.
    1625 The {\c11} standard uses \lstinline@size_t@ in several cases where a library function takes an argument that is used as a subscript, but \lstinline@size_t@ is unsuitable here because it is an unsigned type.
     1596The {\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.
    16261597\end{rationale}
    16271598
     
    16321603\lhs{shift-expression}
    16331604\rhs \nonterm{additive-expression}
    1634 \rhs \nonterm{shift-expression} \lstinline@<<@ \nonterm{additive-expression}
    1635 \rhs \nonterm{shift-expression} \lstinline@>>@ \nonterm{additive-expression}
     1605\rhs \nonterm{shift-expression} ©<<© \nonterm{additive-expression}
     1606\rhs \nonterm{shift-expression} ©>>© \nonterm{additive-expression}
    16361607\end{syntax}
    16371608
    1638 \rewriterules \use{?>>?}%use{?<<?}
    1639 \begin{lstlisting}
    1640 a << b §\rewrite§ ?<<?( a, b )
    1641 a >> b §\rewrite§ ?>>?( a, b )
     1609\rewriterules
     1610\begin{lstlisting}
     1611a << b => ?<<?( a, b )§\use{?<<?}§
     1612a >> b => ?>>?( a, b )§\use{?>>?}§
    16421613\end{lstlisting}
    16431614
     
    16511622long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    16521623\end{lstlisting}
    1653 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1624For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16541625% Don't use predefined: keep this out of prelude.cf.
    16551626\begin{lstlisting}
     
    16711642\lhs{relational-expression}
    16721643\rhs \nonterm{shift-expression}
    1673 \rhs \nonterm{relational-expression} \lstinline@< @ \nonterm{shift-expression}
    1674 \rhs \nonterm{relational-expression} \lstinline@> @ \nonterm{shift-expression}
    1675 \rhs \nonterm{relational-expression} \lstinline@<=@ \nonterm{shift-expression}
    1676 \rhs \nonterm{relational-expression} \lstinline@>=@ \nonterm{shift-expression}
     1644\rhs \nonterm{relational-expression} ©< © \nonterm{shift-expression}
     1645\rhs \nonterm{relational-expression} ©> © \nonterm{shift-expression}
     1646\rhs \nonterm{relational-expression} ©<=© \nonterm{shift-expression}
     1647\rhs \nonterm{relational-expression} ©>=© \nonterm{shift-expression}
    16771648\end{syntax}
    16781649
    1679 \rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
    1680 \begin{lstlisting}
    1681 a < b §\rewrite§ ?<?( a, b )
    1682 a > b §\rewrite§ ?>?( a, b )
    1683 a <= b §\rewrite§ ?<=?( a, b )
    1684 a >= b §\rewrite§ ?>=?( a, b )
     1650\rewriterules
     1651\begin{lstlisting}
     1652a < b => ?<?( a, b )§\use{?<?}§
     1653a > b => ?>?( a, b )§\use{?>?}§
     1654a <= b => ?<=?( a, b )§\use{?<=?}§
     1655a >= b => ?>=?( a, b )§\use{?>=?}§
    16851656\end{lstlisting}
    16861657
     
    17141685        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    17151686\end{lstlisting}
    1716 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1687For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17171688% Don't use predefined: keep this out of prelude.cf.
    17181689\begin{lstlisting}
     
    17321703\lhs{equality-expression}
    17331704\rhs \nonterm{relational-expression}
    1734 \rhs \nonterm{equality-expression} \lstinline@==@ \nonterm{relational-expression}
    1735 \rhs \nonterm{equality-expression} \lstinline@!=@ \nonterm{relational-expression}
     1705\rhs \nonterm{equality-expression} ©==© \nonterm{relational-expression}
     1706\rhs \nonterm{equality-expression} ©!=© \nonterm{relational-expression}
    17361707\end{syntax}
    17371708
    17381709\rewriterules
    17391710\begin{lstlisting}
    1740 a == b §\rewrite§ ?==?( a, b )§\use{?==?}§
    1741 a != b §\rewrite§ ?!=?( a, b )§\use{?"!=?}§
     1711a == b => ?==?( a, b )§\use{?==?}§
     1712a != b => ?!=?( a, b )§\use{?"!=?}§
    17421713\end{lstlisting}
    17431714
     
    17921763        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    17931764\end{lstlisting}
    1794 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1765For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17951766% Don't use predefined: keep this out of prelude.cf.
    17961767\begin{lstlisting}
     
    18001771
    18011772\begin{rationale}
    1802 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline@void@ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
     1773The 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.
    18031774In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    18041775\end{rationale}
     
    18211792\lhs{AND-expression}
    18221793\rhs \nonterm{equality-expression}
    1823 \rhs \nonterm{AND-expression} \lstinline@&@ \nonterm{equality-expression}
     1794\rhs \nonterm{AND-expression} ©&© \nonterm{equality-expression}
    18241795\end{syntax}
    18251796
    18261797\rewriterules
    18271798\begin{lstlisting}
    1828 a & b §\rewrite§ ?&?( a, b )§\use{?&?}§
     1799a & b => ?&?( a, b )§\use{?&?}§
    18291800\end{lstlisting}
    18301801
     
    18381809long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    18391810\end{lstlisting}
    1840 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1811For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18411812% Don't use predefined: keep this out of prelude.cf.
    18421813\begin{lstlisting}
     
    18531824\lhs{exclusive-OR-expression}
    18541825\rhs \nonterm{AND-expression}
    1855 \rhs \nonterm{exclusive-OR-expression} \lstinline@^@ \nonterm{AND-expression}
     1826\rhs \nonterm{exclusive-OR-expression} ©^© \nonterm{AND-expression}
    18561827\end{syntax}
    18571828
    18581829\rewriterules
    18591830\begin{lstlisting}
    1860 a ^ b §\rewrite§ ?^?( a, b )§\use{?^?}§
     1831a ^ b => ?^?( a, b )§\use{?^?}§
    18611832\end{lstlisting}
    18621833
     
    18701841long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    18711842\end{lstlisting}
    1872 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1843For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18731844% Don't use predefined: keep this out of prelude.cf.
    18741845\begin{lstlisting}
     
    18851856\lhs{inclusive-OR-expression}
    18861857\rhs \nonterm{exclusive-OR-expression}
    1887 \rhs \nonterm{inclusive-OR-expression} \lstinline@|@ \nonterm{exclusive-OR-expression}
     1858\rhs \nonterm{inclusive-OR-expression} ©|© \nonterm{exclusive-OR-expression}
    18881859\end{syntax}
    18891860
    1890 \rewriterules\use{?"|?}
    1891 \begin{lstlisting}
    1892 a | b §\rewrite§ ?|?( a, b )
     1861\rewriterules
     1862\begin{lstlisting}
     1863a | b => ?|?( a, b )§\use{?"|?}§
    18931864\end{lstlisting}
    18941865
     
    19021873long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    19031874\end{lstlisting}
    1904 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1875For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    19051876% Don't use predefined: keep this out of prelude.cf.
    19061877\begin{lstlisting}
     
    19171888\lhs{logical-AND-expression}
    19181889\rhs \nonterm{inclusive-OR-expression}
    1919 \rhs \nonterm{logical-AND-expression} \lstinline@&&@ \nonterm{inclusive-OR-expression}
     1890\rhs \nonterm{logical-AND-expression} ©&&© \nonterm{inclusive-OR-expression}
    19201891\end{syntax}
    19211892
    1922 \semantics The operands of the expression ``\lstinline@a && b@'' are treated as
    1923 ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b)!=0)@'', which shall both be unambiguous.
    1924 The expression has only one interpretation, which is of type \lstinline@int@.
    1925 \begin{rationale}
    1926 When the operands of a logical expression are values of built-in types, and ``\lstinline@!=@'' has not been redefined for those types, the compiler can optimize away the function calls.
    1927 
    1928 A common C idiom omits comparisons to \lstinline@0@ in the controlling expressions of loops and
    1929 \lstinline@if@ statements.
    1930 For instance, the loop below iterates as long as \lstinline@rp@ points at a \lstinline@Rational@ value that is non-zero.
     1893\semantics The operands of the expression ``©a && b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b)!=0)©'', which shall both be unambiguous.
     1894The expression has only one interpretation, which is of type ©int©.
     1895\begin{rationale}
     1896When 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.
     1897
     1898A common C idiom omits comparisons to ©0© in the controlling expressions of loops and ©if© statements.
     1899For instance, the loop below iterates as long as ©rp© points at a ©Rational© value that is non-zero.
    19311900
    19321901\begin{lstlisting}
     
    19371906while ( rp && *rp ) { ... }
    19381907\end{lstlisting}
    1939 The logical expression calls the \lstinline@Rational@ inequality operator, passing it \lstinline@*rp@ and the \lstinline@Rational 0@, and getting a 1 or 0 as a result.
    1940 In contrast, {\CC} would apply a programmer-defined \lstinline@Rational@-to-\lstinline@int@ conversion to \lstinline@*rp@ in the equivalent situation.
    1941 The conversion to \lstinline@int@ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
     1908The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result.
     1909In contrast, {\CC} would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
     1910The 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.
    19421911\end{rationale}
    19431912
     
    19481917\lhs{logical-OR-expression}
    19491918\rhs \nonterm{logical-AND-expression}
    1950 \rhs \nonterm{logical-OR-expression} \lstinline@||@ \nonterm{logical-AND-expression}
     1919\rhs \nonterm{logical-OR-expression} ©||© \nonterm{logical-AND-expression}
    19511920\end{syntax}
    19521921
    19531922\semantics
    19541923
    1955 The operands of the expression ``\lstinline@a || b@'' are treated as ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b))!=0)@'', which shall both be unambiguous.
    1956 The expression has only one interpretation, which is of type \lstinline@int@.
     1924The operands of the expression ``©a || b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b))!=0)©'', which shall both be unambiguous.
     1925The expression has only one interpretation, which is of type ©int©.
    19571926
    19581927
     
    19621931\lhs{conditional-expression}
    19631932\rhs \nonterm{logical-OR-expression}
    1964 \rhs \nonterm{logical-OR-expression} \lstinline@?@ \nonterm{expression}
    1965          \lstinline@:@ \nonterm{conditional-expression}
     1933\rhs \nonterm{logical-OR-expression} ©?© \nonterm{expression}
     1934         ©:© \nonterm{conditional-expression}
    19661935\end{syntax}
    19671936
    19681937\semantics
    1969 In the conditional expression\use{?:} ``\lstinline@a?b:c@'', if the second and third operands both have an interpretation with \lstinline@void@ type, then the expression has an interpretation with type \lstinline@void@, equivalent to
     1938In 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
    19701939\begin{lstlisting}
    19711940( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    19721941\end{lstlisting}
    19731942
    1974 If the second and third operands both have interpretations with non-\lstinline@void@ types, the expression is treated as if it were the call ``\lstinline@cond((a)!=0, b, c)@'', with \lstinline@cond@ declared as
     1943If 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
    19751944\begin{lstlisting}
    19761945forall( otype T ) T cond( int, T, T );
     
    20241993rand() ? i : l;
    20251994\end{lstlisting}
    2026 The best interpretation infers the expression's type to be \lstinline@long@ and applies the safe
    2027 \lstinline@int@-to-\lstinline@long@ conversion to \lstinline@i@.
     1995The best interpretation infers the expression's type to be ©long© and applies the safe ©int©-to-©long© conversion to ©i©.
    20281996
    20291997\begin{lstlisting}
     
    20322000rand() ? cip : vip;
    20332001\end{lstlisting}
    2034 The expression has type \lstinline@const volatile int *@, with safe conversions applied to the second and third operands to add \lstinline@volatile@ and \lstinline@const@ qualifiers, respectively.
     2002The expression has type ©const volatile int *©, with safe conversions applied to the second and third operands to add ©volatile© and ©const© qualifiers, respectively.
    20352003
    20362004\begin{lstlisting}
    20372005rand() ? cip : 0;
    20382006\end{lstlisting}
    2039 The expression has type \lstinline@const int *@, with a specialization conversion applied to
    2040 \lstinline@0@.
     2007The expression has type ©const int *©, with a specialization conversion applied to ©0©.
    20412008
    20422009
     
    20492016         \nonterm{assignment-expression}
    20502017\lhs{assignment-operator} one of
    2051 \rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@-=@\ \ 
    2052          \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@|=@
     2018\rhs ©=©\ \ ©*=©\ \ ©/=©\ \ ©%=©\ \ ©+=©\ \ ©-=©\ \ ©<<=©\ \ ©>>=©\ \ ©&=©\ \ ©^=©\ \ ©|=©
    20532019\end{syntax}
    20542020
    20552021\rewriterules
    2056 Let ``\(\leftarrow\)'' be any of the assignment operators.
     2022Let ``©<-©'' be any of the assignment operators.
    20572023Then
    2058 \use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}
    2059 \use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    2060 \begin{lstlisting}
    2061 a §$\leftarrow$§ b §\rewrite§ ?§$\leftarrow$§?( &( a ), b )
     2024\use{?=?}\use{?*=?}\use{?/=?}\use{?%=?}\use{?+=?}\use{?-=?}\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
     2025\begin{lstlisting}
     2026a <- b => ?<-?( &( a ), b )
    20622027\end{lstlisting}
    20632028
    20642029\semantics
    20652030Each interpretation of the left operand of an assignment expression is considered separately.
    2066 For each interpretation that is a bit-field or is declared with the \lstinline@register@ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
     2031For 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.
    20672032The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    20682033For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     
    22972262\end{lstlisting}
    22982263\begin{rationale}
    2299 The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline@dtype@ parameter, instead of a \lstinline@type@ parameter, because the left operand may be a pointer to an incomplete type.
    2300 \end{rationale}
    2301 
    2302 For every complete structure or union type \lstinline@S@ there exist
     2264The 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.
     2265\end{rationale}
     2266
     2267For every complete structure or union type ©S© there exist
    23032268% Don't use predefined: keep this out of prelude.cf.
    23042269\begin{lstlisting}
     
    23062271\end{lstlisting}
    23072272
    2308 For every extended integer type \lstinline@X@ there exist
     2273For every extended integer type ©X© there exist
    23092274% Don't use predefined: keep this out of prelude.cf.
    23102275\begin{lstlisting}
     
    23122277\end{lstlisting}
    23132278
    2314 For every complete enumerated type \lstinline@E@ there exist
     2279For every complete enumerated type ©E© there exist
    23152280% Don't use predefined: keep this out of prelude.cf.
    23162281\begin{lstlisting}
     
    23182283\end{lstlisting}
    23192284\begin{rationale}
    2320 The right-hand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.
     2285The right-hand argument is ©int© because enumeration constants have type ©int©.
    23212286\end{rationale}
    23222287
     
    25792544\end{lstlisting}
    25802545
    2581 For every extended integer type \lstinline@X@ there exist
     2546For every extended integer type ©X© there exist
    25822547% Don't use predefined: keep this out of prelude.cf.
    25832548\begin{lstlisting}
     
    25942559\end{lstlisting}
    25952560
    2596 For every complete enumerated type \lstinline@E@ there exist
     2561For every complete enumerated type ©E© there exist
    25972562% Don't use predefined: keep this out of prelude.cf.
    25982563\begin{lstlisting}
     
    26152580\lhs{expression}
    26162581\rhs \nonterm{assignment-expression}
    2617 \rhs \nonterm{expression} \lstinline@,@ \nonterm{assignment-expression}
     2582\rhs \nonterm{expression} ©,© \nonterm{assignment-expression}
    26182583\end{syntax}
    26192584
    26202585\semantics
    2621 In the comma expression ``\lstinline@a, b@'', the first operand is interpreted as
    2622 ``\lstinline@( void )(a)@'', which shall be unambiguous\index{ambiguous interpretation}.
     2586In the comma expression ``©a, b©'', the first operand is interpreted as ``©( void )(a)©'', which shall be unambiguous\index{ambiguous interpretation}.
    26232587The interpretations of the expression are the interpretations of the second operand.
    26242588
     
    26552619{ ... }
    26562620\end{lstlisting}
    2657 Without the rule, \lstinline@Complex@ would be a type in the first case, and a parameter name in the second.
     2621Without the rule, ©Complex© would be a type in the first case, and a parameter name in the second.
    26582622\end{rationale}
    26592623
     
    27122676\begin{syntax}
    27132677\lhs{forall-specifier}
    2714 \rhs \lstinline@forall@ \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
     2678\rhs ©forall© ©(© \nonterm{type-parameter-list} ©)©
    27152679\end{syntax}
    27162680
     
    27242688} mkPair( T, T ); // illegal
    27252689\end{lstlisting}
    2726 If an instance of \lstinline@struct Pair@ was declared later in the current scope, what would the members' type be?
     2690If an instance of ©struct Pair© was declared later in the current scope, what would the members' type be?
    27272691\end{rationale}
    27282692\end{comment}
     
    27312695The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    27322696
    2733 If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forall-specifier}s and
    2734 \lstinline@D@ has the form
     2697If, in the declaration ``©T D©'', ©T© contains \nonterm{forall-specifier}s and ©D© has the form
    27352698\begin{lstlisting}
    27362699D( §\normalsize\nonterm{parameter-type-list}§ )
    2737 \end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline@D@, and it is used in the type of a parameter in the following
    2738 \nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    2739 \Index{specification} in one of the \nonterm{forall-specifier}s.
     2700\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
     2701\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.
    27402702The identifiers declared by assertions that use an inferred parameter of a function declarator are \Index{assertion parameter}s of that function declarator.
    27412703
     
    27482710forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
    27492711\end{lstlisting}
    2750 Here \lstinline@alloc()@ would receive \lstinline@int@ as an inferred argument, and return an
    2751 \lstinline@int *@.
    2752 In general, if a call to \lstinline@alloc()@ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline@T@ to be bound.
    2753 
    2754 With the current restriction, \lstinline@alloc()@ must be given an argument that determines
    2755 \lstinline@T@:
     2712Here ©alloc()© would receive ©int© as an inferred argument, and return an ©int *©.
     2713In 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.
     2714
     2715With the current restriction, ©alloc()© must be given an argument that determines ©T©:
    27562716\begin{lstlisting}
    27572717forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
     
    27612721
    27622722If a function declarator is part of a function definition, its inferred parameters and assertion parameters have \Index{block scope};
    2763 otherwise, identifiers declared by assertions have a
    2764 \define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
     2723otherwise, identifiers declared by assertions have a \define{declaration scope}, which terminates at the end of the \nonterm{declaration}.
    27652724
    27662725A function type that has at least one inferred parameter is a \define{polymorphic function} type.
     
    27712730Let $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.
    27722731Let $f'$ be $f$ with every occurrence of $f_i$ replaced by $g_i$, for all $i$.
    2773 Then $f$ and $g$ are
    2774 \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.
     2732Then $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.
    27752733
    27762734\examples
     
    27802738forall( otype T ) T fT( T );
    27812739\end{lstlisting}
    2782 \lstinline@fi()@ takes an \lstinline@int@ and returns an \lstinline@int@. \lstinline@fT()@ takes a
    2783 \lstinline@T@ and returns a \lstinline@T@, for any type \lstinline@T@.
     2740©fi()© takes an ©int© and returns an ©int©. ©fT()© takes a ©T© and returns a ©T©, for any type ©T©.
    27842741\begin{lstlisting}
    27852742int (*pfi )( int ) = fi;
    27862743forall( otype T ) T (*pfT )( T ) = fT;
    27872744\end{lstlisting}
    2788 \lstinline@pfi@ and \lstinline@pfT@ are pointers to functions. \lstinline@pfT@ is not polymorphic, but the function it points at is.
     2745©pfi© and ©pfT© are pointers to functions. ©pfT© is not polymorphic, but the function it points at is.
    27892746\begin{lstlisting}
    27902747int (*fvpfi( void ))( int ) {
     
    27952752}
    27962753\end{lstlisting}
    2797 \lstinline@fvpfi()@ and \lstinline@fvpfT()@ are functions taking no arguments and returning pointers to functions. \lstinline@fvpfT()@ is monomorphic, but the function that its return value points at is polymorphic.
     2754©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.
    27982755\begin{lstlisting}
    27992756forall( otype T ) int ( *fTpfi( T ) )( int );
     
    28012758forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    28022759\end{lstlisting}
    2803 \lstinline@fTpfi()@ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
    2804 It could return \lstinline@pfi@. \lstinline@fTpfT()@ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    2805 \lstinline@T@, where \lstinline@T@ is an inferred parameter of \lstinline@fTpfT()@.
    2806 For instance, in the expression ``\lstinline@fTpfT(17)@'', \lstinline@T@ is inferred to be \lstinline@int@, and the returned value would have type \lstinline@int ( * )( int )@. ``\lstinline@fTpfT(17)(13)@'' and
    2807 ``\lstinline@fTpfT("yes")("no")@'' are legal, but ``\lstinline@fTpfT(17)("no")@'' is illegal.
    2808 \lstinline@fTpfU()@ is polymorphic ( in type \lstinline@T@), and returns a pointer to a function that is polymorphic ( in type \lstinline@U@). ``\lstinline@f5(17)("no")@'' is a legal expression of type
    2809 \lstinline@char *@.
     2760©fTpfi()© is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2761It could return ©pfi©. ©fTpfT()© is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2762©T©, where ©T© is an inferred parameter of ©fTpfT()©.
     2763For 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.
     2764©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 *©.
    28102765\begin{lstlisting}
    28112766forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    28122767forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    28132768\end{lstlisting}
    2814 The functions \lstinline@f()@ and \lstinline@g()@ have compatible types.
     2769The functions ©f()© and ©g()© have compatible types.
    28152770Let \(f\) and \(g\) be their types;
    2816 then \(f_1\) = \lstinline@T@, \(f_2\) = \lstinline@U@, \(f_3\) = \lstinline@V@, \(g_1\)
    2817 = \lstinline@V@, \(g_2\) = \lstinline@U@, and \(g_3\) = \lstinline@W@.
     2771then \(f_1\) = ©T©, \(f_2\) = ©U©, \(f_3\) = ©V©, \(g_1\)
     2772= ©V©, \(g_2\) = ©U©, and \(g_3\) = ©W©.
    28182773Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    28192774\begin{lstlisting}
     
    28212776\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    28222777\begin{rationale}
    2823 The word ``\lstinline@type@'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
     2778The 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.
    28242779
    28252780Even without parameterized types, I might try to allow
     
    28472802\subsection{Type qualifiers}
    28482803
    2849 \CFA defines a new type qualifier \lstinline@lvalue@\impl{lvalue}\index{lvalue}.
     2804\CFA defines a new type qualifier ©lvalue©\impl{lvalue}\index{lvalue}.
    28502805\begin{syntax}
    28512806\oldlhs{type-qualifier}
    2852 \rhs \lstinline@lvalue@
     2807\rhs ©lvalue©
    28532808\end{syntax}
    28542809
     
    28582813\semantics
    28592814An object's type may be a restrict-qualified type parameter.
    2860 \lstinline@restrict@ does not establish any special semantics in that case.
     2815©restrict© does not establish any special semantics in that case.
    28612816
    28622817\begin{rationale}
     
    28642819\end{rationale}
    28652820
    2866 \lstinline@lvalue@ may be used to qualify the return type of a function type.
    2867 Let \lstinline@T@ be an unqualified version of a type;
    2868 then the result of calling a function with return type
    2869 \lstinline@lvalue T@ is a \Index{modifiable lvalue} of type \lstinline@T@.
    2870 \lstinline@const@\use{const} and \lstinline@volatile@\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
    2871 \begin{rationale}
    2872 The \lstinline@const@ and \lstinline@volatile@ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline@lvalue@ qualifier is also used.
     2821©lvalue© may be used to qualify the return type of a function type.
     2822Let ©T© be an unqualified version of a type;
     2823then the result of calling a function with return type ©lvalue T© is a \Index{modifiable lvalue} of type ©T©.
     2824©const©\use{const} and ©volatile©\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     2825\begin{rationale}
     2826The ©const© and ©volatile© qualifiers can only be sensibly used to qualify the return type of a function if the ©lvalue© qualifier is also used.
    28732827\end{rationale}
    28742828
     
    28772831
    28782832\begin{rationale}
    2879 \lstinline@lvalue@ provides some of the functionality of {\CC}'s ``\lstinline@T&@'' ( reference to object of type \lstinline@T@) type.
     2833©lvalue© provides some of the functionality of {\CC}'s ``©T&©'' ( reference to object of type ©T©) type.
    28802834Reference types have four uses in {\CC}.
    28812835\begin{itemize}
     
    28842838
    28852839\item
    2886 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline@with@ statement.
     2840A 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.
    28872841The following {\CC} code gives an example.
    28882842\begin{lstlisting}
     
    28972851A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    28982852This is most useful for user-defined assignment operators.
    2899 In {\CC}, plain assignment is done by a function called ``\lstinline@operator=@'', and the two expressions
     2853In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions
    29002854\begin{lstlisting}
    29012855a = b;
    29022856operator=( a, b );
    29032857\end{lstlisting} are equivalent.
    2904 If \lstinline@a@ and \lstinline@b@ are of type \lstinline@T@, then the first parameter of \lstinline@operator=@ must have type ``\lstinline@T&@''.
    2905 It cannot have type
    2906 \lstinline@T@, because then assignment couldn't alter the variable, and it can't have type
    2907 ``\lstinline@T *@'', because the assignment would have to be written ``\lstinline@&a = b;@''.
    2908 
    2909 In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline@a = b;@'' is equivalent to
    2910 ``\lstinline@operator=(&( a), b )@''.
    2911 Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline@&@''.
     2858If ©a© and ©b© are of type ©T©, then the first parameter of ©operator=© must have type ``©T&©''.
     2859It 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;©''.
     2860
     2861In 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 )©''.
     2862Reference 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 ``©&©''.
    29122863
    29132864\item
    29142865References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    2915 {\CC} function call ``\lstinline@fiddle( a_thing )@'', where the type of \lstinline@a_thing@ is
    2916 \lstinline@Thing@, the type of \lstinline@fiddle@ could be either of
     2866{\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
     2867©Thing©, the type of ©fiddle© could be either of
    29172868\begin{lstlisting}
    29182869void fiddle( Thing );
    29192870void fiddle( const Thing & );
    29202871\end{lstlisting}
    2921 If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline@fiddle@ the parameter is subject to the usual problems caused by aliases.
    2922 The reference form might be chosen for efficiency's sake if \lstinline@Thing@s are too large or their constructors or destructors are too expensive.
     2872If 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.
     2873The reference form might be chosen for efficiency's sake if ©Thing©s are too large or their constructors or destructors are too expensive.
    29232874An implementation may switch between them without causing trouble for well-behaved clients.
    29242875This leaves the implementor to define ``too large'' and ``too expensive''.
     
    29282879void fiddle( const volatile Thing );
    29292880\end{lstlisting} with call-by-reference.
    2930 Since it knows all about the size of \lstinline@Thing@s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
     2881Since 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''.
    29312882\end{itemize}
    29322883
     
    29482899\begin{syntax}
    29492900\lhs{spec-definition}
    2950 \rhs \lstinline@spec@ \nonterm{identifier}
    2951         \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
    2952         \lstinline@{@ \nonterm{spec-declaration-list}\opt \lstinline@}@
     2901\rhs ©spec© \nonterm{identifier}
     2902        ©(© \nonterm{type-parameter-list} ©)©
     2903        ©{© \nonterm{spec-declaration-list}\opt ©}©
    29532904\lhs{spec-declaration-list}
    2954 \rhs \nonterm{spec-declaration} \lstinline@;@
    2955 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline@;@
     2905\rhs \nonterm{spec-declaration} ©;©
     2906\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} ©;©
    29562907\lhs{spec-declaration}
    29572908\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    29582909\lhs{declarator-list}
    29592910\rhs \nonterm{declarator}
    2960 \rhs \nonterm{declarator-list} \lstinline@,@ \nonterm{declarator}
     2911\rhs \nonterm{declarator-list} ©,© \nonterm{declarator}
    29612912\end{syntax}
    29622913\begin{rationale}
     
    29802931\rhs \nonterm{assertion-list} \nonterm{assertion}
    29812932\lhs{assertion}
    2982 \rhs \lstinline@|@ \nonterm{identifier} \lstinline@(@ \nonterm{type-name-list} \lstinline@)@
    2983 \rhs \lstinline@|@ \nonterm{spec-declaration}
     2933\rhs ©|© \nonterm{identifier} ©(© \nonterm{type-name-list} ©)©
     2934\rhs ©|© \nonterm{spec-declaration}
    29842935\lhs{type-name-list}
    29852936\rhs \nonterm{type-name}
    2986 \rhs \nonterm{type-name-list} \lstinline@,@ \nonterm{type-name}
     2937\rhs \nonterm{type-name-list} ©,© \nonterm{type-name}
    29872938\end{syntax}
    29882939
     
    29912942The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    29922943If the
    2993 \nonterm{type-parameter} uses type-class \lstinline@type@\use{type}, the argument shall be the type name of an \Index{object type};
    2994 if it uses \lstinline@dtype@, the argument shall be the type name of an object type or an \Index{incomplete type};
    2995 and if it uses \lstinline@ftype@, the argument shall be the type name of a \Index{function type}.
     2944\nonterm{type-parameter} uses type-class ©type©\use{type}, the argument shall be the type name of an \Index{object type};
     2945if it uses ©dtype©, the argument shall be the type name of an object type or an \Index{incomplete type};
     2946and if it uses ©ftype©, the argument shall be the type name of a \Index{function type}.
    29962947
    29972948\semantics
    2998 An \define{assertion} is a declaration of a collection of objects and functions, called
    2999 \define{assertion parameters}.
     2949An \define{assertion} is a declaration of a collection of objects and functions, called \define{assertion parameters}.
    30002950
    30012951The 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.
     
    30232973trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    30242974\end{lstlisting}
    3025 \lstinline@sum_list@ contains seven declarations, which describe a list whose elements can be added up.
    3026 The assertion ``\lstinline@|sum_list( i_list, int )@''\use{sum_list} produces the assertion parameters
     2975©sum_list© contains seven declarations, which describe a list whose elements can be added up.
     2976The assertion ``©|sum_list( i_list, int )©''\use{sum_list} produces the assertion parameters
    30272977\begin{lstlisting}
    30282978int ?+=?( int *, int );
     
    30412991\lhs{type-parameter-list}
    30422992\rhs \nonterm{type-parameter}
    3043 \rhs \nonterm{type-parameter-list} \lstinline@,@ \nonterm{type-parameter}
     2993\rhs \nonterm{type-parameter-list} ©,© \nonterm{type-parameter}
    30442994\lhs{type-parameter}
    30452995\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    30462996\lhs{type-class}
    3047 \rhs \lstinline@type@
    3048 \rhs \lstinline@dtype@
    3049 \rhs \lstinline@ftype@
     2997\rhs ©type©
     2998\rhs ©dtype©
     2999\rhs ©ftype©
    30503000\lhs{type-declaration}
    3051 \rhs \nonterm{storage-class-specifier}\opt \lstinline@type@ \nonterm{type-declarator-list} \verb|;|
     3001\rhs \nonterm{storage-class-specifier}\opt ©type© \nonterm{type-declarator-list} \verb|;|
    30523002\lhs{type-declarator-list}
    30533003\rhs \nonterm{type-declarator}
    3054 \rhs \nonterm{type-declarator-list} \lstinline@,@ \nonterm{type-declarator}
     3004\rhs \nonterm{type-declarator-list} ©,© \nonterm{type-declarator}
    30553005\lhs{type-declarator}
    3056 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline@=@ \nonterm{type-name}
     3006\rhs \nonterm{identifier} \nonterm{assertion-list}\opt ©=© \nonterm{type-name}
    30573007\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    30583008\end{syntax}
     
    30653015
    30663016An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
    3067 Identifiers declared with type-class \lstinline@type@\use{type} are \Index{object type}s;
    3068 those declared with type-class
    3069 \lstinline@dtype@\use{dtype} are \Index{incomplete type}s;
    3070 and those declared with type-class
    3071 \lstinline@ftype@\use{ftype} are \Index{function type}s.
     3017Identifiers declared with type-class ©type©\use{type} are \Index{object type}s;
     3018those declared with type-class ©dtype©\use{dtype} are \Index{incomplete type}s;
     3019and those declared with type-class ©ftype©\use{ftype} are \Index{function type}s.
    30723020The 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}.
    30733021
     
    30773025Within 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.
    30783026
    3079 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline@static@\use{static} defines an \Index{incomplete type}.
    3080 If a
    3081 \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).
     3027A 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}.
     3028If 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).
    30823029\begin{rationale}
    30833030Incomplete type declarations allow compact mutually-recursive types.
     
    30963043\end{rationale}
    30973044
    3098 A type declaration without an initializer and with \Index{storage-class specifier}
    3099 \lstinline@extern@\use{extern} is an \define{opaque type declaration}.
    3100 Opaque types are
    3101 \Index{object type}s.
     3045A type declaration without an initializer and with \Index{storage-class specifier} ©extern©\use{extern} is an \define{opaque type declaration}.
     3046Opaque types are \Index{object type}s.
    31023047An opaque type is not a \nonterm{constant-expression};
    3103 neither is a structure or union that has a member whose type is not a \nonterm{constant-expression}.  Every other
    3104 \Index{object type} is a \nonterm{constant-expression}.
     3048neither is a structure or union that has a member whose type is not a \nonterm{constant-expression}.
     3049Every other \Index{object type} is a \nonterm{constant-expression}.
    31053050Objects with static storage duration shall be declared with a type that is a \nonterm{constant-expression}.
    31063051\begin{rationale}
     
    31123057\end{rationale}
    31133058
    3114 An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline@dtype@.
    3115 An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline@type@ and \lstinline@dtype@.
    3116 A
    3117 \Index{function type} is a value of type-class \lstinline@ftype@.
     3059An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} ©dtype©.
     3060An object type\index{object types} which is not a qualified version of a type is a value of type-classes ©type© and ©dtype©.
     3061A \Index{function type} is a value of type-class ©ftype©.
    31183062\begin{rationale}
    31193063Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     
    31243068
    31253069Type qualifiers are a weak point of C's type system.
    3126 Consider the standard library function
    3127 \lstinline@strchr()@ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
     3070Consider 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.
    31283071\begin{lstlisting}
    31293072char *strchr( const char *s, int c ) {§\impl{strchr}§
     
    31343077}
    31353078\end{lstlisting}
    3136 The parameter \lstinline@s@ must be \lstinline@const char *@, because \lstinline@strchr()@ might be used to search a constant string, but the return type must be \lstinline@char *@, because the result might be used to modify a non-constant string.
    3137 Hence the body must perform a cast, and ( even worse)
    3138 \lstinline@strchr()@ provides a type-safe way to attempt to modify constant strings.
    3139 What is needed is some way to say that \lstinline@s@'s type might contain qualifiers, and the result type has exactly the same qualifiers.
     3079The 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.
     3080Hence the body must perform a cast, and ( even worse) ©strchr()© provides a type-safe way to attempt to modify constant strings.
     3081What is needed is some way to say that ©s©'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    31403082Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
    3141 Instead, overloading can be used to define \lstinline@strchr()@ for each combination of qualifiers.
     3083Instead, overloading can be used to define ©strchr()© for each combination of qualifiers.
    31423084\end{rationale}
    31433085
     
    31633105};
    31643106\end{lstlisting}
    3165 Without this restriction, \CFA might require ``module initialization'' code ( since
    3166 \lstinline@Rational@ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline@Huge@ and the translation that declares \lstinline@Rational@.
     3107Without 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©.
    31673108
    31683109A 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.
     
    31703111//  File a.c:
    31713112        extern type t1;
    3172         type t2 = struct { t1 f1; ... } // illegal
     3113        type t2 = struct { t1 f1; ... } // illegal
    31733114//  File b.c:
    31743115        extern type t2;
    3175         type t1 = struct { t2 f2; ... } // illegal
     3116        type t1 = struct { t2 f2; ... } // illegal
    31763117\end{lstlisting}
    31773118\end{rationale}
     
    31813122\nonterm{struct-declaration}, type declarations can not be structure members.
    31823123The form of
    3183 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.
     3124\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning ©type©.
    31843125Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    31853126It also side-steps the problem of type-valued expressions producing different values in different declarations.
     
    31963137#include <stdlib.h>
    31973138T * new( otype T ) { return ( T * )malloc( sizeof( T) ); };
    3198 §\ldots§ int * ip = new( int );
    3199 \end{lstlisting}
    3200 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline@T@'' in the function body refers to the parameter, but the ``\lstinline@T@'' in the return type refers to the meaning of \lstinline@T@ in the scope that contains \lstinline@new@;
     3139... int * ip = new( int );
     3140\end{lstlisting}
     3141This 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©;
    32013142it could be undefined, or a type name, or a function or variable name.
    32023143Nothing good can result from such a situation.
     
    32153156f2( v2 );
    32163157\end{lstlisting}
    3217 \lstinline@V1@ is passed by value, so \lstinline@f1()@'s assignment to \lstinline@a[0]@ does not modify v1.  \lstinline@V2@ is converted to a pointer, so \lstinline@f2()@ modifies \lstinline@v2[0]@.
     3158©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]©.
    32183159
    32193160A translation unit containing the declarations
     
    32213162extern type Complex;§\use{Complex}§ // opaque type declaration
    32223163extern float abs( Complex );§\use{abs}§
    3223 \end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline@abs@.
    3224 Some other translation unit must implement \lstinline@Complex@ and \lstinline@abs@.
     3164\end{lstlisting} can contain declarations of complex numbers, which can be passed to ©abs©.
     3165Some other translation unit must implement ©Complex© and ©abs©.
    32253166That unit might contain the declarations
    32263167\begin{lstlisting}
     
    32313172}
    32323173\end{lstlisting}
    3233 Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@ so that its components can be retrieved.
     3174Note that ©c© is implicitly converted to a ©struct© so that its components can be retrieved.
    32343175
    32353176\begin{lstlisting}
     
    32393180}
    32403181\end{lstlisting}
    3241 \lstinline@t1@ must be cast to its implementation type to prevent infinite recursion.
     3182©t1© must be cast to its implementation type to prevent infinite recursion.
    32423183
    32433184\begin{rationale}
    32443185Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
    3245 In the \lstinline@Time_of_day@ example, the difference is important.
     3186In the ©Time_of_day© example, the difference is important.
    32463187Different languages have treated the distinction between the abstraction and the implementation in different ways.
    32473188\begin{itemize}
    32483189\item
    32493190Inside a Clu cluster \cite{CLU}, the declaration of an instance states which view applies.
    3250 Two primitives called \lstinline@up@ and \lstinline@down@ can be used to convert between the views.
     3191Two primitives called ©up© and ©down© can be used to convert between the views.
    32513192\item
    32523193The Simula class \cite{SIMULA87} is essentially a record type.
    32533194Since 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.
    32543195In {\CC}
    3255 \cite{C++}, operations on class instances include assignment and ``\lstinline@&@'', which can be overloaded.
     3196\cite{C++}, operations on class instances include assignment and ``©&©'', which can be overloaded.
    32563197A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    32573198\item
     
    32663207In this case, explicit conversions between the derived type and the old type can be used.
    32673208\end{itemize}
    3268 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline@up@ and \lstinline@down@.
     3209\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©.
    32693210\end{rationale}
    32703211
     
    32723213\subsubsection{Default functions and objects}
    32733214
    3274 A declaration\index{type declaration} of a type identifier \lstinline@T@ with type-class
    3275 \lstinline@type@ implicitly declares a \define{default assignment} function
    3276 \lstinline@T ?=?( T *, T )@\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
     3215A 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©.
    32773216\begin{rationale}
    32783217Assignment 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).
    32793218Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
    3280 If a type parameter should not have an assignment operation,
    3281 \lstinline@dtype@ should be used.
     3219If a type parameter should not have an assignment operation, ©dtype© should be used.
    32823220If 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.
    32833221\end{rationale}
    32843222
    3285 A definition\index{type definition} of a type identifier \lstinline@T@ with \Index{implementation type} \lstinline@I@ and type-class \lstinline@type@ implicitly defines a default assignment function.
    3286 A definition\index{type definition} of a type identifier \lstinline@T@ with implementation type \lstinline@I@ and an assertion list implicitly defines \define{default function}s and
    3287 \define{default object}s as declared by the assertion declarations.
    3288 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
     3223A definition\index{type definition} of a type identifier ©T© with \Index{implementation type} ©I© and type-class ©type© implicitly defines a default assignment function.
     3224A 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.
     3225The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    32893226Their values are determined as follows:
    32903227\begin{itemize}
    32913228\item
    3292 If at the definition of \lstinline@T@ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default object, then the default object is initialized with that object.
    3293 Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default object.
     3229If 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.
     3230Otherwise the scope of the declaration of ©T© must contain a definition of the default object.
    32943231
    32953232\item
    3296 If at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
    3297 
    3298 Otherwise, if \lstinline@I@ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
    3299 
    3300 Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default function.
     3233If 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.
     3234
     3235Otherwise, 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.
     3236
     3237Otherwise the scope of the declaration of ©T© must contain a definition of the default function.
    33013238\end{itemize}
    33023239\begin{rationale}
     
    33043241\end{rationale}
    33053242
    3306 A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline@T@ replaces the default function or object.
     3243A 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.
    33073244
    33083245\examples
     
    33143251Pair b = { 1, 1 };
    33153252\end{lstlisting}
    3316 The definition of \lstinline@Pair@ implicitly defines two objects \lstinline@a@ and \lstinline@b@.
    3317 \lstinline@Pair a@ inherits its value from the \lstinline@struct impl a@.
    3318 The definition of
    3319 \lstinline@Pair b@ is compulsory because there is no \lstinline@struct impl b@ to construct a value from.
     3253The definition of ©Pair© implicitly defines two objects ©a© and ©b©.
     3254©Pair a© inherits its value from the ©struct impl a©.
     3255The definition of ©Pair b© is compulsory because there is no ©struct impl b© to construct a value from.
    33203256\begin{lstlisting}
    33213257trait ss( otype T ) {
     
    33303266Doodad clone( Doodad ) { ... }
    33313267\end{lstlisting}
    3332 The definition of \lstinline@Doodad@ implicitly defines three functions:
     3268The definition of ©Doodad© implicitly defines three functions:
    33333269\begin{lstlisting}
    33343270Doodad ?=?( Doodad *, Doodad );
     
    33363272void munge( Doodad * );
    33373273\end{lstlisting}
    3338 The assignment function inherits \lstinline@struct doodad@'s assignment function because the types match when \lstinline@struct doodad@ is replaced by \lstinline@Doodad@ throughout.
    3339 \lstinline@munge()@ inherits \lstinline@Whatsit@'s \lstinline@munge()@ because the types match when
    3340 \lstinline@Whatsit@ is replaced by \lstinline@Doodad@ in the parameter list. \lstinline@clone()@ does \emph{not} inherit \lstinline@Whatsit@'s \lstinline@clone()@: replacement in the parameter list yields ``\lstinline@Whatsit clone( Doodad )@'', which is not compatible with
    3341 \lstinline@Doodad@'s \lstinline@clone()@'s type.
    3342 Hence the definition of
    3343 ``\lstinline@Doodad clone( Doodad )@'' is necessary.
     3274The assignment function inherits ©struct doodad©'s assignment function because the types match when ©struct doodad©  is replaced by ©Doodad© throughout.
     3275©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.
     3276Hence the definition of ``©Doodad clone( Doodad )©'' is necessary.
    33443277
    33453278Default functions and objects are subject to the normal scope rules.
    33463279\begin{lstlisting}
    3347 otype T = §\ldots§;
    3348 T a_T = §\ldots§;               // Default assignment used.
     3280otype T = ...;
     3281T a_T = ...;            // Default assignment used.
    33493282T ?=?( T *, T );
    3350 T a_T = §\ldots§;               // Programmer-defined assignment called.
     3283T a_T = ...;            // Programmer-defined assignment called.
    33513284\end{lstlisting}
    33523285\begin{rationale}
     
    33813314\begin{syntax}
    33823315\oldlhs{labeled-statement}
    3383 \rhs \lstinline@case@ \nonterm{case-value-list} : \nonterm{statement}
     3316\rhs ©case© \nonterm{case-value-list} : \nonterm{statement}
    33843317\lhs{case-value-list}
    33853318\rhs \nonterm{case-value}
    3386 \rhs \nonterm{case-value-list} \lstinline@,@ \nonterm{case-value}
     3319\rhs \nonterm{case-value-list} ©,© \nonterm{case-value}
    33873320\lhs{case-value}
    33883321\rhs \nonterm{constant-expression}
    33893322\rhs \nonterm{subrange}
    33903323\lhs{subrange}
    3391 \rhs \nonterm{constant-expression} \lstinline@~@ \nonterm{constant-expression}
     3324\rhs \nonterm{constant-expression} ©~© \nonterm{constant-expression}
    33923325\end{syntax}
    33933326
     
    34023335case 1~4, 9~14, 27~32:
    34033336\end{lstlisting}
    3404 The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@ statements, precluding Duff's device.
     3337The ©case© and ©default© clauses are restricted within the ©switch© and ©choose© statements, precluding Duff's device.
    34053338
    34063339
    34073340\subsection{Expression and null statements}
    34083341
    3409 The expression in an expression statement is treated as being cast to \lstinline@void@.
     3342The expression in an expression statement is treated as being cast to ©void©.
    34103343
    34113344
     
    34143347\begin{syntax}
    34153348\oldlhs{selection-statement}
    3416 \rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@ \nonterm{statement}
     3349\rhs ©choose© ©(© \nonterm{expression} ©)© \nonterm{statement}
    34173350\end{syntax}
    34183351
    3419 The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@ statement:
     3352The controlling expression ©E© in the ©switch© and ©choose© statement:
    34203353\begin{lstlisting}
    34213354switch ( E ) ...
     
    34233356\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    34243357An \Index{integer promotion} is performed on the expression if necessary.
    3425 The constant expressions in \lstinline@case@ statements with the switch are converted to the promoted type.
     3358The constant expressions in ©case© statements with the switch are converted to the promoted type.
    34263359
    34273360
     
    34293362\subsubsection[The choose statement]{The \lstinline@choose@ statement}
    34303363
    3431 The \lstinline@choose@ statement is the same as the \lstinline@switch@ statement except control transfers to the end of the \lstinline@choose@ statement at a \lstinline@case@ or \lstinline@default@ labeled statement.
    3432 The \lstinline@fallthru@ statement is used to fall through to the next \lstinline@case@ or \lstinline@default@ labeled statement.
     3364The ©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.
     3365The ©fallthru© statement is used to fall through to the next ©case© or ©default© labeled statement.
    34333366The following have identical meaning:
    34343367\begin{flushleft}
     
    34553388\end{tabular}
    34563389\end{flushleft}
    3457 The \lstinline@choose@ statement addresses the problem of accidental fall-through associated with the \lstinline@switch@ statement.
     3390The ©choose© statement addresses the problem of accidental fall-through associated with the ©switch© statement.
    34583391
    34593392
    34603393\subsection{Iteration statements}
    34613394
    3462 The controlling expression \lstinline@E@ in the loops
     3395The controlling expression ©E© in the loops
    34633396\begin{lstlisting}
    34643397if ( E ) ...
    34653398while ( E ) ...
    34663399do ... while ( E );
    3467 \end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''.
     3400\end{lstlisting}
     3401is treated as ``©( int )((E)!=0)©''.
    34683402
    34693403The statement
    34703404\begin{lstlisting}
    3471 for ( a; b; c ) §\ldots§
     3405for ( a; b; c ) ...
    34723406\end{lstlisting} is treated as
    34733407\begin{lstlisting}
     
    34803414\begin{syntax}
    34813415\oldlhs{jump-statement}
    3482 \rhs \lstinline@continue@ \nonterm{identifier}\opt
    3483 \rhs \lstinline@break@ \nonterm{identifier}\opt
     3416\rhs ©continue© \nonterm{identifier}\opt
     3417\rhs ©break© \nonterm{identifier}\opt
    34843418\rhs \ldots
    3485 \rhs \lstinline@throw@ \nonterm{assignment-expression}\opt
    3486 \rhs \lstinline@throwResume@ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    3487 \lhs{at-expression} \lstinline@_At@ \nonterm{assignment-expression}
     3419\rhs ©throw© \nonterm{assignment-expression}\opt
     3420\rhs ©throwResume© \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     3421\lhs{at-expression} ©_At© \nonterm{assignment-expression}
    34883422\end{syntax}
    34893423
    3490 Labeled \lstinline@continue@ and \lstinline@break@ allow useful but restricted control-flow that reduces the need for the \lstinline@goto@ statement for exiting multiple nested control-structures.
     3424Labeled ©continue© and ©break© allow useful but restricted control-flow that reduces the need for the ©goto© statement for exiting multiple nested control-structures.
    34913425\begin{lstlisting}
    34923426L1: {                                                   // compound
     
    35173451\subsubsection[The continue statement]{The \lstinline@continue@ statement}
    35183452
    3519 The identifier in a \lstinline@continue@ statement shall name a label located on an enclosing iteration statement.
     3453The identifier in a ©continue© statement shall name a label located on an enclosing iteration statement.
    35203454
    35213455
    35223456\subsubsection[The break statement]{The \lstinline@break@ statement}
    35233457
    3524 The identifier in a \lstinline@break@ statement shall name a label located on an enclosing compound, selection or iteration statement.
     3458The identifier in a ©break© statement shall name a label located on an enclosing compound, selection or iteration statement.
    35253459
    35263460
    35273461\subsubsection[The return statement]{The \lstinline@return@ statement}
    35283462
    3529 An expression in a \lstinline@return@ statement is treated as being cast to the result type of the function.
     3463An expression in a ©return© statement is treated as being cast to the result type of the function.
    35303464
    35313465
     
    35423476\begin{syntax}
    35433477\lhs{exception-statement}
    3544 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list}
    3545 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{finally-clause}
    3546 \rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
     3478\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list}
     3479\rhs ©try© \nonterm{compound-statement} \nonterm{finally-clause}
     3480\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    35473481\lhs{handler-list}
    35483482\rhs \nonterm{handler-clause}
    3549 \rhs \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3550 \rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3551 \rhs \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    3552 \rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3483\rhs ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3484\rhs \nonterm{handler-clause} ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3485\rhs ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
     3486\rhs \nonterm{handler-clause} ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
    35533487\lhs{handler-clause}
    3554 \rhs \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3555 \rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3556 \rhs \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    3557 \rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3488\rhs ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3489\rhs \nonterm{handler-clause} ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3490\rhs ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3491\rhs \nonterm{handler-clause} ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    35583492\lhs{finally-clause}
    3559 \rhs \lstinline@finally@ \nonterm{compound-statement}
     3493\rhs ©finally© \nonterm{compound-statement}
    35603494\lhs{exception-declaration}
    35613495\rhs \nonterm{type-specifier}
     
    35653499\rhs \nonterm{new-abstract-declarator-tuple}
    35663500\lhs{asynchronous-statement}
    3567 \rhs \lstinline@enable@ \nonterm{identifier-list} \nonterm{compound-statement}
    3568 \rhs \lstinline@disable@ \nonterm{identifier-list} \nonterm{compound-statement}
     3501\rhs ©enable© \nonterm{identifier-list} \nonterm{compound-statement}
     3502\rhs ©disable© \nonterm{identifier-list} \nonterm{compound-statement}
    35693503\end{syntax}
    35703504
     
    35743508\subsubsection[The try statement]{The \lstinline@try@ statement}
    35753509
    3576 The \lstinline@try@ statement is a block with associated handlers, called a \Index{guarded block};
     3510The ©try© statement is a block with associated handlers, called a \Index{guarded block};
    35773511all other blocks are \Index{unguarded block}s.
    3578 A \lstinline@goto@, \lstinline@break@, \lstinline@return@, or \lstinline@continue@ statement can be used to transfer control out of a try block or handler, but not into one.
     3512A ©goto©, ©break©, ©return©, or ©continue© statement can be used to transfer control out of a try block or handler, but not into one.
    35793513
    35803514
    35813515\subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
    35823516
    3583 The \lstinline@enable@/\lstinline@disable@ statements toggle delivery of \Index{asynchronous exception}s.
     3517The ©enable©/©disable© statements toggle delivery of \Index{asynchronous exception}s.
    35843518
    35853519
     
    35913525\subsection{Predefined macro names}
    35923526
    3593 The implementation shall define the macro names \lstinline@__LINE__@, \lstinline@__FILE__@,
    3594 \lstinline@__DATE__@, and \lstinline@__TIME__@, as in the {\c11} standard.
    3595 It shall not define the macro name \lstinline@__STDC__@.
    3596 
    3597 In addition, the implementation shall define the macro name \lstinline@__CFORALL__@ to be the decimal constant 1.
     3527The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard.
     3528It shall not define the macro name ©__STDC__©.
     3529
     3530In addition, the implementation shall define the macro name ©__CFORALL__© to be the decimal constant 1.
    35983531
    35993532
     
    36123545The pointer, integral, and floating-point types are all \define{scalar types}.
    36133546All of these types can be logically negated and compared.
    3614 The assertion ``\lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@ is scalar''.
     3547The assertion ``©scalar( Complex )©'' should be read as ``type ©Complex© is scalar''.
    36153548\begin{lstlisting}
    36163549trait scalar( otype T ) {§\impl{scalar}§
     
    36303563\end{lstlisting}
    36313564
    3632 The various flavors of \lstinline@char@ and \lstinline@int@ and the enumerated types make up the
    3633 \define{integral types}.
     3565The various flavors of ©char© and ©int© and the enumerated types make up the \define{integral types}.
    36343566\begin{lstlisting}
    36353567trait integral( otype T | arithmetic( T ) ) {§\impl{integral}§§\use{arithmetic}§
     
    36643596
    36653597Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3666 Note that this results in the ``inheritance'' of \lstinline@scalar@ along both paths.
     3598Note that this results in the ``inheritance'' of ©scalar© along both paths.
    36673599\begin{lstlisting}
    36683600trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
     
    36793611\subsection{Pointer and array types}
    36803612
    3681 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
    3682 ``\lstinline@a[i]@'' is equivalent to the dereferencing expression ``\lstinline@(*( a+( i )))@''.
    3683 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline@==@'' and
    3684 ``\lstinline@!=@'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
     3613Array 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 )))©''.
     3614Technically, 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.
    36853615Consequently, there is no need for a separate ``array type'' specification.
    36863616
    36873617Pointer types are scalar types.
    3688 Like other scalar types, they have ``\lstinline@+@'' and
    3689 ``\lstinline@-@'' operators, but the types do not match the types of the operations in
    3690 \lstinline@arithmetic@, so these operators cannot be consolidated in \lstinline@scalar@.
     3618Like 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©.
    36913619\begin{lstlisting}
    36923620trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
     
    37033631Specifications 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.
    37043632Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
    3705 The assertion ``\lstinline@|ptr_to( Safe_pointer, int )@'' should be read as
    3706 ``\lstinline@Safe_pointer@ acts like a pointer to \lstinline@int@''.
     3633The assertion ``©|ptr_to( Safe_pointer, int )©'' should be read as ``©Safe_pointer© acts like a pointer to ©int©''.
    37073634\begin{lstlisting}
    37083635trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
     
    37243651\end{lstlisting}
    37253652
    3726 Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline@T *@'' can be assigned to a ``\lstinline@const T *@'', a ``\lstinline@volatile T *@'', and a ``\lstinline@const volatile T *@''.
    3727 Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    3728 ``\lstinline@ptr_to@'' specifications.
     3653Assignment 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 *©''.
     3654Again, the pointed-at type is passed in, so that assertions can connect these specifications to the ``©ptr_to©'' specifications.
    37293655\begin{lstlisting}
    37303656trait 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}§ {
     
    37553681};
    37563682\end{lstlisting}
    3757 The assertion ``\lstinline@| m_l_ptr_like( Safe_ptr, const int * )@'' should be read as
    3758 ``\lstinline@Safe_ptr@ is a pointer type like \lstinline@const int *@''.
    3759 This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a
    3760 \lstinline@MyP@ produces an lvalue of the type that \lstinline@CP@ points at, and the
    3761 ``\lstinline@|m_l_pointer( CP )@'' assertion provides only a weak assurance that the argument passed to \lstinline@CP@ really is a pointer type.
     3683The assertion ``©| m_l_ptr_like( Safe_ptr, const int * )©'' should be read as ``©Safe_ptr© is a pointer type like ©const int *©''.
     3684This 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.
    37623685
    37633686
     
    37653688
    37663689Different operators often have related meanings;
    3767 for instance, in C, ``\lstinline@+@'',
    3768 ``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition.
     3690for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition.
    37693691Languages 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.
    37703692Completeness and consistency is left to the good taste and discretion of the programmer.
     
    37793701The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    37803702However, 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;
    3781 the library function \lstinline@strcmp@ is an example.
    3782 
    3783 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline@!@'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
     3703the library function ©strcmp© is an example.
     3704
     3705C and \CFA have an extra, non-obvious comparison operator: ``©!©'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    37843706\begin{lstlisting}
    37853707trait comparable( otype T ) {
     
    38293751\end{lstlisting}
    38303752
    3831 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
    3832 \lstinline@int_base@, \lstinline@arith_base@ and \lstinline@comparable@.
     3753Note 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©.
    38333754Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
    3834 A truly minimal implementation of an arithmetic type might only provide \lstinline@0@, \lstinline@1@, and \lstinline@?-=?@, which would be used by polymorphic \lstinline@?+=?@, \lstinline@?*=?@, and \lstinline@?/=?@ functions.
    3835 
    3836 Note also that \lstinline@short@ is an integer type in C11 terms, but has no operations!
     3755A truly minimal implementation of an arithmetic type might only provide ©0©, ©1©, and ©?-=?©, which would be used by polymorphic ©?+=?©, ©?*=?©, and ©?/=?© functions.
     3756
     3757Note also that ©short© is an integer type in C11 terms, but has no operations!
    38373758
    38383759
     
    38413762
    38423763Restrict allowed to qualify anything, or type/dtype parameters, but only affects pointers.
    3843 This gets into \lstinline@noalias@ territory.
    3844 Qualifying anything (``\lstinline@short restrict rs@'') means pointer parameters of \lstinline@?++@, etc, would need restrict qualifiers.
     3764This gets into ©noalias© territory.
     3765Qualifying anything (``©short restrict rs©'') means pointer parameters of ©?++©, etc, would need restrict qualifiers.
    38453766
    38463767Enumerated types.
     
    38523773Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    38533774
    3854 Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@ harmless;
     3775Operators on {,signed,unsigned} char and other small types. ©?<?© harmless;
    38553776?*? questionable for chars.
    38563777Generic selections make these choices visible.
    3857 Safe conversion operators? Predefined
    3858 ``promotion'' function?
    3859 
    3860 \lstinline@register@ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
    3861 
    3862 Don't use \lstinline@ptrdiff_t@ by name in the predefineds.
     3778Safe conversion operators? Predefined ``promotion'' function?
     3779
     3780©register© assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
     3781
     3782Don't use ©ptrdiff_t© by name in the predefineds.
    38633783
    38643784Polymorphic objects.
  • doc/user/user.tex

    r1048b31 r1b7ea43  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Apr 30 13:54:32 2016
    14 %% Update Count     : 221
     13%% Last Modified On : Tue May  3 08:05:33 2016
     14%% Update Count     : 246
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    1717% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    1818
    19 % red highlighting ®...® (registered trademark sumbol)
    20 % blue highlighting ©...© (copyright symbol)
    21 % latex escape §...§ (section symbol)
    22 % keyword escape ¶...¶ (pilcrow symbol)
     19% inline code ©...© (copyright symbol) emacs: C-q M-)
     20% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
     21% latex escape §...§ (section symbol) emacs: C-q M-'
     22% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    2323% math escape $...$ (dollar symbol)
    2424
     
    180180\CC~\cite{c++,ANSI14:C++} is an example of a similar project;
    181181however, it largely extended the language, and did not address existing problems.\footnote{%
    182 Two important existing problems addressed were changing the type of character literals from \lstinline@int@ to \lstinline@char@ and enumerator from \lstinline@int@ to the type of its enumerators.}
     182Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
    183183Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features are added and problems fixed within the framework of the existing language.
    184184Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
     
    205205
    206206However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
    207 For example, the C math-library provides the following routines for computing the absolute value of the basic type: \lstinline@abs@, \lstinline@labs@, \lstinline@llabs@, \lstinline@fabs@, \lstinline@fabsf@, \lstinline@fabsl@, \lstinline@cabsf@, \lstinline@cabs@, and \lstinline@cabsl@.
    208 Whereas, \CFA wraps each of these routines into one with the common name \lstinline@abs@.
     207For example, the C math-library provides the following routines for computing the absolute value of the basic type: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
     208Whereas, \CFA wraps each of these routines into one with the common name ©abs©.
    209209\begin{lstlisting}
    210210char abs( char );
     
    221221long double _Complex abs( long double _Complex );
    222222\end{lstlisting}
    223 The problem is the name clash between the library routine \lstinline@abs@ and the \CFA names \lstinline@abs@.
    224 Hence, names appearing in an \lstinline@extern "C"@ block have \newterm{C linkage}.
     223The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
     224Hence, names appearing in an ©extern "C"© block have \newterm{C linkage}.
    225225Then overloading polymorphism uses a mechanism called \newterm{name mangling} to create unique names that are different from C names, which are not mangled.
    226226Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
    227227There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
    228228This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
    229 The name ``\lstinline@abs@'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
    230 Hence, knowing the name \lstinline@abs@ should be sufficient to apply it to any type where it is applicable.
     229The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
     230Hence, knowing the name ©abs© should be sufficient to apply it to any type where it is applicable.
    231231The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
    232232
     
    234234\section[Compiling CFA Program]{Compiling \CFA Program}
    235235
    236 The command \lstinline@cfa@ is used to compile \CFA program(s).
    237 This command works like the GNU \lstinline@gcc@\index{gcc} command, e.g.:
    238 \begin{lstlisting}
    239 cfa [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    240 \end{lstlisting}
    241 \indexc{cfa}\index{compilation!cfa@\lstinline$cfa$}
    242 By default, \CFA programs having the following \lstinline@gcc@ flags turned on:
     236The command ©cfa© is used to compile \CFA program(s).
     237This command works like the GNU ©gcc©\index{gcc} command, e.g.:
     238\begin{lstlisting}
     239cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
     240\end{lstlisting}
     241By default, \CFA programs having the following ©gcc© flags turned on:
    243242\begin{description}
    244 \item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{\lstinline$-std=gnu99$}}
     243\item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
    245244The 1999 C standard plus GNU extensions.
    246 \item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{\lstinline$-fgnu89-¶inline¶$}}
     245\item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
    247246Use the traditional GNU semantics for inline routines in C99 mode.
    248247\end{description}
    249248The following new \CFA option is available:
    250249\begin{description}
    251 \item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{\lstinline$-CFA$}}
     250\item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{©-CFA©}}
    252251Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
    253252\end{description}
     
    255254The following preprocessor variables are available:
    256255\begin{description}
    257 \item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{\lstinline$__CFA__$}}
     256\item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
    258257is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
    259258The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
    260259Hence, the need to have three variables for the major, minor and patch version number.}
    261260
    262 \item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{\lstinline$__CFA_MINOR__$}}
     261\item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
    263262is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
    264263
    265 \item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@\lstinline$__CFA_PATCH__$}
     264\item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
    266265is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
    267266
    268 \item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@\lstinline$__CFORALL__$}
     267\item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
    269268is always available during preprocessing and it has no value.
    270269\end{description}
     
    279278#endif
    280279\end{lstlisting}
    281 which conditionally includes the correct header file, if the program is compiled using \lstinline@gcc@ or \lstinline@cfa@.
     280which conditionally includes the correct header file, if the program is compiled using ©gcc© or ©cfa©.
    282281
    283282
     
    300299\begin{enumerate}
    301300\item
    302 A sequence of underscores is disallowed, e.g., \lstinline@12__34@ is invalid.
     301A sequence of underscores is disallowed, e.g., ©12__34© is invalid.
    303302\item
    304303Underscores may only appear within a sequence of digits (regardless of the digit radix).
    305 In other words, an underscore cannot start or end a sequence of digits, e.g., \lstinline@_1@, \lstinline@1_@ and \lstinline@_1_@ are invalid (actually, the 1st and 3rd examples are identifier names).
     304In other words, an underscore cannot start or end a sequence of digits, e.g., ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
    306305\item
    307306A numeric prefix may end with an underscore;
    308307a numeric infix may begin and/or end with an underscore;
    309308a numeric suffix may begin with an underscore.
    310 For example, the octal \lstinline@0@ or hexadecimal \lstinline@0x@ prefix may end with an underscore \lstinline@0_377@ or \lstinline@0x_ff@;
    311 the exponent infix \lstinline@E@ may start or end with an underscore \lstinline@1.0_E10@, \lstinline@1.0E_10@ or \lstinline@1.0_E_10@;
    312 the type suffixes \lstinline@U@, \lstinline@L@, etc. may start with an underscore \lstinline@1_U@, \lstinline@1_ll@ or \lstinline@1.0E10_f@.
     309For example, the octal ©0© or hexadecimal ©0x© prefix may end with an underscore ©0_377© or ©0x_ff©;
     310the exponent infix ©E© may start or end with an underscore ©1.0_E10©, ©1.0E_10© or ©1.0_E_10©;
     311the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
    313312\end{enumerate}
    314313It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
     
    345344C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
    346345
    347 In \CFA declarations, the same tokens are used as in C: the character \lstinline@*@ is used to indicate a pointer, square brackets \lstinline@[@\,\lstinline@]@ are used to represent an array, and parentheses \lstinline@()@ are used to indicate a routine parameter.
     346In \CFA declarations, the same tokens are used as in C: the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array, and parentheses ©()© are used to indicate a routine parameter.
    348347However, unlike C, \CFA type declaration tokens are specified from left to right and the entire type specification is distributed across all variables in the declaration list.
    349 For instance, variables \lstinline@x@ and \lstinline@y@ of type pointer to integer are defined in \CFA as follows:
     348For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows:
    350349\begin{quote2}
    351350\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
     
    399398\end{quote2}
    400399
    401 All type qualifiers, i.e., \lstinline@const@ and \lstinline@volatile@, are used in the normal way with the new declarations but appear left to right, e.g.:
     400All type qualifiers, i.e., ©const© and ©volatile©, are used in the normal way with the new declarations but appear left to right, e.g.:
    402401\begin{quote2}
    403402\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
     
    419418\end{tabular}
    420419\end{quote2}
    421 All declaration qualifiers, i.e., \lstinline@extern@, \lstinline@static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
     420All declaration qualifiers, i.e., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
    422421The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
    423422\begin{quote2}
     
    441440\end{quote2}
    442441
    443 Unsupported are K\&R C declarations where the base type defaults to \lstinline@int@, if no type is specified\footnote{
     442Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified\footnote{
    444443At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}},
    445444e.g.:
     
    458457\section{Type Operators}
    459458
    460 The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine \lstinline@sizeof@:
     459The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
    461460\begin{quote2}
    462461\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
     
    484483}
    485484\end{lstlisting}
    486 where routine \lstinline@f@ has three output (return values) and three input parameters.
     485where routine ©f© has three output (return values) and three input parameters.
    487486Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
    488487
    489 In detail, the brackets, \lstinline@[]@, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
     488In detail, the brackets, ©[]©, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
    490489Michael Tiemann, with help from Doug Lea, provided named return values in g++, circa 1989.}
    491490The value of each local return variable is automatically returned at routine termination.
     
    511510int (*f(x))[ 5 ] int x; {}
    512511\end{lstlisting}
    513 The string ``\lstinline@int (*f(x))[ 5 ]@'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``\lstinline@[ 5 ] int x@'' declares a \CFA style parameter x of type array of 5 integers.
    514 Since the strings overlap starting with the open bracket, \lstinline@[@, there is an ambiguous interpretation for the string.
     512The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers.
     513Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
    515514As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
    516515\begin{lstlisting}
     
    518517int f( int (* foo) );           // foo is redefined as a parameter name
    519518\end{lstlisting}
    520 The string ``\lstinline@int (* foo)@'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
    521 The redefinition of a type name in a parameter list is the only context in C where the character \lstinline@*@ can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
     519The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
     520The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
    522521The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
    523522
     
    538537\subsection{Returning Values}
    539538
    540 Named return values handle the case where it is necessary to define a local variable whose value is then returned in a \lstinline@return@ statement, as in:
     539Named return values handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
    541540\begin{lstlisting}
    542541int f() {
     
    546545}
    547546\end{lstlisting}
    548 Because the value in the return variable is automatically returned when a \CFA routine terminates, the \lstinline@return@ statement \emph{does not} contain an expression, as in:
     547Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
    549548\begin{lstlisting}
    550549®[ int x ]® f() {
     
    553552}
    554553\end{lstlisting}
    555 When the return is encountered, the current value of \lstinline@x@ is returned to the calling routine.
    556 As well, ``falling off the end'' of a routine without a \lstinline@return@ statement is permitted, as in:
     554When the return is encountered, the current value of ©x© is returned to the calling routine.
     555As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
    557556\begin{lstlisting}
    558557[ int x ] f() {
     
    560559} // implicitly return x
    561560\end{lstlisting}
    562 In this case, the current value of \lstinline@x@ is returned to the calling routine just as if a \lstinline@return@ had been encountered.
     561In this case, the current value of ©x© is returned to the calling routine just as if a ©return© had been encountered.
    563562
    564563
     
    836835\end{tabular}
    837836\end{quote2}
    838 In the left example in C, types \lstinline@C@, \lstinline@U@ and \lstinline@T@ are implicitly hoisted outside of type \lstinline@S@ into the containing block scope.
    839 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``\lstinline@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``\lstinline@::@''.
     837In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
     838In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does Java, rather than the \CC type-selection operator ``©::©''.
    840839
    841840
     
    862861Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks;
    863862the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program.
    864 The following program in undefined in \CFA (and \lstinline@gcc@\index{gcc})
     863The following program in undefined in \CFA (and ©gcc©\index{gcc})
    865864\begin{lstlisting}
    866865[* [int]( int )] foo() {                // int (*foo())( int )
     
    891890[ §\emph{exprlist}§ ]
    892891\end{lstlisting}
    893 where \lstinline@$\emph{exprlist}$@ is a list of one or more expressions separated by commas.
    894 The brackets, \lstinline$[]$, allow differentiating between tuples and expressions containing the C comma operator.
     892where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
     893The brackets, ©[]©, allow differentiating between tuples and expressions containing the C comma operator.
    895894The following are examples of tuples:
    896895\begin{lstlisting}
     
    899898[ v+w, x*y, 3.14159, f() ]
    900899\end{lstlisting}
    901 Tuples are permitted to contain sub-tuples (i.e., nesting), such as \lstinline@[ [ 14, 21 ], 9 ]@, which is a 2-element tuple whose first element is itself a tuple.
     900Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
    902901Note, a tuple is not a record (structure);
    903902a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
     
    911910[ §\emph{typelist}§ ]
    912911\end{lstlisting}
    913 where \lstinline@$\emph{typelist}$@ is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
     912where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
    914913Examples of tuple types include:
    915914\begin{lstlisting}
     
    919918[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
    920919\end{lstlisting}
    921 Like tuples, tuple types may be nested, such as \lstinline@[ [ int, int ], int ]@, which is a 2-element tuple type whose first element is itself a tuple type.
     920Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type.
    922921
    923922Examples of declarations using tuple types are:
     
    955954tuple does not have structure like a record; a tuple is simply converted into a list of components.
    956955\begin{rationale}
    957 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as \lstinline@g( f() )@ is not supported.
     956The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e., a statement such as ©g( f() )© is not supported.
    958957Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
    959958\end{rationale}
     
    984983\begin{rationale}
    985984Unfortunately, C's syntax for subscripts precluded treating them as tuples.
    986 The C subscript list has the form \lstinline@[i][j]...@ and not \lstinline@i, j, ...]@.
    987 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., \lstinline@f[g()]@ always means a single subscript value because there is only one set of brackets.
    988 Fixing this requires a major change to C because the syntactic form \lstinline@M[i, j, k]@ already has a particular meaning: \lstinline@i, j, k@ is a comma expression.
     985The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
     986Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g., ©f[g()]© always means a single subscript value because there is only one set of brackets.
     987Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
    989988\end{rationale}
    990989
     
    10051004[ a, b, c, d ] = w
    10061005\end{lstlisting}
    1007 \lstinline@w@ is implicitly opened to yield a tuple of four values, which are then assigned individually.
     1006©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
    10081007
    10091008A \newterm{flattening coercion} coerces a nested tuple, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
     
    10131012First the right-hand tuple is flattened and then the values are assigned individually.
    10141013Flattening is also performed on tuple types.
    1015 For example, the type \lstinline@[ int, [ int, int ], int ]@ can be coerced, using flattening, into the type \lstinline@[ int, int, int, int ]@.
     1014For example, the type ©[ int, [ int, int ], int ]© can be coerced, using flattening, into the type ©[ int, int, int, int ]©.
    10161015
    10171016A \newterm{structuring coercion} is the opposite of flattening;
    10181017a tuple is structured into a more complex nested tuple.
    1019 For example, structuring the tuple \lstinline@[ 1, 2, 3, 4 ]@ into the tuple \lstinline@[ 1, [ 2, 3 ], 4 ]@ or the tuple type \lstinline@[ int, int, int, int ]@ into the tuple type \lstinline@[ int, [ int, int ], int ]@.
     1018For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
    10201019In the following example, the last assignment illustrates all the tuple coercions:
    10211020\begin{lstlisting}
     
    10251024\end{lstlisting}
    10261025Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
    1027 therefore, the right-hand tuple is now the tuple \lstinline@[ [ 1, 2, 3, 4 ], 5 ]@.
    1028 This tuple is then flattened, yielding \lstinline@[ 1, 2, 3, 4, 5 ]@, which is structured into \lstinline@[ 1, [ 2, 3, 4, 5 ] ]@ to match the tuple type of the left-hand side.
    1029 The tuple \lstinline@[ 2, 3, 4, 5 ]@ is then closed to create a tuple value.
    1030 Finally, \lstinline@x@ is assigned \lstinline@1@ and \lstinline@w@ is assigned the tuple value using multiple assignment (see Section 14).
     1026therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
     1027This tuple is then flattened, yielding ©[ 1, 2, 3, 4, 5 ]©, which is structured into ©[ 1, [ 2, 3, 4, 5 ] ]© to match the tuple type of the left-hand side.
     1028The tuple ©[ 2, 3, 4, 5 ]© is then closed to create a tuple value.
     1029Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using multiple assignment (see Section 14).
    10311030\begin{rationale}
    10321031A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
     
    10421041\end{lstlisting}
    10431042The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement.
    1044 \lstinline@$\emph{expr}$@ is any standard arithmetic expression.
     1043©$\emph{expr}$© is any standard arithmetic expression.
    10451044Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
    10461045
     
    10681067*a1 = t; *a2 = t; *a3 = t;
    10691068\end{lstlisting}
    1070 The temporary \lstinline@t@ is necessary to store the value of the expression to eliminate conversion issues.
     1069The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
    10711070The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
    1072 In this case, \lstinline@y[i]@ uses the previous value of \lstinline@i@ and not the new value set at the beginning of the mass assignment.
     1071In this case, ©y[i]© uses the previous value of ©i© and not the new value set at the beginning of the mass assignment.
    10731072
    10741073
     
    10861085[ x, y, z ] = [ 1, 2, 3 ];
    10871086\end{lstlisting}
    1088 Here, the values \lstinline@1@, \lstinline@2@ and \lstinline@3@ are assigned, respectively, to the variables \lstinline@x@, \lstinline@y@ and \lstinline@z@.
     1087Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
    10891088 A more complex example is:
    10901089\begin{lstlisting}
    10911090[ i, y[ i ], z ] = [ 1, i, a + b ];
    10921091\end{lstlisting}
    1093 Here, the values \lstinline@1@, \lstinline@i@ and \lstinline@a + b@ are assigned to the variables \lstinline@i@, \lstinline@y[i]@ and \lstinline@z@, respectively.
     1092Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
    10941093 Note, the parallel semantics of
    10951094multiple assignment ensures:
     
    10971096[ x, y ] = [ y, x ];
    10981097\end{lstlisting}
    1099 correctly interchanges (swaps) the values stored in \lstinline@x@ and \lstinline@y@.
     1098correctly interchanges (swaps) the values stored in ©x© and ©y©.
    11001099The following cases are errors:
    11011100\begin{lstlisting}
     
    11391138§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
    11401139\end{lstlisting}
    1141 \emph{expr} is any expression yielding a value of type record, e.g., \lstinline@struct@, \lstinline@union@.
     1140\emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©.
    11421141Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    11431142A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
     
    11551154also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
    11561155
    1157 If a field of a \lstinline@struct@ is itself another \lstinline@struct@, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
     1156If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
    11581157\begin{lstlisting}
    11591158struct inner {
     
    11721171\section{Labelled Break/Continue}
    11731172
    1174 While C provides \lstinline@break@ and \lstinline@continue@ statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    1175 Unfortunately, this restriction forces programmers to use \lstinline@goto@ to achieve the equivalent for more than one level of nesting.
    1176 To prevent having to make this switch, the \lstinline@break@ and \lstinline@continue@ are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
    1177 For the labelled \lstinline@break@, it is possible to specify which control structure is the target for exit, as in:
     1173While C provides ©break© and ©continue© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
     1174Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent for more than one level of nesting.
     1175To prevent having to make this switch, the ©break© and ©continue© are extended with a target label to support static multi-level exit~\cite{Buhr85,Java}.
     1176For the labelled ©break©, it is possible to specify which control structure is the target for exit, as in:
    11781177\begin{quote2}
    11791178\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
     
    12051204\end{quote2}
    12061205The inner most loop has three exit points, which cause termination of one or more of the three nested loops, respectively.
    1207 For the labelled \lstinline@continue@, it is possible to specify which control structure is the target for the next loop iteration, as in:
     1206For the labelled ©continue©, it is possible to specify which control structure is the target for the next loop iteration, as in:
    12081207\begin{quote2}
    12091208\begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
     
    12411240\end{quote2}
    12421241The inner most loop has three restart points, which cause the next loop iteration to begin, respectively.
    1243 For both \lstinline@break@ and \lstinline@continue@, the target label must be directly associated with a \lstinline@for@, \lstinline@while@ or \lstinline@do@ statement;
    1244 for \lstinline@break@, the target label can also be associated with a \lstinline@switch@ statement.
    1245 Both \lstinline@break@ and \lstinline@continue@ with target labels are simply a \lstinline@goto@ restricted in the following ways:
     1242For both ©break© and ©continue©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
     1243for ©break©, the target label can also be associated with a ©switch© statement.
     1244Both ©break© and ©continue© with target labels are simply a ©goto© restricted in the following ways:
    12461245\begin{itemize}
    12471246\item
     
    12521251Since they always transfers out of containing control structures, they cannot be used to branch into a control structure.
    12531252\end{itemize}
    1254 The advantage of the labelled \lstinline@break@/\lstinline@continue@ is that it allows static multi-level exits without having to use the \lstinline@goto@ statement and ties control flow to the target control structure rather than an arbitrary point in a program.
     1253The advantage of the labelled ©break©/©continue© is that it allows static multi-level exits without having to use the ©goto© statement and ties control flow to the target control structure rather than an arbitrary point in a program.
    12551254Furthermore, the location of the label at the beginning of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
    1256 With \lstinline@goto@, the label at the end of the control structure fails to convey this important clue early enough to the reader.
     1255With ©goto©, the label at the end of the control structure fails to convey this important clue early enough to the reader.
    12571256Finally, using an explicit target for the transfer instead of an implicit target allows new nested loop or switch constructs to be added or removed without affecting other constructs.
    1258 The implicit targets of the current \lstinline@break@ and \lstinline@continue@, i.e., the closest enclosing loop or \lstinline@switch@, change as certain constructs are added or removed.
     1257The implicit targets of the current ©break© and ©continue©, i.e., the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
    12591258
    12601259
    12611260\section{Switch Statement}
    12621261
    1263 C allows a number of questionable forms for the \lstinline@switch@ statement:
     1262C allows a number of questionable forms for the ©switch© statement:
    12641263\begin{enumerate}
    12651264\item
    1266 By default, the end of a \lstinline@case@ clause\footnote{
    1267 In this section, the term \emph{case clause} refers to either a \lstinline@case@ or \lstinline@default@ clause.}
    1268 \emph{falls through} to the next \lstinline@case@ clause in the \lstinline@switch@ statement;
    1269 to exit a \lstinline@switch@ statement from a \lstinline@case@ clause requires explicitly terminating the clause with a transfer statement, most commonly \lstinline@break@, as in:
     1265By default, the end of a ©case© clause\footnote{
     1266In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
     1267\emph{falls through} to the next ©case© clause in the ©switch© statement;
     1268to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©, as in:
    12701269\begin{lstlisting}
    12711270switch ( i ) {
     
    12921291\end{lstlisting}
    12931292In this example, case 2 is always done if case 3 is done.
    1294 This control flow is difficult to simulate with if statements or a \lstinline@switch@ statement without fall-through as code must be duplicated or placed in a separate routine.
     1293This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
    12951294C also uses fall-through to handle multiple case-values resulting in the same action, as in:
    12961295\begin{lstlisting}
     
    13051304\end{lstlisting}
    13061305However, this situation is handled in other languages without fall-through by allowing a list of case values.
    1307 While fall-through itself is not a problem, the problem occurs when fall-through is the \lstinline@default@, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a \lstinline@switch@ statement.
    1308 Hence, \lstinline@default@ fall-through semantics results in a large number of programming errors as programmers often forget the \lstinline@break@ statement at the end of a \lstinline@case@ clause, resulting in inadvertent fall-through.
    1309 
    1310 \item
    1311 It is possible to place \lstinline@case@ clauses on statements nested \emph{within} the body of the \lstinline@switch@ statement, as in:
     1306While fall-through itself is not a problem, the problem occurs when fall-through is the ©default©, as this semantics is not intuitive to most programmers and is different from virtually all other programming languages with a ©switch© statement.
     1307Hence, ©default© fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
     1308
     1309\item
     1310It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement, as in:
    13121311\begin{lstlisting}
    13131312switch ( i ) {
     
    13501349}
    13511350\end{lstlisting}
    1352 which unrolls a loop N times (N = 8 above) and uses the \lstinline@switch@ statement to deal with any iterations not a multiple of N.
     1351which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    13531352While efficient, this sort of special purpose usage is questionable:
    13541353\begin{quote}
     
    13571356\end{quote}
    13581357\item
    1359 It is possible to place the \lstinline@default@ clause anywhere in the list of labelled clauses for a \lstinline@switch@ statement, rather than only at the end.
    1360 Virtually all programming languages with a \lstinline@switch@ statement require the \lstinline@default@ clause to appear last in the case-clause list.
    1361 The logic for this semantics is that after checking all the \lstinline@case@ clauses without success, the \lstinline@default@ clause is selected;
    1362 hence, physically placing the \lstinline@default@ clause at the end of the \lstinline@case@ clause list matches with this semantics.
    1363 This physical placement can be compared to the physical placement of an \lstinline@else@ clause at the end of a series of connected \lstinline@if@/\lstinline@else@ statements.
    1364 
    1365 \item
    1366 It is possible to place unreachable code at the start of a \lstinline@switch@ statement, as in:
     1358It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
     1359Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     1360The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
     1361hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     1362This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
     1363
     1364\item
     1365It is possible to place unreachable code at the start of a ©switch© statement, as in:
    13671366\begin{lstlisting}
    13681367switch ( x ) {
     
    13741373}
    13751374\end{lstlisting}
    1376 While the declaration of the local variable \lstinline@y@ is useful and its scope is across all \lstinline@case@ clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
    1377 Furthermore, any statements before the first \lstinline@case@ clause can only be executed if labelled and transfered to using a \lstinline@goto@, either from outside or inside of the \lstinline@switch@.
     1375While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
     1376Furthermore, any statements before the first ©case© clause can only be executed if labelled and transfered to using a ©goto©, either from outside or inside of the ©switch©.
    13781377As mentioned, transfer into control structures should be forbidden.
    1379 Transfers from within the \lstinline@switch@ body using a \lstinline@goto@ are equally unpalatable.
     1378Transfers from within the ©switch© body using a ©goto© are equally unpalatable.
    13801379\end{enumerate}
    13811380Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
    13821381\begin{itemize}
    13831382\item
    1384 the number of \lstinline@switch@ statements is small,
    1385 \item
    1386 most \lstinline@switch@ statements are well formed (i.e., no Duff's device),
    1387 \item
    1388 the \lstinline@default@ clause is usually written as the last case-clause,
    1389 \item
    1390 and there is only a medium amount of fall-through from one \lstinline@case@ clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
     1383the number of ©switch© statements is small,
     1384\item
     1385most ©switch© statements are well formed (i.e., no Duff's device),
     1386\item
     1387the ©default© clause is usually written as the last case-clause,
     1388\item
     1389and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
    13911390\end{itemize}
    13921391These observations should help to put the effects of suggested changes into perspective.
     
    13941393\begin{enumerate}
    13951394\item
    1396 Eliminating the \lstinline@default@ fall-through problem has the greatest potential for affecting existing code.
    1397 However, even if fall-through is removed, most \lstinline@switch@ statements would continue to work because of the explicit transfers already present at the end of each \lstinline@case@ clause, and the common placement of the \lstinline@default@ clause at the end of the case list.
    1398 In addition, the above grammar provides for the most common use of fall-through, i.e., a list of \lstinline@case@ clauses executing common code, e.g.:
     1395Eliminating the ©default© fall-through problem has the greatest potential for affecting existing code.
     1396However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, and the common placement of the ©default© clause at the end of the case list.
     1397In addition, the above grammar provides for the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.:
    13991398\begin{lstlisting}
    14001399case 1:  case 2:  case 3: ...
    14011400\end{lstlisting}
    14021401Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    1403 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of \lstinline@switch@ statement, called \lstinline@choose@, with no fall-through semantics.
    1404 The \lstinline@choose@ statement is identical to the new \lstinline@switch@ statement, except there is no implicit fall-through between case-clauses and the \lstinline@break@ statement applies to the enclosing loop construct (as for the continue statement in a \lstinline@switch@ statement).
     1402Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics.
     1403The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the continue statement in a ©switch© statement).
    14051404It is still possible to fall-through if a case-clause ends with the new keyword fallthru, e.g.:
    14061405\begin{lstlisting}
     
    14181417\item
    14191418Eliminating Duff's device is straightforward and only invalidates a small amount of very questionable code.
    1420 The solution is to allow \lstinline@case@ clauses to only appear at the same nesting level as the \lstinline@switch@ body, as is done in most other programming languages with \lstinline@switch@ statements.
    1421 \item
    1422 The issue of \lstinline@default@ at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the \lstinline@default@ clause may appear is locations other than at the end.
     1419The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements.
     1420\item
     1421The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause may appear is locations other than at the end.
    14231422Therefore, no language change is made for this issue.
    14241423\item
    1425 Dealing with unreachable code at the start of a \lstinline@switch@ statement is solved by defining the declaration-list, including any associated initialization, at the start of a \lstinline@switch@ statement body to be executed before the transfer to the appropriate \lstinline@case@ clause.
     1424Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed before the transfer to the appropriate ©case© clause.
    14261425This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body.
    1427 As well, this grammar does not allow statements to appear before the first \lstinline@case@ clause.
     1426As well, this grammar does not allow statements to appear before the first ©case© clause.
    14281427The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred.
    14291428The change is incompatible for statements, but any existing code using it is highly questionable, as in:
     
    14351434}
    14361435\end{lstlisting}
    1437 The statement after the \lstinline@switch@ can never be executed unless it is labelled.
    1438 If it is labelled, it must be transfered to from outside or inside the \lstinline@switch@ statement, neither of which is acceptable control flow.
     1436The statement after the ©switch© can never be executed unless it is labelled.
     1437If it is labelled, it must be transfered to from outside or inside the ©switch© statement, neither of which is acceptable control flow.
    14391438\end{enumerate}
    14401439
     
    14421441\section{Case Clause}
    14431442
    1444 C restricts the \lstinline@case@ clause of a \lstinline@switch@ statement to a single value.
    1445 For multiple \lstinline@case@ clauses associated with the same statement, it is necessary to have multiple \lstinline@case@ clauses rather than multiple values.
    1446 Requiring a \lstinline@case@ clause for each value does not seem to be in the spirit of brevity normally associated with C.
    1447 Therefore, the \lstinline@case@ clause is extended with a list of values, as in:
     1443C restricts the ©case© clause of a ©switch© statement to a single value.
     1444For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
     1445Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
     1446Therefore, the ©case© clause is extended with a list of values, as in:
    14481447\begin{quote2}
    14491448\begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
     
    17401739
    17411740The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
    1742 Use \lstinline@&@ to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
     1741Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
    17431742When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
    1744 The \lstinline@&@ is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
     1743The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
    17451744
    17461745\begin{figure}
     
    18151814In \CFA, as in C, all scalar types can be incremented and
    18161815decremented, which is defined in terms of adding or subtracting 1.
    1817 The operations \lstinline@&&@, \lstinline@||@, and \lstinline@!@ can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. \lstinline@(a && b)@ becomes \lstinline@(a != 0 && b != 0)@).
     1816The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. ©(a && b)© becomes ©(a != 0 && b != 0)©).
    18181817
    18191818In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any
     
    18241823polymorphic parameters, and user-defined pointer-like types may need a null value.
    18251824Defining special
    1826 constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
     1825constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
    18271826
    18281827Why just 0 and 1? Why not other integers? No other integers have special status in C.
     
    19071906\begin{tabular}[t]{ll}
    19081907%identifier & operation \\ \hline
    1909 \lstinline@?[?]@ & subscripting \impl{?[?]}\\
    1910 \lstinline@?()@ & function call \impl{?()}\\
    1911 \lstinline@?++@ & postfix increment \impl{?++}\\
    1912 \lstinline@?--@ & postfix decrement \impl{?--}\\
    1913 \lstinline@++?@ & prefix increment \impl{++?}\\
    1914 \lstinline@--?@ & prefix decrement \impl{--?}\\
    1915 \lstinline@*?@ & dereference \impl{*?}\\
    1916 \lstinline@+?@ & unary plus \impl{+?}\\
    1917 \lstinline@-?@ & arithmetic negation \impl{-?}\\
    1918 \lstinline@~?@ & bitwise negation \impl{~?}\\
    1919 \lstinline@!?@ & logical complement \impl{"!?}\\
    1920 \lstinline@?*?@ & multiplication \impl{?*?}\\
    1921 \lstinline@?/?@ & division \impl{?/?}\\
     1908©?[?]© & subscripting \impl{?[?]}\\
     1909©?()© & function call \impl{?()}\\
     1910©?++© & postfix increment \impl{?++}\\
     1911©?--© & postfix decrement \impl{?--}\\
     1912©++?© & prefix increment \impl{++?}\\
     1913©--?© & prefix decrement \impl{--?}\\
     1914©*?© & dereference \impl{*?}\\
     1915©+?© & unary plus \impl{+?}\\
     1916©-?© & arithmetic negation \impl{-?}\\
     1917©~?© & bitwise negation \impl{~?}\\
     1918©!?© & logical complement \impl{"!?}\\
     1919©?*?© & multiplication \impl{?*?}\\
     1920©?/?© & division \impl{?/?}\\
    19221921\end{tabular}\hfil
    19231922\begin{tabular}[t]{ll}
    19241923%identifier & operation \\ \hline
    1925 \lstinline@?%?@ & remainder \impl{?%?}\\
    1926 \lstinline@?+?@ & addition \impl{?+?}\\
    1927 \lstinline@?-?@ & subtraction \impl{?-?}\\
    1928 \lstinline@?<<?@ & left shift \impl{?<<?}\\
    1929 \lstinline@?>>?@ & right shift \impl{?>>?}\\
    1930 \lstinline@?<?@ & less than \impl{?<?}\\
    1931 \lstinline@?<=?@ & less than or equal \impl{?<=?}\\
    1932 \lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
    1933 \lstinline@?>?@ & greater than \impl{?>?}\\
    1934 \lstinline@?==?@ & equality \impl{?==?}\\
    1935 \lstinline@?!=?@ & inequality \impl{?"!=?}\\
    1936 \lstinline@?&?@ & bitwise AND \impl{?&?}\\
     1924©?%?© & remainder \impl{?%?}\\
     1925©?+?© & addition \impl{?+?}\\
     1926©?-?© & subtraction \impl{?-?}\\
     1927©?<<?© & left shift \impl{?<<?}\\
     1928©?>>?© & right shift \impl{?>>?}\\
     1929©?<?© & less than \impl{?<?}\\
     1930©?<=?© & less than or equal \impl{?<=?}\\
     1931©?>=?© & greater than or equal \impl{?>=?}\\
     1932©?>?© & greater than \impl{?>?}\\
     1933©?==?© & equality \impl{?==?}\\
     1934©?!=?© & inequality \impl{?"!=?}\\
     1935©?&?© & bitwise AND \impl{?&?}\\
    19371936\end{tabular}\hfil
    19381937\begin{tabular}[t]{ll}
    19391938%identifier & operation \\ \hline
    1940 \lstinline@?^?@ & exclusive OR \impl{?^?}\\
    1941 \lstinline@?|?@ & inclusive OR \impl{?"|?}\\
    1942 \lstinline@?=?@ & simple assignment \impl{?=?}\\
    1943 \lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
    1944 \lstinline@?/=?@ & division assignment \impl{?/=?}\\
    1945 \lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
    1946 \lstinline@?+=?@ & addition assignment \impl{?+=?}\\
    1947 \lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
    1948 \lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
    1949 \lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
    1950 \lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
    1951 \lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
    1952 \lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
     1939©?^?© & exclusive OR \impl{?^?}\\
     1940©?|?© & inclusive OR \impl{?"|?}\\
     1941©?=?© & simple assignment \impl{?=?}\\
     1942©?*=?© & multiplication assignment \impl{?*=?}\\
     1943©?/=?© & division assignment \impl{?/=?}\\
     1944©?%=?© & remainder assignment \impl{?%=?}\\
     1945©?+=?© & addition assignment \impl{?+=?}\\
     1946©?-=?© & subtraction assignment \impl{?-=?}\\
     1947©?<<=?© & left-shift assignment \impl{?<<=?}\\
     1948©?>>=?© & right-shift assignment \impl{?>>=?}\\
     1949©?&=?© & bitwise AND assignment \impl{?&=?}\\
     1950©?^=?© & exclusive OR assignment \impl{?^=?}\\
     1951©?|=?© & inclusive OR assignment \impl{?"|=?}\\
    19531952\end{tabular}
    19541953\hfil
     
    19591958These identifiers are defined such that the question marks in the name identify the location of the operands.
    19601959These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
    1961 For example, \lstinline@a + b@ becomes \lstinline@?+?(a, b)@.
     1960For example, ©a + b© becomes ©?+?(a, b)©.
    19621961
    19631962In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
     
    20022001\begin{quote2}
    20032002\begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
    2004 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{\lstinline@gcc@}\index{gcc} \\
     2003\multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
    20052004\begin{lstlisting}
    20062005
     
    20332032\end{itemize}
    20342033
    2035 In \CFA, \lstinline@typedef@ provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
    2036 \lstinline@gcc@ provides \lstinline@typeof@ to declare a secondary variable from a primary variable.
     2034In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
     2035©gcc© provides ©typeof© to declare a secondary variable from a primary variable.
    20372036\CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
    20382037Only for overloaded routines with the same return type is variable type-inferencing possible.
    2039 Finally, \lstinline@auto@ presents the programming problem of tracking down a type when the type is actually needed.
     2038Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
    20402039For example, given
    20412040\begin{lstlisting}
    20422041auto j = ®...®
    20432042\end{lstlisting}
    2044 and the need to write a routine to compute using \lstinline@j@
     2043and the need to write a routine to compute using ©j©
    20452044\begin{lstlisting}
    20462045void rtn( ®...® parm );
    20472046rtn( j );
    20482047\end{lstlisting}
    2049 A programmer must work backwards to determine the type of \lstinline@j@'s initialization expression, reconstructing the possibly long generic type-name.
     2048A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
    20502049In this situation, having the type name or a short alias is very useful.
    20512050
     
    20552054At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
    20562055
    2057 Given \lstinline@typedef@ and \lstinline@typeof@ in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
     2056Given ©typedef© and ©typeof© in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
    20582057Should a significant need arise, this feature can be revisited.
    20592058
     
    23572356} s;
    23582357\end{lstlisting}
    2359 The problem occurs in accesing these fields using the selection operation ``\lstinline@.@'':
     2358The problem occurs in accesing these fields using the selection operation ``©.©'':
    23602359\begin{lstlisting}
    23612360s.0 = 0;        // ambiguity with floating constant .0
     
    23682367\end{lstlisting}
    23692368While this sytact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.
    2370 Like the \CC lexical problem with closing template-syntax, e.g, \lstinline@Foo<Bar<int®>>®@, this issue can be solved with a more powerful lexer/parser.
    2371 
    2372 There are several ambiguous cases with operator identifiers, e.g., \lstinline@int *?*?()@, where the string \lstinline@*?*?@ can be lexed as \lstinline@*@/\lstinline@?*?@ or \lstinline@*?@/\lstinline@*?@.
    2373 Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., \lstinline@*i@, users will be annoyed if they cannot do this with respect to operator identifiers.
     2369Like the \CC lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
     2370
     2371There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
     2372Since it is common practise to put a unary operator juxtaposed to an identifier, e.g., ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
    23742373Even with this special hack, there are 5 general cases that cannot be handled.
    2375 The first case is for the function-call identifier \lstinline@?()@:
     2374The first case is for the function-call identifier ©?()©:
    23762375\begin{lstlisting}
    23772376int *§\textvisiblespace§?()();  // declaration: space required after '*'
    23782377*§\textvisiblespace§?()();              // expression: space required after '*'
    23792378\end{lstlisting}
    2380 Without the space, the string \lstinline@*?()@ is ambiguous without N character look ahead;
    2381 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument/parameter list.
     2379Without the space, the string ©*?()© is ambiguous without N character look ahead;
     2380it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list.
    23822381
    23832382The 4 remaining cases occur in expressions:
     
    23882387i§\textvisiblespace§?--i:0;             // space required after '?'
    23892388\end{lstlisting}
    2390 In the first two cases, the string \lstinline@i++?@ is ambiguous, where this string can be lexed as \lstinline@i@ / \lstinline@++?@ or \lstinline@i++@ / \lstinline@?@;
    2391 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
    2392 In the second two cases, the string \lstinline@?++x@ is ambiguous, where this string can be lexed as \lstinline@?++@ / \lstinline@x@ or \lstinline@?@ / y\lstinline@++x@;
    2393 it requires scanning ahead to determine if there is a \lstinline@'('@, which is the start of an argument list.
     2389In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©;
     2390it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
     2391In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©;
     2392it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list.
    23942393
    23952394
     
    40074006\begin{enumerate}
    40084007\item
    4009 Change type of character literal \lstinline@int@ to \lstinline@char@.
     4008Change type of character literal ©int© to ©char©.
    40104009This change allows overloading differentiation argument type matching, e.g.:
    40114010\begin{lstlisting}
     
    40244023
    40254024\item
    4026 Change: String literals made \lstinline@const@ \\
    4027 The type of a string literal is changed from \lstinline@array of char@ to \lstinline@array of const char@.
    4028 The type of a wide string literal is changed from \lstinline@array of wchar_t@ to \lstinline@array of const wchar_t@. \\
     4025Change: String literals made ©const© \\
     4026The type of a string literal is changed from ©array of char© to ©array of const char©.
     4027The type of a wide string literal is changed from ©array of wchar_t© to ©array of const wchar_t©. \\
    40294028Rationale: This avoids calling an inappropriate overloaded function, which might expect to be able to modify its argument.
    40304029Effect on original feature: Change to semantics of well-defined feature. \\
    4031 Difficulty of converting: Simple syntactic transformation, because string literals can be converted to \lstinline@char*;@ (4.2).
     4030Difficulty of converting: Simple syntactic transformation, because string literals can be converted to ©char*;© (4.2).
    40324031The most common cases are handled by a new but deprecated standard conversion:
    40334032\begin{lstlisting}
     
    40684067
    40694068\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \CC.
    4070 Nested types are not hoisted and can be referenced using the field selection operator ``\lstinline@.@'', unlike the \CC scope-resolution operator ``\lstinline@::@''.
     4069Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    40714070Given that nested types in C are equivalent to not using them, i.e., they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.
    40724071
     
    41744173%$
    41754174\item
    4176 A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline@,.:;!?)]}%¢»@
     4175A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
    41774176\begin{lstlisting}[belowskip=0pt]
    41784177sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
  • src/examples/abstype.c

    r1048b31 r1b7ea43  
    1010// Created On       : Wed May 27 17:56:53 2015
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Wed May 27 18:10:01 2015
    13 // Update Count     : 4
     12// Last Modified On : Wed Apr  6 22:16:08 2016
     13// Update Count     : 8
    1414//
    1515
    16 type T | { T x( T ); };
     16otype T | { T x( T ); };
    1717
    1818T y( T t ) {
     
    2121}
    2222
    23 forall(type T) lvalue T *?( T* );
    24 int ?++( int *);
    25 int ?=?( int*, int );
    26 forall(dtype DT) DT* ?=?( DT **, DT* );
     23forall( otype T ) lvalue T *?( T* );
     24int ?++( int * );
     25int ?=?( int *, int );
     26forall( dtype DT ) DT * ?=?( DT **, DT* );
    2727
    28 type U = int*;
     28otype U = int *;
    2929
    3030U x( U u ) {
  • src/examples/alloc.c

    r1048b31 r1b7ea43  
    1111// Created On       : Wed Feb  3 07:56:22 2016
    1212// Last Modified By : Peter A. Buhr
    13 // Last Modified On : Wed Feb 17 11:43:23 2016
    14 // Update Count     : 40
     13// Last Modified On : Fri Mar 11 17:42:08 2016
     14// Update Count     : 59
    1515//
    1616
     17forall( otype T ) T * malloc( char fill );
     18forall( dtype T ) T *?=?( T **, void * );
     19void *malloc( unsigned long int );
     20#if 0
    1721#include <fstream>
    1822#include <stdlib>
     
    2529int * bar( int * p, int c ) { return p; }
    2630int * baz( int * p, int c ) { return p; }
     31#endif
    2732
    2833int main( void ) {
     34#if 0
    2935    size_t size = 10;
    3036    int * p;
    3137    struct S { int x; double y; } * s;
     38#endif
    3239
     40#if 0
    3341    p = malloc( sizeof(*p) );                                                   // C malloc, type unsafe
    3442        printf( "here1\n" );
     
    3745        printf( "here2\n" );
    3846    free( p );
    39     p = malloc( (char)'\0' );                                                                   // CFA malloc, type safe
     47#endif
     48//    int * p;
     49//    p = malloc( (char)'\0' );                                                                 // CFA malloc, type safe
     50    (int *)malloc( (char)'\0' );                                                                        // CFA malloc, type safe
     51    (void *)malloc( (char)'\0' );                                                                       // CFA malloc, type safe
     52#if 0
    4053        printf( "here3\n" );
    4154    p = malloc( p, 1000 );                                                              // CFA remalloc, type safe
     
    6073        printf( "here9\n" );
    6174    free( p );
    62 #if 0
     75
    6376    float * fp = malloc() + 1;
    6477    fprintf( stderr, "%p %p\n", fp, fp - 1 );
  • src/examples/fstream_test.c

    r1048b31 r1b7ea43  
    1010// Created On       : Wed May 27 17:56:53 2015
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Sun Mar  6 20:58:29 2016
    13 // Update Count     : 54
     12// Last Modified On : Mon May  2 15:25:54 2016
     13// Update Count     : 61
    1414//
    1515
  • src/examples/includes.c

    r1048b31 r1b7ea43  
    1010// Created On       : Wed May 27 17:56:53 2015
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Wed Mar  2 23:28:02 2016
    13 // Update Count     : 328
     12// Last Modified On : Wed Apr 13 22:30:02 2016
     13// Update Count     : 370
    1414//
    1515
     
    2424#if 1
    2525#define _GNU_SOURCE
    26 #include <aio.h>
    27 #include <a.out.h>
    28 #include <aliases.h>
    29 #include <alloca.h>
    30 #include <ansidecl.h>
    31 #include <ar.h>
    32 #include <argp.h>
     26//#include <aio.h>
     27//#include <a.out.h>
     28//#include <aliases.h>
     29//#include <alloca.h>
     30//#include <ansidecl.h>
     31//#include <ar.h>
     32//#include <argp.h>
    3333#include <argz.h>
    34 #include <assert.h>
     34//#include <assert.h>
    3535#include <bfd.h>
     36#if 0
    3637#include <bfdlink.h>
    3738#include <byteswap.h>
     
    5657#include <err.h>
    5758#include <errno.h>
    58 #if 0
    5959#include <error.h>
    60 #endif
    6160#include <eti.h>
    6261#include <evdns.h>
    6362#include <event.h>
    6463#include <evhttp.h>
     64#endif
    6565#if 0
    6666#include <evrpc.h>
     
    129129
    130130//#define _GNU_SOURCE
    131 #include <error.h>
     131#include <bfd.h>
     132//#include <error.h>
    132133
    133134#endif // 0
  • src/examples/sum.c

    r1048b31 r1b7ea43  
    1010// Created On       : Wed May 27 17:56:53 2015
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Fri Mar  4 15:06:47 2016
    13 // Update Count     : 196
     12// Last Modified On : Mon May  2 15:07:57 2016
     13// Update Count     : 198
    1414//
    1515
     
    4848        } // for
    4949        sout | "sum from" | low | "to" | High | "is"
    50                  | (int)sum( size, a ) | "" | ", check" | (int)s | endl;
     50                 | (int)sum( size, a ) | ", check" | (int)s | endl;
    5151
    5252        int s = 0, a[size], v = low;
     
    5656        } // for
    5757        sout | "sum from" | low | "to" | High | "is"
    58                  | sum( size, (int *)a ) | "" | ", check" | (int)s | endl;
     58                 | sum( size, (int *)a ) | ", check" | (int)s | endl;
    5959
    6060        float s = 0.0, a[size], v = low / 10.0;
     
    6464        } // for
    6565        sout | "sum from" | low / 10.0 | "to" | High / 10.0 | "is"
    66                  | sum( size, (float *)a ) | "" | ", check" | (float)s | endl;
     66                 | sum( size, (float *)a ) | ", check" | (float)s | endl;
    6767
    6868        double s = 0, a[size], v = low / 10.0;
     
    7272        } // for
    7373        sout | "sum from" | low / 10.0 | "to" | High / 10.0 | "is"
    74                  | sum( size, (double *)a ) | "" | ", check" | (double)s | endl;
     74                 | sum( size, (double *)a ) | ", check" | (double)s | endl;
    7575
    7676        struct S { int i, j; } 0 = { 0, 0 }, 1 = { 1, 1 };
     
    8787        } // for
    8888        sout | "sum from" | low | "to" | High | "is"
    89                  | sum( size, (S *)a ) | "" | ", check" | (S)s | endl;
     89                 | sum( size, (S *)a ) | ", check" | (S)s | endl;
    9090} // main
    9191
Note: See TracChangeset for help on using the changeset viewer.