Changeset 7527e63 for doc


Ignore:
Timestamp:
Aug 16, 2016, 3:20:06 PM (10 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, stuck-waitfor-destruct, with_gc
Children:
1f6d4624
Parents:
950f7a7 (diff), 7880579 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

Location:
doc
Files:
7 added
4 edited

Legend:

Unmodified
Added
Removed

  • doc/LaTeXmacros/common.tex

    r950f7a7 r7527e63  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Tue Jul 12 20:37:57 2016
    14 %% Update Count     : 206
     13%% Last Modified On : Sun Aug 14 08:27:29 2016
     14%% Update Count     : 231
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    16 
    17 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1816
    1917\setlength{\textheight}{9in}
    2018%\oddsidemargin 0.0in
    21 \renewcommand{\topfraction}{0.8}        % float must be greater than X of the page before it is forced onto its own page
    22 \renewcommand{\bottomfraction}{0.8}     % float must be greater than X of the page before it is forced onto its own page
     19\renewcommand{\topfraction}{0.8}                % float must be greater than X of the page before it is forced onto its own page
     20\renewcommand{\bottomfraction}{0.8}             % float must be greater than X of the page before it is forced onto its own page
    2321\renewcommand{\floatpagefraction}{0.8}  % float must be greater than X of the page before it is forced onto its own page
    24 \renewcommand{\textfraction}{0.0}       % the entire page maybe devoted to floats with no text on the page at all
    25 
    26 \lefthyphenmin=4
     22\renewcommand{\textfraction}{0.0}               % the entire page maybe devoted to floats with no text on the page at all
     23
     24\lefthyphenmin=4                                                % hyphen only after 4 characters
    2725\righthyphenmin=4
    2826
    … …  
    3836% Names used in the document.
    3937
    40 \newcommand{\CFA}{C$\mathbf\forall$\xspace}              % set language symbolic name
    41 \newcommand{\CFL}{Cforall\xspace}                        % set language text name
     38\newcommand{\CFA}{C$\mathbf\forall$\xspace} % set language symbolic name
     39\newcommand{\CFL}{Cforall\xspace}               % set language text name
    4240\newcommand{\CC}{\rm C\kern-.1em\hbox{+\kern-.25em+}\xspace} % CC symbolic name
    43 \def\c11{ISO/IEC C} % C11 name (cannot have numbers in latex command name)
     41\newcommand{\CCeleven}{\rm C\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name
     42\newcommand{\Celeven}{C11\xspace}               % C11 symbolic name
    4443
    4544%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    5150\setlength{\parindentlnth}{\parindent}
    5251
    53 \newlength{\gcolumnposn}
     52\newlength{\gcolumnposn}                                % temporary hack because lstlisting does handle tabs correctly
    5453\newlength{\columnposn}
    5554\setlength{\gcolumnposn}{2.5in}
    … …  
    6261%\patchcmd{\lsthk@TextStyle}{\let\lst@DefEsc\@empty}{}{}{\errmessage{failed to patch}}
    6362
    64 \usepackage{pslatex}                                                                    % reduce size of san serif font
    65 \usepackage{relsize}                                    % must be after change to small or selects old size
     63\usepackage{pslatex}                                    % reduce size of san serif font
     64\usepackage{relsize}                                    % must be after change to small or selects old size
    6665
    6766% reduce size of chapter/section titles
    … …  
    119118
    120119% inline text and lowercase index: \Index{inline and lowercase index text}
     120\newcommand{\Index}{\@ifstar\@sIndex\@Index}
    121121% inline text and as-in index: \Index[as-is index text]{inline text}
     122\newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    122123% inline text but index with different as-is text: \Index[index text]{inline text}
    123 \newcommand{\Index}{\@ifstar\@sIndex\@Index}
    124 \newcommand{\@Index}[2][\@empty]{\lowercase{\def\temp{#2}}#2\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    125124\newcommand{\@sIndex}[2][\@empty]{#2\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
    126125
    127 % cannot use ©
     126% inline text and code index (cannot use ©)
    128127\newcommand{\Indexc}[1]{\lstinline$#1$\index{#1@\lstinline$#1$}}
     128% code index (cannot use ©)
    129129\newcommand{\indexc}[1]{\index{#1@\lstinline$#1$}}
    130130
    … …  
    136136\newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    137137\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
     138
     139% Latin abbreviation
     140\newcommand{\abbrevFont}{\textit}       % set empty for no italics
     141\newcommand*{\eg}{%
     142        \@ifnextchar{,}{\abbrevFont{e}.\abbrevFont{g}.}%
     143                {\@ifnextchar{:}{\abbrevFont{e}.\abbrevFont{g}.}%
     144                        {\abbrevFont{e}.\abbrevFont{g}.,\xspace}}%
     145}%
     146\newcommand*{\ie}{%
     147        \@ifnextchar{,}{\abbrevFont{i}.\abbrevFont{e}.}%
     148                {\@ifnextchar{:}{\abbrevFont{i}.\abbrevFont{e}.}%
     149                        {\abbrevFont{i}.\abbrevFont{e}.,\xspace}}%
     150}%
     151\newcommand*{\etc}{%
     152        \@ifnextchar{.}{\abbrevFont{etc}}%
     153        {\abbrevFont{etc}.\xspace}%
     154}%
     155\newcommand{\etal}{%
     156        \@ifnextchar{.}{\abbrevFont{et~al}}%
     157                {\abbrevFont{et al}.\xspace}%
     158}%
    138159\makeatother
    139160
    … …  
    144165        \endlist
    145166}% quote2
     167
    146168\newenvironment{rationale}{%
    147169  \begin{quote2}\noindent$\Box$\enspace
    … …  
    187209\newcommand{\VPageref}[2][page]{\ifx#1\@empty\else{#1}\nobreakspace\fi\pageref{#2}}
    188210
    189 % Go programming language
     211% Go programming language: https://github.com/julienc91/listings-golang/blob/master/listings-golang.sty
    190212\lstdefinelanguage{Golang}{
    191213        morekeywords=[1]{package,import,func,type,struct,return,defer,panic, recover,select,var,const,iota,},%
    … …  
    203225}
    204226
    205 % CFA programming language, based on ANSI C
     227% CFA programming language, based on ANSI C (with some gcc additions)
    206228\lstdefinelanguage{CFA}[ANSI]{C}{
    207229        morekeywords={_Alignas,_Alignof,__alignof,__alignof__,asm,__asm,__asm__,_At,_Atomic,__attribute,__attribute__,auto,
    208230                _Bool,catch,catchResume,choose,_Complex,__complex,__complex__,__const,__const__,disable,dtype,enable,__extension__,
    209                 fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,__label__,lvalue,_Noreturn,otype,restrict,_Static_assert,
     231                fallthrough,fallthru,finally,forall,ftype,_Generic,_Imaginary,inline,__label__,lvalue,_Noreturn,otype,restrict,_Static_assert,
    210232                _Thread_local,throw,throwResume,trait,try,typeof,__typeof,__typeof__,},
    211233}%
    … …  
    214236language=CFA,
    215237columns=fullflexible,
    216 basicstyle=\linespread{0.9}\sf,
    217 stringstyle=\tt,
    218 tabsize=4,
    219 xleftmargin=\parindentlnth,
    220 extendedchars=true,
    221 escapechar=§,
    222 mathescape=true,
    223 keepspaces=true,
    224 showstringspaces=false,
    225 showlines=true,
    226 aboveskip=4pt,
     238basicstyle=\linespread{0.9}\sf,                 % reduce line spacing and use sanserif font
     239stringstyle=\tt,                                                % use typewriter font
     240tabsize=4,                                                              % 4 space tabbing
     241xleftmargin=\parindentlnth,                             % indent code to paragraph indentation
     242extendedchars=true,                                             % allow ASCII characters in the range 128-255
     243escapechar=§,                                                   % escape to latex in CFA code
     244mathescape=true,                                                % allow $...$ LaTeX math escapes in code
     245%keepspaces=true,                                               %
     246showstringspaces=false,                                 % do not show spaces with cup
     247showlines=true,                                                 % show blank lines at end of code
     248aboveskip=4pt,                                                  % spacing above/below code block
    227249belowskip=3pt,
    228 moredelim=**[is][\color{red}]{®}{®}, % red highlighting
    229 moredelim=**[is][\color{blue}]{ß}{ß}, % blue highlighting
     250moredelim=**[is][\color{red}]{®}{®},    % red highlighting
     251moredelim=**[is][\color{blue}]{ß}{ß},   % blue highlighting
    230252moredelim=**[is][\color{OliveGreen}]{¢}{¢}, % green highlighting
    231253moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % temporarily turn off keywords
    … …  
    233255literate={-}{\raisebox{-0.15ex}{\texttt{-}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
    234256        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {_}{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}1 {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
    235         {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {...}{$\dots$}2,
     257        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2,
    236258}%
    237259
    … …  
    241263\renewcommand\thebibliography[1]{
    242264  \Oldthebibliography{#1}
    243   \setlength{\parskip}{0pt}                     % reduce vertical spacing between references
     265  \setlength{\parskip}{0pt}                             % reduce vertical spacing between references
    244266  \setlength{\itemsep}{5pt plus 0.3ex}
    245267}%

  • doc/bibliography/cfa.bib

    r950f7a7 r7527e63  
    832832    address     = {http://www.iso.org},
    833833    year        = 2012,
     834}
     835
     836@manual{C++Concepts,
     837        keywords = {ISO/IEC TS 19217:2015},
     838        contributer = {a3moss@uwaterloo.ca},
     839        key = {C++ Concepts},
     840        title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
     841        organization = {International Standard ISO/IEC TS 19217:2015},
     842        publisher = {International Standard Organization},
     843        address = {http://www.iso.org},
     844        year = 2015
    834845}
    835846
    … …  
    16231634    year        = 1974,
    16241635}
     1636
     1637@unpublished{Ditchfield:conversions,
     1638        contributer = {a3moss@uwaterloo.ca},
     1639        author = {Glen Ditchfield},
     1640        title = {Conversions for {Cforall}},
     1641        note = {\href{http://plg.uwaterloo.ca/~cforall/Conversions/index.html}{http://\-plg.uwaterloo.ca/\-\textasciitilde cforall/\-Conversions/\-index.html}},
     1642        month = {Nov},
     1643        year = {2002},
     1644        urldate = {28 July 2016},
     1645}
     1646
    16251647
    16261648@techreport{Dijkstra65,
    … …  
    46634685}
    46644686
     4687@article{Ganzinger80,
     4688        contributer = {a3moss@uwaterloo.ca},
     4689        author = {Ganzinger, Harald and Ripken, Knut},
     4690        title = {Operator Identification in {ADA}: Formal Specification, Complexity, and Concrete Implementation},
     4691        journal = {SIGPLAN Notices},
     4692        issue_date = {February 1980},
     4693        volume = {15},
     4694        number = {2},
     4695        month = feb,
     4696        year = {1980},
     4697        issn = {0362-1340},
     4698        pages = {30--42},
     4699        numpages = {13},
     4700        url = {http://doi.acm.org/10.1145/947586.947589},
     4701        doi = {10.1145/947586.947589},
     4702        publisher = {ACM},
     4703        address = {New York, NY, USA}
     4704}
     4705
    46654706@article{Ford82,
    46664707    keywords    = {},
    … …  
    58295870}
    58305871
     5872@article{Pennello80,
     5873        contributer = {a3moss@uwaterloo.ca},
     5874        author = {Pennello, Tom and DeRemer, Frank and Meyers, Richard},
     5875        title = {A Simplified Operator Identification Scheme for {Ada}},
     5876        journal = {SIGPLAN Notices},
     5877        issue_date = {July-August 1980},
     5878        volume = {15},
     5879        number = {7 and 8},
     5880        month = jul,
     5881        year = {1980},
     5882        issn = {0362-1340},
     5883        pages = {82--87},
     5884        numpages = {6},
     5885        url = {http://doi.acm.org/10.1145/947680.947688},
     5886        doi = {10.1145/947680.947688},
     5887        publisher = {ACM},
     5888        address = {New York, NY, USA},
     5889}
     5890
    58315891@inproceedings{Dice10,
    58325892    keywords    = {hardware, synchronization, transactional memory},

  • doc/user/user.tex

    r950f7a7 r7527e63  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Wed Jul 13 08:14:39 2016
    14 %% Update Count     : 1247
     13%% Last Modified On : Sun Aug 14 08:23:06 2016
     14%% Update Count     : 1323
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    211211however, it largely extended the language, and did not address many existing problems.\footnote{%
    212212Two 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.}
    213 \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 (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language.
     213\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.
    214214\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.
    215215These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
    … …  
    226226
    227227\section{Interoperability}
     228\label{s:Interoperability}
    228229
    229230\CFA is designed to integrate well with existing C programs and libraries.
    … …  
    265266\section[Compiling CFA Program]{Compiling \CFA Program}
    266267
    267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, e.g.:
     268The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg:
    268269\begin{lstlisting}
    269270cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
    … …  
    314315The \CFA compilation message is printed at the beginning of a compilation.
    315316\textbf{This option is the default.}
     317
     318\item
     319\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
     320Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
     321\textbf{This option is \emph{not} the default.}
    316322\end{description}
    317323
    … …  
    350356\section{Underscores in Constants}
    351357
    352 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
     358Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg:
    353359\begin{lstlisting}
    3543602®_®147®_®483®_®648;                    §\C{// decimal constant}§
    … …  
    366372\begin{enumerate}
    367373\item
    368 A sequence of underscores is disallowed, e.g., ©12__34© is invalid.
     374A sequence of underscores is disallowed, \eg ©12__34© is invalid.
    369375\item
    370376Underscores may only appear within a sequence of digits (regardless of the digit radix).
    371 In 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).
     377In 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).
    372378\item
    373379A numeric prefix may end with an underscore;
    … …  
    498504\end{quote2}
    499505
    500 All type qualifiers, e.g., ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, e.g.:
     506All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
    501507\begin{quote2}
    502508\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
    … …  
    518524\end{tabular}
    519525\end{quote2}
    520 All declaration qualifiers, e.g., ©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}
    521 The 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.:
     526All 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}
     527The 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:
    522528\begin{quote2}
    523529\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
    … …  
    542548Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{
    543549At 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}}
    544 e.g.:
     550\eg:
    545551\begin{lstlisting}
    546552x;                                                              §\C{// int x}§
    … …  
    612618A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime.
    613619(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)
    614 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:
     620Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
    615621\begin{quote2}
    616622\begin{tabular}{@{}ll@{}}
    … …  
    669675Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
    670676Hence, a reference behaves like the variable name for the current variable it is pointing-to.
    671 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.:
     677The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg:
    672678\begin{lstlisting}
    673679r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15);
    … …  
    677683®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
    678684\end{lstlisting}
    679 When a reference operation appears beside a dereference operation, e.g., ©&*©, they cancel out.\footnote{
     685When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{
    680686The unary ©&© operator yields the address of its operand.
    681687If the operand has type ``type'', the result has type ``pointer to type''.
    … …  
    721727®&®crc = &cx;                                   §\C{// error, cannot change crc}§
    722728\end{lstlisting}
    723 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, e.g.:
     729Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg:
    724730\begin{lstlisting}
    725731int & const r = *0;                             §\C{// where 0 is the int * zero}§
    726732\end{lstlisting}
    727733Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented.
     734Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     735The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
     736\CFA-style declarations attempt to address this issue:
     737\begin{quote2}
     738\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     739\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
     740\begin{lstlisting}
     741®const® * ®const® * const int ccp;
     742®const® & ®const® & const int ccr;
     743\end{lstlisting}
     744&
     745\begin{lstlisting}
     746const int * ®const® * ®const® ccp;
     747
     748\end{lstlisting}
     749\end{tabular}
     750\end{quote2}
     751where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
    728752
    729753\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
    … …  
    783807
    784808
     809\section{Backquote Identifiers}
     810\label{s:BackquoteIdentifiers}
     811
     812\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
     813\begin{lstlisting}
     814int `otype` = 3;                                // make keyword an identifier
     815double `choose` = 3.5;
     816\end{lstlisting}
     817Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.
     818Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
     819\begin{lstlisting}
     820// include file uses the CFA keyword "otype".
     821#if ! defined( otype )                  // nesting ?
     822#define otype `otype`
     823#define __CFA_BFD_H__
     824#endif // ! otype
     825
     826#include_next <bfd.h>                   // must have internal check for multiple expansion
     827
     828#if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
     829#undef otype
     830#undef __CFA_BFD_H__
     831#endif // otype && __CFA_BFD_H__
     832\end{lstlisting}
     833
     834
    785835\section{Type Operators}
    786836
    787 The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
     837The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:
    788838\begin{quote2}
    789839\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    805855
    806856\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
    807 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, e.g.:
     857The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    808858\begin{lstlisting}
    809859®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
    … …  
    817867\Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.}
    818868The value of each local return variable is automatically returned at routine termination.
    819 Declaration qualifiers can only appear at the start of a routine definition, e.g.:
     869Declaration qualifiers can only appear at the start of a routine definition, \eg:
    820870\begin{lstlisting}
    821871®extern® [ int x ] g( int y ) {§\,§}
    … …  
    849899The 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.
    850900
    851 C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:
     901C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    852902\begin{lstlisting}
    853903[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
    … …  
    898948
    899949The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
    900 as well, parameter names are optional, e.g.:
     950as well, parameter names are optional, \eg:
    901951\begin{lstlisting}
    902952[ int x ] f ();                                 §\C{// returning int with no parameters}§
    … …  
    906956\end{lstlisting}
    907957This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    908 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), e.g.:
     958It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg:
    909959\begin{quote2}
    910960\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    919969\end{tabular}
    920970\end{quote2}
    921 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} e.g.:
     971Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
    922972\begin{lstlisting}
    923973extern [ int ] f (int);
    … …  
    928978\section{Routine Pointers}
    929979
    930 The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.:
     980The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    931981\begin{lstlisting}
    932982* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
    … …  
    9871037Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
    9881038The former is easy to do, while the latter is more complex.
    989 Currently, \CFA does \emph{not} attempt to support named arguments.
     1039
     1040Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
     1041For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
     1042\begin{lstlisting}
     1043int f( int i, int j );
     1044int f( int x, double y );
     1045
     1046f( j : 3, i : 4 );                              §\C{// 1st f}§
     1047f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
     1048f( 4, 5 );                                              §\C{// ambiguous call}§
     1049\end{lstlisting}
     1050However, named arguments compound routine resolution in conjunction with conversions:
     1051\begin{lstlisting}
     1052f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
     1053\end{lstlisting}
     1054Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
     1055Adding named argument into the routine resolution algorithm does not seem worth the complexity.
     1056Therefore, \CFA does \emph{not} attempt to support named arguments.
    9901057
    9911058\item[Default Arguments]
    … …  
    9971064the allowable positional calls are:
    9981065\begin{lstlisting}
    999 p();                            §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    1000 p( 4 );                         §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
    1001 p( 4, 4 );                      §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
    1002 p( 4, 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
     1066p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
     1067p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     1068p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     1069p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
    10031070// empty arguments
    1004 p(  , 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
    1005 p( 4,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
    1006 p( 4, 4,   );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
    1007 p( 4,  ,   );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
    1008 p(  , 4,   );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
    1009 p(  ,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
    1010 p(  ,  ,   );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
     1071p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
     1072p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
     1073p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
     1074p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
     1075p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
     1076p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
     1077p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    10111078\end{lstlisting}
    10121079Here the missing arguments are inserted from the default values in the parameter list.
    … …  
    10431110The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
    10441111\begin{lstlisting}
    1045 p( /* positional */, . . ., /* named */ );
    1046 p( /* positional */, /* named */, . . . );
    1047 \end{lstlisting}
    1048 While it is possible to implement both approaches, the first possibly is more complex than the second, e.g.:
    1049 \begin{lstlisting}
    1050 p( int x, int y, int z, . . . );
    1051 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§
    1052 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§
     1112p( /* positional */, ... , /* named */ );
     1113p( /* positional */, /* named */, ... );
     1114\end{lstlisting}
     1115While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
     1116\begin{lstlisting}
     1117p( int x, int y, int z, ... );
     1118p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
     1119p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
    10531120\end{lstlisting}
    10541121In 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.
    … …  
    10561123In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
    10571124
    1058 The problem is exacerbated with default arguments, e.g.:
    1059 \begin{lstlisting}
    1060 void p( int x, int y = 2, int z = 3. . . );
    1061 p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, . . ., /* named */ );}§
    1062 p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, . . . );}§
     1125The problem is exacerbated with default arguments, \eg:
     1126\begin{lstlisting}
     1127void p( int x, int y = 2, int z = 3... );
     1128p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
     1129p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
    10631130\end{lstlisting}
    10641131The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
    … …  
    11051172\subsection{Type Nesting}
    11061173
    1107 \CFA allows \Index{type nesting}, and type qualification of the nested types (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
     1174\CFA allows \Index{type nesting}, and type qualification of the nested typres (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
    11081175\begin{figure}
     1176\centering
    11091177\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
    11101178\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
    … …  
    12641332
    12651333As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call.
    1266 In unambiguous situations, the tuple brackets may be omitted, e.g., a tuple that appears as an argument may have its
     1334In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its
    12671335square brackets omitted for convenience; therefore, the following routine invocations are equivalent:
    12681336\begin{lstlisting}
    … …  
    13031371
    13041372Type qualifiers, i.e., const and volatile, may modify a tuple type.
    1305 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, e.g.:
     1373The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg:
    13061374\begin{lstlisting}
    13071375const volatile [ int, float, const int ] x;
    … …  
    13111379[ const volatile int, const volatile float, const volatile int ] x;
    13121380\end{lstlisting}
    1313 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, e.g.:
     1381Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg:
    13141382\begin{lstlisting}
    13151383extern [ int, int ] w1;
    … …  
    13191387Unfortunately, C's syntax for subscripts precluded treating them as tuples.
    13201388The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©.
    1321 Therefore, 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.
     1389Therefore, 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.
    13221390Fixing 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.
    13231391\end{rationale}
    … …  
    13731441Mass assignment has the following form:
    13741442\begin{lstlisting}
    1375 [ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§;
     1443[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
    13761444\end{lstlisting}
    13771445\index{lvalue}
    … …  
    13801448Clearly, the types of the entities being assigned must be type compatible with the value of the expression.
    13811449
    1382 Mass assignment has parallel semantics, e.g., the statement:
     1450Mass assignment has parallel semantics, \eg the statement:
    13831451\begin{lstlisting}
    13841452[ x, y, z ] = 1.5;
    … …  
    14131481Multiple assignment has the following form:
    14141482\begin{lstlisting}
    1415 [ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];
     1483[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
    14161484\end{lstlisting}
    14171485\index{lvalue}
    … …  
    14691537\section{Unnamed Structure Fields}
    14701538
    1471 C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:
     1539C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg:
    14721540\begin{lstlisting}
    14731541struct {
    1474         int f1;                 // named field
    1475         int f2 : 4;             // named field with bit field size
    1476         int : 3;                // unnamed field for basic type with bit field size
    1477         int ;                   // disallowed, unnamed field
    1478         int *;                  // disallowed, unnamed field
    1479         int (*)(int);   // disallowed, unnamed field
     1542        int f1;                                 §\C{// named field}§
     1543        int f2 : 4;                             §\C{// named field with bit field size}§
     1544        int : 3;                                §\C{// unnamed field for basic type with bit field size}§
     1545        int ;                                   §\C{// disallowed, unnamed field}§
     1546        int *;                                  §\C{// disallowed, unnamed field}§
     1547        int (*)(int);                   §\C{// disallowed, unnamed field}§
    14801548};
    14811549\end{lstlisting}
    14821550This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed.
    14831551As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size.
    1484 A list of unnamed fields is also supported, e.g.:
     1552A list of unnamed fields is also supported, \eg:
    14851553\begin{lstlisting}
    14861554struct {
    1487         int , , ;               // 3 unnamed fields
     1555        int , , ;                               §\C{// 3 unnamed fields}§
    14881556}
    14891557\end{lstlisting}
    … …  
    14981566§\emph{expr}§ -> [ §\emph{fieldlist}§ ]
    14991567\end{lstlisting}
    1500 \emph{expr} is any expression yielding a value of type record, e.g., ©struct©, ©union©.
     1568\emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©.
    15011569Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}.
    15021570A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is
    … …  
    17601828}
    17611829\end{lstlisting}
    1762 While 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.
    1763 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©.
    1764 As mentioned, transfer into control structures should be forbidden;
    1765 transfers from within the ©switch© body using a ©goto© are equally unpalatable.
    1766 As well, the declaration of ©z© is 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.
     1830While 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.
     1831Furthermore, 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.
     1832As 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.
     1833The key observation is that the ©switch© statement branches into control structure, i.e., there are multiple entry points into its statement body.
    17671834\end{enumerate}
    17681835
    … …  
    17781845and 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.
    17791846\end{itemize}
    1780 These observations help to put the suggested changes to the ©switch© into perspective.
     1847These observations help to put the \CFA changes to the ©switch© into perspective.
    17811848\begin{enumerate}
    17821849\item
    17831850Eliminating default fall-through has the greatest potential for affecting existing code.
    1784 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, i.e., a list of ©case© clauses executing common code, e.g.:
    1785 \begin{lstlisting}
     1851However, 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, i.e., a list of ©case© clauses executing common code, \eg:
     1852 \begin{lstlisting}
    17861853case 1:  case 2:  case 3: ...
    17871854\end{lstlisting}
    17881855still work.
    17891856Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
    1790 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 ©fallthru©, e.g.:
     1857<<<<<<< HEAD
     1858Therefore, 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 ©fallthru©, \eg:
     1859=======
     1860Therefore, 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©, e.g.:
     1861>>>>>>> 080615890f586cb9954c252b55cab47f52c25758
    17911862\begin{lstlisting}
    17921863®choose® ( i ) {
    … …  
    18151886Therefore, no change is made for this issue.
    18161887\item
    1817 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{
    1818 Essentially, these declarations are hoisted before the statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
    1819 Further declaration in the statement body are disallowed.
     1888Dealing 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{
     1889Essentially, 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.
     1890Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
    18201891\begin{lstlisting}
    18211892switch ( x ) {
    1822         ®int i = 0;®                            §\C{// allowed}§
     1893        ®int i = 0;®                            §\C{// allowed only at start}§
    18231894  case 0:
    18241895        ...
    1825         ®int i = 0;®                            §\C{// disallowed}§
     1896        ®int j = 0;®                            §\C{// disallowed}§
    18261897  case 1:
    18271898    {
    1828                 ®int i = 0;®                    §\C{// allowed in any compound statement}§
     1899                ®int k = 0;®                    §\C{// allowed at different nesting levels}§
    18291900                ...
    18301901        }
    … …  
    18461917\begin{lstlisting}
    18471918switch ( i ) {
    1848   ®case 1, 3, 5®:
     1919  case ®1, 3, 5®:
    18491920        ...
    1850   ®case 2, 4, 6®:
     1921  case ®2, 4, 6®:
    18511922        ...
    18521923}
    … …  
    18791950\begin{lstlisting}
    18801951switch ( i ) {
    1881   ®case 1~5:®
     1952  case ®1~5:®
    18821953        ...
    1883   ®case 10~15:®
     1954  case ®10~15:®
    18841955        ...
    18851956}
    … …  
    18881959\begin{lstlisting}
    18891960switch ( i )
    1890   case 1 ... 5:
     1961  case ®1 ... 5®:
    18911962        ...
    1892   case 10 ... 15:
     1963  case ®10 ... 15®:
    18931964        ...
    18941965}
    … …  
    27072778Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser.
    27082779
    2709 There are several ambiguous cases with operator identifiers, e.g., ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
    2710 Since 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.
     2780There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.
     2781Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.
    27112782Even with this special hack, there are 5 general cases that cannot be handled.
    27122783The first case is for the function-call identifier ©?()©:
    … …  
    27732844This means that a function requiring mutual exclusion could block if the lock is already held by another thread.
    27742845Blocking on a monitor lock does not block the kernel thread, it simply blocks the user thread, which yields its kernel thread while waiting to obtain the lock.
    2775 If multiple mutex parameters are specified, they will be locked in parameter order (i.e. first parameter is locked first) and unlocked in the
     2846If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the
    27762847reverse order.
    27772848\begin{lstlisting}
    … …  
    43504421\begin{description}
    43514422\item[Change:] add new keywords \\
    4352 New keywords are added to \CFA.
     4423New keywords are added to \CFA (see~\VRef{s:NewKeywords}).
    43534424\item[Rationale:] keywords added to implement new semantics of \CFA.
    43544425\item[Effect on original feature:] change to semantics of well-defined feature. \\
    43554426Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
    4356 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
    4357 \begin{lstlisting}
    4358 int `otype` = 3;                                // make keyword an identifier
    4359 double `choose` = 3.5;
    4360 \end{lstlisting}
    4361 Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed.
    4362 Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©:
    4363 \begin{lstlisting}
    4364 // include file uses the CFA keyword "otype".
    4365 #if ! defined( otype )                  // nesting ?
    4366 #define otype `otype`
    4367 #define __CFA_BFD_H__
    4368 #endif // ! otype
    4369 
    4370 #include_next <bfd.h>                   // must have internal check for multiple expansion
    4371 
    4372 #if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
    4373 #undef otype
    4374 #undef __CFA_BFD_H__
    4375 #endif // otype && __CFA_BFD_H__
    4376 \end{lstlisting}
     4427\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):
    43774428\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
    43784429\end{description}
    … …  
    43844435int rtn( int i );
    43854436int rtn( char c );
    4386 rtn( 'x' );                                             // programmer expects 2nd rtn to be called
     4437rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
    43874438\end{lstlisting}
    43884439\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
    … …  
    44064457\item[Change:] make string literals ©const©:
    44074458\begin{lstlisting}
    4408 char * p = "abc";                               // valid in C, deprecated in §\CFA§
    4409 char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§
     4459char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
     4460char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
    44104461\end{lstlisting}
    44114462The type of a string literal is changed from ©[] char© to ©const [] char©.
    … …  
    44144465\begin{lstlisting}
    44154466char * p = "abc";
    4416 p[0] = 'w';                                             // segment fault or change constant literal
     4467p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
    44174468\end{lstlisting}
    44184469The same problem occurs when passing a string literal to a routine that changes its argument.
    … …  
    44264477\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
    44274478\begin{lstlisting}
    4428 int i;                                                  // forward definition
    4429 int *j = ®&i®;                                  // forward reference, valid in C, invalid in §\CFA§
    4430 int i = 0;                                              // definition
     4479int i;                                                  §\C{// forward definition}§
     4480int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
     4481int i = 0;                                              §\C{// definition}§
    44314482\end{lstlisting}
    44324483is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
    … …  
    44344485\begin{lstlisting}
    44354486struct X { int i; struct X *next; };
    4436 static struct X a;                              // forward definition
    4437 static struct X b = { 0, ®&a® };        // forward reference, valid in C, invalid in §\CFA§
    4438 static struct X a = { 1, &b };  // definition
     4487static struct X a;                              §\C{// forward definition}§
     4488static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
     4489static struct X a = { 1, &b };  §\C{// definition}§
    44394490\end{lstlisting}
    44404491\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
    … …  
    44464497\item
    44474498\begin{description}
    4448 \item[Change:] have ©struct© introduce a scope for nested types
    4449 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing
    4450 Example:
     4499\item[Change:] have ©struct© introduce a scope for nested types:
    44514500\begin{lstlisting}
    44524501enum ®Colour® { R, G, B, Y, C, M };
    44534502struct Person {
    4454         enum ®Colour® { R, G, B };      // nested type
    4455         struct Face {                           // nested type
    4456                 ®Colour® Eyes, Hair;            // type defined outside (1 level)
     4503        enum ®Colour® { R, G, B };      §\C{// nested type}§
     4504        struct Face {                           §\C{// nested type}§
     4505                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
    44574506        };
    4458         ß.ß®Colour® shirt;                              // type defined outside (top level)
    4459         ®Colour® pants;                         // type defined same level
    4460         Face looks[10];                         // type defined same level
     4507        ß.ß®Colour® shirt;                      §\C{// type defined outside (top level)}§
     4508        ®Colour® pants;                         §\C{// type defined same level}§
     4509        Face looks[10];                         §\C{// type defined same level}§
    44614510};
    4462 ®Colour® c = R;                                 // type/enum defined same level
    4463 Personß.ß®Colour® pc = Personß.ßR;      // type/enum defined inside
    4464 Personß.ßFace pretty;                           // type defined inside
    4465 \end{lstlisting}
     4511®Colour® c = R;                                 §\C{// type/enum defined same level}§
     4512Personß.ß®Colour® pc = Personß.ßR;      §\C{// type/enum defined inside}§
     4513Personß.ßFace pretty;                   §\C{// type defined inside}§
     4514\end{lstlisting}
     4515In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.
     4516\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
     4517Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    44664518\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
    44674519\item[Effect on original feature:] change to semantics of well-defined feature.
    44684520\item[Difficulty of converting:] Semantic transformation.
    44694521\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
    4470 
    4471 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
    4472 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
    4473 Given 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.
    44744522\end{description}
    44754523
    … …  
    44804528\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:
    44814529\begin{lstlisting}
    4482 struct Y; // struct Y and struct X are at the same scope
     4530struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
    44834531struct X {
    44844532struct Y { /* ... */ } y;
    … …  
    45014549
    45024550
     4551\section{New Keywords}
     4552\label{s:NewKeywords}
     4553
     4554\begin{quote2}
     4555\begin{tabular}{lll}
     4556©catch©                 & ©fallthrough© & ©otype©               \\
     4557©catchResume©   & ©fallthru©    & ©throw©               \\
     4558©choose©                & ©finally©             & ©throwResume© \\
     4559©disable©               & ©forall©              & ©trait©               \\
     4560©dtype©                 & ©ftype©               & ©try©                 \\
     4561©enable©                & ©lvalue©              &                               \\
     4562\end{tabular}
     4563\end{quote2}
     4564
     4565
     4566\section{Standard Headers}
     4567\label{s:StandardHeaders}
     4568
     4569C prescribes the following standard header-files~\cite[\S~7.1.2]{C11}:
     4570\begin{quote2}
     4571\begin{minipage}{\linewidth}
     4572\begin{tabular}{lll}
     4573assert.h        & math.h                & stdlib.h              \\
     4574complex.h       & setjmp.h              & stdnoreturn.h \\
     4575ctype.h         & signal.h              & string.h              \\
     4576errno.h         & stdalign.h    & tgmath.h              \\
     4577fenv.h          & stdarg.h              & threads.h             \\
     4578float.h         & stdatomic.h   & time.h                \\
     4579inttypes.h      & stdbool.h             & uchar.h               \\
     4580iso646.h        & stddef.h              & wchar.h               \\
     4581limits.h        & stdint.h              & wctype.h              \\
     4582locale.h        & stdio.h               & unistd.h\footnote{\CFA extension}
     4583\end{tabular}
     4584\end{minipage}
     4585\end{quote2}
     4586For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©;
     4587hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
     4588All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
     4589
     4590
    45034591\section{I/O Library}
    45044592\label{s:IOLibrary}
    … …  
    45704658%$
    45714659\begin{lstlisting}[mathescape=off]
    4572 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7 | "x ¿" | 8 | "x «" | 9 | endl;
     4660sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x $" | 4 | "x £" | 5 | "x ¥" | 6 | "x ¡" | 7
     4661         | "x ¿" | 8 | "x «" | 9 | endl;
    45734662\end{lstlisting}
    45744663%$
    … …  
    45804669A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»©
    45814670\begin{lstlisting}[belowskip=0pt]
    4582 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | ") x" | 8 | "] x" | 9 | "} x"
    4583          | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
     4671sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7
     4672         | ") x" | 8 | "] x" | 9 | "} x" | 10 | "% x" | 11 | "¢ x" | 12 | "» x" | endl;
    45844673\end{lstlisting}
    45854674\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    45974686The following \CC-style \Index{manipulator}s allow further control over implicit seperation.
    45984687\begin{lstlisting}[mathescape=off,belowskip=0pt]
    4599 sout | sepOn | 1 | 2 | 3 | sepOn | endl;        // separator at start of line
     4688sout | sepOn | 1 | 2 | 3 | sepOn | endl;        §\C{// separator at start of line}§
    46004689\end{lstlisting}
    46014690\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46034692\end{lstlisting}
    46044693\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4605 sout | 1 | sepOff | 2 | 3 | endl;                       // turn off implicit separator temporarily
     4694sout | 1 | sepOff | 2 | 3 | endl;                       §\C{// turn off implicit separator temporarily}§
    46064695\end{lstlisting}
    46074696\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46094698\end{lstlisting}
    46104699\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4611 sout | sepDisable | 1 | 2 | 3 | endl;           // turn off implicit separation, affects all subsequent prints
     4700sout | sepDisable | 1 | 2 | 3 | endl;           §\C{// turn off implicit separation, affects all subsequent prints}§
    46124701\end{lstlisting}
    46134702\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46154704\end{lstlisting}
    46164705\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4617 sout | 1 | sepOn | 2 | 3 | endl;                        // turn on implicit separator temporarily
     4706sout | 1 | sepOn | 2 | 3 | endl;                        §\C{// turn on implicit separator temporarily}§
    46184707\end{lstlisting}
    46194708\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46214710\end{lstlisting}
    46224711\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]
    4623 sout | sepEnable | 1 | 2 | 3 | endl;            // turn on implicit separation, affects all subsequent prints
     4712sout | sepEnable | 1 | 2 | 3 | endl;            §\C{// turn on implicit separation, affects all subsequent prints}§
    46244713\end{lstlisting}
    46254714\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]
    … …  
    46274716\end{lstlisting}
    46284717\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]
    4629 sepSet( sout, ", $" );                                          // change separator from " " to ", $"
     4718sepSet( sout, ", $" );                                          §\C{// change separator from " " to ", \$"}§
    46304719sout | 1 | 2 | 3 | endl;
    46314720\end{lstlisting}
    … …  
    46734762\subsection{malloc}
    46744763
     4764\leavevmode
    46754765\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    46764766forall( otype T ) T * malloc( void );§\indexc{malloc}§
    … …  
    46894779forall( otype T ) T * memset( T * ptr );                                // remove when default value available
    46904780\end{lstlisting}
    4691 \
     4781
    46924782
    46934783\subsection{ato / strto}
    46944784
     4785\leavevmode
    46954786\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    46964787int ato( const char * ptr );§\indexc{ato}§
    … …  
    47204811long double _Complex strto( const char * sptr, char ** eptr );
    47214812\end{lstlisting}
    4722 \
    47234813
    47244814
    47254815\subsection{bsearch / qsort}
    47264816
     4817\leavevmode
    47274818\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47284819forall( otype T | { int ?<?( T, T ); } )
    … …  
    47324823void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
    47334824\end{lstlisting}
    4734 \
    47354825
    47364826
    47374827\subsection{abs}
    47384828
     4829\leavevmode
    47394830\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47404831char abs( char );§\indexc{abs}§
    … …  
    47494840long double abs( long double _Complex );
    47504841\end{lstlisting}
    4751 \
    47524842
    47534843
    47544844\subsection{random}
    47554845
     4846\leavevmode
    47564847\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47574848void rand48seed( long int s );§\indexc{rand48seed}§
    … …  
    47674858long double _Complex rand48();
    47684859\end{lstlisting}
    4769 \
    47704860
    47714861
    47724862\subsection{min / max / clamp / swap}
    47734863
     4864\leavevmode
    47744865\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47754866forall( otype T | { int ?<?( T, T ); } )
    … …  
    47854876void swap( T * t1, T * t2 );§\indexc{swap}§
    47864877\end{lstlisting}
    4787 \
    47884878
    47894879
    … …  
    47964886\subsection{General}
    47974887
     4888\leavevmode
    47984889\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    47994890float fabs( float );§\indexc{fabs}§
    … …  
    48414932long double nan( const char * );
    48424933\end{lstlisting}
    4843 \
    48444934
    48454935
    48464936\subsection{Exponential}
    48474937
     4938\leavevmode
    48484939\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    48494940float exp( float );§\indexc{exp}§
    … …  
    48984989long double logb( long double );
    48994990\end{lstlisting}
    4900 \
    49014991
    49024992
    49034993\subsection{Power}
    49044994
     4995\leavevmode
    49054996\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49064997float sqrt( float );§\indexc{sqrt}§
    … …  
    49265017long double _Complex pow( long double _Complex, long double _Complex );
    49275018\end{lstlisting}
    4928 \
    49295019
    49305020
    49315021\subsection{Trigonometric}
    49325022
     5023\leavevmode
    49335024\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49345025float sin( float );§\indexc{sin}§
    … …  
    49825073long double atan( long double, long double );
    49835074\end{lstlisting}
    4984 \
    49855075
    49865076
    49875077\subsection{Hyperbolic}
    49885078
     5079\leavevmode
    49895080\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    49905081float sinh( float );§\indexc{sinh}§
    … …  
    50305121long double _Complex atanh( long double _Complex );
    50315122\end{lstlisting}
    5032 \
    50335123
    50345124
    50355125\subsection{Error / Gamma}
    50365126
     5127\leavevmode
    50375128\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50385129float erf( float );§\indexc{erf}§
    … …  
    50615152long double tgamma( long double );
    50625153\end{lstlisting}
    5063 \
    50645154
    50655155
    50665156\subsection{Nearest Integer}
    50675157
     5158\leavevmode
    50685159\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    50695160float floor( float );§\indexc{floor}§
    … …  
    51155206long long int llround( long double );
    51165207\end{lstlisting}
    5117 \
    51185208
    51195209
    51205210\subsection{Manipulation}
    51215211
     5212\leavevmode
    51225213\begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
    51235214float copysign( float, float );§\indexc{copysign}§
    … …  
    51565247long double scalbln( long double, long int );
    51575248\end{lstlisting}
    5158 \
    51595249
    51605250
    … …  
    51625252\label{s:RationalNumbers}
    51635253
    5164 Rational numbers are numbers written as a ratio, i.e., as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
     5254Rational numbers are numbers written as a ratio, \ie as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.
    51655255When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible.
    51665256

  • doc/working/resolver_design.md

    r950f7a7 r7527e63  
    3737
    3838An alternate possibility would be to only count two-arg constructors
    39 `void ?{} ( To*, From )` as unsafe conversions; under this semantics, safe and  
     39`void ?{} ( To*, From )` as unsafe conversions; under this semantics, safe and
    4040explicit conversions should also have a compiler-enforced restriction to
    4141ensure that they are two-arg functions (this restriction may be valuable
    … …  
    6969two chains of conversions, one among the signed integral types, another among
    7070the unsigned, and to use monomorphic conversions to allow conversions between
    71 signed and unsigned integer types).   
     71signed and unsigned integer types).
    7272
    7373### Implementation Details ###
    … …  
    509509A variant of the above scheme would be to fix a maximum depth of polymorphic
    510510type variables (16 seems like a reasonable choice) at which a parameter would
    511 be considered to be effectively monomorphic, and to subtract the value  
     511be considered to be effectively monomorphic, and to subtract the value
    512512described above from that maximum, clamping the result to a minimum of 0.
    513513Under this scheme, assuming a maximum value of 4, `int` has value 0, `T` has
    … …  
    577577specifying the (completely arbitrary) maximum depth as part of the language or
    578578allowing the compiler to refuse to accept otherwise well-typed deeply-nested
    579 polymorphic types. 
     579polymorphic types.
    580580
    581581For purposes of determining polymorphism, the list of return types of a
    … …  
    951951`sizeof`, `alignof`, and `offsetof` expressions have at most a single
    952952interpretation, of type `size_t`.
    953 `sizeof` and `alignof` expressions take either a type or an expression as a 
    954 an argument; if the argument is a type, it must be a complete type which is
    955 not a function type, if an expression, the expression must have a single
     953`sizeof` and `alignof` expressions take either a type or an expression as an
     954argument; if the argument is a type, it must be a complete type which is not a
     955function type, if an expression, the expression must have a single
    956956interpretation, the type of which conforms to the same rules.
    957957`offsetof` takes two arguments, a type and a member name; the type must be
    … …  
    16201620                        = delete;
    16211621        }
     1622
     1623## Appendix E: Features to Add in Resolver Re-write ##
     1624* Reference types
     1625* Special types for 0 and 1 literals
     1626* Expression type for return statement that resolves similarly to ?=?
     1627  - This is to get rid of the kludge in the box pass that effectively
     1628    re-implements the resolver poorly.
Note: See TracChangeset for help on using the changeset viewer.