Changeset 0638c44


Ignore:
Timestamp:
May 3, 2016, 9:30:55 AM (6 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, ctor, deferred_resn, demangler, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
7937abf, a1d6d80
Parents:
e945826
Message:

more formatting changes to documents, update I/O for examples

Files:
5 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    re945826 r0638c44  
    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 : Tue May  3 07:59:41 2016
     14%% Update Count     : 44
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    200200belowskip=2pt,
    201201moredelim=**[is][\color{red}]{®}{®}, % red highlighting
    202 moredelim=**[is][\color{blue}]{©}{©}, % blue highlighting
     202% moredelim=**[is][\color{blue}]{©}{©}, % blue highlighting
    203203moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % temporarily turn off keywords
    204204% literate={\\`}{\raisebox{0.3ex}{\ttfamily\upshape \hspace*{-2pt}`}}1, % escape \`, otherwise used for red highlighting
    205205}%
     206
     207\lstMakeShortInline©    % single-character for \lstinline
    206208
    207209\makeatletter
  • doc/refrat/refrat.tex

    re945826 r0638c44  
    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 09:23:43 2016
     13%% Update Count     : 52
    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
     
    131141\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
    132142\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;
     143The 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.
     144The outer declaration becomes \Index{visible} when the scope of the inner declaration terminates.
     145\begin{rationale}
     146Hence, a \CFA program can declare an ©int v© and a ©float v© in the same scope;
    138147a {\CC} program can not.
    139148\end{rationale}
     
    149158Identifiers with \Index{no linkage} always denote unique entities.
    150159\begin{rationale}
    151 A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;
     160A \CFA program can declare an ©extern int v© and an ©extern float v©;
    152161a C program cannot.
    153162\end{rationale}
     
    172181\end{lstlisting}
    173182
    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@.
     183The 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©.
    175184The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    176185
     
    233242In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    234243
    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.
     244Let ©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$.
     245Let ©unsigned$_{mr}$© be the unsigned integer type with maximal rank.
    237246
    238247The following conversions are \emph{direct} safe arithmetic conversions.
     
    241250The \Index{integer promotion}s.
    242251\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@.
     252For every rank $r$ greater than or equal to the rank of ©int©, conversion from ©int$_r$© to ©unsigned$_r$©.
     253\item
     254For 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}$©.
     255\item
     256Conversion from ©unsigned$_{mr}$© to ©float©.
    248257\item
    249258Conversion from an enumerated type to its compatible integer type.
    250259\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@.
     260Conversion from ©float© to ©double©, and from ©double© to ©long double©.
     261\item
     262Conversion from ©float _Complex© to ©double _Complex©, and from ©double _Complex© to ©long double _Complex©.
    254263\begin{sloppypar}
    255264\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.
     265Conversion from ©float _Imaginary© to ©double _Imaginary©, and from ©double _Imaginary© to ©long double _Imaginary©, if the implementation supports imaginary types.
    257266\end{sloppypar}
    258267\end{itemize}
    259268
    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.
     269If 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.
    261270
    262271\begin{rationale}
     
    291300move_to( &cp1, &cp2 );
    292301\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.
     302Thanks to implicit conversion, the two arguments that ©move_by()© receives are pointers to ©cp1©'s second member and ©cp2©'s second member.
    295303
    296304
     
    334342a direct safe arithmetic conversion;
    335343\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@;
     344from any object type or incomplete type to ©void©;
     345\item
     346from a pointer to any non-©void© type to a pointer to ©void©;
    339347\item
    340348from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     
    347355Conversions that are not safe conversions are \define{unsafe conversion}s.
    348356\begin{rationale}
    349 As in C, there is an implicit conversion from \lstinline@void *@ to any pointer type.
     357As in C, there is an implicit conversion from ©void *© to any pointer type.
    350358This is clearly dangerous, and {\CC} does not have this implicit conversion.
    351359\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.
     
    373381\begin{itemize}
    374382\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.
     383The cost of an implicit conversion from ©int© to ©long© is 1.
     384The 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©.
     385
     386\item
     387If ©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©.
     388Otherwise, ©unsigned short© is converted directly to ©unsigned©, and the cost is 1.
     389
     390\item
     391If ©long© can represent all the values of ©unsigned©, then the conversion cost of ©unsigned© to ©long© is 1.
    385392Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    386393\end{itemize}
     
    390397\begin{syntax}
    391398\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@
     399        \rhs ©forall©
     400        \rhs ©lvalue©
     401        \rhs ©trait©
     402        \rhs ©dtype©
     403        \rhs ©ftype©
     404        \rhs ©otype©
    398405\end{syntax}
    399406
     
    402409
    403410\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.
     411Furthermore, 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.
    405412Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    406413
     
    411418\begin{syntax}
    412419\oldlhs{identifier}
    413 \rhs \lstinline@0@
    414 \rhs \lstinline@1@
     420\rhs ©0©
     421\rhs ©1©
    415422\end{syntax}
    416423
    417 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline@0@''\impl{0} and ``\lstinline@1@''\impl{1} are identifiers.
     424\index{constant identifiers}\index{identifiers!for constants} The tokens ``©0©''\impl{0} and ``©1©''\impl{1} are identifiers.
    418425No other tokens defined by the rules for integer constants are considered to be identifiers.
    419426\begin{rationale}
    420 Why ``\lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.
     427Why ``©0©'' and ``©1©''? Those integers have special status in C.
    421428All 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.
     429The operations ``©&&©'', ``©||©'', and ``©!©'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    423430A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    424431
    425432In 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.
    426433However, 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.
     434Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
     435
     436Why \emph{just} ``©0©'' and ``©1©''? Why not other integers? No other integers have special status in C.
     437A facility that let programmers declare specific constants---``©const Rational 12©'', for instance---would not be much of an improvement.
    431438Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    432439The complexity of such a feature doesn't seem worth the gain.
     
    444451\begin{tabular}[t]{ll}
    445452%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{?/?}\\
     453©?[?]© & subscripting \impl{?[?]}\\
     454©?()© & function call \impl{?()}\\
     455©?++© & postfix increment \impl{?++}\\
     456©?--© & postfix decrement \impl{?--}\\
     457©++?© & prefix increment \impl{++?}\\
     458©--?© & prefix decrement \impl{--?}\\
     459©*?© & dereference \impl{*?}\\
     460©+?© & unary plus \impl{+?}\\
     461©-?© & arithmetic negation \impl{-?}\\
     462©~?© & bitwise negation \impl{~?}\\
     463©!?© & logical complement \impl{"!?}\\
     464©?*?© & multiplication \impl{?*?}\\
     465©?/?© & division \impl{?/?}\\
    459466\end{tabular}\hfil
    460467\begin{tabular}[t]{ll}
    461468%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{?&?}\\
     469©?%?© & remainder \impl{?%?}\\
     470©?+?© & addition \impl{?+?}\\
     471©?-?© & subtraction \impl{?-?}\\
     472©?<<?© & left shift \impl{?<<?}\\
     473©?>>?© & right shift \impl{?>>?}\\
     474©?<?© & less than \impl{?<?}\\
     475©?<=?© & less than or equal \impl{?<=?}\\
     476©?>=?© & greater than or equal \impl{?>=?}\\
     477©?>?© & greater than \impl{?>?}\\
     478©?==?© & equality \impl{?==?}\\
     479©?!=?© & inequality \impl{?"!=?}\\
     480©?&?© & bitwise AND \impl{?&?}\\
    474481\end{tabular}\hfil
    475482\begin{tabular}[t]{ll}
    476483%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{?"|=?}\\
     484©?^?© & exclusive OR \impl{?^?}\\
     485©?|?© & inclusive OR \impl{?"|?}\\
     486©?=?© & simple assignment \impl{?=?}\\
     487©?*=?© & multiplication assignment \impl{?*=?}\\
     488©?/=?© & division assignment \impl{?/=?}\\
     489©?%=?© & remainder assignment \impl{?%=?}\\
     490©?+=?© & addition assignment \impl{?+=?}\\
     491©?-=?© & subtraction assignment \impl{?-=?}\\
     492©?<<=?© & left-shift assignment \impl{?<<=?}\\
     493©?>>=?© & right-shift assignment \impl{?>>=?}\\
     494©?&=?© & bitwise AND assignment \impl{?&=?}\\
     495©?^=?© & exclusive OR assignment \impl{?^=?}\\
     496©?|=?© & inclusive OR assignment \impl{?"|=?}\\
    490497\end{tabular}
    491498\hfil
     
    502509
    503510\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@--@''.
     511The 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
     512\CFA compiler detects a syntax error because it treats ``©?--©'' as an identifier, not as the two tokens ``©?©'' and ``©--©''.
    506513\end{rationale}
    507514
     
    510517\begin{itemize}
    511518\item
    512 The logical operators ``\lstinline@&&@'' and ``\lstinline@||@'', and the conditional operator
    513 ``\lstinline@?:@''.
     519The logical operators ``©&&©'' and ``©||©'', and the conditional operator ``©?:©''.
    514520These 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.
     521Note 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.
    516522
    517523\item
     
    522528\item
    523529The ``address of'' operator.
    524 It would seem useful to define a unary ``\lstinline@&@'' operator that returns values of some programmer-defined pointer-like type.
     530It would seem useful to define a unary ``©&©'' operator that returns values of some programmer-defined pointer-like type.
    525531The 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 )@''
     532Consider the expression ``©p = &x©'', where ©x© is of type ©T© and ©p© has the programmer-defined type ©T_ptr©.
     533The expression might be treated as a call to the unary function ``©&?©''.
     534Now 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.
     535Hence the parameter must have type ©T *©.
     536But then the expression must be rewritten as ``©p = &?( &x )©''
    532537---which doesn't seem like progress!
    533538
    534539The 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.
     540It seems simpler to define a conversion function from ©T *© to ©T_ptr©.
     541
     542\item
     543The ©sizeof© operator.
    539544It is already defined for every object type, and intimately tied into the language's storage allocation model.
    540545Redefining it seems pointless.
    541546
    542547\item
    543 The ``member of'' operators ``\lstinline@.@'' and ``\lstinline@->@''.
     548The ``member of'' operators ``©.©'' and ``©->©''.
    544549These are not really infix operators, since their right ``operand'' is not a value or object.
    545550
     
    578583The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    579584The ``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@.
     585The 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©.
    581586
    582587The ``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}).
     588It also gives preference to monomorphic values (such as the ©int© ©0©) over polymorphic values (such as the \Index{null pointer} ©0©\use{0}).
    586589However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    587590
     
    603606\begin{rationale}
    604607Predefined 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)@''.
     608For instance, ``©an_int + an_int©'' is equivalent to ``©?+?(an_int, an_int)©''.
    606609If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    607610If predefined functions had external linkage, this optimization would be difficult.
     
    629632\rhs \nonterm{constant}
    630633\rhs \nonterm{string-literal}
    631 \rhs \lstinline@(@ \nonterm{expression} \lstinline@)@
     634\rhs ©(© \nonterm{expression} ©)©
    632635\rhs \nonterm{generic-selection}
    633636\end{syntax}
     
    645648
    646649A \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.
     650The predefined integer identifiers ``©1©'' and ``©0©'' have the integer values 1 and 0, respectively.
     651The 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.
    649652
    650653A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    651654
    652655\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.
     656The 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 *©.
     657In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer ©0© to a pointer.
    656658
    657659\begin{rationale}
     
    659661
    660662\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
     663The C token ``©0©'' is an expression of type ©int© with the value ``zero'', and it \emph{also} is a null pointer constant.
     664Similarly, ``©(void *)0© is an expression of type ©(void *)© whose value is a null pointer, and it also is a null pointer constant.
     665However, in C, ``©(void *)(void *)0©'' is
    665666\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.
    666667
     
    669670\begin{lstlisting}
    670671forall( 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.
     672\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.
    672673The only such value is the null pointer.
    673674Therefore the type \emph{alone} is enough to identify a null pointer.
     
    679680
    680681\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.
     682If 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.
    682683
    683684\semantics
     
    690691\lhs{postfix-expression}
    691692\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@}@
     693\rhs \nonterm{postfix-expression} ©[© \nonterm{expression} ©]©
     694\rhs \nonterm{postfix-expression} ©(©
     695         \nonterm{argument-expression-list}\opt ©)©
     696\rhs \nonterm{postfix-expression} ©.© \nonterm{identifier}
     697\rhs \nonterm{postfix-expression} ©->© \nonterm{identifier}
     698\rhs \nonterm{postfix-expression} ©++©
     699\rhs \nonterm{postfix-expression} ©--©
     700\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©}©
     701\rhs ©(© \nonterm{type-name} ©)© ©{© \nonterm{initializer-list} ©,© ©}©
    701702\lhs{argument-expression-list}
    702703\rhs \nonterm{assignment-expression}
    703 \rhs \nonterm{argument-expression-list} \lstinline@,@
     704\rhs \nonterm{argument-expression-list} ©,©
    704705         \nonterm{assignment-expression}
    705706\end{syntax}
     
    739740The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    740741\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@?[?]@.
     742C 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 ©?[?]©.
    743743
    744744Subscript expressions are rewritten as function calls that pass the first parameter by value.
    745745This 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.
     746The alternative is to use the rewrite rule ``©a[b]© \rewrite ©?[?](&(a), b)©''.
     747However, C semantics forbid this approach: the ©a© in ``©a[b]©'' can be an arbitrary pointer value, which does not have an address.
    748748
    749749The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
     
    760760\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    761761
    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@?()@''.
     762For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``©?()©''.
    763763The valid interpretations of the rewritten expression are determined in the manner described below.
    764764
     
    767767\begin{itemize}
    768768\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.
     769\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.
    771770\end{itemize}
    772771The type of the valid interpretation is the return type of the function designator.
     
    776775\begin{itemize}
    777776\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.
     777If the declaration of the implicit parameter uses \Index{type-class} ©type©\use{type}, the implicit argument must be an object type;
     778if it uses ©dtype©, the implicit argument must be an object type or an incomplete type;
     779and if it uses ©ftype©, the implicit argument must be a function type.
    781780
    782781\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.
     
    797796\begin{rationale}
    798797One 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@.
     798For 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©.
    800799
    801800\CFA\index{deficiencies!generalizability} does not fully possess this property, because
     
    811810f = g( d, f );          // (3) (unsafe conversion to float)
    812811\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.
     812If ©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©.
     813
     814Another example is the function ``©void h( int *);©''.
     815This function can be passed a ©void *© argument, but the generalization ``©forall( otype T ) void h( T *);©'' can not.
     816In this case, ©void© is not a valid value for ©T© because it is not an object type.
     817If unsafe conversions were allowed, ©T© could be inferred to be \emph{any} object type, which is undesirable.
    821818\end{rationale}
    822819
    823820\examples
    824 A function called ``\lstinline@?()@'' might be part of a numerical differentiation package.
     821A function called ``©?()©'' might be part of a numerical differentiation package.
    825822\begin{lstlisting}
    826823extern otype Derivative;
     
    833830d = sin_dx( 12.9 );
    834831\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 )@''.
     832Here, the only interpretation of ©sin_dx© is as an object of type ©Derivative©.
     833For that interpretation, the function call is treated as ``©?()( sin_dx, 12.9 )©''.
    837834\begin{lstlisting}
    838835int f( long );          // (1)
     
    841838int i = f( 5 );         // calls (1)
    842839\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.
     840Function (1) provides a valid interpretation of ``©f( 5 )©'', using an implicit ©int© to ©long© conversion.
     841The 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.
    845842
    846843\begin{lstlisting}
     
    848845double d = h( 1.5 );
    849846\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@.
     847``©1.5©'' is a ©double© constant, so ©T© is inferred to be ©double©, and the result of the function call is a ©double©.
    852848
    853849\begin{lstlisting}
    854850forall( otype T, otype U ) void g( T, U );      // (4)
    855851forall( otype T ) void g( T, T );                       // (5)
    856 forall( otype T ) void g( T, long );                    // (6)
     852forall( otype T ) void g( T, long );            // (6)
    857853void g( long, long );                                           // (7)
    858854double d;
    859855int i;
    860856int *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).
     857g( d, d );                                                                      // calls (5)
     858g( d, i );                                                                      // calls (6)
     859g( i, i );                                                                      // calls (7)
     860g( i, p );                                                                      // calls (4)
     861\end{lstlisting}
     862The 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).
    867863
    868864For 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.
     865Of the remaining interpretations for (4), (5), and (6) (with ©i© converted to ©long©), (6) is chosen because it is the least polymorphic.
    870866
    871867The third call has valid interpretations for all of the functions;
     
    883879shuffle( 9, 10 );
    884880\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)
     881The 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©.
     882\begin{lstlisting}
     883extern void q( int );                                           // (8)
     884extern void q( void * );                                        // (9)
    890885extern void r();
    891886q( 0 );
    892887r( 0 );
    893888\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.
     889The ©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).
     890The former is chosen because the ©int© ©0© is \Index{less polymorphic}.
     891For the same reason, ©int© ©0© is passed to ©r()©, even though it has \emph{no} declared parameter types.
    897892
    898893
    899894\subsubsection{Structure and union members}
    900895
    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.
     896\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©.
     897If 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.
     898If 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.
    906899The expression has no other interpretations.
    907900
    908 The expression ``\lstinline@p->m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.
     901The expression ``©p->m©'' has the same interpretations as the expression ``©(*p).m©''.
    909902
    910903
     
    1001994        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    1002995\end{lstlisting}
    1003 For every extended integer type \lstinline@X@ there exist
     996For every extended integer type ©X© there exist
    1004997% Don't use predefined: keep this out of prelude.cf.
    1005998\begin{lstlisting}
     
    10071000  ?--( volatile X * ), ?--( _Atomic volatile X * );
    10081001\end{lstlisting}
    1009 For every complete enumerated type \lstinline@E@ there exist
     1002For every complete enumerated type ©E© there exist
    10101003% Don't use predefined: keep this out of prelude.cf.
    10111004\begin{lstlisting}
     
    10151008
    10161009\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.
     1010Note 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.
    10181011This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    10191012\end{rationale}
     
    10211014\begin{rationale}
    10221015In 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@.
     1016Hence, ©void *© objects cannot be incremented.
     1017In \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©.
    10251018\end{rationale}
    10261019
     
    10401033\end{lstlisting}
    10411034\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.
     1035Since ©&(vs)© has type ©volatile short int *©, the best valid interpretation of ©vs++© calls the ©?++© function with the ©volatile short *© parameter.
     1036©s++© does the same, applying the safe conversion from ©short int *© to ©volatile short int *©.
     1037Note that there is no conversion that adds an ©_Atomic© qualifier, so the ©_Atomic volatile short int© overloading does not provide a valid interpretation.
    10461038\end{sloppypar}
    10471039
    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.
     1040There 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.
     1041
     1042The 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.
    10511043\begin{lstlisting}
    10521044char * const restrict volatile * restrict volatile pqpc;
     
    10551047ppc++;
    10561048\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@.
     1049Since ©&(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 *©.
     1050
     1051©ppc++© calls the same function, again inferring ©T© to be ©char *©, and using the safe conversions from ©T© to ©T const© ©restrict volatile©.
    10601052
    10611053\begin{rationale}
     
    10711063\begin{enumerate}
    10721064\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
     1065``©char * p; p++;©''.
     1066The argument to ©?++© has type ©char * *©, and the result has type ©char *©.
     1067The expression would be valid if ©?++© were declared by
    10761068\begin{lstlisting}
    10771069forall( 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.
     1070\end{lstlisting} with ©T© inferred to be ©char©.
     1071
     1072\item
     1073``©char *restrict volatile qp; qp++©''.
     1074The 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.
    10831075Hence the actual predefined function is
    10841076\begin{lstlisting}
    10851077forall( 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:
     1078\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.)
     1079
     1080\item
     1081``©char *_Atomic ap; ap++©''.
     1082The result again has type ©char *©, but no safe conversion adds an ©_Atomic© qualifier, so the function in point 2 is not applicable.
     1083A separate overloading of ©?++© is required.
     1084
     1085\item
     1086``©char const volatile * pq; pq++©''.
     1087Here the result has type ©char const volatile *©, so a new overloading is needed:
    10981088\begin{lstlisting}
    10991089forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     
    11021092 
    11031093\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:
     1094``©float *restrict * prp; prp++©''.
     1095The ©restrict© qualifier is handled just like ©const© and ©volatile© in the previous case:
    11061096\begin{lstlisting}
    11071097forall( 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.
     1098\end{lstlisting} with ©T© inferred to be ©float *©.
     1099This 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.
    11101100\end{enumerate}
    11111101\end{rationale}
     
    11231113\lhs{unary-expression}
    11241114\rhs \nonterm{postfix-expression}
    1125 \rhs \lstinline@++@ \nonterm{unary-expression}
    1126 \rhs \lstinline@--@ \nonterm{unary-expression}
     1115\rhs ©++© \nonterm{unary-expression}
     1116\rhs ©--© \nonterm{unary-expression}
    11271117\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@!@
     1118\rhs ©sizeof© \nonterm{unary-expression}
     1119\rhs ©sizeof© ©(© \nonterm{type-name} ©)©
     1120\lhs{unary-operator} one of \rhs ©&© ©*© ©+© ©-© ©~© ©!©
    11311121\end{syntax}
    11321122
     
    12351225        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12361226\end{lstlisting}
    1237 For every extended integer type \lstinline@X@ there exist
     1227For every extended integer type ©X© there exist
    12381228% Don't use predefined: keep this out of prelude.cf.
    12391229\begin{lstlisting}
     
    12431233        --?( _Atomic volatile X * );
    12441234\end{lstlisting}
    1245 For every complete enumerated type \lstinline@E@ there exist
     1235For every complete enumerated type ©E© there exist
    12461236% Don't use predefined: keep this out of prelude.cf.
    12471237\begin{lstlisting}
     
    12801270
    12811271\constraints
    1282 The operand of the unary ``\lstinline@&@'' operator shall have exactly one
     1272The operand of the unary ``©&©'' operator shall have exactly one
    12831273\Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    12841274
    12851275\semantics
    1286 The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where
    1287 \lstinline@T@ is the type of the operand.
     1276The ``©&©'' expression has one interpretation which is of type ©T *©, where ©T© is the type of the operand.
    12881277
    12891278The interpretations of an indirection expression are the interpretations of the corresponding function call.
     
    13141303forall( ftype FT ) int !?( FT * );
    13151304\end{lstlisting}
    1316 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1305For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    13171306% Don't use predefined: keep this out of prelude.cf.
    13181307\begin{lstlisting}
     
    13301319eat_double(-li ); // §\rewrite§ eat_double( -?( li ) );
    13311320\end{lstlisting}
    1332 The valid interpretations of ``\lstinline@-li@'' (assuming no extended integer types exist) are
     1321The valid interpretations of ``©-li©'' (assuming no extended integer types exist) are
    13331322\begin{center}
    13341323\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    13351324\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) \\
     1325©-?( (int)li )©                                         & ©int©                                         & (unsafe) \\
     1326©-?( (unsigned)li)©                                     & ©unsigned int©                        & (unsafe) \\
     1327©-?( (long)li)©                                         & ©long©                                        & 0 \\
     1328©-?( (long unsigned int)li)©            & ©long unsigned int©           & 1 \\
     1329©-?( (long long int)li)©                        & ©long long int©                       & 2 \\
     1330©-?( (long long unsigned int)li)©       & ©long long unsigned int©      & 3 \\
     1331©-?( (float)li)©                                        & ©float©                                       & 4 \\
     1332©-?( (double)li)©                                       & ©double©                                      & 5 \\
     1333©-?( (long double)li)©                          & ©long double©                         & 6 \\
     1334©-?( (_Complex float)li)©                       & ©float©                                       & (unsafe) \\
     1335©-?( (_Complex double)li)©                      & ©double©                                      & (unsafe) \\
     1336©-?( (_Complex long double)li)©         & ©long double©                         & (unsafe) \\
    13481337\end{tabular}
    13491338\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
     1339The valid interpretations of the ©eat_double© call, with the cost of the argument conversion and the cost of the entire expression, are
    13511340\begin{center}
    13521341\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    13531342\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) \\
     1343©eat_double( (double)-?( (int)li) )©                                    & 7                     & (unsafe) \\
     1344©eat_double( (double)-?( (unsigned)li) )©                               & 6                     & (unsafe) \\
     1345©eat_double( (double)-?(li) )©                                                  & 5                     & \(0+5=5\) \\
     1346©eat_double( (double)-?( (long unsigned int)li) )©              & 4                     & \(1+4=5\) \\
     1347©eat_double( (double)-?( (long long int)li) )©                  & 3                     & \(2+3=5\) \\
     1348©eat_double( (double)-?( (long long unsigned int)li) )© & 2                     & \(3+2=5\) \\
     1349©eat_double( (double)-?( (float)li) )©                                  & 1                     & \(4+1=5\) \\
     1350©eat_double( (double)-?( (double)li) )©                                 & 0                     & \(5+0=5\) \\
     1351©eat_double( (double)-?( (long double)li) )©                    & (unsafe)      & (unsafe) \\
     1352©eat_double( (double)-?( (_Complex float)li) )©                 & (unsafe)      & (unsafe) \\
     1353©eat_double( (double)-?( (_Complex double)li) )©                & (unsafe)      & (unsafe) \\
     1354©eat_double( (double)-?( (_Complex long double)li) )©   & (unsafe)      & (unsafe) \\
    13661355\end{tabular}
    13671356\end{center}
    1368 Each has result type \lstinline@void@, so the best must be selected.
     1357Each has result type ©void©, so the best must be selected.
    13691358The 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) )@.
     1359The remainder have equal expression conversion costs, so the ``highest argument conversion cost'' rule is invoked, and the chosen interpretation is ©eat_double( (double)-?(li) )©.
    13731360
    13741361
     
    13761363
    13771364\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
     1365The operand of ©sizeof© or ©_Alignof© shall not be ©type©, ©dtype©, or ©ftype©.
     1366
     1367When 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©.
     1368
     1369When ©sizeof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13831370\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    13841371When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    13851372
    1386 When \lstinline@_Alignof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1373When ©_Alignof© is applied to an identifier declared by a \nonterm{type-declaration} or a
    13871374\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    13881375When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     
    13981385}
    13991386\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.
     1387``©sizeof Rational©'', although not statically known, is fixed.
     1388Within ©f()©, ``©sizeof(T)©'' is fixed for each call of ©f()©, but may vary from call to call.
    14031389\end{rationale}
    14041390
     
    14091395\lhs{cast-expression}
    14101396\rhs \nonterm{unary-expression}
    1411 \rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \nonterm{cast-expression}
     1397\rhs ©(© \nonterm{type-name} ©)© \nonterm{cast-expression}
    14121398\end{syntax}
    14131399
    14141400\constraints
    1415 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline@type@,
    1416 \lstinline@dtype@, or \lstinline@ftype@.
     1401The \nonterm{type-name} in a \nonterm{cast-expression} shall not be ©type©, ©dtype©, or ©ftype©.
    14171402
    14181403\semantics
    14191404
    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.
     1405In a \Index{cast expression} ``©(©\nonterm{type-name}©)e©'', if
     1406\nonterm{type-name} is the type of an interpretation of ©e©, then that interpretation is the only interpretation of the cast expression;
     1407otherwise, ©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.
    14231408The 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.
    14241409
     
    14331418\lhs{multiplicative-expression}
    14341419\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}
     1420\rhs \nonterm{multiplicative-expression} ©*© \nonterm{cast-expression}
     1421\rhs \nonterm{multiplicative-expression} ©/© \nonterm{cast-expression}
     1422\rhs \nonterm{multiplicative-expression} ©%© \nonterm{cast-expression}
    14381423\end{syntax}
    14391424
     
    14691454        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    14701455\end{lstlisting}
    1471 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1456For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    14721457% Don't use predefined: keep this out of prelude.cf.
    14731458\begin{lstlisting}
     
    14901475eat_double( li % i );
    14911476\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
     1477``©li % i©'' is rewritten as ``©?%?(li, i )©''.
     1478The 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
    14941479\begin{center}
    14951480\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     \\
     1481\hline
     1482© ?%?( (int)li, i )©                                                                            & (unsafe)      & 6     \\
     1483© ?%?( (unsigned)li,(unsigned)i )©                                                      & (unsafe)      & 5     \\
     1484© ?%?( li, (long)i )©                                                                           & 1                     & 4     \\
     1485© ?%?( (long unsigned)li,(long unsigned)i )©                            & 3                     & 3     \\
     1486© ?%?( (long long)li,(long long)i )©                                            & 5                     & 2     \\
     1487© ?%?( (long long unsigned)li, (long long unsigned)i )©         & 7                     & 1     \\
    15031488\end{tabular}
    15041489\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 )@''.
     1490The best interpretation of ©eat_double( li, i )© is ©eat_double( (double)?%?(li, (long)i ))©, which has no unsafe conversions and the lowest total cost.
     1491
     1492\begin{rationale}
     1493{\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©.
     1494If ©s© is a ©short int©, ``©s *s©'' does not have type ©short int©;
     1495it is treated as ``©( (int)s ) * ( (int)s )©'', and has type ©int©. \CFA matches that pattern;
     1496it does not predefine ``©short ?*?( short, short )©''.
    15131497
    15141498These ``missing'' operators limit polymorphism.
     
    15191503square( s );
    15201504\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@.
     1505Since \CFA does not define a multiplication operator for ©short int©, ©square( s )© is treated as ©square( (int)s )©, and the result has type ©int©.
    15241506This is mildly surprising, but it follows the {\c11} operator pattern.
    15251507
     
    15301512product( sa, 5);
    15311513\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@''.
     1514This has no valid interpretations, because \CFA has no conversion from ``array of ©short int©'' to ``array of ©int©''.
    15341515The alternatives in such situations include
    15351516\begin{itemize}
    15361517\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.
     1518Defining monomorphic overloadings of ©product© for ©short© and the other ``small'' types.
     1519\item
     1520Defining ``©short ?*?( short, short )©'' within the scope containing the call to ©product©.
     1521\item
     1522Defining ©product© to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    15441523\end{itemize}
    15451524\end{rationale}
     
    15511530\lhs{additive-expression}
    15521531\rhs \nonterm{multiplicative-expression}
    1553 \rhs \nonterm{additive-expression} \lstinline@+@ \nonterm{multiplicative-expression}
    1554 \rhs \nonterm{additive-expression} \lstinline@-@ \nonterm{multiplicative-expression}
     1532\rhs \nonterm{additive-expression} ©+© \nonterm{multiplicative-expression}
     1533\rhs \nonterm{additive-expression} ©-© \nonterm{multiplicative-expression}
    15551534\end{syntax}
    15561535
     
    16111590        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    16121591\end{lstlisting}
    1613 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1592For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16141593% Don't use predefined: keep this out of prelude.cf.
    16151594\begin{lstlisting}
     
    16211600
    16221601\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.
     1602©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.
    16241603It 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.
     1604The {\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.
    16261605\end{rationale}
    16271606
     
    16321611\lhs{shift-expression}
    16331612\rhs \nonterm{additive-expression}
    1634 \rhs \nonterm{shift-expression} \lstinline@<<@ \nonterm{additive-expression}
    1635 \rhs \nonterm{shift-expression} \lstinline@>>@ \nonterm{additive-expression}
     1613\rhs \nonterm{shift-expression} ©<<© \nonterm{additive-expression}
     1614\rhs \nonterm{shift-expression} ©>>© \nonterm{additive-expression}
    16361615\end{syntax}
    16371616
     
    16511630long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    16521631\end{lstlisting}
    1653 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1632For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    16541633% Don't use predefined: keep this out of prelude.cf.
    16551634\begin{lstlisting}
     
    16711650\lhs{relational-expression}
    16721651\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}
     1652\rhs \nonterm{relational-expression} ©< © \nonterm{shift-expression}
     1653\rhs \nonterm{relational-expression} ©> © \nonterm{shift-expression}
     1654\rhs \nonterm{relational-expression} ©<=© \nonterm{shift-expression}
     1655\rhs \nonterm{relational-expression} ©>=© \nonterm{shift-expression}
    16771656\end{syntax}
    16781657
     
    17141693        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    17151694\end{lstlisting}
    1716 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1695For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17171696% Don't use predefined: keep this out of prelude.cf.
    17181697\begin{lstlisting}
     
    17321711\lhs{equality-expression}
    17331712\rhs \nonterm{relational-expression}
    1734 \rhs \nonterm{equality-expression} \lstinline@==@ \nonterm{relational-expression}
    1735 \rhs \nonterm{equality-expression} \lstinline@!=@ \nonterm{relational-expression}
     1713\rhs \nonterm{equality-expression} ©==© \nonterm{relational-expression}
     1714\rhs \nonterm{equality-expression} ©!=© \nonterm{relational-expression}
    17361715\end{syntax}
    17371716
     
    17921771        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    17931772\end{lstlisting}
    1794 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1773For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    17951774% Don't use predefined: keep this out of prelude.cf.
    17961775\begin{lstlisting}
     
    18001779
    18011780\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.
     1781The 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.
    18031782In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    18041783\end{rationale}
     
    18211800\lhs{AND-expression}
    18221801\rhs \nonterm{equality-expression}
    1823 \rhs \nonterm{AND-expression} \lstinline@&@ \nonterm{equality-expression}
     1802\rhs \nonterm{AND-expression} ©&© \nonterm{equality-expression}
    18241803\end{syntax}
    18251804
     
    18381817long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    18391818\end{lstlisting}
    1840 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1819For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18411820% Don't use predefined: keep this out of prelude.cf.
    18421821\begin{lstlisting}
     
    18531832\lhs{exclusive-OR-expression}
    18541833\rhs \nonterm{AND-expression}
    1855 \rhs \nonterm{exclusive-OR-expression} \lstinline@^@ \nonterm{AND-expression}
     1834\rhs \nonterm{exclusive-OR-expression} ©^© \nonterm{AND-expression}
    18561835\end{syntax}
    18571836
     
    18701849long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    18711850\end{lstlisting}
    1872 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1851For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    18731852% Don't use predefined: keep this out of prelude.cf.
    18741853\begin{lstlisting}
     
    18851864\lhs{inclusive-OR-expression}
    18861865\rhs \nonterm{exclusive-OR-expression}
    1887 \rhs \nonterm{inclusive-OR-expression} \lstinline@|@ \nonterm{exclusive-OR-expression}
     1866\rhs \nonterm{inclusive-OR-expression} ©|© \nonterm{exclusive-OR-expression}
    18881867\end{syntax}
    18891868
     
    19021881long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    19031882\end{lstlisting}
    1904 For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
     1883For every extended integer type ©X© with \Index{integer conversion rank} greater than the rank of ©int© there exist
    19051884% Don't use predefined: keep this out of prelude.cf.
    19061885\begin{lstlisting}
     
    19171896\lhs{logical-AND-expression}
    19181897\rhs \nonterm{inclusive-OR-expression}
    1919 \rhs \nonterm{logical-AND-expression} \lstinline@&&@ \nonterm{inclusive-OR-expression}
     1898\rhs \nonterm{logical-AND-expression} ©&&© \nonterm{inclusive-OR-expression}
    19201899\end{syntax}
    19211900
    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.
     1901\semantics The operands of the expression ``©a && b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b)!=0)©'', which shall both be unambiguous.
     1902The expression has only one interpretation, which is of type ©int©.
     1903\begin{rationale}
     1904When 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.
     1905
     1906A common C idiom omits comparisons to ©0© in the controlling expressions of loops and ©if© statements.
     1907For instance, the loop below iterates as long as ©rp© points at a ©Rational© value that is non-zero.
    19311908
    19321909\begin{lstlisting}
     
    19371914while ( rp && *rp ) { ... }
    19381915\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.
     1916The logical expression calls the ©Rational© inequality operator, passing it ©*rp© and the ©Rational 0©, and getting a 1 or 0 as a result.
     1917In contrast, {\CC} would apply a programmer-defined ©Rational©-to-©int© conversion to ©*rp© in the equivalent situation.
     1918The 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.
    19421919\end{rationale}
    19431920
     
    19481925\lhs{logical-OR-expression}
    19491926\rhs \nonterm{logical-AND-expression}
    1950 \rhs \nonterm{logical-OR-expression} \lstinline@||@ \nonterm{logical-AND-expression}
     1927\rhs \nonterm{logical-OR-expression} ©||© \nonterm{logical-AND-expression}
    19511928\end{syntax}
    19521929
    19531930\semantics
    19541931
    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@.
     1932The operands of the expression ``©a || b©'' are treated as ``©(int)((a)!=0)©'' and ``©(int)((b))!=0)©'', which shall both be unambiguous.
     1933The expression has only one interpretation, which is of type ©int©.
    19571934
    19581935
     
    19621939\lhs{conditional-expression}
    19631940\rhs \nonterm{logical-OR-expression}
    1964 \rhs \nonterm{logical-OR-expression} \lstinline@?@ \nonterm{expression}
    1965          \lstinline@:@ \nonterm{conditional-expression}
     1941\rhs \nonterm{logical-OR-expression} ©?© \nonterm{expression}
     1942         ©:© \nonterm{conditional-expression}
    19661943\end{syntax}
    19671944
    19681945\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
     1946In 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
    19701947\begin{lstlisting}
    19711948( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    19721949\end{lstlisting}
    19731950
    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
     1951If 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
    19751952\begin{lstlisting}
    19761953forall( otype T ) T cond( int, T, T );
     
    20242001rand() ? i : l;
    20252002\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@.
     2003The best interpretation infers the expression's type to be ©long© and applies the safe ©int©-to-©long© conversion to ©i©.
    20282004
    20292005\begin{lstlisting}
     
    20322008rand() ? cip : vip;
    20332009\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.
     2010The expression has type ©const volatile int *©, with safe conversions applied to the second and third operands to add ©volatile© and ©const© qualifiers, respectively.
    20352011
    20362012\begin{lstlisting}
    20372013rand() ? cip : 0;
    20382014\end{lstlisting}
    2039 The expression has type \lstinline@const int *@, with a specialization conversion applied to
    2040 \lstinline@0@.
     2015The expression has type ©const int *©, with a specialization conversion applied to ©0©.
    20412016
    20422017
     
    20492024         \nonterm{assignment-expression}
    20502025\lhs{assignment-operator} one of
    2051 \rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@-=@\ \ 
    2052          \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@|=@
     2026\rhs ©=©\ \ ©*=©\ \ ©/=©\ \ ©%=©\ \ ©+=©\ \ ©-=©\ \ 
     2027         ©<<=©\ \ ©>>=©\ \ ©&=©\ \ ©^=©\ \ ©|=©
    20532028\end{syntax}
    20542029
     
    20642039\semantics
    20652040Each 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.
     2041For 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.
    20672042The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    20682043For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     
    22972272\end{lstlisting}
    22982273\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
     2274The 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.
     2275\end{rationale}
     2276
     2277For every complete structure or union type ©S© there exist
    23032278% Don't use predefined: keep this out of prelude.cf.
    23042279\begin{lstlisting}
     
    23062281\end{lstlisting}
    23072282
    2308 For every extended integer type \lstinline@X@ there exist
     2283For every extended integer type ©X© there exist
    23092284% Don't use predefined: keep this out of prelude.cf.
    23102285\begin{lstlisting}
     
    23122287\end{lstlisting}
    23132288
    2314 For every complete enumerated type \lstinline@E@ there exist
     2289For every complete enumerated type ©E© there exist
    23152290% Don't use predefined: keep this out of prelude.cf.
    23162291\begin{lstlisting}
     
    23182293\end{lstlisting}
    23192294\begin{rationale}
    2320 The right-hand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.
     2295The right-hand argument is ©int© because enumeration constants have type ©int©.
    23212296\end{rationale}
    23222297
     
    25792554\end{lstlisting}
    25802555
    2581 For every extended integer type \lstinline@X@ there exist
     2556For every extended integer type ©X© there exist
    25822557% Don't use predefined: keep this out of prelude.cf.
    25832558\begin{lstlisting}
     
    25942569\end{lstlisting}
    25952570
    2596 For every complete enumerated type \lstinline@E@ there exist
     2571For every complete enumerated type ©E© there exist
    25972572% Don't use predefined: keep this out of prelude.cf.
    25982573\begin{lstlisting}
     
    26152590\lhs{expression}
    26162591\rhs \nonterm{assignment-expression}
    2617 \rhs \nonterm{expression} \lstinline@,@ \nonterm{assignment-expression}
     2592\rhs \nonterm{expression} ©,© \nonterm{assignment-expression}
    26182593\end{syntax}
    26192594
    26202595\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}.
     2596In the comma expression ``©a, b©'', the first operand is interpreted as ``©( void )(a)©'', which shall be unambiguous\index{ambiguous interpretation}.
    26232597The interpretations of the expression are the interpretations of the second operand.
    26242598
     
    26552629{ ... }
    26562630\end{lstlisting}
    2657 Without the rule, \lstinline@Complex@ would be a type in the first case, and a parameter name in the second.
     2631Without the rule, ©Complex© would be a type in the first case, and a parameter name in the second.
    26582632\end{rationale}
    26592633
     
    27122686\begin{syntax}
    27132687\lhs{forall-specifier}
    2714 \rhs \lstinline@forall@ \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
     2688\rhs ©forall© ©(© \nonterm{type-parameter-list} ©)©
    27152689\end{syntax}
    27162690
     
    27242698} mkPair( T, T ); // illegal
    27252699\end{lstlisting}
    2726 If an instance of \lstinline@struct Pair@ was declared later in the current scope, what would the members' type be?
     2700If an instance of ©struct Pair© was declared later in the current scope, what would the members' type be?
    27272701\end{rationale}
    27282702\end{comment}
     
    27312705The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    27322706
    2733 If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forall-specifier}s and
    2734 \lstinline@D@ has the form
     2707If, in the declaration ``©T D©'', ©T© contains \nonterm{forall-specifier}s and ©D© has the form
    27352708\begin{lstlisting}
    27362709D( §\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
     2710\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
    27382711\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    27392712\Index{specification} in one of the \nonterm{forall-specifier}s.
     
    27482721forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
    27492722\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@:
     2723Here ©alloc()© would receive ©int© as an inferred argument, and return an ©int *©.
     2724In 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.
     2725
     2726With the current restriction, ©alloc()© must be given an argument that determines ©T©:
    27562727\begin{lstlisting}
    27572728forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
     
    27802751forall( otype T ) T fT( T );
    27812752\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@.
     2753©fi()© takes an ©int© and returns an ©int©. ©fT()© takes a ©T© and returns a ©T©, for any type ©T©.
    27842754\begin{lstlisting}
    27852755int (*pfi )( int ) = fi;
    27862756forall( otype T ) T (*pfT )( T ) = fT;
    27872757\end{lstlisting}
    2788 \lstinline@pfi@ and \lstinline@pfT@ are pointers to functions. \lstinline@pfT@ is not polymorphic, but the function it points at is.
     2758©pfi© and ©pfT© are pointers to functions. ©pfT© is not polymorphic, but the function it points at is.
    27892759\begin{lstlisting}
    27902760int (*fvpfi( void ))( int ) {
     
    27952765}
    27962766\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.
     2767©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.
    27982768\begin{lstlisting}
    27992769forall( otype T ) int ( *fTpfi( T ) )( int );
     
    28012771forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    28022772\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 *@.
     2773©fTpfi()© is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2774It could return ©pfi©. ©fTpfT()© is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2775©T©, where ©T© is an inferred parameter of ©fTpfT()©.
     2776For 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.
     2777©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 *©.
    28102778\begin{lstlisting}
    28112779forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    28122780forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    28132781\end{lstlisting}
    2814 The functions \lstinline@f()@ and \lstinline@g()@ have compatible types.
     2782The functions ©f()© and ©g()© have compatible types.
    28152783Let \(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@.
     2784then \(f_1\) = ©T©, \(f_2\) = ©U©, \(f_3\) = ©V©, \(g_1\)
     2785= ©V©, \(g_2\) = ©U©, and \(g_3\) = ©W©.
    28182786Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    28192787\begin{lstlisting}
     
    28212789\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    28222790\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.
     2791The 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.
    28242792
    28252793Even without parameterized types, I might try to allow
     
    28472815\subsection{Type qualifiers}
    28482816
    2849 \CFA defines a new type qualifier \lstinline@lvalue@\impl{lvalue}\index{lvalue}.
     2817\CFA defines a new type qualifier ©lvalue©\impl{lvalue}\index{lvalue}.
    28502818\begin{syntax}
    28512819\oldlhs{type-qualifier}
    2852 \rhs \lstinline@lvalue@
     2820\rhs ©lvalue©
    28532821\end{syntax}
    28542822
     
    28582826\semantics
    28592827An object's type may be a restrict-qualified type parameter.
    2860 \lstinline@restrict@ does not establish any special semantics in that case.
     2828©restrict© does not establish any special semantics in that case.
    28612829
    28622830\begin{rationale}
     
    28642832\end{rationale}
    28652833
    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.
     2834©lvalue© may be used to qualify the return type of a function type.
     2835Let ©T© be an unqualified version of a type;
     2836then the result of calling a function with return type ©lvalue T© is a \Index{modifiable lvalue} of type ©T©.
     2837©const©\use{const} and ©volatile©\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     2838\begin{rationale}
     2839The ©const© and ©volatile© qualifiers can only be sensibly used to qualify the return type of a function if the ©lvalue© qualifier is also used.
    28732840\end{rationale}
    28742841
     
    28772844
    28782845\begin{rationale}
    2879 \lstinline@lvalue@ provides some of the functionality of {\CC}'s ``\lstinline@T&@'' ( reference to object of type \lstinline@T@) type.
     2846©lvalue© provides some of the functionality of {\CC}'s ``©T&©'' ( reference to object of type ©T©) type.
    28802847Reference types have four uses in {\CC}.
    28812848\begin{itemize}
     
    28842851
    28852852\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.
     2853A 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.
    28872854The following {\CC} code gives an example.
    28882855\begin{lstlisting}
     
    28972864A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    28982865This 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
     2866In {\CC}, plain assignment is done by a function called ``©operator=©'', and the two expressions
    29002867\begin{lstlisting}
    29012868a = b;
    29022869operator=( a, b );
    29032870\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@&@''.
     2871If ©a© and ©b© are of type ©T©, then the first parameter of ©operator=© must have type ``©T&©''.
     2872It 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;©''.
     2873
     2874In 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 )©''.
     2875Reference 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 ``©&©''.
    29122876
    29132877\item
    29142878References 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
     2879{\CC} function call ``©fiddle( a_thing )©'', where the type of ©a_thing© is
     2880©Thing©, the type of ©fiddle© could be either of
    29172881\begin{lstlisting}
    29182882void fiddle( Thing );
    29192883void fiddle( const Thing & );
    29202884\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.
     2885If 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.
     2886The reference form might be chosen for efficiency's sake if ©Thing©s are too large or their constructors or destructors are too expensive.
    29232887An implementation may switch between them without causing trouble for well-behaved clients.
    29242888This leaves the implementor to define ``too large'' and ``too expensive''.
     
    29282892void fiddle( const volatile Thing );
    29292893\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''.
     2894Since 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''.
    29312895\end{itemize}
    29322896
     
    29482912\begin{syntax}
    29492913\lhs{spec-definition}
    2950 \rhs \lstinline@spec@ \nonterm{identifier}
    2951         \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
    2952         \lstinline@{@ \nonterm{spec-declaration-list}\opt \lstinline@}@
     2914\rhs ©spec© \nonterm{identifier}
     2915        ©(© \nonterm{type-parameter-list} ©)©
     2916        ©{© \nonterm{spec-declaration-list}\opt ©}©
    29532917\lhs{spec-declaration-list}
    2954 \rhs \nonterm{spec-declaration} \lstinline@;@
    2955 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline@;@
     2918\rhs \nonterm{spec-declaration} ©;©
     2919\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} ©;©
    29562920\lhs{spec-declaration}
    29572921\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    29582922\lhs{declarator-list}
    29592923\rhs \nonterm{declarator}
    2960 \rhs \nonterm{declarator-list} \lstinline@,@ \nonterm{declarator}
     2924\rhs \nonterm{declarator-list} ©,© \nonterm{declarator}
    29612925\end{syntax}
    29622926\begin{rationale}
     
    29802944\rhs \nonterm{assertion-list} \nonterm{assertion}
    29812945\lhs{assertion}
    2982 \rhs \lstinline@|@ \nonterm{identifier} \lstinline@(@ \nonterm{type-name-list} \lstinline@)@
    2983 \rhs \lstinline@|@ \nonterm{spec-declaration}
     2946\rhs ©|© \nonterm{identifier} ©(© \nonterm{type-name-list} ©)©
     2947\rhs ©|© \nonterm{spec-declaration}
    29842948\lhs{type-name-list}
    29852949\rhs \nonterm{type-name}
    2986 \rhs \nonterm{type-name-list} \lstinline@,@ \nonterm{type-name}
     2950\rhs \nonterm{type-name-list} ©,© \nonterm{type-name}
    29872951\end{syntax}
    29882952
     
    29912955The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    29922956If 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}.
     2957\nonterm{type-parameter} uses type-class ©type©\use{type}, the argument shall be the type name of an \Index{object type};
     2958if it uses ©dtype©, the argument shall be the type name of an object type or an \Index{incomplete type};
     2959and if it uses ©ftype©, the argument shall be the type name of a \Index{function type}.
    29962960
    29972961\semantics
     
    30232987trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    30242988\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
     2989©sum_list© contains seven declarations, which describe a list whose elements can be added up.
     2990The assertion ``©|sum_list( i_list, int )©''\use{sum_list} produces the assertion parameters
    30272991\begin{lstlisting}
    30282992int ?+=?( int *, int );
     
    30413005\lhs{type-parameter-list}
    30423006\rhs \nonterm{type-parameter}
    3043 \rhs \nonterm{type-parameter-list} \lstinline@,@ \nonterm{type-parameter}
     3007\rhs \nonterm{type-parameter-list} ©,© \nonterm{type-parameter}
    30443008\lhs{type-parameter}
    30453009\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    30463010\lhs{type-class}
    3047 \rhs \lstinline@type@
    3048 \rhs \lstinline@dtype@
    3049 \rhs \lstinline@ftype@
     3011\rhs ©type©
     3012\rhs ©dtype©
     3013\rhs ©ftype©
    30503014\lhs{type-declaration}
    3051 \rhs \nonterm{storage-class-specifier}\opt \lstinline@type@ \nonterm{type-declarator-list} \verb|;|
     3015\rhs \nonterm{storage-class-specifier}\opt ©type© \nonterm{type-declarator-list} \verb|;|
    30523016\lhs{type-declarator-list}
    30533017\rhs \nonterm{type-declarator}
    3054 \rhs \nonterm{type-declarator-list} \lstinline@,@ \nonterm{type-declarator}
     3018\rhs \nonterm{type-declarator-list} ©,© \nonterm{type-declarator}
    30553019\lhs{type-declarator}
    3056 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline@=@ \nonterm{type-name}
     3020\rhs \nonterm{identifier} \nonterm{assertion-list}\opt ©=© \nonterm{type-name}
    30573021\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    30583022\end{syntax}
     
    30653029
    30663030An 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.
     3031Identifiers declared with type-class ©type©\use{type} are \Index{object type}s;
     3032those declared with type-class ©dtype©\use{dtype} are \Index{incomplete type}s;
     3033and those declared with type-class ©ftype©\use{ftype} are \Index{function type}s.
    30723034The 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}.
    30733035
     
    30773039Within 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.
    30783040
    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}.
     3041A 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}.
    30803042If a
    30813043\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).
     
    30963058\end{rationale}
    30973059
    3098 A type declaration without an initializer and with \Index{storage-class specifier}
    3099 \lstinline@extern@\use{extern} is an \define{opaque type declaration}.
     3060A type declaration without an initializer and with \Index{storage-class specifier} ©extern©\use{extern} is an \define{opaque type declaration}.
    31003061Opaque types are
    31013062\Index{object type}s.
     
    31123073\end{rationale}
    31133074
    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@.
     3075An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} ©dtype©.
     3076An object type\index{object types} which is not a qualified version of a type is a value of type-classes ©type© and ©dtype©.
    31163077A
    3117 \Index{function type} is a value of type-class \lstinline@ftype@.
     3078\Index{function type} is a value of type-class ©ftype©.
    31183079\begin{rationale}
    31193080Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     
    31243085
    31253086Type 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.
     3087Consider 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.
    31283088\begin{lstlisting}
    31293089char *strchr( const char *s, int c ) {§\impl{strchr}§
     
    31343094}
    31353095\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.
     3096The 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.
     3097Hence the body must perform a cast, and ( even worse) ©strchr()© provides a type-safe way to attempt to modify constant strings.
     3098What is needed is some way to say that ©s©'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    31403099Polymorphic 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.
     3100Instead, overloading can be used to define ©strchr()© for each combination of qualifiers.
    31423101\end{rationale}
    31433102
     
    31633122};
    31643123\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@.
     3124Without 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©.
    31673125
    31683126A 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.
     
    31813139\nonterm{struct-declaration}, type declarations can not be structure members.
    31823140The form of
    3183 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.
     3141\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning ©type©.
    31843142Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    31853143It also side-steps the problem of type-valued expressions producing different values in different declarations.
     
    31983156§\ldots§ int * ip = new( int );
    31993157\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@;
     3158This 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©;
    32013159it could be undefined, or a type name, or a function or variable name.
    32023160Nothing good can result from such a situation.
     
    32153173f2( v2 );
    32163174\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]@.
     3175©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]©.
    32183176
    32193177A translation unit containing the declarations
     
    32213179extern type Complex;§\use{Complex}§ // opaque type declaration
    32223180extern 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@.
     3181\end{lstlisting} can contain declarations of complex numbers, which can be passed to ©abs©.
     3182Some other translation unit must implement ©Complex© and ©abs©.
    32253183That unit might contain the declarations
    32263184\begin{lstlisting}
     
    32313189}
    32323190\end{lstlisting}
    3233 Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@ so that its components can be retrieved.
     3191Note that ©c© is implicitly converted to a ©struct© so that its components can be retrieved.
    32343192
    32353193\begin{lstlisting}
     
    32393197}
    32403198\end{lstlisting}
    3241 \lstinline@t1@ must be cast to its implementation type to prevent infinite recursion.
     3199©t1© must be cast to its implementation type to prevent infinite recursion.
    32423200
    32433201\begin{rationale}
    32443202Within 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.
     3203In the ©Time_of_day© example, the difference is important.
    32463204Different languages have treated the distinction between the abstraction and the implementation in different ways.
    32473205\begin{itemize}
    32483206\item
    32493207Inside 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.
     3208Two primitives called ©up© and ©down© can be used to convert between the views.
    32513209\item
    32523210The Simula class \cite{SIMULA87} is essentially a record type.
    32533211Since 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.
    32543212In {\CC}
    3255 \cite{C++}, operations on class instances include assignment and ``\lstinline@&@'', which can be overloaded.
     3213\cite{C++}, operations on class instances include assignment and ``©&©'', which can be overloaded.
    32563214A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    32573215\item
     
    32663224In this case, explicit conversions between the derived type and the old type can be used.
    32673225\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@.
     3226\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©.
    32693227\end{rationale}
    32703228
     
    32723230\subsubsection{Default functions and objects}
    32733231
    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@.
     3232A 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©.
    32773233\begin{rationale}
    32783234Assignment 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).
    32793235Without 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.
     3236If a type parameter should not have an assignment operation, ©dtype© should be used.
    32823237If 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.
    32833238\end{rationale}
    32843239
    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
     3240A definition\index{type definition} of a type identifier ©T© with \Index{implementation type} ©I© and type-class ©type© implicitly defines a default assignment function.
     3241A definition\index{type definition} of a type identifier ©T© with implementation type ©I© and an assertion list implicitly defines \define{default function}s and
    32873242\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@.
     3243The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier ©T©.
    32893244Their values are determined as follows:
    32903245\begin{itemize}
    32913246\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.
     3247If 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.
     3248Otherwise the scope of the declaration of ©T© must contain a definition of the default object.
    32943249
    32953250\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.
     3251If at the definition of ©T© there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of ©I© replaced by ©T© is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
     3252
     3253Otherwise, if ©I© contains exactly one anonymous member\index{anonymous member} such that at the definition of ©T© there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by ©T© is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
     3254
     3255Otherwise the scope of the declaration of ©T© must contain a definition of the default function.
    33013256\end{itemize}
    33023257\begin{rationale}
     
    33043259\end{rationale}
    33053260
    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.
     3261A 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.
    33073262
    33083263\examples
     
    33143269Pair b = { 1, 1 };
    33153270\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.
     3271The definition of ©Pair© implicitly defines two objects ©a© and ©b©.
     3272©Pair a© inherits its value from the ©struct impl a©.
     3273The definition of ©Pair b© is compulsory because there is no ©struct impl b© to construct a value from.
    33203274\begin{lstlisting}
    33213275trait ss( otype T ) {
     
    33303284Doodad clone( Doodad ) { ... }
    33313285\end{lstlisting}
    3332 The definition of \lstinline@Doodad@ implicitly defines three functions:
     3286The definition of ©Doodad© implicitly defines three functions:
    33333287\begin{lstlisting}
    33343288Doodad ?=?( Doodad *, Doodad );
     
    33363290void munge( Doodad * );
    33373291\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.
     3292The assignment function inherits ©struct doodad©'s assignment function because the types match when ©struct doodad©  is replaced by ©Doodad© throughout.
     3293©munge()© inherits ©Whatsit©'s ©munge()© because the types match when ©Whatsit© is replaced by ©Doodad© in the parameter list. ©clone()© does \emph{not} inherit ©Whatsit©'s ©clone()©: replacement in the parameter list yields ``©Whatsit clone( Doodad )©'', which is not compatible with ©Doodad©'s ©clone()©'s type.
     3294Hence the definition of ``©Doodad clone( Doodad )©'' is necessary.
    33443295
    33453296Default functions and objects are subject to the normal scope rules.
     
    33813332\begin{syntax}
    33823333\oldlhs{labeled-statement}
    3383 \rhs \lstinline@case@ \nonterm{case-value-list} : \nonterm{statement}
     3334\rhs ©case© \nonterm{case-value-list} : \nonterm{statement}
    33843335\lhs{case-value-list}
    33853336\rhs \nonterm{case-value}
    3386 \rhs \nonterm{case-value-list} \lstinline@,@ \nonterm{case-value}
     3337\rhs \nonterm{case-value-list} ©,© \nonterm{case-value}
    33873338\lhs{case-value}
    33883339\rhs \nonterm{constant-expression}
    33893340\rhs \nonterm{subrange}
    33903341\lhs{subrange}
    3391 \rhs \nonterm{constant-expression} \lstinline@~@ \nonterm{constant-expression}
     3342\rhs \nonterm{constant-expression} ©~© \nonterm{constant-expression}
    33923343\end{syntax}
    33933344
     
    34023353case 1~4, 9~14, 27~32:
    34033354\end{lstlisting}
    3404 The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@ statements, precluding Duff's device.
     3355The ©case© and ©default© clauses are restricted within the ©switch© and ©choose© statements, precluding Duff's device.
    34053356
    34063357
    34073358\subsection{Expression and null statements}
    34083359
    3409 The expression in an expression statement is treated as being cast to \lstinline@void@.
     3360The expression in an expression statement is treated as being cast to ©void©.
    34103361
    34113362
     
    34143365\begin{syntax}
    34153366\oldlhs{selection-statement}
    3416 \rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@ \nonterm{statement}
     3367\rhs ©choose© ©(© \nonterm{expression} ©)© \nonterm{statement}
    34173368\end{syntax}
    34183369
    3419 The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@ statement:
     3370The controlling expression ©E© in the ©switch© and ©choose© statement:
    34203371\begin{lstlisting}
    34213372switch ( E ) ...
     
    34233374\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    34243375An \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.
     3376The constant expressions in ©case© statements with the switch are converted to the promoted type.
    34263377
    34273378
     
    34293380\subsubsection[The choose statement]{The \lstinline@choose@ statement}
    34303381
    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.
     3382The ©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.
     3383The ©fallthru© statement is used to fall through to the next ©case© or ©default© labeled statement.
    34333384The following have identical meaning:
    34343385\begin{flushleft}
     
    34553406\end{tabular}
    34563407\end{flushleft}
    3457 The \lstinline@choose@ statement addresses the problem of accidental fall-through associated with the \lstinline@switch@ statement.
     3408The ©choose© statement addresses the problem of accidental fall-through associated with the ©switch© statement.
    34583409
    34593410
    34603411\subsection{Iteration statements}
    34613412
    3462 The controlling expression \lstinline@E@ in the loops
     3413The controlling expression ©E© in the loops
    34633414\begin{lstlisting}
    34643415if ( E ) ...
    34653416while ( E ) ...
    34663417do ... while ( E );
    3467 \end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''.
     3418\end{lstlisting}
     3419is treated as ``©( int )((E)!=0)©''.
    34683420
    34693421The statement
     
    34803432\begin{syntax}
    34813433\oldlhs{jump-statement}
    3482 \rhs \lstinline@continue@ \nonterm{identifier}\opt
    3483 \rhs \lstinline@break@ \nonterm{identifier}\opt
     3434\rhs ©continue© \nonterm{identifier}\opt
     3435\rhs ©break© \nonterm{identifier}\opt
    34843436\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}
     3437\rhs ©throw© \nonterm{assignment-expression}\opt
     3438\rhs ©throwResume© \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     3439\lhs{at-expression} ©_At© \nonterm{assignment-expression}
    34883440\end{syntax}
    34893441
    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.
     3442Labeled ©continue© and ©break© allow useful but restricted control-flow that reduces the need for the ©goto© statement for exiting multiple nested control-structures.
    34913443\begin{lstlisting}
    34923444L1: {                                                   // compound
     
    35173469\subsubsection[The continue statement]{The \lstinline@continue@ statement}
    35183470
    3519 The identifier in a \lstinline@continue@ statement shall name a label located on an enclosing iteration statement.
     3471The identifier in a ©continue© statement shall name a label located on an enclosing iteration statement.
    35203472
    35213473
    35223474\subsubsection[The break statement]{The \lstinline@break@ statement}
    35233475
    3524 The identifier in a \lstinline@break@ statement shall name a label located on an enclosing compound, selection or iteration statement.
     3476The identifier in a ©break© statement shall name a label located on an enclosing compound, selection or iteration statement.
    35253477
    35263478
    35273479\subsubsection[The return statement]{The \lstinline@return@ statement}
    35283480
    3529 An expression in a \lstinline@return@ statement is treated as being cast to the result type of the function.
     3481An expression in a ©return© statement is treated as being cast to the result type of the function.
    35303482
    35313483
     
    35423494\begin{syntax}
    35433495\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}
     3496\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list}
     3497\rhs ©try© \nonterm{compound-statement} \nonterm{finally-clause}
     3498\rhs ©try© \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    35473499\lhs{handler-list}
    35483500\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}
     3501\rhs ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3502\rhs \nonterm{handler-clause} ©catch© ©(© \ldots ©)© \nonterm{compound-statement}
     3503\rhs ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
     3504\rhs \nonterm{handler-clause} ©catchResume© ©(© \ldots ©)© \nonterm{compound-statement}
    35533505\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}
     3506\rhs ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3507\rhs \nonterm{handler-clause} ©catch© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3508\rhs ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
     3509\rhs \nonterm{handler-clause} ©catchResume© ©(© \nonterm{exception-declaration} ©)© \nonterm{compound-statement}
    35583510\lhs{finally-clause}
    3559 \rhs \lstinline@finally@ \nonterm{compound-statement}
     3511\rhs ©finally© \nonterm{compound-statement}
    35603512\lhs{exception-declaration}
    35613513\rhs \nonterm{type-specifier}
     
    35653517\rhs \nonterm{new-abstract-declarator-tuple}
    35663518\lhs{asynchronous-statement}
    3567 \rhs \lstinline@enable@ \nonterm{identifier-list} \nonterm{compound-statement}
    3568 \rhs \lstinline@disable@ \nonterm{identifier-list} \nonterm{compound-statement}
     3519\rhs ©enable© \nonterm{identifier-list} \nonterm{compound-statement}
     3520\rhs ©disable© \nonterm{identifier-list} \nonterm{compound-statement}
    35693521\end{syntax}
    35703522
     
    35743526\subsubsection[The try statement]{The \lstinline@try@ statement}
    35753527
    3576 The \lstinline@try@ statement is a block with associated handlers, called a \Index{guarded block};
     3528The ©try© statement is a block with associated handlers, called a \Index{guarded block};
    35773529all 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.
     3530A ©goto©, ©break©, ©return©, or ©continue© statement can be used to transfer control out of a try block or handler, but not into one.
    35793531
    35803532
    35813533\subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
    35823534
    3583 The \lstinline@enable@/\lstinline@disable@ statements toggle delivery of \Index{asynchronous exception}s.
     3535The ©enable©/©disable© statements toggle delivery of \Index{asynchronous exception}s.
    35843536
    35853537
     
    35913543\subsection{Predefined macro names}
    35923544
    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.
     3545The implementation shall define the macro names ©__LINE__©, ©__FILE__©, ©__DATE__©, and ©__TIME__©, as in the {\c11} standard.
     3546It shall not define the macro name ©__STDC__©.
     3547
     3548In addition, the implementation shall define the macro name ©__CFORALL__© to be the decimal constant 1.
    35983549
    35993550
     
    36123563The pointer, integral, and floating-point types are all \define{scalar types}.
    36133564All of these types can be logically negated and compared.
    3614 The assertion ``\lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@ is scalar''.
     3565The assertion ``©scalar( Complex )©'' should be read as ``type ©Complex© is scalar''.
    36153566\begin{lstlisting}
    36163567trait scalar( otype T ) {§\impl{scalar}§
     
    36303581\end{lstlisting}
    36313582
    3632 The various flavors of \lstinline@char@ and \lstinline@int@ and the enumerated types make up the
     3583The various flavors of ©char© and ©int© and the enumerated types make up the
    36333584\define{integral types}.
    36343585\begin{lstlisting}
     
    36643615
    36653616Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3666 Note that this results in the ``inheritance'' of \lstinline@scalar@ along both paths.
     3617Note that this results in the ``inheritance'' of ©scalar© along both paths.
    36673618\begin{lstlisting}
    36683619trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
     
    36793630\subsection{Pointer and array types}
    36803631
    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.
     3632Array 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 )))©''.
     3633Technically, 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.
    36853634Consequently, there is no need for a separate ``array type'' specification.
    36863635
    36873636Pointer 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@.
     3637Like 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©.
    36913638\begin{lstlisting}
    36923639trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
     
    37033650Specifications 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.
    37043651Different 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@''.
     3652The assertion ``©|ptr_to( Safe_pointer, int )©'' should be read as ``©Safe_pointer© acts like a pointer to ©int©''.
    37073653\begin{lstlisting}
    37083654trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
     
    37243670\end{lstlisting}
    37253671
    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.
     3672Assignment 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 *©''.
     3673Again, the pointed-at type is passed in, so that assertions can connect these specifications to the ``©ptr_to©'' specifications.
    37293674\begin{lstlisting}
    37303675trait 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}§ {
     
    37553700};
    37563701\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.
     3702The assertion ``©| m_l_ptr_like( Safe_ptr, const int * )©'' should be read as ``©Safe_ptr© is a pointer type like ©const int *©''.
     3703This 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.
    37623704
    37633705
     
    37653707
    37663708Different operators often have related meanings;
    3767 for instance, in C, ``\lstinline@+@'',
    3768 ``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition.
     3709for instance, in C, ``©+©'', ``©+=©'', and the two versions of ``©++©'' perform variations of addition.
    37693710Languages 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.
    37703711Completeness and consistency is left to the good taste and discretion of the programmer.
     
    37793720The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    37803721However, 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.
     3722the library function ©strcmp© is an example.
     3723
     3724C and \CFA have an extra, non-obvious comparison operator: ``©!©'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    37843725\begin{lstlisting}
    37853726trait comparable( otype T ) {
     
    38293770\end{lstlisting}
    38303771
    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@.
     3772Note 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©.
    38333773Note 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!
     3774A truly minimal implementation of an arithmetic type might only provide ©0©, ©1©, and ©?-=?©, which would be used by polymorphic ©?+=?©, ©?*=?©, and ©?/=?© functions.
     3775
     3776Note also that ©short© is an integer type in C11 terms, but has no operations!
    38373777
    38383778
     
    38413781
    38423782Restrict 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.
     3783This gets into ©noalias© territory.
     3784Qualifying anything (``©short restrict rs©'') means pointer parameters of ©?++©, etc, would need restrict qualifiers.
    38453785
    38463786Enumerated types.
     
    38523792Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    38533793
    3854 Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@ harmless;
     3794Operators on {,signed,unsigned} char and other small types. ©?<?© harmless;
    38553795?*? questionable for chars.
    38563796Generic 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.
     3797Safe conversion operators? Predefined ``promotion'' function?
     3798
     3799©register© assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
     3800
     3801Don't use ©ptrdiff_t© by name in the predefineds.
    38633802
    38643803Polymorphic objects.
  • doc/user/user.tex

    re945826 r0638c44  
    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/fstream_test.c

    re945826 r0638c44  
    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/sum.c

    re945826 r0638c44  
    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.