Changeset e945826 for doc/refrat


Ignore:
Timestamp:
Apr 30, 2016, 2:05:06 PM (9 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, gc_noraii, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
0638c44, 1048b31, fbfde843
Parents:
8bc4ef8
Message:

formatting in iostream.c, and change escape sequences in documentation

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/refrat/refrat.tex

    r8bc4ef8 re945826  
    1111%% Created On       : Wed Apr  6 14:52:25 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sat Apr  9 10:19:12 2016
    14 %% Update Count     : 8
     13%% Last Modified On : Sat Apr 30 13:45:40 2016
     14%% Update Count     : 29
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    1717% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
     18
     19% red highlighting ®...® (registered trademark sumbol)
     20% blue highlighting ©...© (copyright symbol)
     21% latex escape §...§ (section symbol)
     22% keyword escape ¶...¶ (pilcrow symbol)
     23% math escape $...$ (dollar symbol)
    1824
    1925\documentclass[openright,twoside]{report}
     
    125131\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
    126132\Index{name space}, instead of hiding them.
    127 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
    128 \lstinline$typedef$\use{typedef} declaration and the other is not.  The outer declaration becomes
     133The outer declaration is hidden if the two declarations have \Index{compatible type}, or if one declares an array type and the other declares a pointer type and the element type and pointed-at type are compatible, or if one has function type and the other is a pointer to a compatible function type, or if one declaration is a \lstinline@type@\use{type} or
     134\lstinline@typedef@\use{typedef} declaration and the other is not.  The outer declaration becomes
    129135\Index{visible} when the scope of the inner declaration terminates.
    130136\begin{rationale}
    131 Hence, a \CFA program can declare an \lstinline$int v$ and a \lstinline$float v$ in the same scope;
     137Hence, a \CFA program can declare an \lstinline@int v@ and a \lstinline@float v@ in the same scope;
    132138a {\CC} program can not.
    133139\end{rationale}
     
    143149Identifiers with \Index{no linkage} always denote unique entities.
    144150\begin{rationale}
    145 A \CFA program can declare an \lstinline$extern int v$ and an \lstinline$extern float v$;
     151A \CFA program can declare an \lstinline@extern int v@ and an \lstinline@extern float v@;
    146152a C program cannot.
    147153\end{rationale}
     
    166172\end{lstlisting}
    167173
    168 The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline$sumable$.
     174The type parameters in an instantiation of a generic type must satisfy any constraints in the forall specifier on the type generator declaration, e.g., \lstinline@sumable@.
    169175The instantiation then has the semantics that would result if the type parameters were substituted into the type generator declaration by macro substitution.
    170176
     
    227233In \CFA, these conversions play a role in overload resolution, and collectively are called the \define{safe arithmetic conversion}s.
    228234
    229 Let \(int_r\) and \(unsigned_r\) be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
    230 Let \(unsigned_{mr}\) be the unsigned integer type with maximal rank.
     235Let \lstinline@int$_r$@ and \lstinline@unsigned$_r$@ be the signed and unsigned integer types with integer conversion rank\index{integer conversion rank}\index{rank|see{integer conversion rank}} $r$.
     236Let \lstinline@unsigned$_{mr}$@ be the unsigned integer type with maximal rank.
    231237
    232238The following conversions are \emph{direct} safe arithmetic conversions.
     
    235241The \Index{integer promotion}s.
    236242\item
    237 For every rank $r$ greater than or equal to the rank of \lstinline$int$, conversion from \(int_r\) to \(unsigned_r\).
    238 \item
    239 For every rank $r$ greater than or equal to the rank of \lstinline$int$, where \(int_{r+1}\) exists and can represent all values of \(unsigned_r\), conversion from \(unsigned_r\) to \(int_{r+1}\).
    240 \item
    241 Conversion from \(unsigned_{mr}\) to \lstinline$float$.
     243For every rank $r$ greater than or equal to the rank of \lstinline@int@, conversion from \lstinline@int$_r$@ to \lstinline@unsigned$_r$@.
     244\item
     245For every rank $r$ greater than or equal to the rank of \lstinline@int@, where \lstinline@int$_{r+1}$@ exists and can represent all values of \lstinline@unsigned$_r$@, conversion from \lstinline@unsigned$_r$@ to \lstinline@int$_{r+1}$@.
     246\item
     247Conversion from \lstinline@unsigned$_{mr}$@ to \lstinline@float@.
    242248\item
    243249Conversion from an enumerated type to its compatible integer type.
    244250\item
    245 Conversion from \lstinline$float$ to \lstinline$double$, and from \lstinline$double$ to \lstinline$long double$.
    246 \item
    247 Conversion from \lstinline$float _Complex$ to \lstinline$double _Complex$, and from \lstinline$double _Complex$ to \lstinline$long double _Complex$.
     251Conversion from \lstinline@float@ to \lstinline@double@, and from \lstinline@double@ to \lstinline@long double@.
     252\item
     253Conversion from \lstinline@float _Complex@ to \lstinline@double _Complex@, and from \lstinline@double _Complex@ to \lstinline@long double _Complex@.
    248254\begin{sloppypar}
    249255\item
    250 Conversion from \lstinline$float _Imaginary$ to \lstinline$double _Imaginary$, and from \lstinline$double _Imaginary$ to \lstinline$long double$ \lstinline$_Imaginary$, if the implementation supports imaginary types.
     256Conversion from \lstinline@float _Imaginary@ to \lstinline@double _Imaginary@, and from \lstinline@double _Imaginary@ to \lstinline@long double _Imaginary@, if the implementation supports imaginary types.
    251257\end{sloppypar}
    252258\end{itemize}
    253259
    254 If type \lstinline$T$ can be converted to type \lstinline$U$ by a safe direct arithmetic conversion and type \lstinline$U$ can be converted to type \lstinline$V$ by a safe arithmetic conversion, then the conversion from \lstinline$T$ to type \lstinline$V$ is an \emph{indirect} safe arithmetic conversion.
     260If type \lstinline@T@ can be converted to type \lstinline@U@ by a safe direct arithmetic conversion and type \lstinline@U@ can be converted to type \lstinline@V@ by a safe arithmetic conversion, then the conversion from \lstinline@T@ to type \lstinline@V@ is an \emph{indirect} safe arithmetic conversion.
    255261
    256262\begin{rationale}
     
    275281        int x, y;
    276282};
    277 void move_by( struct point * p1, struct point * p2 ) {@\impl{move_by}@
     283void move_by( struct point * p1, struct point * p2 ) {§\impl{move_by}§
    278284        p1->x += p2.x;
    279285        p1->y += p2.y;
     
    285291move_to( &cp1, &cp2 );
    286292\end{lstlisting}
    287 Thanks to implicit conversion, the two arguments that \lstinline$move_by()$ receives are pointers to
    288 \lstinline$cp1$'s second member and \lstinline$cp2$'s second member.
     293Thanks to implicit conversion, the two arguments that \lstinline@move_by()@ receives are pointers to
     294\lstinline@cp1@'s second member and \lstinline@cp2@'s second member.
    289295
    290296
     
    328334a direct safe arithmetic conversion;
    329335\item
    330 from any object type or incomplete type to \lstinline$void$;
    331 \item
    332 from a pointer to any non-\lstinline$void$ type to a pointer to \lstinline$void$;
     336from any object type or incomplete type to \lstinline@void@;
     337\item
     338from a pointer to any non-\lstinline@void@ type to a pointer to \lstinline@void@;
    333339\item
    334340from a pointer to any type to a pointer to a more qualified version of the type\index{qualified type};
     
    341347Conversions that are not safe conversions are \define{unsafe conversion}s.
    342348\begin{rationale}
    343 As in C, there is an implicit conversion from \lstinline$void *$ to any pointer type.
     349As in C, there is an implicit conversion from \lstinline@void *@ to any pointer type.
    344350This is clearly dangerous, and {\CC} does not have this implicit conversion.
    345351\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.
     
    367373\begin{itemize}
    368374\item
    369 The cost of an implicit conversion from \lstinline$int$ to \lstinline$long$ is 1.
    370 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$.
    371 
    372 \item
    373 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:
    374 \lstinline$unsigned short$ to \lstinline$int$ to \lstinline$unsigned$.
    375 Otherwise, \lstinline$unsigned short$ is converted directly to \lstinline$unsigned$, and the cost is 1.
    376 
    377 \item
    378 If \lstinline$long$ can represent all the values of \lstinline$unsigned$, then the conversion cost of \lstinline$unsigned$ to \lstinline$long$ is 1.
     375The cost of an implicit conversion from \lstinline@int@ to \lstinline@long@ is 1.
     376The cost of an implicit conversion from \lstinline@long@ to \lstinline@double@ is 3, because it is defined in terms of conversions from \lstinline@long@ to \lstinline@unsigned long@, then to \lstinline@float@, and then to \lstinline@double@.
     377
     378\item
     379If \lstinline@int@ can represent all the values of \lstinline@unsigned short@, then the cost of an implicit conversion from \lstinline@unsigned short@ to \lstinline@unsigned@ is 2:
     380\lstinline@unsigned short@ to \lstinline@int@ to \lstinline@unsigned@.
     381Otherwise, \lstinline@unsigned short@ is converted directly to \lstinline@unsigned@, and the cost is 1.
     382
     383\item
     384If \lstinline@long@ can represent all the values of \lstinline@unsigned@, then the conversion cost of \lstinline@unsigned@ to \lstinline@long@ is 1.
    379385Otherwise, the conversion is an unsafe conversion, and its conversion cost is undefined.
    380386\end{itemize}
     
    384390\begin{syntax}
    385391\oldlhs{keyword}
    386         \rhs \lstinline$forall$
    387         \rhs \lstinline$lvalue$
    388         \rhs \lstinline$trait$
    389         \rhs \lstinline$dtype$
    390         \rhs \lstinline$ftype$
    391         \rhs \lstinline$type$
     392        \rhs \lstinline@forall@
     393        \rhs \lstinline@lvalue@
     394        \rhs \lstinline@trait@
     395        \rhs \lstinline@dtype@
     396        \rhs \lstinline@ftype@
     397        \rhs \lstinline@otype@
    392398\end{syntax}
    393399
     
    396402
    397403\CFA allows operator \Index{overloading} by associating operators with special function identifiers.
    398 Furthermore, the constants ``\lstinline$0$'' and ``\lstinline$1$'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
     404Furthermore, the constants ``\lstinline@0@'' and ``\lstinline@1@'' have special status for many of C's data types (and for many programmer-defined data types as well), so \CFA treats them as overloadable identifiers.
    399405Programmers can use these identifiers to declare functions and objects that implement operators and constants for their own types.
    400406
     
    405411\begin{syntax}
    406412\oldlhs{identifier}
    407 \rhs \lstinline$0$
    408 \rhs \lstinline$1$
     413\rhs \lstinline@0@
     414\rhs \lstinline@1@
    409415\end{syntax}
    410416
    411 \index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline$0$''\impl{0} and ``\lstinline$1$''\impl{1} are identifiers.
     417\index{constant identifiers}\index{identifiers!for constants} The tokens ``\lstinline@0@''\impl{0} and ``\lstinline@1@''\impl{1} are identifiers.
    412418No other tokens defined by the rules for integer constants are considered to be identifiers.
    413419\begin{rationale}
    414 Why ``\lstinline$0$'' and ``\lstinline$1$''? Those integers have special status in C.
     420Why ``\lstinline@0@'' and ``\lstinline@1@''? Those integers have special status in C.
    415421All scalar types can be incremented and decremented, which is defined in terms of adding or subtracting 1.
    416 The operations ``\lstinline$&&$'', ``\lstinline$||$'', and ``\lstinline$!$'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
     422The operations ``\lstinline@&&@'', ``\lstinline@||@'', and ``\lstinline@!@'' can be applied to any scalar arguments, and are defined in terms of comparison against 0.
    417423A \nonterm{constant-expression} that evaluates to 0 is effectively compatible with every pointer type.
    418424
    419425In 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.
    420426However, 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.
    421 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline$_Bool$.
    422 
    423 Why \emph{just} ``\lstinline$0$'' and ``\lstinline$1$''? Why not other integers? No other integers have special status in C.
    424 A facility that let programmers declare specific constants---``\lstinline$const Rational 12$'', for instance---would not be much of an improvement.
     427Defining special constants for a user-defined type is more efficient than defining a conversion to the type from \lstinline@_Bool@.
     428
     429Why \emph{just} ``\lstinline@0@'' and ``\lstinline@1@''? Why not other integers? No other integers have special status in C.
     430A facility that let programmers declare specific constants---``\lstinline@const Rational 12@'', for instance---would not be much of an improvement.
    425431Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed.
    426432The complexity of such a feature doesn't seem worth the gain.
     
    438444\begin{tabular}[t]{ll}
    439445%identifier & operation \\ \hline
    440 \lstinline$?[?]$ & subscripting \impl{?[?]}\\
    441 \lstinline$?()$ & function call \impl{?()}\\
    442 \lstinline$?++$ & postfix increment \impl{?++}\\
    443 \lstinline$?--$ & postfix decrement \impl{?--}\\
    444 \lstinline$++?$ & prefix increment \impl{++?}\\
    445 \lstinline$--?$ & prefix decrement \impl{--?}\\
    446 \lstinline$*?$ & dereference \impl{*?}\\
    447 \lstinline$+?$ & unary plus \impl{+?}\\
    448 \lstinline$-?$ & arithmetic negation \impl{-?}\\
    449 \lstinline$~?$ & bitwise negation \impl{~?}\\
    450 \lstinline$!?$ & logical complement \impl{"!?}\\
    451 \lstinline$?*?$ & multiplication \impl{?*?}\\
    452 \lstinline$?/?$ & division \impl{?/?}\\
     446\lstinline@?[?]@ & subscripting \impl{?[?]}\\
     447\lstinline@?()@ & function call \impl{?()}\\
     448\lstinline@?++@ & postfix increment \impl{?++}\\
     449\lstinline@?--@ & postfix decrement \impl{?--}\\
     450\lstinline@++?@ & prefix increment \impl{++?}\\
     451\lstinline@--?@ & prefix decrement \impl{--?}\\
     452\lstinline@*?@ & dereference \impl{*?}\\
     453\lstinline@+?@ & unary plus \impl{+?}\\
     454\lstinline@-?@ & arithmetic negation \impl{-?}\\
     455\lstinline@~?@ & bitwise negation \impl{~?}\\
     456\lstinline@!?@ & logical complement \impl{"!?}\\
     457\lstinline@?*?@ & multiplication \impl{?*?}\\
     458\lstinline@?/?@ & division \impl{?/?}\\
    453459\end{tabular}\hfil
    454460\begin{tabular}[t]{ll}
    455461%identifier & operation \\ \hline
    456 \lstinline$?%?$ & remainder \impl{?%?}\\
    457 \lstinline$?+?$ & addition \impl{?+?}\\
    458 \lstinline$?-?$ & subtraction \impl{?-?}\\
    459 \lstinline$?<<?$ & left shift \impl{?<<?}\\
    460 \lstinline$?>>?$ & right shift \impl{?>>?}\\
    461 \lstinline$?<?$ & less than \impl{?<?}\\
    462 \lstinline$?<=?$ & less than or equal \impl{?<=?}\\
    463 \lstinline$?>=?$ & greater than or equal \impl{?>=?}\\
    464 \lstinline$?>?$ & greater than \impl{?>?}\\
    465 \lstinline$?==?$ & equality \impl{?==?}\\
    466 \lstinline$?!=?$ & inequality \impl{?"!=?}\\
    467 \lstinline$?&?$ & bitwise AND \impl{?&?}\\
     462\lstinline@?%?@ & remainder \impl{?%?}\\
     463\lstinline@?+?@ & addition \impl{?+?}\\
     464\lstinline@?-?@ & subtraction \impl{?-?}\\
     465\lstinline@?<<?@ & left shift \impl{?<<?}\\
     466\lstinline@?>>?@ & right shift \impl{?>>?}\\
     467\lstinline@?<?@ & less than \impl{?<?}\\
     468\lstinline@?<=?@ & less than or equal \impl{?<=?}\\
     469\lstinline@?>=?@ & greater than or equal \impl{?>=?}\\
     470\lstinline@?>?@ & greater than \impl{?>?}\\
     471\lstinline@?==?@ & equality \impl{?==?}\\
     472\lstinline@?!=?@ & inequality \impl{?"!=?}\\
     473\lstinline@?&?@ & bitwise AND \impl{?&?}\\
    468474\end{tabular}\hfil
    469475\begin{tabular}[t]{ll}
    470476%identifier & operation \\ \hline
    471 \lstinline$?^?$ & exclusive OR \impl{?^?}\\
    472 \lstinline$?|?$ & inclusive OR \impl{?"|?}\\
    473 \lstinline$?=?$ & simple assignment \impl{?=?}\\
    474 \lstinline$?*=?$ & multiplication assignment \impl{?*=?}\\
    475 \lstinline$?/=?$ & division assignment \impl{?/=?}\\
    476 \lstinline$?%=?$ & remainder assignment \impl{?%=?}\\
    477 \lstinline$?+=?$ & addition assignment \impl{?+=?}\\
    478 \lstinline$?-=?$ & subtraction assignment \impl{?-=?}\\
    479 \lstinline$?<<=?$ & left-shift assignment \impl{?<<=?}\\
    480 \lstinline$?>>=?$ & right-shift assignment \impl{?>>=?}\\
    481 \lstinline$?&=?$ & bitwise AND assignment \impl{?&=?}\\
    482 \lstinline$?^=?$ & exclusive OR assignment \impl{?^=?}\\
    483 \lstinline$?|=?$ & inclusive OR assignment \impl{?"|=?}\\
     477\lstinline@?^?@ & exclusive OR \impl{?^?}\\
     478\lstinline@?|?@ & inclusive OR \impl{?"|?}\\
     479\lstinline@?=?@ & simple assignment \impl{?=?}\\
     480\lstinline@?*=?@ & multiplication assignment \impl{?*=?}\\
     481\lstinline@?/=?@ & division assignment \impl{?/=?}\\
     482\lstinline@?%=?@ & remainder assignment \impl{?%=?}\\
     483\lstinline@?+=?@ & addition assignment \impl{?+=?}\\
     484\lstinline@?-=?@ & subtraction assignment \impl{?-=?}\\
     485\lstinline@?<<=?@ & left-shift assignment \impl{?<<=?}\\
     486\lstinline@?>>=?@ & right-shift assignment \impl{?>>=?}\\
     487\lstinline@?&=?@ & bitwise AND assignment \impl{?&=?}\\
     488\lstinline@?^=?@ & exclusive OR assignment \impl{?^=?}\\
     489\lstinline@?|=?@ & inclusive OR assignment \impl{?"|=?}\\
    484490\end{tabular}
    485491\hfil
     
    496502
    497503\begin{rationale}
    498 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
    499 \CFA compiler detects a syntax error because it treats ``\lstinline$?--$'' as an identifier, not as the two tokens ``\lstinline$?$'' and ``\lstinline$--$''.
     504The use of ``\lstinline@?@'' in identifiers means that some C programs are not \CFA programs.  For instance, the sequence of characters ``\lstinline@(i < 0)?--i:i@'' is legal in a C program, but a
     505\CFA compiler detects a syntax error because it treats ``\lstinline@?--@'' as an identifier, not as the two tokens ``\lstinline@?@'' and ``\lstinline@--@''.
    500506\end{rationale}
    501507
     
    504510\begin{itemize}
    505511\item
    506 The logical operators ``\lstinline$&&$'' and ``\lstinline$||$'', and the conditional operator
    507 ``\lstinline$?:$''.
     512The logical operators ``\lstinline@&&@'' and ``\lstinline@||@'', and the conditional operator
     513``\lstinline@?:@''.
    508514These 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.
    509 Note that the definitions of ``\lstinline$&&$'' and ``\lstinline$||$'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline$!=$'' and ``\lstinline$0$'' for user-defined types is enough to allow them to be used in logical expressions.
     515Note that the definitions of ``\lstinline@&&@'' and ``\lstinline@||@'' say that they work by checking that their arguments are unequal to 0, so defining ``\lstinline@!=@'' and ``\lstinline@0@'' for user-defined types is enough to allow them to be used in logical expressions.
    510516
    511517\item
     
    516522\item
    517523The ``address of'' operator.
    518 It would seem useful to define a unary ``\lstinline$&$'' operator that returns values of some programmer-defined pointer-like type.
     524It would seem useful to define a unary ``\lstinline@&@'' operator that returns values of some programmer-defined pointer-like type.
    519525The problem lies with the type of the operator.
    520 Consider the expression ``\lstinline$p = &x$'', where \lstinline$x$ is of type
    521 \lstinline$T$ and \lstinline$p$ has the programmer-defined type \lstinline$T_ptr$.
    522 The expression might be treated as a call to the unary function ``\lstinline$&?$''.
    523 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.
    524 Hence the parameter must have type \lstinline$T *$.
    525 But then the expression must be rewritten as ``\lstinline$p = &?( &x )$''
     526Consider the expression ``\lstinline@p = &x@'', where \lstinline@x@ is of type
     527\lstinline@T@ and \lstinline@p@ has the programmer-defined type \lstinline@T_ptr@.
     528The expression might be treated as a call to the unary function ``\lstinline@&?@''.
     529Now what is the type of the function's parameter? It can not be \lstinline@T@, because then \lstinline@x@ would be passed by value, and there is no way to create a useful pointer-like result from a value.
     530Hence the parameter must have type \lstinline@T *@.
     531But then the expression must be rewritten as ``\lstinline@p = &?( &x )@''
    526532---which doesn't seem like progress!
    527533
    528534The 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''.
    529 It seems simpler to define a conversion function from \lstinline$T *$ to \lstinline$T_ptr$.
    530 
    531 \item
    532 The \lstinline$sizeof$ operator.
     535It seems simpler to define a conversion function from \lstinline@T *@ to \lstinline@T_ptr@.
     536
     537\item
     538The \lstinline@sizeof@ operator.
    533539It is already defined for every object type, and intimately tied into the language's storage allocation model.
    534540Redefining it seems pointless.
    535541
    536542\item
    537 The ``member of'' operators ``\lstinline$.$'' and ``\lstinline$->$''.
     543The ``member of'' operators ``\lstinline@.@'' and ``\lstinline@->@''.
    538544These are not really infix operators, since their right ``operand'' is not a value or object.
    539545
     
    572578The ``fewest unsafe conversions'' rule ensures that the usual conversions are done, if possible.
    573579The ``lowest total expression cost'' rule chooses the proper common type.
    574 The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline$(double)-i$ will be preferred to \lstinline$-(double)i$.
     580The odd-looking ``highest argument conversion cost'' rule ensures that, when unary expressions must be converted, conversions of function results are preferred to conversion of function arguments: \lstinline@(double)-i@ will be preferred to \lstinline@-(double)i@.
    575581
    576582The ``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.
    577583It also gives preference to monomorphic values (such as the
    578 \lstinline$int$ \lstinline$0$) over polymorphic values (such as the \Index{null pointer}
    579 \lstinline$0$\use{0}).
     584\lstinline@int@ \lstinline@0@) over polymorphic values (such as the \Index{null pointer}
     585\lstinline@0@\use{0}).
    580586However, interpretations that call polymorphic functions are preferred to interpretations that perform unsafe conversions, because those conversions potentially lose accuracy or violate strong typing.
    581587
     
    597603\begin{rationale}
    598604Predefined functions and constants have internal linkage because that simplifies optimization in traditional compile-and-link environments.
    599 For instance, ``\lstinline$an_int + an_int$'' is equivalent to ``\lstinline$?+?(an_int, an_int)$''.
     605For instance, ``\lstinline@an_int + an_int@'' is equivalent to ``\lstinline@?+?(an_int, an_int)@''.
    600606If integer addition has not been redefined in the current scope, a compiler can generate code to perform the addition directly.
    601607If predefined functions had external linkage, this optimization would be difficult.
     
    623629\rhs \nonterm{constant}
    624630\rhs \nonterm{string-literal}
    625 \rhs \lstinline$($ \nonterm{expression} \lstinline$)$
     631\rhs \lstinline@(@ \nonterm{expression} \lstinline@)@
    626632\rhs \nonterm{generic-selection}
    627633\end{syntax}
     
    629635\predefined
    630636\begin{lstlisting}
    631 const int 1;@\use{1}@
    632 const int 0;@\use{0}@
     637const int 1;§\use{1}§
     638const int 0;§\use{0}§
    633639forall( dtype DT ) DT * const 0;
    634640forall( ftype FT ) FT * const 0;
     
    639645
    640646A \nonterm{constant} or \nonterm{string-literal} has one valid interpretation, which has the type and value defined by {\c11}.
    641 The predefined integer identifiers ``\lstinline$1$'' and ``\lstinline$0$'' have the integer values 1 and 0, respectively.
    642 The other two predefined ``\lstinline$0$'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
     647The predefined integer identifiers ``\lstinline@1@'' and ``\lstinline@0@'' have the integer values 1 and 0, respectively.
     648The other two predefined ``\lstinline@0@'' identifiers are bound to polymorphic pointer values that, when specialized\index{specialization} with a data type or function type respectively, produce a null pointer of that type.
    643649
    644650A parenthesised expression has the same interpretations as the contained \nonterm{expression}.
    645651
    646652\examples
    647 The expression \lstinline$(void *)0$\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline$void$. \lstinline$(const void *)0$ does the same, and also uses a safe conversion from \lstinline$void *$ to \lstinline$const void *$.
     653The expression \lstinline@(void *)0@\use{0} specializes the (polymorphic) null pointer to a null pointer to \lstinline@void@. \lstinline@(const void *)0@ does the same, and also uses a safe conversion from \lstinline@void *@ to \lstinline@const void *@.
    648654In each case, the null pointer conversion is better\index{best valid interpretations} than the unsafe conversion of the integer
    649 \lstinline$0$ to a pointer.
     655\lstinline@0@ to a pointer.
    650656
    651657\begin{rationale}
     
    653659
    654660\CFA does not have C's concept of ``null pointer constants'', which are not typed values but special strings of tokens.
    655 The C token ``\lstinline$0$'' is an expression of type \lstinline$int$ with the value ``zero'', and it \emph{also} is a null pointer constant.
     661The C token ``\lstinline@0@'' is an expression of type \lstinline@int@ with the value ``zero'', and it \emph{also} is a null pointer constant.
    656662Similarly,
    657 ``\lstinline$(void *)0$ is an expression of type \lstinline$(void *)$ whose value is a null pointer, and it also is a null pointer constant.
    658 However, in C, ``\lstinline$(void *)(void *)0$'' is
     663``\lstinline@(void *)0@ is an expression of type \lstinline@(void *)@ whose value is a null pointer, and it also is a null pointer constant.
     664However, in C, ``\lstinline@(void *)(void *)0@'' is
    659665\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.
    660666
     
    663669\begin{lstlisting}
    664670forall( dtype DT ) DT * const 0;
    665 \end{lstlisting} means that \lstinline$0$ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
     671\end{lstlisting} means that \lstinline@0@ is a polymorphic object, and contains a value that can have \emph{any} pointer-to-object type or pointer-to-incomplete type.
    666672The only such value is the null pointer.
    667673Therefore the type \emph{alone} is enough to identify a null pointer.
     
    673679
    674680\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.
    675 If a generic selection has no \lstinline$default$ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
     681If a generic selection has no \lstinline@default@ generic association, the best interpretation of its controlling expression shall have type compatible with exactly one of the types named in its generic association list.
    676682
    677683\semantics
     
    684690\lhs{postfix-expression}
    685691\rhs \nonterm{primary-expression}
    686 \rhs \nonterm{postfix-expression} \lstinline$[$ \nonterm{expression} \lstinline$]$
    687 \rhs \nonterm{postfix-expression} \lstinline$($
    688          \nonterm{argument-expression-list}\opt \lstinline$)$
    689 \rhs \nonterm{postfix-expression} \lstinline$.$ \nonterm{identifier}
    690 \rhs \nonterm{postfix-expression} \lstinline$->$ \nonterm{identifier}
    691 \rhs \nonterm{postfix-expression} \lstinline$++$
    692 \rhs \nonterm{postfix-expression} \lstinline$--$
    693 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$}$
    694 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \lstinline${$ \nonterm{initializer-list} \lstinline$,$ \lstinline$}$
     692\rhs \nonterm{postfix-expression} \lstinline@[@ \nonterm{expression} \lstinline@]@
     693\rhs \nonterm{postfix-expression} \lstinline@(@
     694         \nonterm{argument-expression-list}\opt \lstinline@)@
     695\rhs \nonterm{postfix-expression} \lstinline@.@ \nonterm{identifier}
     696\rhs \nonterm{postfix-expression} \lstinline@->@ \nonterm{identifier}
     697\rhs \nonterm{postfix-expression} \lstinline@++@
     698\rhs \nonterm{postfix-expression} \lstinline@--@
     699\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@}@
     700\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \lstinline@{@ \nonterm{initializer-list} \lstinline@,@ \lstinline@}@
    695701\lhs{argument-expression-list}
    696702\rhs \nonterm{assignment-expression}
    697 \rhs \nonterm{argument-expression-list} \lstinline$,$
     703\rhs \nonterm{argument-expression-list} \lstinline@,@
    698704         \nonterm{assignment-expression}
    699705\end{syntax}
     
    701707\rewriterules
    702708\begin{lstlisting}
    703 a[b] @\rewrite@ ?[?]( b, a ) // if a has integer type@\use{?[?]}@
    704 a[b] @\rewrite@ ?[?]( a, b ) // otherwise
    705 a( @\emph{arguments}@ ) @\rewrite@ ?()( a, @\emph{arguments}@ )@\use{?()}@
    706 a++ @\rewrite@ ?++(&( a ))@\use{?++}@
    707 a-- @\rewrite@ ?--(&( a ))@\use{?--}@
     709a[b] §\rewrite§ ?[?]( b, a ) // if a has integer type§\use{?[?]}§
     710a[b] §\rewrite§ ?[?]( a, b ) // otherwise
     711a( §\emph{arguments}§ ) §\rewrite§ ?()( a, §\emph{arguments}§ )§\use{?()}§
     712a++ §\rewrite§ ?++(&( a ))§\use{?++}§
     713a-- §\rewrite§ ?--(&( a ))§\use{?--}§
    708714\end{lstlisting}
    709715
     
    713719\predefined
    714720\begin{lstlisting}
    715 forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );@\use{ptrdiff_t}@
     721forall( otype T ) lvalue T ?[?]( T *, ptrdiff_t );§\use{ptrdiff_t}§
    716722forall( otype T ) lvalue _Atomic T ?[?]( _Atomic T *, ptrdiff_t );
    717723forall( otype T ) lvalue const T ?[?]( const T *, ptrdiff_t );
     
    733739The interpretations of subscript expressions are the interpretations of the corresponding function call expressions.
    734740\begin{rationale}
    735 C defines subscripting as pointer arithmetic in a way that makes \lstinline$a[i]$ and
    736 \lstinline$i[a]$ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline$?[?]$.
     741C defines subscripting as pointer arithmetic in a way that makes \lstinline@a[i]@ and
     742\lstinline@i[a]@ equivalent. \CFA provides the equivalence through a rewrite rule to reduce the number of overloadings of \lstinline@?[?]@.
    737743
    738744Subscript expressions are rewritten as function calls that pass the first parameter by value.
    739745This is somewhat unfortunate, since array-like types tend to be large.
    740 The alternative is to use the rewrite rule ``\lstinline$a[b]$ \rewrite \lstinline$?[?](&(a), b)$''.
    741 However, C semantics forbid this approach: the \lstinline$a$ in ``\lstinline$a[b]$'' can be an arbitrary pointer value, which does not have an address.
     746The alternative is to use the rewrite rule ``\lstinline@a[b]@ \rewrite \lstinline@?[?](&(a), b)@''.
     747However, C semantics forbid this approach: the \lstinline@a@ in ``\lstinline@a[b]@'' can be an arbitrary pointer value, which does not have an address.
    742748
    743749The repetitive form of the predefined identifiers shows up a deficiency\index{deficiencies!pointers
     
    754760\nonterm{postfix-expression} in a function call may have some interpretations that are function designators and some that are not.
    755761
    756 For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline$?()$''.
     762For those interpretations of the \nonterm{postfix-expression} that are not function designators, the expression is rewritten and becomes a call of a function named ``\lstinline@?()@''.
    757763The valid interpretations of the rewritten expression are determined in the manner described below.
    758764
     
    762768\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
    763769\item if the function designator's type does not include a prototype or if the argument corresponds to
    764 ``\lstinline$...$'' in a prototype, a \Index{default argument promotion} is applied to it.
     770``\lstinline@...@'' in a prototype, a \Index{default argument promotion} is applied to it.
    765771\end{itemize}
    766772The type of the valid interpretation is the return type of the function designator.
     
    770776\begin{itemize}
    771777\item
    772 If the declaration of the implicit parameter uses \Index{type-class} \lstinline$type$\use{type}, the implicit argument must be an object type;
    773 if it uses \lstinline$dtype$, the implicit argument must be an object type or an incomplete type;
    774 and if it uses \lstinline$ftype$, the implicit argument must be a function type.
     778If the declaration of the implicit parameter uses \Index{type-class} \lstinline@type@\use{type}, the implicit argument must be an object type;
     779if it uses \lstinline@dtype@, the implicit argument must be an object type or an incomplete type;
     780and if it uses \lstinline@ftype@, the implicit argument must be a function type.
    775781
    776782\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.
     
    791797\begin{rationale}
    792798One 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}.
    793 For instance, it should be possible to replace a function ``\lstinline$int f( int );$'' with ``\lstinline$forall( otype T ) T f( T );$'' without affecting any calls of \lstinline$f$.
     799For instance, it should be possible to replace a function ``\lstinline@int f( int );@'' with ``\lstinline@forall( otype T ) T f( T );@'' without affecting any calls of \lstinline@f@.
    794800
    795801\CFA\index{deficiencies!generalizability} does not fully possess this property, because
     
    805811f = g( d, f );          // (3) (unsafe conversion to float)
    806812\end{lstlisting}
    807 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
    808 \lstinline$double$, and the result would be a \lstinline$double$.
    809 
    810 Another example is the function ``\lstinline$void h( int *);$''.
     813If \lstinline@g@ was replaced by ``\lstinline@forall( otype T ) T g( T, T );@'', the first and second calls would be unaffected, but the third would change: \lstinline@f@ would be converted to
     814\lstinline@double@, and the result would be a \lstinline@double@.
     815
     816Another example is the function ``\lstinline@void h( int *);@''.
    811817This function can be passed a
    812 \lstinline$void *$ argument, but the generalization ``\lstinline$forall( otype T ) void h( T *);$'' can not.
    813 In this case, \lstinline$void$ is not a valid value for \lstinline$T$ because it is not an object type.
    814 If unsafe conversions were allowed, \lstinline$T$ could be inferred to be \emph{any} object type, which is undesirable.
     818\lstinline@void *@ argument, but the generalization ``\lstinline@forall( otype T ) void h( T *);@'' can not.
     819In this case, \lstinline@void@ is not a valid value for \lstinline@T@ because it is not an object type.
     820If unsafe conversions were allowed, \lstinline@T@ could be inferred to be \emph{any} object type, which is undesirable.
    815821\end{rationale}
    816822
    817823\examples
    818 A function called ``\lstinline$?()$'' might be part of a numerical differentiation package.
     824A function called ``\lstinline@?()@'' might be part of a numerical differentiation package.
    819825\begin{lstlisting}
    820826extern otype Derivative;
     
    827833d = sin_dx( 12.9 );
    828834\end{lstlisting}
    829 Here, the only interpretation of \lstinline$sin_dx$ is as an object of type \lstinline$Derivative$.
    830 For that interpretation, the function call is treated as ``\lstinline$?()( sin_dx, 12.9 )$''.
     835Here, the only interpretation of \lstinline@sin_dx@ is as an object of type \lstinline@Derivative@.
     836For that interpretation, the function call is treated as ``\lstinline@?()( sin_dx, 12.9 )@''.
    831837\begin{lstlisting}
    832838int f( long );          // (1)
     
    835841int i = f( 5 );         // calls (1)
    836842\end{lstlisting}
    837 Function (1) provides a valid interpretation of ``\lstinline$f( 5 )$'', using an implicit \lstinline$int$ to \lstinline$long$ conversion.
    838 The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline$int$ to \lstinline$int *$ that could be used with the third function.
     843Function (1) provides a valid interpretation of ``\lstinline@f( 5 )@'', using an implicit \lstinline@int@ to \lstinline@long@ conversion.
     844The other functions do not, since the second requires two arguments, and since there is no implicit conversion from \lstinline@int@ to \lstinline@int *@ that could be used with the third function.
    839845
    840846\begin{lstlisting}
     
    842848double d = h( 1.5 );
    843849\end{lstlisting}
    844 ``\lstinline$1.5$'' is a \lstinline$double$ constant, so \lstinline$T$ is inferred to be
    845 \lstinline$double$, and the result of the function call is a \lstinline$double$.
     850``\lstinline@1.5@'' is a \lstinline@double@ constant, so \lstinline@T@ is inferred to be
     851\lstinline@double@, and the result of the function call is a \lstinline@double@.
    846852
    847853\begin{lstlisting}
     
    858864g( i, p );                      // calls (4)
    859865\end{lstlisting}
    860 The first call has valid interpretations for all four versions of \lstinline$g$. (6) and (7) are discarded because they involve unsafe \lstinline$double$-to-\lstinline$long$ conversions. (5) is chosen because it is less polymorphic than (4).
     866The first call has valid interpretations for all four versions of \lstinline@g@. (6) and (7) are discarded because they involve unsafe \lstinline@double@-to-\lstinline@long@ conversions. (5) is chosen because it is less polymorphic than (4).
    861867
    862868For the second call, (7) is again discarded.
    863 Of the remaining interpretations for (4), (5), and (6) (with \lstinline$i$ converted to \lstinline$long$), (6) is chosen because it is the least polymorphic.
     869Of the remaining interpretations for (4), (5), and (6) (with \lstinline@i@ converted to \lstinline@long@), (6) is chosen because it is the least polymorphic.
    864870
    865871The third call has valid interpretations for all of the functions;
     
    870876forall( otype T ) T min( T, T );
    871877double max( double, double );
    872 trait min_max( T ) {@\impl{min_max}@
     878trait min_max( T ) {§\impl{min_max}§
    873879        T min( T, T );
    874880        T max( T, T );
     
    877883shuffle( 9, 10 );
    878884\end{lstlisting}
    879 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
    880 \lstinline$min$ must be specialized with \lstinline$T$ bound to \lstinline$double$.
     885The only possibility for \lstinline@U@ is \lstinline@double@, because that is the type used in the only visible \lstinline@max@ function. 9 and 10 must be converted to \lstinline@double@, and
     886\lstinline@min@ must be specialized with \lstinline@T@ bound to \lstinline@double@.
    881887\begin{lstlisting}
    882888extern void q( int );           // (8)
     
    886892r( 0 );
    887893\end{lstlisting}
    888 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).
    889 The former is chosen because the \lstinline$int$ \lstinline$0$ is \Index{less polymorphic}.
    890 For the same reason, \lstinline$int$ \lstinline$0$ is passed to \lstinline$r()$, even though it has \emph{no} declared parameter types.
     894The \lstinline@int 0@ could be passed to (8), or the \lstinline@(void *)@ \Index{specialization} of the null pointer\index{null pointer} \lstinline@0@\use{0} could be passed to (9).
     895The former is chosen because the \lstinline@int@ \lstinline@0@ is \Index{less polymorphic}.
     896For the same reason, \lstinline@int@ \lstinline@0@ is passed to \lstinline@r()@, even though it has \emph{no} declared parameter types.
    891897
    892898
    893899\subsubsection{Structure and union members}
    894900
    895 \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$.
    896 If two or more interpretations of \lstinline$s$ have members named
    897 \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.
    898 If an interpretation of \lstinline$s$ has a member \lstinline$m$ whose type is not compatible with any other
    899 \lstinline$s$'s \lstinline$m$, then the expression has an interpretation with the member's type.
     901\semantics In the member selection expression ``\lstinline@s@.\lstinline@m@'', there shall be at least one interpretation of \lstinline@s@ whose type is a structure type or union type containing a member named \lstinline@m@.
     902If two or more interpretations of \lstinline@s@ have members named
     903\lstinline@m@ with mutually compatible types, then the expression has an \Index{ambiguous interpretation} whose type is the composite type of the types of the members.
     904If an interpretation of \lstinline@s@ has a member \lstinline@m@ whose type is not compatible with any other
     905\lstinline@s@'s \lstinline@m@, then the expression has an interpretation with the member's type.
    900906The expression has no other interpretations.
    901907
    902 The expression ``\lstinline$p->m$'' has the same interpretations as the expression
    903 ``\lstinline$(*p).m$''.
     908The expression ``\lstinline@p->m@'' has the same interpretations as the expression ``\lstinline@(*p).m@''.
    904909
    905910
     
    9961001        * ?--( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    9971002\end{lstlisting}
    998 For every extended integer type \lstinline$X$ there exist
     1003For every extended integer type \lstinline@X@ there exist
    9991004% Don't use predefined: keep this out of prelude.cf.
    10001005\begin{lstlisting}
     
    10021007  ?--( volatile X * ), ?--( _Atomic volatile X * );
    10031008\end{lstlisting}
    1004 For every complete enumerated type \lstinline$E$ there exist
     1009For every complete enumerated type \lstinline@E@ there exist
    10051010% Don't use predefined: keep this out of prelude.cf.
    10061011\begin{lstlisting}
     
    10101015
    10111016\begin{rationale}
    1012 Note that ``\lstinline$++$'' and ``\lstinline$--$'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
     1017Note that ``\lstinline@++@'' and ``\lstinline@--@'' are rewritten as function calls that are given a pointer to that operand. (This is true of all operators that modify an operand.) As Hamish Macdonald has pointed out, this forces the modified operand of such expressions to be an lvalue.
    10131018This partially enforces the C semantic rule that such operands must be \emph{modifiable} lvalues.
    10141019\end{rationale}
     
    10161021\begin{rationale}
    10171022In C, a semantic rule requires that pointer operands of increment and decrement be pointers to object types.
    1018 Hence, \lstinline$void *$ objects cannot be incremented.
    1019 In \CFA, the restriction follows from the use of a \lstinline$type$ parameter in the predefined function definitions, as opposed to \lstinline$dtype$, since only object types can be inferred arguments corresponding to the type parameter \lstinline$T$.
     1023Hence, \lstinline@void *@ objects cannot be incremented.
     1024In \CFA, the restriction follows from the use of a \lstinline@type@ parameter in the predefined function definitions, as opposed to \lstinline@dtype@, since only object types can be inferred arguments corresponding to the type parameter \lstinline@T@.
    10201025\end{rationale}
    10211026
    10221027\semantics
    10231028First, each interpretation of the operand of an increment or decrement expression is considered separately.
    1024 For each interpretation that is a bit-field or is declared with the
    1025 \lstinline$register$\index{register@{\lstinline$register$}} \index{Itorage-class specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is.
     1029For each interpretation that is a bit-field or is declared with the \Indexc{register}\index{storage-class specifier}, the expression has one valid interpretation, with the type of the operand, and the expression is ambiguous if the operand is.
    10261030
    10271031For the remaining interpretations, the expression is rewritten, and the interpretations of the expression are the interpretations of the corresponding function call.
     
    10361040\end{lstlisting}
    10371041\begin{sloppypar}
    1038 Since \lstinline$&(vs)$ has type \lstinline$volatile short int *$, the best valid interpretation of
    1039 \lstinline$vs++$ calls the \lstinline$?++$ function with the \lstinline$volatile short *$ parameter.
    1040 \lstinline$s++$ does the same, applying the safe conversion from \lstinline$short int *$ to
    1041 \lstinline$volatile short int *$.
    1042 Note that there is no conversion that adds an \lstinline$_Atomic$ qualifier, so the \lstinline$_Atomic volatile short int$ overloading does not provide a valid interpretation.
     1042Since \lstinline@&(vs)@ has type \lstinline@volatile short int *@, the best valid interpretation of
     1043\lstinline@vs++@ calls the \lstinline@?++@ function with the \lstinline@volatile short *@ parameter.
     1044\lstinline@s++@ does the same, applying the safe conversion from \lstinline@short int *@ to \lstinline@volatile short int *@.
     1045Note that there is no conversion that adds an \lstinline@_Atomic@ qualifier, so the \lstinline@_Atomic volatile short int@ overloading does not provide a valid interpretation.
    10431046\end{sloppypar}
    10441047
    1045 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.
    1046 
    1047 The best valid interpretation of \lstinline$as++$ calls the \lstinline$short ?++$ function with the \lstinline$_Atomic volatile short int *$ parameter, applying a safe conversion to add the \lstinline$volatile$ qualifier.
     1048There is no safe conversion from \lstinline@const short int *@ to \lstinline@volatile short int *@, and no \lstinline@?++@ function that accepts a \lstinline@const *@ parameter, so \lstinline@cs++@ has no valid interpretations.
     1049
     1050The best valid interpretation of \lstinline@as++@ calls the \lstinline@short ?++@ function with the \lstinline@_Atomic volatile short int *@ parameter, applying a safe conversion to add the \lstinline@volatile@ qualifier.
    10481051\begin{lstlisting}
    10491052char * const restrict volatile * restrict volatile pqpc;
     
    10521055ppc++;
    10531056\end{lstlisting}
    1054 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 *$.
    1055 
    1056 \lstinline$ppc++$ calls the same function, again inferring \lstinline$T$ to be \lstinline$char *$, and using the safe conversions from \lstinline$T$ to \lstinline$T const$ \lstinline$restrict volatile$.
     1057Since \lstinline@&(pqpc)@ has type \lstinline@char * const restrict volatile * restrict volatile *@, the best valid interpretation of \lstinline@pqpc++@ calls the polymorphic \lstinline@?++@ function with the \lstinline@const restrict volatile T * restrict volatile *@ parameter, inferring \lstinline@T@ to be \lstinline@char *@.
     1058
     1059\lstinline@ppc++@ calls the same function, again inferring \lstinline@T@ to be \lstinline@char *@, and using the safe conversions from \lstinline@T@ to \lstinline@T const@ \lstinline@restrict volatile@.
    10571060
    10581061\begin{rationale}
     
    10681071\begin{enumerate}
    10691072\item
    1070 ``\lstinline$char * p; p++;$''.
    1071 The argument to \lstinline$?++$ has type \lstinline$char * *$, and the result has type \lstinline$char *$.
    1072 The expression would be valid if \lstinline$?++$ were declared by
     1073``\lstinline@char * p; p++;@''.
     1074The argument to \lstinline@?++@ has type \lstinline@char * *@, and the result has type \lstinline@char *@.
     1075The expression would be valid if \lstinline@?++@ were declared by
    10731076\begin{lstlisting}
    10741077forall( otype T ) T * ?++( T * * );
    1075 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$char$.
    1076 
    1077 \item
    1078 ``\lstinline$char *restrict volatile qp; qp++$''.
    1079 The result again has type \lstinline$char *$, but the argument now has type \lstinline$char *restrict volatile *$, so it cannot be passed to the hypothetical function declared in point 1.
     1078\end{lstlisting} with \lstinline@T@ inferred to be \lstinline@char@.
     1079
     1080\item
     1081``\lstinline@char *restrict volatile qp; qp++@''.
     1082The result again has type \lstinline@char *@, but the argument now has type \lstinline@char *restrict volatile *@, so it cannot be passed to the hypothetical function declared in point 1.
    10801083Hence the actual predefined function is
    10811084\begin{lstlisting}
    10821085forall( otype T ) T * ?++( T * restrict volatile * );
    1083 \end{lstlisting} which also accepts a \lstinline$char * *$ argument, because of the safe conversions that add
    1084 \lstinline$volatile$ and \lstinline$restrict$ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
    1085 
    1086 \item
    1087 ``\lstinline$char *_Atomic ap; ap++$''.
    1088 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.
    1089 A separate overloading of \lstinline$?++$ is required.
    1090 
    1091 \item
    1092 ``\lstinline$char const volatile * pq; pq++$''.
     1086\end{lstlisting} which also accepts a \lstinline@char * *@ argument, because of the safe conversions that add
     1087\lstinline@volatile@ and \lstinline@restrict@ qualifiers. (The parameter is not const-qualified, so constant pointers cannot be incremented.)
     1088
     1089\item
     1090``\lstinline@char *_Atomic ap; ap++@''.
     1091The result again has type \lstinline@char *@, but no safe conversion adds an \lstinline@_Atomic@ qualifier, so the function in point 2 is not applicable.
     1092A separate overloading of \lstinline@?++@ is required.
     1093
     1094\item
     1095``\lstinline@char const volatile * pq; pq++@''.
    10931096Here the result has type
    1094 \lstinline$char const volatile *$, so a new overloading is needed:
     1097\lstinline@char const volatile *@, so a new overloading is needed:
    10951098\begin{lstlisting}
    10961099forall( otype T ) T const volatile * ?++( T const volatile *restrict volatile * );
     
    10991102 
    11001103\item
    1101 ``\lstinline$float *restrict * prp; prp++$''.
    1102 The \lstinline$restrict$ qualifier is handled just like \lstinline$const$ and \lstinline$volatile$ in the previous case:
     1104``\lstinline@float *restrict * prp; prp++@''.
     1105The \lstinline@restrict@ qualifier is handled just like \lstinline@const@ and \lstinline@volatile@ in the previous case:
    11031106\begin{lstlisting}
    11041107forall( otype T ) T restrict * ?++( T restrict *restrict volatile * );
    1105 \end{lstlisting} with \lstinline$T$ inferred to be \lstinline$float *$.
    1106 This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline$T$ is not syntactically a pointer type. \CFA loosens the constraint.
     1108\end{lstlisting} with \lstinline@T@ inferred to be \lstinline@float *@.
     1109This looks odd, because {\c11} contains a constraint that requires restrict-qualified types to be pointer-to-object types, and \lstinline@T@ is not syntactically a pointer type. \CFA loosens the constraint.
    11071110\end{enumerate}
    11081111\end{rationale}
     
    11201123\lhs{unary-expression}
    11211124\rhs \nonterm{postfix-expression}
    1122 \rhs \lstinline$++$ \nonterm{unary-expression}
    1123 \rhs \lstinline$--$ \nonterm{unary-expression}
     1125\rhs \lstinline@++@ \nonterm{unary-expression}
     1126\rhs \lstinline@--@ \nonterm{unary-expression}
    11241127\rhs \nonterm{unary-operator} \nonterm{cast-expression}
    1125 \rhs \lstinline$sizeof$ \nonterm{unary-expression}
    1126 \rhs \lstinline$sizeof$ \lstinline$($ \nonterm{type-name} \lstinline$)$
    1127 \lhs{unary-operator} one of \rhs \lstinline$&$ \lstinline$*$ \lstinline$+$ \lstinline$-$ \lstinline$~$ \lstinline$!$
     1128\rhs \lstinline@sizeof@ \nonterm{unary-expression}
     1129\rhs \lstinline@sizeof@ \lstinline@(@ \nonterm{type-name} \lstinline@)@
     1130\lhs{unary-operator} one of \rhs \lstinline@&@ \lstinline@*@ \lstinline@+@ \lstinline@-@ \lstinline@~@ \lstinline@!@
    11281131\end{syntax}
    11291132
    11301133\rewriterules
    11311134\begin{lstlisting}
    1132 *a      @\rewrite@ *?( a ) @\use{*?}@
    1133 +a      @\rewrite@ +?( a ) @\use{+?}@
    1134 -a      @\rewrite@ -?( a ) @\use{-?}@
    1135 ~a      @\rewrite@ ~?( a ) @\use{~?}@
    1136 !a      @\rewrite@ !?( a ) @\use{"!?}@
    1137 ++a     @\rewrite@ ++?(&( a )) @\use{++?}@
    1138 --a     @\rewrite@ --?(&( a )) @\use{--?}@
     1135*a      §\rewrite§ *?( a ) §\use{*?}§
     1136+a      §\rewrite§ +?( a ) §\use{+?}§
     1137-a      §\rewrite§ -?( a ) §\use{-?}§
     1138~a      §\rewrite§ ~?( a ) §\use{~?}§
     1139!a      §\rewrite§ !?( a ) §\use{"!?}§
     1140++a     §\rewrite§ ++?(&( a )) §\use{++?}§
     1141--a     §\rewrite§ --?(&( a )) §\use{--?}§
    11391142\end{lstlisting}
    11401143
     
    12321235        * --?( _Atomic const restrict volatile T * _Atomic restrict volatile * );
    12331236\end{lstlisting}
    1234 For every extended integer type \lstinline$X$ there exist
     1237For every extended integer type \lstinline@X@ there exist
    12351238% Don't use predefined: keep this out of prelude.cf.
    12361239\begin{lstlisting}
     
    12401243        --?( _Atomic volatile X * );
    12411244\end{lstlisting}
    1242 For every complete enumerated type \lstinline$E$ there exist
     1245For every complete enumerated type \lstinline@E@ there exist
    12431246% Don't use predefined: keep this out of prelude.cf.
    12441247\begin{lstlisting}
     
    12771280
    12781281\constraints
    1279 The operand of the unary ``\lstinline$&$'' operator shall have exactly one
     1282The operand of the unary ``\lstinline@&@'' operator shall have exactly one
    12801283\Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous.
    12811284
    12821285\semantics
    1283 The ``\lstinline$&$'' expression has one interpretation which is of type \lstinline$T *$, where
    1284 \lstinline$T$ is the type of the operand.
     1286The ``\lstinline@&@'' expression has one interpretation which is of type \lstinline@T *@, where
     1287\lstinline@T@ is the type of the operand.
    12851288
    12861289The interpretations of an indirection expression are the interpretations of the corresponding function call.
     
    13111314forall( ftype FT ) int !?( FT * );
    13121315\end{lstlisting}
    1313 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1316For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    13141317% Don't use predefined: keep this out of prelude.cf.
    13151318\begin{lstlisting}
     
    13241327\begin{lstlisting}
    13251328long int li;
    1326 void eat_double( double );@\use{eat_double}@
    1327 eat_double(-li ); // @\rewrite@ eat_double( -?( li ) );
    1328 \end{lstlisting}
    1329 The valid interpretations of ``\lstinline$-li$'' (assuming no extended integer types exist) are
     1329void eat_double( double );§\use{eat_double}§
     1330eat_double(-li ); // §\rewrite§ eat_double( -?( li ) );
     1331\end{lstlisting}
     1332The valid interpretations of ``\lstinline@-li@'' (assuming no extended integer types exist) are
    13301333\begin{center}
    13311334\begin{tabular}{llc} interpretation & result type & expression conversion cost \\
    13321335\hline
    1333 \lstinline$-?( (int)li )$                                       & \lstinline$int$                                       & (unsafe) \\
    1334 \lstinline$-?( (unsigned)li)$                           & \lstinline$unsigned int$                      & (unsafe) \\
    1335 \lstinline$-?( (long)li)$                                       & \lstinline$long$                                      & 0 \\
    1336 \lstinline$-?( (long unsigned int)li)$          & \lstinline$long unsigned int$         & 1 \\
    1337 \lstinline$-?( (long long int)li)$                      & \lstinline$long long int$                     & 2 \\
    1338 \lstinline$-?( (long long unsigned int)li)$     & \lstinline$long long unsigned int$& 3 \\
    1339 \lstinline$-?( (float)li)$                                      & \lstinline$float$                                     & 4 \\
    1340 \lstinline$-?( (double)li)$                                     & \lstinline$double$                            & 5 \\
    1341 \lstinline$-?( (long double)li)$                        & \lstinline$long double$                       & 6 \\
    1342 \lstinline$-?( (_Complex float)li)$                     & \lstinline$float$                                     & (unsafe) \\
    1343 \lstinline$-?( (_Complex double)li)$            & \lstinline$double$                            & (unsafe) \\
    1344 \lstinline$-?( (_Complex long double)li)$       & \lstinline$long double$                       & (unsafe) \\
     1336\lstinline@-?( (int)li )@                                       & \lstinline@int@                                       & (unsafe) \\
     1337\lstinline@-?( (unsigned)li)@                           & \lstinline@unsigned int@                      & (unsafe) \\
     1338\lstinline@-?( (long)li)@                                       & \lstinline@long@                                      & 0 \\
     1339\lstinline@-?( (long unsigned int)li)@          & \lstinline@long unsigned int@         & 1 \\
     1340\lstinline@-?( (long long int)li)@                      & \lstinline@long long int@                     & 2 \\
     1341\lstinline@-?( (long long unsigned int)li)@     & \lstinline@long long unsigned int@& 3 \\
     1342\lstinline@-?( (float)li)@                                      & \lstinline@float@                                     & 4 \\
     1343\lstinline@-?( (double)li)@                                     & \lstinline@double@                            & 5 \\
     1344\lstinline@-?( (long double)li)@                        & \lstinline@long double@                       & 6 \\
     1345\lstinline@-?( (_Complex float)li)@                     & \lstinline@float@                                     & (unsafe) \\
     1346\lstinline@-?( (_Complex double)li)@            & \lstinline@double@                            & (unsafe) \\
     1347\lstinline@-?( (_Complex long double)li)@       & \lstinline@long double@                       & (unsafe) \\
    13451348\end{tabular}
    13461349\end{center}
    1347 The valid interpretations of the \lstinline$eat_double$ call, with the cost of the argument conversion and the cost of the entire expression, are
     1350The valid interpretations of the \lstinline@eat_double@ call, with the cost of the argument conversion and the cost of the entire expression, are
    13481351\begin{center}
    13491352\begin{tabular}{lcc} interpretation & argument cost & expression cost \\
    13501353\hline
    1351 \lstinline$eat_double( (double)-?( (int)li) )$                                  & 7                     & (unsafe) \\
    1352 \lstinline$eat_double( (double)-?( (unsigned)li) )$                             & 6                     & (unsafe) \\
    1353 \lstinline$eat_double( (double)-?(li) )$                                                & 5                     & \(0+5=5\) \\
    1354 \lstinline$eat_double( (double)-?( (long unsigned int)li) )$    & 4                     & \(1+4=5\) \\
    1355 \lstinline$eat_double( (double)-?( (long long int)li) )$                & 3                     & \(2+3=5\) \\
    1356 \lstinline$eat_double( (double)-?( (long long unsigned int)li) )$& 2            & \(3+2=5\) \\
    1357 \lstinline$eat_double( (double)-?( (float)li) )$                                & 1                     & \(4+1=5\) \\
    1358 \lstinline$eat_double( (double)-?( (double)li) )$                               & 0                     & \(5+0=5\) \\
    1359 \lstinline$eat_double( (double)-?( (long double)li) )$                  & (unsafe)      & (unsafe) \\
    1360 \lstinline$eat_double( (double)-?( (_Complex float)li) )$               & (unsafe)      & (unsafe) \\
    1361 \lstinline$eat_double( (double)-?( (_Complex double)li) )$              & (unsafe)      & (unsafe) \\
    1362 \lstinline$eat_double( (double)-?( (_Complex long double)li) )$ & (unsafe)      & (unsafe) \\
     1354\lstinline@eat_double( (double)-?( (int)li) )@                                  & 7                     & (unsafe) \\
     1355\lstinline@eat_double( (double)-?( (unsigned)li) )@                             & 6                     & (unsafe) \\
     1356\lstinline@eat_double( (double)-?(li) )@                                                & 5                     & \(0+5=5\) \\
     1357\lstinline@eat_double( (double)-?( (long unsigned int)li) )@    & 4                     & \(1+4=5\) \\
     1358\lstinline@eat_double( (double)-?( (long long int)li) )@                & 3                     & \(2+3=5\) \\
     1359\lstinline@eat_double( (double)-?( (long long unsigned int)li) )@& 2            & \(3+2=5\) \\
     1360\lstinline@eat_double( (double)-?( (float)li) )@                                & 1                     & \(4+1=5\) \\
     1361\lstinline@eat_double( (double)-?( (double)li) )@                               & 0                     & \(5+0=5\) \\
     1362\lstinline@eat_double( (double)-?( (long double)li) )@                  & (unsafe)      & (unsafe) \\
     1363\lstinline@eat_double( (double)-?( (_Complex float)li) )@               & (unsafe)      & (unsafe) \\
     1364\lstinline@eat_double( (double)-?( (_Complex double)li) )@              & (unsafe)      & (unsafe) \\
     1365\lstinline@eat_double( (double)-?( (_Complex long double)li) )@ & (unsafe)      & (unsafe) \\
    13631366\end{tabular}
    13641367\end{center}
    1365 Each has result type \lstinline$void$, so the best must be selected.
     1368Each has result type \lstinline@void@, so the best must be selected.
    13661369The interpretations involving unsafe conversions are discarded.
    13671370The remainder have equal expression conversion costs, so the
    13681371``highest argument conversion cost'' rule is invoked, and the chosen interpretation is
    1369 \lstinline$eat_double( (double)-?(li) )$.
    1370 
    1371 
    1372 \subsubsection{The \lstinline$sizeof$ and \lstinline$_Alignof$ operators}
     1372\lstinline@eat_double( (double)-?(li) )@.
     1373
     1374
     1375\subsubsection[The sizeof and \_Alignof operators]{The \lstinline@sizeof@ and \lstinline@_Alignof@ operators}
    13731376
    13741377\constraints
    1375 The operand of \lstinline$sizeof$ or \lstinline$_Alignof$ shall not be \lstinline$type$,
    1376 \lstinline$dtype$, or \lstinline$ftype$.
    1377 
    1378 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$.
    1379 
    1380 When \lstinline$sizeof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1378The operand of \lstinline@sizeof@ or \lstinline@_Alignof@ shall not be \lstinline@type@, \lstinline@dtype@, or \lstinline@ftype@.
     1379
     1380When the \lstinline@sizeof@\use{sizeof} operator is applied to an expression, the expression shall have exactly one \Index{interpretation}\index{ambiguous interpretation}, which shall be unambiguous. \semantics A \lstinline@sizeof@ or \lstinline@_Alignof@ expression has one interpretation, of type \lstinline@size_t@.
     1381
     1382When \lstinline@sizeof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
    13811383\nonterm{type-parameter}, it yields the size in bytes of the type that implements the operand.
    13821384When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
    13831385
    1384 When \lstinline$_Alignof$ is applied to an identifier declared by a \nonterm{type-declaration} or a
     1386When \lstinline@_Alignof@ is applied to an identifier declared by a \nonterm{type-declaration} or a
    13851387\nonterm{type-parameter}, it yields the alignment requirement of the type that implements the operand.
    13861388When the operand is an opaque type or an inferred type parameter\index{inferred parameter}, the expression is not a constant expression.
     
    13891391otype Pair = struct { int first, second; };
    13901392size_t p_size = sizeof(Pair);           // constant expression
    1391 extern otype Rational;@\use{Rational}@
     1393extern otype Rational;§\use{Rational}§
    13921394size_t c_size = sizeof(Rational);       // non-constant expression
    13931395forall(type T) T f(T p1, T p2) {
     
    13961398}
    13971399\end{lstlisting}
    1398 ``\lstinline$sizeof Rational$'', although not statically known, is fixed.
    1399 Within \lstinline$f()$,
    1400 ``\lstinline$sizeof(T)$'' is fixed for each call of \lstinline$f()$, but may vary from call to call.
     1400``\lstinline@sizeof Rational@'', although not statically known, is fixed.
     1401Within \lstinline@f()@,
     1402``\lstinline@sizeof(T)@'' is fixed for each call of \lstinline@f()@, but may vary from call to call.
    14011403\end{rationale}
    14021404
     
    14071409\lhs{cast-expression}
    14081410\rhs \nonterm{unary-expression}
    1409 \rhs \lstinline$($ \nonterm{type-name} \lstinline$)$ \nonterm{cast-expression}
     1411\rhs \lstinline@(@ \nonterm{type-name} \lstinline@)@ \nonterm{cast-expression}
    14101412\end{syntax}
    14111413
    14121414\constraints
    1413 The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline$type$,
    1414 \lstinline$dtype$, or \lstinline$ftype$.
     1415The \nonterm{type-name} in a \nonterm{cast-expression} shall not be \lstinline@type@,
     1416\lstinline@dtype@, or \lstinline@ftype@.
    14151417
    14161418\semantics
    14171419
    1418 In a \Index{cast expression} ``\lstinline$($\nonterm{type-name}\lstinline$)e$'', if
    1419 \nonterm{type-name} is the type of an interpretation of \lstinline$e$, then that interpretation is the only interpretation of the cast expression;
    1420 otherwise, \lstinline$e$ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
     1420In a \Index{cast expression} ``\lstinline@(@\nonterm{type-name}\lstinline@)e@'', if
     1421\nonterm{type-name} is the type of an interpretation of \lstinline@e@, then that interpretation is the only interpretation of the cast expression;
     1422otherwise, \lstinline@e@ shall have some interpretation that can be converted to \nonterm{type-name}, and the interpretation of the cast expression is the cast of the interpretation that can be converted at the lowest cost.
    14211423The 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.
    14221424
     
    14311433\lhs{multiplicative-expression}
    14321434\rhs \nonterm{cast-expression}
    1433 \rhs \nonterm{multiplicative-expression} \lstinline$*$ \nonterm{cast-expression}
    1434 \rhs \nonterm{multiplicative-expression} \lstinline$/$ \nonterm{cast-expression}
    1435 \rhs \nonterm{multiplicative-expression} \lstinline$%$ \nonterm{cast-expression}
     1435\rhs \nonterm{multiplicative-expression} \lstinline@*@ \nonterm{cast-expression}
     1436\rhs \nonterm{multiplicative-expression} \lstinline@/@ \nonterm{cast-expression}
     1437\rhs \nonterm{multiplicative-expression} \lstinline@%@ \nonterm{cast-expression}
    14361438\end{syntax}
    14371439
    14381440\rewriterules
    14391441\begin{lstlisting}
    1440 a * b @\rewrite@ ?*?( a, b )@\use{?*?}@
    1441 a / b @\rewrite@ ?/?( a, b )@\use{?/?}@
    1442 a % b @\rewrite@ ?%?( a, b )@\use{?%?}@
     1442a * b §\rewrite§ ?*?( a, b )§\use{?*?}§
     1443a / b §\rewrite§ ?/?( a, b )§\use{?/?}§
     1444a % b §\rewrite§ ?%?( a, b )§\use{?%?}§
    14431445\end{lstlisting}
    14441446
     
    14671469        ?*?( _Complex long double, _Complex long double ), ?/?( _Complex long double, _Complex long double );
    14681470\end{lstlisting}
    1469 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1471For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    14701472% Don't use predefined: keep this out of prelude.cf.
    14711473\begin{lstlisting}
     
    14851487int i;
    14861488long li;
    1487 void eat_double( double );@\use{eat_double}@
     1489void eat_double( double );§\use{eat_double}§
    14881490eat_double( li % i );
    14891491\end{lstlisting}
    1490 ``\lstinline$li % i$'' is rewritten as ``\lstinline$?%?(li, i )$''.
    1491 The valid interpretations of \lstinline$?%?(li, i )$, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline$double$ (assuming no extended integer types are present ) are
     1492``\lstinline@li % i@'' is rewritten as ``\lstinline@?%?(li, i )@''.
     1493The valid interpretations of \lstinline@?%?(li, i )@, the cost\index{conversion cost} of converting their arguments, and the cost of converting the result to \lstinline@double@ (assuming no extended integer types are present ) are
    14921494\begin{center}
    14931495\begin{tabular}{lcc} interpretation & argument cost & result cost \\
    14941496\hline
    1495 \lstinline$ ?%?( (int)li, i )$                                                                          & (unsafe)      & 6     \\
    1496 \lstinline$ ?%?( (unsigned)li,(unsigned)i )$                                            & (unsafe)      & 5     \\
    1497 \lstinline$ ?%?( li, (long)i )$                                                                         & 1                     & 4     \\
    1498 \lstinline$ ?%?( (long unsigned)li,(long unsigned)i )$                          & 3                     & 3     \\
    1499 \lstinline$ ?%?( (long long)li,(long long)i )$                                          & 5                     & 2     \\
    1500 \lstinline$ ?%?( (long long unsigned)li, (long long unsigned)i )$       & 7                     & 1     \\
     1497\lstinline@ ?%?( (int)li, i )@                                                                          & (unsafe)      & 6     \\
     1498\lstinline@ ?%?( (unsigned)li,(unsigned)i )@                                            & (unsafe)      & 5     \\
     1499\lstinline@ ?%?( li, (long)i )@                                                                         & 1                     & 4     \\
     1500\lstinline@ ?%?( (long unsigned)li,(long unsigned)i )@                          & 3                     & 3     \\
     1501\lstinline@ ?%?( (long long)li,(long long)i )@                                          & 5                     & 2     \\
     1502\lstinline@ ?%?( (long long unsigned)li, (long long unsigned)i )@       & 7                     & 1     \\
    15011503\end{tabular}
    15021504\end{center}
    1503 The best interpretation of \lstinline$eat_double( li, i )$ is
    1504 \lstinline$eat_double( (double)?%?(li, (long)i ))$, which has no unsafe conversions and the lowest total cost.
    1505 
    1506 \begin{rationale}
    1507 {\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
    1508 \lstinline$s$ is a \lstinline$short int$, ``\lstinline$s *s$'' does not have type \lstinline$short int$;
    1509 it is treated as ``\lstinline$( (int)s ) * ( (int)s )$'', and has type \lstinline$int$. \CFA matches that pattern;
    1510 it does not predefine ``\lstinline$short ?*?( short, short )$''.
     1505The best interpretation of \lstinline@eat_double( li, i )@ is
     1506\lstinline@eat_double( (double)?%?(li, (long)i ))@, which has no unsafe conversions and the lowest total cost.
     1507
     1508\begin{rationale}
     1509{\c11} defines most arithmetic operations to apply an \Index{integer promotion} to any argument that belongs to a type that has an \Index{integer conversion rank} less than that of \lstinline@int@.If
     1510\lstinline@s@ is a \lstinline@short int@, ``\lstinline@s *s@'' does not have type \lstinline@short int@;
     1511it is treated as ``\lstinline@( (int)s ) * ( (int)s )@'', and has type \lstinline@int@. \CFA matches that pattern;
     1512it does not predefine ``\lstinline@short ?*?( short, short )@''.
    15111513
    15121514These ``missing'' operators limit polymorphism.
     
    15171519square( s );
    15181520\end{lstlisting}
    1519 Since \CFA does not define a multiplication operator for \lstinline$short int$,
    1520 \lstinline$square( s )$ is treated as \lstinline$square( (int)s )$, and the result has type
    1521 \lstinline$int$.
     1521Since \CFA does not define a multiplication operator for \lstinline@short int@,
     1522\lstinline@square( s )@ is treated as \lstinline@square( (int)s )@, and the result has type
     1523\lstinline@int@.
    15221524This is mildly surprising, but it follows the {\c11} operator pattern.
    15231525
     
    15291531\end{lstlisting}
    15301532This has no valid interpretations, because \CFA has no conversion from ``array of
    1531 \lstinline$short int$'' to ``array of \lstinline$int$''.
     1533\lstinline@short int@'' to ``array of \lstinline@int@''.
    15321534The alternatives in such situations include
    15331535\begin{itemize}
    15341536\item
    1535 Defining monomorphic overloadings of \lstinline$product$ for \lstinline$short$ and the other
     1537Defining monomorphic overloadings of \lstinline@product@ for \lstinline@short@ and the other
    15361538``small'' types.
    15371539\item
    1538 Defining ``\lstinline$short ?*?( short, short )$'' within the scope containing the call to
    1539 \lstinline$product$.
    1540 \item
    1541 Defining \lstinline$product$ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
     1540Defining ``\lstinline@short ?*?( short, short )@'' within the scope containing the call to
     1541\lstinline@product@.
     1542\item
     1543Defining \lstinline@product@ to take as an argument a conversion function from the ``small'' type to the operator's argument type.
    15421544\end{itemize}
    15431545\end{rationale}
     
    15491551\lhs{additive-expression}
    15501552\rhs \nonterm{multiplicative-expression}
    1551 \rhs \nonterm{additive-expression} \lstinline$+$ \nonterm{multiplicative-expression}
    1552 \rhs \nonterm{additive-expression} \lstinline$-$ \nonterm{multiplicative-expression}
     1553\rhs \nonterm{additive-expression} \lstinline@+@ \nonterm{multiplicative-expression}
     1554\rhs \nonterm{additive-expression} \lstinline@-@ \nonterm{multiplicative-expression}
    15531555\end{syntax}
    15541556
    15551557\rewriterules
    15561558\begin{lstlisting}
    1557 a + b @\rewrite@ ?+?( a, b )@\use{?+?}@
    1558 a - b @\rewrite@ ?-?( a, b )@\use{?-?}@
     1559a + b §\rewrite§ ?+?( a, b )§\use{?+?}§
     1560a - b §\rewrite§ ?-?( a, b )§\use{?-?}§
    15591561\end{lstlisting}
    15601562
     
    16091611        * ?-?( _Atomic const restrict volatile T *, _Atomic const restrict volatile T * );
    16101612\end{lstlisting}
    1611 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1613For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    16121614% Don't use predefined: keep this out of prelude.cf.
    16131615\begin{lstlisting}
     
    16191621
    16201622\begin{rationale}
    1621 \lstinline$ptrdiff_t$ is an implementation-defined identifier defined in \lstinline$<stddef.h>$ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
     1623\lstinline@ptrdiff_t@ is an implementation-defined identifier defined in \lstinline@<stddef.h>@ that is synonymous with a signed integral type that is large enough to hold the difference between two pointers.
    16221624It 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.
    1623 The {\c11} standard uses \lstinline$size_t$ in several cases where a library function takes an argument that is used as a subscript, but \lstinline$size_t$ is unsuitable here because it is an unsigned type.
     1625The {\c11} standard uses \lstinline@size_t@ in several cases where a library function takes an argument that is used as a subscript, but \lstinline@size_t@ is unsuitable here because it is an unsigned type.
    16241626\end{rationale}
    16251627
     
    16301632\lhs{shift-expression}
    16311633\rhs \nonterm{additive-expression}
    1632 \rhs \nonterm{shift-expression} \lstinline$<<$ \nonterm{additive-expression}
    1633 \rhs \nonterm{shift-expression} \lstinline$>>$ \nonterm{additive-expression}
     1634\rhs \nonterm{shift-expression} \lstinline@<<@ \nonterm{additive-expression}
     1635\rhs \nonterm{shift-expression} \lstinline@>>@ \nonterm{additive-expression}
    16341636\end{syntax}
    16351637
    16361638\rewriterules \use{?>>?}%use{?<<?}
    16371639\begin{lstlisting}
    1638 a << b @\rewrite@ ?<<?( a, b )
    1639 a >> b @\rewrite@ ?>>?( a, b )
     1640a << b §\rewrite§ ?<<?( a, b )
     1641a >> b §\rewrite§ ?>>?( a, b )
    16401642\end{lstlisting}
    16411643
     
    16491651long long unsigned int ?<<?( long long unsigned int, int ), ?>>?( long long unsigned int, int);
    16501652\end{lstlisting}
    1651 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1653For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    16521654% Don't use predefined: keep this out of prelude.cf.
    16531655\begin{lstlisting}
     
    16691671\lhs{relational-expression}
    16701672\rhs \nonterm{shift-expression}
    1671 \rhs \nonterm{relational-expression} \lstinline$< $ \nonterm{shift-expression}
    1672 \rhs \nonterm{relational-expression} \lstinline$> $ \nonterm{shift-expression}
    1673 \rhs \nonterm{relational-expression} \lstinline$<=$ \nonterm{shift-expression}
    1674 \rhs \nonterm{relational-expression} \lstinline$>=$ \nonterm{shift-expression}
     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}
    16751677\end{syntax}
    16761678
    16771679\rewriterules\use{?>?}\use{?>=?}%use{?<?}%use{?<=?}
    16781680\begin{lstlisting}
    1679 a < b @\rewrite@ ?<?( a, b )
    1680 a > b @\rewrite@ ?>?( a, b )
    1681 a <= b @\rewrite@ ?<=?( a, b )
    1682 a >= b @\rewrite@ ?>=?( a, b )
     1681a < b §\rewrite§ ?<?( a, b )
     1682a > b §\rewrite§ ?>?( a, b )
     1683a <= b §\rewrite§ ?<=?( a, b )
     1684a >= b §\rewrite§ ?>=?( a, b )
    16831685\end{lstlisting}
    16841686
     
    17121714        ?>=?( _Atomic const restrict volatile DT *, _Atomic const restrict volatile DT * );
    17131715\end{lstlisting}
    1714 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1716For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    17151717% Don't use predefined: keep this out of prelude.cf.
    17161718\begin{lstlisting}
     
    17301732\lhs{equality-expression}
    17311733\rhs \nonterm{relational-expression}
    1732 \rhs \nonterm{equality-expression} \lstinline$==$ \nonterm{relational-expression}
    1733 \rhs \nonterm{equality-expression} \lstinline$!=$ \nonterm{relational-expression}
     1734\rhs \nonterm{equality-expression} \lstinline@==@ \nonterm{relational-expression}
     1735\rhs \nonterm{equality-expression} \lstinline@!=@ \nonterm{relational-expression}
    17341736\end{syntax}
    17351737
    17361738\rewriterules
    17371739\begin{lstlisting}
    1738 a == b @\rewrite@ ?==?( a, b )@\use{?==?}@
    1739 a != b @\rewrite@ ?!=?( a, b )@\use{?"!=?}@
     1740a == b §\rewrite§ ?==?( a, b )§\use{?==?}§
     1741a != b §\rewrite§ ?!=?( a, b )§\use{?"!=?}§
    17401742\end{lstlisting}
    17411743
     
    17901792        ?==?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * ), ?!=?( forall( ftype FT2) FT2*, forall( ftype FT3) FT3 * );
    17911793\end{lstlisting}
    1792 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1794For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    17931795% Don't use predefined: keep this out of prelude.cf.
    17941796\begin{lstlisting}
     
    17981800
    17991801\begin{rationale}
    1800 The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline$void$ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
     1802The polymorphic equality operations come in three styles: comparisons between pointers of compatible types, between pointers to \lstinline@void@ and pointers to object types or incomplete types, and between the \Index{null pointer} constant and pointers to any type.
    18011803In the last case, a special constraint rule for null pointer constant operands has been replaced by a consequence of the \CFA type system.
    18021804\end{rationale}
     
    18191821\lhs{AND-expression}
    18201822\rhs \nonterm{equality-expression}
    1821 \rhs \nonterm{AND-expression} \lstinline$&$ \nonterm{equality-expression}
     1823\rhs \nonterm{AND-expression} \lstinline@&@ \nonterm{equality-expression}
    18221824\end{syntax}
    18231825
    18241826\rewriterules
    18251827\begin{lstlisting}
    1826 a & b @\rewrite@ ?&?( a, b )@\use{?&?}@
     1828a & b §\rewrite§ ?&?( a, b )§\use{?&?}§
    18271829\end{lstlisting}
    18281830
     
    18361838long long unsigned int ?&?( long long unsigned int, long long unsigned int );
    18371839\end{lstlisting}
    1838 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1840For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    18391841% Don't use predefined: keep this out of prelude.cf.
    18401842\begin{lstlisting}
     
    18511853\lhs{exclusive-OR-expression}
    18521854\rhs \nonterm{AND-expression}
    1853 \rhs \nonterm{exclusive-OR-expression} \lstinline$^$ \nonterm{AND-expression}
     1855\rhs \nonterm{exclusive-OR-expression} \lstinline@^@ \nonterm{AND-expression}
    18541856\end{syntax}
    18551857
    18561858\rewriterules
    18571859\begin{lstlisting}
    1858 a ^ b @\rewrite@ ?^?( a, b )@\use{?^?}@
     1860a ^ b §\rewrite§ ?^?( a, b )§\use{?^?}§
    18591861\end{lstlisting}
    18601862
     
    18681870long long unsigned int ?^?( long long unsigned int, long long unsigned int );
    18691871\end{lstlisting}
    1870 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1872For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    18711873% Don't use predefined: keep this out of prelude.cf.
    18721874\begin{lstlisting}
     
    18831885\lhs{inclusive-OR-expression}
    18841886\rhs \nonterm{exclusive-OR-expression}
    1885 \rhs \nonterm{inclusive-OR-expression} \lstinline$|$ \nonterm{exclusive-OR-expression}
     1887\rhs \nonterm{inclusive-OR-expression} \lstinline@|@ \nonterm{exclusive-OR-expression}
    18861888\end{syntax}
    18871889
    18881890\rewriterules\use{?"|?}
    18891891\begin{lstlisting}
    1890 a | b @\rewrite@ ?|?( a, b )
     1892a | b §\rewrite§ ?|?( a, b )
    18911893\end{lstlisting}
    18921894
     
    19001902long long unsigned int ?|?( long long unsigned int, long long unsigned int );
    19011903\end{lstlisting}
    1902 For every extended integer type \lstinline$X$ with \Index{integer conversion rank} greater than the rank of \lstinline$int$ there exist
     1904For every extended integer type \lstinline@X@ with \Index{integer conversion rank} greater than the rank of \lstinline@int@ there exist
    19031905% Don't use predefined: keep this out of prelude.cf.
    19041906\begin{lstlisting}
     
    19151917\lhs{logical-AND-expression}
    19161918\rhs \nonterm{inclusive-OR-expression}
    1917 \rhs \nonterm{logical-AND-expression} \lstinline$&&$ \nonterm{inclusive-OR-expression}
     1919\rhs \nonterm{logical-AND-expression} \lstinline@&&@ \nonterm{inclusive-OR-expression}
    19181920\end{syntax}
    19191921
    1920 \semantics The operands of the expression ``\lstinline$a && b$'' are treated as
    1921 ``\lstinline$(int)((a)!=0)$'' and ``\lstinline$(int)((b)!=0)$'', which shall both be unambiguous.
    1922 The expression has only one interpretation, which is of type \lstinline$int$.
    1923 \begin{rationale}
    1924 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.
    1925 
    1926 A common C idiom omits comparisons to \lstinline$0$ in the controlling expressions of loops and
    1927 \lstinline$if$ statements.
    1928 For instance, the loop below iterates as long as \lstinline$rp$ points at a \lstinline$Rational$ value that is non-zero.
    1929 
    1930 \begin{lstlisting}
    1931 extern otype Rational;@\use{Rational}@
    1932 extern const Rational 0;@\use{0}@
     1922\semantics The operands of the expression ``\lstinline@a && b@'' are treated as
     1923``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b)!=0)@'', which shall both be unambiguous.
     1924The expression has only one interpretation, which is of type \lstinline@int@.
     1925\begin{rationale}
     1926When the operands of a logical expression are values of built-in types, and ``\lstinline@!=@'' has not been redefined for those types, the compiler can optimize away the function calls.
     1927
     1928A common C idiom omits comparisons to \lstinline@0@ in the controlling expressions of loops and
     1929\lstinline@if@ statements.
     1930For instance, the loop below iterates as long as \lstinline@rp@ points at a \lstinline@Rational@ value that is non-zero.
     1931
     1932\begin{lstlisting}
     1933extern otype Rational;§\use{Rational}§
     1934extern const Rational 0;§\use{0}§
    19331935extern int ?!=?( Rational, Rational );
    19341936Rational *rp;
    19351937while ( rp && *rp ) { ... }
    19361938\end{lstlisting}
    1937 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.
    1938 In contrast, {\CC} would apply a programmer-defined \lstinline$Rational$-to-\lstinline$int$ conversion to \lstinline$*rp$ in the equivalent situation.
    1939 The conversion to \lstinline$int$ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
     1939The logical expression calls the \lstinline@Rational@ inequality operator, passing it \lstinline@*rp@ and the \lstinline@Rational 0@, and getting a 1 or 0 as a result.
     1940In contrast, {\CC} would apply a programmer-defined \lstinline@Rational@-to-\lstinline@int@ conversion to \lstinline@*rp@ in the equivalent situation.
     1941The conversion to \lstinline@int@ would produce a general integer value, which is unfortunate, and possibly dangerous if the conversion was not written with this situation in mind.
    19401942\end{rationale}
    19411943
     
    19461948\lhs{logical-OR-expression}
    19471949\rhs \nonterm{logical-AND-expression}
    1948 \rhs \nonterm{logical-OR-expression} \lstinline$||$ \nonterm{logical-AND-expression}
     1950\rhs \nonterm{logical-OR-expression} \lstinline@||@ \nonterm{logical-AND-expression}
    19491951\end{syntax}
    19501952
    19511953\semantics
    19521954
    1953 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.
    1954 The expression has only one interpretation, which is of type \lstinline$int$.
     1955The operands of the expression ``\lstinline@a || b@'' are treated as ``\lstinline@(int)((a)!=0)@'' and ``\lstinline@(int)((b))!=0)@'', which shall both be unambiguous.
     1956The expression has only one interpretation, which is of type \lstinline@int@.
    19551957
    19561958
     
    19601962\lhs{conditional-expression}
    19611963\rhs \nonterm{logical-OR-expression}
    1962 \rhs \nonterm{logical-OR-expression} \lstinline$?$ \nonterm{expression}
    1963          \lstinline$:$ \nonterm{conditional-expression}
     1964\rhs \nonterm{logical-OR-expression} \lstinline@?@ \nonterm{expression}
     1965         \lstinline@:@ \nonterm{conditional-expression}
    19641966\end{syntax}
    19651967
    19661968\semantics
    1967 In the conditional expression\use{?:} ``\lstinline$a?b:c$'', if the second and third operands both have an interpretation with \lstinline$void$ type, then the expression has an interpretation with type \lstinline$void$, equivalent to
     1969In the conditional expression\use{?:} ``\lstinline@a?b:c@'', if the second and third operands both have an interpretation with \lstinline@void@ type, then the expression has an interpretation with type \lstinline@void@, equivalent to
    19681970\begin{lstlisting}
    19691971( int)(( a)!=0) ? ( void)( b) : ( void)( c)
    19701972\end{lstlisting}
    19711973
    1972 If the second and third operands both have interpretations with non-\lstinline$void$ types, the expression is treated as if it were the call ``\lstinline$cond((a)!=0, b, c)$'', with \lstinline$cond$ declared as
     1974If the second and third operands both have interpretations with non-\lstinline@void@ types, the expression is treated as if it were the call ``\lstinline@cond((a)!=0, b, c)@'', with \lstinline@cond@ declared as
    19731975\begin{lstlisting}
    19741976forall( otype T ) T cond( int, T, T );
     
    20222024rand() ? i : l;
    20232025\end{lstlisting}
    2024 The best interpretation infers the expression's type to be \lstinline$long$ and applies the safe
    2025 \lstinline$int$-to-\lstinline$long$ conversion to \lstinline$i$.
     2026The best interpretation infers the expression's type to be \lstinline@long@ and applies the safe
     2027\lstinline@int@-to-\lstinline@long@ conversion to \lstinline@i@.
    20262028
    20272029\begin{lstlisting}
     
    20302032rand() ? cip : vip;
    20312033\end{lstlisting}
    2032 The expression has type \lstinline$const volatile int *$, with safe conversions applied to the second and third operands to add \lstinline$volatile$ and \lstinline$const$ qualifiers, respectively.
     2034The expression has type \lstinline@const volatile int *@, with safe conversions applied to the second and third operands to add \lstinline@volatile@ and \lstinline@const@ qualifiers, respectively.
    20332035
    20342036\begin{lstlisting}
    20352037rand() ? cip : 0;
    20362038\end{lstlisting}
    2037 The expression has type \lstinline$const int *$, with a specialization conversion applied to
    2038 \lstinline$0$.
     2039The expression has type \lstinline@const int *@, with a specialization conversion applied to
     2040\lstinline@0@.
    20392041
    20402042
     
    20472049         \nonterm{assignment-expression}
    20482050\lhs{assignment-operator} one of
    2049 \rhs \lstinline$=$\ \ \lstinline$*=$\ \ \lstinline$/=$\ \ \lstinline$%=$\ \ \lstinline$+=$\ \ \lstinline$-=$\ \ 
    2050          \lstinline$<<=$\ \ \lstinline$>>=$\ \ \lstinline$&=$\ \ \lstinline$^=$\ \ \lstinline$|=$
     2051\rhs \lstinline@=@\ \ \lstinline@*=@\ \ \lstinline@/=@\ \ \lstinline@%=@\ \ \lstinline@+=@\ \ \lstinline@-=@\ \ 
     2052         \lstinline@<<=@\ \ \lstinline@>>=@\ \ \lstinline@&=@\ \ \lstinline@^=@\ \ \lstinline@|=@
    20512053\end{syntax}
    20522054
     
    20572059\use{?>>=?}\use{?&=?}\use{?^=?}\use{?"|=?}%use{?<<=?}
    20582060\begin{lstlisting}
    2059 a @$\leftarrow$@ b @\rewrite@ ?@$\leftarrow$@?( &( a ), b )
     2061a §$\leftarrow$§ b §\rewrite§ ?§$\leftarrow$§?( &( a ), b )
    20602062\end{lstlisting}
    20612063
    20622064\semantics
    20632065Each interpretation of the left operand of an assignment expression is considered separately.
    2064 For each interpretation that is a bit-field or is declared with the \lstinline$register$ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
     2066For each interpretation that is a bit-field or is declared with the \lstinline@register@ storage class specifier, the expression has one valid interpretation, with the type of the left operand.
    20652067The right operand is cast to that type, and the assignment expression is ambiguous if either operand is.
    20662068For the remaining interpretations, the expression is rewritten, and the interpretations of the assignment expression are the interpretations of the corresponding function call.
     
    22952297\end{lstlisting}
    22962298\begin{rationale}
    2297 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.
    2298 \end{rationale}
    2299 
    2300 For every complete structure or union type \lstinline$S$ there exist
     2299The pattern of overloadings for simple assignment resembles that of pointer increment and decrement, except that the polymorphic pointer assignment functions declare a \lstinline@dtype@ parameter, instead of a \lstinline@type@ parameter, because the left operand may be a pointer to an incomplete type.
     2300\end{rationale}
     2301
     2302For every complete structure or union type \lstinline@S@ there exist
    23012303% Don't use predefined: keep this out of prelude.cf.
    23022304\begin{lstlisting}
     
    23042306\end{lstlisting}
    23052307
    2306 For every extended integer type \lstinline$X$ there exist
     2308For every extended integer type \lstinline@X@ there exist
    23072309% Don't use predefined: keep this out of prelude.cf.
    23082310\begin{lstlisting}
     
    23102312\end{lstlisting}
    23112313
    2312 For every complete enumerated type \lstinline$E$ there exist
     2314For every complete enumerated type \lstinline@E@ there exist
    23132315% Don't use predefined: keep this out of prelude.cf.
    23142316\begin{lstlisting}
     
    23162318\end{lstlisting}
    23172319\begin{rationale}
    2318 The right-hand argument is \lstinline$int$ because enumeration constants have type \lstinline$int$.
     2320The right-hand argument is \lstinline@int@ because enumeration constants have type \lstinline@int@.
    23192321\end{rationale}
    23202322
     
    25772579\end{lstlisting}
    25782580
    2579 For every extended integer type \lstinline$X$ there exist
     2581For every extended integer type \lstinline@X@ there exist
    25802582% Don't use predefined: keep this out of prelude.cf.
    25812583\begin{lstlisting}
     
    25922594\end{lstlisting}
    25932595
    2594 For every complete enumerated type \lstinline$E$ there exist
     2596For every complete enumerated type \lstinline@E@ there exist
    25952597% Don't use predefined: keep this out of prelude.cf.
    25962598\begin{lstlisting}
     
    26132615\lhs{expression}
    26142616\rhs \nonterm{assignment-expression}
    2615 \rhs \nonterm{expression} \lstinline$,$ \nonterm{assignment-expression}
     2617\rhs \nonterm{expression} \lstinline@,@ \nonterm{assignment-expression}
    26162618\end{syntax}
    26172619
    26182620\semantics
    2619 In the comma expression ``\lstinline$a, b$'', the first operand is interpreted as
    2620 ``\lstinline$( void )(a)$'', which shall be unambiguous\index{ambiguous interpretation}.
     2621In the comma expression ``\lstinline@a, b@'', the first operand is interpreted as
     2622``\lstinline@( void )(a)@'', which shall be unambiguous\index{ambiguous interpretation}.
    26212623The interpretations of the expression are the interpretations of the second operand.
    26222624
     
    26532655{ ... }
    26542656\end{lstlisting}
    2655 Without the rule, \lstinline$Complex$ would be a type in the first case, and a parameter name in the second.
     2657Without the rule, \lstinline@Complex@ would be a type in the first case, and a parameter name in the second.
    26562658\end{rationale}
    26572659
     
    26792681\examples
    26802682\begin{lstlisting}
    2681 struct point {@\impl{point}@
     2683struct point {§\impl{point}§
    26822684        int x, y;
    26832685};
    2684 struct color_point {@\impl{color_point}@
     2686struct color_point {§\impl{color_point}§
    26852687        enum { RED, BLUE, GREEN } color;
    26862688        struct point;
     
    26892691cp.x = 0;
    26902692cp.color = RED;
    2691 struct literal {@\impl{literal}@
     2693struct literal {§\impl{literal}§
    26922694        enum { NUMBER, STRING } tag;
    26932695        union {
     
    27102712\begin{syntax}
    27112713\lhs{forall-specifier}
    2712 \rhs \lstinline$forall$ \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
     2714\rhs \lstinline@forall@ \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
    27132715\end{syntax}
    27142716
     
    27222724} mkPair( T, T ); // illegal
    27232725\end{lstlisting}
    2724 If an instance of \lstinline$struct Pair$ was declared later in the current scope, what would the members' type be?
     2726If an instance of \lstinline@struct Pair@ was declared later in the current scope, what would the members' type be?
    27252727\end{rationale}
    27262728\end{comment}
     
    27292731The \nonterm{type-parameter-list}s and assertions of the \nonterm{forall-specifier}s declare type identifiers, function and object identifiers with \Index{no linkage}.
    27302732
    2731 If, in the declaration ``\lstinline$T D$'', \lstinline$T$ contains \nonterm{forall-specifier}s and
    2732 \lstinline$D$ has the form
    2733 \begin{lstlisting}
    2734 D( @\normalsize\nonterm{parameter-type-list}@ )
    2735 \end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline$D$, and it is used in the type of a parameter in the following
     2733If, in the declaration ``\lstinline@T D@'', \lstinline@T@ contains \nonterm{forall-specifier}s and
     2734\lstinline@D@ has the form
     2735\begin{lstlisting}
     2736D( §\normalsize\nonterm{parameter-type-list}§ )
     2737\end{lstlisting} then a type identifier declared by one of the \nonterm{forall-specifier}s is an \define{inferred parameter} of the function declarator if and only if it is not an inferred parameter of a function declarator in \lstinline@D@, and it is used in the type of a parameter in the following
    27362738\nonterm{type-parameter-list} or it and an inferred parameter are used as arguments of a
    27372739\Index{specification} in one of the \nonterm{forall-specifier}s.
     
    27442746If this restriction were lifted, it would be possible to write
    27452747\begin{lstlisting}
    2746 forall( otype T ) T * alloc( void );@\use{alloc}@ int *p = alloc();
    2747 \end{lstlisting}
    2748 Here \lstinline$alloc()$ would receive \lstinline$int$ as an inferred argument, and return an
    2749 \lstinline$int *$.
    2750 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.
    2751 
    2752 With the current restriction, \lstinline$alloc()$ must be given an argument that determines
    2753 \lstinline$T$:
    2754 \begin{lstlisting}
    2755 forall( otype T ) T * alloc( T initial_value );@\use{alloc}@
     2748forall( otype T ) T * alloc( void );§\use{alloc}§ int *p = alloc();
     2749\end{lstlisting}
     2750Here \lstinline@alloc()@ would receive \lstinline@int@ as an inferred argument, and return an
     2751\lstinline@int *@.
     2752In general, if a call to \lstinline@alloc()@ is a subexpression of an expression involving polymorphic functions and overloaded identifiers, there could be considerable distance between the call and the subexpression that causes \lstinline@T@ to be bound.
     2753
     2754With the current restriction, \lstinline@alloc()@ must be given an argument that determines
     2755\lstinline@T@:
     2756\begin{lstlisting}
     2757forall( otype T ) T * alloc( T initial_value );§\use{alloc}§
    27562758\end{lstlisting}
    27572759\end{rationale}
     
    27782780forall( otype T ) T fT( T );
    27792781\end{lstlisting}
    2780 \lstinline$fi()$ takes an \lstinline$int$ and returns an \lstinline$int$. \lstinline$fT()$ takes a
    2781 \lstinline$T$ and returns a \lstinline$T$, for any type \lstinline$T$.
     2782\lstinline@fi()@ takes an \lstinline@int@ and returns an \lstinline@int@. \lstinline@fT()@ takes a
     2783\lstinline@T@ and returns a \lstinline@T@, for any type \lstinline@T@.
    27822784\begin{lstlisting}
    27832785int (*pfi )( int ) = fi;
    27842786forall( otype T ) T (*pfT )( T ) = fT;
    27852787\end{lstlisting}
    2786 \lstinline$pfi$ and \lstinline$pfT$ are pointers to functions. \lstinline$pfT$ is not polymorphic, but the function it points at is.
     2788\lstinline@pfi@ and \lstinline@pfT@ are pointers to functions. \lstinline@pfT@ is not polymorphic, but the function it points at is.
    27872789\begin{lstlisting}
    27882790int (*fvpfi( void ))( int ) {
     
    27932795}
    27942796\end{lstlisting}
    2795 \lstinline$fvpfi()$ and \lstinline$fvpfT()$ are functions taking no arguments and returning pointers to functions. \lstinline$fvpfT()$ is monomorphic, but the function that its return value points at is polymorphic.
     2797\lstinline@fvpfi()@ and \lstinline@fvpfT()@ are functions taking no arguments and returning pointers to functions. \lstinline@fvpfT()@ is monomorphic, but the function that its return value points at is polymorphic.
    27962798\begin{lstlisting}
    27972799forall( otype T ) int ( *fTpfi( T ) )( int );
     
    27992801forall( otype T, otype U ) U ( *fTpfU( T ) )( U );
    28002802\end{lstlisting}
    2801 \lstinline$fTpfi()$ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
    2802 It could return \lstinline$pfi$. \lstinline$fTpfT()$ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
    2803 \lstinline$T$, where \lstinline$T$ is an inferred parameter of \lstinline$fTpfT()$.
    2804 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
    2805 ``\lstinline$fTpfT("yes")("no")$'' are legal, but ``\lstinline$fTpfT(17)("no")$'' is illegal.
    2806 \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
    2807 \lstinline$char *$.
     2803\lstinline@fTpfi()@ is a polymorphic function that returns a pointer to a monomorphic function taking an integer and returning an integer.
     2804It could return \lstinline@pfi@. \lstinline@fTpfT()@ is subtle: it is a polymorphic function returning a \emph{monomorphic} function taking and returning
     2805\lstinline@T@, where \lstinline@T@ is an inferred parameter of \lstinline@fTpfT()@.
     2806For instance, in the expression ``\lstinline@fTpfT(17)@'', \lstinline@T@ is inferred to be \lstinline@int@, and the returned value would have type \lstinline@int ( * )( int )@. ``\lstinline@fTpfT(17)(13)@'' and
     2807``\lstinline@fTpfT("yes")("no")@'' are legal, but ``\lstinline@fTpfT(17)("no")@'' is illegal.
     2808\lstinline@fTpfU()@ is polymorphic ( in type \lstinline@T@), and returns a pointer to a function that is polymorphic ( in type \lstinline@U@). ``\lstinline@f5(17)("no")@'' is a legal expression of type
     2809\lstinline@char *@.
    28082810\begin{lstlisting}
    28092811forall( otype T, otype U, otype V ) U * f( T *, U, V * const );
    28102812forall( otype U, otype V, otype W ) U * g( V *, U, W * const );
    28112813\end{lstlisting}
    2812 The functions \lstinline$f()$ and \lstinline$g()$ have compatible types.
     2814The functions \lstinline@f()@ and \lstinline@g()@ have compatible types.
    28132815Let \(f\) and \(g\) be their types;
    2814 then \(f_1\) = \lstinline$T$, \(f_2\) = \lstinline$U$, \(f_3\) = \lstinline$V$, \(g_1\)
    2815 = \lstinline$V$, \(g_2\) = \lstinline$U$, and \(g_3\) = \lstinline$W$.
     2816then \(f_1\) = \lstinline@T@, \(f_2\) = \lstinline@U@, \(f_3\) = \lstinline@V@, \(g_1\)
     2817= \lstinline@V@, \(g_2\) = \lstinline@U@, and \(g_3\) = \lstinline@W@.
    28162818Replacing every \(f_i\) by \(g_i\) in \(f\) gives
    28172819\begin{lstlisting}
     
    28192821\end{lstlisting} which has a return type and parameter list that is compatible with \(g\).
    28202822\begin{rationale}
    2821 The word ``\lstinline$type$'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
     2823The word ``\lstinline@type@'' in a forall specifier is redundant at the moment, but I want to leave room for inferred parameters of ordinary types in case parameterized types get added one day.
    28222824
    28232825Even without parameterized types, I might try to allow
     
    28452847\subsection{Type qualifiers}
    28462848
    2847 \CFA defines a new type qualifier \lstinline$lvalue$\impl{lvalue}\index{lvalue}.
     2849\CFA defines a new type qualifier \lstinline@lvalue@\impl{lvalue}\index{lvalue}.
    28482850\begin{syntax}
    28492851\oldlhs{type-qualifier}
    2850 \rhs \lstinline$lvalue$
     2852\rhs \lstinline@lvalue@
    28512853\end{syntax}
    28522854
    28532855\constraints
    2854 \lstinline$restrict$\index{register@{\lstinline$restrict$}} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
     2856\Indexc{restrict} Types other than type parameters and pointer types whose referenced type is an object type shall not be restrict-qualified.
    28552857
    28562858\semantics
    2857 An object's type may be a restrict-qualified type parameter. \lstinline$restrict$ does not establish any special semantics in that case.
     2859An object's type may be a restrict-qualified type parameter.
     2860\lstinline@restrict@ does not establish any special semantics in that case.
    28582861
    28592862\begin{rationale}
     
    28612864\end{rationale}
    28622865
    2863 \lstinline$lvalue$ may be used to qualify the return type of a function type.
    2864 Let \lstinline$T$ be an unqualified version of a type;
     2866\lstinline@lvalue@ may be used to qualify the return type of a function type.
     2867Let \lstinline@T@ be an unqualified version of a type;
    28652868then the result of calling a function with return type
    2866 \lstinline$lvalue T$ is a \Index{modifiable lvalue} of type \lstinline$T$.
    2867 \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.
    2868 \begin{rationale}
    2869 The \lstinline$const$ and \lstinline$volatile$ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline$lvalue$ qualifier is also used.
     2869\lstinline@lvalue T@ is a \Index{modifiable lvalue} of type \lstinline@T@.
     2870\lstinline@const@\use{const} and \lstinline@volatile@\use{volatile} qualifiers may also be added to indicate that the function result is a constant or volatile lvalue.
     2871\begin{rationale}
     2872The \lstinline@const@ and \lstinline@volatile@ qualifiers can only be sensibly used to qualify the return type of a function if the \lstinline@lvalue@ qualifier is also used.
    28702873\end{rationale}
    28712874
     
    28742877
    28752878\begin{rationale}
    2876 \lstinline$lvalue$ provides some of the functionality of {\CC}'s ``\lstinline$T&$'' ( reference to object of type \lstinline$T$) type.
     2879\lstinline@lvalue@ provides some of the functionality of {\CC}'s ``\lstinline@T&@'' ( reference to object of type \lstinline@T@) type.
    28772880Reference types have four uses in {\CC}.
    28782881\begin{itemize}
    28792882\item
    2880 They are necessary for user-defined operators that return lvalues, such as ``subscript'' and
    2881 ``dereference''.
    2882 
    2883 \item
    2884 A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline$with$ statement.
     2883They are necessary for user-defined operators that return lvalues, such as ``subscript'' and ``dereference''.
     2884
     2885\item
     2886A reference can be used to define an alias for a complicated lvalue expression, as a way of getting some of the functionality of the Pascal \lstinline@with@ statement.
    28852887The following {\CC} code gives an example.
    28862888\begin{lstlisting}
     
    28952897A reference parameter can be used to allow a function to modify an argument without forcing the caller to pass the address of the argument.
    28962898This is most useful for user-defined assignment operators.
    2897 In {\CC}, plain assignment is done by a function called ``\lstinline$operator=$'', and the two expressions
     2899In {\CC}, plain assignment is done by a function called ``\lstinline@operator=@'', and the two expressions
    28982900\begin{lstlisting}
    28992901a = b;
    29002902operator=( a, b );
    29012903\end{lstlisting} are equivalent.
    2902 If \lstinline$a$ and \lstinline$b$ are of type \lstinline$T$, then the first parameter of \lstinline$operator=$ must have type ``\lstinline$T&$''.
     2904If \lstinline@a@ and \lstinline@b@ are of type \lstinline@T@, then the first parameter of \lstinline@operator=@ must have type ``\lstinline@T&@''.
    29032905It cannot have type
    2904 \lstinline$T$, because then assignment couldn't alter the variable, and it can't have type
    2905 ``\lstinline$T *$'', because the assignment would have to be written ``\lstinline$&a = b;$''.
    2906 
    2907 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
    2908 ``\lstinline$operator=(&( a), b )$''.
    2909 Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline$&$''.
     2906\lstinline@T@, because then assignment couldn't alter the variable, and it can't have type
     2907``\lstinline@T *@'', because the assignment would have to be written ``\lstinline@&a = b;@''.
     2908
     2909In the case of user-defined operators, this could just as well be handled by using pointer types and by changing the rewrite rules so that ``\lstinline@a = b;@'' is equivalent to
     2910``\lstinline@operator=(&( a), b )@''.
     2911Reference parameters of ``normal'' functions are Bad Things, because they remove a useful property of C function calls: an argument can only be modified by a function if it is preceded by ``\lstinline@&@''.
    29102912
    29112913\item
    29122914References to \Index{const-qualified} types can be used instead of value parameters.  Given the
    2913 {\CC} function call ``\lstinline$fiddle( a_thing )$'', where the type of \lstinline$a_thing$ is
    2914 \lstinline$Thing$, the type of \lstinline$fiddle$ could be either of
     2915{\CC} function call ``\lstinline@fiddle( a_thing )@'', where the type of \lstinline@a_thing@ is
     2916\lstinline@Thing@, the type of \lstinline@fiddle@ could be either of
    29152917\begin{lstlisting}
    29162918void fiddle( Thing );
    29172919void fiddle( const Thing & );
    29182920\end{lstlisting}
    2919 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.
    2920 The reference form might be chosen for efficiency's sake if \lstinline$Thing$s are too large or their constructors or destructors are too expensive.
     2921If the second form is used, then constructors and destructors are not invoked to create a temporary variable at the call site ( and it is bad style for the caller to make any assumptions about such things), and within \lstinline@fiddle@ the parameter is subject to the usual problems caused by aliases.
     2922The reference form might be chosen for efficiency's sake if \lstinline@Thing@s are too large or their constructors or destructors are too expensive.
    29212923An implementation may switch between them without causing trouble for well-behaved clients.
    29222924This leaves the implementor to define ``too large'' and ``too expensive''.
     
    29262928void fiddle( const volatile Thing );
    29272929\end{lstlisting} with call-by-reference.
    2928 Since it knows all about the size of \lstinline$Thing$s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
     2930Since it knows all about the size of \lstinline@Thing@s and the parameter passing mechanism, it should be able to come up with a better definition of ``too large'', and may be able to make a good guess at ``too expensive''.
    29292931\end{itemize}
    29302932
     
    29462948\begin{syntax}
    29472949\lhs{spec-definition}
    2948 \rhs \lstinline$spec$ \nonterm{identifier}
    2949         \lstinline$($ \nonterm{type-parameter-list} \lstinline$)$
    2950         \lstinline${$ \nonterm{spec-declaration-list}\opt \lstinline$}$
     2950\rhs \lstinline@spec@ \nonterm{identifier}
     2951        \lstinline@(@ \nonterm{type-parameter-list} \lstinline@)@
     2952        \lstinline@{@ \nonterm{spec-declaration-list}\opt \lstinline@}@
    29512953\lhs{spec-declaration-list}
    2952 \rhs \nonterm{spec-declaration} \lstinline$;$
    2953 \rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline$;$
     2954\rhs \nonterm{spec-declaration} \lstinline@;@
     2955\rhs \nonterm{spec-declaration-list} \nonterm{spec-declaration} \lstinline@;@
    29542956\lhs{spec-declaration}
    29552957\rhs \nonterm{specifier-qualifier-list} \nonterm{declarator-list}
    29562958\lhs{declarator-list}
    29572959\rhs \nonterm{declarator}
    2958 \rhs \nonterm{declarator-list} \lstinline$,$ \nonterm{declarator}
     2960\rhs \nonterm{declarator-list} \lstinline@,@ \nonterm{declarator}
    29592961\end{syntax}
    29602962\begin{rationale}
     
    29782980\rhs \nonterm{assertion-list} \nonterm{assertion}
    29792981\lhs{assertion}
    2980 \rhs \lstinline$|$ \nonterm{identifier} \lstinline$($ \nonterm{type-name-list} \lstinline$)$
    2981 \rhs \lstinline$|$ \nonterm{spec-declaration}
     2982\rhs \lstinline@|@ \nonterm{identifier} \lstinline@(@ \nonterm{type-name-list} \lstinline@)@
     2983\rhs \lstinline@|@ \nonterm{spec-declaration}
    29822984\lhs{type-name-list}
    29832985\rhs \nonterm{type-name}
    2984 \rhs \nonterm{type-name-list} \lstinline$,$ \nonterm{type-name}
     2986\rhs \nonterm{type-name-list} \lstinline@,@ \nonterm{type-name}
    29852987\end{syntax}
    29862988
     
    29892991The \nonterm{type-name-list} shall contain one \nonterm{type-name} argument for each \nonterm{type-parameter} in that specification's \nonterm{spec-parameter-list}.
    29902992If the
    2991 \nonterm{type-parameter} uses type-class \lstinline$type$\use{type}, the argument shall be the type name of an \Index{object type};
    2992 if it uses \lstinline$dtype$, the argument shall be the type name of an object type or an \Index{incomplete type};
    2993 and if it uses \lstinline$ftype$, the argument shall be the type name of a \Index{function type}.
     2993\nonterm{type-parameter} uses type-class \lstinline@type@\use{type}, the argument shall be the type name of an \Index{object type};
     2994if it uses \lstinline@dtype@, the argument shall be the type name of an object type or an \Index{incomplete type};
     2995and if it uses \lstinline@ftype@, the argument shall be the type name of a \Index{function type}.
    29942996
    29952997\semantics
     
    30043006\examples
    30053007\begin{lstlisting}
    3006 forall( otype T | T ?*?( T, T ))@\use{?*?}@
    3007 T square( T val ) {@\impl{square}@
     3008forall( otype T | T ?*?( T, T ))§\use{?*?}§
     3009T square( T val ) {§\impl{square}§
    30083010        return val + val;
    30093011}
    3010 trait summable( otype T ) {@\impl{summable}@
    3011         T ?+=?( T *, T );@\use{?+=?}@
    3012         const T 0;@\use{0}@
     3012trait summable( otype T ) {§\impl{summable}§
     3013        T ?+=?( T *, T );§\use{?+=?}§
     3014        const T 0;§\use{0}§
    30133015};
    3014 trait list_of( otype List, otype Element ) {@\impl{list_of}@
     3016trait list_of( otype List, otype Element ) {§\impl{list_of}§
    30153017        Element car( List );
    30163018        List cdr( List );
     
    30213023trait sum_list( otype List, otype Element | summable( Element ) | list_of( List, Element ) ) {};
    30223024\end{lstlisting}
    3023 \lstinline$sum_list$ contains seven declarations, which describe a list whose elements can be added up.
    3024 The assertion ``\lstinline$|sum_list( i_list, int )$''\use{sum_list} produces the assertion parameters
     3025\lstinline@sum_list@ contains seven declarations, which describe a list whose elements can be added up.
     3026The assertion ``\lstinline@|sum_list( i_list, int )@''\use{sum_list} produces the assertion parameters
    30253027\begin{lstlisting}
    30263028int ?+=?( int *, int );
     
    30393041\lhs{type-parameter-list}
    30403042\rhs \nonterm{type-parameter}
    3041 \rhs \nonterm{type-parameter-list} \lstinline$,$ \nonterm{type-parameter}
     3043\rhs \nonterm{type-parameter-list} \lstinline@,@ \nonterm{type-parameter}
    30423044\lhs{type-parameter}
    30433045\rhs \nonterm{type-class} \nonterm{identifier} \nonterm{assertion-list}\opt
    30443046\lhs{type-class}
    3045 \rhs \lstinline$type$
    3046 \rhs \lstinline$dtype$
    3047 \rhs \lstinline$ftype$
     3047\rhs \lstinline@type@
     3048\rhs \lstinline@dtype@
     3049\rhs \lstinline@ftype@
    30483050\lhs{type-declaration}
    3049 \rhs \nonterm{storage-class-specifier}\opt \lstinline$type$ \nonterm{type-declarator-list} \verb|;|
     3051\rhs \nonterm{storage-class-specifier}\opt \lstinline@type@ \nonterm{type-declarator-list} \verb|;|
    30503052\lhs{type-declarator-list}
    30513053\rhs \nonterm{type-declarator}
    3052 \rhs \nonterm{type-declarator-list} \lstinline$,$ \nonterm{type-declarator}
     3054\rhs \nonterm{type-declarator-list} \lstinline@,@ \nonterm{type-declarator}
    30533055\lhs{type-declarator}
    3054 \rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline$=$ \nonterm{type-name}
     3056\rhs \nonterm{identifier} \nonterm{assertion-list}\opt \lstinline@=@ \nonterm{type-name}
    30553057\rhs \nonterm{identifier} \nonterm{assertion-list}\opt
    30563058\end{syntax}
     
    30633065
    30643066An identifier declared by a \nonterm{type-parameter} has \Index{no linkage}.
    3065 Identifiers declared with type-class \lstinline$type$\use{type} are \Index{object type}s;
     3067Identifiers declared with type-class \lstinline@type@\use{type} are \Index{object type}s;
    30663068those declared with type-class
    3067 \lstinline$dtype$\use{dtype} are \Index{incomplete type}s;
     3069\lstinline@dtype@\use{dtype} are \Index{incomplete type}s;
    30683070and those declared with type-class
    3069 \lstinline$ftype$\use{ftype} are \Index{function type}s.
     3071\lstinline@ftype@\use{ftype} are \Index{function type}s.
    30703072The 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}.
    30713073
     
    30753077Within 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.
    30763078
    3077 A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline$static$\use{static} defines an \Index{incomplete type}.
     3079A type declaration without an \Index{initializer} and without a \Index{storage-class specifier} or with storage-class specifier \lstinline@static@\use{static} defines an \Index{incomplete type}.
    30783080If a
    30793081\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).
     
    30953097
    30963098A type declaration without an initializer and with \Index{storage-class specifier}
    3097 \lstinline$extern$\use{extern} is an \define{opaque type declaration}.
     3099\lstinline@extern@\use{extern} is an \define{opaque type declaration}.
    30983100Opaque types are
    30993101\Index{object type}s.
     
    31103112\end{rationale}
    31113113
    3112 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$.
    3113 An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline$type$ and \lstinline$dtype$.
     3114An \Index{incomplete type} which is not a qualified version\index{qualified type} of a type is a value of \Index{type-class} \lstinline@dtype@.
     3115An object type\index{object types} which is not a qualified version of a type is a value of type-classes \lstinline@type@ and \lstinline@dtype@.
    31143116A
    3115 \Index{function type} is a value of type-class \lstinline$ftype$.
     3117\Index{function type} is a value of type-class \lstinline@ftype@.
    31163118\begin{rationale}
    31173119Syntactically, a type value is a \nonterm{type-name}, which is a declaration for an object which omits the identifier being declared.
     
    31233125Type qualifiers are a weak point of C's type system.
    31243126Consider the standard library function
    3125 \lstinline$strchr()$ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
    3126 \begin{lstlisting}
    3127 char *strchr( const char *s, int c ) {@\impl{strchr}@
     3127\lstinline@strchr()@ which, given a string and a character, returns a pointer to the first occurrence of the character in the string.
     3128\begin{lstlisting}
     3129char *strchr( const char *s, int c ) {§\impl{strchr}§
    31283130        char real_c = c; // done because c was declared as int.
    31293131        for ( ; *s != real_c; s++ )
     
    31323134}
    31333135\end{lstlisting}
    3134 The parameter \lstinline$s$ must be \lstinline$const char *$, because \lstinline$strchr()$ might be used to search a constant string, but the return type must be \lstinline$char *$, because the result might be used to modify a non-constant string.
     3136The parameter \lstinline@s@ must be \lstinline@const char *@, because \lstinline@strchr()@ might be used to search a constant string, but the return type must be \lstinline@char *@, because the result might be used to modify a non-constant string.
    31353137Hence the body must perform a cast, and ( even worse)
    3136 \lstinline$strchr()$ provides a type-safe way to attempt to modify constant strings.
    3137 What is needed is some way to say that \lstinline$s$'s type might contain qualifiers, and the result type has exactly the same qualifiers.
     3138\lstinline@strchr()@ provides a type-safe way to attempt to modify constant strings.
     3139What is needed is some way to say that \lstinline@s@'s type might contain qualifiers, and the result type has exactly the same qualifiers.
    31383140Polymorphic functions do not provide a fix for this deficiency\index{deficiencies!pointers to qualified types}, because type qualifiers are not part of type values.
    3139 Instead, overloading can be used to define \lstinline$strchr()$ for each combination of qualifiers.
     3141Instead, overloading can be used to define \lstinline@strchr()@ for each combination of qualifiers.
    31403142\end{rationale}
    31413143
     
    31623164\end{lstlisting}
    31633165Without this restriction, \CFA might require ``module initialization'' code ( since
    3164 \lstinline$Rational$ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline$Huge$ and the translation that declares \lstinline$Rational$.
     3166\lstinline@Rational@ has external linkage, it must be created before any other translation unit instantiates it), and would force an ordering on the initialization of the translation unit that defines \lstinline@Huge@ and the translation that declares \lstinline@Rational@.
    31653167
    31663168A 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.
     
    31793181\nonterm{struct-declaration}, type declarations can not be structure members.
    31803182The form of
    3181 \nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline$type$.
     3183\nonterm{type-declaration} forbids arrays of, pointers to, and functions returning \lstinline@type@.
    31823184Hence the syntax of \nonterm{type-specifier} does not have to be extended to allow type-valued expressions.
    31833185It also side-steps the problem of type-valued expressions producing different values in different declarations.
     
    31943196#include <stdlib.h>
    31953197T * new( otype T ) { return ( T * )malloc( sizeof( T) ); };
    3196 @\ldots@ int * ip = new( int );
    3197 \end{lstlisting}
    3198 This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline$T$'' in the function body refers to the parameter, but the ``\lstinline$T$'' in the return type refers to the meaning of \lstinline$T$ in the scope that contains \lstinline$new$;
     3198§\ldots§ int * ip = new( int );
     3199\end{lstlisting}
     3200This looks sensible, but \CFA's declaration-before-use rules mean that ``\lstinline@T@'' in the function body refers to the parameter, but the ``\lstinline@T@'' in the return type refers to the meaning of \lstinline@T@ in the scope that contains \lstinline@new@;
    31993201it could be undefined, or a type name, or a function or variable name.
    32003202Nothing good can result from such a situation.
     
    32133215f2( v2 );
    32143216\end{lstlisting}
    3215 \lstinline$V1$ is passed by value, so \lstinline$f1()$'s assignment to \lstinline$a[0]$ does not modify v1.  \lstinline$V2$ is converted to a pointer, so \lstinline$f2()$ modifies \lstinline$v2[0]$.
     3217\lstinline@V1@ is passed by value, so \lstinline@f1()@'s assignment to \lstinline@a[0]@ does not modify v1.  \lstinline@V2@ is converted to a pointer, so \lstinline@f2()@ modifies \lstinline@v2[0]@.
    32163218
    32173219A translation unit containing the declarations
    32183220\begin{lstlisting}
    3219 extern type Complex;@\use{Complex}@ // opaque type declaration
    3220 extern float abs( Complex );@\use{abs}@
    3221 \end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline$abs$.
    3222 Some other translation unit must implement \lstinline$Complex$ and \lstinline$abs$.
     3221extern type Complex;§\use{Complex}§ // opaque type declaration
     3222extern float abs( Complex );§\use{abs}§
     3223\end{lstlisting} can contain declarations of complex numbers, which can be passed to \lstinline@abs@.
     3224Some other translation unit must implement \lstinline@Complex@ and \lstinline@abs@.
    32233225That unit might contain the declarations
    32243226\begin{lstlisting}
    3225 otype Complex = struct { float re, im; };@\impl{Complex}@
    3226 Complex cplx_i = { 0.0, 1.0 };@\impl{cplx_i}@
    3227 float abs( Complex c ) {@\impl{abs( Complex )}@
     3227otype Complex = struct { float re, im; };§\impl{Complex}§
     3228Complex cplx_i = { 0.0, 1.0 };§\impl{cplx_i}§
     3229float abs( Complex c ) {§\impl{abs( Complex )}§
    32283230        return sqrt( c.re * c.re + c.im * c.im );
    32293231}
    32303232\end{lstlisting}
    3231 Note that \lstinline$c$ is implicitly converted to a \lstinline$struct$ so that its components can be retrieved.
    3232 
    3233 \begin{lstlisting}
    3234 otype Time_of_day = int;@\impl{Time_of_day}@ // seconds since midnight.
    3235 Time_of_day ?+?( Time_of_day t1, int seconds ) {@\impl{?+?}@
     3233Note that \lstinline@c@ is implicitly converted to a \lstinline@struct@ so that its components can be retrieved.
     3234
     3235\begin{lstlisting}
     3236otype Time_of_day = int;§\impl{Time_of_day}§ // seconds since midnight.
     3237Time_of_day ?+?( Time_of_day t1, int seconds ) {§\impl{?+?}§
    32363238        return (( int)t1 + seconds ) % 86400;
    32373239}
    32383240\end{lstlisting}
    3239 \lstinline$t1$ must be cast to its implementation type to prevent infinite recursion.
     3241\lstinline@t1@ must be cast to its implementation type to prevent infinite recursion.
    32403242
    32413243\begin{rationale}
    32423244Within the scope of a type definition, an instance of the type can be viewed as having that type or as having the implementation type.
    3243 In the \lstinline$Time_of_day$ example, the difference is important.
     3245In the \lstinline@Time_of_day@ example, the difference is important.
    32443246Different languages have treated the distinction between the abstraction and the implementation in different ways.
    32453247\begin{itemize}
    32463248\item
    32473249Inside a Clu cluster \cite{CLU}, the declaration of an instance states which view applies.
    3248 Two primitives called \lstinline$up$ and \lstinline$down$ can be used to convert between the views.
     3250Two primitives called \lstinline@up@ and \lstinline@down@ can be used to convert between the views.
    32493251\item
    32503252The Simula class \cite{SIMULA87} is essentially a record type.
    32513253Since 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.
    32523254In {\CC}
    3253 \cite{C++}, operations on class instances include assignment and ``\lstinline$&$'', which can be overloaded.
     3255\cite{C++}, operations on class instances include assignment and ``\lstinline@&@'', which can be overloaded.
    32543256A ``scope resolution'' operator can be used inside the class to specify whether the abstract or implementation version of the operation should be used.
    32553257\item
     
    32643266In this case, explicit conversions between the derived type and the old type can be used.
    32653267\end{itemize}
    3266 \CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline$up$ and \lstinline$down$.
     3268\CFA's rules are like Clu's, except that implicit conversions and conversion costs allow it to do away with most uses of \lstinline@up@ and \lstinline@down@.
    32673269\end{rationale}
    32683270
     
    32703272\subsubsection{Default functions and objects}
    32713273
    3272 A declaration\index{type declaration} of a type identifier \lstinline$T$ with type-class
    3273 \lstinline$type$ implicitly declares a \define{default assignment} function
    3274 \lstinline$T ?=?( T *, T )$\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3274A declaration\index{type declaration} of a type identifier \lstinline@T@ with type-class
     3275\lstinline@type@ implicitly declares a \define{default assignment} function
     3276\lstinline@T ?=?( T *, T )@\use{?=?}, with the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
    32753277\begin{rationale}
    32763278Assignment 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).
    32773279Without this rule, nearly every inferred type parameter would need an accompanying assignment assertion parameter.
    32783280If a type parameter should not have an assignment operation,
    3279 \lstinline$dtype$ should be used.
     3281\lstinline@dtype@ should be used.
    32803282If 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.
    32813283\end{rationale}
    32823284
    3283 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.
    3284 A definition\index{type definition} of a type identifier \lstinline$T$ with implementation type \lstinline$I$ and an assertion list implicitly defines \define{default function}s and
     3285A definition\index{type definition} of a type identifier \lstinline@T@ with \Index{implementation type} \lstinline@I@ and type-class \lstinline@type@ implicitly defines a default assignment function.
     3286A definition\index{type definition} of a type identifier \lstinline@T@ with implementation type \lstinline@I@ and an assertion list implicitly defines \define{default function}s and
    32853287\define{default object}s as declared by the assertion declarations.
    3286 The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline$T$.
     3288The default objects and functions have the same \Index{scope} and \Index{linkage} as the identifier \lstinline@T@.
    32873289Their values are determined as follows:
    32883290\begin{itemize}
    32893291\item
    3290 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.
    3291 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default object.
     3292If at the definition of \lstinline@T@ there is visible a declaration of an object with the same name as the default object, and if the type of that object with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default object, then the default object is initialized with that object.
     3293Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default object.
    32923294
    32933295\item
    3294 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.
    3295 
    3296 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.
    3297 
    3298 Otherwise the scope of the declaration of \lstinline$T$ must contain a definition of the default function.
     3296If at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and if the type of that function with all occurrence of \lstinline@I@ replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the converted result.
     3297
     3298Otherwise, if \lstinline@I@ contains exactly one anonymous member\index{anonymous member} such that at the definition of \lstinline@T@ there is visible a declaration of a function with the same name as the default function, and the type of that function with all occurrences of the anonymous member's type in its parameter list replaced by \lstinline@T@ is compatible with the type of the default function, then the default function calls that function after converting its arguments and returns the result.
     3299
     3300Otherwise the scope of the declaration of \lstinline@T@ must contain a definition of the default function.
    32993301\end{itemize}
    33003302\begin{rationale}
     
    33023304\end{rationale}
    33033305
    3304 A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline$T$ replaces the default function or object.
     3306A function or object with the same type and name as a default function or object that is declared within the scope of the definition of \lstinline@T@ replaces the default function or object.
    33053307
    33063308\examples
     
    33123314Pair b = { 1, 1 };
    33133315\end{lstlisting}
    3314 The definition of \lstinline$Pair$ implicitly defines two objects \lstinline$a$ and \lstinline$b$.
    3315 \lstinline$Pair a$ inherits its value from the \lstinline$struct impl a$.
     3316The definition of \lstinline@Pair@ implicitly defines two objects \lstinline@a@ and \lstinline@b@.
     3317\lstinline@Pair a@ inherits its value from the \lstinline@struct impl a@.
    33163318The definition of
    3317 \lstinline$Pair b$ is compulsory because there is no \lstinline$struct impl b$ to construct a value from.
     3319\lstinline@Pair b@ is compulsory because there is no \lstinline@struct impl b@ to construct a value from.
    33183320\begin{lstlisting}
    33193321trait ss( otype T ) {
     
    33213323        void munge( T * );
    33223324}
    3323 otype Whatsit | ss( Whatsit );@\use{Whatsit}@
    3324 otype Doodad | ss( Doodad ) = struct doodad {@\use{Doodad}@
     3325otype Whatsit | ss( Whatsit );§\use{Whatsit}§
     3326otype Doodad | ss( Doodad ) = struct doodad {§\use{Doodad}§
    33253327        Whatsit; // anonymous member
    33263328        int extra;
     
    33283330Doodad clone( Doodad ) { ... }
    33293331\end{lstlisting}
    3330 The definition of \lstinline$Doodad$ implicitly defines three functions:
     3332The definition of \lstinline@Doodad@ implicitly defines three functions:
    33313333\begin{lstlisting}
    33323334Doodad ?=?( Doodad *, Doodad );
     
    33343336void munge( Doodad * );
    33353337\end{lstlisting}
    3336 The assignment function inherits \lstinline$struct doodad$'s assignment function because the types match when \lstinline$struct doodad$ is replaced by \lstinline$Doodad$ throughout.
    3337 \lstinline$munge()$ inherits \lstinline$Whatsit$'s \lstinline$munge()$ because the types match when
    3338 \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
    3339 \lstinline$Doodad$'s \lstinline$clone()$'s type.
     3338The assignment function inherits \lstinline@struct doodad@'s assignment function because the types match when \lstinline@struct doodad@ is replaced by \lstinline@Doodad@ throughout.
     3339\lstinline@munge()@ inherits \lstinline@Whatsit@'s \lstinline@munge()@ because the types match when
     3340\lstinline@Whatsit@ is replaced by \lstinline@Doodad@ in the parameter list. \lstinline@clone()@ does \emph{not} inherit \lstinline@Whatsit@'s \lstinline@clone()@: replacement in the parameter list yields ``\lstinline@Whatsit clone( Doodad )@'', which is not compatible with
     3341\lstinline@Doodad@'s \lstinline@clone()@'s type.
    33403342Hence the definition of
    3341 ``\lstinline$Doodad clone( Doodad )$'' is necessary.
     3343``\lstinline@Doodad clone( Doodad )@'' is necessary.
    33423344
    33433345Default functions and objects are subject to the normal scope rules.
    33443346\begin{lstlisting}
    3345 otype T = @\ldots@;
    3346 T a_T = @\ldots@;               // Default assignment used.
     3347otype T = §\ldots§;
     3348T a_T = §\ldots§;               // Default assignment used.
    33473349T ?=?( T *, T );
    3348 T a_T = @\ldots@;               // Programmer-defined assignment called.
     3350T a_T = §\ldots§;               // Programmer-defined assignment called.
    33493351\end{lstlisting}
    33503352\begin{rationale}
     
    33793381\begin{syntax}
    33803382\oldlhs{labeled-statement}
    3381 \rhs \lstinline$case$ \nonterm{case-value-list} : \nonterm{statement}
     3383\rhs \lstinline@case@ \nonterm{case-value-list} : \nonterm{statement}
    33823384\lhs{case-value-list}
    33833385\rhs \nonterm{case-value}
    3384 \rhs \nonterm{case-value-list} \lstinline$,$ \nonterm{case-value}
     3386\rhs \nonterm{case-value-list} \lstinline@,@ \nonterm{case-value}
    33853387\lhs{case-value}
    33863388\rhs \nonterm{constant-expression}
    33873389\rhs \nonterm{subrange}
    33883390\lhs{subrange}
    3389 \rhs \nonterm{constant-expression} \lstinline$~$ \nonterm{constant-expression}
     3391\rhs \nonterm{constant-expression} \lstinline@~@ \nonterm{constant-expression}
    33903392\end{syntax}
    33913393
     
    34003402case 1~4, 9~14, 27~32:
    34013403\end{lstlisting}
    3402 The \lstinline$case$ and \lstinline$default$ clauses are restricted within the \lstinline$switch$ and \lstinline$choose$ statements, precluding Duff's device.
     3404The \lstinline@case@ and \lstinline@default@ clauses are restricted within the \lstinline@switch@ and \lstinline@choose@ statements, precluding Duff's device.
    34033405
    34043406
    34053407\subsection{Expression and null statements}
    34063408
    3407 The expression in an expression statement is treated as being cast to \lstinline$void$.
     3409The expression in an expression statement is treated as being cast to \lstinline@void@.
    34083410
    34093411
     
    34123414\begin{syntax}
    34133415\oldlhs{selection-statement}
    3414 \rhs \lstinline$choose$ \lstinline$($ \nonterm{expression} \lstinline$)$ \nonterm{statement}
     3416\rhs \lstinline@choose@ \lstinline@(@ \nonterm{expression} \lstinline@)@ \nonterm{statement}
    34153417\end{syntax}
    34163418
    3417 The controlling expression \lstinline$E$ in the \lstinline$switch$ and \lstinline$choose$ statement:
     3419The controlling expression \lstinline@E@ in the \lstinline@switch@ and \lstinline@choose@ statement:
    34183420\begin{lstlisting}
    34193421switch ( E ) ...
     
    34213423\end{lstlisting} may have more than one interpretation, but it shall have only one interpretation with an integral type.
    34223424An \Index{integer promotion} is performed on the expression if necessary.
    3423 The constant expressions in \lstinline$case$ statements with the switch are converted to the promoted type.
     3425The constant expressions in \lstinline@case@ statements with the switch are converted to the promoted type.
    34243426
    34253427
    34263428\setcounter{subsubsection}{3}
    3427 \subsubsection{The \lstinline$choose$ statement}
    3428 
    3429 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.
    3430 The \lstinline$fallthru$ statement is used to fall through to the next \lstinline$case$ or \lstinline$default$ labeled statement.
     3429\subsubsection[The choose statement]{The \lstinline@choose@ statement}
     3430
     3431The \lstinline@choose@ statement is the same as the \lstinline@switch@ statement except control transfers to the end of the \lstinline@choose@ statement at a \lstinline@case@ or \lstinline@default@ labeled statement.
     3432The \lstinline@fallthru@ statement is used to fall through to the next \lstinline@case@ or \lstinline@default@ labeled statement.
    34313433The following have identical meaning:
    34323434\begin{flushleft}
     
    34533455\end{tabular}
    34543456\end{flushleft}
    3455 The \lstinline$choose$ statement addresses the problem of accidental fall-through associated with the \lstinline$switch$ statement.
     3457The \lstinline@choose@ statement addresses the problem of accidental fall-through associated with the \lstinline@switch@ statement.
    34563458
    34573459
    34583460\subsection{Iteration statements}
    34593461
    3460 The controlling expression \lstinline$E$ in the loops
     3462The controlling expression \lstinline@E@ in the loops
    34613463\begin{lstlisting}
    34623464if ( E ) ...
    34633465while ( E ) ...
    34643466do ... while ( E );
    3465 \end{lstlisting} is treated as ``\lstinline$( int )((E)!=0)$''.
     3467\end{lstlisting} is treated as ``\lstinline@( int )((E)!=0)@''.
    34663468
    34673469The statement
    34683470\begin{lstlisting}
    3469 for ( a; b; c ) @\ldots@
     3471for ( a; b; c ) §\ldots§
    34703472\end{lstlisting} is treated as
    34713473\begin{lstlisting}
     
    34783480\begin{syntax}
    34793481\oldlhs{jump-statement}
    3480 \rhs \lstinline$continue$ \nonterm{identifier}\opt
    3481 \rhs \lstinline$break$ \nonterm{identifier}\opt
     3482\rhs \lstinline@continue@ \nonterm{identifier}\opt
     3483\rhs \lstinline@break@ \nonterm{identifier}\opt
    34823484\rhs \ldots
    3483 \rhs \lstinline$throw$ \nonterm{assignment-expression}\opt
    3484 \rhs \lstinline$throwResume$ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
    3485 \lhs{at-expression} \lstinline$_At$ \nonterm{assignment-expression}
     3485\rhs \lstinline@throw@ \nonterm{assignment-expression}\opt
     3486\rhs \lstinline@throwResume@ \nonterm{assignment-expression}\opt \nonterm{at-expression}\opt
     3487\lhs{at-expression} \lstinline@_At@ \nonterm{assignment-expression}
    34863488\end{syntax}
    34873489
    3488 Labeled \lstinline$continue$ and \lstinline$break$ allow useful but restricted control-flow that reduces the need for the \lstinline$goto$ statement for exiting multiple nested control-structures.
     3490Labeled \lstinline@continue@ and \lstinline@break@ allow useful but restricted control-flow that reduces the need for the \lstinline@goto@ statement for exiting multiple nested control-structures.
    34893491\begin{lstlisting}
    34903492L1: {                                                   // compound
     
    35133515
    35143516\setcounter{subsubsection}{1}
    3515 \subsubsection{The \lstinline$continue$ statement}
    3516 
    3517 The identifier in a \lstinline$continue$ statement shall name a label located on an enclosing iteration statement.
    3518 
    3519 
    3520 \subsubsection{The \lstinline$break$ statement}
    3521 
    3522 The identifier in a \lstinline$break$ statement shall name a label located on an enclosing compound, selection or iteration statement.
    3523 
    3524 
    3525 \subsubsection{The \lstinline$return$ statement}
    3526 
    3527 An expression in a \lstinline$return$ statement is treated as being cast to the result type of the function.
    3528 
    3529 
    3530 \subsubsection{The \lstinline$throw$ statement}
     3517\subsubsection[The continue statement]{The \lstinline@continue@ statement}
     3518
     3519The identifier in a \lstinline@continue@ statement shall name a label located on an enclosing iteration statement.
     3520
     3521
     3522\subsubsection[The break statement]{The \lstinline@break@ statement}
     3523
     3524The identifier in a \lstinline@break@ statement shall name a label located on an enclosing compound, selection or iteration statement.
     3525
     3526
     3527\subsubsection[The return statement]{The \lstinline@return@ statement}
     3528
     3529An expression in a \lstinline@return@ statement is treated as being cast to the result type of the function.
     3530
     3531
     3532\subsubsection[The throw statement]{The \lstinline@throw@ statement}
    35313533
    35323534When an exception is raised, \Index{propagation} directs control from a raise in the source execution to a handler in the faulting execution.
    35333535
    35343536
    3535 \subsubsection{The \lstinline$throwResume$ statement}
     3537\subsubsection[The throwResume statement]{The \lstinline@throwResume@ statement}
    35363538
    35373539
     
    35403542\begin{syntax}
    35413543\lhs{exception-statement}
    3542 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list}
    3543 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{finally-clause}
    3544 \rhs \lstinline$try$ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
     3544\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list}
     3545\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{finally-clause}
     3546\rhs \lstinline@try@ \nonterm{compound-statement} \nonterm{handler-list} \nonterm{finally-clause}
    35453547\lhs{handler-list}
    35463548\rhs \nonterm{handler-clause}
    3547 \rhs \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3548 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3549 \rhs \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
    3550 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \ldots \lstinline$)$ \nonterm{compound-statement}
     3549\rhs \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3550\rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3551\rhs \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
     3552\rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \ldots \lstinline@)@ \nonterm{compound-statement}
    35513553\lhs{handler-clause}
    3552 \rhs \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3553 \rhs \nonterm{handler-clause} \lstinline$catch$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3554 \rhs \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
    3555 \rhs \nonterm{handler-clause} \lstinline$catchResume$ \lstinline$($ \nonterm{exception-declaration} \lstinline$)$ \nonterm{compound-statement}
     3554\rhs \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3555\rhs \nonterm{handler-clause} \lstinline@catch@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3556\rhs \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
     3557\rhs \nonterm{handler-clause} \lstinline@catchResume@ \lstinline@(@ \nonterm{exception-declaration} \lstinline@)@ \nonterm{compound-statement}
    35563558\lhs{finally-clause}
    3557 \rhs \lstinline$finally$ \nonterm{compound-statement}
     3559\rhs \lstinline@finally@ \nonterm{compound-statement}
    35583560\lhs{exception-declaration}
    35593561\rhs \nonterm{type-specifier}
     
    35633565\rhs \nonterm{new-abstract-declarator-tuple}
    35643566\lhs{asynchronous-statement}
    3565 \rhs \lstinline$enable$ \nonterm{identifier-list} \nonterm{compound-statement}
    3566 \rhs \lstinline$disable$ \nonterm{identifier-list} \nonterm{compound-statement}
     3567\rhs \lstinline@enable@ \nonterm{identifier-list} \nonterm{compound-statement}
     3568\rhs \lstinline@disable@ \nonterm{identifier-list} \nonterm{compound-statement}
    35673569\end{syntax}
    35683570
     
    35703572
    35713573
    3572 \subsubsection{The \lstinline$try$ statement}
    3573 
    3574 The \lstinline$try$ statement is a block with associated handlers, called a \Index{guarded block};
     3574\subsubsection[The try statement]{The \lstinline@try@ statement}
     3575
     3576The \lstinline@try@ statement is a block with associated handlers, called a \Index{guarded block};
    35753577all other blocks are \Index{unguarded block}s.
    3576 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.
    3577 
    3578 
    3579 \subsubsection{The \lstinline$enable$/\lstinline$disable$ statements}
    3580 
    3581 The \lstinline$enable$/\lstinline$disable$ statements toggle delivery of \Index{asynchronous exception}s.
     3578A \lstinline@goto@, \lstinline@break@, \lstinline@return@, or \lstinline@continue@ statement can be used to transfer control out of a try block or handler, but not into one.
     3579
     3580
     3581\subsubsection[The enable/disable statements]{The \lstinline@enable@/\lstinline@disable@ statements}
     3582
     3583The \lstinline@enable@/\lstinline@disable@ statements toggle delivery of \Index{asynchronous exception}s.
    35823584
    35833585
     
    35893591\subsection{Predefined macro names}
    35903592
    3591 The implementation shall define the macro names \lstinline$__LINE__$, \lstinline$__FILE__$,
    3592 \lstinline$__DATE__$, and \lstinline$__TIME__$, as in the {\c11} standard.
    3593 It shall not define the macro name \lstinline$__STDC__$.
    3594 
    3595 In addition, the implementation shall define the macro name \lstinline$__CFORALL__$ to be the decimal constant 1.
     3593The implementation shall define the macro names \lstinline@__LINE__@, \lstinline@__FILE__@,
     3594\lstinline@__DATE__@, and \lstinline@__TIME__@, as in the {\c11} standard.
     3595It shall not define the macro name \lstinline@__STDC__@.
     3596
     3597In addition, the implementation shall define the macro name \lstinline@__CFORALL__@ to be the decimal constant 1.
    35963598
    35973599
     
    36103612The pointer, integral, and floating-point types are all \define{scalar types}.
    36113613All of these types can be logically negated and compared.
    3612 The assertion ``\lstinline$scalar( Complex )$'' should be read as ``type \lstinline$Complex$ is scalar''.
    3613 \begin{lstlisting}
    3614 trait scalar( otype T ) {@\impl{scalar}@
     3614The assertion ``\lstinline@scalar( Complex )@'' should be read as ``type \lstinline@Complex@ is scalar''.
     3615\begin{lstlisting}
     3616trait scalar( otype T ) {§\impl{scalar}§
    36153617        int !?( T );
    36163618        int ?<?( T, T ), ?<=?( T, T ), ?==?( T, T ), ?>=?( T, T ), ?>?( T, T ), ?!=?( T, T );
     
    36223624This is equivalent to inheritance of specifications.
    36233625\begin{lstlisting}
    3624 trait arithmetic( otype T | scalar( T ) ) {@\impl{arithmetic}@@\use{scalar}@
     3626trait arithmetic( otype T | scalar( T ) ) {§\impl{arithmetic}§§\use{scalar}§
    36253627        T +?( T ), -?( T );
    36263628        T ?*?( T, T ), ?/?( T, T ), ?+?( T, T ), ?-?( T, T );
     
    36283630\end{lstlisting}
    36293631
    3630 The various flavors of \lstinline$char$ and \lstinline$int$ and the enumerated types make up the
     3632The various flavors of \lstinline@char@ and \lstinline@int@ and the enumerated types make up the
    36313633\define{integral types}.
    36323634\begin{lstlisting}
    3633 trait integral( otype T | arithmetic( T ) ) {@\impl{integral}@@\use{arithmetic}@
     3635trait integral( otype T | arithmetic( T ) ) {§\impl{integral}§§\use{arithmetic}§
    36343636        T ~?( T );
    36353637        T ?&?( T, T ), ?|?( T, T ), ?^?( T, T );
     
    36453647The only operation that can be applied to all modifiable lvalues is simple assignment.
    36463648\begin{lstlisting}
    3647 trait m_lvalue( otype T ) {@\impl{m_lvalue}@
     3649trait m_lvalue( otype T ) {§\impl{m_lvalue}§
    36483650        T ?=?( T *, T );
    36493651};
     
    36553657Scalars can also be incremented and decremented.
    36563658\begin{lstlisting}
    3657 trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {@\impl{m_l_scalar}@
    3658         T ?++( T * ), ?--( T * );@\use{scalar}@@\use{m_lvalue}@
     3659trait m_l_scalar( otype T | scalar( T ) | m_lvalue( T ) ) {§\impl{m_l_scalar}§
     3660        T ?++( T * ), ?--( T * );§\use{scalar}§§\use{m_lvalue}§
    36593661        T ++?( T * ), --?( T * );
    36603662};
     
    36623664
    36633665Modifiable arithmetic lvalues are both modifiable scalar lvalues and arithmetic.
    3664 Note that this results in the ``inheritance'' of \lstinline$scalar$ along both paths.
    3665 \begin{lstlisting}
    3666 trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {@\impl{m_l_arithmetic}@
    3667         T ?/=?( T *, T ), ?*=?( T *, T );@\use{m_l_scalar}@@\use{arithmetic}@
     3666Note that this results in the ``inheritance'' of \lstinline@scalar@ along both paths.
     3667\begin{lstlisting}
     3668trait m_l_arithmetic( otype T | m_l_scalar( T ) | arithmetic( T ) ) {§\impl{m_l_arithmetic}§
     3669        T ?/=?( T *, T ), ?*=?( T *, T );§\use{m_l_scalar}§§\use{arithmetic}§
    36683670        T ?+=?( T *, T ), ?-=?( T *, T );
    36693671};
    3670 trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {@\impl{m_l_integral}@
    3671         T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );@\use{m_l_arithmetic}@
    3672         T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );@\use{integral}@
     3672trait m_l_integral( otype T | m_l_arithmetic( T ) | integral( T ) ) {§\impl{m_l_integral}§
     3673        T ?&=?( T *, T ), ?|=?( T *, T ), ?^=?( T *, T );§\use{m_l_arithmetic}§
     3674        T ?%=?( T *, T ), ?<<=?( T *, T ), ?>>=?( T *, T );§\use{integral}§
    36733675};
    36743676\end{lstlisting}
     
    36783680
    36793681Array 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
    3680 ``\lstinline$a[i]$'' is equivalent to the dereferencing expression ``\lstinline$(*( a+( i )))$''.
    3681 Technically, pointer arithmetic and pointer comparisons other than ``\lstinline$==$'' and
    3682 ``\lstinline$!=$'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
     3682``\lstinline@a[i]@'' is equivalent to the dereferencing expression ``\lstinline@(*( a+( i )))@''.
     3683Technically, pointer arithmetic and pointer comparisons other than ``\lstinline@==@'' and
     3684``\lstinline@!=@'' are only defined for pointers to array elements, but the type system does not enforce those restrictions.
    36833685Consequently, there is no need for a separate ``array type'' specification.
    36843686
    36853687Pointer types are scalar types.
    3686 Like other scalar types, they have ``\lstinline$+$'' and
    3687 ``\lstinline$-$'' operators, but the types do not match the types of the operations in
    3688 \lstinline$arithmetic$, so these operators cannot be consolidated in \lstinline$scalar$.
    3689 \begin{lstlisting}
    3690 trait pointer( type P | scalar( P ) ) {@\impl{pointer}@@\use{scalar}@
     3688Like other scalar types, they have ``\lstinline@+@'' and
     3689``\lstinline@-@'' operators, but the types do not match the types of the operations in
     3690\lstinline@arithmetic@, so these operators cannot be consolidated in \lstinline@scalar@.
     3691\begin{lstlisting}
     3692trait pointer( type P | scalar( P ) ) {§\impl{pointer}§§\use{scalar}§
    36913693        P ?+?( P, long int ), ?+?( long int, P ), ?-?( P, long int );
    36923694        ptrdiff_t ?-?( P, P );
    36933695};
    3694 trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {@\impl{m_l_pointer}@
     3696trait m_l_pointer( type P | pointer( P ) | m_l_scalar( P ) ) {§\impl{m_l_pointer}§
    36953697        P ?+=?( P *, long int ), ?-=?( P *, long int );
    36963698        P ?=?( P *, void * );
     
    37013703Specifications 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.
    37023704Different specifications are needed for each set of \Index{type qualifier}s, because qualifiers are not included in types.
    3703 The assertion ``\lstinline$|ptr_to( Safe_pointer, int )$'' should be read as
    3704 ``\lstinline$Safe_pointer$ acts like a pointer to \lstinline$int$''.
    3705 \begin{lstlisting}
    3706 trait ptr_to( otype P | pointer( P ), otype T ) {@\impl{ptr_to}@@\use{pointer}@
     3705The assertion ``\lstinline@|ptr_to( Safe_pointer, int )@'' should be read as
     3706``\lstinline@Safe_pointer@ acts like a pointer to \lstinline@int@''.
     3707\begin{lstlisting}
     3708trait ptr_to( otype P | pointer( P ), otype T ) {§\impl{ptr_to}§§\use{pointer}§
    37073709        lvalue T *?( P );
    37083710        lvalue T ?[?]( P, long int );
    37093711};
    3710 trait ptr_to_const( otype P | pointer( P ), otype T ) {@\impl{ptr_to_const}@
     3712trait ptr_to_const( otype P | pointer( P ), otype T ) {§\impl{ptr_to_const}§
    37113713        const lvalue T *?( P );
    3712         const lvalue T ?[?]( P, long int );@\use{pointer}@
     3714        const lvalue T ?[?]( P, long int );§\use{pointer}§
    37133715};
    3714 trait ptr_to_volatile( otype P | pointer( P ), otype T ) }@\impl{ptr_to_volatile}@
     3716trait ptr_to_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_volatile}§
    37153717        volatile lvalue T *?( P );
    3716         volatile lvalue T ?[?]( P, long int );@\use{pointer}@
     3718        volatile lvalue T ?[?]( P, long int );§\use{pointer}§
    37173719};
    3718 trait ptr_to_const_volatile( otype P | pointer( P ), otype T ) }@\impl{ptr_to_const_volatile}@
    3719         const volatile lvalue T *?( P );@\use{pointer}@
     3720trait ptr_to_const_volatile( otype P | pointer( P ), otype T ) }§\impl{ptr_to_const_volatile}§
     3721        const volatile lvalue T *?( P );§\use{pointer}§
    37203722        const volatile lvalue T ?[?]( P, long int );
    37213723};
    37223724\end{lstlisting}
    37233725
    3724 Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline$T *$'' can be assigned to a ``\lstinline$const T *$'', a ``\lstinline$volatile T *$'', and a ``\lstinline$const volatile T *$''.
     3726Assignment to pointers is more complicated than is the case with other types, because the target's type can have extra type qualifiers in the pointed-at type: a ``\lstinline@T *@'' can be assigned to a ``\lstinline@const T *@'', a ``\lstinline@volatile T *@'', and a ``\lstinline@const volatile T *@''.
    37253727Again, the pointed-at type is passed in, so that assertions can connect these specifications to the
    3726 ``\lstinline$ptr_to$'' specifications.
    3727 \begin{lstlisting}
    3728 trait m_l_ptr_to( otype P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to}@ otype T | ptr_to( P, T )@\use{ptr_to}@ {
     3728``\lstinline@ptr_to@'' specifications.
     3729\begin{lstlisting}
     3730trait m_l_ptr_to( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to}§ otype T | ptr_to( P, T )§\use{ptr_to}§ {
    37293731        P ?=?( P *, T * );
    37303732        T * ?=?( T **, P );
    37313733};
    3732 trait m_l_ptr_to_const( otype P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_const}@ otype T | ptr_to_const( P, T )@\use{ptr_to_const}@) {
     3734trait m_l_ptr_to_const( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to_const}§ otype T | ptr_to_const( P, T )§\use{ptr_to_const}§) {
    37333735        P ?=?( P *, const T * );
    37343736        const T * ?=?( const T **, P );
    37353737};
    3736 trait m_l_ptr_to_volatile( otype P | m_l_pointer( P ),@\use{m_l_pointer}@@\impl{m_l_ptr_to_volatile}@ otype T | ptr_to_volatile( P, T )) {@\use{ptr_to_volatile}@
     3738trait m_l_ptr_to_volatile( otype P | m_l_pointer( P ),§\use{m_l_pointer}§§\impl{m_l_ptr_to_volatile}§ otype T | ptr_to_volatile( P, T )) {§\use{ptr_to_volatile}§
    37373739        P ?=?( P *, volatile T * );
    37383740        volatile T * ?=?( volatile T **, P );
    37393741};
    3740 trait m_l_ptr_to_const_volatile( otype P | ptr_to_const_volatile( P ),@\use{ptr_to_const_volatile}@@\impl{m_l_ptr_to_const_volatile}@
    3741                 otype T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {@\use{m_l_ptr_to_const}@@\use{m_l_ptr_to_volatile}@
     3742trait m_l_ptr_to_const_volatile( otype P | ptr_to_const_volatile( P ),§\use{ptr_to_const_volatile}§§\impl{m_l_ptr_to_const_volatile}§
     3743                otype T | m_l_ptr_to_volatile( P, T ) | m_l_ptr_to_const( P )) {§\use{m_l_ptr_to_const}§§\use{m_l_ptr_to_volatile}§
    37423744        P ?=?( P *, const volatile T * );
    37433745        const volatile T * ?=?( const volatile T **, P );
     
    37483750An alternative specification can make use of the fact that qualification of the pointed-at type is part of a pointer type to capture that regularity.
    37493751\begin{lstlisting}
    3750 trait m_l_ptr_like( type MyP | m_l_pointer( MyP ),@\use{m_l_pointer}@@\impl{m_l_ptr_like}@ type CP | m_l_pointer( CP ) ) {
     3752trait m_l_ptr_like( type MyP | m_l_pointer( MyP ),§\use{m_l_pointer}§§\impl{m_l_ptr_like}§ type CP | m_l_pointer( CP ) ) {
    37513753        MyP ?=?( MyP *, CP );
    37523754        CP ?=?( CP *, MyP );
    37533755};
    37543756\end{lstlisting}
    3755 The assertion ``\lstinline$| m_l_ptr_like( Safe_ptr, const int * )$'' should be read as
    3756 ``\lstinline$Safe_ptr$ is a pointer type like \lstinline$const int *$''.
     3757The assertion ``\lstinline@| m_l_ptr_like( Safe_ptr, const int * )@'' should be read as
     3758``\lstinline@Safe_ptr@ is a pointer type like \lstinline@const int *@''.
    37573759This specification has two defects, compared to the original four: there is no automatic assertion that dereferencing a
    3758 \lstinline$MyP$ produces an lvalue of the type that \lstinline$CP$ points at, and the
    3759 ``\lstinline$|m_l_pointer( CP )$'' assertion provides only a weak assurance that the argument passed to \lstinline$CP$ really is a pointer type.
     3760\lstinline@MyP@ produces an lvalue of the type that \lstinline@CP@ points at, and the
     3761``\lstinline@|m_l_pointer( CP )@'' assertion provides only a weak assurance that the argument passed to \lstinline@CP@ really is a pointer type.
    37603762
    37613763
     
    37633765
    37643766Different operators often have related meanings;
    3765 for instance, in C, ``\lstinline$+$'',
    3766 ``\lstinline$+=$'', and the two versions of ``\lstinline$++$'' perform variations of addition.
     3767for instance, in C, ``\lstinline@+@'',
     3768``\lstinline@+=@'', and the two versions of ``\lstinline@++@'' perform variations of addition.
    37673769Languages 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.
    37683770Completeness and consistency is left to the good taste and discretion of the programmer.
     
    37773779The different comparison operators have obvious relationships, but there is no obvious subset of the operations to use in the implementation of the others.
    37783780However, 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;
    3779 the library function \lstinline$strcmp$ is an example.
    3780 
    3781 C and \CFA have an extra, non-obvious comparison operator: ``\lstinline$!$'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
     3781the library function \lstinline@strcmp@ is an example.
     3782
     3783C and \CFA have an extra, non-obvious comparison operator: ``\lstinline@!@'', logical negation, returns 1 if its operand compares equal to 0, and 0 otherwise.
    37823784\begin{lstlisting}
    37833785trait comparable( otype T ) {
     
    38283830
    38293831Note 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
    3830 \lstinline$int_base$, \lstinline$arith_base$ and \lstinline$comparable$.
     3832\lstinline@int_base@, \lstinline@arith_base@ and \lstinline@comparable@.
    38313833Note also that these declarations provide guidance and assistance, but they do not define an absolutely minimal set of requirements.
    3832 A truly minimal implementation of an arithmetic type might only provide
    3833 \lstinline$0$, \lstinline$1$, and \lstinline$?-=?$, which would be used by polymorphic
    3834 \lstinline$?+=?$, \lstinline$?*=?$, and \lstinline$?/=?$ functions.
    3835 
    3836 Note also that \lstinline$short$ is an integer type in C11 terms, but has no operations!
     3834A truly minimal implementation of an arithmetic type might only provide \lstinline@0@, \lstinline@1@, and \lstinline@?-=?@, which would be used by polymorphic \lstinline@?+=?@, \lstinline@?*=?@, and \lstinline@?/=?@ functions.
     3835
     3836Note also that \lstinline@short@ is an integer type in C11 terms, but has no operations!
    38373837
    38383838
     
    38413841
    38423842Restrict 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.
     3843This gets into \lstinline@noalias@ territory.
     3844Qualifying anything (``\lstinline@short restrict rs@'') means pointer parameters of \lstinline@?++@, etc, would need restrict qualifiers.
    38453845
    38463846Enumerated types.
     
    38523852Color, enum Color ) really make sense? ?++ does, but it adds (int)1.
    38533853
    3854 Operators on {,signed,unsigned} char and other small types. ?<? harmless;
     3854Operators on {,signed,unsigned} char and other small types. \lstinline@?<?@ harmless;
    38553855?*? questionable for chars.
    38563856Generic selections make these choices visible.
     
    38583858``promotion'' function?
    38593859
    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 ptrdiff\_t by name in the predefineds.
     3860\lstinline@register@ assignment might be handled as assignment to a temporary with copying back and forth, but copying must not be done by assignment.
     3861
     3862Don't use \lstinline@ptrdiff_t@ by name in the predefineds.
    38633863
    38643864Polymorphic objects.
Note: See TracChangeset for help on using the changeset viewer.