Changeset 67f2170


Ignore:
Timestamp:
Jul 7, 2017, 12:44:55 PM (4 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
0322865
Parents:
eaace25
Message:

Fixed bad merge of doc

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

    reaace25 r67f2170  
    11%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
    2 %%
     2%% 
    33%% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo
    44%%
    55%% The contents of this file are covered under the licence agreement in the
    66%% file "LICENCE" distributed with Cforall.
    7 %%
    8 %% user.tex --
    9 %%
     7%% 
     8%% user.tex -- 
     9%% 
    1010%% Author           : Peter A. Buhr
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Sun Jul  2 09:49:56 2017
    14 %% Update Count     : 2503
     13%% Last Modified On : Fri Jul  7 10:36:39 2017
     14%% Update Count     : 2547
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    5757\CFAStyle                                                                                               % use default CFA format-style
    5858
    59 % inline code �...� (copyright symbol) emacs: C-q M-)
    60 % red highlighting �...� (registered trademark symbol) emacs: C-q M-.
    61 % blue highlighting �...� (sharp s symbol) emacs: C-q M-_
    62 % green highlighting �...� (cent symbol) emacs: C-q M-"
    63 % LaTex escape �...� (section symbol) emacs: C-q M-'
    64 % keyword escape �...� (pilcrow symbol) emacs: C-q M-^
     59% inline code ©...© (copyright symbol) emacs: C-q M-)
     60% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
     61% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
     62% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
     63% LaTex escape §...§ (section symbol) emacs: C-q M-'
     64% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    6565% math escape $...$ (dollar symbol)
    6666
     
    158158\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
    159159\begin{cfa}
    160 #include <fstream>�\indexc{fstream}�
     160#include <fstream>§\indexc{fstream}§
    161161
    162162int main( void ) {
    163163        int x = 0, y = 1, z = 2;
    164         �sout | x | y | z | endl;�
     164        ®sout | x | y | z | endl;®
    165165}
    166166\end{cfa}
    167167&
    168168\begin{lstlisting}
    169 #include <stdio.h>�\indexc{stdio.h}�
     169#include <stdio.h>§\indexc{stdio.h}§
    170170
    171171int main( void ) {
    172172        int x = 0, y = 1, z = 2;
    173         �printf( "%d %d %d\n", x, y, z );�
     173        ®printf( "%d %d %d\n", x, y, z );®
    174174}
    175175\end{lstlisting}
    176176&
    177177\begin{lstlisting}
    178 #include <iostream>�\indexc{iostream}�
     178#include <iostream>§\indexc{iostream}§
    179179using namespace std;
    180180int main() {
    181181        int x = 0, y = 1, z = 2;
    182         �cout<<x<<" "<<y<<" "<<z<<endl;�
     182        ®cout<<x<<" "<<y<<" "<<z<<endl;®
    183183}
    184184\end{lstlisting}
     
    222222\CC~\cite{C++14,C++} is an example of a similar project;
    223223however, it largely extended the language, and did not address many existing problems.\footnote{%
    224 Two important existing problems addressed were changing the type of character literals from �int� to �char� and enumerator from �int� to the type of its enumerators.}
     224Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
    225225\Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language.
    226226\Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
     
    242242(See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
    243243A first \CFA implementation of these extensions was by Esteves~\cite{Esteves04}.
    244 The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a �forall� clause (giving the language its name):
     244The signature feature of \CFA is parametric-polymorphic functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
    245245\begin{lstlisting}
    246 �forall( otype T )� T identity( T val ) { return val; }
    247 int forty_two = identity( 42 );                 �\C{// T is bound to int, forty\_two == 42}�
     246®forall( otype T )® T identity( T val ) { return val; }
     247int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
    248248\end{lstlisting}
    249249% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
     
    264264
    265265\begin{comment}
    266 A simple example is leveraging the existing type-unsafe (�void *�) C �bsearch� to binary search a sorted floating-point array:
     266A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point array:
    267267\begin{lstlisting}
    268268void * bsearch( const void * key, const void * base, size_t dim, size_t size,
     
    288288int posn = bsearch( 5.0, vals, 10 );
    289289\end{lstlisting}
    290 The nested function �comp� provides the hidden interface from typed \CFA to untyped (�void *�) C, plus the cast of the result.
    291 Providing a hidden �comp� function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
     290The nested function ©comp© provides the hidden interface from typed \CFA to untyped (©void *©) C, plus the cast of the result.
     291Providing a hidden ©comp© function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
    292292As well, an alternate kind of return is made available: position versus pointer to found element.
    293 \CC's type-system cannot disambiguate between the two versions of �bsearch� because it does not use the return type in overload resolution, nor can \CC separately compile a templated �bsearch�.
     293\CC's type-system cannot disambiguate between the two versions of ©bsearch© because it does not use the return type in overload resolution, nor can \CC separately compile a templated ©bsearch©.
    294294
    295295\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations.
    296 For example, it is possible to write a type-safe \CFA wrapper �malloc� based on the C �malloc�:
     296For example, it is possible to write a type-safe \CFA wrapper ©malloc© based on the C ©malloc©:
    297297\begin{lstlisting}
    298298forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
    299 int * ip = malloc();                                    �\C{// select type and size from left-hand side}�
     299int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
    300300double * dp = malloc();
    301301struct S {...} * sp = malloc();
     
    305305
    306306However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
    307 For example, the C math-library provides the following routines for computing the absolute value of the basic types: �abs�, �labs�, �llabs�, �fabs�, �fabsf�, �fabsl�, �cabsf�, �cabs�, and �cabsl�.
    308 Whereas, \CFA wraps each of these routines into ones with the common name �abs�:
     307For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
     308Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
    309309\begin{cfa}
    310310char abs( char );
    311 �extern "C" {�
    312 int abs( int );                                                 �\C{// use default C routine for int}�
    313 �}� // extern "C"
     311®extern "C" {®
     312int abs( int );                                                 §\C{// use default C routine for int}§
     313®}® // extern "C"
    314314long int abs( long int );
    315315long long int abs( long long int );
     
    321321long double _Complex abs( long double _Complex );
    322322\end{cfa}
    323 The problem is the name clash between the library routine �abs� and the \CFA names �abs�.
    324 Hence, names appearing in an �extern "C"� block have \newterm*{C linkage}.
     323The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
     324Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    325325Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
    326326Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
    327327There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
    328328This example strongly illustrates a core idea in \CFA: \emph{the power of a name}.
    329 The name ``�abs�'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
    330 Hence, knowing the name �abs� should be sufficient to apply it to any type where it is applicable.
     329The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
     330Hence, knowing the name ©abs© should be sufficient to apply it to any type where it is applicable.
    331331The time savings and safety of using one name uniformly versus $N$ unique names should not be underestimated.
    332332
     
    334334\section[Compiling CFA Program]{Compiling \CFA Program}
    335335
    336 The command �cfa� is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
    337 \begin{cfa}
    338 cfa�\indexc{cfa}\index{compilation!cfa@�cfa�}� [ gcc-options ] C/�\CFA�-files [ assembler/loader-files ]
    339 \end{cfa}
    340 \CFA programs having the following �gcc� flags turned on:
     336The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
     337\begin{cfa}
     338cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
     339\end{cfa}
     340\CFA programs having the following ©gcc© flags turned on:
    341341\begin{description}
    342342\item
    343 \Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{�-std=gnu99�}}
     343\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
    344344The 1999 C standard plus GNU extensions.
    345345\item
    346346{\lstset{deletekeywords={inline}}
    347 \Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{�-fgnu89-inline�}}
     347\Indexc{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{©-fgnu89-inline©}}
    348348Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
    349349}%
     
    352352\begin{description}
    353353\item
    354 \Indexc{-CFA}\index{compilation option!-CFA@�-CFA�}
     354\Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
    355355Only the C preprocessor and the \CFA translator steps are performed and the transformed program is written to standard output, which makes it possible to examine the code generated by the \CFA translator.
    356356The generated code started with the standard \CFA prelude.
    357357
    358358\item
    359 \Indexc{-debug}\index{compilation option!-debug@�-debug�}
     359\Indexc{-debug}\index{compilation option!-debug@©-debug©}
    360360The program is linked with the debugging version of the runtime system.
    361361The debug version performs runtime checks to help during the debugging phase of a \CFA program, but substantially slows the execution of the program.
     
    364364
    365365\item
    366 \Indexc{-nodebug}\index{compilation option!-nodebug@�-nodebug�}
     366\Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©}
    367367The program is linked with the non-debugging version of the runtime system, so the execution of the program is faster.
    368 \Emph{However, no runtime checks or �assert�s are performed so errors usually result in abnormal program termination.}
    369 
    370 \item
    371 \Indexc{-help}\index{compilation option!-help@�-help�}
     368\Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.}
     369
     370\item
     371\Indexc{-help}\index{compilation option!-help@©-help©}
    372372Information about the set of \CFA compilation flags is printed.
    373373
    374374\item
    375 \Indexc{-nohelp}\index{compilation option!-nohelp@�-nohelp�}
     375\Indexc{-nohelp}\index{compilation option!-nohelp@©-nohelp©}
    376376Information about the set of \CFA compilation flags is not printed.
    377377\textbf{This option is the default.}
    378378
    379379\item
    380 \Indexc{-quiet}\index{compilation option!-quiet@�-quiet�}
     380\Indexc{-quiet}\index{compilation option!-quiet@©-quiet©}
    381381The \CFA compilation message is not printed at the beginning of a compilation.
    382382
    383383\item
    384 \Indexc{-noquiet}\index{compilation option!-noquiet@�-noquiet�}
     384\Indexc{-noquiet}\index{compilation option!-noquiet@©-noquiet©}
    385385The \CFA compilation message is printed at the beginning of a compilation.
    386386\textbf{This option is the default.}
    387387
    388388\item
    389 \Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@�-no-include-stdhdr�}
    390 Do not supply �extern "C"� wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
     389\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
     390Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
    391391\textbf{This option is \emph{not} the default.}
    392392\end{description}
     
    395395\begin{description}
    396396\item
    397 \Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{�__CFA__�}}
     397\Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
    398398is available during preprocessing and its value is the major \Index{version number} of \CFA.\footnote{
    399399The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
     
    401401
    402402\item
    403 \Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{�__CFA_MINOR__�}}
     403\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
    404404is available during preprocessing and its value is the minor \Index{version number} of \CFA.
    405405
    406406\item
    407 \Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@�__CFA_PATCH__�}
     407\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
    408408is available during preprocessing and its value is the patch \Index{level number} of \CFA.
    409409
    410410\item
    411 \Indexc{__CFA__}\index{preprocessor variables!__CFA__@�__CFA__�},
    412 \Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@�__CFORALL__�} and
    413 \Indexc{__cforall}\index{preprocessor variables!__cforall@�__cforall�}
     411\Indexc{__CFA__}\index{preprocessor variables!__CFA__@©__CFA__©},
     412\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©} and
     413\Indexc{__cforall}\index{preprocessor variables!__cforall@©__cforall©}
    414414are always available during preprocessing and have no value.
    415415\end{description}
     
    418418\begin{cfa}
    419419#ifndef __CFORALL__
    420 #include <stdio.h>�\indexc{stdio.h}�    �\C{// C header file}�
     420#include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
    421421#else
    422 #include <fstream>�\indexc{fstream}�    �\C{// \CFA header file}�
     422#include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
    423423#endif
    424424\end{cfa}
    425 which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}.
     425which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}. 
    426426
    427427
     
    430430Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
    431431\begin{cfa}
    432 2�_�147�_�483�_�648;                                    �\C{// decimal constant}�
    433 56�_�ul;                                                                �\C{// decimal unsigned long constant}�
    434 0�_�377;                                                                �\C{// octal constant}�
    435 0x�_�ff�_�ff;                                                   �\C{// hexadecimal constant}�
    436 0x�_�ef3d�_�aa5c;                                               �\C{// hexadecimal constant}�
    437 3.141�_�592�_�654;                                              �\C{// floating point constant}�
    438 10�_�e�_�+1�_�00;                                               �\C{// floating point constant}�
    439 0x�_�ff�_�ff�_�p�_�3;                                   �\C{// hexadecimal floating point}�
    440 0x�_�1.ffff�_�ffff�_�p�_�128�_�l;               �\C{// hexadecimal floating point long constant}�
    441 L�_��"\texttt{\textbackslash{x}}��_��\texttt{ff}��_��\texttt{ee}"�;     �\C{// wide character constant}�
     4322®_®147®_®483®_®648;                                    §\C{// decimal constant}§
     43356®_®ul;                                                                §\C{// decimal unsigned long constant}§
     4340®_®377;                                                                §\C{// octal constant}§
     4350x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
     4360x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
     4373.141®_®592®_®654;                                              §\C{// floating point constant}§
     43810®_®e®_®+1®_®00;                                               §\C{// floating point constant}§
     4390x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating point}§
     4400x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating point long constant}§
     441L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
    442442\end{cfa}
    443443The rules for placement of underscores is as follows:
    444444\begin{enumerate}
    445445\item
    446 A sequence of underscores is disallowed, \eg �12__34� is invalid.
     446A sequence of underscores is disallowed, \eg ©12__34© is invalid.
    447447\item
    448448Underscores may only appear within a sequence of digits (regardless of the digit radix).
    449 In other words, an underscore cannot start or end a sequence of digits, \eg �_1�, �1_� and �_1_� are invalid (actually, the 1st and 3rd examples are identifier names).
     449In other words, an underscore cannot start or end a sequence of digits, \eg ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).
    450450\item
    451451A numeric prefix may end with an underscore;
    452452a numeric infix may begin and/or end with an underscore;
    453453a numeric suffix may begin with an underscore.
    454 For example, the octal �0� or hexadecimal �0x� prefix may end with an underscore �0_377� or �0x_ff�;
    455 the exponent infix �E� may start or end with an underscore �1.0_E10�, �1.0E_10� or �1.0_E_10�;
    456 the type suffixes �U�, �L�, etc. may start with an underscore �1_U�, �1_ll� or �1.0E10_f�.
     454For example, the octal ©0© or hexadecimal ©0x© prefix may end with an underscore ©0_377© or ©0x_ff©;
     455the exponent infix ©E© may start or end with an underscore ©1.0_E10©, ©1.0E_10© or ©1.0_E_10©;
     456the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
    457457\end{enumerate}
    458458It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
     
    465465\CFA accommodates keyword clashes with existing C variable-names by syntactic transformations using the \CFA backquote escape-mechanism:
    466466\begin{cfa}
    467 int �`�otype�`� = 3;                    �\C{// make keyword an identifier}�
    468 double �`�forall�`� = 3.5;
     467int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
     468double ®`®forall®`® = 3.5;
    469469\end{cfa}
    470470Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
    471 \VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: �#include_next� and �-I filename�:
     471\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
    472472
    473473\begin{figure}
    474474\begin{cfa}
    475475// include file uses the CFA keyword "otype".
    476 #if ! defined( otype )                  �\C{// nesting ?}�
    477 #define otype �`�otype�`�               �\C{// make keyword an identifier}�
     476#if ! defined( otype )                  §\C{// nesting ?}§
     477#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
    478478#define __CFA_BFD_H__
    479479#endif // ! otype
    480480
    481 #�include_next� <bfd.h>                 �\C{// must have internal check for multiple expansion}�
    482 
    483 #if defined( otype ) && defined( __CFA_BFD_H__ )        �\C{// reset only if set}�
     481#®include_next® <bfd.h>                 §\C{// must have internal check for multiple expansion}§
     482
     483#if defined( otype ) && defined( __CFA_BFD_H__ )        §\C{// reset only if set}§
    484484#undef otype
    485485#undef __CFA_BFD_H__
     
    493493\section{Labelled Continue/Break}
    494494
    495 While C provides �continue� and �break� statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
     495While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    496496Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
    497 To prevent having to switch to the �goto�, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@�continue�} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@�break�} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
    498 For both �continue� and �break�, the target label must be directly associated with a �for�, �while� or �do� statement;
    499 for �break�, the target label can also be associated with a �switch�, �if� or compound (�{}�) statement.
    500 \VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled �continue� and �break�, specifying which control structure is the target for exit, and the corresponding C program using only �goto�.
     497To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@\lstinline $continue$!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@\lstinline $break$!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}.
     498For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
     499for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
     500\VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled ©continue© and ©break©, specifying which control structure is the target for exit, and the corresponding C program using only ©goto©.
    501501The innermost loop has 7 exit points, which cause resumption or termination of one or more of the 7 \Index{nested control-structure}s.
    502502
     
    505505\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}}      & \multicolumn{1}{c}{\textbf{C}}        \\
    506506\begin{cfa}
    507 �LC:� {
    508         ... �declarations� ...
    509         �LS:� switch ( ... ) {
     507®LC:® {
     508        ... §declarations§ ...
     509        ®LS:® switch ( ... ) {
    510510          case 3:
    511                 �LIF:� if ( ... ) {
    512                         �LF:� for ( ... ) {
    513                                 �LW:� while ( ... ) {
    514                                         ... break �LC�; ...                     // terminate compound
    515                                         ... break �LS�; ...                     // terminate switch
    516                                         ... break �LIF�; ...                    // terminate if
    517                                         ... continue �LF;� ...   // resume loop
    518                                         ... break �LF�; ...                     // terminate loop
    519                                         ... continue �LW�; ...   // resume loop
    520                                         ... break �LW�; ...               // terminate loop
     511                ®LIF:® if ( ... ) {
     512                        ®LF:® for ( ... ) {
     513                                ®LW:® while ( ... ) {
     514                                        ... break ®LC®; ...                     // terminate compound
     515                                        ... break ®LS®; ...                     // terminate switch
     516                                        ... break ®LIF®; ...                    // terminate if
     517                                        ... continue ®LF;® ...   // resume loop
     518                                        ... break ®LF®; ...                     // terminate loop
     519                                        ... continue ®LW®; ...   // resume loop
     520                                        ... break ®LW®; ...               // terminate loop
    521521                                } // while
    522522                        } // for
    523523                } else {
    524                         ... break �LIF�; ...                                     // terminate if
     524                        ... break ®LIF®; ...                                     // terminate if
    525525                } // if
    526526        } // switch
     
    530530\begin{cfa}
    531531{
    532         ... �declarations� ...
     532        ... §declarations§ ...
    533533        switch ( ... ) {
    534534          case 3:
     
    536536                        for ( ... ) {
    537537                                while ( ... ) {
    538                                         ... goto �LC�; ...
    539                                         ... goto �LS�; ...
    540                                         ... goto �LIF�; ...
    541                                         ... goto �LFC�; ...
    542                                         ... goto �LFB�; ...
    543                                         ... goto �LWC�; ...
    544                                         ... goto �LWB�; ...
    545                                   �LWC�: ; } �LWB:� ;
    546                           �LFC:� ; } �LFB:� ;
     538                                        ... goto ®LC®; ...
     539                                        ... goto ®LS®; ...
     540                                        ... goto ®LIF®; ...
     541                                        ... goto ®LFC®; ...
     542                                        ... goto ®LFB®; ...
     543                                        ... goto ®LWC®; ...
     544                                        ... goto ®LWB®; ...
     545                                  ®LWC®: ; } ®LWB:® ;
     546                          ®LFC:® ; } ®LFB:® ;
    547547                } else {
    548                         ... goto �LIF�; ...
    549                 } �L3:� ;
    550         } �LS:� ;
    551 } �LC:� ;
     548                        ... goto ®LIF®; ...
     549                } ®L3:® ;
     550        } ®LS:® ;
     551} ®LC:® ;
    552552\end{cfa}
    553553\end{tabular}
     
    606606
    607607
    608 Both labelled �continue� and �break� are a �goto�\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
     608Both labelled ©continue© and ©break© are a ©goto©\index{goto@\lstinline $goto$!restricted} restricted in the following ways:
    609609\begin{itemize}
    610610\item
     
    615615This restriction prevents missing initialization at the start of a control structure resulting in undefined behaviour.
    616616\end{itemize}
    617 The advantage of the labelled �continue�/�break� is allowing static multi-level exits without having to use the �goto� statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
     617The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
    618618Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure.
    619 With �goto�, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
     619With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
    620620Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
    621 The implicit targets of the current �continue� and �break�, \ie the closest enclosing loop or �switch�, change as certain constructs are added or removed.
     621The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
    622622
    623623
    624624\section{Switch Statement}
    625625
    626 C allows a number of questionable forms for the �switch� statement:
     626C allows a number of questionable forms for the ©switch© statement:
    627627\begin{enumerate}
    628628\item
    629 By default, the end of a �case� clause\footnote{
    630 In this section, the term \emph{case clause} refers to either a �case� or �default� clause.}
    631 \emph{falls through} to the next �case� clause in the �switch� statement;
    632 to exit a �switch� statement from a �case� clause requires explicitly terminating the clause with a transfer statement, most commonly �break�:
     629By default, the end of a ©case© clause\footnote{
     630In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
     631\emph{falls through} to the next ©case© clause in the ©switch© statement;
     632to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
    633633\begin{cfa}
    634634switch ( i ) {
     
    661661if ( argc == 3 ) {
    662662        // open output file
    663         // open input file
    664 } else if ( argc == 2 ) {
    665         // open input file
    666 
    667 } else {
     663        ®// open input file
     664®} else if ( argc == 2 ) {
     665        ®// open input file
     666
     667®} else {
    668668        // usage message
    669669}
     
    672672\end{quote2}
    673673In this example, case 2 is always done if case 3 is done.
    674 This control flow is difficult to simulate with if statements or a �switch� statement without fall-through as code must be duplicated or placed in a separate routine.
     674This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
    675675C also uses fall-through to handle multiple case-values resulting in the same action:
    676676\begin{cfa}
     
    685685\end{cfa}
    686686However, this situation is handled in other languages without fall-through by allowing a list of case values.
    687 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a �switch� statement.
    688 Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the �break� statement at the end of a �case� clause, resulting in inadvertent fall-through.
    689 
    690 \item
    691 It is possible to place �case� clauses on statements nested \emph{within} the body of the �switch� statement:
     687While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
     688Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
     689
     690\item
     691It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
    692692\begin{cfa}
    693693switch ( i ) {
     
    695695        if ( j < k ) {
    696696                ...
    697           �case 1:�             // transfer into "if" statement
     697          ®case 1:®             // transfer into "if" statement
    698698                ...
    699699        } // if
     
    701701        while ( j < 5 ) {
    702702                ...
    703           �case 3:�             // transfer into "while" statement
     703          ®case 3:®             // transfer into "while" statement
    704704                ...
    705705        } // while
     
    726726}
    727727\end{cfa}
    728 which unrolls a loop N times (N = 8 above) and uses the �switch� statement to deal with any iterations not a multiple of N.
     728which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
    729729While efficient, this sort of special purpose usage is questionable:
    730730\begin{quote}
     
    733733\end{quote}
    734734\item
    735 It is possible to place the �default� clause anywhere in the list of labelled clauses for a �switch� statement, rather than only at the end.
    736 Virtually all programming languages with a �switch� statement require the �default� clause to appear last in the case-clause list.
    737 The logic for this semantics is that after checking all the �case� clauses without success, the �default� clause is selected;
    738 hence, physically placing the �default� clause at the end of the �case� clause list matches with this semantics.
    739 This physical placement can be compared to the physical placement of an �else� clause at the end of a series of connected �if�/�else� statements.
    740 
    741 \item
    742 It is possible to place unreachable code at the start of a �switch� statement, as in:
     735It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
     736Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     737The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
     738hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     739This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
     740
     741\item
     742It is possible to place unreachable code at the start of a ©switch© statement, as in:
    743743\begin{cfa}
    744744switch ( x ) {
    745         �int y = 1;�                            �\C{// unreachable initialization}�
    746         �x = 7;�                                        �\C{// unreachable code without label/branch}�
     745        ®int y = 1;®                            §\C{// unreachable initialization}§
     746        ®x = 7;®                                        §\C{// unreachable code without label/branch}§
    747747  case 3: ...
    748748        ...
    749         �int z = 0;�                            �\C{// unreachable initialization, cannot appear after case}�
     749        ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
    750750        z = 2;
    751751  case 3:
    752         �x = z;�                                        �\C{// without fall through, z is uninitialized}�
    753 }
    754 \end{cfa}
    755 While the declaration of the local variable �y� is useful with a scope across all �case� clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
    756 Furthermore, any statements before the first �case� clause can only be executed if labelled and transferred to using a �goto�, either from outside or inside of the �switch�, both of which are problematic.
    757 As well, the declaration of �z� cannot occur after the �case� because a label can only be attached to a statement, and without a fall through to case 3, �z� is uninitialized.
    758 The key observation is that the �switch� statement branches into control structure, \ie there are multiple entry points into its statement body.
     752        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
     753}
     754\end{cfa}
     755While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
     756Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
     757As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
     758The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
    759759\end{enumerate}
    760760
     
    762762\begin{itemize}
    763763\item
    764 the number of �switch� statements is small,
    765 \item
    766 most �switch� statements are well formed (\ie no \Index*{Duff's device}),
    767 \item
    768 the �default� clause is usually written as the last case-clause,
    769 \item
    770 and there is only a medium amount of fall-through from one �case� clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
     764the number of ©switch© statements is small,
     765\item
     766most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
     767\item
     768the ©default© clause is usually written as the last case-clause,
     769\item
     770and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
    771771\end{itemize}
    772 These observations help to put the \CFA changes to the �switch� into perspective.
     772These observations help to put the \CFA changes to the ©switch© into perspective.
    773773\begin{enumerate}
    774774\item
    775775Eliminating default fall-through has the greatest potential for affecting existing code.
    776 However, even if fall-through is removed, most �switch� statements would continue to work because of the explicit transfers already present at the end of each �case� clause, the common placement of the �default� clause at the end of the case list, and the most common use of fall-through, \ie a list of �case� clauses executing common code, \eg:
     776However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
    777777\begin{cfa}
    778778case 1:  case 2:  case 3: ...
     
    780780still works.
    781781Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    782 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of �switch� statement, called �choose�, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword �fallthrough�/�fallthru�, \eg:
    783 \begin{cfa}
    784 �choose� ( i ) {
     782Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
     783\begin{cfa}
     784®choose® ( i ) {
    785785  case 1:  case 2:  case 3:
    786786        ...
    787         // implicit end of switch (break)
    788   case 5:
     787        ®// implicit end of switch (break)
     788  ®case 5:
    789789        ...
    790         �fallthru�;                                     �\C{// explicit fall through}�
     790        ®fallthru®;                                     §\C{// explicit fall through}§
    791791  case 7:
    792792        ...
    793         �break�                                         �\C{// explicit end of switch}�
     793        ®break®                                         §\C{// explicit end of switch}§
    794794  default:
    795795        j = 3;
    796796}
    797797\end{cfa}
    798 Like the �switch� statement, the �choose� statement retains the fall-through semantics for a list of �case� clauses;
    799 the implicit �break� is applied only at the end of the \emph{statements} following a �case� clause.
    800 The explicit �fallthru� is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the �choose� statement.
    801 As well, allowing an explicit �break� from the �choose� is a carry over from the �switch� statement, and expected by C programmers.
    802 \item
    803 \Index*{Duff's device} is eliminated from both �switch� and �choose� statements, and only invalidates a small amount of very questionable code.
    804 Hence, the �case� clause must appear at the same nesting level as the �switch�/�choose� body, as is done in most other programming languages with �switch� statements.
    805 \item
    806 The issue of �default� at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the �default� clause needs to appear is locations other than at the end.
     798Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
     799the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
     800The explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
     801As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
     802\item
     803\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
     804Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
     805\item
     806The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
    807807Therefore, no change is made for this issue.
    808808\item
    809 Dealing with unreachable code in a �switch�/�choose� body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate �case� clause\footnote{
    810 Essentially, these declarations are hoisted before the �switch�/�choose� statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first �case� clause.
     809Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
     810Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
    811811Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    812812\begin{cfa}
    813813switch ( x ) {
    814         �int i = 0;�                            �\C{// allowed only at start}�
     814        ®int i = 0;®                            §\C{// allowed only at start}§
    815815  case 0:
    816816        ...
    817         �int j = 0;�                            �\C{// disallowed}�
     817        ®int j = 0;®                            §\C{// disallowed}§
    818818  case 1:
    819819        {
    820                 �int k = 0;�                    �\C{// allowed at different nesting levels}�
     820                ®int k = 0;®                    §\C{// allowed at different nesting levels}§
    821821                ...
    822822        }
     
    829829\section{Case Clause}
    830830
    831 C restricts the �case� clause of a �switch� statement to a single value.
    832 For multiple �case� clauses associated with the same statement, it is necessary to have multiple �case� clauses rather than multiple values.
    833 Requiring a �case� clause for each value does not seem to be in the spirit of brevity normally associated with C.
    834 Therefore, the �case� clause is extended with a list of values, as in:
     831C restricts the ©case© clause of a ©switch© statement to a single value.
     832For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
     833Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
     834Therefore, the ©case© clause is extended with a list of values, as in:
    835835\begin{quote2}
    836836\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
     
    838838\begin{cfa}
    839839switch ( i ) {
    840   case �1, 3, 5�:
     840  case ®1, 3, 5®:
    841841        ...
    842   case �2, 4, 6�:
     842  case ®2, 4, 6®:
    843843        ...
    844844}
     
    871871\begin{cfa}
    872872switch ( i ) {
    873   case �1~5:�
     873  case ®1~5:®
    874874        ...
    875   case �10~15:�
     875  case ®10~15:®
    876876        ...
    877877}
     
    880880\begin{cfa}
    881881switch ( i )
    882   case �1 ... 5�:
     882  case ®1 ... 5®:
    883883        ...
    884   case �10 ... 15�:
     884  case ®10 ... 15®:
    885885        ...
    886886}
     
    899899Lists of subranges are also allowed.
    900900\begin{cfa}
    901 case �1~5, 12~21, 35~42�:
     901case ®1~5, 12~21, 35~42®:
    902902\end{cfa}
    903903
     
    943943catch( Arithmetic )
    944944\end{cfa}
    945 matches all three derived exception-types: �DivideByZero�, �Overflow�, and �Underflow�.
     945matches all three derived exception-types: ©DivideByZero©, ©Overflow©, and ©Underflow©.
    946946Because the propagation mechanisms perform a simple linear search of the handler clause for a guarded block, and selects the first matching handler, the order of catch clauses in the handler clause becomes important, \eg:
    947947\begin{cfa}
     
    976976For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    977977\begin{cfa}
    978 int �(*�f�())[�5�]� {...};                              �\C{definition}�
    979  ... �(*�f�())[�3�]� += 1;                              �\C{usage}�
     978int ®(*®f®())[®5®]® {...};                              §\C{definition}§
     979 ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
    980980\end{cfa}
    981981Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
     
    990990\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    991991\begin{cfa}
    992 �[5] *� �int� x1;
    993 �* [5]� �int� x2;
    994 �[* [5] int]� f�( int p )�;
     992ß[5] *ß ®int® x1;
     993ß* [5]ß ®int® x2;
     994ß[* [5] int]ß f®( int p )®;
    995995\end{cfa}
    996996&
    997997\begin{cfa}
    998 �int� �*� x1 �[5]�;
    999 �int� �(*�x2�)[5]�;
    1000 �int (*�f�( int p )��)[5]�;
     998®int® ß*ß x1 ß[5]ß;
     999®int® ß(*ßx2ß)[5]ß;
     1000ßint (*ßf®( int p )®ß)[5]ß;
    10011001\end{cfa}
    10021002\end{tabular}
    10031003\end{quote2}
    10041004The only exception is \Index{bit field} specification, which always appear to the right of the base type.
    1005 % Specifically, the character �*� is used to indicate a pointer, square brackets �[�\,�]� are used to represent an array or function return value, and parentheses �()� are used to indicate a routine parameter.
     1005% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
    10061006However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    1007 For instance, variables �x� and �y� of type \Index{pointer} to integer are defined in \CFA as follows:
     1007For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows:
    10081008\begin{quote2}
    10091009\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    10101010\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    10111011\begin{cfa}
    1012 �*� int x, y;
     1012®*® int x, y;
    10131013\end{cfa}
    10141014&
    10151015\begin{cfa}
    1016 int �*�x, �*�y;
     1016int ®*®x, ®*®y;
    10171017\end{cfa}
    10181018\end{tabular}
     
    10231023\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    10241024\begin{cfa}
    1025 �*� int x;
     1025®*® int x;
    10261026int y;
    10271027\end{cfa}
    10281028&
    10291029\begin{cfa}
    1030 int �*�x, y;
     1030int ®*®x, y;
    10311031
    10321032\end{cfa}
     
    10731073\end{quote2}
    10741074
    1075 All type qualifiers, \eg �const�, �volatile�, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
     1075All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
    10761076\begin{quote2}
    10771077\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
     
    10931093\end{tabular}
    10941094\end{quote2}
    1095 All declaration qualifiers, \eg �extern�, �static�, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
     1095All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
    10961096The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
    10971097\begin{quote2}
     
    11151115\end{quote2}
    11161116
    1117 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine �sizeof�:
     1117The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
    11181118\begin{quote2}
    11191119\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    11201120\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    11211121\begin{cfa}
    1122 y = (�* int�)x;
    1123 i = sizeof(�[ 5 ] * int�);
     1122y = (®* int®)x;
     1123i = sizeof(®[ 5 ] * int®);
    11241124\end{cfa}
    11251125&
    11261126\begin{cfa}
    1127 y = (�int *�)x;
    1128 i = sizeof(�int * [ 5 ]�);
     1127y = (®int *®)x;
     1128i = sizeof(®int * [ 5 ]®);
    11291129\end{cfa}
    11301130\end{tabular}
     
    11421142These types may be derived from an object or routine type, called the \newterm{referenced type}.
    11431143Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
    1144 An integer constant expression with the value 0, or such an expression cast to type �void *�, is called a \newterm{null-pointer constant}.\footnote{
     1144An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
    11451145One way to conceptualize the null pointer is that no variable is placed at this address, so the null-pointer address can be used to denote an uninitialized pointer/reference object;
    11461146\ie the null pointer is guaranteed to compare unequal to a pointer to any object or routine.}
     
    11621162&
    11631163\begin{cfa}
    1164 int * �const� x = (int *)100
     1164int * ®const® x = (int *)100
    11651165*x = 3;                 // implicit dereference
    1166 int * �const� y = (int *)104;
     1166int * ®const® y = (int *)104;
    11671167*y = *x;                // implicit dereference
    11681168\end{cfa}
     
    11711171where the right example is how the compiler logically interprets the variables in the left example.
    11721172Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer};
    1173 hence, the implicit type of pointer variables �x� and �y� are constant pointers in the compiler interpretation.
     1173hence, the implicit type of pointer variables ©x© and ©y© are constant pointers in the compiler interpretation.
    11741174In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage.
    11751175These approaches are contrasted in the following:
     
    11941194\end{quote2}
    11951195Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.
    1196 Therefore, the expression �x = y� has only one meaning, �*x = *y�, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
     1196Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of \Index{instruction decoding}.
    11971197
    11981198A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
     
    12021202\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
    12031203\begin{cfa}
    1204 int x, y, �*� p1, �*� p2, �**� p3;
    1205 p1 = �&�x;               // p1 points to x
     1204int x, y, ®*® p1, ®*® p2, ®**® p3;
     1205p1 = ®&®x;               // p1 points to x
    12061206p2 = p1;                 // p2 points to x
    1207 p1 = �&�y;               // p1 points to y
     1207p1 = ®&®y;               // p1 points to y
    12081208p3 = &p2;               // p3 points to p2
    12091209\end{cfa}
     
    12171217For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage
    12181218\begin{cfa}
    1219 p2 = p1 + x;                                    �\C{// compiler infers *p2 = *p1 + x;}�
    1220 \end{cfa}
    1221 Algol68 infers the following dereferencing �*p2 = *p1 + x�, because adding the arbitrary integer value in �x� to the address of �p1� and storing the resulting address into �p2� is an unlikely operation.
    1222 Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices.
     1219p2 = p1 + x;                                    §\C{// compiler infers *p2 = *p1 + x;}§
     1220\end{cfa}
     1221Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
     1222Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices. 
    12231223
    12241224Rather than inferring dereference, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality.
    12251225In C, objects of pointer type always manipulate the pointer object's address:
    12261226\begin{cfa}
    1227 p1 = p2;                                                �\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}�
    1228 p2 = p1 + x;                                    �\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}�
    1229 \end{cfa}
    1230 even though the assignment to �p2� is likely incorrect, and the programmer probably meant:
    1231 \begin{cfa}
    1232 p1 = p2;                                                �\C{// pointer address assignment}�
    1233 �*�p2 = �*�p1 + x;                              �\C{// pointed-to value assignment / operation}�
    1234 \end{cfa}
    1235 The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (�malloc�/�free�).
     1227p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
     1228p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
     1229\end{cfa}
     1230even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
     1231\begin{cfa}
     1232p1 = p2;                                                §\C{// pointer address assignment}§
     1233®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
     1234\end{cfa}
     1235The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    12361236
    12371237However, in most other situations, the pointed-to value is requested more often than the pointer address.
     
    12451245\end{cfa}
    12461246
    1247 To support this common case, a reference type is introduced in \CFA, denoted by �&�, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
    1248 \begin{cfa}
    1249 int x, y, �&� r1, �&� r2, �&&� r3;
    1250 �&�r1 = &x;                                             �\C{// r1 points to x}�
    1251 �&�r2 = &r1;                                    �\C{// r2 points to x}�
    1252 �&�r1 = &y;                                             �\C{// r1 points to y}�
    1253 �&&�r3 = �&�&r2;                                �\C{// r3 points to r2}�
    1254 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); �\C{// implicit dereferencing}�
     1247To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
     1248\begin{cfa}
     1249int x, y, ®&® r1, ®&® r2, ®&&® r3;
     1250®&®r1 = &x;                                             §\C{// r1 points to x}§
     1251®&®r2 = &r1;                                    §\C{// r2 points to x}§
     1252®&®r1 = &y;                                             §\C{// r1 points to y}§
     1253®&&®r3 = ®&®&r2;                                §\C{// r3 points to r2}§
     1254r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
    12551255\end{cfa}
    12561256Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
     
    12581258One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
    12591259\begin{cfa}
    1260 �*�r2 = ((�*�r1 + �*�r2) �*� (�**�r3 - �*�r1)) / (�**�r3 - 15);
    1261 \end{cfa}
    1262 When a reference operation appears beside a dereference operation, \eg �&*�, they cancel out.
     1260®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
     1261\end{cfa}
     1262When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.
    12631263However, in C, the cancellation always yields a value (\Index{rvalue}).\footnote{
    1264 The unary �&� operator yields the address of its operand.
     1264The unary ©&© operator yields the address of its operand.
    12651265If the operand has type ``type'', the result has type ``pointer to type''.
    1266 If the operand is the result of a unary �*� operator, neither that operator nor the �&� operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
     1266If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}}
    12671267For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
    12681268\begin{cfa}
    1269 (&�*�)r1 = &x;                                  �\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}�
     1269(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
    12701270\end{cfa}
    12711271Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    12721272\begin{cfa}
    1273 (&(&�*�)�*�)r3 = &(&�*�)r2;             �\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}�
     1273(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
    12741274\end{cfa}
    12751275Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
     
    12791279int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    12801280                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
    1281 ***p3 = 3;                                              �\C{// change x}�
    1282 r3 = 3;                                                 �\C{// change x, ***r3}�
    1283 **p3 = ...;                                             �\C{// change p1}�
    1284 &r3 = ...;                                              �\C{// change r1, (\&*)**r3, 1 cancellation}�
    1285 *p3 = ...;                                              �\C{// change p2}�
    1286 &&r3 = ...;                                             �\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}�
    1287 &&&r3 = p3;                                             �\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}�
     1281***p3 = 3;                                              §\C{// change x}§
     1282r3 = 3;                                                 §\C{// change x, ***r3}§
     1283**p3 = ...;                                             §\C{// change p1}§
     1284&r3 = ...;                                              §\C{// change r1, (\&*)**r3, 1 cancellation}§
     1285*p3 = ...;                                              §\C{// change p2}§
     1286&&r3 = ...;                                             §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
     1287&&&r3 = p3;                                             §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
    12881288\end{cfa}
    12891289Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
     
    12921292As for a pointer type, a reference type may have qualifiers:
    12931293\begin{cfa}
    1294 const int cx = 5;                                       �\C{// cannot change cx;}�
    1295 const int & cr = cx;                            �\C{// cannot change what cr points to}�
    1296 �&�cr = &cx;                                            �\C{// can change cr}�
    1297 cr = 7;                                                         �\C{// error, cannot change cx}�
    1298 int & const rc = x;                                     �\C{// must be initialized}�
    1299 �&�rc = &x;                                                     �\C{// error, cannot change rc}�
    1300 const int & const crc = cx;                     �\C{// must be initialized}�
    1301 crc = 7;                                                        �\C{// error, cannot change cx}�
    1302 �&�crc = &cx;                                           �\C{// error, cannot change crc}�
    1303 \end{cfa}
    1304 Hence, for type �& const�, there is no pointer assignment, so �&rc = &x� is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
    1305 \begin{cfa}
    1306 int & const cr = *0;                            �\C{// where 0 is the int * zero}�
     1294const int cx = 5;                                       §\C{// cannot change cx;}§
     1295const int & cr = cx;                            §\C{// cannot change what cr points to}§
     1296®&®cr = &cx;                                            §\C{// can change cr}§
     1297cr = 7;                                                         §\C{// error, cannot change cx}§
     1298int & const rc = x;                                     §\C{// must be initialized}§
     1299®&®rc = &x;                                                     §\C{// error, cannot change rc}§
     1300const int & const crc = cx;                     §\C{// must be initialized}§
     1301crc = 7;                                                        §\C{// error, cannot change cx}§
     1302®&®crc = &cx;                                           §\C{// error, cannot change crc}§
     1303\end{cfa}
     1304Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
     1305\begin{cfa}
     1306int & const cr = *0;                            §\C{// where 0 is the int * zero}§
    13071307\end{cfa}
    13081308Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
     
    13111311cr = 5;
    13121312free( &cr );
    1313 cr = 7;                                                         �\C{// unsound pointer dereference}�
    1314 \end{cfa}
    1315 
    1316 The position of the �const� qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    1317 The �const� qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
     1313cr = 7;                                                         §\C{// unsound pointer dereference}§
     1314\end{cfa}
     1315
     1316The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     1317The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    13181318\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
    13191319\begin{quote2}
     
    13211321\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    13221322\begin{cfa}
    1323 �const� * �const� * const int ccp;
    1324 �const� & �const� & const int ccr;
     1323®const® * ®const® * const int ccp;
     1324®const® & ®const® & const int ccr;
    13251325\end{cfa}
    13261326&
    13271327\begin{cfa}
    1328 const int * �const� * �const� ccp;
     1328const int * ®const® * ®const® ccp;
    13291329
    13301330\end{cfa}
     
    13351335Finally, like pointers, references are usable and composable with other type operators and generators.
    13361336\begin{cfa}
    1337 int w, x, y, z, & ar[3] = { x, y, z }; �\C{// initialize array of references}�
    1338 &ar[1] = &w;                                            �\C{// change reference array element}�
    1339 typeof( ar[1] ) p;                                      �\C{// (gcc) is int, i.e., the type of referenced object}�
    1340 typeof( &ar[1] ) q;                                     �\C{// (gcc) is int \&, i.e., the type of reference}�
    1341 sizeof( ar[1] ) == sizeof( int );       �\C{// is true, i.e., the size of referenced object}�
    1342 sizeof( &ar[1] ) == sizeof( int *)      �\C{// is true, i.e., the size of a reference}�
    1343 \end{cfa}
    1344 
    1345 In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all �const� references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
     1337int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
     1338&ar[1] = &w;                                            §\C{// change reference array element}§
     1339typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
     1340typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
     1341sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
     1342sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
     1343\end{cfa}
     1344
     1345In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
    13461346Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
    13471347The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
     
    13571357Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
    13581358\begin{cfa}
    1359 int * p = &x;                                           �\C{// assign address of x}�
    1360 �int * p = x;�                                          �\C{// assign value of x}�
    1361 int & r = x;                                            �\C{// must have address of x}�
    1362 \end{cfa}
    1363 Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of �x� into a pointer is meaningful (again, a warning is usually given).
     1359int * p = &x;                                           §\C{// assign address of x}§
     1360®int * p = x;®                                          §\C{// assign value of x}§
     1361int & r = x;                                            §\C{// must have address of x}§
     1362\end{cfa}
     1363Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
    13641364Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
    13651365Note, this is strictly a convenience and safety feature for a programmer.
    1366 Hence, \CFA allows �r� to be assigned �x� because it infers a reference for �x�, by implicitly inserting a address-of operator, �&�, and it is an error to put an �&� because the types no longer match due to the implicit dereference.
    1367 Unfortunately, C allows �p� to be assigned with �&x� (address) or �x� (value), but most compilers warn about the latter assignment as being potentially incorrect.
     1366Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
     1367Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
    13681368Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
    13691369\begin{cfa}
    1370 int & f( int & r );                                     �\C{// reference parameter and return}�
    1371 z = f( x ) + f( y );                            �\C{// reference operator added, temporaries needed for call results}�
    1372 \end{cfa}
    1373 Within routine �f�, it is possible to change the argument by changing the corresponding parameter, and parameter �r� can be locally reassigned within �f�.
    1374 Since operator routine �?+?� takes its arguments by value, the references returned from �f� are used to initialize compiler generated temporaries with value semantics that copy from the references.
     1370int & f( int & r );                                     §\C{// reference parameter and return}§
     1371z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
     1372\end{cfa}
     1373Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
     1374Since operator routine ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.
    13751375\begin{cfa}
    13761376int temp1 = f( x ), temp2 = f( y );
     
    13801380otherwise references have the same syntactic  burden as pointers in these contexts.
    13811381
    1382 When a pointer/reference parameter has a �const� value (immutable), it is possible to pass literals and expressions.
    1383 \begin{cfa}
    1384 void f( �const� int & cr );
    1385 void g( �const� int * cp );
    1386 f( 3 );                   g( �&�3 );
    1387 f( x + y );             g( �&�(x + y) );
    1388 \end{cfa}
    1389 Here, the compiler passes the address to the literal 3 or the temporary for the expression �x + y�, knowing the argument cannot be changed through the parameter.
    1390 The �&� before the constant/expression for the pointer-type parameter (�g�) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg �scanf�).
    1391 Importantly, �&3� may not be equal to �&3�, where the references occur across calls because the temporaries maybe different on each call.
     1382When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
     1383\begin{cfa}
     1384void f( ®const® int & cr );
     1385void g( ®const® int * cp );
     1386f( 3 );                   g( ®&®3 );
     1387f( x + y );             g( ®&®(x + y) );
     1388\end{cfa}
     1389Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
     1390The ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
     1391Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
    13921392
    13931393\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.\footnote{
    1394 If whole program analysis is possible, and shows the parameter is not assigned, \ie it is �const�, the temporary is unnecessary.}
     1394If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
    13951395\begin{cfa}
    13961396void f( int & r );
    13971397void g( int * p );
    1398 f( 3 );                   g( �&�3 );            �\C{// compiler implicit generates temporaries}�
    1399 f( x + y );             g( �&�(x + y) );        �\C{// compiler implicit generates temporaries}�
     1398f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
     1399f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
    14001400\end{cfa}
    14011401Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
    1402 This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a �const� qualifier causes a cascade of type failures, requiring an unknown number of additional �const� qualifiers, until it is discovered a �const� qualifier cannot be added and all the �const� qualifiers must be removed.}
     1402This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.}
    14031403The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call.
    14041404
     
    14081408\begin{cfa}
    14091409void f( int i );
    1410 void (*fp)( int );                                      �\C{// routine pointer}�
    1411 fp = f;                                                         �\C{// reference initialization}�
    1412 fp = &f;                                                        �\C{// pointer initialization}�
    1413 fp = *f;                                                        �\C{// reference initialization}�
    1414 fp(3);                                                          �\C{// reference invocation}�
    1415 (*fp)(3);                                                       �\C{// pointer invocation}�
    1416 \end{cfa}
    1417 While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (�f�, �&f�, �*f�) without regard for type.
    1418 Instead, a routine object should be referenced by a �const� reference:
    1419 \begin{cfa}
    1420 �const� void (�&� fr)( int ) = f;       �\C{// routine reference}�
    1421 fr = ...                                                        �\C{// error, cannot change code}�
    1422 &fr = ...;                                                      �\C{// changing routine reference}�
    1423 fr( 3 );                                                        �\C{// reference call to f}�
    1424 (*fr)(3);                                                       �\C{// error, incorrect type}�
     1410void (*fp)( int );                                      §\C{// routine pointer}§
     1411fp = f;                                                         §\C{// reference initialization}§
     1412fp = &f;                                                        §\C{// pointer initialization}§
     1413fp = *f;                                                        §\C{// reference initialization}§
     1414fp(3);                                                          §\C{// reference invocation}§
     1415(*fp)(3);                                                       §\C{// pointer invocation}§
     1416\end{cfa}
     1417While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
     1418Instead, a routine object should be referenced by a ©const© reference:
     1419\begin{cfa}
     1420®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
     1421fr = ...                                                        §\C{// error, cannot change code}§
     1422&fr = ...;                                                      §\C{// changing routine reference}§
     1423fr( 3 );                                                        §\C{// reference call to f}§
     1424(*fr)(3);                                                       §\C{// error, incorrect type}§
    14251425\end{cfa}
    14261426because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
     
    14311431\subsection{Address-of Semantics}
    14321432
    1433 In C, �&E� is an rvalue for any expression �E�.
    1434 \CFA extends the �&� (address-of) operator as follows:
     1433In C, ©&E© is an rvalue for any expression ©E©.
     1434\CFA extends the ©&© (address-of) operator as follows:
    14351435\begin{itemize}
    14361436\item
    1437 if �R� is an \Index{rvalue} of type �T &$_1$...&$_r$� where $r \ge 1$ references (�&� symbols) than �&R� has type �T �*�&$_{\color{red}2}$...&$_{\color{red}r}$�, \ie �T� pointer with $r-1$ references (�&� symbols).
    1438 
    1439 \item
    1440 if �L� is an \Index{lvalue} of type �T &$_1$...&$_l$� where $l \ge 0$ references (�&� symbols) then �&L� has type �T �*�&$_{\color{red}1}$...&$_{\color{red}l}$�, \ie �T� pointer with $l$ references (�&� symbols).
     1437if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
     1438
     1439\item
     1440if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
    14411441\end{itemize}
    14421442The following example shows the first rule applied to different \Index{rvalue} contexts:
     
    14671467\setcounter{enumi}{-1}
    14681468\item
    1469 lvalue to rvalue conversion: �cv T� converts to �T�, which allows implicit variable dereferencing.
     1469lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
    14701470\begin{cfa}
    14711471int x;
    14721472x + 1;                  // lvalue variable (int) converts to rvalue for expression
    14731473\end{cfa}
    1474 An rvalue has no type qualifiers (�cv�), so the lvalue qualifiers are dropped.
     1474An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
    14751475\end{enumerate}
    14761476\CFA provides three new implicit conversion for reference types to simplify reference usage.
    14771477\begin{enumerate}
    14781478\item
    1479 reference to rvalue conversion: �cv T &� converts to �T�, which allows implicit reference dereferencing.
     1479reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
    14801480\begin{cfa}
    14811481int x, &r = x, f( int p );
    1482 x = �r� + f( �r� );  // lvalue reference converts to rvalue
    1483 \end{cfa}
    1484 An rvalue has no type qualifiers (�cv�), so the reference qualifiers are dropped.
    1485 
    1486 \item
    1487 lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to �cv2 T &�, which allows implicitly converting variables to references.
    1488 \begin{cfa}
    1489 int x, &r = �x�, f( int & p ); // lvalue variable (int) convert to reference (int &)
    1490 f( �x� );               // lvalue variable (int) convert to reference (int &)
    1491 \end{cfa}
    1492 Conversion can restrict a type, where �cv1� $\le$ �cv2�, \eg passing an �int� to a �const volatile int &�, which has low cost.
    1493 Conversion can expand a type, where �cv1� $>$ �cv2�, \eg passing a �const volatile int� to an �int &�, which has high cost (\Index{warning});
    1494 furthermore, if �cv1� has �const� but not �cv2�, a temporary variable is created to preserve the immutable lvalue.
    1495 
    1496 \item
    1497 rvalue to reference conversion: �T� converts to �cv T &�, which allows binding references to temporaries.
     1482x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
     1483\end{cfa}
     1484An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
     1485
     1486\item
     1487lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
     1488\begin{cfa}
     1489int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
     1490f( ®x® );               // lvalue variable (int) convert to reference (int &)
     1491\end{cfa}
     1492Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
     1493Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
     1494furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
     1495
     1496\item
     1497rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
    14981498\begin{cfa}
    14991499int x, & f( int & p );
    1500 f( �x + 3� );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
    1501 �&f�(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
     1500f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
     1501®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
    15021502\end{cfa}
    15031503In both case, modifications to the temporary are inaccessible (\Index{warning}).
    1504 Conversion expands the temporary-type with �cv�, which is low cost since the temporary is inaccessible.
     1504Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
    15051505\end{enumerate}
    15061506
     
    16711671The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    16721672\begin{cfa}
    1673 �[ int o1, int o2, char o3 ]� f( int i1, char i2, char i3 ) {
    1674         �\emph{routine body}�
    1675 }
    1676 \end{cfa}
    1677 where routine �f� has three output (return values) and three input parameters.
     1673®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
     1674        §\emph{routine body}§
     1675}
     1676\end{cfa}
     1677where routine ©f© has three output (return values) and three input parameters.
    16781678Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications.
    16791679
    1680 In detail, the brackets, �[]�, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
     1680In detail, the brackets, ©[]©, enclose the result type, where each return value is named and that name is a local variable of the particular return type.\footnote{
    16811681\Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
    16821682The value of each local return variable is automatically returned at routine termination.
    16831683Declaration qualifiers can only appear at the start of a routine definition, \eg:
    16841684\begin{cfa}
    1685 �extern� [ int x ] g( int y ) {�\,�}
     1685®extern® [ int x ] g( int y ) {§\,§}
    16861686\end{cfa}
    16871687Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
    16881688in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    16891689\begin{cfa}
    1690 [�\,�] g();                                                     �\C{// no input or output parameters}�
    1691 [ void ] g( void );                                     �\C{// no input or output parameters}�
     1690[§\,§] g();                                                     §\C{// no input or output parameters}§
     1691[ void ] g( void );                                     §\C{// no input or output parameters}§
    16921692\end{cfa}
    16931693
     
    17021702int (*f(x))[ 5 ] int x; {}
    17031703\end{cfa}
    1704 The string ``�int (*f(x))[ 5 ]�'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``�[ 5 ] int x�'' declares a \CFA style parameter x of type array of 5 integers.
    1705 Since the strings overlap starting with the open bracket, �[�, there is an ambiguous interpretation for the string.
     1704The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers.
     1705Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string.
    17061706As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity:
    17071707\begin{cfa}
    17081708typedef int foo;
    1709 int f( int (* foo) );                           �\C{// foo is redefined as a parameter name}�
    1710 \end{cfa}
    1711 The string ``�int (* foo)�'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
    1712 The redefinition of a type name in a parameter list is the only context in C where the character �*� can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name.
     1709int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
     1710\end{cfa}
     1711The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
     1712The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name.
    17131713The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
    17141714
    17151715C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    17161716\begin{cfa}
    1717 [ int ] f( * int, int * );                      �\C{// returns an integer, accepts 2 pointers to integers}�
    1718 [ * int, int * ] f( int );                      �\C{// returns 2 pointers to integers, accepts an integer}�
     1717[ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
     1718[ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
    17191719\end{cfa}
    17201720The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    17211721\begin{cfa}
    17221722#define ptoa( n, d ) int (*n)[ d ]
    1723 int f( ptoa( p, 5 ) ) ...                       �\C{// expands to int f( int (*p)[ 5 ] )}�
    1724 [ int ] f( ptoa( p, 5 ) ) ...           �\C{// expands to [ int ] f( int (*p)[ 5 ] )}�
     1723int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
     1724[ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
    17251725\end{cfa}
    17261726Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
     
    17291729\subsection{Named Return Values}
    17301730
    1731 \Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a �return� statement, as in:
     1731\Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
    17321732\begin{cfa}
    17331733int f() {
     
    17371737}
    17381738\end{cfa}
    1739 Because the value in the return variable is automatically returned when a \CFA routine terminates, the �return� statement \emph{does not} contain an expression, as in:
     1739Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
    17401740\newline
    17411741\begin{minipage}{\linewidth}
    17421742\begin{cfa}
    1743 �[ int x, int y ]� f() {
     1743®[ int x, int y ]® f() {
    17441744        int z;
    17451745        ... x = 0; ... y = z; ...
    1746         �return;�                                                       �\C{// implicitly return x, y}�
     1746        ®return;®                                                       §\C{// implicitly return x, y}§
    17471747}
    17481748\end{cfa}
    17491749\end{minipage}
    17501750\newline
    1751 When the return is encountered, the current values of �x� and �y� are returned to the calling routine.
    1752 As well, ``falling off the end'' of a routine without a �return� statement is permitted, as in:
     1751When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine.
     1752As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
    17531753\begin{cfa}
    17541754[ int x, int y ] f() {
    17551755        ...
    1756 }                                                                               �\C{// implicitly return x, y}�
    1757 \end{cfa}
    1758 In this case, the current values of �x� and �y� are returned to the calling routine just as if a �return� had been encountered.
     1756}                                                                               §\C{// implicitly return x, y}§
     1757\end{cfa}
     1758In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
    17591759
    17601760Named return values may be used in conjunction with named parameter values;
     
    17631763[ int x, int y ] f( int, x, int y ) {
    17641764        ...
    1765 }                                                                               �\C{// implicitly return x, y}�
     1765}                                                                               §\C{// implicitly return x, y}§
    17661766\end{cfa}
    17671767This notation allows the compiler to eliminate temporary variables in nested routine calls.
    17681768\begin{cfa}
    1769 [ int x, int y ] f( int, x, int y );    �\C{// prototype declaration}�
     1769[ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
    17701770int a, b;
    17711771[a, b] = f( f( f( a, b ) ) );
    17721772\end{cfa}
    17731773While the compiler normally ignores parameters names in prototype declarations, here they are used to eliminate temporary return-values by inferring that the results of each call are the inputs of the next call, and ultimately, the left-hand side of the assignment.
    1774 Hence, even without the body of routine �f� (separate compilation), it is possible to perform a global optimization across routine calls.
     1774Hence, even without the body of routine ©f© (separate compilation), it is possible to perform a global optimization across routine calls.
    17751775The compiler warns about naming inconsistencies between routine prototype and definition in this case, and behaviour is \Index{undefined} if the programmer is inconsistent.
    17761776
     
    17811781as well, parameter names are optional, \eg:
    17821782\begin{cfa}
    1783 [ int x ] f ();                                                 �\C{// returning int with no parameters}�
    1784 [ * int ] g (int y);                                    �\C{// returning pointer to int with int parameter}�
    1785 [ ] h ( int, char );                                    �\C{// returning no result with int and char parameters}�
    1786 [ * int, int ] j ( int );                               �\C{// returning pointer to int and int, with int parameter}�
     1783[ int x ] f ();                                                 §\C{// returning int with no parameters}§
     1784[ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
     1785[ ] h ( int, char );                                    §\C{// returning no result with int and char parameters}§
     1786[ * int, int ] j ( int );                               §\C{// returning pointer to int and int, with int parameter}§
    17871787\end{cfa}
    17881788This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
     
    18111811The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    18121812\begin{cfa}
    1813 * [ int x ] () fp;                                              �\C{// pointer to routine returning int with no parameters}�
    1814 * [ * int ] (int y) gp;                                 �\C{// pointer to routine returning pointer to int with int parameter}�
    1815 * [ ] (int,char) hp;                                    �\C{// pointer to routine returning no result with int and char parameters}�
    1816 * [ * int,int ] ( int ) jp;                             �\C{// pointer to routine returning pointer to int and int, with int parameter}�
     1813* [ int x ] () fp;                                              §\C{// pointer to routine returning int with no parameters}§
     1814* [ * int ] (int y) gp;                                 §\C{// pointer to routine returning pointer to int with int parameter}§
     1815* [ ] (int,char) hp;                                    §\C{// pointer to routine returning no result with int and char parameters}§
     1816* [ * int,int ] ( int ) jp;                             §\C{// pointer to routine returning pointer to int and int, with int parameter}§
    18171817\end{cfa}
    18181818While parameter names are optional, \emph{a routine name cannot be specified};
    18191819for example, the following is incorrect:
    18201820\begin{cfa}
    1821 * [ int x ] f () fp;                                    �\C{// routine name "f" is not allowed}�
     1821* [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
    18221822\end{cfa}
    18231823
     
    18421842whereas a named (keyword) call may be:
    18431843\begin{cfa}
    1844 p( z : 3, x : 4, y : 7 );       �\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}�
     1844p( z : 3, x : 4, y : 7 );       §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
    18451845\end{cfa}
    18461846Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
     
    18591859For example, the following routine prototypes and definition are all valid.
    18601860\begin{cfa}
    1861 void p( int, int, int );                        �\C{// equivalent prototypes}�
     1861void p( int, int, int );                        §\C{// equivalent prototypes}§
    18621862void p( int x, int y, int z );
    18631863void p( int y, int x, int z );
    18641864void p( int z, int y, int x );
    1865 void p( int q, int r, int s ) {}        �\C{// match with this definition}�
     1865void p( int q, int r, int s ) {}        §\C{// match with this definition}§
    18661866\end{cfa}
    18671867Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
     
    18701870
    18711871Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
    1872 For example, it is technically possible to disambiguate between these two overloaded definitions of �f� based on named arguments at the call site:
     1872For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
    18731873\begin{cfa}
    18741874int f( int i, int j );
    18751875int f( int x, double y );
    18761876
    1877 f( j : 3, i : 4 );                              �\C{// 1st f}�
    1878 f( x : 7, y : 8.1 );                    �\C{// 2nd f}�
    1879 f( 4, 5 );                                              �\C{// ambiguous call}�
     1877f( j : 3, i : 4 );                              §\C{// 1st f}§
     1878f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
     1879f( 4, 5 );                                              §\C{// ambiguous call}§
    18801880\end{cfa}
    18811881However, named arguments compound routine resolution in conjunction with conversions:
    18821882\begin{cfa}
    1883 f( i : 3, 5.7 );                                �\C{// ambiguous call ?}�
     1883f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
    18841884\end{cfa}
    18851885Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
     
    18951895the allowable positional calls are:
    18961896\begin{cfa}
    1897 p();                                                    �\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}�
    1898 p( 4 );                                                 �\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}�
    1899 p( 4, 4 );                                              �\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}�
    1900 p( 4, 4, 4 );                                   �\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}�
     1897p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
     1898p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     1899p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     1900p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
    19011901// empty arguments
    1902 p(  , 4, 4 );                                   �\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}�
    1903 p( 4,  , 4 );                                   �\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}�
    1904 p( 4, 4,   );                                   �\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}�
    1905 p( 4,  ,   );                                   �\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}�
    1906 p(  , 4,   );                                   �\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}�
    1907 p(  ,  , 4 );                                   �\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}�
    1908 p(  ,  ,   );                                   �\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}�
     1902p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
     1903p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
     1904p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     1905p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     1906p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
     1907p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
     1908p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    19091909\end{cfa}
    19101910Here the missing arguments are inserted from the default values in the parameter list.
     
    19301930Default values may only appear in a prototype versus definition context:
    19311931\begin{cfa}
    1932 void p( int x, int y = 2, int z = 3 );          �\C{// prototype: allowed}�
    1933 void p( int, int = 2, int = 3 );                        �\C{// prototype: allowed}�
    1934 void p( int x, int y = 2, int z = 3 ) {}        �\C{// definition: not allowed}�
     1932void p( int x, int y = 2, int z = 3 );          §\C{// prototype: allowed}§
     1933void p( int, int = 2, int = 3 );                        §\C{// prototype: allowed}§
     1934void p( int x, int y = 2, int z = 3 ) {}        §\C{// definition: not allowed}§
    19351935\end{cfa}
    19361936The reason for this restriction is to allow separate compilation.
     
    19471947\begin{cfa}
    19481948p( int x, int y, int z, ... );
    1949 p( 1, 4, 5, 6, z : 3, y : 2 ); �\C{// assume p( /* positional */, ... , /* named */ );}�
    1950 p( 1, z : 3, y : 2, 4, 5, 6 ); �\C{// assume p( /* positional */, /* named */, ... );}�
     1949p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
     1950p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
    19511951\end{cfa}
    19521952In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin.
     
    19571957\begin{cfa}
    19581958void p( int x, int y = 2, int z = 3... );
    1959 p( 1, 4, 5, 6, z : 3 );         �\C{// assume p( /* positional */, ... , /* named */ );}�
    1960 p( 1, z : 3, 4, 5, 6 );         �\C{// assume p( /* positional */, /* named */, ... );}�
     1959p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
     1960p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
    19611961\end{cfa}
    19621962The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
     
    19881988Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
    19891989\begin{cfa}
    1990 p( 1, /* default */, 5 );               �\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}�
     1990p( 1, /* default */, 5 );               §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
    19911991\end{cfa}
    19921992
     
    20012001\begin{cfa}
    20022002struct {
    2003         int f1;                                 �\C{// named field}�
    2004         int f2 : 4;                             �\C{// named field with bit field size}�
    2005         int : 3;                                �\C{// unnamed field for basic type with bit field size}�
    2006         int ;                                   �\C{// disallowed, unnamed field}�
    2007         int *;                                  �\C{// disallowed, unnamed field}�
    2008         int (*)( int );                 �\C{// disallowed, unnamed field}�
     2003        int f1;                                 §\C{// named field}§
     2004        int f2 : 4;                             §\C{// named field with bit field size}§
     2005        int : 3;                                §\C{// unnamed field for basic type with bit field size}§
     2006        int ;                                   §\C{// disallowed, unnamed field}§
     2007        int *;                                  §\C{// disallowed, unnamed field}§
     2008        int (*)( int );                 §\C{// disallowed, unnamed field}§
    20092009};
    20102010\end{cfa}
     
    20142014\begin{cfa}
    20152015struct {
    2016         int , , ;                               �\C{// 3 unnamed fields}�
     2016        int , , ;                               §\C{// 3 unnamed fields}§
    20172017}
    20182018\end{cfa}
     
    20612061        struct T t;
    20622062} s;
    2063 
     2063       
    20642064
    20652065
     
    20822082
    20832083int fred() {
    2084         s.t.c = �S.�R;  // type qualification
    2085         struct �S.�T t = { �S.�R, 1, 2 };
    2086         enum �S.�C c;
    2087         union �S.T.�U u;
     2084        s.t.c = ®S.®R;  // type qualification
     2085        struct ®S.®T t = { ®S.®R, 1, 2 };
     2086        enum ®S.®C c;
     2087        union ®S.T.®U u;
    20882088}
    20892089\end{cfa}
     
    20922092\label{f:TypeNestingQualification}
    20932093\end{figure}
    2094 In the left example in C, types �C�, �U� and �T� are implicitly hoisted outside of type �S� into the containing block scope.
    2095 In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``�.�'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``�::�''.
     2094In the left example in C, types ©C©, ©U© and ©T© are implicitly hoisted outside of type ©S© into the containing block scope.
     2095In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``©.©'' for type qualification, as does \Index*{Java}, rather than the \CC type-selection operator ``©::©''.
    20962096
    20972097
     
    21082108const unsigned int size = 5;
    21092109int ia[size];
    2110 ...                                             �\C{// assign values to array ia}�
    2111 qsort( ia, size );              �\C{// sort ascending order using builtin ?<?}�
     2110...                                             §\C{// assign values to array ia}§
     2111qsort( ia, size );              §\C{// sort ascending order using builtin ?<?}§
    21122112{
    2113         �int ?<?( int x, int y ) { return x > y; }� �\C{// nested routine}�
    2114         qsort( ia, size );      �\C{// sort descending order by local redefinition}�
     2113        ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
     2114        qsort( ia, size );      §\C{// sort descending order by local redefinition}§
    21152115}
    21162116\end{cfa}
     
    21202120The following program in undefined in \CFA (and Indexc{gcc})
    21212121\begin{cfa}
    2122 [* [int]( int )] foo() {                �\C{// int (*foo())( int )}�
    2123         int �i� = 7;
     2122[* [int]( int )] foo() {                §\C{// int (*foo())( int )}§
     2123        int ®i® = 7;
    21242124        int bar( int p ) {
    2125                 �i� += 1;                               �\C{// dependent on local variable}�
    2126                 sout | �i� | endl;
     2125                ®i® += 1;                               §\C{// dependent on local variable}§
     2126                sout | ®i® | endl;
    21272127        }
    2128         return bar;                                     �\C{// undefined because of local dependence}�
     2128        return bar;                                     §\C{// undefined because of local dependence}§
    21292129}
    21302130int main() {
    2131         * [int]( int ) fp = foo();      �\C{// int (*fp)( int )}�
     2131        * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
    21322132        sout | fp( 3 ) | endl;
    21332133}
    21342134\end{cfa}
    2135 because
     2135because 
    21362136
    21372137Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine.
     
    21452145The general syntax of a lexical list is:
    21462146\begin{cfa}
    2147 [ �\emph{exprlist}� ]
    2148 \end{cfa}
    2149 where �$\emph{exprlist}$� is a list of one or more expressions separated by commas.
    2150 The brackets, �[]�, allow differentiating between lexical lists and expressions containing the C comma operator.
     2147[ §\emph{exprlist}§ ]
     2148\end{cfa}
     2149where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
     2150The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator.
    21512151The following are examples of lexical lists:
    21522152\begin{cfa}
     
    21552155[ v+w, x*y, 3.14159, f() ]
    21562156\end{cfa}
    2157 Tuples are permitted to contain sub-tuples (\ie nesting), such as �[ [ 14, 21 ], 9 ]�, which is a 2-element tuple whose first element is itself a tuple.
     2157Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.
    21582158Note, a tuple is not a record (structure);
    21592159a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1).
     
    21652165The general syntax of a tuple type is:
    21662166\begin{cfa}
    2167 [ �\emph{typelist}� ]
    2168 \end{cfa}
    2169 where �$\emph{typelist}$� is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
     2167[ §\emph{typelist}§ ]
     2168\end{cfa}
     2169where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications.
    21702170Examples of tuple types include:
    21712171\begin{cfa}
    21722172[ unsigned int, char ]
    21732173[ double, double, double ]
    2174 [ * int, int * ]                �\C{// mix of CFA and ANSI}�
     2174[ * int, int * ]                §\C{// mix of CFA and ANSI}§
    21752175[ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ]
    21762176\end{cfa}
    2177 Like tuples, tuple types may be nested, such as �[ [ int, int ], int ]�, which is a 2-element tuple type whose first element is itself a tuple type.
     2177Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type.
    21782178
    21792179Examples of declarations using tuple types are:
    21802180\begin{cfa}
    2181 [ int, int ] x;                 �\C{// 2 element tuple, each element of type int}�
    2182 * [ char, char ] y;             �\C{// pointer to a 2 element tuple}�
     2181[ int, int ] x;                 §\C{// 2 element tuple, each element of type int}§
     2182* [ char, char ] y;             §\C{// pointer to a 2 element tuple}§
    21832183[ [ int, int ] ] z ([ int, int ]);
    21842184\end{cfa}
     
    22112211tuple does not have structure like a record; a tuple is simply converted into a list of components.
    22122212\begin{rationale}
    2213 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as �g( f() )� is not supported.
     2213The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported.
    22142214Using a temporary variable to store the  results of the inner routine and then passing this variable to the outer routine works, however.
    22152215\end{rationale}
     
    22402240\begin{rationale}
    22412241Unfortunately, C's syntax for subscripts precluded treating them as tuples.
    2242 The C subscript list has the form �[i][j]...� and not �[i, j, ...]�.
    2243 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg �f[g()]� always means a single subscript value because there is only one set of brackets.
    2244 Fixing this requires a major change to C because the syntactic form �M[i, j, k]� already has a particular meaning: �i, j, k� is a comma expression.
     2242The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
     2243Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[g()]© always means a single subscript value because there is only one set of brackets.
     2244Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression.
    22452245\end{rationale}
    22462246
     
    22612261[ a, b, c, d ] = w
    22622262\end{cfa}
    2263 �w� is implicitly opened to yield a tuple of four values, which are then assigned individually.
     2263©w© is implicitly opened to yield a tuple of four values, which are then assigned individually.
    22642264
    22652265A \newterm{flattening coercion} coerces a nested tuple, \ie a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:
     
    22692269First the right-hand tuple is flattened and then the values are assigned individually.
    22702270Flattening is also performed on tuple types.
    2271 For example, the type �[ int, [ int, int ], int ]� can be coerced, using flattening, into the type �[ int, int, int, int ]�.
     2271For example, the type ©[ int, [ int, int ], int ]© can be coerced, using flattening, into the type ©[ int, int, int, int ]©.
    22722272
    22732273A \newterm{structuring coercion} is the opposite of flattening;
    22742274a tuple is structured into a more complex nested tuple.
    2275 For example, structuring the tuple �[ 1, 2, 3, 4 ]� into the tuple �[ 1, [ 2, 3 ], 4 ]� or the tuple type �[ int, int, int, int ]� into the tuple type �[ int, [ int, int ], int ]�.
     2275For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©.
    22762276In the following example, the last assignment illustrates all the tuple coercions:
    22772277\begin{cfa}
    22782278[ int, int, int, int ] w = [ 1, 2, 3, 4 ];
    22792279int x = 5;
    2280 [ x, w ] = [ w, x ];            �\C{// all four tuple coercions}�
     2280[ x, w ] = [ w, x ];            §\C{// all four tuple coercions}§
    22812281\end{cfa}
    22822282Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values;
    2283 therefore, the right-hand tuple is now the tuple �[ [ 1, 2, 3, 4 ], 5 ]�.
    2284 This tuple is then flattened, yielding �[ 1, 2, 3, 4, 5 ]�, which is structured into �[ 1, [ 2, 3, 4, 5 ] ]� to match the tuple type of the left-hand side.
    2285 The tuple �[ 2, 3, 4, 5 ]� is then closed to create a tuple value.
    2286 Finally, �x� is assigned �1� and �w� is assigned the tuple value using multiple assignment (see Section 14).
     2283therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©.
     2284This tuple is then flattened, yielding ©[ 1, 2, 3, 4, 5 ]©, which is structured into ©[ 1, [ 2, 3, 4, 5 ] ]© to match the tuple type of the left-hand side.
     2285The tuple ©[ 2, 3, 4, 5 ]© is then closed to create a tuple value.
     2286Finally, ©x© is assigned ©1© and ©w© is assigned the tuple value using multiple assignment (see Section 14).
    22872287\begin{rationale}
    22882288A possible additional language extension is to use the structuring coercion for tuples to initialize a complex record with a tuple.
     
    22952295Mass assignment has the following form:
    22962296\begin{cfa}
    2297 [ �\emph{lvalue}�, ... , �\emph{lvalue}� ] = �\emph{expr}�;
     2297[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
    22982298\end{cfa}
    22992299\index{lvalue}
    23002300The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement.
    2301 �$\emph{expr}$� is any standard arithmetic expression.
     2301©$\emph{expr}$© is any standard arithmetic expression.
    23022302Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
    23032303
     
    23252325*a1 = t; *a2 = t; *a3 = t;
    23262326\end{cfa}
    2327 The temporary �t� is necessary to store the value of the expression to eliminate conversion issues.
     2327The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues.
    23282328The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned.
    2329 In this case, �y[i]� uses the previous value of �i� and not the new value set at the beginning of the mass assignment.
     2329In this case, ©y[i]© uses the previous value of ©i© and not the new value set at the beginning of the mass assignment.
    23302330
    23312331
     
    23352335Multiple assignment has the following form:
    23362336\begin{cfa}
    2337 [ �\emph{lvalue}�, ... , �\emph{lvalue}� ] = [ �\emph{expr}�, ... , �\emph{expr}� ];
     2337[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
    23382338\end{cfa}
    23392339\index{lvalue}
     
    23442344[ x, y, z ] = [ 1, 2, 3 ];
    23452345\end{cfa}
    2346 Here, the values �1�, �2� and �3� are assigned, respectively, to the variables �x�, �y� and �z�.
     2346Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©.
    23472347 A more complex example is:
    23482348\begin{cfa}
    23492349[ i, y[ i ], z ] = [ 1, i, a + b ];
    23502350\end{cfa}
    2351 Here, the values �1�, �i� and �a + b� are assigned to the variables �i�, �y[i]� and �z�, respectively.
     2351Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively.
    23522352 Note, the parallel semantics of
    23532353multiple assignment ensures:
     
    23552355[ x, y ] = [ y, x ];
    23562356\end{cfa}
    2357 correctly interchanges (swaps) the values stored in �x� and �y�.
     2357correctly interchanges (swaps) the values stored in ©x© and ©y©.
    23582358The following cases are errors:
    23592359\begin{cfa}
     
    23662366both these examples produce indeterminate results:
    23672367\begin{cfa}
    2368 f( x++, x++ );                          �\C{// C routine call with side effects in arguments}�
    2369 [ v1, v2 ] = [ x++, x++ ];      �\C{// side effects in righthand side of multiple assignment}�
     2368f( x++, x++ );                          §\C{// C routine call with side effects in arguments}§
     2369[ v1, v2 ] = [ x++, x++ ];      §\C{// side effects in righthand side of multiple assignment}§
    23702370\end{cfa}
    23712371
     
    23762376Cascade assignment has the following form:
    23772377\begin{cfa}
    2378 �\emph{tuple}� = �\emph{tuple}� = ... = �\emph{tuple}�;
     2378§\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§;
    23792379\end{cfa}
    23802380and it has the same parallel semantics as for mass and multiple assignment.
     
    23942394Its general form is:
    23952395\begin{cfa}
    2396 �\emph{expr}� . [ �\emph{fieldlist}� ]
    2397 �\emph{expr}� -> [ �\emph{fieldlist}� ]
    2398 \end{cfa}
    2399 \emph{expr} is any expression yielding a value of type record, \eg �struct�, �union�.
     2396§\emph{expr}§ . [ §\emph{fieldlist}§ ]
     2397§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
     2398\end{cfa}
     2399\emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
    24002400Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    24012401A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
     
    24072407        double f4;
    24082408} v;
    2409 v.[ f3, f1, f2 ] = ['x', 11, 17 ];      �\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}�
    2410 f( v.[ f3, f1, f2 ] );                          �\C{// equivalent to f( v.f3, v.f1, v.f2 )}�
     2409v.[ f3, f1, f2 ] = ['x', 11, 17 ];      §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§
     2410f( v.[ f3, f1, f2 ] );                          §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§
    24112411\end{cfa}
    24122412Note, the fields appearing in a record-field tuple may be specified in any order;
    24132413also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple.
    24142414
    2415 If a field of a �struct� is itself another �struct�, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
     2415If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example:
    24162416\begin{cfa}
    24172417struct inner {
     
    24422442\begin{cfa}
    24432443int x = 1, y = 2, z = 3;
    2444 sout | x �|� y �|� z | endl;
     2444sout | x ®|® y ®|® z | endl;
    24452445\end{cfa}
    24462446&
    24472447\begin{cfa}
    24482448
    2449 cout << x �<< " "� << y �<< " "� << z << endl;
     2449cout << x ®<< " "® << y ®<< " "® << z << endl;
    24502450\end{cfa}
    24512451\\
    2452 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2453 1� �2� �3
     2452\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     24531® ®2® ®3
    24542454\end{cfa}
    24552455&
    2456 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     2456\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    245724571 2 3
    24582458\end{cfa}
     
    24612461The \CFA form has half the characters of the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators.
    24622462Similar simplification occurs for \Index{tuple} I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''.
    2463 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2464 [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 3, [ 4, 5 ] ];
    2465 sout | t1 | t2 | endl;                                  �\C{// print tuples}�
    2466 \end{cfa}
    2467 \begin{cfa}[mathescape=off,showspaces=true,belowskip=0pt]
    2468 1�, �2�, �3 3�, �4�, �5
     2463\begin{cfa}
     2464[int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 4, [ 5, 6 ] ];
     2465sout | t1 | t2 | endl;                                  §\C{// print tuples}§
     2466\end{cfa}
     2467\begin{cfa}[showspaces=true,aboveskip=0pt]
     24681®, ®2®, ®3 4®, ®5®, ®6
    24692469\end{cfa}
    24702470Finally, \CFA uses the logical-or operator for I/O as it is the lowest-priority overloadable operator, other than assignment.
     
    24812481&
    24822482\begin{cfa}
    2483 cout << x * 3 << y + 1 << �(�z << 2�)� << �(�x == y�)� << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
     2483cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << (x | y) << (x || y) << (x > z ? 1 : 2) << endl;
    24842484\end{cfa}
    24852485\\
    24862486&
    2487 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     2487\begin{cfa}[showspaces=true,aboveskip=0pt]
    248824883 3 12 0 3 1 2
    24892489\end{cfa}
     
    25032503sout | 1 | 2 | 3 | endl;
    25042504\end{cfa}
    2505 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     2505\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    250625061 2 3
    25072507\end{cfa}
     
    25232523
    25242524\item
    2525 A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$�����@
     2525A separator does not appear before a C string starting with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@
    25262526%$
    25272527\begin{cfa}[mathescape=off]
    2528 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x �" | 6 | "x �"
    2529                 | 7 | "x �" | 8 | "x �" | 9 | "x �" | 10 | endl;
     2528sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
     2529                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
    25302530\end{cfa}
    25312531%$
    25322532\begin{cfa}[mathescape=off,basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2533 x �(�1 x �[�2 x �{�3 x �=�4 x �$�5 x ���6 x ���7 x ���8 x ���9 x ���10
     2533x ®(®1 x ®[®2 x ®{®3 x ®=®4 x ®$®5 x ®£®6 x ®¥®7 x ®¡®8 x ®¿®9 x ®«®10
    25342534\end{cfa}
    25352535%$
    2536 where \lstinline[basicstyle=\tt]@��@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@�@ is an opening citation mark.
    2537 
    2538 \item
    2539 {\lstset{language=CFA,deletedelim=**[is][]{�}{�}}
    2540 A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%��@
     2536where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark.
     2537
     2538\item
     2539{\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}}
     2540A seperator does not appear after a C string ending with the (extended) \Index*{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@
    25412541\begin{cfa}[belowskip=0pt]
    25422542sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
    2543                 | 7 | "� x" | 8 | "� x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
     2543                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
    25442544\end{cfa}
    25452545\begin{cfa}[basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2546 1�,� x 2�.� x 3�;� x 4�!� x 5�?� x 6�%� x 7�\color{red}\textcent� x 8��� x 9�)� x 10�]� x 11�}� x
     25461®,® x 2®.® x 3®;® x 4®!® x 5®?® x 6®%® x 7§\color{red}\textcent§ x 8®»® x 9®)® x 10®]® x 11®}® x
    25472547\end{cfa}}%
    2548 where \lstinline[basicstyle=\tt]@@ is a closing citation mark.
     2548where \lstinline[basicstyle=\tt]@»@ is a closing citation mark.
    25492549
    25502550\item
     
    25542554\end{cfa}
    25552555\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
    2556 x�`�1�`�x�\color{red}\texttt{'}�2�\color{red}\texttt{'}�x�\color{red}\texttt{"}�3�\color{red}\texttt{"}�x�:�4�:�x� �5� �x�      �6�     �x
     2556x®`®1®`®x§\color{red}\texttt{'}§2§\color{red}\texttt{'}§x§\color{red}\texttt{"}§3§\color{red}\texttt{"}§x®:®4®:®x® ®5® ®x®      ®6®     ®x
    25572557\end{cfa}
    25582558
     
    25602560If a space is desired before or after one of the special string start/end characters, simply insert a space.
    25612561\begin{cfa}[belowskip=0pt]
    2562 sout | "x (�\color{red}\texttt{\textvisiblespace}�" | 1 | "�\color{red}\texttt{\textvisiblespace}�) x" | 2 | "�\color{red}\texttt{\textvisiblespace}�, x" | 3 | "�\color{red}\texttt{\textvisiblespace}�:x:�\color{red}\texttt{\textvisiblespace}�" | 4 | endl;
     2562sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl;
    25632563\end{cfa}
    25642564\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]
    2565 x (� �1� �) x 2� �, x 3� �:x:� �4
     2565x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4
    25662566\end{cfa}
    25672567\end{enumerate}
     
    25702570\subsection{Manipulator}
    25712571
    2572 The following routines and \CC-style \Index{manipulator}s control implicit seperation.
     2572The following \CC-style \Index{manipulator}s and routines control implicit seperation.
    25732573\begin{enumerate}
    25742574\item
    2575 Routines \Indexc{sepSet}\index{manipulator!sepSet@�sepSet�} and \Indexc{sepGet}\index{manipulator!sepGet@�sepGet�} set and get the separator string.
    2576 The separator string can be at most 16 characters including the �'\0'� string terminator (15 printable characters).
    2577 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2578 sepSet( sout, ", $" );                                          �\C{// set separator from " " to ", \$"}�
    2579 sout | 1 | 2 | 3 | " \"" | �sepGet( sout )� | "\"" | endl;
     2575Routines \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sep}\index{manipulator!sep@©sep©}/\Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string.
     2576The separator string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
     2577\begin{cfa}[mathescape=off,belowskip=0pt]
     2578sepSet( sout, ", $" );                                          §\C{// set separator from " " to ", \$"}§
     2579sout | 1 | 2 | 3 | " \"" | ®sep® | "\"" | endl;
    25802580\end{cfa}
    25812581%$
    25822582\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
    2583 1�, $�2�, $�3 �", $"�
     25831®, $®2®, $®3 ®", $"®
    25842584\end{cfa}
    25852585%$
    2586 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2587 sepSet( sout, " " );                                            �\C{// reset separator to " "}�
    2588 sout | 1 | 2 | 3 | " \"" | �sepGet( sout )� | "\"" | endl;
    2589 \end{cfa}
    2590 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
    2591 1� �2� �3 �" "�
    2592 \end{cfa}
    2593 
    2594 \item
    2595 Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@�sepSetTuple�} and \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@�sepGetTuple�} get and set the tuple separator-string.
    2596 The tuple separator-string can be at most 16 characters including the �'\0'� string terminator (15 printable characters).
    2597 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2598 sepSetTuple( sout, " " );                                       �\C{// set tuple separator from ", " to " "}�
    2599 sout | t1 | t2 | " \"" | �sepGetTuple( sout )� | "\"" | endl;
    2600 \end{cfa}
    2601 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
    2602 1 2 3 4 �" "�
    2603 \end{cfa}
    2604 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2605 sepSetTuple( sout, ", " );                                      �\C{// reset tuple separator to ", "}�
    2606 sout | t1 | t2 | " \"" | �sepGetTuple( sout )� | "\"" | endl;
    2607 \end{cfa}
    2608 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt]
    2609 1, 2, 3, 4 �", "�
    2610 \end{cfa}
    2611 
    2612 \item
    2613 Manipulators \Indexc{sepOn}\index{manipulator!sepOn@�sepOn�} and \Indexc{sepOff}\index{manipulator!sepOff@�sepOff�} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
    2614 \begin{cfa}[mathescape=off,belowskip=0pt]
    2615 sout | sepOn | 1 | 2 | 3 | sepOn | endl;        �\C{// separator at start/end of line}�
    2616 \end{cfa}
    2617 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2618 � �1 2 3� �
    2619 \end{cfa}
    2620 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2621 sout | 1 | sepOff | 2 | 3 | endl;                       �\C{// locally turn off implicit separator}�
    2622 \end{cfa}
    2623 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2624 12 3
    2625 \end{cfa}
    2626 The tuple separator also responses to being turned on and off.
    2627 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2628 sout | sepOn | t1 | sepOff | t2 | endl;         �\C{// locally turn on/off implicit separation}�
    2629 \end{cfa}
    2630 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2631 , 1, 23, 4
    2632 \end{cfa}
    2633 Notice a tuple seperator starts the line because the next item is a tuple.
    2634 
    2635 \item
    2636 Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@�sepDisable�} and \Indexc{sepEnable}\index{manipulator!sepEnable@�sepEnable�} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.
    2637 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2638 sout | sepDisable | 1 | 2 | 3 | endl;           �\C{// globally turn off implicit separation}�
    2639 \end{cfa}
    2640 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
     2586\begin{cfa}[belowskip=0pt]
     2587sepSet( sout, " " );                                            §\C{// reset separator to " "}§
     2588sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl;
     2589\end{cfa}
     2590\begin{cfa}[showspaces=true,aboveskip=0pt]
     25911® ®2® ®3 ®" "®
     2592\end{cfa}
     2593©sepGet© can be used to store a separator and then restore it:
     2594\begin{cfa}[belowskip=0pt]
     2595char store[®sepSize®];                                          §\C{// sepSize is the maximum separator size}§
     2596strcpy( store, sepGet( sout ) );
     2597sepSet( sout, "_" );
     2598sout | 1 | 2 | 3 | endl;
     2599\end{cfa}
     2600\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     26011®_®2®_®3
     2602\end{cfa}
     2603\begin{cfa}[belowskip=0pt]
     2604sepSet( sout, store );
     2605sout | 1 | 2 | 3 | endl;
     2606\end{cfa}
     2607\begin{cfa}[showspaces=true,aboveskip=0pt]
     26081® ®2® ®3
     2609\end{cfa}
     2610
     2611\item
     2612Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepTuple}\index{manipulator!sepTuple@©sepTuple©}/\Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string.
     2613The tuple separator-string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters).
     2614\begin{cfa}[belowskip=0pt]
     2615sepSetTuple( sout, " " );                                       §\C{// set tuple separator from ", " to " "}§
     2616sout | t1 | t2 | " \"" | ®sepTuple® | "\"" | endl;
     2617\end{cfa}
     2618\begin{cfa}[showspaces=true,aboveskip=0pt]
     26191 2 3 4 5 6 ®" "®
     2620\end{cfa}
     2621\begin{cfa}[belowskip=0pt]
     2622sepSetTuple( sout, ", " );                                      §\C{// reset tuple separator to ", "}§
     2623sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl;
     2624\end{cfa}
     2625\begin{cfa}[showspaces=true,aboveskip=0pt]
     26261, 2, 3 4, 5, 6 ®", "®
     2627\end{cfa}
     2628As for ©sepGet©, ©sepGetTuple© can be use to store a tuple separator and then restore it.
     2629
     2630\item
     2631Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items.
     2632\begin{cfa}[belowskip=0pt]
     2633sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// globally turn off implicit separator}§
     2634\end{cfa}
     2635\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
    26412636123
    26422637\end{cfa}
    2643 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2644 sout | 1 | �sepOn� | 2 | 3 | endl;                      �\C{// locally turn on implicit separator}�
    2645 \end{cfa}
    2646 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    2647 1� �23
    2648 \end{cfa}
    2649 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    2650 sout | sepEnable | 1 | 2 | 3 | endl;            �\C{// globally turn on implicit separation}�
     2638\begin{cfa}[belowskip=0pt]
     2639sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// globally turn on implicit separator}§
    26512640\end{cfa}
    26522641\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    265326421 2 3
    26542643\end{cfa}
     2644
     2645\item
     2646Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item.
     2647\begin{cfa}[belowskip=0pt]
     2648sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// locally turn off implicit separator}§
     2649\end{cfa}
     2650\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     265112 3
     2652\end{cfa}
     2653\begin{cfa}[belowskip=0pt]
     2654sout | sepDisable | 1 | sepOn | 2 | 3 | endl; §\C{// locally turn on implicit separator}§
     2655\end{cfa}
     2656\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     26571 23
     2658\end{cfa}
     2659The tuple separator also responses to being turned on and off.
     2660\begin{cfa}[belowskip=0pt]
     2661sout | t1 | sepOff | t2 | endl;                         §\C{// locally turn on/off implicit separator}§
     2662\end{cfa}
     2663\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     26641, 2, 34, 5, 6
     2665\end{cfa}
     2666©sepOn© \emph{cannot} be used to start/end a line with a separator because separators do not appear at the start/end of a line;
     2667use ©sep© to accomplish this functionality.
     2668\begin{cfa}[belowskip=0pt]
     2669sout | sepOn | 1 | 2 | 3 | sepOn | endl ;       §\C{// sepOn does nothing at start/end of line}§
     2670\end{cfa}
     2671\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     26721 2 3
     2673\end{cfa}
     2674\begin{cfa}[belowskip=0pt]
     2675sout | sep | 1 | 2 | 3 | sep | endl ;           §\C{// use sep to print separator at start/end of line}§
     2676\end{cfa}
     2677\begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt]
     2678® ®1 2 3® ®
     2679\end{cfa}
    26552680\end{enumerate}
    26562681
    26572682\begin{comment}
    26582683#include <fstream>
     2684#include <string.h>                                                                             // strcpy
    26592685
    26602686int main( void ) {
    26612687        int x = 1, y = 2, z = 3;
    26622688        sout | x | y | z | endl;
    2663         [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 3, [ 4, 5 ] ];
     2689        [int, [ int, int ] ] t1 = [ 1, [ 2, 3 ] ], t2 = [ 4, [ 5, 6 ] ];
    26642690        sout | t1 | t2 | endl;                                          // print tuples
    26652691        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
     
    26672693        sout | '1' | '2' | '3' | endl;
    26682694        sout | 1 | "" | 2 | "" | 3 | endl;
    2669         sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x �" | 6 | "x �"
    2670                 | 7 | "x �" | 8 | "x �" | 9 | "x �" | 10 | endl;
     2695        sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥"
     2696                | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl;
    26712697        sout | 1 | ", x" | 2 | ". x" | 3 | "; x" | 4 | "! x" | 5 | "? x" | 6 | "% x"
    2672                 | 7 | "� x" | 8 | "� x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
     2698                | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl;
    26732699        sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl;
    26742700        sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl;
    26752701
    26762702        sepSet( sout, ", $" );                                          // set separator from " " to ", $"
    2677         sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
     2703        sout | 1 | 2 | 3 | " \"" | sep | "\"" | endl;
    26782704        sepSet( sout, " " );                                            // reset separator to " "
    26792705        sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl;
    26802706
    2681         sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
    2682         sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn off implicit separator
    2683 
    2684         sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separation
    2685         sout | 1 | sepOn | 2 | 3 | endl;                        // locally turn on implicit separator
    2686         sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separation
     2707        char store[sepSize];
     2708        strcpy( store, sepGet( sout ) );
     2709        sepSet( sout, "_" );
     2710        sout | 1 | 2 | 3 | endl;
     2711        sepSet( sout, store );
     2712        sout | 1 | 2 | 3 | endl;
    26872713
    26882714        sepSetTuple( sout, " " );                                       // set tuple separator from ", " to " "
    2689         sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
     2715        sout | t1 | t2 | " \"" | sepTuple | "\"" | endl;
    26902716        sepSetTuple( sout, ", " );                                      // reset tuple separator to ", "
    26912717        sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl;
    26922718
    2693         sout | t1 | t2 | endl;                                          // print tuple
    2694         sout | sepOn | t1 | sepOff | t2 | endl;         // locally turn on/off implicit separation
     2719        sout | sepDisable | 1 | 2 | 3 | endl;           // globally turn off implicit separator
     2720        sout | sepEnable | 1 | 2 | 3 | endl;            // globally turn on implicit separator
     2721       
     2722        sout | 1 | sepOff | 2 | 3 | endl;                       // locally turn on implicit separator
     2723        sout | sepDisable | 1 | sepOn | 2 | 3 | endl; // globally turn off implicit separator
     2724        sout | sepEnable;
     2725        sout | t1 | sepOff | t2 | endl;                         // locally turn on/off implicit separator
     2726
     2727        sout | sepOn | 1 | 2 | 3 | sepOn | endl ;       // sepOn does nothing at start/end of line
     2728        sout | sep | 1 | 2 | 3 | sep | endl ;           // use sep to print separator at start/end of line
    26952729}
    26962730
     
    29092943In \CFA, as in C, all scalar types can be incremented and
    29102944decremented, which is defined in terms of adding or subtracting 1.
    2911 The operations �&&�, �||�, and �!� can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. �(a && b)� becomes �(a != 0 && b != 0)�).
     2945The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (ex. ©(a && b)© becomes ©(a != 0 && b != 0)©).
    29122946
    29132947In 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.
    29142948However, 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.
    2915 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from �_Bool�.
     2949Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©_Bool©.
    29162950
    29172951Why just 0 and 1? Why not other integers? No other integers have special status in C.
     
    29963030\begin{tabular}[t]{ll}
    29973031%identifier & operation \\ \hline
    2998 �?[?]� & subscripting \impl{?[?]}\\
    2999 �?()� & function call \impl{?()}\\
    3000 �?++� & postfix increment \impl{?++}\\
    3001 �?--� & postfix decrement \impl{?--}\\
    3002 �++?� & prefix increment \impl{++?}\\
    3003 �--?� & prefix decrement \impl{--?}\\
    3004 �*?� & dereference \impl{*?}\\
    3005 �+?� & unary plus \impl{+?}\\
    3006 �-?� & arithmetic negation \impl{-?}\\
    3007 �~?� & bitwise negation \impl{~?}\\
    3008 �!?� & logical complement \impl{"!?}\\
    3009 �?*?� & multiplication \impl{?*?}\\
    3010 �?/?� & division \impl{?/?}\\
     3032©?[?]© & subscripting \impl{?[?]}\\
     3033©?()© & function call \impl{?()}\\
     3034©?++© & postfix increment \impl{?++}\\
     3035©?--© & postfix decrement \impl{?--}\\
     3036©++?© & prefix increment \impl{++?}\\
     3037©--?© & prefix decrement \impl{--?}\\
     3038©*?© & dereference \impl{*?}\\
     3039©+?© & unary plus \impl{+?}\\
     3040©-?© & arithmetic negation \impl{-?}\\
     3041©~?© & bitwise negation \impl{~?}\\
     3042©!?© & logical complement \impl{"!?}\\
     3043©?*?© & multiplication \impl{?*?}\\
     3044©?/?© & division \impl{?/?}\\
    30113045\end{tabular}\hfil
    30123046\begin{tabular}[t]{ll}
    30133047%identifier & operation \\ \hline
    3014 �?%?� & remainder \impl{?%?}\\
    3015 �?+?� & addition \impl{?+?}\\
    3016 �?-?� & subtraction \impl{?-?}\\
    3017 �?<<?� & left shift \impl{?<<?}\\
    3018 �?>>?� & right shift \impl{?>>?}\\
    3019 �?<?� & less than \impl{?<?}\\
    3020 �?<=?� & less than or equal \impl{?<=?}\\
    3021 �?>=?� & greater than or equal \impl{?>=?}\\
    3022 �?>?� & greater than \impl{?>?}\\
    3023 �?==?� & equality \impl{?==?}\\
    3024 �?!=?� & inequality \impl{?"!=?}\\
    3025 �?&?� & bitwise AND \impl{?&?}\\
     3048©?%?© & remainder \impl{?%?}\\
     3049©?+?© & addition \impl{?+?}\\
     3050©?-?© & subtraction \impl{?-?}\\
     3051©?<<?© & left shift \impl{?<<?}\\
     3052©?>>?© & right shift \impl{?>>?}\\
     3053©?<?© & less than \impl{?<?}\\
     3054©?<=?© & less than or equal \impl{?<=?}\\
     3055©?>=?© & greater than or equal \impl{?>=?}\\
     3056©?>?© & greater than \impl{?>?}\\
     3057©?==?© & equality \impl{?==?}\\
     3058©?!=?© & inequality \impl{?"!=?}\\
     3059©?&?© & bitwise AND \impl{?&?}\\
    30263060\end{tabular}\hfil
    30273061\begin{tabular}[t]{ll}
    30283062%identifier & operation \\ \hline
    3029 �?^?� & exclusive OR \impl{?^?}\\
    3030 �?|?� & inclusive OR \impl{?"|?}\\
    3031 �?=?� & simple assignment \impl{?=?}\\
    3032 �?*=?� & multiplication assignment \impl{?*=?}\\
    3033 �?/=?� & division assignment \impl{?/=?}\\
    3034 �?%=?� & remainder assignment \impl{?%=?}\\
    3035 �?+=?� & addition assignment \impl{?+=?}\\
    3036 �?-=?� & subtraction assignment \impl{?-=?}\\
    3037 �?<<=?� & left-shift assignment \impl{?<<=?}\\
    3038 �?>>=?� & right-shift assignment \impl{?>>=?}\\
    3039 �?&=?� & bitwise AND assignment \impl{?&=?}\\
    3040 �?^=?� & exclusive OR assignment \impl{?^=?}\\
    3041 �?|=?� & inclusive OR assignment \impl{?"|=?}\\
     3063©?^?© & exclusive OR \impl{?^?}\\
     3064©?|?© & inclusive OR \impl{?"|?}\\
     3065©?=?© & simple assignment \impl{?=?}\\
     3066©?*=?© & multiplication assignment \impl{?*=?}\\
     3067©?/=?© & division assignment \impl{?/=?}\\
     3068©?%=?© & remainder assignment \impl{?%=?}\\
     3069©?+=?© & addition assignment \impl{?+=?}\\
     3070©?-=?© & subtraction assignment \impl{?-=?}\\
     3071©?<<=?© & left-shift assignment \impl{?<<=?}\\
     3072©?>>=?© & right-shift assignment \impl{?>>=?}\\
     3073©?&=?© & bitwise AND assignment \impl{?&=?}\\
     3074©?^=?© & exclusive OR assignment \impl{?^=?}\\
     3075©?|=?© & inclusive OR assignment \impl{?"|=?}\\
    30423076\end{tabular}
    30433077\hfil
     
    30483082These identifiers are defined such that the question marks in the name identify the location of the operands.
    30493083These operands represent the parameters to the functions, and define how the operands are mapped to the function call.
    3050 For example, �a + b� becomes �?+?(a, b)�.
     3084For example, ©a + b© becomes ©?+?(a, b)©.
    30513085
    30523086In the example below, a new type, myComplex, is defined with an overloaded constructor, + operator, and string operator.
     
    31223156\end{itemize}
    31233157
    3124 In \CFA, �typedef� provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
    3125 \Indexc{gcc} provides �typeof� to declare a secondary variable from a primary variable.
     3158In \CFA, ©typedef© provides a mechanism to alias long type names with short ones, both globally and locally, but not eliminate the use of the short name.
     3159\Indexc{gcc} provides ©typeof© to declare a secondary variable from a primary variable.
    31263160\CFA also relies heavily on the specification of the left-hand side of assignment for type inferencing, so in many cases it is crucial to specify the type of the left-hand side to select the correct type of the right-hand expression.
    31273161Only for overloaded routines with the same return type is variable type-inferencing possible.
    3128 Finally, �auto� presents the programming problem of tracking down a type when the type is actually needed.
     3162Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed.
    31293163For example, given
    31303164\begin{cfa}
    3131 auto j = �...�
    3132 \end{cfa}
    3133 and the need to write a routine to compute using �j�
    3134 \begin{cfa}
    3135 void rtn( �...� parm );
     3165auto j = ®...®
     3166\end{cfa}
     3167and the need to write a routine to compute using ©j©
     3168\begin{cfa}
     3169void rtn( ®...® parm );
    31363170rtn( j );
    31373171\end{cfa}
    3138 A programmer must work backwards to determine the type of �j�'s initialization expression, reconstructing the possibly long generic type-name.
     3172A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name.
    31393173In this situation, having the type name or a short alias is very useful.
    31403174
     
    31443178At some point, a programmer wants the type of the variable to remain constant and the expression to be in error when it changes.
    31453179
    3146 Given �typedef� and �typeof� in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
     3180Given ©typedef© and ©typeof© in \CFA, and the strong need to use the type of left-hand side in inferencing, auto type-inferencing is not supported at this time.
    31473181Should a significant need arise, this feature can be revisited.
    31483182
     
    34563490
    34573491coroutine Fibonacci {
    3458         int fn;                                                         �\C{// used for communication}�
     3492        int fn;                                                         §\C{// used for communication}§
    34593493};
    34603494void ?{}( Fibonacci * this ) {
     
    34623496}
    34633497void main( Fibonacci * this ) {
    3464         int fn1, fn2;                                           �\C{// retained between resumes}�
    3465         this->fn = 0;                                           �\C{// case 0}�
     3498        int fn1, fn2;                                           §\C{// retained between resumes}§
     3499        this->fn = 0;                                           §\C{// case 0}§
    34663500        fn1 = this->fn;
    3467         suspend();                                                      �\C{// return to last resume}�
    3468 
    3469         this->fn = 1;                                           �\C{// case 1}�
     3501        suspend();                                                      §\C{// return to last resume}§
     3502
     3503        this->fn = 1;                                           §\C{// case 1}§
    34703504        fn2 = fn1;
    34713505        fn1 = this->fn;
    3472         suspend();                                                      �\C{// return to last resume}�
    3473 
    3474         for ( ;; ) {                                            �\C{// general case}�
     3506        suspend();                                                      §\C{// return to last resume}§
     3507
     3508        for ( ;; ) {                                            §\C{// general case}§
    34753509                this->fn = fn1 + fn2;
    34763510                fn2 = fn1;
    34773511                fn1 = this->fn;
    3478                 suspend();                                              �\C{// return to last resume}�
     3512                suspend();                                              §\C{// return to last resume}§
    34793513        } // for
    34803514}
    34813515int next( Fibonacci * this ) {
    3482         resume( this );                                         �\C{// transfer to last suspend}�
     3516        resume( this );                                         §\C{// transfer to last suspend}§
    34833517        return this->fn;
    34843518}
     
    36223656#include <thread>
    36233657
    3624 thread First  { semaphore* lock; };
    3625 thread Second { semaphore* lock; };
    3626 
    3627 void ?{}( First * this, semaphore* lock ) { this->lock = lock; }
    3628 void ?{}( Second * this, semaphore* lock ) { this->lock = lock; }
    3629 
    3630 void main(First* this) {
    3631         for(int i = 0; i < 10; i++) {
     3658thread First  { signal_once * lock; };
     3659thread Second { signal_once * lock; };
     3660
     3661void ?{}( First * this, signal_once* lock ) { this->lock = lock; }
     3662void ?{}( Second * this, signal_once* lock ) { this->lock = lock; }
     3663
     3664void main( First * this ) {
     3665        for ( int i = 0; i < 10; i += 1 ) {
    36323666                sout | "First : Suspend No." | i + 1 | endl;
    36333667                yield();
    36343668        }
    3635         V(this->lock);
    3636 }
    3637 
    3638 void main(Second* this) {
    3639         P(this->lock);
    3640         for(int i = 0; i < 10; i++) {
     3669        signal( this->lock );
     3670}
     3671
     3672void main( Second * this ) {
     3673        wait( this->lock );
     3674        for ( int i = 0; i < 10; i += 1 ) {
    36413675                sout | "Second : Suspend No." | i + 1 | endl;
    36423676                yield();
     
    36443678}
    36453679
    3646 
    3647 int main(int argc, char* argv[]) {
    3648         semaphore lock = { 0 };
     3680int main( void ) {
     3681        signal_once lock;
    36493682        sout | "User main begin" | endl;
    36503683        {
     
    38603893In \CFA, multiple definitions are not necessary.
    38613894Within a module, all of the module's global definitions are visible throughout the module.
    3862 For example, the following code compiles, even though �isOdd� was not declared before being called:
     3895For example, the following code compiles, even though ©isOdd© was not declared before being called:
    38633896\begin{cfa}
    38643897bool isEven(unsigned int x) {
     
    51895222
    51905223C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
    5191 For example, the program fragment �x+++++y� is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens �++� and �+� overlap.
     5224For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
    51925225Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
    51935226Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
    51945227
    5195 In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg �int *?*?()�, where the string �*?*?� can be interpreted as:
    5196 \begin{cfa}
    5197 *?�\color{red}\textvisiblespace�*?              �\C{// dereference operator, dereference operator}�
    5198 *�\color{red}\textvisiblespace�?*?              �\C{// dereference, multiplication operator}�
     5228In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as:
     5229\begin{cfa}
     5230*?§\color{red}\textvisiblespace§*?              §\C{// dereference operator, dereference operator}§
     5231*§\color{red}\textvisiblespace§?*?              §\C{// dereference, multiplication operator}§
    51995232\end{cfa}
    52005233By default, the first interpretation is selected, which does not yield a meaningful parse.
     
    52025235Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
    52035236
    5204 A similar issue occurs with the dereference, �*?(...)�, and routine-call, �?()(...)� identifiers.
     5237A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
    52055238The ambiguity occurs when the deference operator has no parameters:
    52065239\begin{cfa}
    5207 *?()�\color{red}\textvisiblespace...� ;
    5208 *?()�\color{red}\textvisiblespace...�(...) ;
     5240*?()§\color{red}\textvisiblespace...§ ;
     5241*?()§\color{red}\textvisiblespace...§(...) ;
    52095242\end{cfa}
    52105243requiring arbitrary whitespace look-ahead for the routine-call parameter-list to disambiguate.
    5211 However, the dereference operator \emph{must} have a parameter/argument to dereference �*?(...)�.
    5212 Hence, always interpreting the string �*?()� as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
     5244However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
     5245Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
    52135246
    52145247The remaining cases are with the increment/decrement operators and conditional expression, \eg:
    52155248\begin{cfa}
    5216 i++?�\color{red}\textvisiblespace...�(...);
    5217 i?++�\color{red}\textvisiblespace...�(...);
     5249i++?§\color{red}\textvisiblespace...§(...);
     5250i?++§\color{red}\textvisiblespace...§(...);
    52185251\end{cfa}
    52195252requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
    52205253Therefore, it is necessary to disambiguate these cases with a space:
    52215254\begin{cfa}
    5222 i++�\color{red}\textvisiblespace�? i : 0;
    5223 i?�\color{red}\textvisiblespace�++i : 0;
     5255i++§\color{red}\textvisiblespace§? i : 0;
     5256i?§\color{red}\textvisiblespace§++i : 0;
    52245257\end{cfa}
    52255258
     
    52315264\begin{tabular}{llll}
    52325265\begin{tabular}{@{}l@{}}
    5233 �_AT�                   \\
    5234 �catch�                 \\
    5235 �catchResume�   \\
    5236 �choose�                \\
    5237 �coroutine�             \\
    5238 �disable�               \\
     5266©_AT©                   \\
     5267©catch©                 \\
     5268©catchResume©   \\
     5269©choose©                \\
     5270©coroutine©             \\
     5271©disable©               \\
    52395272\end{tabular}
    52405273&
    52415274\begin{tabular}{@{}l@{}}
    5242 �dtype�                 \\
    5243 �enable�                \\
    5244 �fallthrough�   \\
    5245 �fallthru�              \\
    5246 �finally�               \\
    5247 �forall�                \\
     5275©dtype©                 \\
     5276©enable©                \\
     5277©fallthrough©   \\
     5278©fallthru©              \\
     5279©finally©               \\
     5280©forall©                \\
    52485281\end{tabular}
    52495282&
    52505283\begin{tabular}{@{}l@{}}
    5251 �ftype�                 \\
    5252 �lvalue�                \\
    5253 �monitor�               \\
    5254 �mutex�                 \\
    5255 �one_t�                 \\
    5256 �otype�                 \\
     5284©ftype©                 \\
     5285©lvalue©                \\
     5286©monitor©               \\
     5287©mutex©                 \\
     5288©one_t©                 \\
     5289©otype©                 \\
    52575290\end{tabular}
    52585291&
    52595292\begin{tabular}{@{}l@{}}
    5260 �throw�                 \\
    5261 �throwResume�   \\
    5262 �trait�                 \\
    5263 �try�                   \\
    5264 �ttype�                 \\
    5265 �zero_t�                \\
     5293©throw©                 \\
     5294©throwResume©   \\
     5295©trait©                 \\
     5296©try©                   \\
     5297©ttype©                 \\
     5298©zero_t©                \\
    52665299\end{tabular}
    52675300\end{tabular}
     
    52895322\begin{description}
    52905323\item[Change:] drop K\&R C declarations \\
    5291 K\&R declarations allow an implicit base-type of �int�, if no type is specified, plus an alternate syntax for declaring parameters.
     5324K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters.
    52925325\eg:
    52935326\begin{cfa}
    5294 x;                                                              �\C{// int x}�
    5295 *y;                                                             �\C{// int *y}�
    5296 f( p1, p2 );                                    �\C{// int f( int p1, int p2 );}�
    5297 g( p1, p2 ) int p1, p2;                 �\C{// int g( int p1, int p2 );}�
     5327x;                                                              §\C{// int x}§
     5328*y;                                                             §\C{// int *y}§
     5329f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
     5330g( p1, p2 ) int p1, p2;                 §\C{// int g( int p1, int p2 );}§
    52985331\end{cfa}
    52995332\CFA supports K\&R routine definitions:
    53005333\begin{cfa}
    5301 f( a, b, c )                                    �\C{// default int return}�
    5302         int a, b; char c                        �\C{// K\&R parameter declarations}�
     5334f( a, b, c )                                    §\C{// default int return}§
     5335        int a, b; char c                        §\C{// K\&R parameter declarations}§
    53035336{
    53045337        ...
     
    53155348\item
    53165349\begin{description}
    5317 \item[Change:] type of character literal �int� to �char� to allow more intuitive overloading:
     5350\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
    53185351\begin{cfa}
    53195352int rtn( int i );
    53205353int rtn( char c );
    5321 rtn( 'x' );                                             �\C{// programmer expects 2nd rtn to be called}�
    5322 \end{cfa}
    5323 \item[Rationale:] it is more intuitive for the call to �rtn� to match the second version of definition of �rtn� rather than the first.
    5324 In particular, output of �char� variable now print a character rather than the decimal ASCII value of the character.
     5354rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
     5355\end{cfa}
     5356\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
     5357In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
    53255358\begin{cfa}
    53265359sout | 'x' | " " | (int)'x' | endl;
    53275360x 120
    53285361\end{cfa}
    5329 Having to cast �'x'� to �char� is non-intuitive.
     5362Having to cast ©'x'© to ©char© is non-intuitive.
    53305363\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
    53315364\begin{cfa}
     
    53345367no long work the same in \CFA programs.
    53355368\item[Difficulty of converting:] simple
    5336 \item[How widely used:] programs that depend upon �sizeof( 'x' )� are rare and can be changed to �sizeof(char)�.
     5369\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
    53375370\end{description}
    53385371
    53395372\item
    53405373\begin{description}
    5341 \item[Change:] make string literals �const�:
    5342 \begin{cfa}
    5343 char * p = "abc";                               �\C{// valid in C, deprecated in \CFA}�
    5344 char * q = expr ? "abc" : "de"; �\C{// valid in C, invalid in \CFA}�
    5345 \end{cfa}
    5346 The type of a string literal is changed from �[] char� to �const [] char�.
    5347 Similarly, the type of a wide string literal is changed from �[] wchar_t� to �const [] wchar_t�.
     5374\item[Change:] make string literals ©const©:
     5375\begin{cfa}
     5376char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
     5377char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
     5378\end{cfa}
     5379The type of a string literal is changed from ©[] char© to ©const [] char©.
     5380Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
    53485381\item[Rationale:] This change is a safety issue:
    53495382\begin{cfa}
    53505383char * p = "abc";
    5351 p[0] = 'w';                                             �\C{// segment fault or change constant literal}�
     5384p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
    53525385\end{cfa}
    53535386The same problem occurs when passing a string literal to a routine that changes its argument.
    53545387\item[Effect on original feature:] change to semantics of well-defined feature.
    5355 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to �char *�.
     5388\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
    53565389\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
    53575390\end{description}
     
    53615394\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
    53625395\begin{cfa}
    5363 int i;                                                  �\C{// forward definition}�
    5364 int *j = �&i�;                                  �\C{// forward reference, valid in C, invalid in \CFA}�
    5365 int i = 0;                                              �\C{// definition}�
     5396int i;                                                  §\C{// forward definition}§
     5397int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
     5398int i = 0;                                              §\C{// definition}§
    53665399\end{cfa}
    53675400is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
     
    53695402\begin{cfa}
    53705403struct X { int i; struct X *next; };
    5371 static struct X a;                              �\C{// forward definition}�
    5372 static struct X b = { 0, �&a� };        �\C{// forward reference, valid in C, invalid in \CFA}�
    5373 static struct X a = { 1, &b };  �\C{// definition}�
     5404static struct X a;                              §\C{// forward definition}§
     5405static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
     5406static struct X a = { 1, &b };  §\C{// definition}§
    53745407\end{cfa}
    53755408\item[Rationale:] avoids having different initialization rules for builtin types and user-defined types.
     
    53815414\item
    53825415\begin{description}
    5383 \item[Change:] have �struct� introduce a scope for nested types:
    5384 \begin{cfa}
    5385 enum �Colour� { R, G, B, Y, C, M };
     5416\item[Change:] have ©struct© introduce a scope for nested types:
     5417\begin{cfa}
     5418enum ®Colour® { R, G, B, Y, C, M };
    53865419struct Person {
    5387         enum �Colour� { R, G, B };      �\C{// nested type}�
    5388         struct Face {                           �\C{// nested type}�
    5389                 �Colour� Eyes, Hair;    �\C{// type defined outside (1 level)}�
     5420        enum ®Colour® { R, G, B };      §\C{// nested type}§
     5421        struct Face {                           §\C{// nested type}§
     5422                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
    53905423        };
    5391         �.Colour� shirt;                        �\C{// type defined outside (top level)}�
    5392         �Colour� pants;                         �\C{// type defined same level}�
    5393         Face looks[10];                         �\C{// type defined same level}�
     5424        ®.Colour® shirt;                        §\C{// type defined outside (top level)}§
     5425        ®Colour® pants;                         §\C{// type defined same level}§
     5426        Face looks[10];                         §\C{// type defined same level}§
    53945427};
    5395 �Colour� c = R;                                 �\C{// type/enum defined same level}�
    5396 Person�.Colour� pc = Person�.�R;        �\C{// type/enum defined inside}�
    5397 Person�.�Face pretty;                   �\C{// type defined inside}�
     5428®Colour® c = R;                                 §\C{// type/enum defined same level}§
     5429Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
     5430Person®.®Face pretty;                   §\C{// type defined inside}§
    53985431\end{cfa}
    53995432In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
    54005433\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC{}}.
    5401 Nested types are not hoisted and can be referenced using the field selection operator ``�.�'', unlike the \CC scope-resolution operator ``�::�''.
    5402 \item[Rationale:] �struct� scope is crucial to \CFA as an information structuring and hiding mechanism.
     5434Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
     5435\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
    54035436\item[Effect on original feature:] change to semantics of well-defined feature.
    54045437\item[Difficulty of converting:] Semantic transformation.
     
    54125445\item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:
    54135446\begin{cfa}
    5414 struct Y;                                               �\C{// struct Y and struct X are at the same scope}�
     5447struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
    54155448struct X {
    54165449        struct Y { /* ... */ } y;
     
    54255458\begin{description}
    54265459\item[Change:] comma expression is disallowed as subscript
    5427 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: �x[i,j]� instead of �x[i][j]�, and this syntactic form then taken by \CFA for new style arrays.
     5460\item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.
    54285461\item[Effect on original feature:] change to semantics of well-defined feature.
    5429 \item[Difficulty of converting:] semantic transformation of �x[i,j]� to �x[(i,j)]�
     5462\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
    54305463\item[How widely used:] seldom.
    54315464\end{description}
     
    54985531\end{tabular}
    54995532\end{quote2}
    5500 For the prescribed head-files, \CFA uses header interposition to wraps these includes in an �extern "C"�;
     5533For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©;
    55015534hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    5502 All other C header files must be explicitly wrapped in �extern "C"� to prevent name mangling.
    5503 For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable �__cplusplus�, which adds appropriate �extern "C"� qualifiers.
     5535All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
     5536For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
    55045537
    55055538
     
    55335566                &                                       & \multicolumn{1}{c|}{fill}     & resize        & alignment     & array \\
    55345567\hline
    5535 C               & �malloc�                      & no                    & no            & no            & no    \\
    5536                 & �calloc�                      & yes (0 only)  & no            & no            & yes   \\
    5537                 & �realloc�                     & no/copy               & yes           & no            & no    \\
    5538                 & �memalign�            & no                    & no            & yes           & no    \\
    5539                 & �posix_memalign�      & no                    & no            & yes           & no    \\
    5540 C11             & �aligned_alloc�       & no                    & no            & yes           & no    \\
    5541 \CFA    & �alloc�                       & no/copy/yes   & no/yes        & no            & yes   \\
    5542                 & �align_alloc�         & no/yes                & no            & yes           & yes   \\
     5568C               & ©malloc©                      & no                    & no            & no            & no    \\
     5569                & ©calloc©                      & yes (0 only)  & no            & no            & yes   \\
     5570                & ©realloc©                     & no/copy               & yes           & no            & no    \\
     5571                & ©memalign©            & no                    & no            & yes           & no    \\
     5572                & ©posix_memalign©      & no                    & no            & yes           & no    \\
     5573C11             & ©aligned_alloc©       & no                    & no            & yes           & no    \\
     5574\CFA    & ©alloc©                       & no/copy/yes   & no/yes        & no            & yes   \\
     5575                & ©align_alloc©         & no/yes                & no            & yes           & yes   \\
    55435576\end{tabular}
    55445577\end{center}
    5545 It is impossible to resize with alignment because the underlying �realloc� allocates storage if more space is needed, and it does not honour alignment from the original allocation.
     5578It is impossible to resize with alignment because the underlying ©realloc© allocates storage if more space is needed, and it does not honour alignment from the original allocation.
    55465579
    55475580\leavevmode
     
    55495582// C unsafe allocation
    55505583extern "C" {
    5551 void * mallac( size_t size );�\indexc{memset}�
    5552 void * calloc( size_t dim, size_t size );�\indexc{calloc}�
    5553 void * realloc( void * ptr, size_t size );�\indexc{realloc}�
    5554 void * memalign( size_t align, size_t size );�\indexc{memalign}�
    5555 int posix_memalign( void ** ptr, size_t align, size_t size );�\indexc{posix_memalign}�
    5556 }
    5557 
    5558 // �\CFA� safe equivalents, i.e., implicit size specification
     5584void * malloc( size_t size );§\indexc{memset}§
     5585void * calloc( size_t dim, size_t size );§\indexc{calloc}§
     5586void * realloc( void * ptr, size_t size );§\indexc{realloc}§
     5587void * memalign( size_t align, size_t size );§\indexc{memalign}§
     5588int posix_memalign( void ** ptr, size_t align, size_t size );§\indexc{posix_memalign}§
     5589}
     5590
     5591// §\CFA§ safe equivalents, i.e., implicit size specification
    55595592forall( dtype T | sized(T) ) T * malloc( void );
    55605593forall( dtype T | sized(T) ) T * calloc( size_t dim );
     
    55645597forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t align );
    55655598
    5566 // �\CFA� safe general allocation, fill, resize, array
    5567 forall( dtype T | sized(T) ) T * alloc( void );�\indexc{alloc}�
     5599// §\CFA§ safe general allocation, fill, resize, array
     5600forall( dtype T | sized(T) ) T * alloc( void );§\indexc{alloc}§
    55685601forall( dtype T | sized(T) ) T * alloc( char fill );
    55695602forall( dtype T | sized(T) ) T * alloc( size_t dim );
     
    55725605forall( dtype T | sized(T) ) T * alloc( T ptr[], size_t dim, char fill );
    55735606
    5574 // �\CFA� safe general allocation, align, fill, array
     5607// §\CFA§ safe general allocation, align, fill, array
    55755608forall( dtype T | sized(T) ) T * align_alloc( size_t align );
    55765609forall( dtype T | sized(T) ) T * align_alloc( size_t align, char fill );
     
    55845617}
    55855618
    5586 // �\CFA� safe initialization/copy, i.e., implicit size specification
    5587 forall( dtype T | sized(T) ) T * memset( T * dest, char c );�\indexc{memset}�
    5588 forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );�\indexc{memcpy}�
    5589 
    5590 // �\CFA� safe initialization/copy array
     5619// §\CFA§ safe initialization/copy, i.e., implicit size specification
     5620forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
     5621forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
     5622
     5623// §\CFA§ safe initialization/copy array
    55915624forall( dtype T | sized(T) ) T * memset( T dest[], size_t dim, char c );
    55925625forall( dtype T | sized(T) ) T * memcpy( T dest[], const T src[], size_t dim );
    55935626
    5594 // �\CFA� allocation/deallocation and constructor/destructor
    5595 forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * new( Params p );�\indexc{new}�
    5596 forall( dtype T | { void ^?{}( T * ); } ) void delete( T * ptr );�\indexc{delete}�
     5627// §\CFA§ allocation/deallocation and constructor/destructor
     5628forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * new( Params p );§\indexc{new}§
     5629forall( dtype T | { void ^?{}( T * ); } ) void delete( T * ptr );§\indexc{delete}§
    55975630forall( dtype T, ttype Params | { void ^?{}( T * ); void delete( Params ); } )
    55985631  void delete( T * ptr, Params rest );
    55995632
    5600 // �\CFA� allocation/deallocation and constructor/destructor, array
    5601 forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * anew( size_t dim, Params p );�\indexc{anew}�
    5602 forall( dtype T | sized(T) | { void ^?{}( T * ); } ) void adelete( size_t dim, T arr[] );�\indexc{adelete}�
     5633// §\CFA§ allocation/deallocation and constructor/destructor, array
     5634forall( dtype T | sized(T), ttype Params | { void ?{}( T *, Params ); } ) T * anew( size_t dim, Params p );§\indexc{anew}§
     5635forall( dtype T | sized(T) | { void ^?{}( T * ); } ) void adelete( size_t dim, T arr[] );§\indexc{adelete}§
    56035636forall( dtype T | sized(T) | { void ^?{}( T * ); }, ttype Params | { void adelete( Params ); } )
    56045637  void adelete( size_t dim, T arr[], Params rest );
     
    56105643\leavevmode
    56115644\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5612 int ato( const char * ptr );�\indexc{ato}�
     5645int ato( const char * ptr );§\indexc{ato}§
    56135646unsigned int ato( const char * ptr );
    56145647long int ato( const char * ptr );
     
    56425675\leavevmode
    56435676\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5644 forall( otype T | { int ?<?( T, T ); } )        �\C{// location}�
    5645 T * bsearch( T key, const T * arr, size_t dim );�\indexc{bsearch}�
    5646 
    5647 forall( otype T | { int ?<?( T, T ); } )        �\C{// position}�
     5677forall( otype T | { int ?<?( T, T ); } )        §\C{// location}§
     5678T * bsearch( T key, const T * arr, size_t dim );§\indexc{bsearch}§
     5679
     5680forall( otype T | { int ?<?( T, T ); } )        §\C{// position}§
    56485681unsigned int bsearch( T key, const T * arr, size_t dim );
    56495682
    56505683forall( otype T | { int ?<?( T, T ); } )
    5651 void qsort( const T * arr, size_t dim );�\indexc{qsort}�
     5684void qsort( const T * arr, size_t dim );§\indexc{qsort}§
    56525685\end{cfa}
    56535686
     
    56575690\leavevmode
    56585691\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5659 unsigned char abs( signed char );�\indexc{abs}�
     5692unsigned char abs( signed char );§\indexc{abs}§
    56605693int abs( int );
    56615694unsigned long int abs( long int );
     
    56765709\leavevmode
    56775710\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5678 void rand48seed( long int s );�\indexc{rand48seed}�
    5679 char rand48();�\indexc{rand48}�
     5711void rand48seed( long int s );§\indexc{rand48seed}§
     5712char rand48();§\indexc{rand48}§
    56805713int rand48();
    56815714unsigned int rand48();
     
    56945727\leavevmode
    56955728\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5696 forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );�\indexc{min}�
    5697 forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );�\indexc{max}�
    5698 forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );�\indexc{clamp}�
    5699 forall( otype T ) void swap( T * t1, T * t2 );�\indexc{swap}�
     5729forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
     5730forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
     5731forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
     5732forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
    57005733\end{cfa}
    57015734
     
    57115744\leavevmode
    57125745\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5713 float ?%?( float, float );�\indexc{fmod}�
     5746float ?%?( float, float );§\indexc{fmod}§
    57145747float fmod( float, float );
    57155748double ?%?( double, double );
     
    57185751long double fmod( long double, long double );
    57195752
    5720 float remainder( float, float );�\indexc{remainder}�
     5753float remainder( float, float );§\indexc{remainder}§
    57215754double remainder( double, double );
    57225755long double remainder( long double, long double );
    57235756
    5724 [ int, float ] remquo( float, float );�\indexc{remquo}�
     5757[ int, float ] remquo( float, float );§\indexc{remquo}§
    57255758float remquo( float, float, int * );
    57265759[ int, double ] remquo( double, double );
     
    57305763
    57315764[ int, float ] div( float, float );                                             // alternative name for remquo
    5732 float div( float, float, int * );�\indexc{div}�
     5765float div( float, float, int * );§\indexc{div}§
    57335766[ int, double ] div( double, double );
    57345767double div( double, double, int * );
     
    57365769long double div( long double, long double, int * );
    57375770
    5738 float fma( float, float, float );�\indexc{fma}�
     5771float fma( float, float, float );§\indexc{fma}§
    57395772double fma( double, double, double );
    57405773long double fma( long double, long double, long double );
    57415774
    5742 float fdim( float, float );�\indexc{fdim}�
     5775float fdim( float, float );§\indexc{fdim}§
    57435776double fdim( double, double );
    57445777long double fdim( long double, long double );
    57455778
    5746 float nan( const char * );�\indexc{nan}�
     5779float nan( const char * );§\indexc{nan}§
    57475780double nan( const char * );
    57485781long double nan( const char * );
     
    57545787\leavevmode
    57555788\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5756 float exp( float );�\indexc{exp}�
     5789float exp( float );§\indexc{exp}§
    57575790double exp( double );
    57585791long double exp( long double );
     
    57615794long double _Complex exp( long double _Complex );
    57625795
    5763 float exp2( float );�\indexc{exp2}�
     5796float exp2( float );§\indexc{exp2}§
    57645797double exp2( double );
    57655798long double exp2( long double );
     
    57685801long double _Complex exp2( long double _Complex );
    57695802
    5770 float expm1( float );�\indexc{expm1}�
     5803float expm1( float );§\indexc{expm1}§
    57715804double expm1( double );
    57725805long double expm1( long double );
    57735806
    5774 float log( float );�\indexc{log}�
     5807float log( float );§\indexc{log}§
    57755808double log( double );
    57765809long double log( long double );
     
    57795812long double _Complex log( long double _Complex );
    57805813
    5781 float log2( float );�\indexc{log2}�
     5814float log2( float );§\indexc{log2}§
    57825815double log2( double );
    57835816long double log2( long double );
     
    57865819long double _Complex log2( long double _Complex );
    57875820
    5788 float log10( float );�\indexc{log10}�
     5821float log10( float );§\indexc{log10}§
    57895822double log10( double );
    57905823long double log10( long double );
     
    57935826long double _Complex log10( long double _Complex );
    57945827
    5795 float log1p( float );�\indexc{log1p}�
     5828float log1p( float );§\indexc{log1p}§
    57965829double log1p( double );
    57975830long double log1p( long double );
    57985831
    5799 int ilogb( float );�\indexc{ilogb}�
     5832int ilogb( float );§\indexc{ilogb}§
    58005833int ilogb( double );
    58015834int ilogb( long double );
    58025835
    5803 float logb( float );�\indexc{logb}�
     5836float logb( float );§\indexc{logb}§
    58045837double logb( double );
    58055838long double logb( long double );
     
    58115844\leavevmode
    58125845\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5813 float sqrt( float );�\indexc{sqrt}�
     5846float sqrt( float );§\indexc{sqrt}§
    58145847double sqrt( double );
    58155848long double sqrt( long double );
     
    58185851long double _Complex sqrt( long double _Complex );
    58195852
    5820 float cbrt( float );�\indexc{cbrt}�
     5853float cbrt( float );§\indexc{cbrt}§
    58215854double cbrt( double );
    58225855long double cbrt( long double );
    58235856
    5824 float hypot( float, float );�\indexc{hypot}�
     5857float hypot( float, float );§\indexc{hypot}§
    58255858double hypot( double, double );
    58265859long double hypot( long double, long double );
    58275860
    5828 float pow( float, float );�\indexc{pow}�
     5861float pow( float, float );§\indexc{pow}§
    58295862double pow( double, double );
    58305863long double pow( long double, long double );
     
    58395872\leavevmode
    58405873\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5841 float sin( float );�\indexc{sin}�
     5874float sin( float );§\indexc{sin}§
    58425875double sin( double );
    58435876long double sin( long double );
     
    58465879long double _Complex sin( long double _Complex );
    58475880
    5848 float cos( float );�\indexc{cos}�
     5881float cos( float );§\indexc{cos}§
    58495882double cos( double );
    58505883long double cos( long double );
     
    58535886long double _Complex cos( long double _Complex );
    58545887
    5855 float tan( float );�\indexc{tan}�
     5888float tan( float );§\indexc{tan}§
    58565889double tan( double );
    58575890long double tan( long double );
     
    58605893long double _Complex tan( long double _Complex );
    58615894
    5862 float asin( float );�\indexc{asin}�
     5895float asin( float );§\indexc{asin}§
    58635896double asin( double );
    58645897long double asin( long double );
     
    58675900long double _Complex asin( long double _Complex );
    58685901
    5869 float acos( float );�\indexc{acos}�
     5902float acos( float );§\indexc{acos}§
    58705903double acos( double );
    58715904long double acos( long double );
     
    58745907long double _Complex acos( long double _Complex );
    58755908
    5876 float atan( float );�\indexc{atan}�
     5909float atan( float );§\indexc{atan}§
    58775910double atan( double );
    58785911long double atan( long double );
     
    58815914long double _Complex atan( long double _Complex );
    58825915
    5883 float atan2( float, float );�\indexc{atan2}�
     5916float atan2( float, float );§\indexc{atan2}§
    58845917double atan2( double, double );
    58855918long double atan2( long double, long double );
    58865919
    58875920float atan( float, float );                                                             // alternative name for atan2
    5888 double atan( double, double );�\indexc{atan}�
     5921double atan( double, double );§\indexc{atan}§
    58895922long double atan( long double, long double );
    58905923\end{cfa}
     
    58955928\leavevmode
    58965929\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5897 float sinh( float );�\indexc{sinh}�
     5930float sinh( float );§\indexc{sinh}§
    58985931double sinh( double );
    58995932long double sinh( long double );
     
    59025935long double _Complex sinh( long double _Complex );
    59035936
    5904 float cosh( float );�\indexc{cosh}�
     5937float cosh( float );§\indexc{cosh}§
    59055938double cosh( double );
    59065939long double cosh( long double );
     
    59095942long double _Complex cosh( long double _Complex );
    59105943
    5911 float tanh( float );�\indexc{tanh}�
     5944float tanh( float );§\indexc{tanh}§
    59125945double tanh( double );
    59135946long double tanh( long double );
     
    59165949long double _Complex tanh( long double _Complex );
    59175950
    5918 float asinh( float );�\indexc{asinh}�
     5951float asinh( float );§\indexc{asinh}§
    59195952double asinh( double );
    59205953long double asinh( long double );
     
    59235956long double _Complex asinh( long double _Complex );
    59245957
    5925 float acosh( float );�\indexc{acosh}�
     5958float acosh( float );§\indexc{acosh}§
    59265959double acosh( double );
    59275960long double acosh( long double );
     
    59305963long double _Complex acosh( long double _Complex );
    59315964
    5932 float atanh( float );�\indexc{atanh}�
     5965float atanh( float );§\indexc{atanh}§
    59335966double atanh( double );
    59345967long double atanh( long double );
     
    59435976\leavevmode
    59445977\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5945 float erf( float );�\indexc{erf}�
     5978float erf( float );§\indexc{erf}§
    59465979double erf( double );
    59475980long double erf( long double );
     
    59505983long double _Complex erf( long double _Complex );
    59515984
    5952 float erfc( float );�\indexc{erfc}�
     5985float erfc( float );§\indexc{erfc}§
    59535986double erfc( double );
    59545987long double erfc( long double );
     
    59575990long double _Complex erfc( long double _Complex );
    59585991
    5959 float lgamma( float );�\indexc{lgamma}�
     5992float lgamma( float );§\indexc{lgamma}§
    59605993double lgamma( double );
    59615994long double lgamma( long double );
     
    59645997long double lgamma( long double, int * );
    59655998
    5966 float tgamma( float );�\indexc{tgamma}�
     5999float tgamma( float );§\indexc{tgamma}§
    59676000double tgamma( double );
    59686001long double tgamma( long double );
     
    59746007\leavevmode
    59756008\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5976 float floor( float );�\indexc{floor}�
     6009float floor( float );§\indexc{floor}§
    59776010double floor( double );
    59786011long double floor( long double );
    59796012
    5980 float ceil( float );�\indexc{ceil}�
     6013float ceil( float );§\indexc{ceil}§
    59816014double ceil( double );
    59826015long double ceil( long double );
    59836016
    5984 float trunc( float );�\indexc{trunc}�
     6017float trunc( float );§\indexc{trunc}§
    59856018double trunc( double );
    59866019long double trunc( long double );
    59876020
    5988 float rint( float );�\indexc{rint}�
     6021float rint( float );§\indexc{rint}§
    59896022long double rint( long double );
    59906023long int rint( float );
     
    59956028long long int rint( long double );
    59966029
    5997 long int lrint( float );�\indexc{lrint}�
     6030long int lrint( float );§\indexc{lrint}§
    59986031long int lrint( double );
    59996032long int lrint( long double );
     
    60026035long long int llrint( long double );
    60036036
    6004 float nearbyint( float );�\indexc{nearbyint}�
     6037float nearbyint( float );§\indexc{nearbyint}§
    60056038double nearbyint( double );
    60066039long double nearbyint( long double );
    60076040
    6008 float round( float );�\indexc{round}�
     6041float round( float );§\indexc{round}§
    60096042long double round( long double );
    60106043long int round( float );
     
    60156048long long int round( long double );
    60166049
    6017 long int lround( float );�\indexc{lround}�
     6050long int lround( float );§\indexc{lround}§
    60186051long int lround( double );
    60196052long int lround( long double );
     
    60286061\leavevmode
    60296062\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    6030 float copysign( float, float );�\indexc{copysign}�
     6063float copysign( float, float );§\indexc{copysign}§
    60316064double copysign( double, double );
    60326065long double copysign( long double, long double );
    60336066
    6034 float frexp( float, int * );�\indexc{frexp}�
     6067float frexp( float, int * );§\indexc{frexp}§
    60356068double frexp( double, int * );
    60366069long double frexp( long double, int * );
    60376070
    6038 float ldexp( float, int );�\indexc{ldexp}�
     6071float ldexp( float, int );§\indexc{ldexp}§
    60396072double ldexp( double, int );
    60406073long double ldexp( long double, int );
    60416074
    6042 [ float, float ] modf( float );�\indexc{modf}�
     6075[ float, float ] modf( float );§\indexc{modf}§
    60436076float modf( float, float * );
    60446077[ double, double ] modf( double );
     
    60476080long double modf( long double, long double * );
    60486081
    6049 float nextafter( float, float );�\indexc{nextafter}�
     6082float nextafter( float, float );§\indexc{nextafter}§
    60506083double nextafter( double, double );
    60516084long double nextafter( long double, long double );
    60526085
    6053 float nexttoward( float, long double );�\indexc{nexttoward}�
     6086float nexttoward( float, long double );§\indexc{nexttoward}§
    60546087double nexttoward( double, long double );
    60556088long double nexttoward( long double, long double );
    60566089
    6057 float scalbn( float, int );�\indexc{scalbn}�
     6090float scalbn( float, int );§\indexc{scalbn}§
    60586091double scalbn( double, int );
    60596092long double scalbn( long double, int );
    60606093
    6061 float scalbln( float, long int );�\indexc{scalbln}�
     6094float scalbln( float, long int );§\indexc{scalbln}§
    60626095double scalbln( double, long int );
    60636096long double scalbln( long double, long int );
     
    60736106
    60746107\begin{cfa}
    6075 void ?{}( Int * this );                                 �\C{// constructor}�
     6108void ?{}( Int * this );                                 §\C{// constructor}§
    60766109void ?{}( Int * this, Int init );
    60776110void ?{}( Int * this, zero_t );
     
    60826115void ^?{}( Int * this );
    60836116
    6084 Int ?=?( Int * lhs, Int rhs );                  �\C{// assignment}�
     6117Int ?=?( Int * lhs, Int rhs );                  §\C{// assignment}§
    60856118Int ?=?( Int * lhs, long int rhs );
    60866119Int ?=?( Int * lhs, unsigned long int rhs );
     
    60996132unsigned long int narrow( Int val );
    61006133
    6101 int ?==?( Int oper1, Int oper2 );               �\C{// comparison}�
     6134int ?==?( Int oper1, Int oper2 );               §\C{// comparison}§
    61026135int ?==?( Int oper1, long int oper2 );
    61036136int ?==?( long int oper2, Int oper1 );
     
    61356168int ?>=?( unsigned long int oper1, Int oper2 );
    61366169
    6137 Int +?( Int oper );                                             �\C{// arithmetic}�
     6170Int +?( Int oper );                                             §\C{// arithmetic}§
    61386171Int -?( Int oper );
    61396172Int ~?( Int oper );
     
    62176250Int ?>>=?( Int * lhs, mp_bitcnt_t shift );
    62186251
    6219 Int abs( Int oper );                                    �\C{// number functions}�
     6252Int abs( Int oper );                                    §\C{// number functions}§
    62206253Int fact( unsigned long int N );
    62216254Int gcd( Int oper1, Int oper2 );
     
    62296262Int sqrt( Int oper );
    62306263
    6231 forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  �\C{// I/O}�
     6264forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp );  §\C{// I/O}§
    62326265forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp );
    62336266\end{cfa}
     
    62406273\hline
    62416274\begin{cfa}
    6242 #include <gmp>�\indexc{gmp}�
     6275#include <gmp>§\indexc{gmp}§
    62436276int main( void ) {
    62446277        sout | "Factorial Numbers" | endl;
     
    62546287&
    62556288\begin{cfa}
    6256 #include <gmp.h>�\indexc{gmp.h}�
     6289#include <gmp.h>§\indexc{gmp.h}§
    62576290int main( void ) {
    6258         �gmp_printf�( "Factorial Numbers\n" );
    6259         �mpz_t� fact;
    6260         �mpz_init_set_ui�( fact, 1 );
    6261         �gmp_printf�( "%d %Zd\n", 0, fact );
     6291        ®gmp_printf®( "Factorial Numbers\n" );
     6292        ®mpz_t® fact;
     6293        ®mpz_init_set_ui®( fact, 1 );
     6294        ®gmp_printf®( "%d %Zd\n", 0, fact );
    62626295        for ( unsigned int i = 1; i <= 40; i += 1 ) {
    6263                 �mpz_mul_ui�( fact, fact, i );
    6264                 �gmp_printf�( "%d %Zd\n", i, fact );
     6296                ®mpz_mul_ui®( fact, fact, i );
     6297                ®gmp_printf®( "%d %Zd\n", i, fact );
    62656298        }
    62666299}
     
    63276360\begin{cfa}[belowskip=0pt]
    63286361// implementation
    6329 struct Rational {�\indexc{Rational}�
     6362struct Rational {§\indexc{Rational}§
    63306363        long int numerator, denominator;                                        // invariant: denominator > 0
    63316364}; // Rational
    63326365
    6333 Rational rational();                                    �\C{// constructors}�
     6366Rational rational();                                    §\C{// constructors}§
    63346367Rational rational( long int n );
    63356368Rational rational( long int n, long int d );
     
    63376370void ?{}( Rational * r, one_t );
    63386371
    6339 long int numerator( Rational r );               �\C{// numerator/denominator getter/setter}�
     6372long int numerator( Rational r );               §\C{// numerator/denominator getter/setter}§
    63406373long int numerator( Rational r, long int n );
    63416374long int denominator( Rational r );
    63426375long int denominator( Rational r, long int d );
    63436376
    6344 int ?==?( Rational l, Rational r );             �\C{// comparison}�
     6377int ?==?( Rational l, Rational r );             §\C{// comparison}§
    63456378int ?!=?( Rational l, Rational r );
    63466379int ?<?( Rational l, Rational r );
     
    63496382int ?>=?( Rational l, Rational r );
    63506383
    6351 Rational -?( Rational r );                              �\C{// arithmetic}�
     6384Rational -?( Rational r );                              §\C{// arithmetic}§
    63526385Rational ?+?( Rational l, Rational r );
    63536386Rational ?-?( Rational l, Rational r );
     
    63556388Rational ?/?( Rational l, Rational r );
    63566389
    6357 double widen( Rational r );                             �\C{// conversion}�
     6390double widen( Rational r );                             §\C{// conversion}§
    63586391Rational narrow( double f, long int md );
    63596392
Note: See TracChangeset for help on using the changeset viewer.