Changeset 95b3a9c


Ignore:
Timestamp:
Feb 17, 2021, 12:45:36 PM (8 months ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
arm-eh, jacob/cs343-translation, master, new-ast-unique-expr
Children:
e7c077a
Parents:
5e99a9a (diff), 9fb1367 (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

Files:
11 added
30 edited

Legend:

Unmodified
Added
Removed
  • doc/LaTeXmacros/common.tex

    r5e99a9a r95b3a9c  
    1111%% Created On       : Sat Apr  9 10:06:17 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Thu Jan 28 19:01:57 2021
    14 %% Update Count     : 494
     13%% Last Modified On : Sun Feb 14 15:52:46 2021
     14%% Update Count     : 524
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    3737
    3838\usepackage{xspace}
    39 \newcommand{\CFAIcon}{\textsf{C}\raisebox{\depth}{\rotatebox{180}{\textsf{A}}}\xspace} % Cforall symbolic name
    40 \newcommand{\CFA}{\protect\CFAIcon}             % safe for section/caption
    41 \newcommand{\CFL}{\textrm{Cforall}\xspace} % Cforall symbolic name
    42 \newcommand{\Celeven}{\textrm{C11}\xspace} % C11 symbolic name
    43 \newcommand{\CC}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}\xspace} % C++ symbolic name
    44 \newcommand{\CCeleven}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name
    45 \newcommand{\CCfourteen}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}14\xspace} % C++14 symbolic name
    46 \newcommand{\CCseventeen}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}17\xspace} % C++17 symbolic name
    47 \newcommand{\CCtwenty}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
     39\newcommand{\CFAIcon}{\textsf{C}\raisebox{\depth}{\rotatebox{180}{\textsf{A}}}} % Cforall icon
     40\newcommand{\CFA}{\protect\CFAIcon\xspace}                      % CFA symbolic name
     41\newcommand{\CFL}{\textrm{Cforall}\xspace}                      % Cforall non-icon name
     42\newcommand{\Celeven}{\textrm{C11}\xspace}                      % C11 symbolic name
     43\newcommand{\CCIcon}{\textrm{C}\kern-.1em\hbox{+\kern-.25em+}} % C++ icon
     44\newcommand{\CC}{\protect\CCIcon\xspace}                        % C++ symbolic name
     45% numbers disallowed in latex variables names => use number names
     46\newcommand{\CCeleven}{\protect\CCIcon{11}\xspace}      % C++11 symbolic name
     47\newcommand{\CCfourteen}{\protect\CCIcon{14}\xspace} % C++14 symbolic name
     48\newcommand{\CCseventeen}{\protect\CCIcon{17}\xspace} % C++17 symbolic name
     49\newcommand{\CCtwenty}{\protect\CCIcon{20}\xspace}      % C++20 symbolic name
    4850\newcommand{\Csharp}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace} % C# symbolic name
    4951
    5052%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    5153
     54% remove special-character warning in PDF side-bar names
    5255\makeatletter
     56\@ifpackageloaded{hyperref}{
     57  \pdfstringdefDisableCommands{
     58  \def\CFA{\CFL}
     59  \def\Celeven{C11\xspace}
     60  \def\CC{C++\xspace}
     61  \def\CCeleven{C++11\xspace}
     62  \def\CCfourteen{C++14\xspace}
     63  \def\CCseventeen{C++17\xspace}
     64  \def\CCtwenty{C++20\xspace}
     65  \def\Csharp{C\#\xspace}
     66  \def\lstinline{\xspace}% must use {} as delimiters, e.g., \lstinline{...}
     67  }{}
     68}
     69
    5370% parindent is relative, i.e., toggled on/off in environments like itemize, so store the value for
    5471% use rather than use \parident directly.
     
    8198    \vskip 50\p@
    8299  }}
    83 \renewcommand\section{\@startsection{section}{1}{\z@}{-3.5ex \@plus -1ex \@minus -.2ex}{1.75ex \@plus .2ex}{\normalfont\large\bfseries}}
    84 \renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-3.25ex \@plus -1ex \@minus -.2ex}{1.5ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
     100\renewcommand\section{\@startsection{section}{1}{\z@}{-3.0ex \@plus -1ex \@minus -.2ex}{1.5ex \@plus .2ex}{\normalfont\large\bfseries}}
     101\renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-2.75ex \@plus -1ex \@minus -.2ex}{1.25ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    85102\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
    86103\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}{-2.0ex \@plus -1ex \@minus -.2ex}{-1em}{\normalfont\normalsize\bfseries}}
     
    129146% The star version does not lowercase the index information, e.g., \newterm*{IBM}.
    130147\newcommand{\newtermFontInline}{\emph}
    131 \newcommand{\newterm}{\@ifstar\@snewterm\@newterm}
     148\newcommand{\newterm}{\protect\@ifstar\@snewterm\@newterm}
    132149\newcommand{\@newterm}[2][\@empty]{\lowercase{\def\temp{#2}}{\newtermFontInline{#2}}\ifx#1\@empty\index{\temp}\else\index{#1@{\protect#2}}\fi}
    133150\newcommand{\@snewterm}[2][\@empty]{{\newtermFontInline{#2}}\ifx#1\@empty\index{#2}\else\index{#1@{\protect#2}}\fi}
     
    235252\newcommand{\LstKeywordStyle}[1]{{\lst@basicstyle{\lst@keywordstyle{#1}}}}
    236253\newcommand{\LstCommentStyle}[1]{{\lst@basicstyle{\lst@commentstyle{#1}}}}
     254\newcommand{\LstStringStyle}[1]{{\lst@basicstyle{\lst@stringstyle{#1}}}}
    237255
    238256\newlength{\gcolumnposn}                                % temporary hack because lstlisting does not handle tabs correctly
     
    260278xleftmargin=\parindentlnth,                             % indent code to paragraph indentation
    261279extendedchars=true,                                             % allow ASCII characters in the range 128-255
    262 escapechar=§,                                                   % LaTeX escape in CFA code §...§ (section symbol), emacs: C-q M-'
    263 mathescape=true,                                                % LaTeX math escape in CFA code $...$
     280escapechar=\$,                                                  % LaTeX escape in CFA code §...§ (section symbol), emacs: C-q M-'
     281mathescape=false,                                               % LaTeX math escape in CFA code $...$
    264282keepspaces=true,                                                %
    265283showstringspaces=false,                                 % do not show spaces with cup
    266284showlines=true,                                                 % show blank lines at end of code
    267285aboveskip=4pt,                                                  % spacing above/below code block
    268 belowskip=-2pt,
     286belowskip=0pt,
    269287numberstyle=\footnotesize\sf,                   % numbering style
    270288% replace/adjust listing characters that look bad in sanserif
     
    276294
    277295\ifdefined\CFALatin% extra Latin-1 escape characters
    278 \lstnewenvironment{cfa}[1][]{
     296\lstnewenvironment{cfa}[1][]{% necessary
    279297\lstset{
    280298language=CFA,
    281 moredelim=**[is][\color{red}]{®}{®},    % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
    282 moredelim=**[is][\color{blue}]{ß}{ß},   % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    283 moredelim=**[is][\color{OliveGreen}]{¢}{¢}, % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    284 moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    285 % replace/adjust listing characters that look bad in sanserif
    286 add to literate={`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
     299moredelim=**[is][\color{red}]{@}{@},    % red highlighting @...@
     300%moredelim=**[is][\color{red}]{®}{®},   % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
     301%moredelim=**[is][\color{blue}]{ß}{ß},  % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
     302%moredelim=**[is][\color{OliveGreen}]{¢}{¢}, % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
     303%moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    287304}% lstset
    288 \lstset{#1}
     305\lstset{#1}% necessary
    289306}{}
    290307% inline code ©...© (copyright symbol) emacs: C-q M-)
    291308\lstMakeShortInline©                                    % single-character for \lstinline
    292309\else% regular ASCI characters
    293 \lstnewenvironment{cfa}[1][]{
     310\lstnewenvironment{cfa}[1][]{% necessary
    294311\lstset{
    295312language=CFA,
     
    298315moredelim=**[is][\color{red}]{@}{@},    % red highlighting @...@
    299316}% lstset
    300 \lstset{#1}
     317\lstset{#1}% necessary
    301318}{}
    302319% inline code @...@ (at symbol)
  • doc/papers/concurrency/mail2

    r5e99a9a r95b3a9c  
    12881288
    12891289
     1290From: "Wiley Online Proofing" <onlineproofing@eproofing.in>
     1291To: pabuhr@uwaterloo.ca
     1292Reply-To: eproofing@wiley.com
     1293Date: 3 Nov 2020 08:25:06 +0000
     1294Subject: Action: Proof of SPE_EV_SPE2925 for Software: Practice And Experience ready for review
     1295
     1296Dear Dr. Peter Buhr,
     1297
     1298The proof of your Software: Practice And Experience article Advanced control-flow in Cforall is now available for review:
     1299
     1300Edit Article https://wiley.eproofing.in/Proof.aspx?token=ab7739d5678447fbbe5036f3bcba2445081500061
     1301
     1302To review your article, please complete the following steps, ideally within 48 hours*, so we can publish your article as quickly as possible.
     1303
     13041. Open your proof in the online proofing system using the button above.
     13052. Check the article for correctness and respond to all queries.For instructions on using the system, please see the "Help" menu in the upper right corner.
     13063. Submit your changes by clicking the "Submit" button in the proofing system.
     1307
     1308Helpful Tips
     1309
     1310*  Your manuscript has been formatted following the style requirements for the journal. Any requested changes that go against journal style will not be made.
     1311*  Your proof will include queries. These must be replied to using the system before the proof can be submitted.
     1312*  The only acceptable changes at this stage are corrections to grammatical errors or data accuracy, or to provide higher resolution figure files (if requested by the typesetter).
     1313*  Any changes to scientific content or authorship will require editorial review and approval.
     1314*  Once your changes are complete, submit the article after which no additional corrections can be requested.
     1315*  Most authors complete their corrections within 48 hours. Returning any corrections promptly will accelerate publication of your article.
     1316
     1317If you encounter any problems or have questions, please contact the production office at (SPEproofs@wiley.com). For the quickest response, include the journal name and your article ID (found in the subject line) in all correspondence.
     1318
     1319Best regards,
     1320Software: Practice And Experience Production Office
     1321
     1322* We appreciate that the COVID-19 pandemic may create conditions for you that make it difficult for you to review your proof within standard timeframes. If you have any problems keeping to this schedule, please reach out to me at (SPEproofs@wiley.com) to discuss alternatives.
     1323
     1324
     1325
    12901326From: "Pacaanas, Joel -" <jpacaanas@wiley.com>
    12911327To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
     
    13451381
    13461382Since the proof was reset, your added corrections before has also been removed. Please add them back.
    1347 
    13481383Please return your corrections at your earliest convenience.
    13491384
     
    13841419Best regards,
    13851420Joel Pacaanas
     1421
     1422
     1423
     1424Date: Wed, 2 Dec 2020 08:49:52 +0000
     1425From: <cs-author@wiley.com>
     1426To: <pabuhr@uwaterloo.ca>
     1427Subject: Published: Your article is now published in Early View!
     1428
     1429Dear Peter Buhr,
     1430
     1431Your article Advanced Control-flow and Concurrency in C A in Software: Practice and Experience has the following publication status: Published as Early View
     1432
     1433To access your article, please click the following link to register or log in:
     1434
     1435  https://authorservices.wiley.com/index.html#register
     1436
     1437You can also access your published article via this link: http://dx.doi.org/10.1002/spe.2925
     1438
     1439If you need any assistance, please click here https://hub.wiley.com/community/support/authorservices to view our Help section.
     1440
     1441Sincerely,                                                                                 
     1442Wiley Author Services
     1443
     1444
     1445Date: Wed, 2 Dec 2020 02:16:23 -0500
     1446From: <no-reply@copyright.com>
     1447To: <pabuhr@uwaterloo.ca>
     1448CC: <SPEproofs@wiley.com>
     1449Subject: Please submit your publication fee(s) SPE2925
     1450 
     1451John Wiley and Sons
     1452Please submit your selection and payment for publication fee(s).
     1453
     1454Dear Peter A. Buhr,
     1455
     1456Congratulations, your article in Software: Practice and Experience has published online:
     1457
     1458Manuscript DOI: 10.1002/spe.2925
     1459Manuscript ID: SPE2925
     1460Manuscript Title: Advanced control-flow in Cforall
     1461Published by: John Wiley and Sons
     1462
     1463Please carefully review your publication options. If you wish your colour
     1464figures to be printed in colour, you must select and pay for that option now
     1465using the RightsLink e-commerce solution from CCC.
     1466
     1467  Review my options & pay charges 
     1468  https://oa.copyright.com/apc-payment-ui/overview?id=f46ba36a-2565-4c8d-8865-693bb94d87e5&chargeset=CHARGES 
     1469
     1470To review and pay your charge(s), please click here
     1471<https://oa.copyright.com/apc-payment-ui/overview?id=f46ba36a-2565-4c8d-8865-693bb94d87e5&chargeset=CHARGES>. You
     1472can also forward this link to another party for processing.
     1473
     1474To complete a secure transaction, you will need a RightsLink account
     1475<https://oa.copyright.com/apc-payment-ui/registration?id=f46ba36a-2565-4c8d-8865-693bb94d87e5&chargeset=CHARGES>. If
     1476you do not have one already, you will be prompted to register as you are
     1477checking out your author charges. This is a very quick process; the majority of
     1478your registration form will be pre-populated automatically with information we
     1479have already supplied to RightsLink.
     1480
     1481If you have any questions about these charges, please contact CCC Customer
     1482Service <wileysupport@copyright.com> using the information below. Please do not
     1483reply directly to this email as this is an automated email notification sent
     1484from an unmonitored account.
     1485
     1486Sincerely,
     1487John Wiley and Sons
     1488       
     1489Tel.: +1-877-622-5543 / +1-978-646-2777
     1490wileysupport@copyright.com
     1491www.copyright.com
     1492       
     1493Copyright Clearance Center
     1494RightsLink
     1495       
     1496This message (including attachments) is confidential, unless marked
     1497otherwise. It is intended for the addressee(s) only. If you are not an intended
     1498recipient, please delete it without further distribution and reply to the
     1499sender that you have received the message in error.
     1500
     1501
     1502
     1503From: "Pacaanas, Joel -" <jpacaanas@wiley.com>
     1504To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
     1505Subject: RE: Please submit your publication fee(s) SPE2925
     1506Date: Thu, 3 Dec 2020 08:45:10 +0000
     1507
     1508Dear Dr Buhr,
     1509
     1510Thank you for your email and concern with regard to the RightsLink account. As
     1511you have mentioned that all figures will be printed as black and white, then I
     1512have selected it manually from the system to proceed further.
     1513
     1514Best regards,
     1515Joel
     1516
     1517Joel Q. Pacaanas
     1518Production Editor
     1519On behalf of Wiley
     1520Manila
     1521We partner with global experts to further innovative research.
     1522
     1523E-mail: jpacaanas@wiley.com
     1524Tel: +632 88558618
     1525Fax: +632 5325 0768
     1526
     1527-----Original Message-----
     1528From: Peter A. Buhr [mailto:pabuhr@uwaterloo.ca]
     1529Sent: Thursday, December 3, 2020 12:28 AM
     1530To: SPE Proofs <speproofs@wiley.com>
     1531Subject: Re: Please submit your publication fee(s) SPE2925
     1532
     1533I am trying to complete the forms to submit my publication fee.
     1534
     1535I clicked all the boxs to print in Black and White, so there is no fee.
     1536
     1537I then am asked to create RightsLink account, which I did.
     1538
     1539However, it requires that I click a box agreeing to:
     1540
     1541   I consent to have my contact information shared with my publisher and/or
     1542   funding organization, as needed, to facilitate APC payment(s), reporting and
     1543   customer care.
     1544
     1545I do not agree to this sharing and will not click this button.
     1546
     1547How would you like to proceed?
     1548
     1549
     1550
     1551From: "Pacaanas, Joel -" <jpacaanas@wiley.com>
     1552To: "Peter A. Buhr" <pabuhr@uwaterloo.ca>
     1553Subject: RE: Please submit your publication fee(s) SPE2925
     1554Date: Fri, 4 Dec 2020 07:55:59 +0000
     1555
     1556Dear Peter,
     1557
     1558Yes, you are now done with this selection.
     1559
     1560Thank you.
     1561
     1562Best regards,
     1563Joel
     1564
     1565Joel Q. Pacaanas
     1566Production Editor
     1567On behalf of Wiley
     1568Manila
     1569We partner with global experts to further innovative research.
     1570
     1571E-mail: jpacaanas@wiley.com
     1572Tel: +632 88558618
     1573Fax: +632 5325 0768
     1574
     1575-----Original Message-----
     1576From: Peter A. Buhr [mailto:pabuhr@uwaterloo.ca]
     1577Sent: Thursday, December 3, 2020 10:29 PM
     1578To: Pacaanas, Joel - <jpacaanas@wiley.com>
     1579Subject: Re: Please submit your publication fee(s) SPE2925
     1580
     1581    Thank you for your email and concern with regard to the RightsLink
     1582    account. As you have mentioned that all figures will be printed as black and
     1583    white, then I have selected it manually from the system to proceed further.
     1584
     1585Just be clear, am I done? Meaning I do not have to go back to that web-page again.
  • doc/theses/andrew_beach_MMath/existing.tex

    r5e99a9a r95b3a9c  
    1 \chapter{\texorpdfstring{\CFA Existing Features}{Cforall Existing Features}}
     1\chapter{\CFA Existing Features}
    22
    33\CFA (C-for-all)~\cite{Cforall} is an open-source project extending ISO C with
     
    1212obvious to the reader.
    1313
    14 \section{\texorpdfstring{Overloading and \lstinline|extern|}{Overloading and extern}}
     14\section{Overloading and \lstinline{extern}}
    1515\CFA has extensive overloading, allowing multiple definitions of the same name
    1616to be defined.~\cite{Moss18}
     
    4242
    4343\section{Reference Type}
    44 \CFA adds a rebindable reference type to C, but more expressive than the \CC
     44\CFA adds a rebindable reference type to C, but more expressive than the \Cpp
    4545reference.  Multi-level references are allowed and act like auto-dereferenced
    4646pointers using the ampersand (@&@) instead of the pointer asterisk (@*@). \CFA
     
    5959
    6060Both constructors and destructors are operators, which means they are just
    61 functions with special operator names rather than type names in \CC. The
     61functions with special operator names rather than type names in \Cpp. The
    6262special operator names may be used to call the functions explicitly (not
    63 allowed in \CC for constructors).
     63allowed in \Cpp for constructors).
    6464
    6565In general, operator names in \CFA are constructed by bracketing an operator
     
    8888matching overloaded destructor @void ^?{}(T &);@ is called.  Without explicit
    8989definition, \CFA creates a default and copy constructor, destructor and
    90 assignment (like \CC). It is possible to define constructors/destructors for
     90assignment (like \Cpp). It is possible to define constructors/destructors for
    9191basic and existing types.
    9292
     
    9494\CFA uses parametric polymorphism to create functions and types that are
    9595defined over multiple types. \CFA polymorphic declarations serve the same role
    96 as \CC templates or Java generics. The ``parametric'' means the polymorphism is
     96as \Cpp templates or Java generics. The ``parametric'' means the polymorphism is
    9797accomplished by passing argument operations to associate \emph{parameters} at
    9898the call site, and these parameters are used in the function to differentiate
     
    134134
    135135Note, a function named @do_once@ is not required in the scope of @do_twice@ to
    136 compile it, unlike \CC template expansion. Furthermore, call-site inferencing
     136compile it, unlike \Cpp template expansion. Furthermore, call-site inferencing
    137137allows local replacement of the most specific parametric functions needs for a
    138138call.
     
    178178}
    179179\end{cfa}
    180 The generic type @node(T)@ is an example of a polymorphic-type usage.  Like \CC
     180The generic type @node(T)@ is an example of a polymorphic-type usage.  Like \Cpp
    181181templates usage, a polymorphic-type usage must specify a type parameter.
    182182
  • doc/theses/andrew_beach_MMath/features.tex

    r5e99a9a r95b3a9c  
    55
    66\section{Virtuals}
     7Virtual types and casts are not part of the exception system nor are they
     8required for an exception system. But an object-oriented style hierarchy is a
     9great way of organizing exceptions so a minimal virtual system has been added
     10to \CFA.
     11
     12The pattern of a simple hierarchy was borrowed from object-oriented
     13programming was chosen for several reasons.
     14The first is that it allows new exceptions to be added in user code
     15and in libraries independently of each other. Another is it allows for
     16different levels of exception grouping (all exceptions, all IO exceptions or
     17a particular IO exception). Also it also provides a simple way of passing
     18data back and forth across the throw.
     19
    720Virtual types and casts are not required for a basic exception-system but are
    821useful for advanced exception features. However, \CFA is not object-oriented so
    9 there is no obvious concept of virtuals.  Hence, to create advanced exception
    10 features for this work, I needed to designed and implemented a virtual-like
     22there is no obvious concept of virtuals. Hence, to create advanced exception
     23features for this work, I needed to design and implement a virtual-like
    1124system for \CFA.
    1225
     26% NOTE: Maybe we should but less of the rational here.
    1327Object-oriented languages often organized exceptions into a simple hierarchy,
    1428\eg Java.
     
    3044\end{center}
    3145The hierarchy provides the ability to handle an exception at different degrees
    32 of specificity (left to right).  Hence, it is possible to catch a more general
     46of specificity (left to right). Hence, it is possible to catch a more general
    3347exception-type in higher-level code where the implementation details are
    3448unknown, which reduces tight coupling to the lower-level implementation.
     
    6175While much of the virtual infrastructure is created, it is currently only used
    6276internally for exception handling. The only user-level feature is the virtual
    63 cast, which is the same as the \CC \lstinline[language=C++]|dynamic_cast|.
     77cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|.
    6478\label{p:VirtualCast}
    6579\begin{cfa}
    6680(virtual TYPE)EXPRESSION
    6781\end{cfa}
    68 Note, the syntax and semantics matches a C-cast, rather than the unusual \CC
    69 syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be a
    70 pointer to a virtual type. The cast dynamically checks if the @EXPRESSION@ type
    71 is the same or a subtype of @TYPE@, and if true, returns a pointer to the
     82Note, the syntax and semantics matches a C-cast, rather than the function-like
     83\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
     84a pointer to a virtual type.
     85The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype
     86of @TYPE@, and if true, returns a pointer to the
    7287@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).
    7388
     
    7893
    7994Exceptions are defined by the trait system; there are a series of traits, and
    80 if a type satisfies them, then it can be used as an exception.  The following
     95if a type satisfies them, then it can be used as an exception. The following
    8196is the base trait all exceptions need to match.
    8297\begin{cfa}
    8398trait is_exception(exceptT &, virtualT &) {
    84         virtualT const & @get_exception_vtable@(exceptT *);
     99        virtualT const & get_exception_vtable(exceptT *);
    85100};
    86101\end{cfa}
    87 The function takes any pointer, including the null pointer, and returns a
    88 reference to the virtual-table object. Defining this function also establishes
    89 the virtual type and a virtual-table pair to the \CFA type-resolver and
    90 promises @exceptT@ is a virtual type and a child of the base exception-type.
    91 
    92 \PAB{I do not understand this paragraph.}
    93 One odd thing about @get_exception_vtable@ is that it should always be a
    94 constant function, returning the same value regardless of its argument.  A
    95 pointer or reference to the virtual table instance could be used instead,
    96 however using a function has some ease of implementation advantages and allows
    97 for easier disambiguation because the virtual type name (or the address of an
    98 instance that is in scope) can be used instead of the mangled virtual table
    99 name.  Also note the use of the word ``promise'' in the trait
    100 description. Currently, \CFA cannot check to see if either @exceptT@ or
    101 @virtualT@ match the layout requirements. This is considered part of
    102 @get_exception_vtable@'s correct implementation.
    103 
    104 \section{Raise}
    105 \CFA provides two kinds of exception raise: termination
    106 \see{\VRef{s:Termination}} and resumption \see{\VRef{s:Resumption}}, which are
    107 specified with the following traits.
     102The trait is defined over two types, the exception type and the virtual table
     103type. This should be one-to-one, each exception type has only one virtual
     104table type and vice versa. The only assertion in the trait is
     105@get_exception_vtable@, which takes a pointer of the exception type and
     106returns a reference to the virtual table type instance.
     107
     108The function @get_exception_vtable@ is actually a constant function.
     109Recardless of the value passed in (including the null pointer) it should
     110return a reference to the virtual table instance for that type.
     111The reason it is a function instead of a constant is that it make type
     112annotations easier to write as you can use the exception type instead of the
     113virtual table type; which usually has a mangled name.
     114% Also \CFA's trait system handles functions better than constants and doing
     115% it this way reduce the amount of boiler plate we need.
     116
     117% I did have a note about how it is the programmer's responsibility to make
     118% sure the function is implemented correctly. But this is true of every
     119% similar system I know of (except Agda's I guess) so I took it out.
     120
     121There are two more traits for exceptions @is_termination_exception@ and
     122@is_resumption_exception@. They are defined as follows:
     123
    108124\begin{cfa}
    109125trait is_termination_exception(
    110126                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
    111         void @defaultTerminationHandler@(exceptT &);
     127        void defaultTerminationHandler(exceptT &);
    112128};
    113 \end{cfa}
    114 The function is required to allow a termination raise, but is only called if a
    115 termination raise does not find an appropriate handler.
    116 
    117 Allowing a resumption raise is similar.
    118 \begin{cfa}
     129
    119130trait is_resumption_exception(
    120131                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
    121         void @defaultResumptionHandler@(exceptT &);
     132        void defaultResumptionHandler(exceptT &);
    122133};
    123134\end{cfa}
    124 The function is required to allow a resumption raise, but is only called if a
    125 resumption raise does not find an appropriate handler.
    126 
    127 Finally there are three convenience macros for referring to the these traits:
    128 @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.  Each
    129 takes the virtual type's name, and for polymorphic types only, the
    130 parenthesized list of polymorphic arguments. These macros do the name mangling
    131 to get the virtual-table name and provide the arguments to both sides
    132 \PAB{What's a ``side''?}
     135
     136In other words they make sure that a given type and virtual type is an
     137exception and defines one of the two default handlers. These default handlers
     138are used in the main exception handling operations \see{Exception Handling}
     139and their use will be detailed there.
     140
     141However all three of these traits can be trickly to use directly.
     142There is a bit of repetition required but
     143the largest issue is that the virtual table type is mangled and not in a user
     144facing way. So there are three macros that can be used to wrap these traits
     145when you need to refer to the names:
     146@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
     147
     148All take one or two arguments. The first argument is the name of the
     149exception type. Its unmangled and mangled form are passed to the trait.
     150The second (optional) argument is a parenthesized list of polymorphic
     151arguments. This argument should only with polymorphic exceptions and the
     152list will be passed to both types.
     153In the current set-up the base name and the polymorphic arguments have to
     154match so these macros can be used without losing flexability.
     155
     156For example consider a function that is polymorphic over types that have a
     157defined arithmetic exception:
     158\begin{cfa}
     159forall(Num | IS_EXCEPTION(Arithmetic, (Num)))
     160void some_math_function(Num & left, Num & right);
     161\end{cfa}
     162
     163\section{Exception Handling}
     164\CFA provides two kinds of exception handling, termination and resumption.
     165These twin operations are the core of the exception handling mechanism and
     166are the reason for the features of exceptions.
     167This section will cover the general patterns shared by the two operations and
     168then go on to cover the details each individual operation.
     169
     170Both operations follow the same set of steps to do their operation. They both
     171start with the user preforming a throw on an exception.
     172Then there is the search for a handler, if one is found than the exception
     173is caught and the handler is run. After that control returns to normal
     174execution.
     175
     176If the search fails a default handler is run and then control
     177returns to normal execution immediately. That is where the default handlers
     178@defaultTermiationHandler@ and @defaultResumptionHandler@ are used.
    133179
    134180\subsection{Termination}
    135181\label{s:Termination}
    136182
    137 Termination raise, called ``throw'', is familiar and used in most programming
    138 languages with exception handling. The semantics of termination is: search the
    139 stack for a matching handler, unwind the stack frames to the matching handler,
    140 execute the handler, and continue execution after the handler. Termination is
    141 used when execution \emph{cannot} return to the throw. To continue execution,
    142 the program must \emph{recover} in the handler from the failed (unwound)
    143 execution at the raise to safely proceed after the handler.
    144 
    145 A termination raise is started with the @throw@ statement:
     183Termination handling is more familiar kind and used in most programming
     184languages with exception handling.
     185It is dynamic, non-local goto. If a throw is successful then the stack will
     186be unwound and control will (usually) continue in a different function on
     187the call stack. They are commonly used when an error has occured and recovery
     188is impossible in the current function.
     189
     190% (usually) Control can continue in the current function but then a different
     191% control flow construct should be used.
     192
     193A termination throw is started with the @throw@ statement:
    146194\begin{cfa}
    147195throw EXPRESSION;
    148196\end{cfa}
    149 The expression must return a termination-exception reference, where the
    150 termination exception has a type with a @void defaultTerminationHandler(T &)@
    151 (default handler) defined. The handler is found at the call site using \CFA's
    152 trait system and passed into the exception system along with the exception
    153 itself.
    154 
    155 At runtime, a representation of the exception type and an instance of the
    156 exception type is copied into managed memory (heap) to ensure it remains in
    157 scope during unwinding. It is the user's responsibility to ensure the original
    158 exception object at the throw is freed when it goes out of scope. Being
    159 allocated on the stack is sufficient for this.
    160 
    161 Then the exception system searches the stack starting from the throw and
    162 proceeding towards the base of the stack, from callee to caller. At each stack
    163 frame, a check is made for termination handlers defined by the @catch@ clauses
    164 of a @try@ statement.
     197The expression must return a reference to a termination exception, where the
     198termination exception is any type that satifies @is_termination_exception@
     199at the call site.
     200Through \CFA's trait system the functions in the traits are passed into the
     201throw code. A new @defaultTerminationHandler@ can be defined in any scope to
     202change the throw's behavior (see below).
     203
     204The throw will copy the provided exception into managed memory. It is the
     205user's responcibility to ensure the original exception is cleaned up if the
     206stack is unwound (allocating it on the stack should be sufficient).
     207
     208Then the exception system searches the stack using the copied exception.
     209It starts starts from the throw and proceeds to the base of the stack,
     210from callee to caller.
     211At each stack frame, a check is made for resumption handlers defined by the
     212@catch@ clauses of a @try@ statement.
    165213\begin{cfa}
    166214try {
    167215        GUARDED_BLOCK
    168 } @catch (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // termination handler 1
     216} catch (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) {
    169217        HANDLER_BLOCK$\(_1\)$
    170 } @catch (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // termination handler 2
     218} catch (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) {
    171219        HANDLER_BLOCK$\(_2\)$
    172220}
    173221\end{cfa}
    174 The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any
    175 functions invoked from those statements, throws an exception, and the exception
     222When viewed on its own a try statement will simply exceute the statements in
     223@GUARDED_BLOCK@ and when those are finished the try statement finishes.
     224
     225However, while the guarded statements are being executed, including any
     226functions they invoke, all the handlers following the try block are now
     227or any functions invoked from those
     228statements, throws an exception, and the exception
    176229is not handled by a try statement further up the stack, the termination
    177230handlers are searched for a matching exception type from top to bottom.
     
    179232Exception matching checks the representation of the thrown exception-type is
    180233the same or a descendant type of the exception types in the handler clauses. If
    181 there is a match, a pointer to the exception object created at the throw is
    182 bound to @NAME@ and the statements in the associated @HANDLER_BLOCK@ are
    183 executed. If control reaches the end of the handler, the exception is freed,
    184 and control continues after the try statement.
    185 
    186 The default handler visible at the throw statement is used if no matching
    187 termination handler is found after the entire stack is searched. At that point,
    188 the default handler is called with a reference to the exception object
    189 generated at the throw. If the default handler returns, the system default
    190 action is executed, which often terminates the program. This feature allows
    191 each exception type to define its own action, such as printing an informative
    192 error message, when an exception is not handled in the program.
     234it is the same of a descendent of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ is
     235bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
     236are executed. If control reaches the end of the handler, the exception is
     237freed and control continues after the try statement.
     238
     239If no handler is found during the search then the default handler is run.
     240Through \CFA's trait system the best match at the throw sight will be used.
     241This function is run and is passed the copied exception. After the default
     242handler is run control continues after the throw statement.
     243
     244There is a global @defaultTerminationHandler@ that cancels the current stack
     245with the copied exception. However it is generic over all exception types so
     246new default handlers can be defined for different exception types and so
     247different exception types can have different default handlers.
    193248
    194249\subsection{Resumption}
    195250\label{s:Resumption}
    196251
    197 Resumption raise, called ``resume'', is as old as termination
    198 raise~\cite{Goodenough75} but is less popular. In many ways, resumption is
    199 simpler and easier to understand, as it is simply a dynamic call (as in
    200 Lisp). The semantics of resumption is: search the stack for a matching handler,
    201 execute the handler, and continue execution after the resume. Notice, the stack
    202 cannot be unwound because execution returns to the raise point. Resumption is
    203 used used when execution \emph{can} return to the resume. To continue
    204 execution, the program must \emph{correct} in the handler for the failed
    205 execution at the raise so execution can safely continue after the resume.
     252Resumption exception handling is a less common form than termination but is
     253just as old~\cite{Goodenough75} and is in some sense simpler.
     254It is a dynamic, non-local function call. If the throw is successful a
     255closure will be taken from up the stack and executed, after which the throwing
     256function will continue executing.
     257These are most often used when an error occured and if the error is repaired
     258then the function can continue.
    206259
    207260A resumption raise is started with the @throwResume@ statement:
     
    210263\end{cfa}
    211264The semantics of the @throwResume@ statement are like the @throw@, but the
    212 expression has a type with a @void defaultResumptionHandler(T &)@ (default
    213 handler) defined, where the handler is found at the call site by the type
    214 system.  At runtime, a representation of the exception type and an instance of
    215 the exception type is \emph{not} copied because the stack is maintained during
    216 the handler search.
    217 
    218 Then the exception system searches the stack starting from the resume and
    219 proceeding towards the base of the stack, from callee to caller. At each stack
    220 frame, a check is made for resumption handlers defined by the @catchResume@
    221 clauses of a @try@ statement.
     265expression has return a reference a type that satifies the trait
     266@is_resumption_exception@. The assertions from this trait are available to
     267the exception system while handling the exception.
     268
     269At runtime, no copies are made. As the stack is not unwound the exception and
     270any values on the stack will remain in scope while the resumption is handled.
     271
     272Then the exception system searches the stack using the provided exception.
     273It starts starts from the throw and proceeds to the base of the stack,
     274from callee to caller.
     275At each stack frame, a check is made for resumption handlers defined by the
     276@catchResume@ clauses of a @try@ statement.
    222277\begin{cfa}
    223278try {
    224279        GUARDED_BLOCK
    225 } @catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME)@ { // resumption handler 1
     280} catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) {
    226281        HANDLER_BLOCK$\(_1\)$
    227 } @catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME)@ { // resumption handler 2
     282} catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) {
    228283        HANDLER_BLOCK$\(_2\)$
    229284}
    230285\end{cfa}
    231 The statements in the @GUARDED_BLOCK@ are executed. If those statements, or any
    232 functions invoked from those statements, resumes an exception, and the
    233 exception is not handled by a try statement further up the stack, the
    234 resumption handlers are searched for a matching exception type from top to
    235 bottom. (Note, termination and resumption handlers may be intermixed in a @try@
    236 statement but the kind of raise (throw/resume) only matches with the
    237 corresponding kind of handler clause.)
    238 
    239 The exception search and matching for resumption is the same as for
    240 termination, including exception inheritance. The difference is when control
    241 reaches the end of the handler: the resumption handler returns after the resume
    242 rather than after the try statement. The resume point assumes the handler has
    243 corrected the problem so execution can safely continue.
     286If the handlers are not involved in a search this will simply execute the
     287@GUARDED_BLOCK@ and then continue to the next statement.
     288Its purpose is to add handlers onto the stack.
     289(Note, termination and resumption handlers may be intermixed in a @try@
     290statement but the kind of throw must be the same as the handler for it to be
     291considered as a possible match.)
     292
     293If a search for a resumption handler reaches a try block it will check each
     294@catchResume@ clause, top-to-bottom.
     295At each handler if the thrown exception is or is a child type of
     296@EXCEPTION_TYPE@$_i$ then the a pointer to the exception is bound to
     297@NAME@$_i$ and then @HANDLER_BLOCK@$_i$ is executed. After the block is
     298finished control will return to the @throwResume@ statement.
    244299
    245300Like termination, if no resumption handler is found, the default handler
    246 visible at the resume statement is called, and the system default action is
    247 executed.
    248 
    249 For resumption, the exception system uses stack marking to partition the
    250 resumption search. If another resumption exception is raised in a resumption
    251 handler, the second exception search does not start at the point of the
    252 original raise. (Remember the stack is not unwound and the current handler is
    253 at the top of the stack.) The search for the second resumption starts at the
    254 current point on the stack because new try statements may have been pushed by
    255 the handler or functions called from the handler. If there is no match back to
    256 the point of the current handler, the search skips\label{p:searchskip} the stack frames already
    257 searched by the first resume and continues after the try statement. The default
    258 handler always continues from default handler associated with the point where
    259 the exception is created.
     301visible at the throw statement is called. It will use the best match at the
     302call sight according to \CFA's overloading rules. The default handler is
     303passed the exception given to the throw. When the default handler finishes
     304execution continues after the throw statement.
     305
     306There is a global @defaultResumptionHandler@ is polymorphic over all
     307termination exceptions and preforms a termination throw on the exception.
     308The @defaultTerminationHandler@ for that throw is matched at the original
     309throw statement (the resumption @throwResume@) and it can be customized by
     310introducing a new or better match as well.
     311
     312% \subsubsection?
     313
     314A key difference between resumption and termination is that resumption does
     315not unwind the stack. A side effect that is that when a handler is matched
     316and run it's try block (the guarded statements) and every try statement
     317searched before it are still on the stack. This can lead to the recursive
     318resumption problem.
     319
     320The recursive resumption problem is any situation where a resumption handler
     321ends up being called while it is running.
     322Consider a trivial case:
     323\begin{cfa}
     324try {
     325        throwResume (E &){};
     326} catchResume(E *) {
     327        throwResume (E &){};
     328}
     329\end{cfa}
     330When this code is executed the guarded @throwResume@ will throw, start a
     331search and match the handler in the @catchResume@ clause. This will be
     332call and placed on the stack on top of the try-block. The second throw then
     333throws and will seach the same try block and put call another instance of the
     334same handler leading to an infinite loop.
     335
     336This situation is trivial and easy to avoid, but much more complex cycles
     337can form with multiple handlers and different exception types.
     338
     339To prevent all of these cases we mask sections of the stack, or equvilantly
     340the try statements on the stack, so that the resumption seach skips over
     341them and continues with the next unmasked section of the stack.
     342
     343A section of the stack is marked when it is searched to see if it contains
     344a handler for an exception and unmarked when that exception has been handled
     345or the search was completed without finding a handler.
    260346
    261347% This might need a diagram. But it is an important part of the justification
     
    276362\end{verbatim}
    277363
    278 This resumption search-pattern reflect the one for termination, which matches
    279 with programmer expectations. However, it avoids the \emph{recursive
    280 resumption} problem. If parts of the stack are searched multiple times, loops
    281 can easily form resulting in infinite recursion.
    282 
    283 Consider the trivial case:
    284 \begin{cfa}
    285 try {
    286         throwResume$\(_1\)$ (E &){};
    287 } catch( E * ) {
    288         throwResume;
    289 }
    290 \end{cfa}
    291 Based on termination semantics, programmer expectation is for the re-resume to
    292 continue searching the stack frames after the try statement. However, the
    293 current try statement is still on the stack below the handler issuing the
    294 reresume \see{\VRef{s:Reraise}}. Hence, the try statement catches the re-raise
    295 again and does another re-raise \emph{ad infinitum}, which is confusing and
    296 difficult to debug. The \CFA resumption search-pattern skips the try statement
    297 so the reresume search continues after the try, mathcing programmer
    298 expectation.
     364The rules can be remembered as thinking about what would be searched in
     365termination. So when a throw happens in a handler; a termination handler
     366skips everything from the original throw to the original catch because that
     367part of the stack has been unwound, a resumption handler skips the same
     368section of stack because it has been masked.
     369A throw in a default handler will preform the same search as the original
     370throw because; for termination nothing has been unwound, for resumption
     371the mask will be the same.
     372
     373The symmetry with termination is why this pattern was picked. Other patterns,
     374such as marking just the handlers that caught, also work but lack the
     375symmetry whih means there is more to remember.
    299376
    300377\section{Conditional Catch}
    301 Both termination and resumption handler-clauses may perform conditional matching:
    302 \begin{cfa}
    303 catch (EXCEPTION_TYPE * NAME ; @CONDITION@)
     378Both termination and resumption handler clauses can be given an additional
     379condition to further control which exceptions they handle:
     380\begin{cfa}
     381catch (EXCEPTION_TYPE * NAME ; CONDITION)
    304382\end{cfa}
    305383First, the same semantics is used to match the exception type. Second, if the
    306384exception matches, @CONDITION@ is executed. The condition expression may
    307385reference all names in scope at the beginning of the try block and @NAME@
    308 introduced in the handler clause.  If the condition is true, then the handler
    309 matches. Otherwise, the exception search continues at the next appropriate kind
    310 of handler clause in the try block.
     386introduced in the handler clause. If the condition is true, then the handler
     387matches. Otherwise, the exception search continues as if the exception type
     388did not match.
    311389\begin{cfa}
    312390try {
     
    322400remaining handlers in the current try statement.
    323401
    324 \section{Reraise}
    325 \label{s:Reraise}
     402\section{Rethrowing}
     403\colour{red}{From Andrew: I recomend we talk about why the language doesn't
     404have rethrows/reraises instead.}
     405
     406\label{s:Rethrowing}
    326407Within the handler block or functions called from the handler block, it is
    327408possible to reraise the most recently caught exception with @throw@ or
    328 @throwResume@, respective.
    329 \begin{cfa}
    330 catch( ... ) {
    331         ... throw; // rethrow
     409@throwResume@, respectively.
     410\begin{cfa}
     411try {
     412        ...
     413} catch( ... ) {
     414        ... throw;
    332415} catchResume( ... ) {
    333         ... throwResume; // reresume
     416        ... throwResume;
    334417}
    335418\end{cfa}
     
    341424handler is generated that does a program-level abort.
    342425
    343 
    344426\section{Finally Clauses}
    345 A @finally@ clause may be placed at the end of a @try@ statement.
     427Finally clauses are used to preform unconditional clean-up when leaving a
     428scope. They are placed at the end of a try statement:
    346429\begin{cfa}
    347430try {
    348431        GUARDED_BLOCK
    349 } ...   // any number or kind of handler clauses
    350 } finally {
     432} ... // any number or kind of handler clauses
     433... finally {
    351434        FINALLY_BLOCK
    352435}
    353436\end{cfa}
    354 The @FINALLY_BLOCK@ is executed when the try statement is unwound from the
    355 stack, \ie when the @GUARDED_BLOCK@ or any handler clause finishes. Hence, the
    356 finally block is always executed.
     437The @FINALLY_BLOCK@ is executed when the try statement is removed from the
     438stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
     439finishes or during an unwind.
     440The only time the block is not executed is if the program is exited before
     441the stack is unwound.
    357442
    358443Execution of the finally block should always finish, meaning control runs off
    359444the end of the block. This requirement ensures always continues as if the
    360445finally clause is not present, \ie finally is for cleanup not changing control
    361 flow.  Because of this requirement, local control flow out of the finally block
    362 is forbidden.  The compiler precludes any @break@, @continue@, @fallthru@ or
     446flow. Because of this requirement, local control flow out of the finally block
     447is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or
    363448@return@ that causes control to leave the finally block. Other ways to leave
    364449the finally block, such as a long jump or termination are much harder to check,
    365 and at best requiring additional run-time overhead, and so are discouraged.
     450and at best requiring additional run-time overhead, and so are mearly
     451discouraged.
     452
     453Not all languages with exceptions have finally clauses. Notably \Cpp does
     454without it as descructors serve a similar role. Although destructors and
     455finally clauses can be used in many of the same areas they have their own
     456use cases like top-level functions and lambda functions with closures.
     457Destructors take a bit more work to set up but are much easier to reuse while
     458finally clauses are good for once offs and can include local information.
    366459
    367460\section{Cancellation}
     
    370463possible forwards the cancellation exception to a different stack.
    371464
     465Cancellation is not an exception operation like termination or resumption.
    372466There is no special statement for starting a cancellation; instead the standard
    373 library function @cancel_stack@ is called passing an exception.  Unlike a
    374 raise, this exception is not used in matching only to pass information about
     467library function @cancel_stack@ is called passing an exception. Unlike a
     468throw, this exception is not used in matching only to pass information about
    375469the cause of the cancellation.
    376 
    377 Handling of a cancellation depends on which stack is being cancelled.
     470(This also means matching cannot fail so there is no default handler either.)
     471
     472After @cancel_stack@ is called the exception is copied into the exception
     473handling mechanism's memory. Then the entirety of the current stack is
     474unwound. After that it depends one which stack is being cancelled.
    378475\begin{description}
    379476\item[Main Stack:]
    380477The main stack is the one used by the program main at the start of execution,
    381 and is the only stack in a sequential program.  Hence, when cancellation is
    382 forwarded to the main stack, there is no other forwarding stack, so after the
    383 stack is unwound, there is a program-level abort.
     478and is the only stack in a sequential program. Even in a concurrent program
     479the main stack is only dependent on the environment that started the program.
     480Hence, when the main stack is cancelled there is nowhere else in the program
     481to notify. After the stack is unwound, there is a program-level abort.
    384482
    385483\item[Thread Stack:]
    386484A thread stack is created for a @thread@ object or object that satisfies the
    387 @is_thread@ trait.  A thread only has two points of communication that must
     485@is_thread@ trait. A thread only has two points of communication that must
    388486happen: start and join. As the thread must be running to perform a
    389 cancellation, it must occur after start and before join, so join is a
    390 cancellation point.  After the stack is unwound, the thread halts and waits for
    391 another thread to join with it. The joining thread, checks for a cancellation,
     487cancellation, it must occur after start and before join, so join is used
     488for communication here.
     489After the stack is unwound, the thread halts and waits for
     490another thread to join with it. The joining thread checks for a cancellation,
    392491and if present, resumes exception @ThreadCancelled@.
    393492
     
    397496the exception is not caught. The implicit join does a program abort instead.
    398497
    399 This semantics is for safety. One difficult problem for any exception system is
    400 defining semantics when an exception is raised during an exception search:
    401 which exception has priority, the original or new exception? No matter which
    402 exception is selected, it is possible for the selected one to disrupt or
    403 destroy the context required for the other. \PAB{I do not understand the
    404 following sentences.} This loss of information can happen with join but as the
    405 thread destructor is always run when the stack is being unwound and one
    406 termination/cancellation is already active. Also since they are implicit they
    407 are easier to forget about.
     498This semantics is for safety. If an unwind is triggered while another unwind
     499is underway only one of them can proceed as they both want to ``consume'' the
     500stack. Letting both try to proceed leads to very undefined behaviour.
     501Both termination and cancellation involve unwinding and, since the default
     502@defaultResumptionHandler@ preforms a termination that could more easily
     503happen in an implicate join inside a destructor. So there is an error message
     504and an abort instead.
     505\todo{Perhaps have a more general disucssion of unwind collisions before
     506this point.}
     507
     508The recommended way to avoid the abort is to handle the intial resumption
     509from the implicate join. If required you may put an explicate join inside a
     510finally clause to disable the check and use the local
     511@defaultResumptionHandler@ instead.
    408512
    409513\item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object
    410 or object that satisfies the @is_coroutine@ trait.  A coroutine only knows of
    411 two other coroutines, its starter and its last resumer.  The last resumer has
    412 the tightest coupling to the coroutine it activated.  Hence, cancellation of
    413 the active coroutine is forwarded to the last resumer after the stack is
    414 unwound, as the last resumer has the most precise knowledge about the current
    415 execution. When the resumer restarts, it resumes exception
     514or object that satisfies the @is_coroutine@ trait. A coroutine only knows of
     515two other coroutines, its starter and its last resumer. Of the two the last
     516resumer has the tightest coupling to the coroutine it activated and the most
     517up-to-date information.
     518
     519Hence, cancellation of the active coroutine is forwarded to the last resumer
     520after the stack is unwound. When the resumer restarts, it resumes exception
    416521@CoroutineCancelled@, which is polymorphic over the coroutine type and has a
    417522pointer to the cancelled coroutine.
  • doc/theses/andrew_beach_MMath/future.tex

    r5e99a9a r95b3a9c  
    1010\item
    1111The implementation of termination is not portable because it includes
    12 hand-crafted assembly statements. These sections must be generalized to support
    13 more hardware architectures, \eg ARM processor.
     12hand-crafted assembly statements. These sections must be ported by hand to
     13support more hardware architectures, such as the ARM processor.
    1414\item
    1515Due to a type-system problem, the catch clause cannot bind the exception to a
     
    2424scope of the @try@ statement, where the local control-flow transfers are
    2525meaningful.
     26\item
     27There is no detection of colliding unwinds. It is possible for clean-up code
     28run during an unwind to trigger another unwind that escapes the clean-up code
     29itself; such as a termination exception caught further down the stack or a
     30cancellation. There do exist ways to handle this but currently they are not
     31even detected and the first unwind will simply be forgotten, often leaving
     32it in a bad state.
     33\item
     34Also the exception system did not have a lot of time to be tried and tested.
     35So just letting people use the exception system more will reveal new
     36quality of life upgrades that can be made with time.
    2637\end{itemize}
    2738
  • doc/theses/andrew_beach_MMath/implement.tex

    r5e99a9a r95b3a9c  
    278278@_URC_END_OF_STACK@.
    279279
    280 Second, when a handler is matched, raise exception continues onto the cleanup phase.
     280Second, when a handler is matched, raise exception continues onto the cleanup
     281phase.
    281282Once again, it calls the personality functions of each stack frame from newest
    282283to oldest. This pass stops at the stack frame containing the matching handler.
  • doc/theses/andrew_beach_MMath/thesis-frontpgs.tex

    r5e99a9a r95b3a9c  
    3636
    3737        A thesis \\
    38         presented to the University of Waterloo \\ 
     38        presented to the University of Waterloo \\
    3939        in fulfillment of the \\
    4040        thesis requirement for the degree of \\
     
    6464\cleardoublepage
    6565
    66  
     66
    6767%----------------------------------------------------------------------
    6868% EXAMINING COMMITTEE (Required for Ph.D. theses only)
     
    7171\begin{center}\textbf{Examining Committee Membership}\end{center}
    7272  \noindent
    73 The following served on the Examining Committee for this thesis. The decision of the Examining Committee is by majority vote.
    74   \bigskip
    75  
    76   \noindent
    77 \begin{tabbing}
    78 Internal-External Member: \=  \kill % using longest text to define tab length
    79 External Examiner: \>  Bruce Bruce \\
     73The following served on the Examining Committee for this thesis. The decision
     74of the Examining Committee is by majority vote.
     75  \bigskip
     76
     77  \noindent
     78\begin{tabbing}
     79Internal-External Member: \=  \kill % using longest text to define tab length
     80External Examiner: \>  Bruce Bruce \\
    8081\> Professor, Dept. of Philosophy of Zoology, University of Wallamaloo \\
    81 \end{tabbing} 
    82   \bigskip
    83  
     82\end{tabbing}
     83  \bigskip
     84
    8485  \noindent
    8586\begin{tabbing}
     
    9192\end{tabbing}
    9293  \bigskip
    93  
     94
    9495  \noindent
    9596  \begin{tabbing}
     
    99100\end{tabbing}
    100101  \bigskip
    101  
     102
    102103  \noindent
    103104\begin{tabbing}
     
    107108\end{tabbing}
    108109  \bigskip
    109  
     110
    110111  \noindent
    111112\begin{tabbing}
     
    123124  % December 13th, 2006.  It is designed for an electronic thesis.
    124125  \noindent
    125 I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners.
    126 
    127   \bigskip
    128  
     126I hereby declare that I am the sole author of this thesis. This is a true copy
     127of the thesis, including any required final revisions, as accepted by my
     128examiners.
     129
     130  \bigskip
     131
    129132  \noindent
    130133I understand that my thesis may be made electronically available to the public.
  • doc/theses/andrew_beach_MMath/thesis.tex

    r5e99a9a r95b3a9c  
    4545% FRONT MATERIAL
    4646%----------------------------------------------------------------------
    47 \input{thesis-frontpgs} 
     47\input{thesis-frontpgs}
    4848
    4949%----------------------------------------------------------------------
     
    6565A \gls{computer} could compute $\pi$ all day long. In fact, subsets of digits
    6666of $\pi$'s decimal approximation would make a good source for psuedo-random
    67 vectors, \gls{rvec} . 
     67vectors, \gls{rvec} .
    6868
    6969%----------------------------------------------------------------------
     
    9696
    9797\begin{itemize}
    98 \item A well-prepared PDF should be 
     98\item A well-prepared PDF should be
    9999  \begin{enumerate}
    100100    \item Of reasonable size, {\it i.e.} photos cropped and compressed.
    101     \item Scalable, to allow enlargment of text and drawings. 
    102   \end{enumerate} 
     101    \item Scalable, to allow enlargment of text and drawings.
     102  \end{enumerate}
    103103\item Photos must be bit maps, and so are not scaleable by definition. TIFF and
    104104BMP are uncompressed formats, while JPEG is compressed. Most photos can be
    105105compressed without losing their illustrative value.
    106 \item Drawings that you make should be scalable vector graphics, \emph{not} 
     106\item Drawings that you make should be scalable vector graphics, \emph{not}
    107107bit maps. Some scalable vector file formats are: EPS, SVG, PNG, WMF. These can
    108 all be converted into PNG or PDF, that pdflatex recognizes. Your drawing 
    109 package probably can export to one of these formats directly. Otherwise, a 
    110 common procedure is to print-to-file through a Postscript printer driver to 
    111 create a PS file, then convert that to EPS (encapsulated PS, which has a 
    112 bounding box to describe its exact size rather than a whole page). 
     108all be converted into PNG or PDF, that pdflatex recognizes. Your drawing
     109package probably can export to one of these formats directly. Otherwise, a
     110common procedure is to print-to-file through a Postscript printer driver to
     111create a PS file, then convert that to EPS (encapsulated PS, which has a
     112bounding box to describe its exact size rather than a whole page).
    113113Programs such as GSView (a Ghostscript GUI) can create both EPS and PDF from
    114114PS files. Appendix~\ref{AppendixA} shows how to generate properly sized Matlab
    115115plots and save them as PDF.
    116116\item It's important to crop your photos and draw your figures to the size that
    117 you want to appear in your thesis. Scaling photos with the 
    118 includegraphics command will cause loss of resolution. And scaling down 
     117you want to appear in your thesis. Scaling photos with the
     118includegraphics command will cause loss of resolution. And scaling down
    119119drawings may cause any text annotations to become too small.
    120120\end{itemize}
    121  
     121
    122122For more information on \LaTeX\, see the uWaterloo Skills for the
    123 Academic Workplace \href{https://uwaterloo.ca/information-systems-technology/services/electronic-thesis-preparation-and-submission-support/ethesis-guide/creating-pdf-version-your-thesis/creating-pdf-files-using-latex/latex-ethesis-and-large-documents}{course notes}. 
     123Academic Workplace \href{https://uwaterloo.ca/information-systems-technology/services/electronic-thesis-preparation-and-submission-support/ethesis-guide/creating-pdf-version-your-thesis/creating-pdf-files-using-latex/latex-ethesis-and-large-documents}{course notes}.
    124124\footnote{
    125125Note that while it is possible to include hyperlinks to external documents,
    126 it is not wise to do so, since anything you can't control may change over time. 
    127 It \emph{would} be appropriate and necessary to provide external links to 
    128 additional resources for a multimedia ``enhanced'' thesis. 
    129 But also note that if the \package{hyperref} package is not included, 
    130 as for the print-optimized option in this thesis template, any \cmmd{href} 
     126it is not wise to do so, since anything you can't control may change over time.
     127It \emph{would} be appropriate and necessary to provide external links to
     128additional resources for a multimedia ``enhanced'' thesis.
     129But also note that if the \package{hyperref} package is not included,
     130as for the print-optimized option in this thesis template, any \cmmd{href}
    131131commands in your logical document are no longer defined.
    132132A work-around employed by this thesis template is to define a dummy
    133 \cmmd{href} command (which does nothing) in the preamble of the document, 
    134 before the \package{hyperref} package is included. 
     133\cmmd{href} command (which does nothing) in the preamble of the document,
     134before the \package{hyperref} package is included.
    135135The dummy definition is then redifined by the
    136136\package{hyperref} package when it is included.
     
    138138
    139139The classic book by Leslie Lamport \cite{lamport.book}, author of \LaTeX , is
    140 worth a look too, and the many available add-on packages are described by 
     140worth a look too, and the many available add-on packages are described by
    141141Goossens \textit{et al} \cite{goossens.book}.
    142142
     
    180180Export Setup button in the figure Property Editor.
    181181
    182 \section{From the Command Line} 
     182\section{From the Command Line}
    183183All figure properties can also be manipulated from the command line. Here's an
    184 example: 
     184example:
    185185\begin{verbatim}
    186186x=[0:0.1:pi];
  • doc/theses/andrew_beach_MMath/unwinding.tex

    r5e99a9a r95b3a9c  
    1 \chapter{\texorpdfstring{Unwinding in \CFA}{Unwinding in Cforall}}
     1\chapter{Unwinding in \CFA}
    22
    33Stack unwinding is the process of removing stack frames (activations) from the
     
    110110alternate transfers of control.
    111111
    112 \section{\texorpdfstring{\CFA Implementation}{Cforall Implementation}}
     112\section{\CFA Implementation}
    113113
    114114To use libunwind, \CFA provides several wrappers, its own storage, personality
  • doc/theses/andrew_beach_MMath/uw-ethesis-frontpgs.tex

    r5e99a9a r95b3a9c  
    1313        \vspace*{1.0cm}
    1414
    15         \Huge
    16         {\bf Exception Handling in \CFA}
     15        {\Huge\bf Exception Handling in \CFA}
    1716
    1817        \vspace*{1.0cm}
    1918
    20         \normalsize
    2119        by \\
    2220
    2321        \vspace*{1.0cm}
    2422
    25         \Large
    26         Andrew James Beach \\
     23        {\Large Andrew James Beach} \\
    2724
    2825        \vspace*{3.0cm}
    2926
    30         \normalsize
    3127        A thesis \\
    32         presented to the University of Waterloo \\ 
     28        presented to the University of Waterloo \\
    3329        in fulfillment of the \\
    3430        thesis requirement for the degree of \\
     
    4339        \vspace*{1.0cm}
    4440
    45         \copyright\ Andrew James Beach \the\year \\
     41        \copyright{} Andrew James Beach \the\year \\
    4642        \end{center}
    4743\end{titlepage}
    4844
    49 % The rest of the front pages should contain no headers and be numbered using Roman numerals starting with `ii'
     45% The rest of the front pages should contain no headers and be numbered using
     46% Roman numerals starting with `ii'.
    5047\pagestyle{plain}
    5148\setcounter{page}{2}
    5249
    53 \cleardoublepage % Ends the current page and causes all figures and tables that have so far appeared in the input to be printed.
    54 % In a two-sided printing style, it also makes the next page a right-hand (odd-numbered) page, producing a blank page if necessary.
     50\cleardoublepage % Ends the current page and causes all figures and tables
     51% that have so far appeared in the input to be printed. In a two-sided
     52% printing style, it also makes the next page a right-hand (odd-numbered)
     53% page, producing a blank page if necessary.
    5554
    56 \begin{comment} 
     55\begin{comment}
    5756% E X A M I N I N G   C O M M I T T E E (Required for Ph.D. theses only)
    5857% Remove or comment out the lines below to remove this page
    5958\begin{center}\textbf{Examining Committee Membership}\end{center}
    6059  \noindent
    61 The following served on the Examining Committee for this thesis. The decision of the Examining Committee is by majority vote.
     60The following served on the Examining Committee for this thesis.
     61The decision of the Examining Committee is by majority vote.
    6262  \bigskip
    63  
     63
    6464  \noindent
    6565\begin{tabbing}
    6666Internal-External Member: \=  \kill % using longest text to define tab length
    67 External Examiner: \>  Bruce Bruce \\ 
     67External Examiner: \>  Bruce Bruce \\
    6868\> Professor, Dept. of Philosophy of Zoology, University of Wallamaloo \\
    69 \end{tabbing} 
     69\end{tabbing}
    7070  \bigskip
    71  
     71
    7272  \noindent
    7373\begin{tabbing}
     
    7979\end{tabbing}
    8080  \bigskip
    81  
     81
    8282  \noindent
    8383  \begin{tabbing}
     
    8787\end{tabbing}
    8888  \bigskip
    89  
     89
    9090  \noindent
    9191\begin{tabbing}
     
    9595\end{tabbing}
    9696  \bigskip
    97  
     97
    9898  \noindent
    9999\begin{tabbing}
     
    111111  % December 13th, 2006.  It is designed for an electronic thesis.
    112112 \begin{center}\textbf{Author's Declaration}\end{center}
    113  
     113
    114114 \noindent
    115 I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners.
     115I hereby declare that I am the sole author of this thesis. This is a true copy
     116of the thesis, including any required final revisions, as accepted by my
     117examiners.
    116118
    117119  \bigskip
    118  
     120
    119121  \noindent
    120122I understand that my thesis may be made electronically available to the public.
  • doc/theses/andrew_beach_MMath/uw-ethesis.tex

    r5e99a9a r95b3a9c  
    11%======================================================================
    2 % University of Waterloo Thesis Template for LaTeX 
    3 % Last Updated November, 2020 
    4 % by Stephen Carr, IST Client Services, 
     2% University of Waterloo Thesis Template for LaTeX
     3% Last Updated November, 2020
     4% by Stephen Carr, IST Client Services,
    55% University of Waterloo, 200 University Ave. W., Waterloo, Ontario, Canada
    66% FOR ASSISTANCE, please send mail to request@uwaterloo.ca
    77
    88% DISCLAIMER
    9 % To the best of our knowledge, this template satisfies the current uWaterloo thesis requirements.
    10 % However, it is your responsibility to assure that you have met all requirements of the University and your particular department.
    11 
    12 % Many thanks for the feedback from many graduates who assisted the development of this template.
    13 % Also note that there are explanatory comments and tips throughout this template.
     9% To the best of our knowledge, this template satisfies the current uWaterloo
     10% thesis requirements. However, it is your responsibility to assure that you
     11% have met all requirements of the University and your particular department.
     12
     13% Many thanks for the feedback from many graduates who assisted the
     14% development of this template. Also note that there are explanatory comments
     15% and tips throughout this template.
    1416%======================================================================
    1517% Some important notes on using this template and making it your own...
    1618
    17 % The University of Waterloo has required electronic thesis submission since October 2006.
    18 % See the uWaterloo thesis regulations at
    19 % https://uwaterloo.ca/graduate-studies/thesis.
    20 % This thesis template is geared towards generating a PDF version optimized for viewing on an electronic display, including hyperlinks within the PDF.
    21 
    22 % DON'T FORGET TO ADD YOUR OWN NAME AND TITLE in the "hyperref" package configuration below.
    23 % THIS INFORMATION GETS EMBEDDED IN THE PDF FINAL PDF DOCUMENT.
    24 % You can view the information if you view properties of the PDF document.
    25 
    26 % Many faculties/departments also require one or more printed copies.
    27 % This template attempts to satisfy both types of output.
     19% The University of Waterloo has required electronic thesis submission since
     20% October 2006. See the uWaterloo thesis regulations at:
     21%   https://uwaterloo.ca/graduate-studies/thesis.
     22% This thesis template is geared towards generating a PDF version optimized
     23% for viewing on an electronic display, including hyperlinks within the PDF.
     24
     25% DON'T FORGET TO ADD YOUR OWN NAME AND TITLE in the "hyperref" package
     26% configuration below. THIS INFORMATION GETS EMBEDDED IN THE FINAL PDF
     27% DOCUMENT. You can view the information if you view properties of the PDF.
     28
     29% Many faculties/departments also require one or more printed copies.
     30% This template attempts to satisfy both types of output.
    2831% See additional notes below.
    29 % It is based on the standard "book" document class which provides all necessary sectioning structures and allows multi-part theses.
    30 
    31 % If you are using this template in Overleaf (cloud-based collaboration service), then it is automatically processed and previewed for you as you edit.
    32 
    33 % For people who prefer to install their own LaTeX distributions on their own computers, and process the source files manually, the following notes provide the sequence of tasks:
    34  
     32% It is based on the standard "book" document class which provides all
     33% necessary sectioning structures and allows multi-part theses.
     34
     35% If you are using this template in Overleaf (cloud-based collaboration
     36% service), then it is automatically processed and previewed for you as you
     37% edit.
     38
     39% For people who prefer to install their own LaTeX distributions on their own
     40% computers, and process the source files manually, the following notes
     41% provide the sequence of tasks:
     42
    3543% E.g. to process a thesis called "mythesis.tex" based on this template, run:
    3644
    3745% pdflatex mythesis     -- first pass of the pdflatex processor
    3846% bibtex mythesis       -- generates bibliography from .bib data file(s)
    39 % makeindex         -- should be run only if an index is used
    40 % pdflatex mythesis     -- fixes numbering in cross-references, bibliographic references, glossaries, index, etc.
    41 % pdflatex mythesis     -- it takes a couple of passes to completely process all cross-references
    42 
    43 % If you use the recommended LaTeX editor, Texmaker, you would open the mythesis.tex file, then click the PDFLaTeX button. Then run BibTeX (under the Tools menu).
    44 % Then click the PDFLaTeX button two more times.
    45 % If you have an index as well,you'll need to run MakeIndex from the Tools menu as well, before running pdflatex
    46 % the last two times.
    47 
    48 % N.B. The "pdftex" program allows graphics in the following formats to be included with the "\includegraphics" command: PNG, PDF, JPEG, TIFF
    49 % Tip: Generate your figures and photos in the size you want them to appear in your thesis, rather than scaling them with \includegraphics options.
    50 % Tip: Any drawings you do should be in scalable vector graphic formats: SVG, PNG, WMF, EPS and then converted to PNG or PDF, so they are scalable in the final PDF as well.
     47% makeindex         -- should be run only if an index is used
     48% pdflatex mythesis     -- fixes numbering in cross-references, bibliographic
     49%                      references, glossaries, index, etc.
     50% pdflatex mythesis     -- it takes a couple of passes to completely process all
     51%                      cross-references
     52
     53% If you use the recommended LaTeX editor, Texmaker, you would open the
     54% mythesis.tex file, then click the PDFLaTeX button. Then run BibTeX (under
     55% the Tools menu). Then click the PDFLaTeX button two more times.
     56% If you have an index as well, you'll need to run MakeIndex from the Tools
     57% menu as well, before running pdflatex the last two times.
     58
     59% N.B. The "pdftex" program allows graphics in the following formats to be
     60% included with the "\includegraphics" command: PNG, PDF, JPEG, TIFF
     61% Tip: Generate your figures and photos in the size you want them to appear
     62% in your thesis, rather than scaling them with \includegraphics options.
     63% Tip: Any drawings you do should be in scalable vector graphic formats: SVG,
     64% PNG, WMF, EPS and then converted to PNG or PDF, so they are scalable in the
     65% final PDF as well.
    5166% Tip: Photographs should be cropped and compressed so as not to be too large.
    5267
    53 % To create a PDF output that is optimized for double-sided printing:
    54 % 1) comment-out the \documentclass statement in the preamble below, and un-comment the second \documentclass line.
    55 % 2) change the value assigned below to the boolean variable "PrintVersion" from " false" to "true".
    56 
    57 %======================================================================
     68% To create a PDF output that is optimized for double-sided printing:
     69% 1) comment-out the \documentclass statement in the preamble below, and
     70%    un-comment the second \documentclass line.
     71% 2) change the value assigned below to the boolean variable "PrintVersion"
     72%    from "false" to "true".
     73
     74% ======================================================================
    5875%   D O C U M E N T   P R E A M B L E
    59 % Specify the document class, default style attributes, and page dimensions, etc.
     76% Specify the document class, default style attributes, page dimensions, etc.
    6077% For hyperlinked PDF, suitable for viewing on a computer, use this:
    6178\documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
    6279
    63 % For PDF, suitable for double-sided printing, change the PrintVersion variable below to "true" and use this \documentclass line instead of the one above:
     80% For PDF, suitable for double-sided printing, change the PrintVersion
     81% variable below to "true" and use this \documentclass line instead of the
     82% one above:
    6483%\documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
    6584
     85\usepackage{etoolbox}
     86
    6687% Some LaTeX commands I define for my own nomenclature.
    67 % If you have to, it's easier to make changes to nomenclature once here than in a million places throughout your thesis!
     88% If you have to, it's easier to make changes to nomenclature once here than
     89% in a million places throughout your thesis!
    6890\newcommand{\package}[1]{\textbf{#1}} % package names in bold text
    69 \newcommand{\cmmd}[1]{\textbackslash\texttt{#1}} % command name in tt font 
    70 \newcommand{\href}[1]{#1} % does nothing, but defines the command so the print-optimized version will ignore \href tags (redefined by hyperref pkg).
    71 %\newcommand{\texorpdfstring}[2]{#1} % does nothing, but defines the command
     91\newcommand{\cmmd}[1]{\textbackslash\texttt{#1}} % command name in tt font
     92\newcommand{\href}[1]{#1} % does nothing, but defines the command so the
     93% print-optimized version will ignore \href tags (redefined by hyperref pkg).
    7294% Anything defined here may be redefined by packages added below...
    7395
     
    7698\newboolean{PrintVersion}
    7799\setboolean{PrintVersion}{false}
    78 % CHANGE THIS VALUE TO "true" as necessary, to improve printed results for hard copies by overriding some options of the hyperref package, called below.
     100% CHANGE THIS VALUE TO "true" as necessary, to improve printed results for
     101% hard copies by overriding some options of the hyperref package, called below.
    79102
    80103%\usepackage{nomencl} % For a nomenclature (optional; available from ctan.org)
    81 \usepackage{amsmath,amssymb,amstext} % Lots of math symbols and environments
    82 \usepackage[pdftex]{graphicx} % For including graphics N.B. pdftex graphics driver
     104% Lots of math symbols and environments
     105\usepackage{amsmath,amssymb,amstext}
     106% For including graphics N.B. pdftex graphics driver
     107\usepackage[pdftex]{graphicx}
     108% Removes large sections of the document.
     109\usepackage{comment}
     110% Adds todos (Must be included after comment.)
     111\usepackage{todonotes}
     112
    83113
    84114% Hyperlinks make it very easy to navigate an electronic document.
    85 % In addition, this is where you should specify the thesis title and author as they appear in the properties of the PDF document.
     115% In addition, this is where you should specify the thesis title and author as
     116% they appear in the properties of the PDF document.
    86117% Use the "hyperref" package
    87118% N.B. HYPERREF MUST BE THE LAST PACKAGE LOADED; ADD ADDITIONAL PKGS ABOVE
    88119\usepackage[pdftex,pagebackref=true]{hyperref} % with basic options
    89120%\usepackage[pdftex,pagebackref=true]{hyperref}
    90                 % N.B. pagebackref=true provides links back from the References to the body text. This can cause trouble for printing.
     121% N.B. pagebackref=true provides links back from the References to the body
     122% text. This can cause trouble for printing.
    91123\hypersetup{
    92124    plainpages=false,       % needed if Roman numbers in frontpages
     
    96128    pdffitwindow=false,     % window fit to page when opened
    97129    pdfstartview={FitH},    % fits the width of the page to the window
    98 %    pdftitle={uWaterloo\ LaTeX\ Thesis\ Template},    % title: CHANGE THIS TEXT!
     130%    pdftitle={uWaterloo\ LaTeX\ Thesis\ Template}, % title: CHANGE THIS TEXT!
    99131%    pdfauthor={Author},    % author: CHANGE THIS TEXT! and uncomment this line
    100132%    pdfsubject={Subject},  % subject: CHANGE THIS TEXT! and uncomment this line
    101 %    pdfkeywords={keyword1} {key2} {key3}, % list of keywords, and uncomment this line if desired
     133%    pdfkeywords={keyword1} {key2} {key3}, % optional list of keywords
    102134    pdfnewwindow=true,      % links in new window
    103135    colorlinks=true,        % false: boxed links; true: colored links
     
    107139    urlcolor=cyan           % color of external links
    108140}
    109 \ifthenelse{\boolean{PrintVersion}}{   % for improved print quality, change some hyperref options
     141% for improved print quality, change some hyperref options
     142\ifthenelse{\boolean{PrintVersion}}{
    110143\hypersetup{    % override some previously defined hyperref options
    111144%    colorlinks,%
     
    116149}{} % end of ifthenelse (no else)
    117150
    118 \usepackage[automake,toc,abbreviations]{glossaries-extra} % Exception to the rule of hyperref being the last add-on package
    119 % If glossaries-extra is not in your LaTeX distribution, get it from CTAN (http://ctan.org/pkg/glossaries-extra),
    120 % although it's supposed to be in both the TeX Live and MikTeX distributions. There are also documentation and
    121 % installation instructions there.
     151% Exception to the rule of hyperref being the last add-on package
     152\usepackage[automake,toc,abbreviations]{glossaries-extra}
     153% If glossaries-extra is not in your LaTeX distribution, get it from CTAN
     154% (http://ctan.org/pkg/glossaries-extra), although it's supposed to be in
     155% both the TeX Live and MikTeX distributions. There are also documentation
     156% and installation instructions there.
    122157
    123158% Setting up the page margins...
    124 \setlength{\textheight}{9in}\setlength{\topmargin}{-0.45in}\setlength{\headsep}{0.25in}
    125 % uWaterloo thesis requirements specify a minimum of 1 inch (72pt) margin at the
    126 % top, bottom, and outside page edges and a 1.125 in. (81pt) gutter margin (on binding side).
    127 % While this is not an issue for electronic viewing, a PDF may be printed, and so we have the same page layout for both printed and electronic versions, we leave the gutter margin in.
    128 % Set margins to minimum permitted by uWaterloo thesis regulations:
     159\setlength{\textheight}{9in}
     160\setlength{\topmargin}{-0.45in}
     161\setlength{\headsep}{0.25in}
     162% uWaterloo thesis requirements specify a minimum of 1 inch (72pt) margin at
     163% the top, bottom, and outside page edges and a 1.125 in. (81pt) gutter margin
     164% (on binding side). While this is not an issue for electronic viewing, a PDF
     165% may be printed, and so we have the same page layout for both printed and
     166% electronic versions, we leave the gutter margin in. Set margins to minimum
     167% permitted by uWaterloo thesis regulations:
    129168\setlength{\marginparwidth}{0pt} % width of margin notes
    130169% N.B. If margin notes are used, you must adjust \textwidth, \marginparwidth
    131170% and \marginparsep so that the space left between the margin notes and page
    132171% edge is less than 15 mm (0.6 in.)
    133 \setlength{\marginparsep}{0pt} % width of space between body text and margin notes
    134 \setlength{\evensidemargin}{0.125in} % Adds 1/8 in. to binding side of all
     172% width of space between body text and margin notes
     173\setlength{\marginparsep}{0pt}
     174% Adds 1/8 in. to binding side of all
    135175% even-numbered pages when the "twoside" printing option is selected
    136 \setlength{\oddsidemargin}{0.125in} % Adds 1/8 in. to the left of all pages when "oneside" printing is selected, and to the left of all odd-numbered pages when "twoside" printing is selected
    137 \setlength{\textwidth}{6.375in} % assuming US letter paper (8.5 in. x 11 in.) and side margins as above
     176\setlength{\evensidemargin}{0.125in}
     177% Adds 1/8 in. to the left of all pages when "oneside" printing is selected,
     178% and to the left of all odd-numbered pages when "twoside" printing is selected
     179\setlength{\oddsidemargin}{0.125in}
     180% assuming US letter paper (8.5 in. x 11 in.) and side margins as above
     181\setlength{\textwidth}{6.375in}
    138182\raggedbottom
    139183
    140 % The following statement specifies the amount of space between paragraphs. Other reasonable specifications are \bigskipamount and \smallskipamount.
     184% The following statement specifies the amount of space between paragraphs.
     185% Other reasonable specifications are \bigskipamount and \smallskipamount.
    141186\setlength{\parskip}{\medskipamount}
    142187
    143 % The following statement controls the line spacing. 
    144 % The default spacing corresponds to good typographic conventions and only slight changes (e.g., perhaps "1.2"), if any, should be made.
     188% The following statement controls the line spacing.
     189% The default spacing corresponds to good typographic conventions and only
     190% slight changes (e.g., perhaps "1.2"), if any, should be made.
    145191\renewcommand{\baselinestretch}{1} % this is the default line space setting
    146192
    147193% By default, each chapter will start on a recto (right-hand side) page.
    148 % We also force each section of the front pages to start on a recto page by inserting \cleardoublepage commands.
    149 % In many cases, this will require that the verso (left-hand) page be blank, and while it should be counted, a page number should not be printed.
    150 % The following statements ensure a page number is not printed on an otherwise blank verso page.
     194% We also force each section of the front pages to start on a recto page by
     195% inserting \cleardoublepage commands. In many cases, this will require that
     196% the verso (left-hand) page be blank, and while it should be counted, a page
     197% number should not be printed. The following statements ensure a page number
     198% is not printed on an otherwise blank verso page.
    151199\let\origdoublepage\cleardoublepage
    152200\newcommand{\clearemptydoublepage}{%
     
    154202\let\cleardoublepage\clearemptydoublepage
    155203
    156 % Define Glossary terms (This is properly done here, in the preamble and could also be \input{} from a separate file...)
     204% Define Glossary terms (This is properly done here, in the preamble and
     205% could also be \input{} from a separate file...)
    157206\input{glossaries}
    158207\makeglossaries
    159208
    160 \usepackage{comment}
    161209% cfa macros used in the document
    162210%\usepackage{cfalab}
     211% I'm going to bring back eventually.
     212\makeatletter
     213% Combines all \CC* commands:
     214\newrobustcmd*\Cpp[1][\xspace]{\cfalab@Cpp#1}
     215\newcommand\cfalab@Cpp{C\kern-.1em\hbox{+\kern-.25em+}}
     216% Optional arguments do not work with pdf string. (Some fix-up required.)
     217\pdfstringdefDisableCommands{\def\Cpp{C++}}
     218
     219% Colour text, formatted in LaTeX style instead of TeX style.
     220\newcommand*\colour[2]{{\color{#1}#2}}
     221\makeatother
     222
    163223\input{common}
    164 \CFAStyle                                               % CFA code-style for all languages
    165 \lstset{language=CFA,basicstyle=\linespread{0.9}\tt}    % CFA default lnaguage
     224% CFA code-style for all languages
     225\CFAStyle
     226% CFA default lnaguage
     227\lstset{language=CFA,basicstyle=\linespread{0.9}\tt}
     228% Annotations from Peter:
    166229\newcommand{\PAB}[1]{{\color{blue}PAB: #1}}
     230% Change the style of abbreviations:
     231\renewcommand{\abbrevFont}{}
    167232
    168233%======================================================================
    169234%   L O G I C A L    D O C U M E N T
    170235% The logical document contains the main content of your thesis.
    171 % Being a large document, it is a good idea to divide your thesis into several files, each one containing one chapter or other significant chunk of content, so you can easily shuffle things around later if desired.
     236% Being a large document, it is a good idea to divide your thesis into several
     237% files, each one containing one chapter or other significant chunk of content,
     238% so you can easily shuffle things around later if desired.
    172239%======================================================================
    173240\begin{document}
     
    176243% FRONT MATERIAL
    177244% title page,declaration, borrowers' page, abstract, acknowledgements,
    178 % dedication, table of contents, list of tables, list of figures, nomenclature, etc.
    179 %----------------------------------------------------------------------
    180 \input{uw-ethesis-frontpgs}
     245% dedication, table of contents, list of tables, list of figures,
     246% nomenclature, etc.
     247%----------------------------------------------------------------------
     248\input{uw-ethesis-frontpgs}
    181249
    182250%----------------------------------------------------------------------
    183251% MAIN BODY
    184252% We suggest using a separate file for each chapter of your thesis.
    185 % Start each chapter file with the \chapter command.
    186 % Only use \documentclass or \begin{document} and \end{document} commands in this master document.
     253% Start each chapter file with the \chapter command. Only use \documentclass,
     254% \begin{document} and \end{document} commands in this master document.
    187255% Tip: Putting each sentence on a new line is a way to simplify later editing.
    188256%----------------------------------------------------------------------
     
    200268% Bibliography
    201269
    202 % The following statement selects the style to use for references. 
    203 % It controls the sort order of the entries in the bibliography and also the formatting for the in-text labels.
     270% The following statement selects the style to use for references.
     271% It controls the sort order of the entries in the bibliography and also the
     272% formatting for the in-text labels.
    204273\bibliographystyle{plain}
    205 % This specifies the location of the file containing the bibliographic information. 
    206 % It assumes you're using BibTeX to manage your references (if not, why not?).
    207 \cleardoublepage % This is needed if the "book" document class is used, to place the anchor in the correct page, because the bibliography will start on its own page.
    208 % Use \clearpage instead if the document class uses the "oneside" argument
    209 \phantomsection  % With hyperref package, enables hyperlinking from the table of contents to bibliography             
    210 % The following statement causes the title "References" to be used for the bibliography section:
     274% This specifies the location of the file containing the bibliographic
     275% information. It assumes you're using BibTeX to manage your references (if
     276% not, why not?).
     277\cleardoublepage % This is needed if the "book" document class is used, to
     278% place the anchor in the correct page, because the bibliography will start
     279% on its own page.
     280% Use \clearpage instead if the document class uses the "oneside" argument.
     281\phantomsection  % With hyperref package, enables hyperlinking from the table
     282% of contents to bibliography.
     283% The following statement causes the title "References" to be used for the
     284% bibliography section:
    211285\renewcommand*{\bibname}{References}
    212286
     
    215289
    216290\bibliography{uw-ethesis,pl}
    217 % Tip: You can create multiple .bib files to organize your references.
    218 % Just list them all in the \bibliogaphy command, separated by commas (no spaces).
    219 
    220 % The following statement causes the specified references to be added to the bibliography even if they were not cited in the text.
    221 % The asterisk is a wildcard that causes all entries in the bibliographic database to be included (optional).
     291% Tip: You can create multiple .bib files to organize your references. Just
     292% list them all in the \bibliogaphy command, separated by commas (no spaces).
     293
     294% The following statement causes the specified references to be added to the
     295% bibliography even if they were not cited in the text. The asterisk is a
     296% wildcard that causes all entries in the bibliographic database to be
     297% included (optional).
    222298% \nocite{*}
    223299%----------------------------------------------------------------------
     
    227303% The \appendix statement indicates the beginning of the appendices.
    228304\appendix
    229 % Add an un-numbered title page before the appendices and a line in the Table of Contents
     305% Add an un-numbered title page before the appendices and a line in the Table
     306% of Contents
    230307% \chapter*{APPENDICES}
    231308% \addcontentsline{toc}{chapter}{APPENDICES}
    232 % Appendices are just more chapters, with different labeling (letters instead of numbers).
     309% Appendices are just more chapters, with different labeling (letters instead
     310% of numbers).
    233311% \input{appendix-matlab_plots.tex}
    234312
    235 % GLOSSARIES (Lists of definitions, abbreviations, symbols, etc. provided by the glossaries-extra package)
     313% GLOSSARIES (Lists of definitions, abbreviations, symbols, etc.
     314% provided by the glossaries-extra package)
    236315% -----------------------------
    237316\printglossaries
  • doc/theses/fangren_yu_COOP_F20/Report.tex

    r5e99a9a r95b3a9c  
    102102\CFA language, developed by the Programming Language Group at the University of Waterloo, has a long history, with the initial language design in 1992 by Glen Ditchfield~\cite{Ditchfield92} and the first proof-of-concept compiler built in 2003 by Richard Bilson~\cite{Bilson03}. Many new features have been added to the language over time, but the core of \CFA's type-system --- parametric functions introduced by the @forall@ clause (hence the name of the language) providing parametric overloading --- remains mostly unchanged.
    103103
    104 The current \CFA reference compiler, @cfa-cc@, is designed using the visitor pattern~\cite{vistorpattern} over an abstract syntax tree (AST), where multiple passes over the AST modify it for subsequent passes. @cfa-cc@ still includes many parts taken directly from the original Bilson implementation, which served as the starting point for this enhancement work to the type system. Unfortunately, the prior implementation did not provide the efficiency required for the language to be practical: a \CFA source file of approximately 1000 lines of code can take a multiple minutes to compile. The cause of the problem is that the old compiler used inefficient data structures and algorithms for expression resolution, which involved significant copying and redundant work.
     104The current \CFA reference compiler, @cfa-cc@, is designed using the visitor pattern~\cite{vistorpattern} over an abstract syntax tree (AST), where multiple passes over the AST modify it for subsequent passes. @cfa-cc@ still includes many parts taken directly from the original Bilson implementation, which served as the starting point for this enhancement work to the type system. Unfortunately, the prior implementation did not provide the efficiency required for the language to be practical: a \CFA source file of approximately 1000 lines of code can take multiple minutes to compile. The cause of the problem is that the old compiler used inefficient data structures and algorithms for expression resolution, which involved significant copying and redundant work.
    105105
    106106This report presents a series of optimizations to the performance-critical parts of the resolver, with a major rework of the compiler data-structures using a functional-programming approach to reduce memory complexity. The improvements were suggested by running the compiler builds with a performance profiler against the \CFA standard-library source-code and a test suite to find the most underperforming components in the compiler algorithm.
     
    122122\end{itemize}
    123123
    124 The resolver algorithm, designed for overload resolution, uses a significant amount of reused, and hence copying, for the intermediate representations, especially in the following two places:
     124The resolver algorithm, designed for overload resolution, allows a significant amount of code reused, and hence copying, for the intermediate representations, especially in the following two places:
    125125\begin{itemize}
    126126\item
     
    301301forall( dtype T | sized( T ) )
    302302T * malloc( void ) { return (T *)malloc( sizeof(T) ); } // call C malloc
    303 int * i = malloc();  // type deduced from left-hand size $\Rightarrow$ no size argument or return cast
     303int * i = malloc();  // type deduced from left-hand size $\(\Rightarrow\)$ no size argument or return cast
    304304\end{cfa}
    305305An unbound return-type is problematic in resolver complexity because a single match of a function call with an unbound return type may create multiple candidates. In the worst case, consider a function declared that returns any @otype@ (defined \VPageref{otype}):
     
    432432\begin{cfa}
    433433void f( int );
    434 double g$_1$( int );
    435 int g$_2$( long );
     434double g$\(_1\)$( int );
     435int g$\(_2\)$( long );
    436436f( g( 42 ) );
    437437\end{cfa}
  • doc/theses/thierry_delisle_PhD/thesis/Makefile

    r5e99a9a r95b3a9c  
    88BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex
    99
    10 MAKEFLAGS = --no-print-directory --silent
     10MAKEFLAGS = --no-print-directory # --silent
    1111VPATH = ${Build} ${Figures}
    1212
     
    3232        emptytree \
    3333        fairness \
     34        io_uring \
     35        pivot_ring \
    3436        system \
    3537}
     
    4345## Define the documents that need to be made.
    4446all: thesis.pdf
    45 thesis.pdf: ${TEXTS} ${FIGURES} ${PICTURES} glossary.tex local.bib
     47thesis.pdf: ${TEXTS} ${FIGURES} ${PICTURES} thesis.tex glossary.tex local.bib
    4648
    4749DOCUMENT = thesis.pdf
     
    4951
    5052# Directives #
     53
     54.NOTPARALLEL:                                           # cannot make in parallel
    5155
    5256.PHONY : all clean                                      # not file names
     
    8185        ${LaTeX} $<
    8286
    83 build/fairness.svg : fig/fairness.py | ${Build}
    84         python3 $< $@
    85 
    8687## Define the default recipes.
    8788
     
    105106        sed -i 's/$@/${Build}\/$@/g' ${Build}/$@_t
    106107
     108build/fairness.svg : fig/fairness.py | ${Build}
     109        python3 $< $@
     110
    107111## pstex with inverted colors
    108112%.dark.pstex : fig/%.fig Makefile | ${Build}
  • doc/theses/thierry_delisle_PhD/thesis/local.bib

    r5e99a9a r95b3a9c  
    512512}
    513513
     514@manual{MAN:bsd/kqueue,
     515  title = {KQUEUE(2) - FreeBSD System Calls Manual},
     516  url   = {https://www.freebsd.org/cgi/man.cgi?query=kqueue},
     517  year  = {2020},
     518  month = {may}
     519}
     520
    514521% Apple's MAC OS X
    515522@manual{MAN:apple/scheduler,
     
    577584
    578585% --------------------------------------------------
     586% Man Pages
     587@manual{MAN:open,
     588  key        = "open",
     589  title      = "open(2) Linux User's Manual",
     590  year       = "2020",
     591  month      = "February",
     592}
     593
     594@manual{MAN:accept,
     595  key        = "accept",
     596  title      = "accept(2) Linux User's Manual",
     597  year       = "2019",
     598  month      = "March",
     599}
     600
     601@manual{MAN:select,
     602  key        = "select",
     603  title      = "select(2) Linux User's Manual",
     604  year       = "2019",
     605  month      = "March",
     606}
     607
     608@manual{MAN:poll,
     609  key        = "poll",
     610  title      = "poll(2) Linux User's Manual",
     611  year       = "2019",
     612  month      = "July",
     613}
     614
     615@manual{MAN:epoll,
     616  key        = "epoll",
     617  title      = "epoll(7) Linux User's Manual",
     618  year       = "2019",
     619  month      = "March",
     620}
     621
     622@manual{MAN:aio,
     623  key        = "aio",
     624  title      = "aio(7) Linux User's Manual",
     625  year       = "2019",
     626  month      = "March",
     627}
     628
     629@misc{MAN:io_uring,
     630  title   = {Efficient IO with io\_uring},
     631  author  = {Axboe, Jens},
     632  year    = "2019",
     633  month   = "March",
     634  version = {0,4},
     635  howpublished = {\url{https://kernel.dk/io_uring.pdf}}
     636}
     637
     638% --------------------------------------------------
    579639% Wikipedia Entries
    580640@misc{wiki:taskparallel,
     
    617677  note = "[Online; accessed 2-January-2021]"
    618678}
     679
     680@misc{wiki:future,
     681  author = "{Wikipedia contributors}",
     682  title = "Futures and promises --- {W}ikipedia{,} The Free Encyclopedia",
     683  year = "2020",
     684  url = "https://en.wikipedia.org/wiki/Futures_and_promises",
     685  note = "[Online; accessed 9-February-2021]"
     686}
  • doc/theses/thierry_delisle_PhD/thesis/text/core.tex

    r5e99a9a r95b3a9c  
    4949
    5050\section{Design}
    51 In general, a na\"{i}ve \glsxtrshort{fifo} ready-queue does not scale with increased parallelism from \glspl{hthrd}, resulting in decreased performance. The problem is adding/removing \glspl{thrd} is a single point of contention. As shown in the evaluation sections, most production schedulers do scale when adding \glspl{hthrd}. The common solution to the single point of contention is to shard the ready-queue so each \gls{hthrd} can access the ready-queue without contention, increasing performance though lack of contention.
     51In general, a na\"{i}ve \glsxtrshort{fifo} ready-queue does not scale with increased parallelism from \glspl{hthrd}, resulting in decreased performance. The problem is adding/removing \glspl{thrd} is a single point of contention. As shown in the evaluation sections, most production schedulers do scale when adding \glspl{hthrd}. The common solution to the single point of contention is to shard the ready-queue so each \gls{hthrd} can access the ready-queue without contention, increasing performance.
    5252
    5353\subsection{Sharding} \label{sec:sharding}
    54 An interesting approach to sharding a queue is presented in \cit{Trevors paper}. This algorithm presents a queue with a relaxed \glsxtrshort{fifo} guarantee using an array of strictly \glsxtrshort{fifo} sublists as shown in Figure~\ref{fig:base}. Each \emph{cell} of the array has a timestamp for the last operation and a pointer to a linked-list with a lock and each node in the list is marked with a timestamp indicating when it is added to the list. A push operation is done by picking a random cell, acquiring the list lock, and pushing to the list. If the cell is locked, the operation is simply retried on another random cell until a lock is acquired. A pop operation is done in a similar fashion except two random cells are picked. If both cells are unlocked with non-empty lists, the operation pops the node with the oldest cell timestamp. If one of the cells is unlocked and non-empty, the operation pops from that cell. If both cells are either locked or empty, the operation picks two new random cells and tries again.
     54An interesting approach to sharding a queue is presented in \cit{Trevors paper}. This algorithm presents a queue with a relaxed \glsxtrshort{fifo} guarantee using an array of strictly \glsxtrshort{fifo} sublists as shown in Figure~\ref{fig:base}. Each \emph{cell} of the array has a timestamp for the last operation and a pointer to a linked-list with a lock. Each node in the list is marked with a timestamp indicating when it is added to the list. A push operation is done by picking a random cell, acquiring the list lock, and pushing to the list. If the cell is locked, the operation is simply retried on another random cell until a lock is acquired. A pop operation is done in a similar fashion except two random cells are picked. If both cells are unlocked with non-empty lists, the operation pops the node with the oldest timestamp. If one of the cells is unlocked and non-empty, the operation pops from that cell. If both cells are either locked or empty, the operation picks two new random cells and tries again.
    5555
    5656\begin{figure}
     
    100100\paragraph{Local Information} Figure~\ref{fig:emptytls} shows an approach using dense information, similar to the bitmap, but each \gls{hthrd} keeps its own independent copy. While this approach can offer good scalability \emph{and} low latency, the liveliness and discovery of the information can become a problem. This case is made worst in systems with few processors where even blind random picks can find \glspl{thrd} in a few tries.
    101101
    102 I built a prototype of these approaches and none of these techniques offer satisfying performance when few threads are present. All of these approach hit the same 2 problems. First, randomly picking sub-queues is very fast but means any improvement to the hit rate can easily be countered by a slow-down in look-up speed when there are empty lists. Second, the array is already as sharded to avoid contention bottlenecks, so any denser data structure tends to become a bottleneck. In all cases, these factors meant the best cases scenario, \ie many threads, would get worst throughput, and the worst-case scenario, few threads, would get a better hit rate, but an equivalent poor throughput. As a result I tried an entirely different approach.
     102I built a prototype of these approaches and none of these techniques offer satisfying performance when few threads are present. All of these approach hit the same 2 problems. First, randomly picking sub-queues is very fast. That speed means any improvement to the hit rate can easily be countered by a slow-down in look-up speed, whether or not there are empty lists. Second, the array is already sharded to avoid contention bottlenecks, so any denser data structure tends to become a bottleneck. In all cases, these factors meant the best cases scenario, \ie many threads, would get worst throughput, and the worst-case scenario, few threads, would get a better hit rate, but an equivalent poor throughput. As a result I tried an entirely different approach.
    103103
    104104\subsection{Dynamic Entropy}\cit{https://xkcd.com/2318/}
    105 In the worst-case scenario there are only few \glspl{thrd} ready to run, or more precisely given $P$ \glspl{proc}\footnote{For simplicity, this assumes there is a one-to-one match between \glspl{proc} and \glspl{hthrd}.}, $T$ \glspl{thrd} and $\epsilon$ a very small number, than the worst case scenario can be represented by $\epsilon \ll P$, than $T = P + \epsilon$. It is important to note in this case that fairness is effectively irrelevant. Indeed, this case is close to \emph{actually matching} the model of the ``Ideal multi-tasking CPU'' on page \pageref{q:LinuxCFS}. In this context, it is possible to use a purely internal-locality based approach and still meet the fairness requirements. This approach simply has each \gls{proc} running a single \gls{thrd} repeatedly. Or from the shared ready-queue viewpoint, each \gls{proc} pushes to a given sub-queue and then popes from the \emph{same} subqueue. In cases where $T \gg P$, the scheduler should also achieves similar performance without affecting the fairness guarantees.
     105In the worst-case scenario there are only few \glspl{thrd} ready to run, or more precisely given $P$ \glspl{proc}\footnote{For simplicity, this assumes there is a one-to-one match between \glspl{proc} and \glspl{hthrd}.}, $T$ \glspl{thrd} and $\epsilon$ a very small number, than the worst case scenario can be represented by $T = P + \epsilon$, with $\epsilon \ll P$. It is important to note in this case that fairness is effectively irrelevant. Indeed, this case is close to \emph{actually matching} the model of the ``Ideal multi-tasking CPU'' on page \pageref{q:LinuxCFS}. In this context, it is possible to use a purely internal-locality based approach and still meet the fairness requirements. This approach simply has each \gls{proc} running a single \gls{thrd} repeatedly. Or from the shared ready-queue viewpoint, each \gls{proc} pushes to a given sub-queue and then pops from the \emph{same} subqueue. The challenge is for the the scheduler to achieve good performance in both the $T = P + \epsilon$ case and the $T \gg P$ case, without affecting the fairness guarantees in the later.
    106106
    107 To handle this case, I use a pseudo random-number generator, \glsxtrshort{prng} in a novel way. When the scheduler uses a \glsxtrshort{prng} instance per \gls{proc} exclusively, the random-number seed effectively starts an encoding that produces a list of all accessed subqueues, from latest to oldest. The novel approach is to be able to ``replay'' the \glsxtrshort{prng} backwards and there exist \glsxtrshort{prng}s that are fast, compact \emph{and} can be run forward and backwards. Linear congruential generators~\cite{wiki:lcg} are an example of \glsxtrshort{prng}s that match these requirements.
     107To handle this case, I use a \glsxtrshort{prng}\todo{Fix missing long form} in a novel way. There exist \glsxtrshort{prng}s that are fast, compact and can be run forward \emph{and} backwards.  Linear congruential generators~\cite{wiki:lcg} are an example of \glsxtrshort{prng}s of such \glsxtrshort{prng}s. The novel approach is to use the ability to run backwards to ``replay'' the \glsxtrshort{prng}. The scheduler uses an exclusive \glsxtrshort{prng} instance per \gls{proc}, the random-number seed effectively starts an encoding that produces a list of all accessed subqueues, from latest to oldest. Replaying the \glsxtrshort{prng} to identify cells accessed recently and which probably have data still cached.
    108108
    109109The algorithm works as follows:
  • doc/theses/thierry_delisle_PhD/thesis/text/intro.tex

    r5e99a9a r95b3a9c  
    77While previous work on the concurrent package of \CFA focused on features and interfaces, this thesis focuses on performance, introducing \glsxtrshort{api} changes only when required by performance considerations. More specifically, this thesis concentrates on scheduling and \glsxtrshort{io}. Prior to this work, the \CFA runtime used a strictly \glsxtrshort{fifo} \gls{rQ}.
    88
    9 This work exclusively concentrates on Linux as it's operating system since the existing \CFA runtime and compiler does not already support other operating systems. Furthermore, as \CFA is yet to be released, supporting version of Linux older that the latest version is not a goal of this work.
     9This work exclusively concentrates on Linux as it's operating system since the existing \CFA runtime and compiler does not already support other operating systems. Furthermore, as \CFA is yet to be released, supporting version of Linux older than the latest version is not a goal of this work.
  • doc/theses/thierry_delisle_PhD/thesis/text/io.tex

    r5e99a9a r95b3a9c  
    1 \chapter{User Level \glsxtrshort{io}}
    2 As mentionned in Section~\ref{prev:io}, User-Level \glsxtrshort{io} requires multiplexing the \glsxtrshort{io} operations of many \glspl{thrd} onto fewer \glspl{proc} using asynchronous \glsxtrshort{io} operations. Various operating systems offer various forms of asynchronous operations and as mentioned in Chapter~\ref{intro}, this work is exclusively focuesd on Linux.
     1\chapter{User Level \io}
     2As mentioned in Section~\ref{prev:io}, User-Level \io requires multiplexing the \io operations of many \glspl{thrd} onto fewer \glspl{proc} using asynchronous \io operations. Different operating systems offer various forms of asynchronous operations and as mentioned in Chapter~\ref{intro}, this work is exclusively focused on the Linux operating-system.
    33
    4 \section{Existing options}
    5 Since \glsxtrshort{io} operations are generally handled by the
     4\section{Kernel Interface}
     5Since this work fundamentally depends on operating-system support, the first step of any design is to discuss the available interfaces and pick one (or more) as the foundations of the non-blocking \io subsystem.
    66
    7 \subsection{\lstinline|epoll|, \lstinline|poll| and \lstinline|select|}
     7\subsection{\lstinline{O_NONBLOCK}}
     8In Linux, files can be opened with the flag @O_NONBLOCK@~\cite{MAN:open} (or @SO_NONBLOCK@~\cite{MAN:accept}, the equivalent for sockets) to use the file descriptors in ``nonblocking mode''. In this mode, ``Neither the @open()@ nor any subsequent \io operations on the [opened file descriptor] will cause the calling
     9process to wait''~\cite{MAN:open}. This feature can be used as the foundation for the non-blocking \io subsystem. However, for the subsystem to know when an \io operation completes, @O_NONBLOCK@ must be use in conjunction with a system call that monitors when a file descriptor becomes ready, \ie, the next \io operation on it does not cause the process to wait\footnote{In this context, ready means \emph{some} operation can be performed without blocking. It does not mean an operation returning \lstinline{EAGAIN} succeeds on the next try. For example, a ready read may only return a subset of bytes and the read must be issues again for the remaining bytes, at which point it may return \lstinline{EAGAIN}.}.
     10This mechanism is also crucial in determining when all \glspl{thrd} are blocked and the application \glspl{kthrd} can now block.
    811
    9 \subsection{Linux's AIO}
     12There are three options to monitor file descriptors in Linux\footnote{For simplicity, this section omits \lstinline{pselect} and \lstinline{ppoll}. The difference between these system calls and \lstinline{select} and \lstinline{poll}, respectively, is not relevant for this discussion.}, @select@~\cite{MAN:select}, @poll@~\cite{MAN:poll} and @epoll@~\cite{MAN:epoll}. All three of these options offer a system call that blocks a \gls{kthrd} until at least one of many file descriptors becomes ready. The group of file descriptors being waited is called the \newterm{interest set}.
    1013
     14\paragraph{\lstinline{select}} is the oldest of these options, it takes as an input a contiguous array of bits, where each bits represent a file descriptor of interest. On return, it modifies the set in place to identify which of the file descriptors changed status. This destructive change means that calling select in a loop requires re-initializing the array each time and the number of file descriptors supported has a hard limit. Another limit of @select@ is that once the call is started, the interest set can no longer be modified. Monitoring a new file descriptor generally requires aborting any in progress call to @select@\footnote{Starting a new call to \lstinline{select} is possible but requires a distinct kernel thread, and as a result is not an acceptable multiplexing solution when the interest set is large and highly dynamic unless the number of parallel calls to \lstinline{select} can be strictly bounded.}.
    1115
     16\paragraph{\lstinline{poll}} is an improvement over select, which removes the hard limit on the number of file descriptors and the need to re-initialize the input on every call. It works using an array of structures as an input rather than an array of bits, thus allowing a more compact input for small interest sets. Like @select@, @poll@ suffers from the limitation that the interest set cannot be changed while the call is blocked.
     17
     18\paragraph{\lstinline{epoll}} further improves these two functions by allowing the interest set to be dynamically added to and removed from while a \gls{kthrd} is blocked on an @epoll@ call. This dynamic capability is accomplished by creating an \emph{epoll instance} with a persistent interest set, which is used across multiple calls. This capability significantly reduces synchronization overhead on the part of the caller (in this case the \io subsystem), since the interest set can be modified when adding or removing file descriptors without having to synchronize with other \glspl{kthrd} potentially calling @epoll@.
     19
     20However, all three of these system calls have limitations. The @man@ page for @O_NONBLOCK@ mentions that ``[@O_NONBLOCK@] has no effect for regular files and block devices'', which means none of these three system calls are viable multiplexing strategies for these types of \io operations. Furthermore, @epoll@ has been shown to have problems with pipes and ttys~\cit{Peter's examples in some fashion}. Finally, none of these are useful solutions for multiplexing \io operations that do not have a corresponding file descriptor and can be awkward for operations using multiple file descriptors.
     21
     22\subsection{POSIX asynchronous I/O (AIO)}
     23An alternative to @O_NONBLOCK@ is the AIO interface. Its interface lets programmers enqueue operations to be performed asynchronously by the kernel. Completions of these operations can be communicated in various ways: either by spawning a new \gls{kthrd}, sending a Linux signal, or by polling for completion of one or more operation. For this work, spawning a new \gls{kthrd} is counter-productive but a related solution is discussed in Section~\ref{io:morethreads}. Using interrupts handlers can also lead to fairly complicated interactions between subsystems. Leaving polling for completion, which is similar to the previous system calls. While AIO only supports read and write operations to file descriptors, it does not have the same limitation as @O_NONBLOCK@, \ie, the file descriptors can be regular files and blocked devices. It also supports batching multiple operations in a single system call.
     24
     25AIO offers two different approach to polling: @aio_error@ can be used as a spinning form of polling, returning @EINPROGRESS@ until the operation is completed, and @aio_suspend@ can be used similarly to @select@, @poll@ or @epoll@, to wait until one or more requests have completed. For the purpose of \io multiplexing, @aio_suspend@ is the best interface. However, even if AIO requests can be submitted concurrently, @aio_suspend@ suffers from the same limitation as @select@ and @poll@, \ie, the interest set cannot be dynamically changed while a call to @aio_suspend@ is in progress. AIO also suffers from the limitation of specifying which requests have completed, \ie programmers have to poll each request in the interest set using @aio_error@ to identify the completed requests. This limitation means that, like @select@ and @poll@ but not @epoll@, the time needed to examine polling results increases based on the total number of requests monitored, not the number of completed requests.
     26Finally, AIO does not seem to be a popular interface, which I believe is due in part to this poor polling interface. Linus Torvalds talks about this interface as follows:
    1227
    1328\begin{displayquote}
    14         AIO is a horrible ad-hoc design, with the main excuse being "other,
     29        AIO is a horrible ad-hoc design, with the main excuse being ``other,
    1530        less gifted people, made that design, and we are implementing it for
    1631        compatibility because database people - who seldom have any shred of
    17         taste - actually use it".
     32        taste - actually use it''.
    1833
    1934        But AIO was always really really ugly.
     
    2439\end{displayquote}
    2540
    26 Interestingly, in this e-mail answer, Linus goes on to describe
     41Interestingly, in this e-mail, Linus goes on to describe
    2742``a true \textit{asynchronous system call} interface''
    2843that does
     
    3045in
    3146``some kind of arbitrary \textit{queue up asynchronous system call} model''.
    32 This description is actually quite close to the interface of the interface described in the next section.
     47This description is actually quite close to the interface described in the next section.
    3348
    34 \subsection{\texttt{io\_uring}}
    35 A very recent addition to Linux, @io_uring@\cit{io\_uring} is a framework that aims to solve many of the problems listed with the above mentioned solutions.
     49\subsection{\lstinline{io_uring}}
     50A very recent addition to Linux, @io_uring@~\cite{MAN:io_uring}, is a framework that aims to solve many of the problems listed in the above interfaces. Like AIO, it represents \io operations as entries added to a queue. But like @epoll@, new requests can be submitted while a blocking call waiting for requests to complete is already in progress. The @io_uring@ interface uses two ring buffers (referred to simply as rings) at its core: a submit ring to which programmers push \io requests and a completion ring from which programmers poll for completion.
     51
     52One of the big advantages over the prior interfaces is that @io_uring@ also supports a much wider range of operations. In addition to supporting reads and writes to any file descriptor like AIO, it supports other operations like @open@, @close@, @fsync@, @accept@, @connect@, @send@, @recv@, @splice@, \etc.
     53
     54On top of these, @io_uring@ adds many extras like avoiding copies between the kernel and user-space using shared memory, allowing different mechanisms to communicate with device drivers, and supporting chains of requests, \ie, requests that automatically trigger followup requests on completion.
    3655
    3756\subsection{Extra Kernel Threads}\label{io:morethreads}
    38 Finally, if the operating system does not offer any satisfying forms of asynchronous \glsxtrshort{io} operations, a solution is to fake it by creating a pool of \glspl{kthrd} and delegating operations to them in order to avoid blocking \glspl{proc}.
     57Finally, if the operating system does not offer a satisfactory form of asynchronous \io operations, an ad-hoc solution is to create a pool of \glspl{kthrd} and delegate operations to it to avoid blocking \glspl{proc}, which is a compromise for multiplexing. In the worst case, where all \glspl{thrd} are consistently blocking on \io, it devolves into 1-to-1 threading. However, regardless of the frequency of \io operations, it achieves the fundamental goal of not blocking \glspl{proc} when \glspl{thrd} are ready to run. This approach is used by languages like Go\cit{Go} and frameworks like libuv\cit{libuv}, since it has the advantage that it can easily be used across multiple operating systems. This advantage is especially relevant for languages like Go, which offer a homogeneous \glsxtrshort{api} across all platforms. As opposed to C, which has a very limited standard api for \io, \eg, the C standard library has no networking.
    3958
    4059\subsection{Discussion}
     60These options effectively fall into two broad camps: waiting for \io to be ready versus waiting for \io to complete. All operating systems that support asynchronous \io must offer an interface along one of these lines, but the details vary drastically. For example, Free BSD offers @kqueue@~\cite{MAN:bsd/kqueue}, which behaves similarly to @epoll@, but with some small quality of use improvements, while Windows (Win32)~\cit{https://docs.microsoft.com/en-us/windows/win32/fileio/synchronous-and-asynchronous-i-o} offers ``overlapped I/O'', which handles submissions similarly to @O_NONBLOCK@ with extra flags on the synchronous system call, but waits for completion events, similarly to @io_uring@.
    4161
     62For this project, I selected @io_uring@, in large parts because to its generality. While @epoll@ has been shown to be a good solution for socket \io (\cite{DBLP:journals/pomacs/KarstenB20}), @io_uring@'s transparent support for files, pipes, and more complex operations, like @splice@ and @tee@, make it a better choice as the foundation for a general \io subsystem.
    4263
    4364\section{Event-Engine}
     65An event engine's responsibility is to use the kernel interface to multiplex many \io operations onto few \glspl{kthrd}. In concrete terms, this means \glspl{thrd} enter the engine through an interface, the event engines then starts the operation and parks the calling \glspl{thrd}, returning control to the \gls{proc}. The parked \glspl{thrd} are then rescheduled by the event engine once the desired operation has completed.
     66
     67\subsection{\lstinline{io_uring} in depth}
     68Before going into details on the design of my event engine, more details on @io_uring@ usage are presented, each important in the design of the engine.
     69Figure~\ref{fig:iouring} shows an overview of an @io_uring@ instance.
     70Two ring buffers are used to communicate with the kernel: one for submissions~(left) and one for completions~(right).
     71The submission ring contains entries, \newterm{Submit Queue Entries} (SQE), produced (appended) by the application when an operation starts and then consumed by the kernel.
     72The completion ring contains entries, \newterm{Completion Queue Entries} (CQE), produced (appended) by the kernel when an operation completes and then consumed by the application.
     73The submission ring contains indexes into the SQE array (denoted \emph{S}) containing entries describing the I/O operation to start;
     74the completion ring contains entries for the completed I/O operation.
     75Multiple @io_uring@ instances can be created, in which case they each have a copy of the data structures in the figure.
     76
     77\begin{figure}
     78        \centering
     79        \input{io_uring.pstex_t}
     80        \caption{Overview of \lstinline{io_uring}}
     81%       \caption[Overview of \lstinline{io_uring}]{Overview of \lstinline{io_uring} \smallskip\newline Two ring buffer are used to communicate with the kernel, one for completions~(right) and one for submissions~(left). The completion ring contains entries, \newterm{CQE}s: Completion Queue Entries, that are produced by the kernel when an operation completes and then consumed by the application. On the other hand, the application produces \newterm{SQE}s: Submit Queue Entries, which it appends to the submission ring for the kernel to consume. Unlike the completion ring, the submission ring does not contain the entries directly, it indexes into the SQE array (denoted \emph{S}) instead.}
     82        \label{fig:iouring}
     83\end{figure}
     84
     85New \io operations are submitted to the kernel following 4 steps, which use the components shown in the figure.
     86\begin{enumerate}
     87\item
     88An SQE is allocated from the pre-allocated array (denoted \emph{S} in Figure~\ref{fig:iouring}). This array is created at the same time as the @io_uring@ instance, is in kernel-locked memory visible by both the kernel and the application, and has a fixed size determined at creation. How these entries are allocated is not important for the functioning of @io_uring@, the only requirement is that no entry is reused before the kernel has consumed it.
     89\item
     90The SQE is filled according to the desired operation. This step is straight forward, the only detail worth mentioning is that SQEs have a @user_data@ field that must be filled in order to match submission and completion entries.
     91\item
     92The SQE is submitted to the submission ring by appending the index of the SQE to the ring following regular ring buffer steps: \lstinline{buffer[head] = item; head++}. Since the head is visible to the kernel, some memory barriers may be required to prevent the compiler from reordering these operations. Since the submission ring is a regular ring buffer, more than one SQE can be added at once and the head is updated only after all entries are updated.
     93\item
     94The kernel is notified of the change to the ring using the system call @io_uring_enter@. The number of elements appended to the submission ring is passed as a parameter and the number of elements consumed is returned. The @io_uring@ instance can be constructed so this step is not required, but this requires elevated privilege.% and an early version of @io_uring@ had additional restrictions.
     95\end{enumerate}
     96
     97\begin{sloppypar}
     98The completion side is simpler: applications call @io_uring_enter@ with the flag @IORING_ENTER_GETEVENTS@ to wait on a desired number of operations to complete. The same call can be used to both submit SQEs and wait for operations to complete. When operations do complete, the kernel appends a CQE to the completion ring and advances the head of the ring. Each CQE contains the result of the operation as well as a copy of the @user_data@ field of the SQE that triggered the operation. It is not necessary to call @io_uring_enter@ to get new events because the kernel can directly modify the completion ring. The system call is only needed if the application wants to block waiting for operations to complete.
     99\end{sloppypar}
     100
     101The @io_uring_enter@ system call is protected by a lock inside the kernel. This protection means that concurrent call to @io_uring_enter@ using the same instance are possible, but there is no performance gained from parallel calls to @io_uring_enter@. It is possible to do the first three submission steps in parallel, however, doing so requires careful synchronization.
     102
     103@io_uring@ also introduces constraints on the number of simultaneous operations that can be ``in flight''. Obviously, SQEs are allocated from a fixed-size array, meaning that there is a hard limit to how many SQEs can be submitted at once. In addition, the @io_uring_enter@ system call can fail because ``The  kernel [...] ran out of resources to handle [a request]'' or ``The application is attempting to overcommit the number of requests it can  have  pending.''. This restriction means \io request bursts may have to be subdivided and submitted in chunks at a later time.
     104
     105\subsection{Multiplexing \io: Submission}
     106The submission side is the most complicated aspect of @io_uring@ and its design largely dictates the completion side.
     107
     108While it is possible to do the first steps of submission in parallel, the duration of the system call scales with number of entries submitted. The consequence is that the amount of parallelism used to prepare submissions for the next system call is limited. Beyond this limit, the length of the system call is the throughput limiting factor. I concluded from early experiments that preparing submissions seems to take about as long as the system call itself, which means that with a single @io_uring@ instance, there is no benefit in terms of \io throughput to having more than two \glspl{hthrd}. Therefore the design of the submission engine must manage multiple instances of @io_uring@ running in parallel, effectively sharding @io_uring@ instances. Similarly to scheduling, this sharding can be done privately, \ie, one instance per \glspl{proc}, or in decoupled pools, \ie, a pool of \glspl{proc} use a pool of @io_uring@ instances without one-to-one coupling between any given instance and any given \gls{proc}.
     109
     110\subsubsection{Pool of Instances}
     111One approach is to have multiple shared instances. \Glspl{thrd} attempting \io operations pick one of the available instances and submits operations to that instance. Since the completion will be sent to the same instance, all instances with pending operations must be polled continuously\footnote{As will be described in Chapter~\ref{practice}, this does not translate into constant CPU usage.}. Since there is no coupling between \glspl{proc} and @io_uring@ instances in this approach, \glspl{thrd} running on more than one \gls{proc} can attempt to submit to the same instance concurrently. Since @io_uring@ effectively sets the amount of sharding needed to avoid contention on its internal locks, performance in this approach is based on two aspects: the synchronization needed to submit does not induce more contention than @io_uring@ already does and the scheme to route \io requests to specific @io_uring@ instances does not introduce contention. This second aspect has an oversized importance because it comes into play before the sharding of instances, and as such, all \glspl{hthrd} can contend on the routing algorithm.
     112
     113Allocation in this scheme can be handled fairly easily. Free SQEs, \ie, SQEs that aren't currently being used to represent a request, can be written to safely and have a field called @user_data@ which the kernel only reads to copy to CQEs. Allocation also requires no ordering guarantee as all free SQEs are interchangeable. This requires a simple concurrent bag. The only added complexity is that the number of SQEs is fixed, which means allocation can fail. This failure needs to be pushed up to the routing algorithm, \glspl{thrd} attempting \io operations must not be directed to @io_uring@ instances without any available SQEs. Ideally, the routing algorithm would block operations up-front if none of the instances have available SQEs.
     114
     115Once an SQE is allocated, \glspl{thrd} can fill them normally, they simply need to keep track of the SQE index and which instance it belongs to.
     116
     117Once an SQE is filled in, what needs to happen is that the SQE must be added to the submission ring buffer, an operation that is not thread-safe on itself, and the kernel must be notified using the @io_uring_enter@ system call. The submission ring buffer is the same size as the pre-allocated SQE buffer, therefore pushing to the ring buffer cannot fail\footnote{This is because it is invalid to have the same \lstinline{sqe} multiple times in the ring buffer.}. However, as mentioned, the system call itself can fail with the expectation that it will be retried once some of the already submitted operations complete. Since multiple SQEs can be submitted to the kernel at once, it is important to strike a balance between batching and latency. Operations that are ready to be submitted should be batched together in few system calls, but at the same time, operations should not be left pending for long period of times before being submitted. This can be handled by either designating one of the submitting \glspl{thrd} as the being responsible for the system call for the current batch of SQEs or by having some other party regularly submitting all ready SQEs, \eg, the poller \gls{thrd} mentioned later in this section.
     118
     119In the case of designating a \gls{thrd}, ideally, when multiple \glspl{thrd} attempt to submit operations to the same @io_uring@ instance, all requests would be batched together and one of the \glspl{thrd} would do the system call on behalf of the others, referred to as the \newterm{submitter}. In practice however, it is important that the \io requests are not left pending indefinitely and as such, it may be required to have a current submitter and a next submitter. Indeed, as long as there is a ``next'' submitter, \glspl{thrd} submitting new \io requests can move on, knowing that some future system call will include their request. Once the system call is done, the submitter must also free SQEs so that the allocator can reused them.
     120
     121Finally, the completion side is much simpler since the @io_uring@ system call enforces a natural synchronization point. Polling simply needs to regularly do the system call, go through the produced CQEs and communicate the result back to the originating \glspl{thrd}. Since CQEs only own a signed 32 bit result, in addition to the copy of the @user_data@ field, all that is needed to communicate the result is a simple future~\cite{wiki:future}. If the submission side does not designate submitters, polling can also submit all SQEs as it is polling events.  A simple approach to polling is to allocate a \gls{thrd} per @io_uring@ instance and simply let the poller \glspl{thrd} poll their respective instances when scheduled. This design is especially convenient for reasons explained in Chapter~\ref{practice}.
     122
     123With this pool of instances approach, the big advantage is that it is fairly flexible. It does not impose restrictions on what \glspl{thrd} submitting \io operations can and cannot do between allocations and submissions. It also can gracefully handle running out of resources, SQEs or the kernel returning @EBUSY@. The down side to this is that many of the steps used for submitting need complex synchronization to work properly. The routing and allocation algorithm needs to keep track of which ring instances have available SQEs, block incoming requests if no instance is available, prevent barging if \glspl{thrd} are already queued up waiting for SQEs and handle SQEs being freed. The submission side needs to safely append SQEs to the ring buffer, make sure no SQE is dropped or left pending forever, notify the allocation side when SQEs can be reused and handle the kernel returning @EBUSY@. Sharding the @io_uring@ instances should alleviate much of the contention caused by this, but all this synchronization may still have non-zero cost.
     124
     125\subsubsection{Private Instances}
     126Another approach is to simply create one ring instance per \gls{proc}. This alleviate the need for synchronization on the submissions, requiring only that \glspl{thrd} are not interrupted in between two submission steps. This is effectively the same requirement as using @thread_local@ variables. Since SQEs that are allocated must be submitted to the same ring, on the same \gls{proc}, this effectively forces the application to submit SQEs in allocation order\footnote{The actual requirement is that \glspl{thrd} cannot context switch between allocation and submission. This requirement means that from the subsystem's point of view, the allocation and submission are sequential. To remove this requirement, a \gls{thrd} would need the ability to ``yield to a specific \gls{proc}'', \ie, park with the promise that it will be run next on a specific \gls{proc}, the \gls{proc} attached to the correct ring. This is not a current or planned feature of \CFA.}, greatly simplifying both allocation and submission. In this design, allocation and submission form a ring partitioned ring buffer as shown in Figure~\ref{fig:pring}. Once added to the ring buffer, the attached \gls{proc} has a significant amount of flexibility with regards to when to do the system call. Possible options are: when the \gls{proc} runs out of \glspl{thrd} to run, after running a given number of threads \glspl{thrd}, etc.
     127
     128\begin{figure}
     129        \centering
     130        \input{pivot_ring.pstex_t}
     131        \caption[Partitioned ring buffer]{Partitioned ring buffer \smallskip\newline Allocated sqes are appending to the first partition. When submitting, the partition is simply advanced to include all the sqes that should be submitted. The kernel considers the partition as the head of the ring.}
     132        \label{fig:pring}
     133\end{figure}
     134
     135This approach has the advantage that it does not require much of the synchronization needed in the shared approach. This comes at the cost that \glspl{thrd} submitting \io operations have less flexibility, they cannot park or yield, and several exceptional cases are handled poorly. Instances running out of SQEs cannot run \glspl{thrd} wanting to do \io operations, in such a case the \gls{thrd} needs to be moved to a different \gls{proc}, the only current way of achieving this would be to @yield()@ hoping to be scheduled on a different \gls{proc}, which is not guaranteed. Another problematic case is that \glspl{thrd} that do not park for long periods of time will delay the submission of any SQE not already submitted. This issue is similar to fairness issues which schedulers that use work-stealing mentioned in the previous chapter.
     136
    44137
    45138
    46139\section{Interface}
     140Finally, the last important part of the \io subsystem is it's interface. There are multiple approaches that can be offered to programmers, each with advantages and disadvantages. The new \io subsystem can replace the C runtime's API or extend it. And in the later case the interface can go from very similar to vastly different. The following sections discuss some useful options using @read@ as an example. The standard Linux interface for C is :
     141
     142@ssize_t read(int fd, void *buf, size_t count);@.
     143
     144\subsection{Replacement}
     145Replacing the C \glsxtrshort{api}
     146
     147\subsection{Synchronous Extension}
     148
     149\subsection{Asynchronous Extension}
     150
     151\subsection{Interface directly to \lstinline{io_uring}}
  • doc/theses/thierry_delisle_PhD/thesis/text/runtime.tex

    r5e99a9a r95b3a9c  
    1111
    1212\section{Clusters}
    13 \CFA allows the option to group user-level threading, in the form of clusters. Both \glspl{thrd} and \glspl{proc} belong to a specific cluster. \Glspl{thrd} are only be scheduled onto \glspl{proc} in the same cluster and scheduling is done independently of other clusters. Figure~\ref{fig:system} shows an overview of the \CFA runtime, which allows programmers to tightly control parallelism. It also opens the door to handling effects like NUMA, by pining clusters to a specific NUMA node\footnote{This is not currently implemented in \CFA, but the only hurdle left is creating a generic interface for cpu masks.}.
     13\CFA allows the option to group user-level threading, in the form of clusters. Both \glspl{thrd} and \glspl{proc} belong to a specific cluster. \Glspl{thrd} are only scheduled onto \glspl{proc} in the same cluster and scheduling is done independently of other clusters. Figure~\ref{fig:system} shows an overview of the \CFA runtime, which allows programmers to tightly control parallelism. It also opens the door to handling effects like NUMA, by pining clusters to a specific NUMA node\footnote{This is not currently implemented in \CFA, but the only hurdle left is creating a generic interface for cpu masks.}.
    1414
    1515\begin{figure}
     
    2525
    2626\section{\glsxtrshort{io}}\label{prev:io}
    27 Prior to this work, the \CFA runtime did not add any particular support for \glsxtrshort{io} operations. %\CFA being built on C, this means that,
    28 While all I/O operations available in C are available in \CFA, \glsxtrshort{io} operations are designed for the POSIX threading model~\cite{pthreads}. Using these 1:1 threading operations in an M:N threading model means I/O operations block \glspl{proc} instead of \glspl{thrd}. While this can work in certain cases, it limits the number of concurrent operations to the number of \glspl{proc} rather than \glspl{thrd}. It also means deadlock can occur because all \glspl{proc} are blocked even if at least one \gls{thrd} is ready to run. A simple example of this type of deadlock would be as follows:
     27Prior to this work, the \CFA runtime did not add any particular support for \glsxtrshort{io} operations. While all \glsxtrshort{io} operations available in C are available in \CFA, \glsxtrshort{io} operations are designed for the POSIX threading model~\cite{pthreads}. Using these 1:1 threading operations in an M:N threading model means \glsxtrshort{io} operations block \glspl{proc} instead of \glspl{thrd}. While this can work in certain cases, it limits the number of concurrent operations to the number of \glspl{proc} rather than \glspl{thrd}. It also means deadlock can occur because all \glspl{proc} are blocked even if at least one \gls{thrd} is ready to run. A simple example of this type of deadlock would be as follows:
     28
    2929\begin{quote}
    3030Given a simple network program with 2 \glspl{thrd} and a single \gls{proc}, one \gls{thrd} sends network requests to a server and the other \gls{thrd} waits for a response from the server. If the second \gls{thrd} races ahead, it may wait for responses to requests that have not been sent yet. In theory, this should not be a problem, even if the second \gls{thrd} waits, because the first \gls{thrd} is still ready to run and should be able to get CPU time to send the request. With M:N threading, while the first \gls{thrd} is ready, the lone \gls{proc} \emph{cannot} run the first \gls{thrd} if it is blocked in the \glsxtrshort{io} operation of the second \gls{thrd}. If this happen, the system is in a synchronization deadlock\footnote{In this example, the deadlocked could be resolved if the server sends unprompted messages to the client. However, this solution is not general and may not be appropriate even in this simple case.}.
    3131\end{quote}
    32 Therefore, one of the objective of this work is to introduce \emph{User-Level \glsxtrshort{io}}, like \glslink{uthrding}{User-Level \emph{Threading}} blocks \glspl{thrd} rather than \glspl{proc} when doing \glsxtrshort{io} operations, which entails multiplexing the \glsxtrshort{io} operations of many \glspl{thrd} onto fewer \glspl{proc}. This multiplexing requires that a single \gls{proc} be able to execute multiple I/O operations in parallel. This requirement cannot be done with operations that block \glspl{proc}, \ie \glspl{kthrd}, since the first operation would prevent starting new operations for its blocking duration. Executing I/O operations in parallel requires \emph{asynchronous} \glsxtrshort{io}, sometimes referred to as \emph{non-blocking}, since the \gls{kthrd} does not block.
    3332
    34 \section{Interoperating with C}
     33Therefore, one of the objective of this work is to introduce \emph{User-Level \glsxtrshort{io}}, like \glslink{uthrding}{User-Level \emph{Threading}} blocks \glspl{thrd} rather than \glspl{proc} when doing \glsxtrshort{io} operations, which entails multiplexing the \glsxtrshort{io} operations of many \glspl{thrd} onto fewer \glspl{proc}. This multiplexing requires that a single \gls{proc} be able to execute multiple \glsxtrshort{io} operations in parallel. This requirement cannot be done with operations that block \glspl{proc}, \ie \glspl{kthrd}, since the first operation would prevent starting new operations for its blocking duration. Executing \glsxtrshort{io} operations in parallel requires \emph{asynchronous} \glsxtrshort{io}, sometimes referred to as \emph{non-blocking}, since the \gls{kthrd} does not block.
     34
     35\section{Interoperating with \texttt{C}}
    3536While \glsxtrshort{io} operations are the classical example of operations that block \glspl{kthrd}, the non-blocking challenge extends to all blocking system-calls. The POSIX standard states~\cite[\S~2.9.1]{POSIX17}:
    3637\begin{quote}
     
    4445\begin{enumerate}
    4546        \item Precisely identifying blocking C calls is difficult.
    46         \item Introducing new code can have a significant impact on general performance.
     47        \item Introducing control points code can have a significant impact on general performance.
    4748\end{enumerate}
    48 Because of these consequences, this work does not attempt to ``sandbox'' calls to C. Therefore, it is possible for an unidentified library calls to block a \gls{kthrd} leading to deadlocks in \CFA's M:N threading model, which would not occur in a traditional 1:1 threading model. Currently, all M:N thread systems interacting with UNIX without sandboxing suffer from this problem but manage to work very well in the majority of applications. Therefore, a complete solution to this problem is outside the scope of this thesis.
     49Because of these consequences, this work does not attempt to ``sandbox'' calls to C. Therefore, it is possible calls from an unidentified library will block a \gls{kthrd} leading to deadlocks in \CFA's M:N threading model, which would not occur in a traditional 1:1 threading model. Currently, all M:N thread systems interacting with UNIX without sandboxing suffer from this problem but manage to work very well in the majority of applications. Therefore, a complete solution to this problem is outside the scope of this thesis.
  • doc/theses/thierry_delisle_PhD/thesis/thesis.tex

    r5e99a9a r95b3a9c  
    1 % uWaterloo Thesis Template for LaTeX
    2 % Last Updated June 14, 2017 by Stephen Carr, IST Client Services
    3 % FOR ASSISTANCE, please send mail to rt-IST-CSmathsci@ist.uwaterloo.ca
    4 
    5 % Effective October 2006, the University of Waterloo
    6 % requires electronic thesis submission. See the uWaterloo thesis regulations at
     1%======================================================================
     2% University of Waterloo Thesis Template for LaTeX
     3% Last Updated November, 2020
     4% by Stephen Carr, IST Client Services,
     5% University of Waterloo, 200 University Ave. W., Waterloo, Ontario, Canada
     6% FOR ASSISTANCE, please send mail to request@uwaterloo.ca
     7
     8% DISCLAIMER
     9% To the best of our knowledge, this template satisfies the current uWaterloo thesis requirements.
     10% However, it is your responsibility to assure that you have met all requirements of the University and your particular department.
     11
     12% Many thanks for the feedback from many graduates who assisted the development of this template.
     13% Also note that there are explanatory comments and tips throughout this template.
     14%======================================================================
     15% Some important notes on using this template and making it your own...
     16
     17% The University of Waterloo has required electronic thesis submission since October 2006.
     18% See the uWaterloo thesis regulations at
    719% https://uwaterloo.ca/graduate-studies/thesis.
    8 
    9 % DON'T FORGET TO ADD YOUR OWN NAME AND TITLE in the "hyperref" package
    10 % configuration below. THIS INFORMATION GETS EMBEDDED IN THE PDF FINAL PDF DOCUMENT.
    11 % You can view the information if you view Properties of the PDF document.
    12 
    13 % Many faculties/departments also require one or more printed
    14 % copies. This template attempts to satisfy both types of output.
    15 % It is based on the standard "book" document class which provides all necessary
    16 % sectioning structures and allows multi-part theses.
    17 
    18 % DISCLAIMER
    19 % To the best of our knowledge, this template satisfies the current uWaterloo requirements.
    20 % However, it is your responsibility to assure that you have met all
    21 % requirements of the University and your particular department.
    22 % Many thanks for the feedback from many graduates that assisted the development of this template.
    23 
    24 % -----------------------------------------------------------------------
    25 
    26 % By default, output is produced that is geared toward generating a PDF
    27 % version optimized for viewing on an electronic display, including
    28 % hyperlinks within the PDF.
    29 
     20% This thesis template is geared towards generating a PDF version optimized for viewing on an electronic display, including hyperlinks within the PDF.
     21
     22% DON'T FORGET TO ADD YOUR OWN NAME AND TITLE in the "hyperref" package configuration below.
     23% THIS INFORMATION GETS EMBEDDED IN THE PDF FINAL PDF DOCUMENT.
     24% You can view the information if you view properties of the PDF document.
     25
     26% Many faculties/departments also require one or more printed copies.
     27% This template attempts to satisfy both types of output.
     28% See additional notes below.
     29% It is based on the standard "book" document class which provides all necessary sectioning structures and allows multi-part theses.
     30
     31% If you are using this template in Overleaf (cloud-based collaboration service), then it is automatically processed and previewed for you as you edit.
     32
     33% For people who prefer to install their own LaTeX distributions on their own computers, and process the source files manually, the following notes provide the sequence of tasks:
     34 
    3035% E.g. to process a thesis called "mythesis.tex" based on this template, run:
    3136
    3237% pdflatex mythesis     -- first pass of the pdflatex processor
    3338% bibtex mythesis       -- generates bibliography from .bib data file(s)
    34 % makeindex         -- should be run only if an index is used
     39% makeindex         -- should be run only if an index is used 
    3540% pdflatex mythesis     -- fixes numbering in cross-references, bibliographic references, glossaries, index, etc.
    36 % pdflatex mythesis     -- fixes numbering in cross-references, bibliographic references, glossaries, index, etc.
    37 
    38 % If you use the recommended LaTeX editor, Texmaker, you would open the mythesis.tex
    39 % file, then click the PDFLaTeX button. Then run BibTeX (under the Tools menu).
    40 % Then click the PDFLaTeX button two more times. If you have an index as well,
    41 % you'll need to run MakeIndex from the Tools menu as well, before running pdflatex
     41% pdflatex mythesis     -- it takes a couple of passes to completely process all cross-references
     42
     43% If you use the recommended LaTeX editor, Texmaker, you would open the mythesis.tex file, then click the PDFLaTeX button. Then run BibTeX (under the Tools menu).
     44% Then click the PDFLaTeX button two more times.
     45% If you have an index as well,you'll need to run MakeIndex from the Tools menu as well, before running pdflatex
    4246% the last two times.
    4347
    44 % N.B. The "pdftex" program allows graphics in the following formats to be
    45 % included with the "\includegraphics" command: PNG, PDF, JPEG, TIFF
    46 % Tip 1: Generate your figures and photos in the size you want them to appear
    47 % in your thesis, rather than scaling them with \includegraphics options.
    48 % Tip 2: Any drawings you do should be in scalable vector graphic formats:
    49 % SVG, PNG, WMF, EPS and then converted to PNG or PDF, so they are scalable in
    50 % the final PDF as well.
    51 % Tip 3: Photographs should be cropped and compressed so as not to be too large.
    52 
    53 % To create a PDF output that is optimized for double-sided printing:
    54 %
    55 % 1) comment-out the \documentclass statement in the preamble below, and
    56 % un-comment the second \documentclass line.
    57 %
    58 % 2) change the value assigned below to the boolean variable
    59 % "PrintVersion" from "false" to "true".
    60 
    61 % --------------------- Start of Document Preamble -----------------------
    62 
    63 % Specify the document class, default style attributes, and page dimensions
     48% N.B. The "pdftex" program allows graphics in the following formats to be included with the "\includegraphics" command: PNG, PDF, JPEG, TIFF
     49% Tip: Generate your figures and photos in the size you want them to appear in your thesis, rather than scaling them with \includegraphics options.
     50% Tip: Any drawings you do should be in scalable vector graphic formats: SVG, PNG, WMF, EPS and then converted to PNG or PDF, so they are scalable in the final PDF as well.
     51% Tip: Photographs should be cropped and compressed so as not to be too large.
     52
     53% To create a PDF output that is optimized for double-sided printing:
     54% 1) comment-out the \documentclass statement in the preamble below, and un-comment the second \documentclass line.
     55% 2) change the value assigned below to the boolean variable "PrintVersion" from " false" to "true".
     56
     57%======================================================================
     58%   D O C U M E N T   P R E A M B L E
     59% Specify the document class, default style attributes, and page dimensions, etc.
    6460% For hyperlinked PDF, suitable for viewing on a computer, use this:
    6561\documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
    6662
    67 % For PDF, suitable for double-sided printing, change the PrintVersion variable below
    68 % to "true" and use this \documentclass line instead of the one above:
     63% For PDF, suitable for double-sided printing, change the PrintVersion variable below to "true" and use this \documentclass line instead of the one above:
    6964%\documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
    7065
    71 \newcommand{\href}[1]{#1} % does nothing, but defines the command so the
    72     % print-optimized version will ignore \href tags (redefined by hyperref pkg).
     66% Some LaTeX commands I define for my own nomenclature.
     67% If you have to, it's easier to make changes to nomenclature once here than in a million places throughout your thesis!
     68\newcommand{\package}[1]{\textbf{#1}} % package names in bold text
     69\newcommand{\cmmd}[1]{\textbackslash\texttt{#1}} % command name in tt font
     70\newcommand{\href}[1]{#1} % does nothing, but defines the command so the print-optimized version will ignore \href tags (redefined by hyperref pkg).
     71%\newcommand{\texorpdfstring}[2]{#1} % does nothing, but defines the command
     72% Anything defined here may be redefined by packages added below...
    7373
    7474% This package allows if-then-else control structures.
     
    7676\newboolean{PrintVersion}
    7777\setboolean{PrintVersion}{false}
    78 % CHANGE THIS VALUE TO "true" as necessary, to improve printed results for hard copies
    79 % by overriding some options of the hyperref package below.
     78% CHANGE THIS VALUE TO "true" as necessary, to improve printed results for hard copies by overriding some options of the hyperref package, called below.
    8079
    8180%\usepackage{nomencl} % For a nomenclature (optional; available from ctan.org)
    8281\usepackage{amsmath,amssymb,amstext} % Lots of math symbols and environments
     82\usepackage{xcolor}
    8383\usepackage{graphicx} % For including graphics
    8484
    8585% Hyperlinks make it very easy to navigate an electronic document.
    86 % In addition, this is where you should specify the thesis title
    87 % and author as they appear in the properties of the PDF document.
     86% In addition, this is where you should specify the thesis title and author as they appear in the properties of the PDF document.
    8887% Use the "hyperref" package
    8988% N.B. HYPERREF MUST BE THE LAST PACKAGE LOADED; ADD ADDITIONAL PKGS ABOVE
    9089\usepackage[pagebackref=false]{hyperref} % with basic options
    91                 % N.B. pagebackref=true provides links back from the References to the body text. This can cause trouble for printing.
     90%\usepackage[pdftex,pagebackref=true]{hyperref}
     91% N.B. pagebackref=true provides links back from the References to the body text. This can cause trouble for printing.
    9292\hypersetup{
    9393        plainpages=false,       % needed if Roman numbers in frontpages
    94         unicode=false,          % non-Latin characters in Acrobats bookmarks
    95         pdftoolbar=true,        % show Acrobats toolbar?
    96         pdfmenubar=true,        % show Acrobats menu?
     94        unicode=false,          % non-Latin characters in Acrobat's bookmarks
     95        pdftoolbar=true,        % show Acrobat's toolbar?
     96        pdfmenubar=true,        % show Acrobat's menu?
    9797        pdffitwindow=false,     % window fit to page when opened
    9898        pdfstartview={FitH},    % fits the width of the page to the window
     
    110110\ifthenelse{\boolean{PrintVersion}}{   % for improved print quality, change some hyperref options
    111111\hypersetup{    % override some previously defined hyperref options
    112         citecolor=black,
    113         filecolor=black,
    114         linkcolor=black,
     112        citecolor=black,%
     113        filecolor=black,%
     114        linkcolor=black,%
    115115        urlcolor=black
    116116}}{} % end of ifthenelse (no else)
     
    120120% although it's supposed to be in both the TeX Live and MikTeX distributions. There are also documentation and
    121121% installation instructions there.
    122 \renewcommand*{\glstextformat}[1]{\textsf{#1}}
     122\makeatletter
     123\newcommand*{\glsplainhyperlink}[2]{%
     124  \colorlet{currenttext}{.}% store current text color
     125  \colorlet{currentlink}{\@linkcolor}% store current link color
     126  \hypersetup{linkcolor=currenttext}% set link color
     127  \hyperlink{#1}{#2}%
     128  \hypersetup{linkcolor=currentlink}% reset to default
     129}
     130\let\@glslink\glsplainhyperlink
     131\makeatother
    123132
    124133\usepackage{csquotes}
     
    126135
    127136% Setting up the page margins...
    128 \setlength{\textheight}{9in}\setlength{\topmargin}{-0.45in}\setlength{\headsep}{0.25in}
     137\setlength{\textheight}{9in}
     138\setlength{\topmargin}{-0.45in}
     139\setlength{\headsep}{0.25in}
    129140% uWaterloo thesis requirements specify a minimum of 1 inch (72pt) margin at the
    130 % top, bottom, and outside page edges and a 1.125 in. (81pt) gutter
    131 % margin (on binding side). While this is not an issue for electronic
    132 % viewing, a PDF may be printed, and so we have the same page layout for
    133 % both printed and electronic versions, we leave the gutter margin in.
     141% top, bottom, and outside page edges and a 1.125 in. (81pt) gutter margin (on binding side).
     142% While this is not an issue for electronic viewing, a PDF may be printed, and so we have the same page layout for both printed and electronic versions, we leave the gutter margin in.
    134143% Set margins to minimum permitted by uWaterloo thesis regulations:
    135144\setlength{\marginparwidth}{0pt} % width of margin notes
     
    140149\setlength{\evensidemargin}{0.125in} % Adds 1/8 in. to binding side of all
    141150% even-numbered pages when the "twoside" printing option is selected
    142 \setlength{\oddsidemargin}{0.125in} % Adds 1/8 in. to the left of all pages
    143 % when "oneside" printing is selected, and to the left of all odd-numbered
    144 % pages when "twoside" printing is selected
    145 \setlength{\textwidth}{6.375in} % assuming US letter paper (8.5 in. x 11 in.) and
    146 % side margins as above
     151\setlength{\oddsidemargin}{0.125in} % Adds 1/8 in. to the left of all pages when "oneside" printing is selected, and to the left of all odd-numbered pages when "twoside" printing is selected
     152\setlength{\textwidth}{6.375in} % assuming US letter paper (8.5 in. x 11 in.) and side margins as above
    147153\raggedbottom
    148154
    149 % The following statement specifies the amount of space between
    150 % paragraphs. Other reasonable specifications are \bigskipamount and \smallskipamount.
     155% The following statement specifies the amount of space between paragraphs. Other reasonable specifications are \bigskipamount and \smallskipamount.
    151156\setlength{\parskip}{\medskipamount}
    152157
    153 % The following statement controls the line spacing.  The default
    154 % spacing corresponds to good typographic conventions and only slight
    155 % changes (e.g., perhaps "1.2"), if any, should be made.
     158% The following statement controls the line spacing.
     159% The default spacing corresponds to good typographic conventions and only slight changes (e.g., perhaps "1.2"), if any, should be made.
    156160\renewcommand{\baselinestretch}{1} % this is the default line space setting
    157161
    158 % By default, each chapter will start on a recto (right-hand side)
    159 % page.  We also force each section of the front pages to start on
    160 % a recto page by inserting \cleardoublepage commands.
    161 % In many cases, this will require that the verso page be
    162 % blank and, while it should be counted, a page number should not be
    163 % printed.  The following statements ensure a page number is not
    164 % printed on an otherwise blank verso page.
     162% By default, each chapter will start on a recto (right-hand side) page.
     163% We also force each section of the front pages to start on a recto page by inserting \cleardoublepage commands.
     164% In many cases, this will require that the verso (left-hand) page be blank, and while it should be counted, a page number should not be printed.
     165% The following statements ensure a page number is not printed on an otherwise blank verso page.
    165166\let\origdoublepage\cleardoublepage
    166167\newcommand{\clearemptydoublepage}{%
     
    194195\input{common}
    195196\CFAStyle                                               % CFA code-style for all languages
    196 \lstset{basicstyle=\linespread{0.9}\tt}
     197\lstset{language=CFA,basicstyle=\linespread{0.9}\tt}    % CFA default language
    197198
    198199% glossary of terms to use
     
    200201\makeindex
    201202
    202 %======================================================================
    203 %   L O G I C A L    D O C U M E N T -- the content of your thesis
     203\newcommand\io{\glsxtrshort{io}\xspace}%
     204
     205%======================================================================
     206%   L O G I C A L    D O C U M E N T
     207% The logical document contains the main content of your thesis.
     208% Being a large document, it is a good idea to divide your thesis into several files, each one containing one chapter or other significant chunk of content, so you can easily shuffle things around later if desired.
    204209%======================================================================
    205210\begin{document}
    206211
    207 % For a large document, it is a good idea to divide your thesis
    208 % into several files, each one containing one chapter.
    209 % To illustrate this idea, the "front pages" (i.e., title page,
    210 % declaration, borrowers' page, abstract, acknowledgements,
    211 % dedication, table of contents, list of tables, list of figures,
    212 % nomenclature) are contained within the file "uw-ethesis-frontpgs.tex" which is
    213 % included into the document by the following statement.
    214212%----------------------------------------------------------------------
    215213% FRONT MATERIAL
     214% title page,declaration, borrowers' page, abstract, acknowledgements,
     215% dedication, table of contents, list of tables, list of figures, nomenclature, etc.
    216216%----------------------------------------------------------------------
    217217\input{text/front.tex}
    218218
    219 
    220219%----------------------------------------------------------------------
    221220% MAIN BODY
    222 %----------------------------------------------------------------------
    223 % Because this is a short document, and to reduce the number of files
    224 % needed for this template, the chapters are not separate
    225 % documents as suggested above, but you get the idea. If they were
    226 % separate documents, they would each start with the \chapter command, i.e,
    227 % do not contain \documentclass or \begin{document} and \end{document} commands.
     221% We suggest using a separate file for each chapter of your thesis.
     222% Start each chapter file with the \chapter command.
     223% Only use \documentclass or \begin{document} and \end{document} commands in this master document.
     224% Tip: Putting each sentence on a new line is a way to simplify later editing.
     225%----------------------------------------------------------------------
     226
    228227\part{Introduction}
    229228\input{text/intro.tex}
     
    232231\part{Design}
    233232\input{text/core.tex}
     233\input{text/io.tex}
    234234\input{text/practice.tex}
    235 \input{text/io.tex}
    236235\part{Evaluation}
    237236\label{Evaluation}
     
    243242%----------------------------------------------------------------------
    244243% END MATERIAL
    245 %----------------------------------------------------------------------
    246 
    247 % B I B L I O G R A P H Y
    248 % -----------------------
    249 
    250 % The following statement selects the style to use for references.  It controls the sort order of the entries in the bibliography and also the formatting for the in-text labels.
     244% Bibliography, Appendices, Index, etc.
     245%----------------------------------------------------------------------
     246
     247% Bibliography
     248
     249% The following statement selects the style to use for references.
     250% It controls the sort order of the entries in the bibliography and also the formatting for the in-text labels.
    251251\bibliographystyle{plain}
    252252% This specifies the location of the file containing the bibliographic information.
    253 % It assumes you're using BibTeX (if not, why not?).
    254 \cleardoublepage % This is needed if the book class is used, to place the anchor in the correct page,
    255                  % because the bibliography will start on its own page.
    256                  % Use \clearpage instead if the document class uses the "oneside" argument
     253% It assumes you're using BibTeX to manage your references (if not, why not?).
     254\cleardoublepage % This is needed if the "book" document class is used, to place the anchor in the correct page, because the bibliography will start on its own page.
     255% Use \clearpage instead if the document class uses the "oneside" argument
    257256\phantomsection  % With hyperref package, enables hyperlinking from the table of contents to bibliography
    258257% The following statement causes the title "References" to be used for the bibliography section:
     
    263262
    264263\bibliography{local,pl}
    265 % Tip 5: You can create multiple .bib files to organize your references.
     264% Tip: You can create multiple .bib files to organize your references.
    266265% Just list them all in the \bibliogaphy command, separated by commas (no spaces).
    267266
    268 % % The following statement causes the specified references to be added to the bibliography% even if they were not
    269 % % cited in the text. The asterisk is a wildcard that causes all entries in the bibliographic database to be included (optional).
     267% The following statement causes the specified references to be added to the bibliography even if they were not cited in the text.
     268% The asterisk is a wildcard that causes all entries in the bibliographic database to be included (optional).
    270269% \nocite{*}
     270%----------------------------------------------------------------------
     271
     272% Appendices
    271273
    272274% The \appendix statement indicates the beginning of the appendices.
    273275\appendix
    274 % Add a title page before the appendices and a line in the Table of Contents
     276% Add an un-numbered title page before the appendices and a line in the Table of Contents
    275277\chapter*{APPENDICES}
    276278\addcontentsline{toc}{chapter}{APPENDICES}
     279% Appendices are just more chapters, with different labeling (letters instead of numbers).
    277280%======================================================================
    278281\chapter[PDF Plots From Matlab]{Matlab Code for Making a PDF Plot}
     
    312315%\input{thesis.ind}                             % index
    313316
    314 \phantomsection
    315 
    316 \end{document}
     317\phantomsection         % allows hyperref to link to the correct page
     318
     319%----------------------------------------------------------------------
     320\end{document} % end of logical document
  • doc/user/figures/Cdecl.fig

    r5e99a9a r95b3a9c  
    19192 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
    2020         2850 1200 3600 1200 3600 1350 2850 1350 2850 1200
    21 4 1 0 50 -1 4 10 0.0000 2 120 90 2925 1325 0\001
    22 4 1 0 50 -1 4 10 0.0000 2 120 90 3075 1325 1\001
    23 4 1 0 50 -1 4 10 0.0000 2 120 90 3225 1325 2\001
    24 4 1 0 50 -1 4 10 0.0000 2 120 90 3375 1325 3\001
    25 4 1 0 50 -1 4 10 0.0000 2 120 90 3525 1325 4\001
     214 1 0 50 -1 4 11 0.0000 2 120 90 2925 1325 0\001
     224 1 0 50 -1 4 11 0.0000 2 120 90 3075 1325 1\001
     234 1 0 50 -1 4 11 0.0000 2 120 90 3225 1325 2\001
     244 1 0 50 -1 4 11 0.0000 2 120 90 3375 1325 3\001
     254 1 0 50 -1 4 11 0.0000 2 120 90 3525 1325 4\001
    2626-6
    27272 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
     
    5555        1 1 1.00 45.00 60.00
    5656         2550 1275 2850 1275
    57 4 1 0 50 -1 4 10 0.0000 2 120 90 1350 1650 0\001
    58 4 1 0 50 -1 4 10 0.0000 2 120 90 1500 1650 1\001
    59 4 1 0 50 -1 4 10 0.0000 2 120 90 1650 1650 2\001
    60 4 1 0 50 -1 4 10 0.0000 2 120 90 1800 1650 3\001
    61 4 1 0 50 -1 4 10 0.0000 2 120 90 1950 1650 4\001
    62 4 1 0 50 -1 4 10 0.0000 2 90 90 1200 1325 x\001
    63 4 1 0 50 -1 4 10 0.0000 2 90 90 2400 1325 x\001
     574 1 0 50 -1 4 11 0.0000 2 120 90 1350 1650 0\001
     584 1 0 50 -1 4 11 0.0000 2 120 90 1500 1650 1\001
     594 1 0 50 -1 4 11 0.0000 2 120 90 1650 1650 2\001
     604 1 0 50 -1 4 11 0.0000 2 120 90 1800 1650 3\001
     614 1 0 50 -1 4 11 0.0000 2 120 90 1950 1650 4\001
     624 1 0 50 -1 4 11 0.0000 2 90 90 1200 1325 x\001
     634 1 0 50 -1 4 11 0.0000 2 90 90 2400 1325 x\001
  • doc/user/user.tex

    r5e99a9a r95b3a9c  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Mon Oct  5 08:57:29 2020
    14 %% Update Count     : 3998
     13%% Last Modified On : Mon Feb 15 13:48:53 2021
     14%% Update Count     : 4452
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    3737\usepackage{mathptmx}                                   % better math font with "times"
    3838\usepackage[usenames]{color}
     39\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
     40\usepackage{breakurl}
     41
     42\renewcommand\footnoterule{\kern -3pt\rule{0.3\linewidth}{0.15pt}\kern 2pt}
     43
     44\usepackage[pagewise]{lineno}
     45\renewcommand{\linenumberfont}{\scriptsize\sffamily}
     46\usepackage[firstpage]{draftwatermark}
     47\SetWatermarkLightness{0.9}
     48
     49% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
     50% removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
     51% AFTER HYPERREF.
     52\renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
     53
     54\setlength{\topmargin}{-0.45in}                                                 % move running title into header
     55\setlength{\headsep}{0.25in}
     56
     57%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     58
    3959\newcommand{\CFALatin}{}
    4060% inline code ©...© (copyright symbol) emacs: C-q M-)
     
    4666% math escape $...$ (dollar symbol)
    4767\input{common}                                          % common CFA document macros
    48 \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    49 \usepackage{breakurl}
    50 
    51 \renewcommand\footnoterule{\kern -3pt\rule{0.3\linewidth}{0.15pt}\kern 2pt}
    52 
    53 \usepackage[pagewise]{lineno}
    54 \renewcommand{\linenumberfont}{\scriptsize\sffamily}
    55 \usepackage[firstpage]{draftwatermark}
    56 \SetWatermarkLightness{0.9}
    57 
    58 % Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
    59 % removes it as a variable-name character so keywords in variables are highlighted. MUST APPEAR
    60 % AFTER HYPERREF.
    61 \renewcommand{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.075ex}}}
    62 
    63 \setlength{\topmargin}{-0.45in}                                                 % move running title into header
    64 \setlength{\headsep}{0.25in}
    65 
    66 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    67 
    6868\CFAStyle                                                                                               % use default CFA format-style
     69\lstset{language=CFA}                                                                   % CFA default lnaguage
    6970\lstnewenvironment{C++}[1][]                            % use C++ style
    70 {\lstset{language=C++,moredelim=**[is][\protect\color{red}]{®}{®},#1}}
     71{\lstset{language=C++,moredelim=**[is][\protect\color{red}]{@}{@},#1}}
    7172{}
    7273
     
    8182\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
    8283\newcommand{\R}[1]{\Textbf{#1}}
     84\newcommand{\RC}[1]{\Textbf{\LstBasicStyle{#1}}}
    8385\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
    8486\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
     
    103105
    104106\author{
    105 \huge \CFA Team \medskip \\
    106 \Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\
    107 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
     107\huge \CFA Team (past and present) \medskip \\
     108\Large Andrew Beach, Richard Bilson, Michael Brooks, Peter A. Buhr, Thierry Delisle, \smallskip \\
     109\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Colby Parsons, Rob Schluntz, \smallskip \\
     110\Large Fangren Yu, Mubeen Zulfiqar
    108111}% author
    109112
     
    126129\vspace*{\fill}
    127130\noindent
    128 \copyright\,2016 \CFA Project \\ \\
     131\copyright\,2016, 2018, 2021 \CFA Project \\ \\
    129132\noindent
    130133This work is licensed under the Creative Commons Attribution 4.0 International License.
     
    144147\section{Introduction}
    145148
    146 \CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed as an evolutionary step forward for the C programming language.
     149\CFA{}\index{cforall@\CFA}\footnote{Pronounced ``\Index*{C-for-all}'', and written \CFA, CFA, or \CFL.} is a modern general-purpose concurrent programming-language, designed as an evolutionary step forward for the C programming language.
    147150The syntax of \CFA builds from C and should look immediately familiar to C/\Index*[C++]{\CC{}} programmers.
    148151% Any language feature that is not described here can be assumed to be using the standard \Celeven syntax.
    149 \CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
     152\CFA adds many modern features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
    150153Like C, \CFA is a statically typed, procedural (non-\Index{object-oriented}) language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
    151154The primary new features include polymorphic routines and types, exceptions, concurrency, and modules.
     
    157160instead, a programmer evolves a legacy program into \CFA by incrementally incorporating \CFA features.
    158161As well, new programs can be written in \CFA using a combination of C and \CFA features.
     162In many ways, \CFA is to C as \Index{Scala}~\cite{Scala} is to Java, providing a vehicle for new typing and control-flow capabilities on top of a highly popular programming language allowing immediate dissemination.
    159163
    160164\Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
     
    165169For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
    166170\begin{center}
    167 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
    168 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
    169 \begin{cfa}
    170 #include <stdio.h>§\indexc{stdio.h}§
     171\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
     172\multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
     173\begin{cfa}
     174#include <stdio.h>$\indexc{stdio.h}$
    171175
    172176int main( void ) {
    173177        int x = 0, y = 1, z = 2;
    174         ®printf( "%d %d %d\n", x, y, z );®
     178        @printf( "%d %d %d\n", x, y, z );@
    175179}
    176180\end{cfa}
    177181&
    178182\begin{cfa}
    179 #include <fstream>§\indexc{fstream}§
     183#include <fstream>$\indexc{fstream}$
    180184
    181185int main( void ) {
    182186        int x = 0, y = 1, z = 2;
    183         ®sout | x | y | z;®§\indexc{sout}§
     187        @sout | x | y | z;@$\indexc{sout}$
    184188}
    185189\end{cfa}
    186190&
    187191\begin{cfa}
    188 #include <iostream>§\indexc{iostream}§
     192#include <iostream>$\indexc{iostream}$
    189193using namespace std;
    190194int main() {
    191195        int x = 0, y = 1, z = 2;
    192         ®cout<<x<<" "<<y<<" "<<z<<endl;®
     196        @cout<<x<<" "<<y<<" "<<z<<endl;@
    193197}
    194198\end{cfa}
    195199\end{tabular}
    196200\end{center}
    197 While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
     201While \CFA I/O \see{\VRef{s:StreamIOLibrary}} looks similar to \Index*[C++]{\CC{}}, there are important differences, such as automatic spacing between variables and an implicit newline at the end of the expression list, similar to \Index*{Python}~\cite{Python}.
    198202
    199203
     
    210214\section{Why fix C?}
    211215
    212 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
     216The C programming language is a foundational technology for modern computing with billions of lines of code implementing everything from hobby projects to commercial operating-systems.
    213217This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
    214218Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
    215 For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
    216 The TIOBE index~\cite{TIOBE} for February 2020 ranks the top six most \emph{popular} programming languages as \Index*{Java} 17.4\%, C 16.8\%, Python 9.3\%, \Index*[C++]{\CC{}} 6.2\%, \Csharp 5.9\%, Visual Basic 5.9\% = 61.5\%, where the next 50 languages are less than 2\% each, with a long tail.
     219For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is the only language of choice.
     220The TIOBE index~\cite{TIOBE} for February 2021 ranks the top six most \emph{popular} programming languages as C 17.4\%, \Index*{Java} 12\%, Python 12\%, \Index*[C++]{\CC{}} 7.6\%, \Csharp 4\%, Visual Basic 3.8\% = 56.8\%, where the next 50 languages are less than 2\% each, with a long tail.
    217221The top 4 rankings over the past 35 years are:
    218222\begin{center}
    219223\setlength{\tabcolsep}{10pt}
    220224\begin{tabular}{@{}rcccccccc@{}}
    221                 & 2020  & 2015  & 2010  & 2005  & 2000  & 1995  & 1990  & 1985  \\ \hline
    222 Java    & 1             & 2             & 1             & 2             & 3             & -             & -             & -             \\
    223 \R{C}   & \R{2} & \R{1} & \R{2} & \R{1} & \R{1} & \R{2} & \R{1} & \R{1} \\
    224 Python  & 3             & 7             & 6             & 6             & 22    & 21    & -             & -             \\
    225 \CC             & 4             & 4             & 4             & 3             & 2             & 1             & 2             & 12    \\
     225                & 2021  & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986  \\ \hline
     226\R{C}   & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1} & \R{1} \\
     227Java    & 2             & 1             & 1             & 2             & 3             & 28    & -             & -             \\
     228Python  & 3             & 5             & 6             & 7             & 23    & 13    & -             & -             \\
     229\CC             & 4             & 3             & 3             & 3             & 2             & 2             & 2             & 8             \\
    226230\end{tabular}
    227231\end{center}
     
    232236As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
    233237\CC~\cite{C++14,C++} is an example of a similar project;
    234 however, it largely extended the C language, and did not address most of C's existing problems.\footnote{%
     238however, it largely extended the C language, and did not address many of C's existing problems.\footnote{%
    235239Two 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.}
    236240\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.
     
    241245
    242246The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while adding modern language-features.
    243 To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
    244 Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
    245 as a result, it will fade into disuse.
    246 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
     247To achieve these goals required a significant engineering exercise, \ie ``thinking \emph{inside} the C box''.
     248Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern language.
    247249While \Index*[C11]{\Celeven{}} made a few simple extensions to the language, nothing was added to address existing problems in the language or to augment the language with modern language-features.
    248250While some may argue that modern language-features may make C complex and inefficient, it is clear a language without modern capabilities is insufficient for the advanced programming problems existing today.
     
    251253\section{History}
    252254
    253 The \CFA project started with \Index*{Dave Till}\index{Till, Dave}'s \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and advanced assignment capabilities using the notion of tuples.
    254 (See~\cite{Werther96} for similar work in \Index*[C++]{\CC{}}.)
     255The \CFA project started with \Index*{Dave Till}\index{Till, Dave}'s \Index*{K-W C}~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and advanced assignment capabilities using the notion of tuples \see{\cite{Werther96} for similar work in \Index*[C++]{\CC{}}}.
    255256The first \CFA implementation of these extensions was by \Index*{Rodolfo Esteves}\index{Esteves, Rodolfo}~\cite{Esteves04}.
    256257
    257258The signature feature of \CFA is \emph{\Index{overload}able} \Index{parametric-polymorphic} functions~\cite{forceone:impl,Cormack90,Duggan96} with functions generalized using a ©forall© clause (giving the language its name):
    258259\begin{cfa}
    259 ®forall( otype T )® T identity( T val ) { return val; }
    260 int forty_two = identity( 42 ); §\C{// T is bound to int, forty\_two == 42}§
     260@forall( otype T )@ T identity( T val ) { return val; }
     261int forty_two = identity( 42 ); $\C{// T is bound to int, forty\_two == 42}$
    261262\end{cfa}
    262263% extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
    263264\CFA{}\hspace{1pt}'s polymorphism was originally formalized by \Index*{Glen Ditchfield}\index{Ditchfield, Glen}~\cite{Ditchfield92}, and first implemented by \Index*{Richard Bilson}\index{Bilson, Richard}~\cite{Bilson03}.
    264265However, at that time, there was little interesting in extending C, so work did not continue.
    265 As the saying goes, ``\Index*{What goes around, comes around.}'', and there is now renewed interest in the C programming language because of legacy code-bases, so the \CFA project has been restarted.
     266As the saying goes, ``\Index*{What goes around, comes around.}'', and there is now renewed interest in the C programming language because of the legacy code-base, so the \CFA project was restarted in 2015.
    266267
    267268
     
    273274This feature allows \CFA programmers to take advantage of the existing panoply of C libraries to access thousands of external software features.
    274275Language developers often state that adequate \Index{library support} takes more work than designing and implementing the language itself.
    275 Fortunately, \CFA, like \Index*[C++]{\CC{}}, starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at very low cost.
     276Fortunately, \CFA, like \Index*[C++]{\CC{}}, starts with immediate access to all exiting C libraries, and in many cases, can easily wrap library routines with simpler and safer interfaces, at zero or very low cost.
    276277Hence, \CFA begins by leveraging the large repository of C libraries, and than allows programmers to incrementally augment their C programs with modern \Index{backward-compatible} features.
    277278
     
    286287
    287288double key = 5.0, vals[10] = { /* 10 sorted floating values */ };
    288 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); §\C{// search sorted array}§
     289double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$
    289290\end{cfa}
    290291which can be augmented simply with a polymorphic, type-safe, \CFA-overloaded wrappers:
     
    295296
    296297forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
    297         T * result = bsearch( key, arr, size ); §\C{// call first version}§
    298         return result ? result - arr : size; } §\C{// pointer subtraction includes sizeof(T)}§
    299 
    300 double * val = bsearch( 5.0, vals, 10 ); §\C{// selection based on return type}§
     298        T * result = bsearch( key, arr, size ); $\C{// call first version}$
     299        return result ? result - arr : size; } $\C{// pointer subtraction includes sizeof(T)}$
     300
     301double * val = bsearch( 5.0, vals, 10 ); $\C{// selection based on return type}$
    301302int posn = bsearch( 5.0, vals, 10 );
    302303\end{cfa}
     
    310311\begin{cfa}
    311312forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
    312 int * ip = malloc(); §\C{// select type and size from left-hand side}§
     313int * ip = malloc(); $\C{// select type and size from left-hand side}$
    313314double * dp = malloc();
    314315struct S {...} * sp = malloc();
     
    319320However, it is necessary to differentiate between C and \CFA code because of name \Index{overload}ing, as for \CC.
    320321For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
    321 Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
    322 \begin{cfa}
    323 char ®abs®( char );
    324 extern "C" { int ®abs®( int ); } §\C{// use default C routine for int}§
    325 long int ®abs®( long int );
    326 long long int ®abs®( long long int );
    327 float ®abs®( float );
    328 double ®abs®( double );
    329 long double ®abs®( long double );
    330 float _Complex ®abs®( float _Complex );
    331 double _Complex ®abs®( double _Complex );
    332 long double _Complex ®abs®( long double _Complex );
    333 \end{cfa}
    334 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
    335 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
    336 Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
    337 Hence, 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.
    338 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
    339 
    340 This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
     322Whereas, \CFA wraps each of these routines into one overloaded name ©abs©:
     323\begin{cfa}
     324char @abs@( char );
     325extern "C" { int @abs@( int ); } $\C{// use default C routine for int}$
     326long int @abs@( long int );
     327long long int @abs@( long long int );
     328float @abs@( float );
     329double @abs@( double );
     330long double @abs@( long double );
     331float _Complex @abs@( float _Complex );
     332double _Complex @abs@( double _Complex );
     333long double _Complex @abs@( long double _Complex );
     334\end{cfa}
     335The problem is \Index{name clash} between the C name ©abs© and the \CFA names ©abs©, resulting in two name linkages\index{C linkage}: ©extern "C"© and ©extern "Cforall"© (default).
     336Overloaded names must use \newterm{name mangling}\index{mangling!name} to create unique names that are different from unmangled C names.
     337Hence, 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.
     338The only way around this problem is C's approach of creating unique names for each pairing of operation and type.
     339
     340This example illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
    341341The name ``©abs©'' evokes the notion of absolute value, and many mathematical types provide the notion of absolute value.
    342342Hence, knowing the name ©abs© is sufficient to apply it to any type where it is applicable.
     
    344344
    345345
    346 \section[Compiling a CFA Program]{Compiling a \CFA Program}
     346\section{\CFA Compilation}
    347347
    348348The command ©cfa© is used to compile a \CFA program and is based on the \Index{GNU} \Indexc{gcc} command, \eg:
    349349\begin{cfa}
    350 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] [ C/§\CFA{}§ source-files ] [ assembler/loader files ]
    351 \end{cfa}
    352 \CFA programs having the following ©gcc© flags turned on:
    353 \begin{description}
     350cfa$\indexc{cfa}\index{compilation!cfa@©cfa©}$ [ gcc/$\CFA{}$-options ] [ C/$\CFA{}$ source-files ] [ assembler/loader files ]
     351\end{cfa}
     352There is no ordering among options (flags) and files, unless an option has an argument, which must appear immediately after the option possibly with or without a space separating option and argument.
     353
     354\CFA has the following ©gcc© flags turned on:
     355\begin{description}[topsep=0pt]
    354356\item
    355357\Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
     
    359361Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
    360362\end{description}
    361 The following new \CFA options are available:
    362 \begin{description}
     363
     364\CFA has the following new options:
     365\begin{description}[topsep=0pt]
    363366\item
    364367\Indexc{-CFA}\index{compilation option!-CFA@©-CFA©}
    365 Only 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.
     368Only the C preprocessor (flag ©-E©) 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.
    366369The generated code starts with the standard \CFA \Index{prelude}.
     370
     371\item
     372\Indexc{-XCFA}\index{compilation option!-XCFA@©-XCFA©}
     373Pass next flag as-is to the ©cfa-cpp© translator (see details below).
    367374
    368375\item
    369376\Indexc{-debug}\index{compilation option!-debug@©-debug©}
    370377The program is linked with the debugging version of the runtime system.
    371 The debug version performs runtime checks to help during the debugging phase of a \CFA program, but can substantially slow program execution.
     378The debug version performs runtime checks to aid the debugging phase of a \CFA program, but can substantially slow program execution.
    372379The runtime checks should only be removed after the program is completely debugged.
    373380\textbf{This option is the default.}
     
    399406\item
    400407\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
    401 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
     408Do not supply ©extern "C"© wrappers for \Celeven standard include files \see{\VRef{s:StandardHeaders}}.
    402409\textbf{This option is \emph{not} the default.}
    403410\end{comment}
     
    430437\begin{cfa}
    431438#ifndef __CFORALL__
    432 #include <stdio.h>§\indexc{stdio.h}§ §\C{// C header file}§
     439#include <stdio.h>$\indexc{stdio.h}$ $\C{// C header file}$
    433440#else
    434 #include <fstream>§\indexc{fstream}§ §\C{// \CFA header file}§
     441#include <fstream>$\indexc{fstream}$ $\C{// \CFA header file}$
    435442#endif
    436443\end{cfa}
     
    438445
    439446The \CFA translator has multiple steps.
    440 The following flags control how the tranlator works, the stages run, and printing within a stage.
     447The following flags control how the translator works, the stages run, and printing within a stage.
    441448The majority of these flags are used by \CFA developers, but some are occasionally useful to programmers.
     449Each option must be escaped with \Indexc{-XCFA}\index{translator option!-XCFA@{©-XCFA©}} to direct it to the compiler step, similar to the ©-Xlinker© flag for the linker, \eg:
     450\begin{lstlisting}[language=sh]
     451cfa $test$.cfa -CFA -XCFA -p # print translated code without printing the standard prelude
     452cfa $test$.cfa -XCFA -P -XCFA parse -XCFA -n # show program parse without prelude
     453\end{lstlisting}
    442454\begin{description}[topsep=5pt,itemsep=0pt,parsep=0pt]
    443455\item
    444 \Indexc{-h}\index{translator option!-h@{©-h©}}, \Indexc{--help}\index{translator option!--help@{©--help©}} \, print help message
    445 \item
    446 \Indexc{-l}\index{translator option!-l@{©-l©}}, \Indexc{--libcfa}\index{translator option!--libcfa@{©--libcfa©}} \, generate libcfa.c
     456\Indexc{-c}\index{translator option!-c@{©-c©}}, \Indexc{--colors}\index{translator option!--colors@{©--colors©}} \, diagnostic color: ©never©, ©always©, \lstinline[deletekeywords=auto]{auto}
     457\item
     458\Indexc{-g}\index{translator option!-g@{©-g©}}, \Indexc{--gdb}\index{translator option!--gdb@{©--gdb©}} \, wait for gdb to attach
     459\item
     460\Indexc{-h}\index{translator option!-h@{©-h©}}, \Indexc{--help}\index{translator option!--help@{©--help©}} \, print translator help message
     461\item
     462\Indexc{-l}\index{translator option!-l@{©-l©}}, \Indexc{--libcfa}\index{translator option!--libcfa@{©--libcfa©}} \, generate ©libcfa.c©
    447463\item
    448464\Indexc{-L}\index{translator option!-L@{©-L©}}, \Indexc{--linemarks}\index{translator option!--linemarks@{©--linemarks©}} \, generate line marks
     
    454470\Indexc{-n}\index{translator option!-n@{©-n©}}, \Indexc{--no-prelude}\index{translator option!--no-prelude@{©--no-prelude©}} \, do not read prelude
    455471\item
    456 \Indexc{-p}\index{translator option!-p@{©-p©}}, \Indexc{--prototypes}\index{translator option!--prototypes@{©--prototypes©}} \, generate prototypes for prelude functions
     472\Indexc{-p}\index{translator option!-p@{©-p©}}, \Indexc{--prototypes}\index{translator option!--prototypes@{©--prototypes©}} \, do not generate prelude prototypes $\Rightarrow$ prelude not printed
     473\item
     474\Indexc{-d}\index{translator option!-d@{©-d©}}, \Indexc{--deterministic-out}\index{translator option!--deterministic-out@{©--deterministic-out©}} \, only print deterministic output
    457475\item
    458476\Indexc{-P}\index{translator option!-P@{©-P©}}, \Indexc{--print}\index{translator option!--print@{©--print©}} \, one of:
    459477\begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
    460478\item
     479\Indexc{ascodegen}\index{translator option!-P@{©-P©}!©ascodegen©}\index{translator option!--print@{©-print©}!©ascodegen©} \, as codegen rather than AST
     480\item
     481\Indexc{asterr}\index{translator option!-P@{©-P©}!©asterr©}\index{translator option!--print@{©-print©}!©asterr©} \, AST on error
     482\item
     483\Indexc{declstats}\index{translator option!-P@{©-P©}!©declstats©}\index{translator option!--print@{©-print©}!©declstats©} \, code property statistics
     484\item
     485\Indexc{parse}\index{translator option!-P@{©-P©}!©parse©}\index{translator option!--print@{©-print©}!©parse©} \, yacc (parsing) debug information
     486\item
     487\Indexc{pretty}\index{translator option!-P@{©-P©}!©pretty©}\index{translator option!--print@{©-print©}!©pretty©} \, prettyprint for ©ascodegen© flag
     488\item
     489\Indexc{rproto}\index{translator option!-P@{©-P©}!©rproto©}\index{translator option!--print@{©-print©}!©rproto©} \, resolver-proto instance
     490\item
     491\Indexc{rsteps}\index{translator option!-P@{©-P©}!©rsteps©}\index{translator option!--print@{©-print©}!©rsteps©} \, resolver steps
     492\item
     493\Indexc{tree}\index{translator option!-P@{©-P©}!©tree©}\index{translator option!--print@{©-print©}!©tree©} \, parse tree
     494\item
     495\Indexc{ast}\index{translator option!-P@{©-P©}!©ast©}\index{translator option!--print@{©-print©}!©ast©} \, AST after parsing
     496\item
     497\Indexc{symevt}\index{translator option!-P@{©-P©}!©symevt©}\index{translator option!--print@{©-print©}!©symevt©} \, symbol table events
     498\item
    461499\Indexc{altexpr}\index{translator option!-P@{©-P©}!©altexpr©}\index{translator option!--print@{©-print©}!©altexpr©} \, alternatives for expressions
    462500\item
    463 \Indexc{ascodegen}\index{translator option!-P@{©-P©}!©ascodegen©}\index{translator option!--print@{©-print©}!©ascodegen©} \, as codegen rather than AST
    464 \item
    465 \Indexc{ast}\index{translator option!-P@{©-P©}!©ast©}\index{translator option!--print@{©-print©}!©ast©} \, AST after parsing
    466 \item
    467501\Indexc{astdecl}\index{translator option!-P@{©-P©}!©astdecl©}\index{translator option!--print@{©-print©}!©astdecl©} \, AST after declaration validation pass
    468502\item
    469 \Indexc{asterr}\index{translator option!-P@{©-P©}!©asterr©}\index{translator option!--print@{©-print©}!©asterr©} \, AST on error
     503\Indexc{resolver}\index{translator option!-P@{©-P©}!©resolver©}\index{translator option!--print@{©-print©}!©resolver©} \, before resolver step
    470504\item
    471505\Indexc{astexpr}\index{translator option!-P@{©-P©}!©astexpr©}\index{translator option!--print@{©-print©}!©altexpr©} \, AST after expression analysis
    472506\item
     507\Indexc{ctordtor}\index{translator option!-P@{©-P©}!©ctordtor©}\index{translator option!--print@{©-print©}!©ctordtor©} \, after ctor/dtor are replaced
     508\item
     509\Indexc{tuple}\index{translator option!-P@{©-P©}!©tuple©}\index{translator option!--print@{©-print©}!©tuple©} \, after tuple expansion
     510\item
    473511\Indexc{astgen}\index{translator option!-P@{©-P©}!©astgen©}\index{translator option!--print@{©-print©}!©astgen©} \, AST after instantiate generics
    474512\item
    475513\Indexc{box}\index{translator option!-P@{©-P©}!©box©}\index{translator option!--print@{©-print©}!©box©} \, before box step
    476514\item
    477 \Indexc{ctordtor}\index{translator option!-P@{©-P©}!©ctordtor©}\index{translator option!--print@{©-print©}!©ctordtor©} \, after ctor/dtor are replaced
    478 \item
    479515\Indexc{codegen}\index{translator option!-P@{©-P©}!©codegen©}\index{translator option!--print@{©-print©}!©codegen©} \, before code generation
    480 \item
    481 \Indexc{declstats}\index{translator option!-P@{©-P©}!©declstats©}\index{translator option!--print@{©-print©}!©declstats©} \, code property statistics
    482 \item
    483 \Indexc{parse}\index{translator option!-P@{©-P©}!©parse©}\index{translator option!--print@{©-print©}!©parse©} \, yacc (parsing) debug information
    484 \item
    485 \Indexc{pretty}\index{translator option!-P@{©-P©}!©pretty©}\index{translator option!--print@{©-print©}!©pretty©} \, prettyprint for ascodegen flag
    486 \item
    487 \Indexc{resolver}\index{translator option!-P@{©-P©}!©resolver©}\index{translator option!--print@{©-print©}!©resolver©} \, before resolver step
    488 \item
    489 \Indexc{rproto}\index{translator option!-P@{©-P©}!©rproto©}\index{translator option!--print@{©-print©}!©rproto©} \, resolver-proto instance
    490 \item
    491 \Indexc{rsteps}\index{translator option!-P@{©-P©}!©rsteps©}\index{translator option!--print@{©-print©}!©rsteps©} \, resolver steps
    492 \item
    493 \Indexc{symevt}\index{translator option!-P@{©-P©}!©symevt©}\index{translator option!--print@{©-print©}!©symevt©} \, symbol table events
    494 \item
    495 \Indexc{tree}\index{translator option!-P@{©-P©}!©tree©}\index{translator option!--print@{©-print©}!©tree©} \, parse tree
    496 \item
    497 \Indexc{tuple}\index{translator option!-P@{©-P©}!©tuple©}\index{translator option!--print@{©-print©}!©tuple©} \, after tuple expansion
    498516\end{description}
    499517\item
    500518\Indexc{--prelude-dir} <directory> \, prelude directory for debug/nodebug
    501519\item
    502 \Indexc{-S}\index{translator option!-S@{©-S©}!©counters,heap,time,all,none©}, \Indexc{--statistics}\index{translator option!--statistics@{©--statistics©}!©counters,heap,time,all,none©} <option-list> \, enable profiling information:
    503 \begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
    504 \item
    505 \Indexc{counters,heap,time,all,none}
    506 \end{description}
     520\Indexc{-S}\index{translator option!-S@{©-S©}!©counters,heap,time,all,none©}, \Indexc{--statistics}\index{translator option!--statistics@{©--statistics©}!©counters,heap,time,all,none©} <option-list> \, enable profiling information: ©counters©, ©heap©, ©time©, ©all©, ©none©
    507521\item
    508522\Indexc{-t}\index{translator option!-t@{©-t©}}, \Indexc{--tree}\index{translator option!--tree@{©--tree©}} build in tree
     
    513527\label{s:BackquoteIdentifiers}
    514528
    515 \CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
     529\CFA introduces several new keywords \see{\VRef{s:CFAKeywords}} that can clash with existing C variable-names in legacy code.
    516530Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
    517531\begin{cfa}
    518 int ®``®otype = 3; §\C{// make keyword an identifier}§
    519 double ®``®forall = 3.5;
     532int @``@otype = 3; $\C{// make keyword an identifier}$
     533double @``@forall = 3.5;
    520534\end{cfa}
    521535
    522536Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
    523 \VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
     537\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files \see{\VRef{s:StandardHeaders}} can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
    524538Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
    525539
     
    527541\begin{cfa}
    528542// include file uses the CFA keyword "with".
    529 #if ! defined( with ) §\C{// nesting ?}§
    530 #define with ®``®with §\C{// make keyword an identifier}§
     543#if ! defined( with )                                                   $\C{// nesting ?}$
     544#define with @``@with                                                   $\C{// make keyword an identifier}$
    531545#define __CFA_BFD_H__
    532546#endif
    533 §{\color{red}\#\textbf{include\_next} <bfdlink.h>}§ §\C{// must have internal check for multiple expansion}§
    534 #if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
     547$\R{\#include\_next} <bfdlink.h>$                               $\C{// must have internal check for multiple expansion}$
     548#if defined( with ) && defined( __CFA_BFD_H__ ) $\C{// reset only if set}$
    535549#undef with
    536550#undef __CFA_BFD_H__
     
    544558\section{Constant Underscores}
    545559
    546 Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
    547 \begin{cfa}
    548 2®_®147®_®483®_®648; §\C{// decimal constant}§
    549 56®_®ul; §\C{// decimal unsigned long constant}§
    550 0®_®377; §\C{// octal constant}§
    551 0x®_®ff®_®ff; §\C{// hexadecimal constant}§
    552 0x®_®ef3d®_®aa5c; §\C{// hexadecimal constant}§
    553 3.141®_®592®_®654; §\C{// floating constant}§
    554 10®_®e®_®+1®_®00; §\C{// floating constant}§
    555 0x®_®ff®_®ff®_®p®_®3; §\C{// hexadecimal floating}§
    556 0x®_®1.ffff®_®ffff®_®p®_®128®_®l; §\C{// hexadecimal floating long constant}§
    557 L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§; §\C{// wide character constant}§
     560Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore} as a separator, \eg:
     561\begin{cfa}
     5622@_@147@_@483@_@648; $\C{// decimal constant}$
     56356@_@ul; $\C{// decimal unsigned long constant}$
     5640@_@377; $\C{// octal constant}$
     5650x@_@ff@_@ff; $\C{// hexadecimal constant}$
     5660x@_@ef3d@_@aa5c; $\C{// hexadecimal constant}$
     5673.141@_@592@_@654; $\C{// floating constant}$
     56810@_@e@_@+1@_@00; $\C{// floating constant}$
     5690x@_@ff@_@ff@_@p@_@3; $\C{// hexadecimal floating}$
     5700x@_@1.ffff@_@ffff@_@p@_@128@_@l; $\C{// hexadecimal floating long constant}$
     571L@_@$"\texttt{\textbackslash{x}}$@_@$\texttt{ff}$@_@$\texttt{ee}"$; $\C{// wide character constant}$
    558572\end{cfa}
    559573The rules for placement of underscores are:
     
    574588It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
    575589This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
     590\CC uses the single quote (©'©) as a separator, restricted within a sequence of digits, \eg ©0xaa©©'©©ff©, ©3.141©©'©©592E1©©'©©1©.
    576591
    577592
    578593\section{Exponentiation Operator}
    579594
    580 C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow(x,y)}, to perform the exponentiation operation.
    581 \CFA extends the basic operators with the exponentiation operator ©?®\®?©\index{?\\?@©?®\®?©} and ©?\=?©\index{?\\=?@©®\®=?©}, as in, ©x ®\® y© and ©x ®\®= y©, which means $x^y$ and $x \leftarrow x^y$.
    582 The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©.
     595C, \CC, and Java (and other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow(x,y)}, to perform the exponentiation operation.
     596\CFA extends the basic operators with the exponentiation operator ©?©\R{©\\©}©?©\index{?\\?@©?@\@?©} and ©?©\R{©\\©}©=?©\index{?\\=?@©@\@=?©}, as in, ©x ©\R{©\\©}© y© and ©x ©\R{©\\©}©= y©, which means $x^y$ and $x \leftarrow x^y$.
     597The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©(w * (((int)x) \ ((int)y))) * z©.
    583598
    584599There are exponentiation operators for integral and floating types, including the builtin \Index{complex} types.
     
    587602Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the exponent cannot be negative.
    588603\begin{cfa}
    589 sout | 1 ®\® 0 | 1 ®\® 1 | 2 ®\® 8 | -4 ®\® 3 | 5 ®\® 3 | 5 ®\® 32 | 5L ®\® 32 | 5L ®\® 64 | -4 ®\® -3 | -4.0 ®\® -3 | 4.0 ®\® 2.1
    590            | (1.0f+2.0fi) ®\® (3.0f+2.0fi);
    591 1 1 256 -64 125 ®0® 3273344365508751233 ®0® ®0® -0.015625 18.3791736799526 0.264715-1.1922i
     604sout | 1 @\@ 0 | 1 @\@ 1 | 2 @\@ 8 | -4 @\@ 3 | 5 @\@ 3 | 5 @\@ 32 | 5L @\@ 32 | 5L @\@ 64 | -4 @\@ -3 | -4.0 @\@ -3 | 4.0 @\@ 2.1
     605           | (1.0f+2.0fi) @\@ (3.0f+2.0fi);
     6061 1 256 -64 125 @0@ 3273344365508751233 @0@ @0@ -0.015625 18.3791736799526 0.264715-1.1922i
    592607\end{cfa}
    593608Note, ©5 \ 32© and ©5L \ 64© overflow, and ©-4 \ -3© is a fraction but stored in an integer so all three computations generate an integral zero.
    594 Parenthesis are necessary for complex constants or the expression is parsed as ©1.0f+®(®2.0fi \ 3.0f®)®+2.0fi©.
     609Because exponentiation has higher priority than ©+©, parenthesis are necessary for exponentiation of \Index{complex constant}s or the expression is parsed as ©1.0f+©\R{©(©}©2.0fi \ 3.0f©\R{©)©}©+2.0fi©, requiring \R{©(©}©1.0f+2.0fi©\R{©)©}© \ ©\R{©(©}©3.0f+2.0fi©\R{©)©}.
     610
    595611The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation version is available.
    596612\begin{cfa}
    597 forall( otype OT | { void ?{}( OT & this, one_t ); OT ?*?( OT, OT ); } )
    598 OT ?®\®?( OT ep, unsigned int y );
    599 forall( otype OT | { void ?{}( OT & this, one_t ); OT ?*?( OT, OT ); } )
    600 OT ?®\®?( OT ep, unsigned long int y );
     613forall( otype T | { void ?{}( T & this, one_t ); T ?*?( T, T ); } )
     614T ?@\@?( T ep, unsigned int y );
     615forall( otype T | { void ?{}( T & this, one_t ); T ?*?( T, T ); } )
     616T ?@\@?( T ep, unsigned long int y );
    601617\end{cfa}
    602618The user type ©T© must define multiplication, one (©1©), and ©*©.
     
    609625
    610626%\subsection{\texorpdfstring{\protect\lstinline@if@/\protect\lstinline@while@ Statement}{if Statement}}
    611 \subsection{\texorpdfstring{\LstKeywordStyle{if}/\LstKeywordStyle{while} Statement}{if/while Statement}}
    612 
    613 The ©if©/©while© expression allows declarations, similar to ©for© declaration expression.
    614 (Does not make sense for ©do©-©while©.)
    615 \begin{cfa}
    616 if ( ®int x = f()® ) ... §\C{// x != 0}§
    617 if ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§
    618 if ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§
    619 if ( ®struct S { int i; } x = { f() }; x.i < 4® ) §\C{// relational expression}§
    620 
    621 while ( ®int x = f()® ) ... §\C{// x != 0}§
    622 while ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§
    623 while ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§
    624 while ( ®struct S { int i; } x = { f() }; x.i < 4® ) ... §\C{// relational expression}§
    625 \end{cfa}
    626 Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical ©&&© operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
    627 The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
     627\subsection{\texorpdfstring{\LstKeywordStyle{if} / \LstKeywordStyle{while} Statement}{if / while Statement}}
     628
     629The ©if©/©while© expression allows declarations, similar to ©for© declaration expression.\footnote{
     630Declarations in the ©do©-©while© condition are not useful because they appear after the loop body.}
     631\begin{cfa}
     632if ( @int x = f()@ ) ... $\C{// x != 0}$
     633if ( @int x = f(), y = g()@ ) ... $\C{// x != 0 \&\& y != 0}$
     634if ( @int x = f(), y = g(); x < y@ ) ... $\C{// relational expression}$
     635if ( @struct S { int i; } x = { f() }; x.i < 4@ ) $\C{// relational expression}$
     636
     637while ( @int x = f()@ ) ... $\C{// x != 0}$
     638while ( @int x = f(), y = g()@ ) ... $\C{// x != 0 \&\& y != 0}$
     639while ( @int x = f(), y = g(); x < y@ ) ... $\C{// relational expression}$
     640while ( @struct S { int i; } x = { f() }; x.i < 4@ ) ... $\C{// relational expression}$
     641\end{cfa}
     642Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical ©&&© operator.
     643The scope of the declaration(s) is local to the ©if© statement but exist within both the \emph{then} and \emph{else} clauses.
     644\CC only provides a single declaration always compared ©!=© to 0.
    628645
    629646
    630647%\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
    631648\subsection{\texorpdfstring{\LstKeywordStyle{case} Clause}{case Clause}}
     649\label{s:caseClause}
    632650
    633651C restricts the ©case© clause of a ©switch© statement to a single value.
     
    640658\begin{cfa}
    641659switch ( i ) {
    642   case ®1, 3, 5®:
     660  case @1, 3, 5@:
    643661        ...
    644   case ®2, 4, 6®:
     662  case @2, 4, 6@:
    645663        ...
    646664}
     
    670688\begin{cfa}
    671689switch ( i ) {
    672   case ®1~5:® §\C{// 1, 2, 3, 4, 5}§
     690  case @1~5:@ $\C{// 1, 2, 3, 4, 5}$
    673691        ...
    674   case ®10~15:® §\C{// 10, 11, 12, 13, 14, 15}§
     692  case @10~15:@ $\C{// 10, 11, 12, 13, 14, 15}$
    675693        ...
    676694}
     
    678696Lists of subranges are also allowed.
    679697\begin{cfa}
    680 case ®1~5, 12~21, 35~42®:
     698case @1~5, 12~21, 35~42@:
    681699\end{cfa}
    682700
     
    722740if ( argc == 3 ) {
    723741        // open output file
    724         ®// open input file
    725 ®} else if ( argc == 2 ) {
    726         ®// open input file (duplicate)
    727 
    728 ®} else {
     742        @// open input file
     743@} else if ( argc == 2 ) {
     744        @// open input file (duplicate)
     745
     746@} else {
    729747        // usage message
    730748}
     
    733751\end{cquote}
    734752In this example, case 2 is always done if case 3 is done.
    735 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
     753This 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.
    736754C also uses fall-through to handle multiple case-values resulting in the same action:
    737755\begin{cfa}
    738756switch ( i ) {
    739   ®case 1: case 3: case 5:®     // odd values
     757  @case 1: case 3: case 5:@     // odd values
    740758        // odd action
    741759        break;
    742   ®case 2: case 4: case 6:®     // even values
     760  @case 2: case 4: case 6:@     // even values
    743761        // even action
    744762        break;
    745763}
    746764\end{cfa}
    747 However, this situation is handled in other languages without fall-through by allowing a list of case values.
    748 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
     765This situation better handled without fall-through by allowing a list of case values \see{\VRef{s:caseClause}}.
     766While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from most programming languages with a ©switch© statement.
    749767Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
    750768
     
    756774        if ( j < k ) {
    757775                ...
    758           ®case 1:®             // transfer into "if" statement
     776          @case 1:@             // transfer into "if" statement
    759777                ...
    760778        } // if
     
    762780        while ( j < 5 ) {
    763781                ...
    764           ®case 3:®             // transfer into "while" statement
     782          @case 3:@             // transfer into "while" statement
    765783                ...
    766784        } // while
    767785} // switch
    768786\end{cfa}
    769 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
    770 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
     787This usage branches into control structures, which is known to cause both comprehension and technical difficulties.
     788The comprehension problem results from the inability to determine how control reaches a particular point due to the number of branches leading to it.
    771789The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
    772 There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
     790There are few arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
    773791Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
    774792\begin{cfa}
     
    794812\item
    795813It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
    796 Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
     814Most programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
    797815The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
    798816hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
     
    803821\begin{cfa}
    804822switch ( x ) {
    805         ®int y = 1;® §\C{// unreachable initialization}§
    806         ®x = 7;® §\C{// unreachable code without label/branch}§
     823        @int y = 1;@ $\C{// unreachable initialization}$
     824        @x = 7;@ $\C{// unreachable code without label/branch}$
    807825  case 0: ...
    808826        ...
    809         ®int z = 0;® §\C{// unreachable initialization, cannot appear after case}§
     827        @int z = 0;@ $\C{// unreachable initialization, cannot appear after case}$
    810828        z = 2;
    811829  case 1:
    812         ®x = z;® §\C{// without fall through, z is uninitialized}§
     830        @x = z;@ $\C{// without fall through, z is uninitialized}$
    813831}
    814832\end{cfa}
    815833While 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.
    816 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
    817 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
    818 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
     834Furthermore, 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©, where both are problematic.
     835As 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.
     836The key observation is that the ©switch© statement branches into a control structure, \ie there are multiple entry points into its statement body.
    819837\end{enumerate}
    820838
     
    842860Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
    843861\begin{cfa}
    844 ®choose® ( i ) {
     862@choose@ ( i ) {
    845863  case 1:  case 2:  case 3:
    846864        ...
    847         ®// implicit end of switch (break)
    848   ®case 5:
     865        @// implicit end of switch (break)
     866  @case 5:
    849867        ...
    850         ®fallthru®; §\C{// explicit fall through}§
     868        @fallthru@; $\C{// explicit fall through}$
    851869  case 7:
    852870        ...
    853         ®break® §\C{// explicit end of switch (redundant)}§
     871        @break@ $\C{// explicit end of switch (redundant)}$
    854872  default:
    855873        j = 3;
    856874}
    857875\end{cfa}
    858 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
     876Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses.
    859877An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
    860878An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
     
    872890\begin{cfa}
    873891switch ( x ) {
    874         ®int i = 0;® §\C{// allowed only at start}§
     892        @int i = 0;@ $\C{// allowed only at start}$
    875893  case 0:
    876894        ...
    877         ®int j = 0;® §\C{// disallowed}§
     895        @int j = 0;@ $\C{// disallowed}$
    878896  case 1:
    879897        {
    880                 ®int k = 0;® §\C{// allowed at different nesting levels}§
     898                @int k = 0;@ $\C{// allowed at different nesting levels}$
    881899                ...
    882           ®case 2:® §\C{// disallow case in nested statements}§
     900          @case 2:@ $\C{// disallow case in nested statements}$
    883901        }
    884902  ...
     
    897915  case 3:
    898916        if ( ... ) {
    899                 ... ®fallthru;® // goto case 4
     917                ... @fallthru;@ // goto case 4
    900918        } else {
    901919                ...
     
    912930choose ( ... ) {
    913931  case 3:
    914         ... ®fallthrough common;®
     932        ... @fallthrough common;@
    915933  case 4:
    916         ... ®fallthrough common;®
    917 
    918   ®common:® // below fallthrough
     934        ... @fallthrough common;@
     935
     936  @common:@ // below fallthrough
    919937                          // at case-clause level
    920938        ...     // common code for cases 3/4
     
    932950                for ( ... ) {
    933951                        // multi-level transfer
    934                         ... ®fallthru common;®
     952                        ... @fallthru common;@
    935953                }
    936954                ...
    937955        }
    938956        ...
    939   ®common:® // below fallthrough
     957  @common:@ // below fallthrough
    940958                          // at case-clause level
    941959\end{cfa}
     
    948966
    949967\begin{figure}
    950 \begin{tabular}{@{}l|l@{}}
    951 \multicolumn{1}{c|}{loop control} & \multicolumn{1}{c}{output} \\
     968\begin{tabular}{@{}l@{\hspace{25pt}}|l@{}}
     969\multicolumn{1}{@{}c@{\hspace{25pt}}|}{loop control} & \multicolumn{1}{c@{}}{output} \\
    952970\hline
    953 \begin{cfa}[xleftmargin=0pt]
    954 while ®()® { sout | "empty"; break; }
    955 do { sout | "empty"; break; } while ®()®;
    956 for ®()® { sout | "empty"; break; }
    957 for ( ®0® ) { sout | "A"; } sout | "zero";
    958 for ( ®1® ) { sout | "A"; }
    959 for ( ®10® ) { sout | "A"; }
    960 for ( ®= 10® ) { sout | "A"; }
    961 for ( ®1 ~= 10 ~ 2® ) { sout | "B"; }
    962 for ( ®10 -~= 1 ~ 2® ) { sout | "C"; }
    963 for ( ®0.5 ~ 5.5® ) { sout | "D"; }
    964 for ( ®5.5 -~ 0.5® ) { sout | "E"; }
    965 for ( ®i; 10® ) { sout | i; }
    966 for ( ®i; = 10® ) { sout | i; }
    967 for ( ®i; 1 ~= 10 ~ 2® ) { sout | i; }
    968 for ( ®i; 10 -~= 1 ~ 2® ) { sout | i; }
    969 for ( ®i; 0.5 ~ 5.5® ) { sout | i; }
    970 for ( ®i; 5.5 -~ 0.5® ) { sout | i; }
    971 for ( ®ui; 2u ~= 10u ~ 2u® ) { sout | ui; }
    972 for ( ®ui; 10u -~= 2u ~ 2u® ) { sout | ui; }
     971\begin{cfa}
     972while @($\,$)@ { sout | "empty"; break; }
     973do { sout | "empty"; break; } while @($\,$)@;
     974for @($\,$)@ { sout | "empty"; break; }
     975for ( @0@ ) { sout | "A"; } sout | "zero";
     976for ( @1@ ) { sout | "A"; }
     977for ( @10@ ) { sout | "A"; }
     978for ( @= 10@ ) { sout | "A"; }
     979for ( @1 ~= 10 ~ 2@ ) { sout | "B"; }
     980for ( @10 -~= 1 ~ 2@ ) { sout | "C"; }
     981for ( @0.5 ~ 5.5@ ) { sout | "D"; }
     982for ( @5.5 -~ 0.5@ ) { sout | "E"; }
     983for ( @i; 10@ ) { sout | i; }
     984for ( @i; = 10@ ) { sout | i; }
     985for ( @i; 1 ~= 10 ~ 2@ ) { sout | i; }
     986for ( @i; 10 -~= 1 ~ 2@ ) { sout | i; }
     987for ( @i; 0.5 ~ 5.5@ ) { sout | i; }
     988for ( @i; 5.5 -~ 0.5@ ) { sout | i; }
     989for ( @ui; 2u ~= 10u ~ 2u@ ) { sout | ui; }
     990for ( @ui; 10u -~= 2u ~ 2u@ ) { sout | ui; }
    973991enum { N = 10 };
    974 for ( ®N® ) { sout | "N"; }
    975 for ( ®i; N® ) { sout | i; }
    976 for ( ®i; N -~ 0® ) { sout | i; }
     992for ( @N@ ) { sout | "N"; }
     993for ( @i; N@ ) { sout | i; }
     994for ( @i; N -~ 0@ ) { sout | i; }
    977995const int start = 3, comp = 10, inc = 2;
    978 for ( ®i; start ~ comp ~ inc + 1® ) { sout | i; }
    979 for ( i; 1 ~ ®@® ) { if ( i > 10 ) break; sout | i; }
    980 for ( i; 10 -~ ®@® ) { if ( i < 0 ) break; sout | i; }
    981 for ( i; 2 ~ ®@® ~ 2 ) { if ( i > 10 ) break; sout | i; }
    982 for ( i; 2.1 ~ ®@® ~ ®@® ) { if ( i > 10.5 ) break; sout | i; i += 1.7; }
    983 for ( i; 10 -~ ®@® ~ 2 ) { if ( i < 0 ) break; sout | i; }
    984 for ( i; 12.1 ~ ®@® ~ ®@® ) { if ( i < 2.5 ) break; sout | i; i -= 1.7; }
    985 for ( i; 5 ®:® j; -5 ~ @ ) { sout | i | j; }
    986 for ( i; 5 ®:® j; -5 -~ @ ) { sout | i | j; }
    987 for ( i; 5 ®:® j; -5 ~ @ ~ 2 ) { sout | i | j; }
    988 for ( i; 5 ®:® j; -5 -~ @ ~ 2 ) { sout | i | j; }
    989 for ( i; 5 ®:® j; -5 ~ @ ) { sout | i | j; }
    990 for ( i; 5 ®:® j; -5 -~ @ ) { sout | i | j; }
    991 for ( i; 5 ®:® j; -5 ~ @ ~ 2 ) { sout | i | j; }
    992 for ( i; 5 ®:® j; -5 -~ @ ~ 2 ) { sout | i | j; }
    993 for ( i; 5 ®:® j; -5 -~ @ ~ 2 ®:® k; 1.5 ~ @ ) { sout | i | j | k; }
    994 for ( i; 5 ®:® j; -5 -~ @ ~ 2 ®:® k; 1.5 ~ @ ) { sout | i | j | k; }
    995 for ( i; 5 ®:® k; 1.5 ~ @ ®:® j; -5 -~ @ ~ 2 ) { sout | i | j | k; }
     996for ( @i; start ~ comp ~ inc + 1@ ) { sout | i; }
     997for ( i; 1 ~ $\R{@}$ ) { if ( i > 10 ) break; sout | i; }
     998for ( i; 10 -~ $\R{@}$ ) { if ( i < 0 ) break; sout | i; }
     999for ( i; 2 ~ $\R{@}$ ~ 2 ) { if ( i > 10 ) break; sout | i; }
     1000for ( i; 2.1 ~ $\R{@}$ ~ $\R{@}$ ) { if ( i > 10.5 ) break; sout | i; i += 1.7; }
     1001for ( i; 10 -~ $\R{@}$ ~ 2 ) { if ( i < 0 ) break; sout | i; }
     1002for ( i; 12.1 ~ $\R{@}$ ~ $\R{@}$ ) { if ( i < 2.5 ) break; sout | i; i -= 1.7; }
     1003for ( i; 5 @:@ j; -5 ~ $@$ ) { sout | i | j; }
     1004for ( i; 5 @:@ j; -5 -~ $@$ ) { sout | i | j; }
     1005for ( i; 5 @:@ j; -5 ~ $@$ ~ 2 ) { sout | i | j; }
     1006for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j; }
     1007for ( i; 5 @:@ j; -5 ~ $@$ ) { sout | i | j; }
     1008for ( i; 5 @:@ j; -5 -~ $@$ ) { sout | i | j; }
     1009for ( i; 5 @:@ j; -5 ~ $@$ ~ 2 ) { sout | i | j; }
     1010for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j; }
     1011for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 @:@ k; 1.5 ~ $@$ ) { sout | i | j | k; }
     1012for ( i; 5 @:@ j; -5 -~ $@$ ~ 2 @:@ k; 1.5 ~ $@$ ) { sout | i | j | k; }
     1013for ( i; 5 @:@ k; 1.5 ~ $@$ @:@ j; -5 -~ $@$ ~ 2 ) { sout | i | j | k; }
    9961014\end{cfa}
    9971015&
     
    10561074\subsection{Loop Control}
    10571075
    1058 The ©for©/©while©/©do-while© loop-control allows empty or simplified ranges (see Figure~\ref{f:LoopControlExamples}).
    1059 \begin{itemize}
     1076Looping a fixed number of times, possibly with a loop index, occurs frequently.
     1077\CFA condenses simply looping to facilitate coding speed and safety.
     1078The ©for©/©while©/©do-while© loop-control is augmented as follows \see{examples in \VRef[Figure]{f:LoopControlExamples}}:
     1079\begin{itemize}[itemsep=0pt]
     1080\item
     1081©0© is the implicit start value;
     1082\item
     1083©1© is the implicit increment value.
     1084\item
     1085The up-to range uses operator ©+=© for increment;
     1086\item
     1087The down-to range uses operator ©-=© for decrement.
    10601088\item
    10611089The loop index is polymorphic in the type of the comparison value N (when the start value is implicit) or the start value M.
     1090\begin{cfa}
     1091for ( i; @5@ )                                  $\C[2.5in]{// typeof(5) i; 5 is comparison value}$
     1092for ( i; @1.5@~5.5~0.5 )                $\C{// typeof(1.5) i; 1.5 is start value}$
     1093\end{cfa}
    10621094\item
    10631095An empty conditional implies comparison value of ©1© (true).
    1064 \item
    1065 A comparison N is implicit up-to exclusive range [0,N©®)®©.
    1066 \item
    1067 A comparison ©=© N is implicit up-to inclusive range [0,N©®]®©.
    1068 \item
    1069 The up-to range M ©~©\index{~@©~©} N means exclusive range [M,N©®)®©.
    1070 \item
    1071 The up-to range M ©~=©\index{~=@©~=©} N means inclusive range [M,N©®]®©.
    1072 \item
    1073 The down-to range M ©-~©\index{-~@©-~©} N means exclusive range [N,M©®)®©.
    1074 \item
    1075 The down-to range M ©-~=©\index{-~=@©-~=©} N means inclusive range [N,M©®]®©.
    1076 \item
    1077 ©0© is the implicit start value;
    1078 \item
    1079 ©1© is the implicit increment value.
    1080 \item
    1081 The up-to range uses operator ©+=© for increment;
    1082 \item
    1083 The down-to range uses operator ©-=© for decrement.
     1096\begin{cfa}
     1097while ( $\R{/*empty*/}$ )               $\C{// while ( true )}$
     1098for ( $\R{/*empty*/}$ )                 $\C{// for ( ; true; )}$
     1099do ... while ( $\R{/*empty*/}$ ) $\C{// do ... while ( true )}$
     1100\end{cfa}
     1101\item
     1102A comparison N is implicit up-to exclusive range [0,N\R{)}.
     1103\begin{cfa}
     1104for ( @5@ )                                             $\C{// for ( typeof(5) i; i < 5; i += 1 )}$
     1105\end{cfa}
     1106\item
     1107A comparison ©=© N is implicit up-to inclusive range [0,N\R{]}.
     1108\begin{cfa}
     1109for ( @=@5 )                                    $\C{// for ( typeof(5) i; i <= 5; i += 1 )}$
     1110\end{cfa}
     1111\item
     1112The up-to range M ©~©\index{~@©~©} N means exclusive range [M,N\R{)}.
     1113\begin{cfa}
     1114for ( 1@~@5 )                                   $\C{// for ( typeof(1) i = 1; i < 5; i += 1 )}$
     1115\end{cfa}
     1116\item
     1117The up-to range M ©~=©\index{~=@©~=©} N means inclusive range [M,N\R{]}.
     1118\begin{cfa}
     1119for ( 1@~=@5 )                                  $\C{// for ( typeof(1) i = 1; i <= 5; i += 1 )}$
     1120\end{cfa}
     1121\item
     1122The down-to range M ©-~©\index{-~@©-~©} N means exclusive range [N,M\R{)}.
     1123\begin{cfa}
     1124for ( 1@-~@5 )                                  $\C{// for ( typeof(1) i = 5; i > 0; i -= 1 )}$
     1125\end{cfa}
     1126\item
     1127The down-to range M ©-~=©\index{-~=@©-~=©} N means inclusive range [N,M\R{]}.
     1128\begin{cfa}
     1129for ( 1@-~=@5 )                                 $\C{// for ( typeof(1) i = 5; i >= 0; i -= 1 )}$
     1130\end{cfa}
    10841131\item
    10851132©@© means put nothing in this field.
     1133\begin{cfa}
     1134for ( 1~$\R{@}$~2 )                             $\C{// for ( typeof(1) i = 1; /*empty*/; i += 2 )}$
     1135\end{cfa}
    10861136\item
    10871137©:© means start another index.
     1138\begin{cfa}
     1139for ( i; 5 @:@ j; 2~12~3 )              $\C{// for ( typeof(i) i = 1, j = 2; i < 5 \&\& j < 12; i += 1, j += 3 )}\CRT$
     1140\end{cfa}
    10881141\end{itemize}
    10891142
     
    10921145\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
    10931146
    1094 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
    1095 Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
     1147C ©continue© and ©break© statements, for altering control flow, are restricted to one level of nesting for a particular control structure.
     1148This restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting.
    10961149To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85}, as in Java.
    10971150For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement;
    10981151for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement.
    1099 \VRef[Figure]{f:MultiLevelExit} shows ©continue© and ©break© indicating the specific control structure, and the corresponding C program using only ©goto© and labels.
     1152\VRef[Figure]{f:MultiLevelExit} shows a comparison between labelled ©continue© and ©break© and the corresponding C equivalent using ©goto© and labels.
    11001153The innermost loop has 8 exit points, which cause continuation or termination of one or more of the 7 \Index{nested control-structure}s.
    11011154
     
    11041157\begin{lrbox}{\myboxA}
    11051158\begin{cfa}[tabsize=3]
    1106 ®Compound:® {
    1107         ®Try:® try {
    1108                 ®For:® for ( ... ) {
    1109                         ®While:® while ( ... ) {
    1110                                 ®Do:® do {
    1111                                         ®If:® if ( ... ) {
    1112                                                 ®Switch:® switch ( ... ) {
     1159@Compound:@ {
     1160        @Try:@ try {
     1161                @For:@ for ( ... ) {
     1162                        @While:@ while ( ... ) {
     1163                                @Do:@ do {
     1164                                        @If:@ if ( ... ) {
     1165                                                @Switch:@ switch ( ... ) {
    11131166                                                        case 3:
    1114                                                                 ®break Compound®;
    1115                                                                 ®break Try®;
    1116                                                                 ®break For®;      /* or */  ®continue For®;
    1117                                                                 ®break While®;  /* or */  ®continue While®;
    1118                                                                 ®break Do®;      /* or */  ®continue Do®;
    1119                                                                 ®break If®;
    1120                                                                 ®break Switch®;
     1167                                                                @break Compound@;
     1168                                                                @break Try@;
     1169                                                                @break For@;      /* or */  @continue For@;
     1170                                                                @break While@;  /* or */  @continue While@;
     1171                                                                @break Do@;      /* or */  @continue Do@;
     1172                                                                @break If@;
     1173                                                                @break Switch@;
    11211174                                                        } // switch
    11221175                                                } else {
    1123                                                         ... ®break If®; ...     // terminate if
     1176                                                        ... @break If@; ...     // terminate if
    11241177                                                } // if
    11251178                                } while ( ... ); // do
    11261179                        } // while
    11271180                } // for
    1128         } ®finally® { // always executed
     1181        } @finally@ { // always executed
    11291182        } // try
    11301183} // compound
     
    11361189{
    11371190
    1138                 ®ForC:® for ( ... ) {
    1139                         ®WhileC:® while ( ... ) {
    1140                                 ®DoC:® do {
     1191                @ForC:@ for ( ... ) {
     1192                        @WhileC:@ while ( ... ) {
     1193                                @DoC:@ do {
    11411194                                        if ( ... ) {
    11421195                                                switch ( ... ) {
    11431196                                                        case 3:
    1144                                                                 ®goto Compound®;
    1145                                                                 ®goto Try®;
    1146                                                                 ®goto ForB®;      /* or */  ®goto ForC®;
    1147                                                                 ®goto WhileB®;  /* or */  ®goto WhileC®;
    1148                                                                 ®goto DoB®;      /* or */  ®goto DoC®;
    1149                                                                 ®goto If®;
    1150                                                                 ®goto Switch®;
    1151                                                         } ®Switch:® ;
     1197                                                                @goto Compound@;
     1198                                                                @goto Try@;
     1199                                                                @goto ForB@;      /* or */  @goto ForC@;
     1200                                                                @goto WhileB@;  /* or */  @goto WhileC@;
     1201                                                                @goto DoB@;      /* or */  @goto DoC@;
     1202                                                                @goto If@;
     1203                                                                @goto Switch@;
     1204                                                        } @Switch:@ ;
    11521205                                                } else {
    1153                                                         ... ®goto If®; ...      // terminate if
    1154                                                 } ®If:®;
    1155                                 } while ( ... ); ®DoB:® ;
    1156                         } ®WhileB:® ;
    1157                 } ®ForB:® ;
    1158 
    1159 
    1160 } ®Compound:® ;
     1206                                                        ... @goto If@; ...      // terminate if
     1207                                                } @If:@;
     1208                                } while ( ... ); @DoB:@ ;
     1209                        } @WhileB:@ ;
     1210                } @ForB:@ ;
     1211
     1212
     1213} @Compound:@ ;
    11611214\end{cfa}
    11621215\end{lrbox}
    11631216
    11641217\subfloat[\CFA]{\label{f:CFibonacci}\usebox\myboxA}
    1165 \hspace{2pt}
     1218\hspace{3pt}
    11661219\vrule
    1167 \hspace{2pt}
     1220\hspace{3pt}
    11681221\subfloat[C]{\label{f:CFAFibonacciGen}\usebox\myboxB}
    11691222\caption{Multi-level Exit}
     
    11801233This restriction prevents missing declarations and/or initializations at the start of a control structure resulting in undefined behaviour.
    11811234\end{itemize}
    1182 The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program.
     1235The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program via a label.
    11831236Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader (\Index{eye candy}) that complex control-flow is occurring in the body of the control structure.
    11841237With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
     
    11871240
    11881241
    1189 %\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
    1190 \section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
     1242%\subsection{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
     1243\subsection{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
    11911244\label{s:WithStatement}
    11921245
    1193 Grouping heterogeneous data into \newterm{aggregate}s (structure/union) is a common programming practice, and an aggregate can be further organized into more complex structures, such as arrays and containers:
    1194 \begin{cfa}
    1195 struct S { §\C{// aggregate}§
    1196         char c; §\C{// fields}§
    1197         int i;
    1198         double d;
     1246Grouping heterogeneous data into an \newterm{aggregate} (structure/union) is a common programming practice, and aggregates may be nested:
     1247\begin{cfa}
     1248struct Person {                                                         $\C{// aggregate}$
     1249        struct Name { char first[20], last[20]; } name $\C{// nesting}$
     1250        struct Address { ... } address                  $\C{// nesting}$
     1251        int sex;
    11991252};
    1200 S s, as[10];
    1201 \end{cfa}
    1202 However, functions manipulating aggregates must repeat the aggregate name to access its containing fields:
    1203 \begin{cfa}
    1204 void f( S s ) {
    1205         ®s.®c; ®s.®i; ®s.®d; §\C{// access containing fields}§
    1206 }
    1207 \end{cfa}
    1208 which extends to multiple levels of qualification for nested aggregates.
    1209 A similar situation occurs in object-oriented programming, \eg \CC:
     1253\end{cfa}
     1254Functions manipulating aggregates must repeat the aggregate name to access its containing fields.
     1255\begin{cfa}
     1256Person p
     1257@p.@name; @p.@address; @p.@sex; $\C{// access containing fields}$
     1258\end{cfa}
     1259which extends to multiple levels of qualification for nested aggregates and multiple aggregates.
     1260\begin{cfa}
     1261struct Ticket { ... } t;
     1262@p.name@.first; @p.address@.street;             $\C{// access nested fields}$
     1263@t.@departure; @t.@cost;                                $\C{// access multiple aggregate}$
     1264\end{cfa}
     1265Repeated aggregate qualification is tedious and makes code difficult to read.
     1266Therefore, reducing aggregate qualification is a useful language design goal.
     1267
     1268C allows unnamed nested aggregates that open their scope into the containing aggregate.
     1269This feature is used to group fields for attributes and/or with ©union© aggregates.
     1270\begin{cfa}
     1271struct S {
     1272        struct { int g,  h; } __attribute__(( aligned(64) ));
     1273        int tag;
     1274        union {
     1275                struct { char c1,  c2; } __attribute__(( aligned(128) ));
     1276                struct { int i1,  i2; };
     1277                struct { double d1,  d2; };
     1278        };
     1279};
     1280s.g; s.h; s.tag; s.c1; s.c2; s.i1; s.i2; s.d1; s.d2;
     1281\end{cfa}
     1282
     1283Object-oriented languages reduce qualification for class variables within member functions, \eg \CC:
    12101284\begin{C++}
    12111285struct S {
    1212         char c; §\C{// fields}§
    1213         int i;
    1214         double d;
    1215         void f() { §\C{// implicit ``this'' aggregate}§
    1216                 ®this->®c; ®this->®i; ®this->®d; §\C{// access containing fields}§
     1286        char @c@;   int @i@;   double @d@;
     1287        void f( /* S * this */ ) {                              $\C{// implicit ``this'' parameter}$
     1288                @c@;   @i@;   @d@;                                      $\C{// this->c; this->i; this->d;}$
    12171289        }
    12181290}
    12191291\end{C++}
    1220 Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
    1221 However, for other aggregate parameters, qualification is necessary:
    1222 \begin{cfa}
    1223 struct T { double m, n; };
    1224 int S::f( T & t ) { §\C{// multiple aggregate parameters}§
    1225         c; i; d; §\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}§
    1226         ®t.®m; ®t.®n; §\C{// must qualify}§
    1227 }
    1228 \end{cfa}
    1229 
    1230 To simplify the programmer experience, \CFA provides a ©with© statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
    1231 Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
    1232 \begin{cfa}
    1233 void f( S & this ) ®with ( this )® { §\C{// with statement}§
    1234         c; i; d; §\C{\color{red}// this.c, this.i, this.d}§
     1292In general, qualification is elided for the variables and functions in the lexical scopes visible from a member function.
     1293However, qualification is necessary for name shadowing and explicit aggregate parameters.
     1294\begin{cfa}
     1295struct T {
     1296        char @m@;   int @i@;   double @n@;              $\C{// derived class variables}$
     1297};
     1298struct S : public T {
     1299        char @c@;   int @i@;   double @d@;              $\C{// class variables}$
     1300        void g( double @d@, T & t ) {
     1301                d;   @t@.m;   @t@.i;   @t@.n;           $\C{// function parameter}$
     1302                c;   i;   @this->@d;   @S::@d;          $\C{// class S variables}$
     1303                m;   @T::@i;   n;                                       $\C{// class T variables}$
     1304        }
     1305};
     1306\end{cfa}
     1307Note the three different forms of qualification syntax in \CC, ©.©, ©->©, ©::©, which is confusing.
     1308
     1309Since \CFA in not object-oriented, it has no implicit parameter with its implicit qualification.
     1310Instead \CFA introduces a general mechanism using the ©with© statement \see{Pascal~\cite[\S~4.F]{Pascal}} to explicitly elide aggregate qualification by opening a scope containing the field identifiers.
     1311Hence, the qualified fields become variables with the side-effect that it is simpler to write, easier to read, and optimize field references in a block.
     1312\begin{cfa}
     1313void f( S & this ) @with ( this )@ {            $\C{// with statement}$
     1314        @c@;   @i@;   @d@;                                              $\C{// this.c, this.i, this.d}$
    12351315}
    12361316\end{cfa}
    12371317with the generality of opening multiple aggregate-parameters:
    12381318\begin{cfa}
    1239 void f( S & s, T & t ) ®with ( s, t )® { §\C{// multiple aggregate parameters}§
    1240         c; i; d; §\C{\color{red}// s.c, s.i, s.d}§
    1241         m; n; §\C{\color{red}// t.m, t.n}§
    1242 }
    1243 \end{cfa}
    1244 
    1245 In detail, the ©with© statement has the form:
    1246 \begin{cfa}
    1247 §\emph{with-statement}§:
    1248         'with' '(' §\emph{expression-list}§ ')' §\emph{compound-statement}§
    1249 \end{cfa}
    1250 and may appear as the body of a function or nested within a function body.
    1251 Each expression in the expression-list provides a type and object.
    1252 The type must be an aggregate type.
     1319void g( S & s, T & t ) @with ( s, t )@ {        $\C{// multiple aggregate parameters}$
     1320        c;   @s.@i;   d;                                                $\C{// s.c, s.i, s.d}$
     1321        m;   @t.@i;   n;                                                $\C{// t.m, t.i, t.n}$
     1322}
     1323\end{cfa}
     1324where qualification is only necessary to disambiguate the shadowed variable ©i©.
     1325
     1326In detail, the ©with© statement may appear as the body of a function or nested within a function body.
     1327The ©with© clause takes a list of expressions, where each expression provides an aggregate type and object.
    12531328(Enumerations are already opened.)
    1254 The object is the implicit qualifier for the open structure-fields.
    1255 
     1329To open a pointer type, the pointer must be dereferenced to obtain a reference to the aggregate type.
     1330\begin{cfa}
     1331S * sp;
     1332with ( *sp ) { ... }
     1333\end{cfa}
     1334The expression object is the implicit qualifier for the open structure-fields.
     1335\CFA's ability to overload variables \see{\VRef{s:VariableOverload}} and use the left-side of assignment in type resolution means most fields with the same name but different types are automatically disambiguated, eliminating qualification.
    12561336All expressions in the expression list are open in parallel within the compound statement.
    12571337This semantic is different from Pascal, which nests the openings from left to right.
    12581338The difference between parallel and nesting occurs for fields with the same name and type:
    12591339\begin{cfa}
    1260 struct S { int ®i®; int j; double m; } s, w;
    1261 struct T { int ®i®; int k; int m; } t, w;
    1262 with ( s, t ) {
    1263         j + k; §\C{// unambiguous, s.j + t.k}§
    1264         m = 5.0; §\C{// unambiguous, t.m = 5.0}§
    1265         m = 1; §\C{// unambiguous, s.m = 1}§
    1266         int a = m; §\C{// unambiguous, a = s.i }§
    1267         double b = m; §\C{// unambiguous, b = t.m}§
    1268         int c = s.i + t.i; §\C{// unambiguous, qualification}§
    1269         (double)m; §\C{// unambiguous, cast}§
    1270 }
    1271 \end{cfa}
    1272 For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
    1273 for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
    1274 \CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
    1275 Qualification or a cast is used to disambiguate.
    1276 
    1277 There is an interesting problem between parameters and the function-body ©with©, \eg:
    1278 \begin{cfa}
    1279 void ?{}( S & s, int i ) with ( s ) { §\C{// constructor}§
    1280         ®s.i = i;®  j = 3;  m = 5.5; §\C{// initialize fields}§
     1340struct Q { int @i@; int k; int @m@; } q, w;
     1341struct R { int @i@; int j; double @m@; } r, w;
     1342with ( r, q ) {
     1343        j + k;                                                                  $\C{// unambiguous, r.j + q.k}$
     1344        m = 5.0;                                                                $\C{// unambiguous, q.m = 5.0}$
     1345        m = 1;                                                                  $\C{// unambiguous, r.m = 1}$
     1346        int a = m;                                                              $\C{// unambiguous, a = r.i }$
     1347        double b = m;                                                   $\C{// unambiguous, b = q.m}$
     1348        int c = r.i + q.i;                                              $\C{// disambiguate with qualification}$
     1349        (double)m;                                                              $\C{// disambiguate with cast}$
     1350}
     1351\end{cfa}
     1352For parallel semantics, both ©r.i© and ©q.i© are visible, so ©i© is ambiguous without qualification;
     1353for nested semantics, ©q.i© hides ©r.i©, so ©i© implies ©q.i©.
     1354Pascal nested-semantics is possible by nesting ©with© statements.
     1355\begin{cfa}
     1356with ( r ) {
     1357        i;                                                                              $\C{// unambiguous, r.i}$
     1358        with ( q ) {
     1359                i;                                                                      $\C{// unambiguous, q.i}$
     1360        }
     1361}
     1362\end{cfa}
     1363A cast or qualification can be used to disambiguate variables within a ©with© \emph{statement}.
     1364A cast can be used to disambiguate among overload variables in a ©with© \emph{expression}:
     1365\begin{cfa}
     1366with ( w ) { ... }                                                      $\C{// ambiguous, same name and no context}$
     1367with ( (Q)w ) { ... }                                           $\C{// unambiguous, cast}$
     1368\end{cfa}
     1369Because there is no left-side in the ©with© expression to implicitly disambiguate between the ©w© variables, it is necessary to explicitly disambiguate by casting ©w© to type ©Q© or ©R©.
     1370
     1371Finally, there is an interesting problem between parameters and the function-body ©with©, \eg:
     1372\begin{cfa}
     1373void ?{}( S & s, int i ) with ( s ) { $\C{// constructor}$
     1374        @s.i = i;@  j = 3;  m = 5.5; $\C{// initialize fields}$
    12811375}
    12821376\end{cfa}
     
    12911385and implicitly opened \emph{after} a function-body open, to give them higher priority:
    12921386\begin{cfa}
    1293 void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
    1294         s.i = ®i®; j = 3; m = 5.5;
    1295 }
    1296 \end{cfa}
    1297 Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
    1298 \begin{cfa}
    1299 with ( w ) { ... } §\C{// ambiguous, same name and no context}§
    1300 with ( (S)w ) { ... } §\C{// unambiguous, cast}§
    1301 \end{cfa}
    1302 and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
    1303 % \begin{cfa}
    1304 % struct S { int i, j; } sv;
    1305 % with ( sv ) { §\C{// implicit reference}§
    1306 %       S & sr = sv;
    1307 %       with ( sr ) { §\C{// explicit reference}§
    1308 %               S * sp = &sv;
    1309 %               with ( *sp ) { §\C{// computed reference}§
    1310 %                       i = 3; j = 4; §\C{\color{red}// sp--{\textgreater}i, sp--{\textgreater}j}§
    1311 %               }
    1312 %               i = 2; j = 3; §\C{\color{red}// sr.i, sr.j}§
    1313 %       }
    1314 %       i = 1; j = 2; §\C{\color{red}// sv.i, sv.j}§
    1315 % }
    1316 % \end{cfa}
    1317 
    1318 In \Index{object-oriented} programming, there is an implicit first parameter, often names \textbf{©self©} or \textbf{©this©}, which is elided.
    1319 \begin{C++}
    1320 class C {
    1321         int i, j;
    1322         int mem() { §\C{\color{red}// implicit "this" parameter}§
    1323                 i = 1; §\C{\color{red}// this->i}§
    1324                 j = 2; §\C{\color{red}// this->j}§
    1325         }
    1326 }
    1327 \end{C++}
    1328 Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:
    1329 \begin{cfa}
    1330 struct S { int i, j; };
    1331 int mem( S & ®this® ) { §\C{// explicit "this" parameter}§
    1332         ®this.®i = 1; §\C{// "this" is not elided}§
    1333         ®this.®j = 2;
    1334 }
    1335 \end{cfa}
    1336 but it is cumbersome having to write ``©this.©'' many times in a member.
    1337 
    1338 \CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
    1339 \begin{cfa}
    1340 int mem( S & this ) ®with( this )® { §\C{// with clause}§
    1341         i = 1; §\C{\color{red}// this.i}§
    1342         j = 2; §\C{\color{red}// this.j}§
    1343 }
    1344 \end{cfa}
    1345 which extends to multiple routine parameters:
    1346 \begin{cfa}
    1347 struct T { double m, n; };
    1348 int mem2( S & this1, T & this2 ) ®with( this1, this2 )® {
    1349         i = 1; j = 2;
    1350         m = 1.0; n = 2.0;
    1351 }
    1352 \end{cfa}
    1353 
    1354 The statement form is used within a block:
    1355 \begin{cfa}
    1356 int foo() {
    1357         struct S1 { ... } s1;
    1358         struct S2 { ... } s2;
    1359         ®with( s1 )® { §\C{// with statement}§
    1360                 // access fields of s1 without qualification
    1361                 ®with s2® { §\C{// nesting}§
    1362                         // access fields of s1 and s2 without qualification
    1363                 }
    1364         }
    1365         ®with s1, s2® {
    1366                 // access unambiguous fields of s1 and s2 without qualification
    1367         }
    1368 }
    1369 \end{cfa}
    1370 
    1371 When opening multiple structures, fields with the same name and type are ambiguous and must be fully qualified.
    1372 For fields with the same name but different type, context/cast can be used to disambiguate.
    1373 \begin{cfa}
    1374 struct S { int i; int j; double m; } a, c;
    1375 struct T { int i; int k; int m } b, c;
    1376 with( a, b )
    1377 {
    1378 }
    1379 \end{cfa}
    1380 
    1381 \begin{comment}
    1382 The components in the "with" clause
    1383 
    1384   with a, b, c { ... }
    1385 
    1386 serve 2 purposes: each component provides a type and object. The type must be a
    1387 structure type. Enumerations are already opened, and I think a union is opened
    1388 to some extent, too. (Or is that just unnamed unions?) The object is the target
    1389 that the naked structure-fields apply to. The components are open in "parallel"
    1390 at the scope of the "with" clause/statement, so opening "a" does not affect
    1391 opening "b", etc. This semantic is different from Pascal, which nests the
    1392 openings.
    1393 
    1394 Having said the above, it seems reasonable to allow a "with" component to be an
    1395 expression. The type is the static expression-type and the object is the result
    1396 of the expression. Again, the type must be an aggregate. Expressions require
    1397 parenthesis around the components.
    1398 
    1399   with( a, b, c ) { ... }
    1400 
    1401 Does this now make sense?
    1402 
    1403 Having written more CFA code, it is becoming clear to me that I *really* want
    1404 the "with" to be implemented because I hate having to type all those object
    1405 names for fields. It's a great way to drive people away from the language.
    1406 \end{comment}
     1387void ?{}( S & s, int @i@ ) with ( s ) @with( $\emph{\R{params}}$ )@ { // syntax not allowed, illustration only
     1388        s.i = @i@; j = 3; m = 5.5;
     1389}
     1390\end{cfa}
     1391This implicit semantic matches with programmer expectation.
     1392
    14071393
    14081394
     
    14141400Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
    14151401\begin{cfa}
    1416 exception_t E {}; §\C{// exception type}§
     1402exception_t E {}; $\C{// exception type}$
    14171403void f(...) {
    1418         ... throw E{}; ... §\C{// termination}§
    1419         ... throwResume E{}; ... §\C{// resumption}§
     1404        ... throw E{}; ... $\C{// termination}$
     1405        ... throwResume E{}; ... $\C{// resumption}$
    14201406}
    14211407try {
    14221408        f(...);
    1423 } catch( E e ; §boolean-predicate§ ) {          §\C{// termination handler}§
     1409} catch( E e ; $boolean-predicate$ ) {          $\C{// termination handler}$
    14241410        // recover and continue
    1425 } catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}§
     1411} catchResume( E e ; $boolean-predicate$ ) { $\C{// resumption handler}$
    14261412        // repair and return
    14271413} finally {
     
    14301416\end{cfa}
    14311417The kind of raise and handler match: ©throw© with ©catch© and ©throwResume© with ©catchResume©.
    1432 Then the exception type must match along with any additonal predicate must be true.
     1418Then the exception type must match along with any additional predicate must be true.
    14331419The ©catch© and ©catchResume© handlers may appear in any oder.
    14341420However, the ©finally© clause must appear at the end of the ©try© statement.
     
    14831469For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    14841470\begin{cfa}
    1485 int ®(*®f®())[®5®]® {...}; §\C{// definition}§
    1486  ... ®(*®f®())[®3®]® += 1; §\C{// usage}§
     1471int @(*@f@())[@5@]@ {...}; $\C{// definition}$
     1472 ... @(*@f@())[@3@]@ += 1; $\C{// usage}$
    14871473\end{cfa}
    14881474Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
     
    14991485\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    15001486\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    1501 \begin{cfa}
    1502 ß[5] *ß ®int® x1;
    1503 ß* [5]ß ®int® x2;
    1504 ß[* [5] int]ß f®( int p )®;
     1487\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     1488#[5] *# @int@ x1;
     1489#* [5]# @int@ x2;
     1490#[* [5] int]# f@( int p )@;
    15051491\end{cfa}
    15061492&
    1507 \begin{cfa}
    1508 ®int® ß*ß x1 ß[5]ß;
    1509 ®int® ß(*ßx2ß)[5]ß;
    1510 ßint (*ßf®( int p )®ß)[5]ß;
     1493\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     1494@int@ #*# x1 #[5]#;
     1495@int@ #(*#x2#)[5]#;
     1496#int (*#f@( int p )@#)[5]#;
    15111497\end{cfa}
    15121498\end{tabular}
     
    15201506\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    15211507\begin{cfa}
    1522 ®*® int x, y;
     1508@*@ int x, y;
    15231509\end{cfa}
    15241510&
    15251511\begin{cfa}
    1526 int ®*®x, ®*®y;
     1512int @*@x, @*@y;
    15271513\end{cfa}
    15281514\end{tabular}
     
    15331519\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    15341520\begin{cfa}
    1535 ®*® int x;
     1521@*@ int x;
    15361522int y;
    15371523\end{cfa}
    15381524&
    15391525\begin{cfa}
    1540 int ®*®x, y;
     1526int @*@x, y;
    15411527
    15421528\end{cfa}
     
    16471633
    16481634\section{Pointer / Reference}
     1635\label{s:PointerReference}
    16491636
    16501637C provides a \newterm{pointer type};
     
    16731660&
    16741661\begin{cfa}
    1675 int * ®const® x = (int *)100
     1662int * @const@ x = (int *)100
    16761663*x = 3;                 // implicit dereference
    1677 int * ®const® y = (int *)104;
     1664int * @const@ y = (int *)104;
    16781665*y = *x;                        // implicit dereference
    16791666\end{cfa}
     
    17131700\begin{tabular}{@{}l@{\hspace{2em}}l@{}}
    17141701\begin{cfa}
    1715 int x, y, ®*® p1, ®*® p2, ®**® p3;
    1716 p1 = ®&®x;     // p1 points to x
     1702int x, y, @*@ p1, @*@ p2, @**@ p3;
     1703p1 = @&@x;     // p1 points to x
    17171704p2 = p1;     // p2 points to x
    1718 p1 = ®&®y;     // p1 points to y
     1705p1 = @&@y;     // p1 points to y
    17191706p3 = &p2;  // p3 points to p2
    17201707\end{cfa}
     
    17281715For example, \Index*{Algol68}~\cite{Algol68} infers pointer dereferencing to select the best meaning for each pointer usage
    17291716\begin{cfa}
    1730 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§
     1717p2 = p1 + x; $\C{// compiler infers *p2 = *p1 + x;}$
    17311718\end{cfa}
    17321719Algol68 infers the following dereferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.
     
    17361723In C, objects of pointer type always manipulate the pointer object's address:
    17371724\begin{cfa}
    1738 p1 = p2; §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
    1739 p2 = p1 + x; §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
     1725p1 = p2; $\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}$
     1726p2 = p1 + x; $\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}$
    17401727\end{cfa}
    17411728even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
    17421729\begin{cfa}
    1743 p1 = p2; §\C{// pointer address assignment}§
    1744 ®*®p2 = ®*®p1 + x; §\C{// pointed-to value assignment / operation}§
     1730p1 = p2; $\C{// pointer address assignment}$
     1731@*@p2 = @*@p1 + x; $\C{// pointed-to value assignment / operation}$
    17451732\end{cfa}
    17461733The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
     
    17581745To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing (similar but not the same as \CC \Index{reference type}s).
    17591746\begin{cfa}
    1760 int x, y, ®&® r1, ®&® r2, ®&&® r3;
    1761 ®&®r1 = &x; §\C{// r1 points to x}§
    1762 ®&®r2 = &r1; §\C{// r2 points to x}§
    1763 ®&®r1 = &y; §\C{// r1 points to y}§
    1764 ®&&®r3 = ®&®&r2; §\C{// r3 points to r2}§
    1765 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§
     1747int x, y, @&@ r1, @&@ r2, @&&@ r3;
     1748@&@r1 = &x; $\C{// r1 points to x}$
     1749@&@r2 = &r1; $\C{// r2 points to x}$
     1750@&@r1 = &y; $\C{// r1 points to y}$
     1751@&&@r3 = @&@&r2; $\C{// r3 points to r2}$
     1752r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); $\C{// implicit dereferencing}$
    17661753\end{cfa}
    17671754Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example.
     
    17691756One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes:
    17701757\begin{cfa}
    1771 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15);
     1758@*@r2 = ((@*@r1 + @*@r2) @*@ (@**@r3 - @*@r1)) / (@**@r3 - 15);
    17721759\end{cfa}
    17731760When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.
     
    17781765For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
    17791766\begin{cfa}
    1780 (&®*®)r1 = &x; §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
     1767(&@*@)r1 = &x; $\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}$
    17811768\end{cfa}
    17821769Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    17831770\begin{cfa}
    1784 (&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
     1771(&(&@*@)@*@)r3 = &(&@*@)r2; $\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}$
    17851772\end{cfa}
    17861773Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
     
    17901777int x, *p1 = &x, **p2 = &p1, ***p3 = &p2,
    17911778                 &r1 = x,    &&r2 = r1,   &&&r3 = r2;
    1792 ***p3 = 3; §\C{// change x}§
    1793 r3 = 3; §\C{// change x, ***r3}§
    1794 **p3 = ...; §\C{// change p1}§
    1795 &r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§
    1796 *p3 = ...; §\C{// change p2}§
    1797 &&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§
    1798 &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§
     1779***p3 = 3; $\C{// change x}$
     1780r3 = 3; $\C{// change x, ***r3}$
     1781**p3 = ...; $\C{// change p1}$
     1782&r3 = ...; $\C{// change r1, (\&*)**r3, 1 cancellation}$
     1783*p3 = ...; $\C{// change p2}$
     1784&&r3 = ...; $\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}$
     1785&&&r3 = p3; $\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}$
    17991786\end{cfa}
    18001787Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types.
     
    18031790As for a pointer type, a reference type may have qualifiers:
    18041791\begin{cfa}
    1805 const int cx = 5; §\C{// cannot change cx;}§
    1806 const int & cr = cx; §\C{// cannot change what cr points to}§
    1807 ®&®cr = &cx; §\C{// can change cr}§
    1808 cr = 7; §\C{// error, cannot change cx}§
    1809 int & const rc = x; §\C{// must be initialized}§
    1810 ®&®rc = &x; §\C{// error, cannot change rc}§
    1811 const int & const crc = cx; §\C{// must be initialized}§
    1812 crc = 7; §\C{// error, cannot change cx}§
    1813 ®&®crc = &cx; §\C{// error, cannot change crc}§
     1792const int cx = 5; $\C{// cannot change cx;}$
     1793const int & cr = cx; $\C{// cannot change what cr points to}$
     1794@&@cr = &cx; $\C{// can change cr}$
     1795cr = 7; $\C{// error, cannot change cx}$
     1796int & const rc = x; $\C{// must be initialized}$
     1797@&@rc = &x; $\C{// error, cannot change rc}$
     1798const int & const crc = cx; $\C{// must be initialized}$
     1799crc = 7; $\C{// error, cannot change cx}$
     1800@&@crc = &cx; $\C{// error, cannot change crc}$
    18141801\end{cfa}
    18151802Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
    18161803\begin{cfa}
    1817 int & const cr = *0; §\C{// where 0 is the int * zero}§
     1804int & const cr = *0; $\C{// where 0 is the int * zero}$
    18181805\end{cfa}
    18191806Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
     
    18221809cr = 5;
    18231810free( &cr );
    1824 cr = 7; §\C{// unsound pointer dereference}§
     1811cr = 7; $\C{// unsound pointer dereference}$
    18251812\end{cfa}
    18261813
    18271814The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    18281815The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    1829 \CFA-style declarations (see \VRef{s:AlternativeDeclarations}) attempt to address this issue:
     1816\CFA-style declarations \see{\VRef{s:AlternativeDeclarations}} attempt to address this issue:
    18301817\begin{cquote}
    18311818\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    18321819\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    18331820\begin{cfa}
    1834 ®const® * ®const® * const int ccp;
    1835 ®const® & ®const® & const int ccr;
     1821@const@ * @const@ * const int ccp;
     1822@const@ & @const@ & const int ccr;
    18361823\end{cfa}
    18371824&
    18381825\begin{cfa}
    1839 const int * ®const® * ®const® ccp;
     1826const int * @const@ * @const@ ccp;
    18401827
    18411828\end{cfa}
     
    18461833Finally, like pointers, references are usable and composable with other type operators and generators.
    18471834\begin{cfa}
    1848 int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
    1849 &ar[1] = &w; §\C{// change reference array element}§
    1850 typeof( ar[1] ) p; §\C{// (gcc) is int, \ie the type of referenced object}§
    1851 typeof( &ar[1] ) q; §\C{// (gcc) is int \&, \ie the type of reference}§
    1852 sizeof( ar[1] ) == sizeof( int ); §\C{// is true, \ie the size of referenced object}§
    1853 sizeof( &ar[1] ) == sizeof( int *) §\C{// is true, \ie the size of a reference}§
     1835int w, x, y, z, & ar[3] = { x, y, z }; $\C{// initialize array of references}$
     1836&ar[1] = &w; $\C{// change reference array element}$
     1837typeof( ar[1] ) p; $\C{// (gcc) is int, \ie the type of referenced object}$
     1838typeof( &ar[1] ) q; $\C{// (gcc) is int \&, \ie the type of reference}$
     1839sizeof( ar[1] ) == sizeof( int ); $\C{// is true, \ie the size of referenced object}$
     1840sizeof( &ar[1] ) == sizeof( int *) $\C{// is true, \ie the size of a reference}$
    18541841\end{cfa}
    18551842
    18561843In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
    18571844Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
    1858 The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
     1845The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referent object.}
    18591846\Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
    18601847
     
    18681855Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
    18691856\begin{cfa}
    1870 int * p = &x; §\C{// assign address of x}§
    1871 ®int * p = x;® §\C{// assign value of x}§
    1872 int & r = x; §\C{// must have address of x}§
     1857int * p = &x; $\C{// assign address of x}$
     1858@int * p = x;@ $\C{// assign value of x}$
     1859int & r = x; $\C{// must have address of x}$
    18731860\end{cfa}
    18741861Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
     
    18791866Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
    18801867\begin{cfa}
    1881 int & f( int & r ); §\C{// reference parameter and return}§
    1882 z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§
     1868int & f( int & r ); $\C{// reference parameter and return}$
     1869z = f( x ) + f( y ); $\C{// reference operator added, temporaries needed for call results}$
    18831870\end{cfa}
    18841871Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
     
    18931880When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions.
    18941881\begin{cfa}
    1895 void f( ®const® int & cr );
    1896 void g( ®const® int * cp );
    1897 f( 3 );                   g( ®&®3 );
    1898 f( x + y );             g( ®&®(x + y) );
     1882void f( @const@ int & cr );
     1883void g( @const@ int * cp );
     1884f( 3 );                   g( @&@3 );
     1885f( x + y );             g( @&@(x + y) );
    18991886\end{cfa}
    19001887Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
     
    19071894void f( int & r );
    19081895void g( int * p );
    1909 f( 3 );                   g( ®&®3 ); §\C{// compiler implicit generates temporaries}§
    1910 f( x + y );             g( ®&®(x + y) ); §\C{// compiler implicit generates temporaries}§
     1896f( 3 );                   g( @&@3 ); $\C{// compiler implicit generates temporaries}$
     1897f( x + y );             g( @&@(x + y) ); $\C{// compiler implicit generates temporaries}$
    19111898\end{cfa}
    19121899Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
     
    19191906\begin{cfa}
    19201907void f( int i );
    1921 void (* fp)( int ); §\C{// routine pointer}§
    1922 fp = f; §\C{// reference initialization}§
    1923 fp = &f; §\C{// pointer initialization}§
    1924 fp = *f; §\C{// reference initialization}§
    1925 fp(3); §\C{// reference invocation}§
    1926 (*fp)(3); §\C{// pointer invocation}§
     1908void (* fp)( int ); $\C{// routine pointer}$
     1909fp = f; $\C{// reference initialization}$
     1910fp = &f; $\C{// pointer initialization}$
     1911fp = *f; $\C{// reference initialization}$
     1912fp(3); $\C{// reference invocation}$
     1913(*fp)(3); $\C{// pointer invocation}$
    19271914\end{cfa}
    19281915While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
    19291916Instead, a routine object should be referenced by a ©const© reference:
    19301917\begin{cfa}
    1931 ®const® void (®&® fr)( int ) = f; §\C{// routine reference}§
    1932 fr = ... §\C{// error, cannot change code}§
    1933 &fr = ...; §\C{// changing routine reference}§
    1934 fr( 3 ); §\C{// reference call to f}§
    1935 (*fr)(3); §\C{// error, incorrect type}§
     1918@const@ void (@&@ fr)( int ) = f; $\C{// routine reference}$
     1919fr = ... $\C{// error, cannot change code}$
     1920&fr = ...; $\C{// changing routine reference}$
     1921fr( 3 ); $\C{// reference call to f}$
     1922(*fr)(3); $\C{// error, incorrect type}$
    19361923\end{cfa}
    19371924because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
     
    19461933\begin{itemize}
    19471934\item
    1948 if ©R© is an \Index{rvalue} of type ©T &©$_1\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ®*®&©$_{\color{red}2}\cdots$ ©&©$_{\color{red}r}$, \ie ©T© pointer with $r-1$ references (©&© symbols).
    1949 
    1950 \item
    1951 if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ®*®&©$_{\color{red}1}\cdots$ ©&©$_{\color{red}l}$, \ie ©T© pointer with $l$ references (©&© symbols).
     1935if ©R© is an \Index{rvalue} of type ©T &©$_1\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ©\R{©*©}©&©\R{$_2$}$\cdots$ ©&©\R{$_r$}, \ie ©T© pointer with $r-1$ references (©&© symbols).
     1936
     1937\item
     1938if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ©\R{©*©}©&©\R{$_1$}$\cdots$ ©&©\R{$_l$}, \ie ©T© pointer with $l$ references (©&© symbols).
    19521939\end{itemize}
    19531940The following example shows the first rule applied to different \Index{rvalue} contexts:
     
    19551942int x, * px, ** ppx, *** pppx, **** ppppx;
    19561943int & rx = x, && rrx = rx, &&& rrrx = rrx ;
    1957 x = rrrx; §\C[2.0in]{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}§
    1958 px = &rrrx; §\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (\&x)}§
    1959 ppx = &&rrrx; §\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (\&rx)}§
    1960 pppx = &&&rrrx; §\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (\&rrx)}§
    1961 ppppx = &&&&rrrx; §\C{// starting from \&\&\&rrrx, \&\&\&\&rrrx is an rvalue with type int **** (\&rrrx)}§
     1944x = rrrx; $\C[2.0in]{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}$
     1945px = &rrrx; $\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (\&x)}$
     1946ppx = &&rrrx; $\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (\&rx)}$
     1947pppx = &&&rrrx; $\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (\&rrx)}$
     1948ppppx = &&&&rrrx; $\C{// starting from \&\&\&rrrx, \&\&\&\&rrrx is an rvalue with type int **** (\&rrrx)}$
    19621949\end{cfa}
    19631950The following example shows the second rule applied to different \Index{lvalue} contexts:
     
    19651952int x, * px, ** ppx, *** pppx;
    19661953int & rx = x, && rrx = rx, &&& rrrx = rrx ;
    1967 rrrx = 2; §\C{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}§
    1968 &rrrx = px; §\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (rx)}§
    1969 &&rrrx = ppx; §\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (rrx)}§
    1970 &&&rrrx = pppx; §\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (rrrx)}\CRT§
     1954rrrx = 2; $\C{// rrrx is an lvalue with type int \&\&\& (equivalent to x)}$
     1955&rrrx = px; $\C{// starting from rrrx, \&rrrx is an rvalue with type int *\&\&\& (rx)}$
     1956&&rrrx = ppx; $\C{// starting from \&rrrx, \&\&rrrx is an rvalue with type int **\&\& (rrx)}$
     1957&&&rrrx = pppx; $\C{// starting from \&\&rrrx, \&\&\&rrrx is an rvalue with type int ***\& (rrrx)}\CRT$
    19711958\end{cfa}
    19721959
     
    19811968\begin{cfa}
    19821969int x;
    1983 x + 1; §\C[2.0in]{// lvalue variable (int) converts to rvalue for expression}§
     1970x + 1; $\C[2.0in]{// lvalue variable (int) converts to rvalue for expression}$
    19841971\end{cfa}
    19851972An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
     
    19911978\begin{cfa}
    19921979int x, &r = x, f( int p );
    1993 x = ®r® + f( ®r® ); §\C{// lvalue reference converts to rvalue}§
     1980x = @r@ + f( @r@ ); $\C{// lvalue reference converts to rvalue}$
    19941981\end{cfa}
    19951982An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
     
    19981985lvalue to reference conversion: \lstinline[deletekeywords=lvalue]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
    19991986\begin{cfa}
    2000 int x, &r = ®x®, f( int & p ); §\C{// lvalue variable (int) convert to reference (int \&)}§
    2001 f( ®x® ); §\C{// lvalue variable (int) convert to reference (int \&)}§
     1987int x, &r = @x@, f( int & p ); $\C{// lvalue variable (int) convert to reference (int \&)}$
     1988f( @x@ ); $\C{// lvalue variable (int) convert to reference (int \&)}$
    20021989\end{cfa}
    20031990Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
     
    20091996\begin{cfa}
    20101997int x, & f( int & p );
    2011 f( ®x + 3® );   §\C[1.5in]{// rvalue parameter (int) implicitly converts to lvalue temporary reference (int \&)}§
    2012 ®&f®(...) = &x; §\C{// rvalue result (int \&) implicitly converts to lvalue temporary reference (int \&)}\CRT§
     1998f( @x + 3@ );   $\C[1.5in]{// rvalue parameter (int) implicitly converts to lvalue temporary reference (int \&)}$
     1999@&f@(...) = &x; $\C{// rvalue result (int \&) implicitly converts to lvalue temporary reference (int \&)}\CRT$
    20132000\end{cfa}
    20142001In both case, modifications to the temporary are inaccessible (\Index{warning}).
     
    21822169The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    21832170\begin{cfa}
    2184 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
    2185         §\emph{routine body}§
     2171@[ int o1, int o2, char o3 ]@ f( int i1, char i2, char i3 ) {
     2172        $\emph{routine body}$
    21862173}
    21872174\end{cfa}
     
    21942181Declaration qualifiers can only appear at the start of a routine definition, \eg:
    21952182\begin{cfa}
    2196 ®extern® [ int x ] g( int y ) {§\,§}
     2183@extern@ [ int x ] g( int y ) {$\,$}
    21972184\end{cfa}
    21982185Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
    21992186in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    22002187\begin{cfa}
    2201 [§\,§] g(); §\C{// no input or output parameters}§
    2202 [ void ] g( void ); §\C{// no input or output parameters}§
     2188[$\,$] g(); $\C{// no input or output parameters}$
     2189[ void ] g( void ); $\C{// no input or output parameters}$
    22032190\end{cfa}
    22042191
     
    22182205\begin{cfa}
    22192206typedef int foo;
    2220 int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§
     2207int f( int (* foo) ); $\C{// foo is redefined as a parameter name}$
    22212208\end{cfa}
    22222209The 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.
     
    22262213C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    22272214\begin{cfa}
    2228 [ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§
    2229 [ * int, int * ] f( int ); §\C{// returns 2 pointers to integers, accepts an integer}§
     2215[ int ] f( * int, int * ); $\C{// returns an integer, accepts 2 pointers to integers}$
     2216[ * int, int * ] f( int ); $\C{// returns 2 pointers to integers, accepts an integer}$
    22302217\end{cfa}
    22312218The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    22322219\begin{cfa}
    22332220#define ptoa( n, d ) int (*n)[ d ]
    2234 int f( ptoa( p, 5 ) ) ... §\C{// expands to int f( int (*p)[ 5 ] )}§
    2235 [ int ] f( ptoa( p, 5 ) ) ... §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
     2221int f( ptoa( p, 5 ) ) ... $\C{// expands to int f( int (*p)[ 5 ] )}$
     2222[ int ] f( ptoa( p, 5 ) ) ... $\C{// expands to [ int ] f( int (*p)[ 5 ] )}$
    22362223\end{cfa}
    22372224Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
     
    22522239\begin{minipage}{\linewidth}
    22532240\begin{cfa}
    2254 ®[ int x, int y ]® f() {
     2241@[ int x, int y ]@ f() {
    22552242        int z;
    22562243        ... x = 0; ... y = z; ...
    2257         ®return;® §\C{// implicitly return x, y}§
     2244        @return;@ $\C{// implicitly return x, y}$
    22582245}
    22592246\end{cfa}
     
    22652252[ int x, int y ] f() {
    22662253        ...
    2267 } §\C{// implicitly return x, y}§
     2254} $\C{// implicitly return x, y}$
    22682255\end{cfa}
    22692256In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
     
    22742261[ int x, int y ] f( int, x, int y ) {
    22752262        ...
    2276 } §\C{// implicitly return x, y}§
     2263} $\C{// implicitly return x, y}$
    22772264\end{cfa}
    22782265This notation allows the compiler to eliminate temporary variables in nested routine calls.
    22792266\begin{cfa}
    2280 [ int x, int y ] f( int, x, int y ); §\C{// prototype declaration}§
     2267[ int x, int y ] f( int, x, int y ); $\C{// prototype declaration}$
    22812268int a, b;
    22822269[a, b] = f( f( f( a, b ) ) );
     
    22922279as well, parameter names are optional, \eg:
    22932280\begin{cfa}
    2294 [ int x ] f (); §\C{// returning int with no parameters}§
    2295 [ * int ] g (int y); §\C{// returning pointer to int with int parameter}§
    2296 [ ] h ( int, char ); §\C{// returning no result with int and char parameters}§
    2297 [ * int, int ] j ( int ); §\C{// returning pointer to int and int, with int parameter}§
     2281[ int x ] f (); $\C{// returning int with no parameters}$
     2282[ * int ] g (int y); $\C{// returning pointer to int with int parameter}$
     2283[ ] h ( int, char ); $\C{// returning no result with int and char parameters}$
     2284[ * int, int ] j ( int ); $\C{// returning pointer to int and int, with int parameter}$
    22982285\end{cfa}
    22992286This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    2300 Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:AlternativeDeclarations}), \eg:
     2287Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list \see{\VRef{s:AlternativeDeclarations}}, \eg:
    23012288\begin{cfa}
    23022289C :             const double bar1(), bar2( int ), bar3( double );
    2303 §\CFA§: [const double] foo(), foo( int ), foo( double ) { return 3.0; }
     2290$\CFA$: [const double] foo(), foo( int ), foo( double ) { return 3.0; }
    23042291\end{cfa}
    23052292\CFA allows the last routine in the list to define its body.
     
    23162303The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    23172304\begin{cfa}
    2318 * [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§
    2319 * [ * int ] (int y) gp; §\C{// pointer to routine returning pointer to int with int parameter}§
    2320 * [ ] (int,char) hp; §\C{// pointer to routine returning no result with int and char parameters}§
    2321 * [ * int,int ] ( int ) jp; §\C{// pointer to routine returning pointer to int and int, with int parameter}§
     2305* [ int x ] () fp; $\C[2.25in]{// pointer to routine returning int with no parameters}$
     2306* [ * int ] (int y) gp; $\C{// pointer to routine returning pointer to int with int parameter}$
     2307* [ ] (int,char) hp; $\C{// pointer to routine returning no result with int and char parameters}$
     2308* [ * int,int ] ( int ) jp; $\C{// pointer to routine returning pointer to int and int, with int parameter}\CRT$
    23222309\end{cfa}
    23232310While parameter names are optional, \emph{a routine name cannot be specified};
    23242311for example, the following is incorrect:
    23252312\begin{cfa}
    2326 * [ int x ] f () fp; §\C{// routine name "f" is not allowed}§
     2313* [ int x ] f () fp; $\C{// routine name "f" is not allowed}$
    23272314\end{cfa}
    23282315
     
    23472334whereas a named (keyword) call may be:
    23482335\begin{cfa}
    2349 p( z : 3, x : 4, y : 7 );  §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§
     2336p( z : 3, x : 4, y : 7 );  $\C{// rewrite \(\Rightarrow\) p( 4, 7, 3 )}$
    23502337\end{cfa}
    23512338Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters.
     
    23642351For example, the following routine prototypes and definition are all valid.
    23652352\begin{cfa}
    2366 void p( int, int, int ); §\C{// equivalent prototypes}§
     2353void p( int, int, int ); $\C{// equivalent prototypes}$
    23672354void p( int x, int y, int z );
    23682355void p( int y, int x, int z );
    23692356void p( int z, int y, int x );
    2370 void p( int q, int r, int s ) {} §\C{// match with this definition}§
     2357void p( int q, int r, int s ) {} $\C{// match with this definition}$
    23712358\end{cfa}
    23722359Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming.
     
    23802367int f( int x, double y );
    23812368
    2382 f( j : 3, i : 4 ); §\C{// 1st f}§
    2383 f( x : 7, y : 8.1 ); §\C{// 2nd f}§
    2384 f( 4, 5 );  §\C{// ambiguous call}§
     2369f( j : 3, i : 4 ); $\C{// 1st f}$
     2370f( x : 7, y : 8.1 ); $\C{// 2nd f}$
     2371f( 4, 5 );  $\C{// ambiguous call}$
    23852372\end{cfa}
    23862373However, named arguments compound routine resolution in conjunction with conversions:
    23872374\begin{cfa}
    2388 f( i : 3, 5.7 ); §\C{// ambiguous call ?}§
     2375f( i : 3, 5.7 ); $\C{// ambiguous call ?}$
    23892376\end{cfa}
    23902377Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
     
    24002387the allowable positional calls are:
    24012388\begin{cfa}
    2402 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
    2403 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
    2404 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
    2405 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
     2389p(); $\C{// rewrite \(\Rightarrow\) p( 1, 2, 3 )}$
     2390p( 4 ); $\C{// rewrite \(\Rightarrow\) p( 4, 2, 3 )}$
     2391p( 4, 4 ); $\C{// rewrite \(\Rightarrow\) p( 4, 4, 3 )}$
     2392p( 4, 4, 4 ); $\C{// rewrite \(\Rightarrow\) p( 4, 4, 4 )}$
    24062393// empty arguments
    2407 p(  , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
    2408 p( 4,  , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
    2409 p( 4, 4,   ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
    2410 p( 4,  ,   ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
    2411 p(  , 4,   ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
    2412 p(  ,  , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
    2413 p(  ,  ,   ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
     2394p(  , 4, 4 ); $\C{// rewrite \(\Rightarrow\) p( 1, 4, 4 )}$
     2395p( 4,  , 4 ); $\C{// rewrite \(\Rightarrow\) p( 4, 2, 4 )}$
     2396p( 4, 4,   ); $\C{// rewrite \(\Rightarrow\) p( 4, 4, 3 )}$
     2397p( 4,  ,   ); $\C{// rewrite \(\Rightarrow\) p( 4, 2, 3 )}$
     2398p(  , 4,   ); $\C{// rewrite \(\Rightarrow\) p( 1, 4, 3 )}$
     2399p(  ,  , 4 ); $\C{// rewrite \(\Rightarrow\) p( 1, 2, 4 )}$
     2400p(  ,  ,   ); $\C{// rewrite \(\Rightarrow\) p( 1, 2, 3 )}$
    24142401\end{cfa}
    24152402Here the missing arguments are inserted from the default values in the parameter list.
     
    24352422Default values may only appear in a prototype versus definition context:
    24362423\begin{cfa}
    2437 void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§
    2438 void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§
    2439 void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§
     2424void p( int x, int y = 2, int z = 3 ); $\C{// prototype: allowed}$
     2425void p( int, int = 2, int = 3 ); $\C{// prototype: allowed}$
     2426void p( int x, int y = 2, int z = 3 ) {} $\C{// definition: not allowed}$
    24402427\end{cfa}
    24412428The reason for this restriction is to allow separate compilation.
     
    24522439\begin{cfa}
    24532440p( int x, int y, int z, ... );
    2454 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
    2455 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
     2441p( 1, 4, 5, 6, z : 3, y : 2 ); $\C{// assume p( /* positional */, ... , /* named */ );}$
     2442p( 1, z : 3, y : 2, 4, 5, 6 ); $\C{// assume p( /* positional */, /* named */, ... );}$
    24562443\end{cfa}
    24572444In 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.
     
    24622449\begin{cfa}
    24632450void p( int x, int y = 2, int z = 3... );
    2464 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
    2465 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
     2451p( 1, 4, 5, 6, z : 3 ); $\C{// assume p( /* positional */, ... , /* named */ );}$
     2452p( 1, z : 3, 4, 5, 6 ); $\C{// assume p( /* positional */, /* named */, ... );}$
    24662453\end{cfa}
    24672454The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
     
    24692456In the second call, the default value for y is implicitly inserted after argument 1 and the named arguments separate the positional and ellipse arguments, making it trivial to read the call.
    24702457For these reasons, \CFA requires named arguments before ellipse arguments.
    2471 Finally, while ellipse arguments are needed for a small set of existing C routines, like printf, the extended \CFA type system largely eliminates the need for ellipse arguments (see Section 24), making much of this discussion moot.
    2472 
    2473 Default arguments and overloading (see Section 24) are complementary.
     2458Finally, while ellipse arguments are needed for a small set of existing C routines, like ©printf©, the extended \CFA type system largely eliminates the need for ellipse arguments \see{\VRef{s:Overloading}}, making much of this discussion moot.
     2459
     2460Default arguments and overloading \see{\VRef{s:Overloading}} are complementary.
    24742461While in theory default arguments can be simulated with overloading, as in:
    24752462\begin{cquote}
     
    24932480Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as:
    24942481\begin{cfa}
    2495 p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§
     2482p( 1, /* default */, 5 ); $\C{// rewrite \(\Rightarrow\) p( 1, 2, 5 )}$
    24962483\end{cfa}
    24972484
     
    25062493\begin{cfa}
    25072494struct {
    2508         int f1; §\C{// named field}§
    2509         int f2 : 4; §\C{// named field with bit field size}§
    2510         int : 3; §\C{// unnamed field for basic type with bit field size}§
    2511         int ; §\C{// disallowed, unnamed field}§
    2512         int *; §\C{// disallowed, unnamed field}§
    2513         int (*)( int ); §\C{// disallowed, unnamed field}§
     2495        int f1; $\C{// named field}$
     2496        int f2 : 4; $\C{// named field with bit field size}$
     2497        int : 3; $\C{// unnamed field for basic type with bit field size}$
     2498        int ; $\C{// disallowed, unnamed field}$
     2499        int *; $\C{// disallowed, unnamed field}$
     2500        int (*)( int ); $\C{// disallowed, unnamed field}$
    25142501};
    25152502\end{cfa}
     
    25192506\begin{cfa}
    25202507struct {
    2521         int , , ; §\C{// 3 unnamed fields}§
     2508        int , , ; $\C{// 3 unnamed fields}$
    25222509}
    25232510\end{cfa}
     
    25312518\subsection{Type Nesting}
    25322519
    2533 \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.
     2520\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.
    25342521\begin{figure}
    25352522\centering
     
    25872574
    25882575int fred() {
    2589         s.t.c = ®S.®R;  // type qualification
    2590         struct ®S.®T t = { ®S.®R, 1, 2 };
    2591         enum ®S.®C c;
    2592         union ®S.T.®U u;
     2576        s.t.c = @S.@R;  // type qualification
     2577        struct @S.@T t = { @S.@R, 1, 2 };
     2578        enum @S.@C c;
     2579        union @S.T.@U u;
    25932580}
    25942581\end{cfa}
     
    26132600const unsigned int size = 5;
    26142601int ia[size];
    2615 ... §\C{// assign values to array ia}§
    2616 qsort( ia, size ); §\C{// sort ascending order using builtin ?<?}§
     2602... $\C{// assign values to array ia}$
     2603qsort( ia, size ); $\C{// sort ascending order using builtin ?<?}$
    26172604{
    2618         ®int ?<?( int x, int y ) { return x > y; }® §\C{// nested routine}§
    2619         qsort( ia, size ); §\C{// sort descending order by local redefinition}§
     2605        @int ?<?( int x, int y ) { return x > y; }@ $\C{// nested routine}$
     2606        qsort( ia, size ); $\C{// sort descending order by local redefinition}$
    26202607}
    26212608\end{cfa}
     
    26252612The following program in undefined in \CFA (and Indexc{gcc})
    26262613\begin{cfa}
    2627 [* [int]( int )] foo() { §\C{// int (* foo())( int )}§
    2628         int ®i® = 7;
     2614[* [int]( int )] foo() { $\C{// int (* foo())( int )}$
     2615        int @i@ = 7;
    26292616        int bar( int p ) {
    2630                 ®i® += 1; §\C{// dependent on local variable}§
    2631                 sout | ®i®;
     2617                @i@ += 1; $\C{// dependent on local variable}$
     2618                sout | @i@;
    26322619        }
    2633         return bar; §\C{// undefined because of local dependence}§
     2620        return bar; $\C{// undefined because of local dependence}$
    26342621}
    26352622int main() {
    2636         * [int]( int ) fp = foo(); §\C{// int (* fp)( int )}§
     2623        * [int]( int ) fp = foo(); $\C{// int (* fp)( int )}$
    26372624        sout | fp( 3 );
    26382625}
     
    26472634In C and \CFA, lists of elements appear in several contexts, such as the parameter list of a routine call.
    26482635\begin{cfa}
    2649 f( ®2, x, 3 + i® ); §\C{// element list}§
     2636f( @2, x, 3 + i@ ); $\C{// element list}$
    26502637\end{cfa}
    26512638A list of elements is called a \newterm{tuple}, and is different from a \Index{comma expression}.
     
    26562643
    26572644In C and most programming languages, functions return at most one value;
    2658 however, many operations have multiple outcomes, some exceptional (see~\VRef{s:ExceptionHandling}).
     2645however, many operations have multiple outcomes, some exceptional \see{\VRef{s:ExceptionHandling}}.
    26592646To emulate functions with multiple return values, \emph{\Index{aggregation}} and/or \emph{\Index{aliasing}} is used.
    26602647
     
    26622649For example, consider C's \Indexc{div} function, which returns the quotient and remainder for a division of an integer value.
    26632650\begin{cfa}
    2664 typedef struct { int quot, rem; } div_t;        §\C[7cm]{// from include stdlib.h}§
     2651typedef struct { int quot, rem; } div_t;        $\C[7cm]{// from include stdlib.h}$
    26652652div_t div( int num, int den );
    2666 div_t qr = div( 13, 5 ); §\C{// return quotient/remainder aggregate}§
    2667 printf( "%d %d\n", qr.quot, qr.rem ); §\C{// print quotient/remainder}§