Changeset 7ff30d07

doc/LaTeXmacros/common.tex

-                      r6cbc25a
+                      r7ff30d07
 %% Created On       : Sat Apr  9 10:06:17 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri Jun  3 09:32:19 2016
 %% Update Count     : 62
+%% Last Modified On : Fri Jun 10 16:35:25 2016
+%% Update Count     : 101
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 %   \belowdisplayskip \abovedisplayskip
 %}
+\usepackage{pslatex}                                                                    % reduce size of san serif font
 \usepackage{relsize}                                    % must be after change to small or selects old size
 …
     \vskip 50\p@
   }}
 \renewcommand\section{\@startsection{section}{1}{\z@}{-3.5ex \@plus -1ex \@minus -.2ex}{2.3ex \@plus .2ex}{\normalfont\large\bfseries}}
+\renewcommand\section{\@startsection{section}{1}{\z@}{-3.5ex \@plus -1ex \@minus -.2ex}{1.75ex \@plus .2ex}{\normalfont\large\bfseries}}
 \renewcommand\subsection{\@startsection{subsection}{2}{\z@}{-3.25ex \@plus -1ex \@minus -.2ex}{1.5ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
 \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}{-2.5ex \@plus -1ex \@minus -.2ex}{1.0ex \@plus .2ex}{\normalfont\normalsize\bfseries}}
 …
 \newenvironment{quote2}{%
         \list{}{\lstset{resetmargins=true}\leftmargin=\parindent\rightmargin\leftmargin}%
+        \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindent\rightmargin\leftmargin}%
         \item\relax
 }{%
 …
 language=CFA,
 columns=flexible,
 basicstyle=\sf,
+basicstyle=\linespread{0.9}\sf,
 stringstyle=\tt,
 tabsize=4,
 …
 showlines=true,
 aboveskip=4pt,
 belowskip=2pt,
+belowskip=3pt,
 moredelim=**[is][\color{red}]{®}{®}, % red highlighting
+% moredelim=**[is][\color{blue}]{¢}{¢}, % blue highlighting
+moredelim=**[is][\color{blue}]{ß}{ß}, % blue highlighting
+moredelim=**[is][\color{OliveGreen}]{¢}{¢}, % green highlighting
 moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % temporarily turn off keywords
+% literate={\\`}{\raisebox{0.3ex}{\ttfamily\upshape \hspace*{-2pt}`}}1, % escape \`, otherwise used for red highlighting
+literate={...}{{$\dots$}}1 {<-}{{$\leftarrow$}}1 {=>}{{$\Rightarrow$}}1,
+% replace/adjust listing characters that look bad in sanserif
+literate={-}{\raisebox{-0.15ex}{\texttt{-}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
+        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {_}{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}1 {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
+        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {...}{$\dots$}2,
 }%
 \lstMakeShortInline©    % single-character for \lstinline
-\makeatletter
-% replace/adjust listings characters that look bad in sanserif
-\lst@CCPutMacro
-\lst@ProcessOther{"22}{\lst@ttfamily{"}{\raisebox{0.3ex}{\ttfamily\upshape "}}} % replace double quote
-\lst@ProcessOther{"27}{\lst@ttfamily{'}{\raisebox{0.3ex}{\ttfamily\upshape '\hspace*{-2pt}}}} % replace single quote
-\lst@ProcessOther{"2D}{\lst@ttfamily{-}{\textbf{\texttt{-}}}} % replace minus
-\lst@ProcessOther{"3C}{\lst@ttfamily{<}{\textbf{\texttt{<}}}} % replace less than
-\lst@ProcessOther{"3E}{\lst@ttfamily{>}{\textbf{\texttt{>}}}} % replace greater than
-\lst@ProcessOther{"5E}{\raisebox{0.4ex}{$\scriptstyle\land\,$}} % replace circumflex
-\lst@ProcessOther{"5F}{\lst@ttfamily{\char95}{{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}}} % replace underscore
-\lst@ProcessOther{"60}{\lst@ttfamily{`}{\raisebox{0.3ex}{\ttfamily\upshape \hspace*{-2pt}`}}} % replace backquote
-\lst@ProcessOther{"7E}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}} % replace tilde
-%\lst@ProcessOther{"7E}{\raisebox{-.4ex}[1ex][0pt]{\textasciitilde}} % lower tilde
-\@empty\z@\@empty % NECESSARY DO NOT REMOVE
-\makeatother
 % Local Variables: %

doc/user/Cdecl.fig

-                      r6cbc25a
+                      r7ff30d07
 1 1.00 45.00 90.00
 1275 1950 1500
 1 0 50 -1 4 9 0.0000 2 105 90 1350 1650 0\001
 1 0 50 -1 4 9 0.0000 2 105 90 1500 1650 1\001
 1 0 50 -1 4 9 0.0000 2 105 90 1650 1650 2\001
 1 0 50 -1 4 9 0.0000 2 105 90 1800 1650 3\001
 1 0 50 -1 4 9 0.0000 2 105 90 1950 1650 4\001
 1 0 50 -1 4 9 0.0000 2 75 75 1200 1325 x\001
+1 0 50 -1 4 10 0.0000 2 105 90 1350 1650 0\001
+1 0 50 -1 4 10 0.0000 2 105 90 1500 1650 1\001
+1 0 50 -1 4 10 0.0000 2 105 90 1650 1650 2\001
+1 0 50 -1 4 10 0.0000 2 105 90 1800 1650 3\001
+1 0 50 -1 4 10 0.0000 2 105 90 1950 1650 4\001
+1 0 50 -1 4 10 0.0000 2 75 75 1200 1325 x\001
 -6
 2325 1200 3600 1350
 …
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1200 3600 1200 3600 1350 2850 1350 2850 1200
 1 0 50 -1 4 9 0.0000 2 105 90 2925 1325 0\001
 1 0 50 -1 4 9 0.0000 2 105 90 3075 1325 1\001
 1 0 50 -1 4 9 0.0000 2 105 90 3225 1325 2\001
 1 0 50 -1 4 9 0.0000 2 105 90 3375 1325 3\001
 1 0 50 -1 4 9 0.0000 2 105 90 3525 1325 4\001
+1 0 50 -1 4 10 0.0000 2 105 90 2925 1325 0\001
+1 0 50 -1 4 10 0.0000 2 105 90 3075 1325 1\001
+1 0 50 -1 4 10 0.0000 2 105 90 3225 1325 2\001
+1 0 50 -1 4 10 0.0000 2 105 90 3375 1325 3\001
+1 0 50 -1 4 10 0.0000 2 105 90 3525 1325 4\001
 -6
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 …
 1275 2850 1275
 -6
 1 0 50 -1 4 9 0.0000 2 75 75 2400 1325 x\001
+1 0 50 -1 4 10 0.0000 2 75 75 2400 1325 x\001
 -6

doc/user/user.tex

-                      r6cbc25a
+                      r7ff30d07
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri Jun  3 09:49:31 2016
 %% Update Count     : 281
+%% Last Modified On : Fri Jun 10 16:38:22 2016
+%% Update Count     : 394
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 % inline code ©...© (copyright symbol) emacs: C-q M-)
+% red highlighting ®...® (registered trademark sumbol) emacs: C-q M-.
+% latex escape §...§ (section symbol) emacs: C-q M-'
+% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
+% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
+% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
+% Latex escape §...§ (section symbol) emacs: C-q M-'
 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
 % math escape $...$ (dollar symbol)
 \documentclass[openright,twoside]{article}
+\documentclass[twoside,11pt]{article}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \usepackage{fullpage,times,comment}
 \usepackage{epic,eepic}
 \usepackage{upquote}                                                                    % switch curled `' to straight `'
+\usepackage{upquote}                                                                    % switch curled `'" to straight `'"
 \usepackage{xspace}
 \usepackage{varioref}                                                                   % extended references
 \usepackage{listings}                                                                   % format program code
 \usepackage{footmisc}                                                                   % support label/reference in footnote
+\usepackage[flushmargin]{footmisc}                                              % support label/reference in footnote
 \usepackage{latexsym}                                   % \Box glyph
 \usepackage{mathptmx}                                   % better math font with "times"
+\usepackage[usenames]{color}
 \usepackage[pagewise]{lineno}
 \renewcommand{\linenumberfont}{\scriptsize\sffamily}
+\input{common}                                          % bespoke macros used in the document
 \usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
 \usepackage{breakurl}
 \renewcommand{\UrlFont}{\small\sf}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% Bespoke macros used in the document.
-\input{common}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Names used in the document.
 \newcommand{\Version}{1.0.0}
 \newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace}
+\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}}
+\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}}
+\newcommand{\R}[1]{\Textbf{#1}}
+\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
+\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \CFA\footnote{Pronounced ``C-for-all'', and written \CFA, CFA, or \CFL.} is a modern general-purpose programming-language, designed an as evolutionary step forward from the C programming language.
 The syntax of the \CFA language builds from C, and should look immediately familiar to C programmers.
+The syntax of the \CFA language builds from C, and should look immediately familiar to C/\CC programmers.
 % Any language feature that is not described here can be assumed to be using the standard C11 syntax.
 \CFA adds many modern programming-language features that directly leads to increased \emph{safety} and \emph{productivity}, while maintaining interoperability with existing C programs and achieving C performance.
+\CFA adds many modern programming-language features that directly lead to increased \emph{safety} and \emph{productivity}, while maintaining interoperability with existing C programs and achieving C performance.
 Like C, \CFA is a statically typed, procedural language with a low-overhead runtime, meaning there is no global garbage-collection.
 The primary new features include parametric-polymorphism routines and types, exceptions, concurrency, and modules.
 …
 New programs can be written in \CFA using a combination of C and \CFA features.
 \CC had a similar goal 30 years ago, but has struggled over the intervening time to incorporate modern programming-language features because of early design choices.
 \CFA has 30 years of hindsight and clean starting point.
+\CFA has 30 years of hindsight and a clean starting point.
 Like \CC, there may be both an old and new ways to achieve the same effect.
 For example, the following programs compare the \CFA and C I/O mechanisms.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 #include <fstream>
 int main( void ) {
         int x = 0, y = 1, z = 2;
         sout | x | y | z | endl;
+        ®sout | x | y | z | endl;®
+}
 \end{lstlisting}
 …
 int main( void ) {
         int x = 0, y = 1, z = 2;
         printf( "%d %d %d\n", x, y, z );
+        ®printf( "%d %d %d\n", x, y, z );®
+}
 \end{lstlisting}
 …
 \end{quote2}
 Both programs output the same result.
 While the \CFA I/O looks similar to the \CC output style, there are several important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
 This document is a reference manual for the \CFA programming language, targeted at \CFA programmers.
+While the \CFA I/O looks similar to the \CC output style, there are important differences, such as automatic spacing between variables as in Python (see also~\VRef{s:IOLibrary}).
+This document is a user manual for the \CFA programming language, targeted at \CFA programmers.
 Implementers may refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
 In its current state, this document covers the intended core features of the language.
 …
 \section{History}
 The \CFA project started with K-W C~\cite{Till89,Buhr94a}, which extended C with new declaration syntax, multiple return values from routines, and extended assignment capabilities using the notion of tuples.
+The \CFA project started with K-W C~\cite{Buhr94a,Till89}, which extended C with new declaration syntax, multiple return values from routines, and extended assignment capabilities using the notion of tuples.
 (See~\cite{Werther96} for some similar work, but for \CC.)
 The original \CFA project~\cite{Ditchfield92} extended the C type system with parametric polymorphism and overloading, as opposed to the \CC approach of object-oriented extensions to the C type-system.
 A first implementation of the core Cforall language was created~\cite{Bilson03,Esteves04}, but at the time there was little interesting in extending C, so work did not continue.
 As the saying goes, ``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.
+As the saying goes, ``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.
 …
 Even with all its problems, C is a very popular programming language because it allows writing software at virtually any level in a computer system without restriction.
 For systems programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
+For system programming, where direct access to hardware and dealing with real-time issues is a requirement, C is usually the language of choice.
 As well, there are millions of lines of C legacy code, forming the base for many software development projects (especially on UNIX systems).
 The TIOBE index (\url{http://www.tiobe.com/tiobe_index}) for March 2016 shows programming-language popularity, with Java 20.5\%, C 14.5\%, \CC 6.7\%, \CS 4.3\%, Python 4.3\%, and all other programming languages below 3\%.
+As well, for 30 years, C has been the number 1 and 2 most popular programming language:
+\begin{center}
+\setlength{\tabcolsep}{1.5ex}
+\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
+Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
+\hline
+Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
+\hline
+\R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
+\hline
+\CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
+\end{tabular}
+\end{center}
 Hence, C is still an extremely important programming language, with double the usage of \CC, where \CC itself is largely C code.
 Finally, love it or hate it, C has been an important and influential part of computer science for 40 years and it appears it will continue to be for many more years.
 …
 The goal of this project is to engineer modern language features into C in an evolutionary rather than revolutionary way.
 \CC~\cite{c++,ANSI14:C++} is an example of a similar project;
 however, it largely extended the language, and did not address existing problems.\footnote{%
+however, it largely extended the language, and did not address many existing problems.\footnote{%
 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.}
 Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features are added and problems fixed within the framework of the existing language.
+Fortran~\cite{Fortran08}, Ada~\cite{Ada12}, and Cobol~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (e.g., objects, concurrency) are added and problems fixed within the framework of the existing language.
 Java~\cite{Java8}, Go~\cite{Go}, Rust~\cite{Rust} and D~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent.
 These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection.
 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
 These costs can be prohibitive for many companies with a large software base in C/\CC, and many programmers that require retraining to a new programming language.
 The result of this project is a language that is largely backwards compatible with C11~\cite{C11}, but containing many modern language features and fixing some of the well known C problems.
 Without significant extension to the C programming language, C will be unable to cope with the needs of modern programming problems and programmers;
+These costs can be prohibitive for many companies with a large software base in C/\CC, and a significant number of programmers requiring retraining to a new programming language.
+The result of this project is a language that is largely backwards compatible with C11~\cite{C11}, but fixing some of the well known C problems and containing many modern language features.
+Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
 as a result, it will fade into disuse.
 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
 …
 This feature allows users of \CFA to take advantage of the existing panoply of C libraries from inside their \CFA code.
 In fact, one of the biggest issues for any new programming language is establishing a minimum level of library code to support a large body of activities.
 Programming-language developers often state that adequate library support takes more work than designing and implementing the language itself.
+Language developers often state that adequate library support takes more work than designing and implementing the language itself.
 Like \CC, \CFA 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.
+Hence, \CFA begins by leveraging the large repository of C libraries with little cost.
 However, it is necessary to differentiate between C and \CFA code because of name overloading, as for \CC.
 For example, the C math-library provides the following routines for computing the absolute value of the basic type: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
 Whereas, \CFA wraps each of these routines into one with the common name ©abs©.
+For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©.
+Whereas, \CFA wraps each of these routines into ones with the common name ©abs©:
 \begin{lstlisting}
 char abs( char );
 extern "C" {
 int abs( int );                         // use default C routine for int
+int abs( int );                                 // use default C routine for int
 } // extern "C"
 long int abs( long int );
 …
 \section[Compiling CFA Program]{Compiling \CFA Program}
+The command ©cfa© is used to compile \CFA program(s).
+This command works like the GNU ©gcc©\index{gcc} command, e.g.:
+The command ©cfa© is used to compile \CFA program(s), and is based on the GNU ©gcc©\index{gcc} command, e.g.:
 \begin{lstlisting}
 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ]
 …
 By default, \CFA programs having the following ©gcc© flags turned on:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
+\item\hspace*{-0.6ex}\Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
 The 1999 C standard plus GNU extensions.
 \item\hspace*{-4pt}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
+\item\hspace*{-0.6ex}\Indexc{-fgnu89-¶inline¶}\index{compilation option!-fgnu89-inline@{©-fgnu89-¶inline¶©}}
 Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
 \end{description}
 The following new \CFA option is available:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{-CFA}\index{compilation option!-CFA@{©-CFA©}}
+\item\hspace*{-0.6ex}\Indexc{-CFA}\index{compilation option!-CFA@{©-CFA©}}
 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.
 \end{description}
 …
 The following preprocessor variables are available:
 \begin{description}
 \item\hspace*{-4pt}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
+\item\hspace*{-0.6ex}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}}
 is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{
 The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed.
 Hence, the need to have three variables for the major, minor and patch version number.}
 \item\hspace*{-4pt}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
+\item\hspace*{-0.6ex}\Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}}
 is always available during preprocessing and its value is the current minor \Index{version number} of \CFA.
 \item\hspace*{-4pt}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
+\item\hspace*{-0.6ex}\Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©}
 is always available during preprocessing and its value is the current patch \Index{version number} of \CFA.
 \item\hspace*{-4pt}\Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
 is always available during preprocessing and it has no value.
+\item\hspace*{-0.6ex}\Indexc{__CFA__}\index{preprocessor variables!__CFA__@©__CFA__©} and \Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©}
+are always available during preprocessing and have no value.
 \end{description}
 …
 \begin{lstlisting}
 #ifndef __CFORALL__
 #include <stdio.h>                      // C header file
+#include <stdio.h>                              // C header file
 #else
 #include <fstream>                      // §\CFA{}§ header file
+#include <fstream>                              // §\CFA{}§ header file
 #endif
 \end{lstlisting}
 …
 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:
 \begin{lstlisting}
 ®_®147®_®483®_®648;                            // decimal constant
 _ul;                                          // decimal unsigned long constant
 _377;                                          // octal constant
 x_ff_ff;                                       // hexadecimal constant
 x_ef3d_aa5c;                           // hexadecimal constant
 .141_592_654;                          // floating point constant
 _e_+1_00;                                     // floating point constant
 x_ff_ff_p_3;                           // hexadecimal floating point
 x_1.ffff_ffff_p_128_l;         // hexadecimal floating point long constant
 L_"\x_ff_ee";                           // wide character constant
+®_®147®_®483®_®648;                                    // decimal constant
+_ul;                                                  // decimal unsigned long constant
+_377;                                                  // octal constant
+x_ff_ff;                                               // hexadecimal constant
+x_ef3d_aa5c;                                   // hexadecimal constant
+.141_592_654;                                  // floating point constant
+_e_+1_00;                                             // floating point constant
+x_ff_ff_p_3;                                   // hexadecimal floating point
+x_1.ffff_ffff_p_128_l;                 // hexadecimal floating point long constant
+L_"\x_ff_ee";                                   // wide character constant
 \end{lstlisting}
 The rules for placement of underscores is as follows:
 …
 \end{enumerate}
 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java.
+This extension is backwards compatible, matches with the use of underscore in variable names, and appears in Ada and Java 8.
 …
 \begin{quote2}
 \begin{tabular}{@{}ll@{}}
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 int *x[ 5 ]
+\begin{lstlisting}
+int *x[5]
 \end{lstlisting}
+&
 …
 For example, a routine returning a pointer to an array of integers is defined and used in the following way:
 \begin{lstlisting}
 int (*f())[ 5 ] {...};  // definition mimics usage
 ... (*f())[ 3 ] += 1;
+int (*f())[5] {...};                    // definition mimics usage
+... (*f())[3] += 1;
 \end{lstlisting}
 Essentially, the return type is wrapped around the routine name in successive layers (like an onion).
 While attempting to make the two contexts consistent was a laudable goal, it has not worked out in practice.
+\CFA provides its own type, variable and routine declarations, using a slightly different syntax.
+The new declarations place modifiers to the left of the base type, while C declarations place modifiers to the right of the base type.
+\CFA provides its own type, variable and routine declarations, using a different syntax.
+The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
+In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
+The \CFA declarations move the qualifiers to the left of the base type, i.e., blue to the left of the red, while the qualifiers have the same meaning but are ordered left to left to right to specify the variable's type.
+\begin{quote2}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{lstlisting}
+ß[5] *ß ®int® x1;
+ß* [5]ß ®int® x2;
+ß[* [5] int]ß f®( int p )®;
+\end{lstlisting}
+&
+\begin{lstlisting}
+®int® ß*ß x1 ß[5]ß;
+®int® ß(*ßx2ß)[5]ß;
+ßint (*ßf®( int p )®ß)[5]ß;
+\end{lstlisting}
+\end{tabular}
+\end{quote2}
 The only exception is bit field specification, which always appear to the right of the base type.
+C and the new \CFA declarations may appear together in the same program block, but cannot be mixed within a specific declaration.
+In \CFA declarations, the same tokens are used as in C: the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array, and parentheses ©()© are used to indicate a routine parameter.
+However, unlike C, \CFA type declaration tokens are specified from left to right and the entire type specification is distributed across all variables in the declaration list.
+% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
+However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
 For instance, variables ©x© and ©y© of type pointer to integer are defined in \CFA as follows:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 ®* int x, y;®
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{lstlisting}
+®*® int x, y;
 \end{lstlisting}
+&
 \begin{lstlisting}
 int *x, *y;
+int ®*®x, ®*®y;
 \end{lstlisting}
 \end{tabular}
 …
 Other examples are:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
 \begin{lstlisting}
 [ 5 ] int z;
 …
 \end{quote2}
 All type qualifiers, i.e., ©const© and ©volatile©, are used in the normal way with the new declarations but appear left to right, e.g.:
+All type qualifiers, e.g., ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, e.g.:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
+\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
 \begin{lstlisting}
 const * const int x;
 …
 \end{tabular}
 \end{quote2}
 All declaration qualifiers, i.e., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+All declaration qualifiers, e.g., ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} e.g.:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
 \begin{lstlisting}
 extern [ 5 ] int x;
 …
 e.g.:
 \begin{lstlisting}
 x;                                              // int x
 *y;                                             // int *y
 f( p1, p2 );                    // int f( int p1, int p2 );
 f( p1, p2 ) {}                  // int f( int p1, int p2 ) {}
 \end{lstlisting}
 As stated above, the two styles of declaration may appear together in the same block.
+x;                                                              // int x
+*y;                                                             // int *y
+f( p1, p2 );                                    // int f( int p1, int p2 );
+f( p1, p2 ) {}                                  // int f( int p1, int p2 ) {}
+\end{lstlisting}
+Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.
 …
 The new declaration syntax can be used in other contexts where types are required, e.g., casts and the pseudo-routine ©sizeof©:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 y = (* int)x;
 i = sizeof([ 5 ] * int);
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{lstlisting}
+y = (®* int®)x;
+i = sizeof(®[ 5 ] * int®);
 \end{lstlisting}
+&
 \begin{lstlisting}
 y = (int *)x;
 i = sizeof(int *[ 5 ]);
+y = (®int *®)x;
+i = sizeof(®int *[ 5 ]®);
 \end{lstlisting}
 \end{tabular}
 …
 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
 The point of the new syntax is to allow returning multiple values from a routine~\cite{CLU,Galletly96}, e.g.:
+The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, e.g.:
 \begin{lstlisting}
 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) {
 …
 Declaration qualifiers can only appear at the start of a routine definition, e.g.:
 \begin{lstlisting}
 extern [ int x ] g( int y ) {§\,§}
+®extern® [ int x ] g( int y ) {§\,§}
 \end{lstlisting}
 Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified;
 in 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:
 \begin{lstlisting}
 [§\,§] g();                                             // no input or output parameters
 [ void ] g( void );                     // no input or output parameters
+[§\,§] g();                                                     // no input or output parameters
+[ void ] g( void );                             // no input or output parameters
 \end{lstlisting}
 …
 [ i, j, ch ] = f( 3, 'a', ch );
 \end{lstlisting}
 The list of return values from f and the grouping on the left-hand side of the assignment is called a tuple and discussed in Section 12.
+The list of return values from f and the grouping on the left-hand side of the assignment is called a \newterm{return list} and discussed in Section 12.
 \CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity:
 …
 \begin{lstlisting}
 typedef int foo;
 int f( int (* foo) );           // foo is redefined as a parameter name
+int f( int (* foo) );                   // foo is redefined as a parameter name
 \end{lstlisting}
 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
 The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type modifier characters appearing to the right of the type name.
+The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name.
 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts.
 C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:
 \begin{lstlisting}
 [ int ] f( * int, int * );      // returns an integer, accepts 2 pointers to integers
 [ * int, int * ] f( int );      // returns 2 pointers to integers, accepts an integer
+[ int ] f( * int, int * );              // returns an integer, accepts 2 pointers to integers
+[ * int, int * ] f( int );              // returns 2 pointers to integers, accepts an integer
 \end{lstlisting}
 The 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:
 \begin{lstlisting}
 #define ptoa( n, d ) int (*n)[ d ]
 int f( ptoa(p,5) ) ...          // expands to int f( int (*p)[ 5 ] )
 [ int ] f( ptoa(p,5) ) ...      // expands to [ int ] f( int (*p)[ 5 ] )
+int f( ptoa( p, 5 ) ) ...               // expands to int f( int (*p)[ 5 ] )
+[ int ] f( ptoa( p, 5 ) ) ...   // expands to [ int ] f( int (*p)[ 5 ] )
 \end{lstlisting}
 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
 \subsection{Returning Values}
 Named return values handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
+\subsection{Named Return Values}
+\Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in:
 \begin{lstlisting}
 int f() {
 …
 \end{lstlisting}
 Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in:
+\begin{lstlisting}
+®[ int x ]® f() {
+        ... x = 0; ... x = y; ...
+        ®return;® // implicitly return x
+}
+\end{lstlisting}
+When the return is encountered, the current value of ©x© is returned to the calling routine.
+\newline
+\begin{minipage}{\linewidth}
+\begin{lstlisting}
+®[ int x, int y ]® f() {
+        int z;
+        ... x = 0; ... y = z; ...
+        ®return;® // implicitly return x, y
+}
+\end{lstlisting}
+\end{minipage}
+\newline
+When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine.
 As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in:
 \begin{lstlisting}
 [ int x ] f() {
         ... x = 0; ... x = y; ...
 } // implicitly return x
 \end{lstlisting}
 In this case, the current value of ©x© is returned to the calling routine just as if a ©return© had been encountered.
+[ int x, int y ] f() {
+        ...
+} // implicitly return x, y
+\end{lstlisting}
+In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
 …
 as well, parameter names are optional, e.g.:
 \begin{lstlisting}
 [ int x ] f ();                         // returning int with no parameters
 [ * int ] g (int y);            // returning pointer to int with int parameter
 [ ] h (int,char);                       // returning no result with int and char parameters
 [ * int,int ] j (int);          // returning pointer to int and int, with int parameter
+[ int x ] f ();                                 // returning int with no parameters
+[ * int ] g (int y);                    // returning pointer to int with int parameter
+[ ] h (int,char);                               // returning no result with int and char parameters
+[ * int,int ] j (int);                  // returning pointer to int and int, with int parameter
 \end{lstlisting}
 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), e.g.:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 [ int ] f(int), g;
 …
 for example, the following is incorrect:
 \begin{lstlisting}
 * [ int x ] f () fp;            // routine name "f" is not allowed
+* [ int x ] f () fp;                    // routine name "f" is not allowed
 \end{lstlisting}
 …
 While in theory default arguments can be simulated with overloading, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{default arguments}}  & \multicolumn{1}{c}{\textbf{overloading}}      \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}}   & \multicolumn{1}{c}{\textbf{overloading}}      \\
 \begin{lstlisting}
 void p( int x, int y = 2, int z = 3 ) {...}
 …
 \CFA allows \Index{type nesting}, and type qualification of the nested types, where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l|l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{C Type Nesting}}     & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
+\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
 \hline
 \begin{lstlisting}
 …
 \section{Tuples}
+\section{Lexical List}
 In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call.
 (More contexts are added shortly.)
 A list of such elements is called a tuple.
 The general syntax of a tuple is:
+A list of such elements is called a \newterm{lexical list}.
+The general syntax of a lexical list is:
 \begin{lstlisting}
 [ §\emph{exprlist}§ ]
 \end{lstlisting}
 where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas.
 The brackets, ©[]©, allow differentiating between tuples and expressions containing the C comma operator.
 The following are examples of tuples:
+The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator.
+The following are examples of lexical lists:
 \begin{lstlisting}
 [ x, y, z ]
 …
 \begin{figure}
 \centering
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 ®L1:® for ( ... ) {
 …
 \vspace*{0.25in}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{lstlisting}
 ®L1®: for ( ... ) {
 …
 Therefore, the ©case© clause is extended with a list of values, as in:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{C}}        \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
 \begin{lstlisting}
 switch ( i ) {
 …
 In addition, two forms of subranges are allowed to specify case values: the GNU C form and a new \CFA form.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{\hspace{20pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c@{\hspace{20pt}}}{\textbf{GNU C}}    \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}}     \\
 \begin{lstlisting}
 switch ( i ) {
 …
 Auto type-inferencing occurs in a declaration where a variable's type is inferred from its initialization expression type.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}ll@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CC}}        & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
+\begin{tabular}{@{}l@{\hspace{3em}}ll@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{©gcc©}\index{gcc} \\
 \begin{lstlisting}
 …
 The general case is printing out a sequence of variables separated by whitespace.
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{30pt}}l@{}}
 \multicolumn{1}{c@{\hspace{30pt}}}{\textbf{\CFA}}       & \multicolumn{1}{c}{\textbf{\CC}}      \\
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{\CC}}      \\
 \begin{lstlisting}
 int x = 0, y = 1, z = 2;

doc/working/resolver_design.md

-                      r6cbc25a
+                      r7ff30d07
 ## Conversion Costs ##
+Each possible resolution of an expression has a _cost_ consisting of four
+integer components: _unsafe_ conversion cost, _polymorphic_ specialization
+cost, _safe_ conversion cost, and a _count_ of conversions.
+These components form a lexically-ordered tuple which can be summed
+element-wise; summation starts at `(0, 0, 0, 0)`.
+Each possible resolution of an expression has a _cost_ tuple consisting of
+the following components: _unsafe_ conversion cost, _polymorphic_
+specialization cost, _safe_ conversion cost, a count of _explicit_
+conversions, and _qualifier_ conversion cost.
+These components are lexically-ordered and can be summed element-wise;
+summation starts at `(0, 0, 0, 0, 0)`.
 ### Lvalue and Qualifier Conversions ###
 …
 programmers.
+## Resolver Architecture ##
+### Function Application Resolution ###
+Our resolution algorithm for function application expressions is based on
+Baker's[3] single-pass bottom-up algorithm, with Cormack's[4] single-pass
+top-down algorithm applied where appropriate as an optimization.
+Broadly speaking, the cost of this resolution per expression will be
+proportional to `i^d`, where `i` is the number of interpretations of each
+program symbol, and `d` is the maximum depth of the expression DAG.
+Since `d` is determined by the user programmer (in general, bounded by a small
+constant), opportunities for resolver optimization primarily revolve around
+minimizing `i`, the number of interpretations of each symbol that are
+considered.
+[3] Baker, Theodore P. A one-pass algorithm for overload resolution in Ada.
+ACM Transactions on Programming Languages and Systems (1982) 4:4 p.601-614
+[4] Cormack, Gordon V. An algorithm for the selection of overloaded functions
+in Ada. SIGPLAN Notices (1981) 16:2 p.48-52
+Unlike Baker, our system allows implicit type conversions for function
+arguments and return types; the problem then becomes to find the valid
+interpretation for an expression that has the unique minimal conversion cost,
+if such exists.
+Interpretations can be produced both by overloaded names and implicit
+conversions applied to existing interpretations; we have proposals to reduce
+the number of interpretations considered from both sources.
+To simplify the problem for this discussion, we will consider application
+resolution restricted to a domain of functions applied to variables, possibly
+in a nested manner (e.g. `f( g( x ), y )`, where `x` and `y` are variables and
+`f` and `g` are functions), and possibly in a typed context such as a variable
+initialization (e.g. `int i = f( x );`); the other aspects of Cforall type
+resolution should be able to be straightforwardly mapped into this model.
+The types of the symbol tables used for variable and function declarations
+look somewhat like the following:
+        variable_table = name_map( variable_name, variable_map )
+        function_table = name_map( function_name, function_map )
+        variable_map = multi_index( by_type( variable_type ),
+                                    variable_decl_set )
+        function_map = multi_index( by_int( n_params ),
+                                                                by_type( return_type ),
+                                                                function_decl_set )
+`variable_name` and `function_name` are likely simple strings, with `name_map`
+a hash table (or perhaps trie) mapping string keys to values.
+`variable_decl_set` and `function_decl_set` can be thought of for the moment
+as simple bags of typed declarations, where the declaration types are linked
+to the graph of available conversions for that type.
+In a typed context both the `variable_decl_set` and the `function_decl_set`
+should be able to be selected upon by type; this is accomplished by the
+`by_type` index of both `variable_map` and `function_map`.
+The `by_int` index of `function_map` also provides a way to select functions
+by their number of parameters; this index may be used to swiftly discard any
+function declaration which does not have the appropriate number of parameters
+for the argument interpretations being passed to it; given the likely small
+number of entries in this map, it is possible that a binary search of a sorted
+vector or even a linear search of an unsorted vector would be more efficient
+than the usual hash-based index.
+Given these data structures, the general outline of our algorithm follows
+Baker, with Cormack's algorithm used as a heuristic filter in typed contexts.
+In an untyped context, we use a variant of Baker's bottom-up algorithm.
+The leaves of the interpretation DAG are drawn from the variable symbol table,
+with entries in the table each producing zero-cost interpretations, and each
+implicit conversion available to be applied to the type of an existing entry
+producing a further interpretation with the same cost as the conversion.
+As in Baker, if two or more interpretations have the same type, only the
+minimum cost interpretation with that type is produced; if there is no unique
+minimum cost interpretation than resolution with that type is ambiguous, and
+not permitted.
+It should be relatively simple to produce the list of interpretations sorted
+by cost by producing the interpretations via a breadth-first search of the
+conversion graph from the initial interpretations provided in the variable
+symbol table.
+To match a function at one of the internal nodes of the DAG, we first look up
+the function's name in the function symbol table, the appropriate number of
+parameters for the arguments that are provided through the `by_int` index of
+the returned `function_map`, then go through the resulting `function_decl_set`
+searching for functions where the parameter types can unify with the provided
+argument lists; any such matching function produces an interpretation with a
+cost that is the sum of its argument costs.
+Though this is not included in our simplified model, this unification step may
+include binding of polymorphic variables, which introduces a cost for the
+function binding itself which must be added to the argument costs.
+Also, checking of function assertions would likely be done at this step as
+well, possibly eliminating some possible matching functions (if no suitable
+assertions can be satisfied), or adding further conversion costs for the
+assertion satisfaction.
+Once the set of valid function interpretations is produced, these may also be
+expanded by the graph of implicit conversions on their return types, as the
+variable interpretations were.
+This implicit conversion-based expansion of interpretations should be skipped
+for the top-level expression if used in an untyped (void) context, e.g. for
+`f` in `f( g ( x ) );` or `x` in `x;`.
+On the other hand, if the top-level expression specifies a type, e.g. in
+`int i = f( x );`, only top level expressions that return that type are
+relevant to the search, so the candidates for `f` can be filtered first by
+those that return `int` (or a type convertable to it); this can be
+accomplished by performing a top-down filter of the interpretations of `f` by
+the `by_type` index of the `function_map` in a manner similar to Cormack's[4]
+algorithm.
+In a typed context, such as an initialization expression
+`T x = f( g( y ), z );`, only interpretations of `f( g( y ), z )` which have
+type `T` are valid; since there are likely to be valid interpretations of
+`f( g( y ), z )` which cannot be used to initialize a variable of type `T`, we
+can use this information to reduce the number of interpretations considered.
+Drawing from Cormack[4], we first search for interpretations of `f` where the
+return type is `T`; by breadth-first-search of the conversion graph, it should
+be straightforward to order the interpretations of `f` by the cost to convert
+their return type to `T`.
+We can also filter out interpretations of `f` with less than two parameters,
+since both `g( y )` and `z` must produce at least one parameter; we may not,
+however, rule out interpretations of `f` with more than two parameters, as
+there may be a valid interpretation of `g( y )` as a function returning more
+than one parameter (if the expression was `f( y, z )` instead, we could use an
+exact parameter count, assuming that variables of tuple type don't exist).
+For each compatible interpretation of `f`, we can add the type of the first
+parameter of that interpretation of `f` to a set `S`, and recursively search
+for interpretations of `g( y )` that return some type `Si` in `S`, and
+similarly for interpretations of `z` that match the type of any of the second
+parameters of some `f`.
+Naturally, if no matching interpretation of `g( y )` can be found for the
+first parameter of some `f`, the type of the second parameter of that `f` will
+not be added to the set of valid types for `z`.
+Each node in this interpretation DAG is given a cost the same way it would be
+in the bottom-up approach, with the exception that when going top-down there
+must be a final bottom-up pass to sum the interpretation costs and sort them
+as appropriate.
+If a parameter type for some `f` is a polymorphic type variable that is left
+unbound by the return type (e.g. `forall(otype S) int f(S x, int y)`), the
+matching arguments should be found using the bottom-up algorithm above for
+untyped contexts, because the polymorphic type variable does not sufficiently
+constrain the available interpretations of the argument expression.
+Similarly, it would likely be an advantage to use top-down resolution for
+cast expressions (e.g. `(int)x`), even when those cast expressions are
+subexpressions of an otherwise untyped expression.
+It may also be fruitful to switch between the bottom-up and top-down
+algorithms if the number of valid interpretations for a subexpression or valid
+types for an argument exceeds some heuristic threshold, but finding such
+a threshold (if any exists) will require experimental data.
+This hybrid top-down/bottom-up search provides more opportunities for pruning
+interpretations than either a bottom-up or top-down approach alone, and thus
+may be more efficient than either.
+A top-down-only approach, however, devolves to linear search through every
+possible interpretation in the solution space in an untyped context, and is
+thus likely to be inferior to a strictly bottom-up approach, though this
+hypothesis needs to be empirically validated.
+Both Baker and Cormack explicitly generate all possible interpretations of a
+given expression; thinking of the set of interpretations of an expression as a
+list sorted by cost, this is an eager evaluation of the list.
+However, since we generally expect that user programmers will not often use
+high-cost implicit conversions, one potentially effective way to prune the
+search space would be to first find the minimal-cost interpretations of any
+given subexpression, then to save the resolution progress of the
+subexpressions and attempt to resolve the superexpression using only those
+subexpression interpretations.
+If no valid interpretation of the superexpression can be found, the resolver
+would then repeatedly find the next-most-minimal cost interpretations of the
+subexpressions and attempt to produce the minimal cost interpretation of the
+superexpression.
+This process would proceed until all possible subexpression interpretations
+have been found and considered.
+A middle ground between the eager and lazy approaches can be taken by
+considering the lexical order on the cost tuple; essentially, every
+interpretation in each of the classes below will be strictly cheaper than any
+interpretation in the class after it, so if a min-cost valid interpretation
+can be found while only generating interpretations in a given class, that
+interpretation is guaranteed to be the best possible one:
+. Interpretations without polymorphic functions or implicit conversions
+. Interpretations without polymorphic functions using only safe conversions
+. Interpretations using polymorphic functions without unsafe conversions
+. Interpretations using unsafe conversions
+In this lazy-eager approach, all the interpretations in one class would be
+eagerly generated, while the interpretations in the next class would only be
+considered if no match was found in the previous class.
 ## Appendix A: Partial and Total Orders ##
 The `<=` relation on integers is a commonly known _total order_, and

src/CodeGen/CodeGenerator.cc

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Fri May 06 16:01:00 2016
 // Update Count     : 255
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Thu Jun  9 13:21:00 2016
+// Update Count     : 256
 //
 …
         //*** Expressions
         void CodeGenerator::visit( ApplicationExpr *applicationExpr ) {
+                extension( applicationExpr );
                 if ( VariableExpr *varExpr = dynamic_cast< VariableExpr* >( applicationExpr->get_function() ) ) {
                         OperatorInfo opInfo;
 …
         void CodeGenerator::visit( UntypedExpr *untypedExpr ) {
+                extension( untypedExpr );
                 if ( NameExpr *nameExpr = dynamic_cast< NameExpr* >( untypedExpr->get_function() ) ) {
                         OperatorInfo opInfo;
 …
         void CodeGenerator::visit( NameExpr *nameExpr ) {
+                extension( nameExpr );
                 OperatorInfo opInfo;
                 if ( operatorLookup( nameExpr->get_name(), opInfo ) ) {
 …
         void CodeGenerator::visit( AddressExpr *addressExpr ) {
+                extension( addressExpr );
                 output << "(&";
                 // this hack makes sure that we don't convert "constant_zero" to "0" if we're taking its address
 …
         void CodeGenerator::visit( CastExpr *castExpr ) {
+                extension( castExpr );
                 output << "(";
                 if ( castExpr->get_results().empty() ) {
 …
         void CodeGenerator::visit( MemberExpr *memberExpr ) {
+                extension( memberExpr );
                 memberExpr->get_aggregate()->accept( *this );
                 output << "." << mangleName( memberExpr->get_member() );
 …
         void CodeGenerator::visit( VariableExpr *variableExpr ) {
+                extension( variableExpr );
                 OperatorInfo opInfo;
                 if ( variableExpr->get_var()->get_linkage() == LinkageSpec::Intrinsic && operatorLookup( variableExpr->get_var()->get_name(), opInfo ) && opInfo.type == OT_CONSTANT ) {
 …
         void CodeGenerator::visit( ConstantExpr *constantExpr ) {
                 assert( constantExpr->get_constant() );
+                extension( constantExpr );
                 constantExpr->get_constant()->accept( *this );
+        }
         void CodeGenerator::visit( SizeofExpr *sizeofExpr ) {
+                extension( sizeofExpr );
                 output << "sizeof(";
                 if ( sizeofExpr->get_isType() ) {
 …
         void CodeGenerator::visit( AlignofExpr *alignofExpr ) {
+                extension( alignofExpr );
                 // use GCC extension to avoid bumping std to C11
                 output << "__alignof__(";
 …
         void CodeGenerator::visit( OffsetofExpr *offsetofExpr ) {
+                extension( offsetofExpr );
                 // use GCC builtin
                 output << "__builtin_offsetof(";
 …
         void CodeGenerator::visit( LogicalExpr *logicalExpr ) {
+                extension( logicalExpr );
                 output << "(";
                 logicalExpr->get_arg1()->accept( *this );
 …
         void CodeGenerator::visit( ConditionalExpr *conditionalExpr ) {
+                extension( conditionalExpr );
                 output << "(";
                 conditionalExpr->get_arg1()->accept( *this );
 …
         void CodeGenerator::visit( CommaExpr *commaExpr ) {
+                extension( commaExpr );
                 output << "(";
                 commaExpr->get_arg1()->accept( *this );
 …
         void CodeGenerator::visit( AsmExpr *asmExpr ) {
+                extension( asmExpr );
                 if ( asmExpr->get_inout() ) {
                         output << "[ ";

src/CodeGen/CodeGenerator.h

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Wed Mar  2 17:32:24 2016
 // Update Count     : 28
+// Last Modified On : Thu Jun  9 13:15:58 2016
+// Update Count     : 29
 //
 …
                         std::ostream& operator()(std::ostream & os);
                 };
+                void extension( Expression *expr ) {
+                        if ( expr->get_extension() ) {
+                                output << "__extension__ ";
+                        } // if
+                } // extension
           private:

src/Common/utility.h

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Thu Apr 28 13:18:24 2016
 // Update Count     : 16
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Wed Jun  8 17:33:59 2016
+// Update Count     : 22
 //
 …
+}
+template<typename T, typename U>
+struct maybeBuild_t {
+        static T * doit( const U *orig ) {
+                if ( orig ) {
+                        return orig->build();
+                } else {
+                        return 0;
+                } // if
+        }
+};
 template< typename T, typename U >
 static inline T * maybeBuild( const U *orig ) {
+        if ( orig ) {
+                return orig->build();
+        } else {
+                return 0;
+        } // if
+        return maybeBuild_t<T,U>::doit(orig);
+}

src/Parser/ExpressionNode.cc

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Sat May 16 13:17:07 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Fri Apr  8 15:43:05 2016
 // Update Count     : 296
+// Last Modified On : Mon Jun 13 14:46:17 2016
+// Update Count     : 307
 //
 …
 using namespace std;
 ExpressionNode::ExpressionNode() : ParseNode(), argName( 0 ) {}
 ExpressionNode::ExpressionNode( const string *name ) : ParseNode( name ), argName( 0 ) {}
 ExpressionNode::ExpressionNode( const ExpressionNode &other ) : ParseNode( other.name ) {
+ExpressionNode::ExpressionNode() : ParseNode() {}
+ExpressionNode::ExpressionNode( const string *name ) : ParseNode( name ) {}
+ExpressionNode::ExpressionNode( const ExpressionNode &other ) : ParseNode( other.name ), extension( other.extension ) {
         if ( other.argName ) {
                 argName = other.argName->clone();
 …
 Expression *DesignatorNode::build() const {
         Expression * ret = get_argName()->build();
+        Expression * ret = maybeBuild<Expression>(get_argName());
         if ( isArrayIndex ) {
 …
         "Cond", "NCond",
         // diadic
         "SizeOf", "AlignOf", "OffsetOf", "Attr", "CompLit", "?+?", "?-?", "?*?", "?/?", "?%?", "||", "&&",
+        "SizeOf", "AlignOf", "OffsetOf", "Attr", "?+?", "?-?", "?*?", "?/?", "?%?", "||", "&&",
         "?|?", "?&?", "?^?", "Cast", "?<<?", "?>>?", "?<?", "?>?", "?<=?", "?>=?", "?==?", "?!=?",
         "?=?", "?*=?", "?/=?", "?%=?", "?+=?", "?-=?", "?<<=?", "?>>=?", "?&=?", "?^=?", "?|=?",
 …
         if ( ! ( op = dynamic_cast<OperatorNode *>( function ) ) ) { // function as opposed to operator
                 return new UntypedExpr( function->build(), args, maybeBuild< Expression >( get_argName() ));
+                return new UntypedExpr( maybeBuild<Expression>(function), args, maybeBuild< Expression >( get_argName() ));
         } // if
 …
                         if ( dynamic_cast< VoidType* >( targetType ) ) {
                                 delete targetType;
                                 return new CastExpr( expr_node->build(), maybeBuild< Expression >( get_argName() ) );
+                                return new CastExpr( maybeBuild<Expression>(expr_node), maybeBuild< Expression >( get_argName() ) );
                         } else {
                                 return new CastExpr( expr_node->build(),targetType, maybeBuild< Expression >( get_argName() ) );
+                                return new CastExpr( maybeBuild<Expression>(expr_node),targetType, maybeBuild< Expression >( get_argName() ) );
                         } // if
+                }
 …
                         assert( var );
                         if ( ! get_args()->get_link() ) {
                                 return new AttrExpr( var->build(), ( Expression*)0);
+                                return new AttrExpr( maybeBuild<Expression>(var), ( Expression*)0);
                         } else if ( TypeValueNode * arg = dynamic_cast<TypeValueNode *>( get_args()->get_link()) ) {
                                 return new AttrExpr( var->build(), arg->get_decl()->buildType());
+                                return new AttrExpr( maybeBuild<Expression>(var), arg->get_decl()->buildType());
                         } else {
+                                return new AttrExpr( var->build(), args.back());
+                        } // if
+                }
+          case OperatorNode::CompLit:
+                throw UnimplementedError( "C99 compound literals" );
+                // the short-circuited operators
+                                return new AttrExpr( maybeBuild<Expression>(var), args.back());
+                        } // if
+                }
           case OperatorNode::Or:
           case OperatorNode::And:
 …
 Expression *AsmExprNode::build() const {
         return new AsmExpr( maybeBuild< Expression >( inout ), (ConstantExpr *)constraint->build(), operand->build() );
+        return new AsmExpr( maybeBuild< Expression >( inout ), (ConstantExpr *)maybeBuild<Expression>(constraint), maybeBuild<Expression>(operand) );
+}
 …
 Expression *ValofExprNode::build() const {
         return new UntypedValofExpr ( get_body()->build(), maybeBuild< Expression >( get_argName() ) );
+        return new UntypedValofExpr ( maybeBuild<Statement>(get_body()), maybeBuild< Expression >( get_argName() ) );
+}
 …
 Expression *CompoundLiteralNode::build() const {
         Declaration * newDecl = type->build();                          // compound literal type
+        Declaration * newDecl = maybeBuild<Declaration>(type); // compound literal type
         if ( DeclarationWithType * newDeclWithType = dynamic_cast< DeclarationWithType * >( newDecl ) ) { // non-sue compound-literal type
                 return new CompoundLiteralExpr( newDeclWithType->get_type(), kids->build() );
+                return new CompoundLiteralExpr( newDeclWithType->get_type(), maybeBuild<Initializer>(kids) );
         // these types do not have associated type information
         } else if ( StructDecl * newDeclStructDecl = dynamic_cast< StructDecl * >( newDecl )  ) {
                 return new CompoundLiteralExpr( new StructInstType( Type::Qualifiers(), newDeclStructDecl->get_name() ), kids->build() );
+                return new CompoundLiteralExpr( new StructInstType( Type::Qualifiers(), newDeclStructDecl->get_name() ), maybeBuild<Initializer>(kids) );
         } else if ( UnionDecl * newDeclUnionDecl = dynamic_cast< UnionDecl * >( newDecl )  ) {
                 return new CompoundLiteralExpr( new UnionInstType( Type::Qualifiers(), newDeclUnionDecl->get_name() ), kids->build() );
+                return new CompoundLiteralExpr( new UnionInstType( Type::Qualifiers(), newDeclUnionDecl->get_name() ), maybeBuild<Initializer>(kids) );
         } else if ( EnumDecl * newDeclEnumDecl = dynamic_cast< EnumDecl * >( newDecl )  ) {
                 return new CompoundLiteralExpr( new EnumInstType( Type::Qualifiers(), newDeclEnumDecl->get_name() ), kids->build() );
+                return new CompoundLiteralExpr( new EnumInstType( Type::Qualifiers(), newDeclEnumDecl->get_name() ), maybeBuild<Initializer>(kids) );
         } else {
                 assert( false );

src/Parser/ParseNode.h

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Rodolfo G. Esteves
 // Created On       : Sat May 16 13:28:16 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Thu Apr 14 15:37:52 2016
 // Update Count     : 205
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Mon Jun 13 16:04:47 2016
+// Update Count     : 240
 //
 …
 #include <list>
 #include <iterator>
+#include <memory>
 #include "Common/utility.h"
 #include "Parser/LinkageSpec.h"
 #include "SynTree/Type.h"
+#include "SynTree/Expression.h"
 //#include "SynTree/Declaration.h"
 #include "Common/UniqueName.h"
 …
         ExpressionNode *set_argName( const std::string *aName );
         ExpressionNode *set_argName( ExpressionNode *aDesignator );
+        bool get_extension() const { return extension; }
+        ExpressionNode *set_extension( bool exten ) { extension = exten; return this; }
         virtual void print( std::ostream &, int indent = 0) const = 0;
 …
         void printDesignation ( std::ostream &, int indent = 0) const;
   private:
+        ExpressionNode *argName;
+        ExpressionNode *argName = 0;
+        bool extension = false;
+};
+template< typename T >
+struct maybeBuild_t<Expression, T> {
+        static inline Expression * doit( const T *orig ) {
+                if ( orig ) {
+                        Expression *p = orig->build();
+                        p->set_extension( orig->get_extension() );
+                        return p;
+                } else {
+                        return 0;
+                } // if
+        }
 };
 …
                                 Cond, NCond,
                                 // diadic
                                 SizeOf, AlignOf, OffsetOf, Attr, CompLit, Plus, Minus, Mul, Div, Mod, Or, And,
+                                SizeOf, AlignOf, OffsetOf, Attr, Plus, Minus, Mul, Div, Mod, Or, And,
                                 BitOr, BitAnd, Xor, Cast, LShift, RShift, LThan, GThan, LEThan, GEThan, Eq, Neq,
                                 Assign, MulAssn, DivAssn, ModAssn, PlusAssn, MinusAssn, LSAssn, RSAssn, AndAssn, ERAssn, OrAssn,
 …
         while ( cur ) {
                 try {
+                        SynTreeType *result = dynamic_cast< SynTreeType *>( cur->build() );
+//                      SynTreeType *result = dynamic_cast< SynTreeType *>( maybeBuild<typename std::result_of<decltype(&NodeType::build)(NodeType)>::type>( cur ) );
+                        SynTreeType *result = dynamic_cast< SynTreeType *>( maybeBuild<typename std::pointer_traits<decltype(cur->build())>::element_type>( cur ) );
                         if ( result ) {
                                 *out++ = result;

src/Parser/StatementNode.cc

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Sat May 16 14:59:41 2015
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Jul 30 14:39:39 2015
 // Update Count     : 130
+// Last Modified On : Thu Jun  9 14:18:46 2016
+// Update Count     : 132
 //
 …
                                 branches.pop_front();
                         } // if
                         return new IfStmt( labs, notZeroExpr( get_control()->build() ), thenb, elseb );
+                        return new IfStmt( labs, notZeroExpr( maybeBuild<Expression>(get_control()) ), thenb, elseb );
+                }
           case While:
                 assert( branches.size() == 1 );
                 return new WhileStmt( labs, notZeroExpr( get_control()->build() ), branches.front() );
+                return new WhileStmt( labs, notZeroExpr( maybeBuild<Expression>(get_control()) ), branches.front() );
           case Do:
                 assert( branches.size() == 1 );
                 return new WhileStmt( labs, notZeroExpr( get_control()->build() ), branches.front(), true );
+                return new WhileStmt( labs, notZeroExpr( maybeBuild<Expression>(get_control()) ), branches.front(), true );
           case For:
+                {
 …
                         Expression *cond = 0;
                         if ( ctl->get_condition() != 0 )
                                 cond = notZeroExpr( ctl->get_condition()->build() );
+                                cond = notZeroExpr( maybeBuild<Expression>(ctl->get_condition()) );
                         Expression *incr = 0;
                         if ( ctl->get_change() != 0 )
                                 incr = ctl->get_change()->build();
+                                incr = maybeBuild<Expression>(ctl->get_change());
                         return new ForStmt( labs, init, cond, incr, branches.front() );
+                }
           case Switch:
                 return new SwitchStmt( labs, get_control()->build(), branches );
+                return new SwitchStmt( labs, maybeBuild<Expression>(get_control()), branches );
           case Choose:
                 return new ChooseStmt( labs, get_control()->build(), branches );
+                return new ChooseStmt( labs, maybeBuild<Expression>(get_control()), branches );
           case Fallthru:
                 return new FallthruStmt( labs );
           case Case:
                 return new CaseStmt( labs, get_control()->build(), branches );
+                return new CaseStmt( labs, maybeBuild<Expression>(get_control()), branches );
           case Default:
                 return new CaseStmt( labs, 0, branches, true );
 …
                         if ( get_target() == "" ) {                                     // computed goto
                                 assert( get_control() != 0 );
                                 return new BranchStmt( labs, get_control()->build(), BranchStmt::Goto );
+                                return new BranchStmt( labs, maybeBuild<Expression>(get_control()), BranchStmt::Goto );
                         } // if

src/Parser/parser.cc

-                      r6cbc25a
+                      r7ff30d07
 /* Line 1806 of yacc.c  */
 #line 432 "parser.yy"
     { (yyval.en) = (yyvsp[(2) - (2)].en); }
+    { (yyval.en) = (yyvsp[(2) - (2)].en)->set_extension( true ); }
     break;
 …
 /* Line 1806 of yacc.c  */
 #line 685 "parser.yy"
     { (yyval.sn) = new StatementNode( (yyvsp[(2) - (2)].decl) ); }
+    { (yyval.sn) = new StatementNode( (yyvsp[(2) - (2)].decl) )/*->set_extension( true )*/; }
     break;
 …
 /* Line 1806 of yacc.c  */
 #line 1475 "parser.yy"
     { (yyval.decl) = (yyvsp[(2) - (3)].decl); }
+    { (yyval.decl) = (yyvsp[(2) - (3)].decl)/*->set_extension( true )*/; }
     break;
 …
 /* Line 1806 of yacc.c  */
 #line 1478 "parser.yy"
     { (yyval.decl) = (yyvsp[(2) - (3)].decl); }
+    { (yyval.decl) = (yyvsp[(2) - (3)].decl)/*->set_extension( true )*/; }
     break;
 …
 /* Line 1806 of yacc.c  */
 #line 1994 "parser.yy"
     { (yyval.decl) = (yyvsp[(2) - (2)].decl); }
+    { (yyval.decl) = (yyvsp[(2) - (2)].decl)/*->set_extension( true )*/; }
     break;

src/Parser/parser.yy

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Sat Sep  1 20:22:55 2001
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Tue Jun  7 08:08:31 2016
 // Update Count     : 1560
+// Last Modified On : Mon Jun 13 15:00:23 2016
+// Update Count     : 1578
 //
 …
                 { $$ = $1; }
         | EXTENSION cast_expression                                                     // GCC
                 { $$ = $2; }
+                { $$ = $2->set_extension( true ); }
         | ptrref_operator cast_expression                                       // CFA
                 { $$ = new CompositeExprNode( $1, $2 ); }
 …
                 { $$ = new StatementNode( $1 ); }
         | EXTENSION declaration                                                         // GCC
                 { $$ = new StatementNode( $2 ); }
+                { $$ = new StatementNode( $2 )/*->set_extension( true )*/; }
         | function_definition
                 { $$ = new StatementNode( $1 ); }
 …
         new_field_declaring_list ';'                                            // CFA, new style field declaration
         | EXTENSION new_field_declaring_list ';'                        // GCC
                 { $$ = $2; }
+                { $$ = $2/*->set_extension( true )*/; }
         | field_declaring_list ';'
         | EXTENSION field_declaring_list ';'                            // GCC
                 { $$ = $2; }
+                { $$ = $2/*->set_extension( true )*/; }
+        ;
 …
+                }
         | EXTENSION external_definition
                 { $$ = $2; }
+                { $$ = $2/*->set_extension( true )*/; }
+        ;

src/ResolvExpr/AlternativeFinder.cc

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Richard C. Bilson
 // Created On       : Sat May 16 23:52:08 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Wed Apr 20 14:24:03 2016
 // Update Count     : 24
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Mon Jun 13 16:13:54 2016
+// Update Count     : 25
 //
 …
                 for ( std::list< DeclarationWithType* >::iterator i = declList.begin(); i != declList.end(); ++i ) {
                         VariableExpr newExpr( *i, nameExpr->get_argName() );
+                        newExpr.set_extension( nameExpr->get_extension() );
                         alternatives.push_back( Alternative( newExpr.clone(), env, Cost() ) );
                         PRINT(

src/SynTree/Expression.cc

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Fri May 13 13:23:11 2016
 // Update Count     : 40
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Mon Jun 13 16:03:39 2016
+// Update Count     : 42
 //
 …
 Expression::Expression( Expression *_aname ) : env( 0 ), argName( _aname ) {}
 Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ), argName( maybeClone( other.get_argName() ) ) {
+Expression::Expression( const Expression &other ) : env( maybeClone( other.env ) ), argName( maybeClone( other.get_argName() ) ), extension( other.extension ) {
         cloneAll( other.results, results );
+}
 …
                 os << std::string( indent, ' ' ) << "with designator:";
                 argName->print( os, indent+2 );
+        } // if
+        if ( extension ) {
+                os << std::string( indent, ' ' ) << "with extension:";
         } // if
+}

src/SynTree/Expression.h

-                      r6cbc25a
+                      r7ff30d07
 // Author           : Richard C. Bilson
 // Created On       : Mon May 18 07:44:20 2015
 // Last Modified By : Rob Schluntz
 // Last Modified On : Wed Apr 27 17:06:49 2016
 // Update Count     : 21
+// Last Modified By : Peter A. Buhr
+// Last Modified On : Wed Jun  8 17:05:30 2016
+// Update Count     : 22
 //
 …
         Expression *get_argName() const { return argName; }
         void set_argName( Expression *name ) { argName = name; }
+        bool get_extension() const { return extension; }
+        void set_extension( bool exten ) { extension = exten; }
         virtual Expression *clone() const = 0;
 …
         TypeSubstitution *env;
         Expression* argName; // if expression is used as an argument, it can be "designated" by this name
+        bool extension = false;
 };

src/Tests/Abstype.c

-                      r6cbc25a
+                      r7ff30d07
 type T | { T x( T ); };
+otype T | { T x( T ); };
 T y( T t ) {
 …
+}
 forall( type T ) lvalue T *?( T * );
+forall( otype T ) lvalue T *?( T * );
 int ?++( int * );
 int ?=?( int *, int );
 forall( dtype DT ) DT * ?=?( DT **, DT * );
 type U = int *;
+otype U = int *;
 U x( U u ) {

src/Tests/Attributes.c

-                      r6cbc25a
+                      r7ff30d07
 //    @max
 //
 // 2. a direct application to a manifest type
+// 2. a direct application to a manifest otype
 //
 //    @max( int )
 //
 // 3. constraining a type variable; the application is implicitly performed at the call site as in (2)
+// 3. constraining a otype variable; the application is implicitly performed at the call site as in (2)
 //
 //    forall( type T | { T @max( T ); } ) T x( T t );
+//    forall( otype T | { T @max( T ); } ) T x( T t );
 //
 //
 …
 //    x = (*attr_var);
 //
 // 2. an indirect application to a manifest type
+// 2. an indirect application to a manifest otype
 //
 //    (*attr_var)( int )
 //
 // 3. a direct application to a type variable
+// 3. a direct application to a otype variable
 //
 //    @max( T )
 …
 // 3. polymorphic
 //
 //    forall( type T | constraint( T ) ) int @attr( T );
+//    forall( otype T | constraint( T ) ) int @attr( T );
 int @max = 3;
 …
 int main() {
     int x;
     type @type(type t);                                                                 // compiler intrinsic
     type @widest(type t);
     @type(x) *y;                                                                                // gcc: typeof(x) *y;
     const @widest(double) *w;                                                   // gcc: const typeof(x) *w;
     * @type(3 + 4) z;                                                                   // cfa declaration syntax
+    otype @otype(otype t);                                                                      // compiler intrinsic
+    otype @widest(otype t);
+    @otype(x) *y;                                                                               // gcc: otypeof(x) *y;
+    const @widest(double) *w;                                                   // gcc: const otypeof(x) *w;
+    * @otype(3 + 4) z;                                                                  // cfa declaration syntax
     y = @max;
     z = @max(x) + @size(int);

src/Tests/InferParam.c

-                      r6cbc25a
+                      r7ff30d07
 double ?=?( double*, double );
 forall( type T, type U | { U f(T); } ) U g(T);
+forall( otype T, otype U | { U f(T); } ) U g(T);
 float f( int );
 double f( int );
 …
+}
 context has_f_and_j( type T, type U ) {
+context has_f_and_j( otype T, otype U ) {
         U f( T );
         U j( T, U );
 …
 float j( int, float );
 forall( type T, type U | has_f_and_j( T, U ) ) U k( T );
+forall( otype T, otype U | has_f_and_j( T, U ) ) U k( T );
 void l() {

src/Tests/Makefile

-                      r6cbc25a
+                      r7ff30d07
 CFA ?= ../cfa-cpp
+CFA ?= ../driver/cfa-cpp
 CFAOPT ?= -a
 OUTPUT ?= Output
 …
 ${OUTPUTDIR} :
         mkdir $@
+        mkdir -p $@
 # remove the expected results directories to generate new ones from the current output

src/Tests/Members.c

r6cbc25a	r7ff30d07
3	3	float ?=?( float*, float );
4	4	forall( dtype DT ) DT * ?=?( DT*, DT );
5		forall(type T) lvalue T ?( T );
	5	forall(otype T) lvalue T ?( T );
6	6	char *__builtin_memcpy();
7	7

src/Tests/OccursError.c

r6cbc25a	r7ff30d07
1		forall( type T ) void f( void ()( T, T ) );
2		forall( type U ) void g( U*, U );
	1	forall( otype T ) void f( void ()( T, T ) );
	2	forall( otype U ) void g( U*, U );
3	3
4	4	void test() {

src/Tests/Quad.c

-                      r6cbc25a
+                      r7ff30d07
 int ?*?( int, int );
 forall( type T | { T ?*?( T, T ); } )
+forall( otype T | { T ?*?( T, T ); } )
 T square( T t ) {
         return t * t;
+}
 forall( type U | { U square( U ); } )
+forall( otype U | { U square( U ); } )
 U quad( U u ) {
         return square( square( u ) );

src/Tests/Rank2.c

-                      r6cbc25a
+                      r7ff30d07
 void a() {
         forall( type T ) void f( T );
         void g( forall( type U ) void p( U ) );
+        forall( otype T ) void f( T );
+        void g( forall( otype U ) void p( U ) );
         g( f );
+}
 …
 void g() {
         void h( int *null );
         forall( type T ) T id( T );
+        forall( otype T ) T id( T );
         forall( dtype T ) T *0;
         int 0;

src/driver/cc1.cc

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Fri Aug 26 14:23:51 2005
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Jun  2 17:24:26 2016
 // Update Count     : 79
+// Last Modified On : Fri Jun 10 09:27:37 2016
+// Update Count     : 80
 //
 …
                                 i += 1;                                                                 // and the argument
                                 cpp_flag = true;
                         } else if ( arg == "-D__CFA__" ) {
+                        } else if ( arg == "-D__CFA_PREPROCESS__" ) {
                                 CFA_flag = true;
                         } else if ( arg == "-D" && string( argv[i + 1] ) == "__CFA__" ) {
+                        } else if ( arg == "-D" && string( argv[i + 1] ) == "__CFA_PREPROCESS__" ) {
                                 i += 1;                                                                 // and the argument
                                 CFA_flag = true;

src/driver/cfa.cc

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Tue Aug 20 13:44:49 2002
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu Jun  2 17:24:25 2016
 // Update Count     : 137
+// Last Modified On : Fri Jun 10 09:26:19 2016
+// Update Count     : 138
 //
 …
         args[nargs] = ( *new string( string("-D__CFA_PATCHLEVEL__=") + Patch ) ).c_str();
         nargs += 1;
+        args[nargs] = "-D__CFORALL__=1";
+        args[nargs] = "-D__CFA__";
+        nargs += 1;
+        args[nargs] = "-D__CFORALL__";
         nargs += 1;
 …
         if ( CFA_flag ) {
                 args[nargs] = "-D__CFA__";
+                args[nargs] = "-D__CFA_PREPROCESS_";
                 nargs += 1;
         } // if

src/libcfa/Makefile.am

-                      r6cbc25a
+                      r7ff30d07
 ## Created On       : Sun May 31 08:54:01 2015
 ## Last Modified By : Peter A. Buhr
 ## Last Modified On : Wed Jun  8 14:20:34 2016
 ## Update Count     : 165
+## Last Modified On : Mon Jun 13 14:27:22 2016
+## Update Count     : 166
 ###############################################################################
 …
         @BACKEND_CC@ -c -o $@ $<
 CFLAGS = -g -Wall -Wno-unused-function -B${abs_top_srcdir}/src/driver -XCFA -t  # TEMPORARY: does not build with -O2
+CFLAGS = -quiet -g -Wall -Wno-unused-function -B${abs_top_srcdir}/src/driver -XCFA -t  # TEMPORARY: does not build with -O2
 CC = ${abs_top_srcdir}/src/driver/cfa

src/tests/Array.c

-                      r6cbc25a
+                      r7ff30d07
 //Testing array declarations
 int a1[];
 int a2[*];
 double a4[3.0];
+//int a2[*];
+//double a4[3.0];
 int m1[][3];
 int m2[*][*];
+//int m2[*][*];
 int m4[3][3];
 …
 int fred() {
         int a1[];
         int a2[*];
+//      int a1[];
+//      int a2[*];
         int a4[3];
         int T[3];

src/tests/Forall.c

-                      r6cbc25a
+                      r7ff30d07
 void g1() {
         forall( type T ) T f( T );
+        forall( otype T ) T f( T );
         void f( int );
         void h( void (*p)(void) );
 …
 void g2() {
         forall( type T ) void f( T, T );
         forall( type T, type U ) void f( T, U );
+        forall( otype T ) void f( T, T );
+        forall( otype T, otype U ) void f( T, U );
         int x;
 …
+}
 typedef forall ( type T ) int (*f)( int );
+typedef forall ( otype T ) int (*f)( int );
 forall( type T )
+forall( otype T )
 void swap( T left, T right ) {
         T temp = left;
 …
+}
 context sumable( type T ) {
+context sumable( otype T ) {
         const T 0;
         T ?+?(T, T);
 …
 };
 type T1 | { const T1 0; T1 ?+?(T1, T1); T1 ?++(T1); [T1] ?+=?(T1,T1); },
         T2(type P1, type P2 ),
+otype T1 | { const T1 0; T1 ?+?(T1, T1); T1 ?++(T1); [T1] ?+=?(T1,T1); },
+        T2(otype P1, otype P2 ),
         T3 | sumable(T3);
 type T2(type P1, type P2) | sumable(T2(P1,P2)) = struct { P1 i; P2 j; };
+otype T2(otype P1, otype P2) | sumable(T2(P1,P2)) = struct { P1 i; P2 j; };
 T2(int, int) w1;
 typedef T2(int, int) w2;
 w2 g2;
 type w3 = T2(int, int);
+otype w3 = T2(int, int);
 w3 g3;
 forall( type T | sumable( T ) )
+forall( otype T | sumable( T ) )
 T sum( int n, T a[] ) {
         T total = 0;
 …
+}
 forall( type T | { const T 0; T ?+?(T, T); T ?++(T); [T] ?+=?(T,T); } )
+forall( otype T | { const T 0; T ?+?(T, T); T ?++(T); [T] ?+=?(T,T); } )
 T twice( T t ) {
         return t + t;
+}
 forall( type T | { const T 0; int ?!=?(T, T); int ?<?(T, T); } )
+forall( otype T | { const T 0; int ?!=?(T, T); int ?<?(T, T); } )
 T min( T t1, T t2 ) {
         return t1 < t2 ? t1 : t2;

src/tests/Functions.c

r6cbc25a	r7ff30d07
28	28	int ((*f12())[])[3] {}
29	29
30		// "implicit int" type specifier (not ANSI)
	30	// "implicit int" otype specifier (not ANSI)
31	31
32	32	fII1( int i ) {}

src/tests/GccExtensions.c

-                      r6cbc25a
+                      r7ff30d07
     __signed s2;
     __typeof(s1) t1;
     __typeof__(s1) t2;
+    __otypeof(s1) t1;
+    __otypeof__(s1) t2;
     __volatile int v1;

src/tests/Scope.c

-                      r6cbc25a
+                      r7ff30d07
 typedef float t;
 y z;
 type u = struct { int a; double b; };
+otype u = struct { int a; double b; };
 int f( int y );
 y q;
 y w( y y, u v ) {
         type x | { x t(u); };
+        otype x | { x t(u); };
         u u = y;
         x z = t(u);
 …
 y p;
 context has_u( type z ) {
+context has_u( otype z ) {
         z u(z);
 };
 forall( type t | has_u( t ) )
+forall( otype t | has_u( t ) )
 y q( t the_t ) {
         t y = u( the_t );

src/tests/Subrange.c

-                      r6cbc25a
+                      r7ff30d07
 // A small context defining the notion of an ordered type.  (The standard
+// A small context defining the notion of an ordered otype.  (The standard
 // library should probably contain a context for this purpose.)
 context ordered(type T) {
+context ordered(otype T) {
     int ?<?(T, T), ?<=?(T, T);
 };
 // A subrange type resembling an Ada subtype with a base type and a range
+// A subrange otype resembling an Ada subotype with a base otype and a range
 // constraint.
 type subrange(type base_t | ordered(base_t), base_t low = 0, base_t high = 8) = base_t;
+otype subrange(otype base_t | ordered(base_t), base_t low = 0, base_t high = 8) = base_t;
 // Note that subrange() can be applied to floating-point and pointer types, not
 // just integral types.
 //   This requires a "type generator" extension to Cforall.  Type generators
 // must accept type and non-type parameters, which is beyond what we discussed
+// Note that subrange() can be applied to floating-point and pointer otypes, not
+// just integral otypes.
+//   This requires a "otype generator" extension to Cforall.  Type generators
+// must accept otype and non-otype parameters, which is beyond what we discussed
 // previously.  Type parameters must be usable in the declaration of
 // subsequent parameters: parameter T is used to declare parameters "low"
 …
 subrange(int, 0, (rand() & 0xF) ) foo;
 // What sorts of expressions can be used as arguments of type generators?  Is
+// What sorts of expressions can be used as arguments of otype generators?  Is
 // "subrange(int, 0, rand() & 0xF)" legal?  Probably.  The nearest C equivalent
 // to the "low" and "high" arguments is the array size in a variable-length
 …
 // Convenient access to subrange bounds, for instance for iteration:
 forall (type T, T low, T high)
+forall (otype T, T low, T high)
 T lbound( subrange(T, low, high) v) {
     return low;
+}
 forall (type T, T low, T high)
+forall (otype T, T low, T high)
 T hbound( subrange(T, low, high) v) {
     return high;
 …
 unsigned lday = lbound(day_of_month);
 // Assignment from the base type, with bounds checking.  I'll ignore the issue
+// Assignment from the base otype, with bounds checking.  I'll ignore the issue
 // of exception handling here.  Inlining allows the compiler to eliminate
 // bounds checks.
 forall (type T | ordered(T), T low, T high)
+forall (otype T | ordered(T), T low, T high)
 inline subrange(T, low, high) ?=?(subrange(T, low, high)* target, T source) {
     if (low <= source && source <= high) *((T*)target) = source;
 …
+}
 // Assignment between subranges with a common base type.  The bounds check
+// Assignment between subranges with a common base otype.  The bounds check
 // compares range bounds so that the compiler can optimize checks away when the
 // ranges are known to overlap.
 forall (type T | ordered(T), T t_low, T t_high, T s_low, T s_high)
+forall (otype T | ordered(T), T t_low, T t_high, T s_low, T s_high)
 inline subrange(T, t_low, t_high) ?=?(subrange(T, t_low, t_high)* target,
                                       subrange(T, s_low, s_high) source) {

src/tests/TypeGenerator.c

-                      r6cbc25a
+                      r7ff30d07
 context addable( type T ) {
+context addable( otype T ) {
         T ?+?( T,T );
         T ?=?( T*, T);
 };
 type List1( type T | addable( T ) ) = struct { T data; List1( T ) *next; } *;
+otype List1( otype T | addable( T ) ) = struct { T data; List1( T ) *next; } *;
 typedef List1( int ) ListOfIntegers;
 //List1( int ) li;
 …
 [int] h( * List1( int ) p );                                                    // new declaration syntax
 struct( type T ) S2 { T i; };                                                   // actual definition
+struct( otype T ) S2 { T i; };                                                  // actual definition
 struct( int ) S3 v1, *p;                                                                // expansion and instantiation
 struct( type T )( int ) S24 { T i; } v2;                                // actual definition, expansion and instantiation
 struct( type T )( int ) { T i; } v2;                                    // anonymous actual definition, expansion and instantiation
+struct( otype T )( int ) S24 { T i; } v2;                               // actual definition, expansion and instantiation
+struct( otype T )( int ) { T i; } v2;                                   // anonymous actual definition, expansion and instantiation
 struct( type T | addable( T ) ) node { T data; struct( T ) node *next; };
 type List( type T ) = struct( T ) node *;
+struct( otype T | addable( T ) ) node { T data; struct( T ) node *next; };
+otype List( otype T ) = struct( T ) node *;
 List( int ) my_list;
 type Complex | addable( Complex );
+otype Complex | addable( Complex );
 int main() {

src/tests/Typedef.c

-                      r6cbc25a
+                      r7ff30d07
 a c;
 typedef typeof(3) x, y;  // GCC
+typedef otypeof(3) x, y;  // GCC
 x p;
 …
 int main() {
     typedef typeof(3) z, p;
+    typedef otypeof(3) z, p;
     z w;
     p x;

src/tests/Typeof.c

-                      r6cbc25a
+                      r7ff30d07
 int main() {
     int *v1;
     typeof(v1) v2;
     typeof(*v1) v3[4];
+    otypeof(v1) v2;
+    otypeof(*v1) v3[4];
     char *v4[4];
     typeof(typeof(char *)[4]) v5;
     typeof (int *) v6;
     typeof( int ( int, int p ) ) *v7;
     typeof( [int] ( int, int p ) ) *v8;
+    otypeof(otypeof(char *)[4]) v5;
+    otypeof (int *) v6;
+    otypeof( int ( int, int p ) ) *v7;
+    otypeof( [int] ( int, int p ) ) *v8;
+}

src/tests/io.c

-                      r6cbc25a
+                      r7ff30d07
 // Created On       : Wed Mar  2 16:56:02 2016
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Thu May 26 10:06:00 2016
 // Update Count     : 28
+// Last Modified On : Wed Jun  8 22:52:04 2016
+// Update Count     : 30
 //
 …
         long double _Complex ldc;
         char s1[10], s2[10];
+        int x = 3, y = 5, z = 7;
+        sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl;
+        sout | 1 | 2 | 3 | endl;
+        sout | '1' | '2' | '3' | endl;
+        sout | 1 | "" | 2 | "" | 3 | endl;
+        sout | endl;
         ifstream in;                                                                                            // create / open file

Context Navigation

Legend:

doc/LaTeXmacros/common.tex

doc/user/Cdecl.fig

doc/user/user.tex

doc/working/resolver_design.md

src/CodeGen/CodeGenerator.cc

src/CodeGen/CodeGenerator.h

src/Common/utility.h

src/Parser/ExpressionNode.cc

src/Parser/ParseNode.h

src/Parser/StatementNode.cc

src/Parser/parser.cc

src/Parser/parser.yy

src/ResolvExpr/AlternativeFinder.cc

src/SynTree/Expression.cc

src/SynTree/Expression.h

src/Tests/Abstype.c

src/Tests/Attributes.c

src/Tests/InferParam.c

src/Tests/Makefile

src/Tests/Members.c

src/Tests/OccursError.c

src/Tests/Quad.c

src/Tests/Rank2.c

src/driver/cc1.cc

src/driver/cfa.cc

src/libcfa/Makefile.am

src/tests/Array.c

src/tests/Forall.c

src/tests/Functions.c

src/tests/GccExtensions.c

src/tests/Scope.c

src/tests/Subrange.c

src/tests/TypeGenerator.c

src/tests/Typedef.c

src/tests/Typeof.c

src/tests/io.c

Download in other formats: