Changeset 0638c44 for doc/user


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

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

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