Changeset 154fdc8

doc/LaTeXmacros/common.tex

-                      r221c2de7
+                      r154fdc8
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%
 …
 %% Created On       : Sat Apr  9 10:06:17 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Wed Apr  5 23:19:42 2017
 %% Update Count     : 255
+%% Last Modified On : Wed Apr 12 11:32:26 2017
+%% Update Count     : 257
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20} % C++20 symbolic name
 \newcommand{\Celeven}{C11\xspace}               % C11 symbolic name
 \newcommand{\Csharp}{C\raisebox{0.4ex}{\#}\xspace}      % C# symbolic name
+\newcommand{\Csharp}{C\raisebox{-0.65ex}{\large$^\sharp$}\xspace}       % C# symbolic name
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

doc/bibliography/cfa.bib

-                      r221c2de7
+                      r154fdc8
 %    Predefined journal names:
 %  acmcs: Computing Surveys             acta: Acta Infomatica
+@string{acta="Acta Infomatica"}
 %  cacm: Communications of the ACM
 %  ibmjrd: IBM J. Research & Development ibmsj: IBM Systems Journal
 …
     keywords    = {Parametric polymorphism, alphard, iterators, nested types},
     contributer = {gjditchfield@plg},
+    key         = {Alphard},
     editor      = {Mary Shaw},
     title       = {{ALPHARD}: Form and Content},
 …
 @techreport{C11,
     type = {International Standard},
+    type        = {International Standard},
     keywords    = {ISO/IEC C 11},
     contributer = {pabuhr@plg},
 …
 @techreport{C++Concepts,
     type = {International Standard},
+    type        = {International Standard},
     keywords    = {ISO/IEC TS 19217:2015},
     contributer = {a3moss@uwaterloo.ca},
     key         = {{ISO/IEC} {TS} 19217},
+    author      = {Concepts},
     title       = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
     institution = {International Standard Organization},
 …
 @online{GCCExtensions,
+    contributer = {a3moss@uwaterloo.ca},
+    key = {{GNU}},
+    title = {Extensions to the {C} Language Family},
+    year = 2014,
+    url = {https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/C-Extensions.html},
+    urldate = {2017-04-02}
+    contributer = {a3moss@uwaterloo.ca},
+    key         = {{GNU}},
+    author      = {{C Extensions}},
+    title       = {Extensions to the {C} Language Family},
+    year        = 2014,
+    note        = {\href{https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/C-Extensions.html}{https://\-gcc.gnu.org/\-onlinedocs/\-gcc-4.7.2/\-gcc/\-C\-Extensions.html}},
+    urldate     = {2017-04-02}
+}
 …
     key         = {Fortran95},
     title       = {Fortran 95 Standard, ISO/IEC 1539},
     organization = {Unicomp, Inc.},
+    organization= {Unicomp, Inc.},
     address     = {7660 E. Broadway, Tucson, Arizona, U.S.A, 85710},
     month       = jan,
 …
 @online{GObject,
+    keywords = {GObject},
+    contributor = {a3moss@uwaterloo.ca},
+    author = {{The GNOME Project}},
+    title = {{GObject} Reference Manual},
+    year = 2014,
+    url = {https://developer.gnome.org/gobject/stable/},
+    urldate = {2017-04-04}
+    keywords    = {GObject},
+    contributor = {a3moss@uwaterloo.ca},
+    author      = {{GObject}},
+    organization= {The GNOME Project},
+    title       = {{GObject} Reference Manual},
+    year        = 2014,
+    url         = {https://developer.gnome.org/gobject/stable/},
+    urldate     = {2017-04-04}
+}
 …
     contributer = {pabuhr@plg},
     author      = {James Gosling and Bill Joy and Guy Steele and Gilad Bracha and Alex Buckley},
+    title       = {{Java} Language Specification},
+    title       = {{Java} Language Spec.},
+    organization= {Oracle},
     publisher   = {Oracle},
     year        = 2015,
 …
 @manual{obj-c-book,
     keywords = {objective-c},
     contributor = {a3moss@uwaterloo.ca},
     author = {{Apple Computer Inc.}},
     title = {The {Objective-C} Programming Language},
     publisher = {Apple Computer Inc.},
     address = {Cupertino, CA},
     year = 2003
+    keywords    = {objective-c},
+    contributor = {a3moss@uwaterloo.ca},
+    author      = {{Objective-C}},
+    title       = {The {Objective-C} Programming Language},
+    organization= {Apple Computer Inc.},
+    address     = {Cupertino, CA},
+    year        = 2003
+}
 …
     keywords    = {objective-c},
     contributor = {a3moss@uwaterloo.ca},
     author      = {{Apple Computer Inc.}},
+    author      = {{Xcode}},
     title       = {{Xcode} 7 Release Notes},
     year        = 2015,
 …
     year        = 1980,
     month       = nov, volume = 15, number = 11, pages = {47-56},
+    note        = {Proceedings of the ACM-SIGPLAN Symposium on the {Ada} Programming
+         Language},
+    note        = {Proceedings of the ACM-SIGPLAN Symposium on the {Ada} Programming Language},
     comment     = {
         The two-pass (bottom-up, then top-down) algorithm, with a proof
 …
     title       = {Programming with Sets: An Introduction to {SETL}},
     publisher   = {Springer},
+    address     = {New York, NY, USA},
     year        = 1986,
+}
 …
     contributer = {pabuhr@plg},
     title       = {The Programming Language {Ada}: Reference Manual},
+    author      = {Ada},
     organization= {United States Department of Defense},
     edition     = {{ANSI/MIL-STD-1815A-1983}},
 …
     keywords    = {Rust programming language},
     contributer = {pabuhr@plg},
+    author      = {{Rust}},
     title       = {The {Rust} Programming Language},
     organization= {The Rust Project Developers},
 …
     keywords    = {Scala programming language},
     contributer = {pabuhr@plg},
+    author      = {{Scala}},
     title       = {{Scala} Language Specification, Version 2.11},
     organization= {\'{E}cole Polytechnique F\'{e}d\'{e}rale de Lausanne},
 …
+}
+@article{Smith98,
+  keywords = {Polymorphic C},
+  contributor = {a3moss@uwaterloo.ca},
+  title={A sound polymorphic type system for a dialect of C},
+  author={Smith, Geoffrey and Volpano, Dennis},
+  journal={Science of computer programming},
+  volume={32},
+  number={1-3},
+  pages={49--72},
+  year={1998},
+  publisher={Elsevier}
+}
 @book{Campbell74,
     keywords    = {path expressions},
 …
     number      = 5,
     pages       = {341-346}
+}
+@online{Sutter15,
+    contributer = {pabuhr@plg},
+    author      = {Herb Sutter and Bjarne Stroustrup and Gabriel Dos Reis},
+    title       = {Structured bindings},
+    issue_date  = {2015-10-14},
+    month       = oct,
+    year        = 2015,
+    pages       = {1--6},
+    numpages    = {6},
+    note        = {\href{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf}{http://\-www.open-std.org/\-jtc1/\-sc22/\-wg21/\-docs/\-papers/\-2015/\-p0144r0.pdf}},
+}
 …
     number      = 6,
     month       = jun,
+    publisher   = {ACM},
+    address     = {New York, NY, USA},
     year        = 1990,
     pages       = {127-136},
 …
 @online{Vala,
+    keywords = {GObject, Vala},
+    contributor = {a3moss@uwaterloo.ca},
+    author = {{The GNOME Project}},
+    title = {Vala Reference Manual},
+    year = 2017,
+    url = {https://wiki.gnome.org/Projects/Vala/Manual},
+    urldate = {2017-04-04}
+    keywords    = {GObject, Vala},
+    contributor = {a3moss@uwaterloo.ca},
+    author      = {{Vala}},
+    organization= {The GNOME Project},
+    title       = {Vala Reference Manual},
+    year        = 2017,
+    url         = {https://wiki.gnome.org/Projects/Vala/Manual},
+    urldate     = {2017-04-04}
+}

doc/generic_types/.gitignore

r221c2de7	r154fdc8
17	17	*.synctex.gz
18	18	comment.cut
	19	timing.tex

doc/generic_types/Makefile

-                      r221c2de7
+                      r154fdc8
 GRAPHS = ${addsuffix .tex, \
+timing \
+}
 …
 #${DOCUMENT} : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
+${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \
+                ../LaTeXmacros/common.tex ../LaTeXmacros/indexstyle ../bibliography/cfa.bib
+${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex ../bibliography/cfa.bib
         # Conditionally create an empty *.idx (index) file for inclusion until makeindex is run.
         if [ ! -r ${basename $@}.idx ] ; then touch ${basename $@}.idx ; fi
 …
 ## Define the default recipes.
+${GRAPHS} : evaluation/timing.gp evaluation/timing.dat
+        gnuplot evaluation/timing.gp
 %.tex : %.fig
         fig2dev -L eepic $< > $@

doc/generic_types/acmart.cls

-                      r221c2de7
+                      r154fdc8
        \immediate\write\@auxout{\string\bibstyle{#1}}%
      \fi}}
 \RequirePackage{graphicx, xcolor}
 \definecolor[named]{ACMBlue}{cmyk}{1,0.1,0,0.1}
 \definecolor[named]{ACMYellow}{cmyk}{0,0.16,1,0}
 \definecolor[named]{ACMOrange}{cmyk}{0,0.42,1,0.01}
 \definecolor[named]{ACMRed}{cmyk}{0,0.90,0.86,0}
 \definecolor[named]{ACMLightBlue}{cmyk}{0.49,0.01,0,0}
 \definecolor[named]{ACMGreen}{cmyk}{0.20,0,1,0.19}
 \definecolor[named]{ACMPurple}{cmyk}{0.55,1,0,0.15}
 \definecolor[named]{ACMDarkBlue}{cmyk}{1,0.58,0,0.21}
+%\RequirePackage{graphicx, xcolor}
+%\definecolor[named]{ACMBlue}{cmyk}{1,0.1,0,0.1}
+%\definecolor[named]{ACMYellow}{cmyk}{0,0.16,1,0}
+%\definecolor[named]{ACMOrange}{cmyk}{0,0.42,1,0.01}
+%\definecolor[named]{ACMRed}{cmyk}{0,0.90,0.86,0}
+%\definecolor[named]{ACMLightBlue}{cmyk}{0.49,0.01,0,0}
+%\definecolor[named]{ACMGreen}{cmyk}{0.20,0,1,0.19}
+%\definecolor[named]{ACMPurple}{cmyk}{0.55,1,0,0.15}
+%\definecolor[named]{ACMDarkBlue}{cmyk}{1,0.58,0,0.21}
 \RequirePackage{geometry}
 \ifcase\ACM@format@nr

doc/generic_types/evaluation/.gitignore

-                      r221c2de7
+                      r154fdc8
 c-bench
 cpp-bench
+cpp-vbench
 cfa-bench
-c2-bench
-cpp2-bench
-cfa2-bench
 *.o
 *.d

doc/generic_types/evaluation/Makefile

-                      r221c2de7
+                      r154fdc8
 CFA = my-cfa
+CFA = cfa
 DEPFLAGS = -MMD -MP
+CFLAGS = -O2
+ifdef N
+CFLAGS += -DN=$(N)
+endif
+CXXFLAGS = $(CFLAGS) --std=c++14
 .PHONY: all clean distclean bench
+.PHONY: all clean distclean run-c run-cpp run-cfa run
 all: c-bench cpp-bench cfa-bench c2-bench cpp2-bench cfa2-bench
+all: c-bench cpp-bench cfa-bench cpp-vbench
 # rewrite object generation to auto-determine deps
 …
 c-%.o : c-%.c
 c-%.o : c-%.c c-%.d
         $(COMPILE.c) -O0 $(OUTPUT_OPTION) -c $<
+        $(COMPILE.c) $(OUTPUT_OPTION) -c $<
 cpp-%.o : cpp-%.cpp
 cpp-%.o : cpp-%.cpp cpp-%.d
         $(COMPILE.cpp) -O0 $(OUTPUT_OPTION) -c $<
+        $(COMPILE.cpp) $(OUTPUT_OPTION) -c $<
 cfa-%.o : cfa-%.c
 cfa-%.o : cfa-%.c cfa-%.d
         $(COMPILE.cfa) -O0 $(OUTPUT_OPTION) -c $<
+        $(COMPILE.cfa) $(OUTPUT_OPTION) -c $<
+c2-%.o : c-%.c
+c2-%.o : c-%.c c-%.d
+        $(COMPILE.c) -O2 $(OUTPUT_OPTION) -c $<
+COBJS = c-stack.o c-pair.o c-print.o
+CPPOBJS =
+CPPVOBJS = cpp-vstack.o
+CFAOBJS = cfa-stack.o cfa-pair.o cfa-print.o
+cpp2-%.o : cpp-%.cpp
+cpp2-%.o : cpp-%.cpp cpp-%.d
+        $(COMPILE.cpp) -O2 $(OUTPUT_OPTION) -c $<
+cfa2-%.o : cfa-%.c
+cfa2-%.o : cfa-%.c cfa-%.d
+        $(COMPILE.cfa) -O2 $(OUTPUT_OPTION) -c $<
+COBJS = c-stack.o
+CPPOBJS =
+CFAOBJS = cfa-stack.o
+C2OBJS = $(patsubst c-%,c2-%, $(COBJS))
+CPP2OBJS = $(patsubst cpp-%,cpp2-%, $(CPPOBJS))
+CFA2OBJS = $(patsubst cfa-%,cfa2-%, $(CFAOBJS))
+CFILES = c-bench.c bench.h $(COBJS:.o=.h) $(COBJS:.o=.c)
+CPPFILES = cpp-bench.cpp bench.hpp cpp-stack.hpp cpp-pair.hpp cpp-print.hpp
+CPPVFILES = cpp-vbench.cpp bench.hpp object.hpp $(CPPVOBJS:.o=.hpp) $(CPPVOBJS:.o=.cpp) cpp-vprint.hpp
+CFAFILES = cfa-bench.c bench.h $(CFAOBJS:.o=.h) $(CFAOBJS:.o=.c)
 c-bench: c-bench.c c-bench.d $(COBJS)
         $(COMPILE.c) -O0 -o $@ $< $(COBJS) $(LDFLAGS)
+        $(COMPILE.c) -o $@ $< $(COBJS) $(LDFLAGS)
 cpp-bench: cpp-bench.cpp cpp-bench.d $(CPPOBJS)
+        $(COMPILE.cpp) -O0 -o $@ $< $(CPPOBJS) $(LDFLAGS)
+        $(COMPILE.cpp) -o $@ $< $(CPPOBJS) $(LDFLAGS)
+cpp-vbench: cpp-vbench.cpp cpp-vbench.d $(CPPVOBJS)
+        $(COMPILE.cpp) -o $@ $< $(CPPVOBJS) $(LDFLAGS)
 cfa-bench: cfa-bench.c cfa-bench.d $(CFAOBJS)
+        $(COMPILE.cfa) -O0 -o $@ $< $(CFAOBJS) $(LDFLAGS)
+c2-bench: c-bench.c c-bench.d $(C2OBJS)
+        $(COMPILE.c) -O2 -o $@ $< $(C2OBJS) $(LDFLAGS)
+cpp2-bench: cpp-bench.cpp cpp-bench.d $(CPP2OBJS)
+        $(COMPILE.cpp) -O2 -o $@ $< $(CPP2OBJS) $(LDFLAGS)
+cfa2-bench: cfa-bench.c cfa-bench.d $(CFA2OBJS)
+        $(COMPILE.cfa) -O2 -o $@ $< $(CFA2OBJS) $(LDFLAGS)
+        $(COMPILE.cfa) -o $@ $< $(CFAOBJS) $(LDFLAGS)
 clean:
         -rm $(COBJS) c-bench
         -rm $(CPPOBJS) cpp-bench
+        -rm $(CPPVOBJS) cpp-vbench
         -rm $(CFAOBJS) cfa-bench
-        -rm $(C2OBJS) c2-bench
-        -rm $(CPP2OBJS) cpp2-bench
-        -rm $(CFA2OBJS) cfa2-bench
 distclean: clean
         -rm $(COBJS:.o=.d) c-bench.d
         -rm $(CPPOBJS:.o=.d) cpp-bench.d
+        -rm $(CPPVOBJS:.o=.d) cpp-vbench.d
         -rm $(CFAOBJS:.o=.d) cfa-bench.d
+bench: c-bench cpp-bench cfa-bench c2-bench cpp2-bench cfa2-bench
+run-c: c-bench
+        @echo
         @echo '## C ##'
+        @./c-bench
+        @/usr/bin/time -f 'max_memory:\t%M kilobytes' ./c-bench
+        @printf 'source_size:\t%8d lines\n' `cat $(CFILES) | wc -l`
+        @printf 'redundant_type_annotations:%8d lines\n' `cat $(CFILES) | fgrep '/***/' -c`
+        @printf 'binary_size:\t%8d bytes\n' `stat -c %s c-bench`
+run-cfa: cfa-bench
+        @echo
+        @echo '## Cforall ##'
+        @/usr/bin/time -f 'max_memory:\t %M kilobytes' ./cfa-bench
+        @printf 'source_size:\t%8d lines\n' `cat $(CFAFILES) | wc -l`
+        @printf 'redundant_type_annotations:%8d lines\n' `cat $(CFAFILES) | fgrep '/***/' -c`
+        @printf 'binary_size:\t%8d bytes\n' `stat -c %s cfa-bench`
+run-cpp: cpp-bench
+        @echo
         @echo '## C++ ##'
+        @./cpp-bench
+        @echo '## Cforall ##'
+        @./cfa-bench
+        @echo '## C -O2 ##'
+        @./c2-bench
+        @echo '## C++ -O2 ##'
+        @./cpp2-bench
+        @echo '## Cforall -O2 ##'
+        @./cfa2-bench
+        @/usr/bin/time -f 'max_memory:\t %M kilobytes' ./cpp-bench
+        @printf 'source_size:\t%8d lines\n' `cat $(CPPFILES) | wc -l`
+        @printf 'redundant_type_annotations:%8d lines\n' `cat $(CPPFILES) | fgrep '/***/' -c`
+        @printf 'binary_size:\t%8d bytes\n' `stat -c %s cpp-bench`
+run-cppv: cpp-vbench
+        @echo
+        @echo '## C++obj ##'
+        @/usr/bin/time -f 'max_memory:\t%M kilobytes' ./cpp-vbench
+        @printf 'source_size:\t%8d lines\n' `cat $(CPPVFILES) | wc -l`
+        @printf 'redundant_type_annotations:%8d lines\n' `cat $(CPPVFILES) | fgrep '/***/' -c`
+        @printf 'binary_size:\t%8d bytes\n' `stat -c %s cpp-vbench`
+run: run-c run-cfa run-cpp run-cppv
 # so make doesn't fail without dependency files

doc/generic_types/evaluation/bench.h

-                      r221c2de7
+                      r154fdc8
+#pragma once
 #include <stdio.h>
 #include <time.h>
+#define N 200000000
+long ms_between(clock_t start, clock_t end) { return (end - start) / (CLOCKS_PER_SEC / 1000); }
+long ms_between(clock_t start, clock_t end) {
+        return (end - start) / (CLOCKS_PER_SEC / 1000);
+#define N 40000000
+#define TIMED(name, code) { \
+        volatile clock_t _start, _end; \
+        _start = clock(); \
+        code \
+        _end = clock(); \
+        printf("%s:\t%8ld ms\n", name, ms_between(_start, _end)); \
+}
+#define TIMED(name, code) { \
+        clock_t start, end; \
+        start = clock(); \
+        code \
+        end = clock(); \
+        printf("%s:\t%7ld ms\n", name, ms_between(start, end)); \
+}
+#define REPEAT_TIMED(name, code) TIMED( name, for (int i = 0; i < N; ++i) { code } )
+#define REPEAT_TIMED(name, n, code) TIMED( name, for (int _i = 0; _i < n; ++_i) { code } )

doc/generic_types/evaluation/c-bench.c

-                      r221c2de7
+                      r154fdc8
+#include <stdio.h>
 #include <stdlib.h>
 #include "bench.h"
+#include "c-pair.h"
 #include "c-stack.h"
+#include "c-print.h"
+_Bool* new_bool( _Bool b ) {
+        _Bool* q = malloc(sizeof(_Bool)); /***/
+        *q = b;
+        return q;
+}
+char* new_char( char c ) {
+        char* q = malloc(sizeof(char)); /***/
+        *q = c;
+        return q;
+}
+int* new_int( int i ) {
+        int* q = malloc(sizeof(int)); /***/
+        *q = i;
+        return q;
+}
+void* copy_bool( const void* p ) { return new_bool( *(const _Bool*)p ); } /***/
+void* copy_char( const void* p ) { return new_char( *(const char*)p ); } /***/
+void* copy_int( const void* p ) { return new_int( *(const int*)p ); } /***/
+void* copy_pair_bool_char( const void* p ) { return copy_pair( p, copy_bool, copy_char ); } /***/
+void free_pair_bool_char( void* p ) { free_pair( p, free, free ); } /***/
+int cmp_bool( const void* a, const void* b ) { /***/
+        return *(const _Bool*)a == *(const _Bool*)b ? 0 : *(const _Bool*)a < *(const _Bool*)b ? -1 : 1;
+}
+int cmp_char( const void* a, const void* b ) { /***/
+        return *(const char*)a == *(const char*)b ? 0 : *(const char*)a < *(const char*)b ? -1 : 1;
+}
 int main(int argc, char** argv) {
+        srand(20171025);
+        FILE * out = fopen("c-out.txt", "w");
+        int maxi = 0, vali = 42;
+        struct stack si = new_stack(), ti;
+        struct stack s = new_stack();
+        REPEAT_TIMED( "push_int", N, push_stack( &si, new_int( vali ) ); )
+        TIMED( "copy_int",      copy_stack( &ti, &si, copy_int ); /***/ )
+        TIMED( "clear_int", clear_stack( &si, free ); /***/ )
+        REPEAT_TIMED( "pop_int", N,
+                int* xi = pop_stack( &ti );
+                if ( *xi > maxi ) { maxi = *xi; }
+                free(xi); )
+        REPEAT_TIMED( "print_int", N/2, print( out, "dsds", vali, ":", vali, "\n" ); /***/ )
+        REPEAT_TIMED( "push_int",
+                int* x = malloc(sizeof(int));
+                *x = rand();
+                push_stack(&s, x);
+        )
+        struct pair * maxp = new_pair( new_bool(0), new_char('\0') ),
+                * valp = new_pair( new_bool(1), new_char('a') );
+        struct stack sp = new_stack(), tp;
+        clear_stack(&s);
+        REPEAT_TIMED( "push_pair", N, push_stack( &sp, copy_pair_bool_char( valp ) ); )
+        TIMED( "copy_pair", copy_stack( &tp, &sp, copy_pair_bool_char ); /***/ )
+        TIMED( "clear_pair", clear_stack( &sp, free_pair_bool_char ); /***/ )
+        REPEAT_TIMED( "pop_pair", N,
+                struct pair * xp = pop_stack( &tp );
+                if ( cmp_pair( xp, maxp, cmp_bool, cmp_char /***/ ) > 0 ) {
+                        free_pair_bool_char( maxp ); /***/
+                        maxp = xp;
+                } else {
+                        free_pair_bool_char( xp ); /***/
+                } )
+        REPEAT_TIMED( "print_pair", N/2, print( out, "pbcspbcs", *valp, ":", *valp, "\n" ); /***/ )
+        free_pair_bool_char( maxp ); /***/
+        free_pair_bool_char( valp ); /***/
+        fclose(out);
+}

doc/generic_types/evaluation/c-stack.c

-                      r221c2de7
+                      r154fdc8
 };
+struct stack new_stack() {
+        return (struct stack){ NULL };
+struct stack new_stack() { return (struct stack){ NULL }; /***/ }
+void copy_stack(struct stack* s, const struct stack* t, void* (*copy)(const void*)) {
+        struct stack_node** crnt = &s->head;
+        struct stack_node* next = t->head;
+        while ( next ) {
+                *crnt = malloc(sizeof(struct stack_node)); /***/
+                **crnt = (struct stack_node){ copy(next->value) }; /***/
+                crnt = &(*crnt)->next;
+                next = next->next;
+        }
+        *crnt = 0;
+}
 void clear_stack(struct stack* s) {
+void clear_stack(struct stack* s, void (*free_el)(void*)) {
         struct stack_node* next = s->head;
         while ( next ) {
                 struct stack_node* crnt = next;
                 next = crnt->next;
                 free(crnt->value);
+                free_el(crnt->value);
                 free(crnt);
+        }
+        s->head = NULL;
+}
+_Bool stack_empty(const struct stack* s) {
+        return s->head == NULL;
+}
+_Bool stack_empty(const struct stack* s) { return s->head == NULL; }
 void push_stack(struct stack* s, void* value) {
         struct stack_node* n = malloc(sizeof(struct stack_node));
         *n = (struct stack_node){ value, s->head };
+        struct stack_node* n = malloc(sizeof(struct stack_node)); /***/
+        *n = (struct stack_node){ value, s->head }; /***/
         s->head = n;
+}

doc/generic_types/evaluation/c-stack.h

-                      r221c2de7
+                      r154fdc8
+#pragma once
 struct stack_node;
 struct stack {
         struct stack_node* head;
 …
 struct stack new_stack();
 void clear_stack(struct stack* s);
+void copy_stack(struct stack* dst, const struct stack* src, void* (*copy)(const void*));
+void clear_stack(struct stack* s, void (*free_el)(void*));
 _Bool stack_empty(const struct stack* s);
 void push_stack(struct stack* s, void* value);
 void* pop_stack(struct stack* s);

doc/generic_types/evaluation/cfa-bench.c

-                      r221c2de7
+                      r154fdc8
 #include <stdlib.h>
+#include <stdio.h>
 #include "bench.h"
 #include "cfa-stack.h"
+#include "cfa-pair.h"
+#include "cfa-print.h"
+int main(int argc, char** argv) {
+        srand(20171025);
+int main( int argc, char *argv[] ) {
+        FILE * out = fopen( "cfa-out.txt", "w" );
+        int maxi = 0, vali = 42;
+        stack(int) si, ti;
+        stack(int) s;
+        REPEAT_TIMED( "push_int", N, push( &si, vali ); )
+        TIMED( "copy_int", ti = si; )
+        TIMED( "clear_int", clear( &si ); )
+        REPEAT_TIMED( "pop_int", N,
+                int xi = pop( &ti );
+                if ( xi > maxi ) { maxi = xi; } )
+        REPEAT_TIMED( "print_int", N/2, print( out, vali, ":", vali, "\n" ); )
+        REPEAT_TIMED( "push_int",
+                push( &s, rand() );
+        )
+        pair(_Bool, char) maxp = { (_Bool)0, '\0' }, valp = { (_Bool)1, 'a' };
+        stack(pair(_Bool, char)) sp, tp;
+        REPEAT_TIMED( "push_pair", N, push( &sp, valp ); )
+        TIMED( "copy_pair", tp = sp; )
+        TIMED( "clear_pair", clear( &sp ); )
+        REPEAT_TIMED( "pop_pair", N,
+                pair(_Bool, char) xp = pop( &tp );
+                if ( xp > maxp ) { maxp = xp; } )
+        REPEAT_TIMED( "print_pair", N/2, print( out, valp, ":", valp, "\n" ); )
+        fclose(out);
+}

doc/generic_types/evaluation/cfa-stack.c

-                      r221c2de7
+                      r154fdc8
 };
+forall(otype T) void ?{}(stack(T)* s) {
+        ?{}( &s->head, 0 );
+forall(otype T) void ?{}(stack(T)* s) { (&s->head){ 0 }; }
+forall(otype T) void ?{}(stack(T)* s, stack(T) t) {
+        stack_node(T)** crnt = &s->head;
+        stack_node(T)* next = t.head;
+        while ( next ) {
+                *crnt = ((stack_node(T)*)malloc()){ next->value }; /***/
+                stack_node(T)* acrnt = *crnt;
+                crnt = &acrnt->next;
+                next = next->next;
+        }
+        *crnt = 0;
+}
+forall(otype T) void ^?{}(stack(T)* s) {
+forall(otype T) stack(T) ?=?(stack(T)* s, stack(T) t) {
+        if ( s->head == t.head ) return *s;
+        clear(s);
+        s{ t };
+        return *s;
+}
+forall(otype T) void ^?{}(stack(T)* s) { clear(s); }
+forall(otype T) _Bool empty(const stack(T)* s) { return s->head == 0; }
+forall(otype T) void push(stack(T)* s, T value) {
+        s->head = ((stack_node(T)*)malloc()){ value, s->head }; /***/
+}
+forall(otype T) T pop(stack(T)* s) {
+        stack_node(T)* n = s->head;
+        s->head = n->next;
+        T x = n->value;
+        ^n{};
+        free(n);
+        return x;
+}
+forall(otype T) void clear(stack(T)* s) {
         stack_node(T)* next = s->head;
         while ( next ) {
 …
                 delete(crnt);
+        }
+        s->head = 0;
+}
-forall(otype T) _Bool empty(const stack(T)* s) {
-        return s->head == 0;
+}
-forall(otype T) void push(stack(T)* s, T value) {
-        s->head = ((stack_node(T)*)malloc()){ value, s->head };
+}
-forall(otype T) T pop(stack(T)* s) {
-        stack_node(T)* n = s->head;
-        s->head = n->next;
-        T x = n->value;
-        delete(n);
-        return x;
+}

doc/generic_types/evaluation/cfa-stack.h

-                      r221c2de7
+                      r154fdc8
+#pragma once
 forall(otype T) struct stack_node;
 forall(otype T) struct stack {
         stack_node(T)* head;
 …
 forall(otype T) void ?{}(stack(T)* s);
+forall(otype T) void ?{}(stack(T)* s, stack(T) t);
+forall(otype T) stack(T) ?=?(stack(T)* s, stack(T) t);
 forall(otype T) void ^?{}(stack(T)* s);
 forall(otype T) _Bool empty(const stack(T)* s);
 forall(otype T) void push(stack(T)* s, T value);
 forall(otype T) T pop(stack(T)* s);
+forall(otype T) void clear(stack(T)* s);

doc/generic_types/evaluation/cpp-bench.cpp

-                      r221c2de7
+                      r154fdc8
+#include <stdlib.h>
+#include "bench.h"
+#include "cpp-stack.h"
+#include <algorithm>
+#include <fstream>
+#include "bench.hpp"
+#include "cpp-stack.hpp"
+#include "cpp-pair.hpp"
+#include "cpp-print.hpp"
 int main(int argc, char** argv) {
+        srand(20171025);
+        std::ofstream out{"cpp-out.txt"};
+        int maxi = 0, vali = 42;
+        stack<int> si, ti;
+        REPEAT_TIMED( "push_int", N, si.push( vali ); )
+        TIMED( "copy_int", ti = si; )
+        TIMED( "clear_int", si.clear(); )
+        REPEAT_TIMED( "pop_int", N, maxi = std::max( maxi, ti.pop() ); )
+        REPEAT_TIMED( "print_int", N/2, print( out, vali, ":", vali, "\n" ); )
+        stack<int> s;
+        REPEAT_TIMED( "push_int",
+                s.push( rand() );
+        )
+        pair<bool, char> maxp = { false, '\0' }, valp = { true, 'a' };
+        stack<pair<bool, char>> sp, tp;
+        REPEAT_TIMED( "push_pair", N, sp.push( valp ); )
+        TIMED( "copy_pair", tp = sp; )
+        TIMED( "clear_pair", sp.clear(); )
+        REPEAT_TIMED( "pop_pair", N, maxp = std::max( maxp, tp.pop() ); )
+        REPEAT_TIMED( "print_pair", N/2, print( out, valp, ":", valp, "\n" ); )
+}

doc/generic_types/generic_types.tex

-                      r221c2de7
+                      r154fdc8
 % take off review (for line numbers) and anonymous (for anonymization) on submission
 % \documentclass[format=acmlarge, anonymous, review]{acmart}
 \documentclass[format=acmlarge,review]{acmart}
+\documentclass[format=acmlarge,anonymous,review]{acmart}
+% \documentclass[format=acmlarge,review]{acmart}
 \usepackage{xspace,calc,comment}
 \usepackage{upquote}                                                                    % switch curled `'" to straight
 \usepackage{listings}                                                                   % format program code
+\usepackage[usenames]{color}
 \makeatletter
+% Default underscore is too low and wide. Cannot use lstlisting "literate" as replacing underscore
+% removes it as a variable-name character so keyworks in variables are highlighted
+\DeclareTextCommandDefault{\textunderscore}{\leavevmode\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}
 % parindent is relative, i.e., toggled on/off in environments like itemize, so store the value for
 % use rather than use \parident directly.
 …
 \setlength{\parindentlnth}{\parindent}
 \newlength{\gcolumnposn}                                % temporary hack because lstlisting does handle tabs correctly
+\newlength{\gcolumnposn}                                % temporary hack because lstlisting does not handle tabs correctly
 \newlength{\columnposn}
 \setlength{\gcolumnposn}{2.75in}
 …
 \newcommand{\C}[2][\@empty]{\ifx#1\@empty\else\global\setlength{\columnposn}{#1}\global\columnposn=\columnposn\fi\hfill\makebox[\textwidth-\columnposn][l]{\lst@commentstyle{#2}}}
 \newcommand{\CRT}{\global\columnposn=\gcolumnposn}
+% Latin abbreviation
+\newcommand{\abbrevFont}{\textit}       % set empty for no italics
+\newcommand*{\eg}{%
+        \@ifnextchar{,}{\abbrevFont{e}.\abbrevFont{g}.}%
+                {\@ifnextchar{:}{\abbrevFont{e}.\abbrevFont{g}.}%
+                        {\abbrevFont{e}.\abbrevFont{g}.,\xspace}}%
+}%
+\newcommand*{\ie}{%
+        \@ifnextchar{,}{\abbrevFont{i}.\abbrevFont{e}.}%
+                {\@ifnextchar{:}{\abbrevFont{i}.\abbrevFont{e}.}%
+                        {\abbrevFont{i}.\abbrevFont{e}.,\xspace}}%
+}%
+\newcommand*{\etc}{%
+        \@ifnextchar{.}{\abbrevFont{etc}}%
+        {\abbrevFont{etc}.\xspace}%
+}%
+\newcommand{\etal}{%
+        \@ifnextchar{.}{\abbrevFont{et~al}}%
+                {\abbrevFont{et al}.\xspace}%
+}%
 \makeatother
 …
 \newcommand{\CCseventeen}{\rm C\kern-.1em\hbox{+\kern-.25em+}17\xspace} % C++17 symbolic name
 \newcommand{\CCtwenty}{\rm C\kern-.1em\hbox{+\kern-.25em+}20\xspace} % C++20 symbolic name
+\newcommand{\CS}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace}
+\newcommand{\CCV}{\rm C\kern-.1em\hbox{+\kern-.25em+}obj\xspace} % C++ virtual symbolic name
+\newcommand{\Csharp}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace} % C# symbolic name
 \newcommand{\Textbf}[1]{{\color{red}\textbf{#1}}}
 \newcommand{\TODO}[1]{\textbf{TODO}: {\itshape #1}} % TODO included
 %\newcommand{\TODO}[1]{} % TODO elided
-\newcommand{\eg}{\textit{e}.\textit{g}.,\xspace}
-\newcommand{\ie}{\textit{i}.\textit{e}.,\xspace}
-\newcommand{\etc}{\textit{etc}.,\xspace}
 % CFA programming language, based on ANSI C (with some gcc additions)
 …
 belowskip=3pt,
 % 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,
+literate={-}{\makebox[1.4ex][c]{\raisebox{0.5ex}{\rule{1.2ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
+        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
+        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1.4ex][c]{\raisebox{0.5ex}{\rule{1.2ex}{0.1ex}}}\kern-0.3ex\textgreater}2,
 moredelim=**[is][\color{red}]{`}{`},
 }% lstset
 % inline code @...@
 \lstMakeShortInline@
+\lstMakeShortInline@%
 % ACM Information
 …
 \begin{abstract}
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects. This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more. Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive. The goal of the \CFA project is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers. Prior projects have attempted similar goals but failed to honour C programming-style; for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers. Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and engineers. This paper describes two \CFA extensions, generic and tuple types, details how their design avoids shortcomings of similar features in C and other C-like languages, and presents experimental results validating the design.
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects.
+This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
+Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
+The goal of the \CFA project is to create an extension of C that provides modern safety and productivity features while still ensuring strong backwards compatibility with C and its programmers.
+Prior projects have attempted similar goals but failed to honour C programming-style; for instance, adding object-oriented or functional programming with garbage collection is a non-starter for many C developers.
+Specifically, \CFA is designed to have an orthogonal feature-set based closely on the C programming paradigm, so that \CFA features can be added \emph{incrementally} to existing C code-bases, and C programmers can learn \CFA extensions on an as-needed basis, preserving investment in existing code and engineers.
+This paper describes two \CFA extensions, generic and tuple types, details how their design avoids shortcomings of similar features in C and other C-like languages, and presents experimental results validating the design.
 \end{abstract}
 …
 \section{Introduction and Background}
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects. This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
+The \citet{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \CS 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail. The top 3 rankings over the past 30 years are:
+\lstDeleteShortInline@
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems to hobby projects.
+This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
+The \citet{TIOBE} ranks the top 5 most popular programming languages as: Java 16\%, \Textbf{C 7\%}, \Textbf{\CC 5\%}, \Csharp 4\%, Python 4\% = 36\%, where the next 50 languages are less than 3\% each with a long tail.
+The top 3 rankings over the past 30 years are:
+\lstDeleteShortInline@%
 \begin{center}
 \setlength{\tabcolsep}{10pt}
+\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
+                & 2017  & 2012  & 2007  & 2002  & 1997  & 1992  & 1987          \\
+\hline
+Java    & 1             & 1             & 1             & 3             & 13    & -             & -                     \\
+\hline
+\Textbf{C}      & \Textbf{2}& \Textbf{2}& \Textbf{2}& \Textbf{1}& \Textbf{1}& \Textbf{1}& \Textbf{1}    \\
+\hline
+\begin{tabular}{@{}rccccccc@{}}
+                & 2017  & 2012  & 2007  & 2002  & 1997  & 1992  & 1987          \\ \hline
+Java    & 1             & 1             & 1             & 1             & 12    & -             & -                     \\
+\Textbf{C}      & \Textbf{2}& \Textbf{2}& \Textbf{2}& \Textbf{2}& \Textbf{1}& \Textbf{1}& \Textbf{1}    \\
 \CC             & 3             & 3             & 3             & 3             & 2             & 2             & 4                     \\
 \end{tabular}
 \end{center}
 \lstMakeShortInline@
 Love it or hate it, C is extremely popular, highly used, and one of the few system's languages.
+\lstMakeShortInline@%
+Love it or hate it, C is extremely popular, highly used, and one of the few systems languages.
 In many cases, \CC is often used solely as a better C.
 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive.
+\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. The four key design goals for \CFA~\citep{Bilson03} are:
+\CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers.
+The four key design goals for \CFA~\citep{Bilson03} are:
 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler;
 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler;
 (3) \CFA code must be at least as portable as standard C code;
 (4) Extensions introduced by \CFA must be translated in the most efficient way possible.
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.
+This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
+\CC is used similarly, but has the disadvantages of multiple legacy design-choices that cannot be updated and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
+\CFA is currently implemented as a source-to-source translator from \CFA to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)--(3).
+Ultimately, a compiler is necessary for advanced features and optimal performance.
+This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings.
+Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions.
+The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.
 …
 \label{sec:poly-fns}
+\CFA's polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}. The signature feature of \CFA is parametric-polymorphic functions where functions are generalized using a @forall@ clause (giving the language its name):
+\CFA's polymorphism was originally formalized by \citet{Ditchfield92}, and first implemented by \citet{Bilson03}.
+The signature feature of \CFA is parametric-polymorphic functions~\citep{forceone:impl,Cormack90,Duggan96} with functions generalized using a @forall@ clause (giving the language its name):
 \begin{lstlisting}
 `forall( otype T )` T identity( T val ) { return val; }
 int forty_two = identity( 42 );                         $\C{// T is bound to int, forty\_two == 42}$
 \end{lstlisting}
+The @identity@ function above can be applied to any complete \emph{object type} (or @otype@). The type variable @T@ is transformed into a set of additional implicit parameters encoding sufficient information about @T@ to create and return a variable of that type. The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor and destructor. If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \emph{data type} (or @dtype@).
+Here, the runtime cost of polymorphism is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments have shown this overhead is similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA polymorphic functions are compatible with C \emph{separate} compilation, preventing code bloat.
+Since bare polymorphic-types provide only a narrow set of available operations, \CFA provides a \emph{type assertion} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable. For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
+The @identity@ function above can be applied to any complete \emph{object type} (or @otype@).
+The type variable @T@ is transformed into a set of additional implicit parameters encoding sufficient information about @T@ to create and return a variable of that type.
+The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor and destructor.
+If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \emph{data type} (or @dtype@).
+In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions;
+the experiments in Section~\ref{sec:eval} show this overhead is similar to \CC virtual-function calls.
+A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat.
+Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \emph{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.
+For example, the function @twice@ can be defined using the \CFA syntax for operator overloading:
 \begin{lstlisting}
 forall( otype T `| { T ?+?(T, T); }` ) T twice( T x ) { return x + x; } $\C{// ? denotes operands}$
 int val = twice( twice( 3.7 ) );
 \end{lstlisting}
+which works for any type @T@ with a matching addition operator. The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@. There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Ada} in its type analysis. The first approach has a late conversion from @int@ to @double@ on the final assignment, while the second has an eager conversion to @int@. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
+which works for any type @T@ with a matching addition operator.
+The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@.
+There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type~\cite{Cormack81,Baker82,Ada}, in its type analysis.
+The first approach has a late conversion from @double@ to @int@ on the final assignment, while the second has an eager conversion to @int@.
+\CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition.
 Crucial to the design of a new programming language are the libraries to access thousands of external software features.
 \CFA inherits a massive compatible library-base, where other programming languages must rewrite or provide fragile inter-language communication with C.
+Like \CC, \CFA inherits a massive compatible library-base, where other programming languages must rewrite or provide fragile inter-language communication with C.
 A simple example is leveraging the existing type-unsafe (@void *@) C @bsearch@ to binary search a sorted floating-point array:
 \begin{lstlisting}
 void * bsearch( const void * key, const void * base, size_t nmemb, size_t size,
                                 int (* compar)(const void *, const void *));
+                                int (* compar)( const void *, const void * ));
 int comp( const void * t1, const void * t2 ) { return *(double *)t1 < *(double *)t2 ? -1 :
                                 *(double *)t2 < *(double *)t1 ? 1 : 0; }
+double vals[10] = { /* 10 floating-point values */ };
+double key = 5.0;
+double key = 5.0, vals[10] = { /* 10 floating-point values */ };
 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp );      $\C{// search sorted array}$
 \end{lstlisting}
 …
         return (T *)bsearch( &key, arr, size, sizeof(T), comp ); }
 forall( otype T | { int ?<?( T, T ); } ) unsigned int bsearch( T key, const T * arr, size_t size ) {
         T *result = bsearch( key, arr, size );  $\C{// call first version}$
+        T * result = bsearch( key, arr, size ); $\C{// call first version}$
         return result ? result - arr : size; }  $\C{// pointer subtraction includes sizeof(T)}$
 double * val = bsearch( 5.0, vals, 10 );        $\C{// selection based on return type}$
 int posn = bsearch( 5.0, vals, 10 );
 \end{lstlisting}
+The nested routine @comp@ provides the hidden interface from typed \CFA to untyped (@void *@) C, plus the cast of the result.
+The nested function @comp@ provides the hidden interface from typed \CFA to untyped (@void *@) C, plus the cast of the result.
+Providing a hidden @comp@ function in \CC is awkward as lambdas do not use C calling-conventions and template declarations cannot appear at block scope.
 As well, an alternate kind of return is made available: position versus pointer to found element.
 \CC's type-system cannot disambiguate between the two versions of @bsearch@ because it does not use the return type in overload resolution, nor can \CC separately compile a templated @bsearch@.
 …
 For example, it is possible to write a type-safe \CFA wrapper @malloc@ based on the C @malloc@:
 \begin{lstlisting}
 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)(void *)malloc( (size_t)sizeof(T) ); }
+forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
 int * ip = malloc();                                            $\C{// select type and size from left-hand side}$
 double * dp = malloc();
 …
 where the return type supplies the type/size of the allocation, which is impossible in most type systems.
+Call-site inferencing and nested functions provide a localized form of inheritance. For example, the \CFA @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour:
+Call-site inferencing and nested functions provide a localized form of inheritance.
+For example, the \CFA @qsort@ only sorts in ascending order using @<@.
+However, it is trivial to locally change this behaviour:
 \begin{lstlisting}
 forall( otype T | { int ?<?( T, T ); } ) void qsort( const T * arr, size_t size ) { /* use C qsort */ }
 …
 \end{lstlisting}
 Within the block, the nested version of @<@ performs @>@ and this local version overrides the built-in @<@ so it is passed to @qsort@.
 Hence, programmers can easily form a local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
+Hence, programmers can easily form local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types.
 Finally, \CFA allows variable overloading:
+\lstDeleteShortInline@
+\par\smallskip
+\begin{tabular}{@{}l@{\hspace{\parindent}}|@{\hspace{\parindent}}l@{}}
+\begin{lstlisting}
+short int MAX = ...;
+int MAX = ...;
+double MAX = ...;
+\end{lstlisting}
+&
+\begin{lstlisting}
+short int s = MAX;  // select correct MAX
+int i = MAX;
+double d = MAX;
+\end{lstlisting}
+\end{tabular}
+\lstMakeShortInline@
+\smallskip\par\noindent
+Hence, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
+\begin{lstlisting}
+short int MAX = ...;   int MAX = ...;  double MAX = ...;
+short int s = MAX;    int i = MAX;    double d = MAX;   $\C{// select correct MAX}$
+\end{lstlisting}
+Here, the single name @MAX@ replaces all the C type-specific names: @SHRT_MAX@, @INT_MAX@, @DBL_MAX@.
 As well, restricted constant overloading is allowed for the values @0@ and @1@, which have special status in C, \eg the value @0@ is both an integer and a pointer literal, so its meaning depends on context.
+In addition, several operations are defined in terms values @0@ and @1@.
+For example,
+In addition, several operations are defined in terms values @0@ and @1@, \eg:
 \begin{lstlisting}
 int x;
+if (x)        // if (x != 0)
+        x++;    //   x += 1;
+\end{lstlisting}
+Every if statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
+if (x) x++                                                                      $\C{// if (x != 0) x += 1;}$
+\end{lstlisting}
+Every if and iteration statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
 Due to these rewrite rules, the values @0@ and @1@ have the types @zero_t@ and @one_t@ in \CFA, which allows overloading various operations for new types that seamlessly connect to all special @0@ and @1@ contexts.
 The types @zero_t@ and @one_t@ have special built in implicit conversions to the various integral types, and a conversion to pointer types for @0@, which allows standard C code involving @0@ and @1@ to work as normal.
 …
 forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) {  // use trait
         `T` total = { `0` };                                    $\C{// instantiate T from 0 by calling its constructor}$
+        for ( unsigned int i = 0; i < size; i += 1 )
+                total `+=` a[i];                                        $\C{// select appropriate +}$
+        for ( unsigned int i = 0; i < size; i += 1 ) total `+=` a[i]; $\C{// select appropriate +}$
         return total; }
 \end{lstlisting}
 In fact, the set of operators is incomplete, \eg no assignment, but @otype@ is syntactic sugar for the following implicit trait:
+In fact, the set of @summable@ trait operators is incomplete, as it is missing assignment for type @T@, but @otype@ is syntactic sugar for the following implicit trait:
 \begin{lstlisting}
 trait otype( dtype T | sized(T) ) {  // sized is a pseudo-trait for types with known size and alignment
 …
 \end{lstlisting}
 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack-allocatable, default or copy-initialized, assigned, and deleted.
+% As an example, the @sum@ function produces generated code something like the following (simplified for clarity and brevity)\TODO{fix example, maybe elide, it's likely too long with the more complicated function}:
+In summation, the \CFA type-system uses \emph{nominal typing} for concrete types, matching with the C type-system, and \emph{structural typing} for polymorphic types.
+Hence, trait names play no part in type equivalence;
+the names are simply macros for a list of polymorphic assertions, which are expanded at usage sites.
+Nevertheless, trait names form a logical subtype-hierarchy with @dtype@ at the top, where traits often contain overlapping assertions, \eg operator @+@.
+Traits are used like interfaces in Java or abstract base-classes in \CC, but without the nominal inheritance-relationships.
+Instead, each polymorphic function (or generic type) defines the structural type needed for its execution (polymorphic type-key), and this key is fulfilled at each call site from the lexical environment, which is similar to Go~\citep{Go} interfaces.
+Hence, new lexical scopes and nested functions are used extensively to create local subtypes, as in the @qsort@ example, without having to manage a nominal-inheritance hierarchy.
+(Nominal inheritance can be approximated with traits using marker variables or functions, as is done in Go.)
+% Nominal inheritance can be simulated with traits using marker variables or functions:
 % \begin{lstlisting}
+% void abs( size_t _sizeof_M, size_t _alignof_M,
+%               void (*_ctor_M)(void*), void (*_copy_M)(void*, void*),
+%               void (*_assign_M)(void*, void*), void (*_dtor_M)(void*),
+%               _Bool (*_lt_M)(void*, void*), void (*_neg_M)(void*, void*),
+%       void (*_ctor_M_zero)(void*, int),
+%               void* m, void* _rtn ) {                         $\C{// polymorphic parameter and return passed as void*}$
+%                                                                                       $\C{// M zero = { 0 };}$
+%       void* zero = alloca(_sizeof_M);                 $\C{// stack allocate zero temporary}$
+%       _ctor_M_zero(zero, 0);                                  $\C{// initialize using zero\_t constructor}$
+%                                                                                       $\C{// return m < zero ? -m : m;}$
+%       void *_tmp = alloca(_sizeof_M);
+%       _copy_M( _rtn,                                                  $\C{// copy-initialize return value}$
+%               _lt_M( m, zero ) ?                                      $\C{// check condition}$
+%                (_neg_M(m, _tmp), _tmp) :                      $\C{// negate m}$
+%                m);
+%       _dtor_M(_tmp); _dtor_M(zero);                   $\C{// destroy temporaries}$
+% trait nominal(otype T) {
+%     T is_nominal;
+% };
+% int is_nominal;                                                               $\C{// int now satisfies the nominal trait}$
+% \end{lstlisting}
+%
+% Traits, however, are significantly more powerful than nominal-inheritance interfaces; most notably, traits may be used to declare a relationship \emph{among} multiple types, a property that may be difficult or impossible to represent in nominal-inheritance type systems:
+% \begin{lstlisting}
+% trait pointer_like(otype Ptr, otype El) {
+%     lvalue El *?(Ptr);                                                $\C{// Ptr can be dereferenced into a modifiable value of type El}$
 % }
+% struct list {
+%     int value;
+%     list * next;                                                              $\C{// may omit "struct" on type names as in \CC}$
+% };
+% typedef list * list_iterator;
+%
+% lvalue int *?( list_iterator it ) { return it->value; }
 % \end{lstlisting}
+Traits may be used for many of the same purposes as interfaces in Java or abstract base classes in \CC. Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy, which is a form of structural inheritance, similar to the implementation of an interface in Go~\citep{Go}, as opposed to the nominal inheritance model of Java and \CC.
+Nominal inheritance can be simulated with traits using marker variables or functions:
+\begin{lstlisting}
+trait nominal(otype T) {
+    T is_nominal;
+% In the example above, @(list_iterator, int)@ satisfies @pointer_like@ by the user-defined dereference function, and @(list_iterator, list)@ also satisfies @pointer_like@ by the built-in dereference operator for pointers. Given a declaration @list_iterator it@, @*it@ can be either an @int@ or a @list@, with the meaning disambiguated by context (\eg @int x = *it;@ interprets @*it@ as an @int@, while @(*it).value = 42;@ interprets @*it@ as a @list@).
+% While a nominal-inheritance system with associated types could model one of those two relationships by making @El@ an associated type of @Ptr@ in the @pointer_like@ implementation, few such systems could model both relationships simultaneously.
+\section{Generic Types}
+One of the known shortcomings of standard C is that it does not provide reusable type-safe abstractions for generic data structures and algorithms.
+Broadly speaking, there are three approaches to implement abstract data-structures in C.
+One approach is to write bespoke data structures for each context in which they are needed.
+While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures.
+A second approach is to use @void *@--based polymorphism, \eg the C standard-library functions @bsearch@ and @qsort@; an approach which does allow reuse of code for common functionality.
+However, basing all polymorphism on @void *@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requiring a number of extra function parameters, pointer indirection, and dynamic allocation that would not otherwise be needed.
+A third approach to generic code is to use preprocessor macros, which does allow the generated code to be both generic and type-checked, but errors may be difficult to interpret.
+Furthermore, writing and using preprocessor macros can be unnatural and inflexible.
+\CC, Java, and other languages use \emph{generic types} to produce type-safe abstract data-types.
+\CFA also implements generic types that integrate efficiently and naturally with the existing polymorphic functions, while retaining backwards compatibility with C and providing separate compilation.
+However, for known concrete parameters, the generic-type definition can be inlined, like \CC templates.
+A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration, and instantiated using a parenthesized list of types after the type name:
+\begin{lstlisting}
+forall( otype R, otype S ) struct pair {
+        R first;
+        S second;
 };
+int is_nominal;                                                         $\C{// int now satisfies the nominal trait}$
+\end{lstlisting}
+Traits, however, are significantly more powerful than nominal-inheritance interfaces; most notably, traits may be used to declare a relationship \emph{among} multiple types, a property that may be difficult or impossible to represent in nominal-inheritance type systems:
+\begin{lstlisting}
+trait pointer_like(otype Ptr, otype El) {
+    lvalue El *?(Ptr);                                          $\C{// Ptr can be dereferenced into a modifiable value of type El}$
+}
+struct list {
+    int value;
+    list *next;                                                         $\C{// may omit "struct" on type names as in \CC}$
+};
+typedef list *list_iterator;
+lvalue int *?( list_iterator it ) { return it->value; }
+\end{lstlisting}
+In the example above, @(list_iterator, int)@ satisfies @pointer_like@ by the user-defined dereference function, and @(list_iterator, list)@ also satisfies @pointer_like@ by the built-in dereference operator for pointers. Given a declaration @list_iterator it@, @*it@ can be either an @int@ or a @list@, with the meaning disambiguated by context (\eg @int x = *it;@ interprets @*it@ as an @int@, while @(*it).value = 42;@ interprets @*it@ as a @list@).
+While a nominal-inheritance system with associated types could model one of those two relationships by making @El@ an associated type of @Ptr@ in the @pointer_like@ implementation, few such systems could model both relationships simultaneously.
+\section{Generic Types}
+One of the known shortcomings of standard C is that it does not provide reusable type-safe abstractions for generic data structures and algorithms. Broadly speaking, there are three approaches to create data structures in C. One approach is to write bespoke data structures for each context in which they are needed. While this approach is flexible and supports integration with the C type-checker and tooling, it is also tedious and error-prone, especially for more complex data structures. A second approach is to use @void*@-based polymorphism. This approach is taken by the C standard library functions @qsort@ and @bsearch@, and does allow the use of common code for common functionality. However, basing all polymorphism on @void*@ eliminates the type-checker's ability to ensure that argument types are properly matched, often requires a number of extra function parameters, and also adds pointer indirection and dynamic allocation to algorithms and data structures that would not otherwise require them. A third approach to generic code is to use pre-processor macros to generate it -- this approach does allow the generated code to be both generic and type-checked, though any errors produced may be difficult to interpret. Furthermore, writing and invoking C code as preprocessor macros is unnatural and somewhat inflexible.
+Other C-like languages such as \CC and Java use \emph{generic types} to produce type-safe abstract data types. \CFA implements generic types with some care taken that the generic types design for \CFA integrates efficiently and naturally with the existing polymorphic functions in \CFA while retaining backwards compatibility with C; maintaining separate compilation is a particularly important constraint on the design. However, where the concrete parameters of the generic type are known, there is no extra overhead for the use of a generic type, as for \CC templates.
+A generic type can be declared by placing a @forall@ specifier on a @struct@ or @union@ declaration, and instantiated using a parenthesized list of types after the type name:
+\begin{lstlisting}
+forall(otype R, otype S) struct pair {
+    R first;
+    S second;
+};
+forall(otype T)
+T value( pair(const char*, T) p ) { return p.second; }
+forall(dtype F, otype T)
+T value_p( pair(F*, T*) p ) { return *p.second; }
+pair(const char*, int) p = { "magic", 42 };
+forall( otype T ) T value( pair( const char *, T ) p ) { return p.second; }
+forall( dtype F, otype T ) T value_p( pair( F *, T * ) p ) { return * p.second; }
+pair( const char *, int ) p = { "magic", 42 };
 int magic = value( p );
+pair(void*, int*) q = { 0, &p.second };
+pair( void *, int * ) q = { 0, &p.second };
 magic = value_p( q );
 double d = 1.0;
 pair(double*, double*) r = { &d, &d };
+pair( double *, double * ) r = { &d, &d };
 d = value_p( r );
 \end{lstlisting}
+\CFA classifies generic types as either \emph{concrete} or \emph{dynamic}. Concrete generic types have a fixed memory layout regardless of type parameters, while dynamic generic types vary in their in-memory layout depending on their type parameters. A type may have polymorphic parameters but still be concrete; in \CFA such types are called \emph{dtype-static}. Polymorphic pointers are an example of dtype-static types -- @forall(dtype T) T*@ is a polymorphic type, but for any @T@ chosen, @T*@ has exactly the same in-memory representation as a @void*@, and can therefore be represented by a @void*@ in code generation.
+\CFA generic types may also specify constraints on their argument type to be checked by the compiler. For example, consider the following declaration of a sorted set-type, which ensures that the set key supports equality and relational comparison:
+\begin{lstlisting}
+forall(otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); })
+  struct sorted_set;
+\end{lstlisting}
+\subsection{Concrete Generic Types}
+The \CFA translator instantiates concrete generic types by template-expanding them to fresh struct types; concrete generic types can therefore be used with zero runtime overhead. To enable inter-operation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated struct declarations where appropriate. For example, a function declaration that accepts or returns a concrete generic type produces a declaration for the instantiated struct in the same scope, which all callers that can see that declaration may reuse. As an example of the expansion, the concrete instantiation for @pair(const char*, int)@ looks like this:
+\CFA classifies generic types as either \emph{concrete} or \emph{dynamic}.
+Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters.
+A type may have polymorphic parameters but still be concrete, called \emph{dtype-static}.
+Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@  is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation.
+\CFA generic types also allow checked argument-constraints.
+For example, the following declaration of a sorted set-type ensures the set key supports equality and relational comparison:
+\begin{lstlisting}
+forall( otype Key | { _Bool ?==?(Key, Key); _Bool ?<?(Key, Key); } ) struct sorted_set;
+\end{lstlisting}
+\subsection{Concrete Generic-Types}
+The \CFA translator template-expands concrete generic-types into new structure types, affording maximal inlining.
+To enable inter-operation among equivalent instantiations of a generic type, the translator saves the set of instantiations currently in scope and reuses the generated structure declarations where appropriate.
+For example, a function declaration that accepts or returns a concrete generic-type produces a declaration for the instantiated struct in the same scope, which all callers may reuse.
+For example, the concrete instantiation for @pair( const char *, int )@ is:
 \begin{lstlisting}
 struct _pair_conc1 {
         const char* first;
+        const char * first;
         int second;
 };
 \end{lstlisting}
+A concrete generic type with dtype-static parameters is also expanded to a struct type, but this struct type is used for all matching instantiations. In the example above, the @pair(F*, T*)@ parameter to @value_p@ is such a type; its expansion looks something like this, and is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate:
+A concrete generic-type with dtype-static parameters is also expanded to a structure type, but this type is used for all matching instantiations.
+In the above example, the @pair( F *, T * )@ parameter to @value_p@ is such a type; its expansion is below and it is used as the type of the variables @q@ and @r@ as well, with casts for member access where appropriate:
 \begin{lstlisting}
 struct _pair_conc0 {
         void* first;
         void* second;
+        void * first;
+        void * second;
 };
 \end{lstlisting}
+\subsection{Dynamic Generic Types}
+Though \CFA implements concrete generic types efficiently, it also has a fully general system for computing with dynamic generic types. As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller. Dynamic generic structs also have implicit size and alignment parameters, and also an \emph{offset array} which contains the offsets of each member of the struct\footnote{Dynamic generic unions need no such offset array, as all members are at offset 0; the size and alignment parameters are still provided for dynamic unions, however.}. Access to members\footnote{The \lstinline@offsetof@ macro is implemented similarly.} of a dynamic generic struct is provided by adding the corresponding member of the offset array to the struct pointer at runtime, essentially moving a compile-time offset calculation to runtime where necessary.
+These offset arrays are statically generated where possible. If a dynamic generic type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume that the generic type is complete (that is, has a known layout) at any call-site, and the offset array is passed from the caller; if the generic type is concrete at the call site the elements of this offset array can even be statically generated using the C @offsetof@ macro. As an example, @p.second@ in the @value@ function above is implemented as @*(p + _offsetof_pair[1])@, where @p@ is a @void*@, and @_offsetof_pair@ is the offset array passed in to @value@ for @pair(const char*, T)@. The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc1, first), offsetof(_pair_conc1, second) };@.
+In some cases the offset arrays cannot be statically generated. For instance, modularity is generally provided in C by including an opaque forward-declaration of a struct and associated accessor and mutator routines in a header file, with the actual implementations in a separately-compiled \texttt{.c} file. \CFA supports this pattern for generic types, and in this instance the caller does not know the actual layout or size of the dynamic generic type, and only holds it by pointer. The \CFA translator automatically generates \emph{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed in to a function from that function's caller. These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic struct (un-@sized@ parameters are forbidden from the language from being used in a context that affects layout). Results of these layout functions are cached so that they are only computed once per type per function.%, as in the example below for @pair@.
+% \begin{lstlisting}
+% static inline void _layoutof_pair(size_t* _szeof_pair, size_t* _alignof_pair, size_t* _offsetof_pair,
+%               size_t _szeof_R, size_t _alignof_R, size_t _szeof_S, size_t _alignof_S) {
+%     *_szeof_pair = 0; // default values
+%     *_alignof_pair = 1;
+%       // add offset, size, and alignment of first field
+%     _offsetof_pair[0] = *_szeof_pair;
+%     *_szeof_pair += _szeof_R;
+%     if ( *_alignof_pair < _alignof_R ) *_alignof_pair = _alignof_R;
+%       // padding, offset, size, and alignment of second field
+%     if ( *_szeof_pair & (_alignof_S - 1) )
+%               *_szeof_pair += (_alignof_S - ( *_szeof_pair & (_alignof_S - 1) ) );
+%     _offsetof_pair[1] = *_szeof_pair;
+%     *_szeof_pair += _szeof_S;
+%     if ( *_alignof_pair < _alignof_S ) *_alignof_pair = _alignof_S;
+%       // pad to struct alignment
+%     if ( *_szeof_pair & (*_alignof_pair - 1) )
+%               *_szeof_pair += ( *_alignof_pair - ( *_szeof_pair & (*_alignof_pair - 1) ) );
+% }
+% \end{lstlisting}
+Layout functions also allow generic types to be used in a function definition without reflecting them in the function signature. For instance, a function that strips duplicate values from an unsorted @vector(T)@ would likely have a pointer to the vector as its only explicit parameter, but use some sort of @set(T)@ internally to test for duplicate values. This function could acquire the layout for @set(T)@ by calling its layout function with the layout of @T@ implicitly passed into the function.
+Whether a type is concrete, dtype-static, or dynamic is decided based solely on the type parameters and @forall@ clause on the struct declaration. This design allows opaque forward declarations of generic types like @forall(otype T) struct Box;@ -- like in C, all uses of @Box(T)@ can be in a separately compiled translation unit, and callers from other translation units know the proper calling conventions to use. If the definition of a struct type was included in the decision of whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T) struct unique_ptr { T* p };@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.), but preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off.
+\subsection{Dynamic Generic-Types}
+Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types.
+As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller.
+Dynamic generic-types also have an \emph{offset array} containing structure-member offsets.
+A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary.
+Access to members of a dynamic structure is provided at runtime via base-displacement addressing with the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime.
+The offset arrays are statically generated where possible.
+If a dynamic generic-type is declared to be passed or returned by value from a polymorphic function, the translator can safely assume the generic type is complete (\ie has a known layout) at any call-site, and the offset array is passed from the caller;
+if the generic type is concrete at the call site, the elements of this offset array can even be statically generated using the C @offsetof@ macro.
+As an example, @p.second@ in the @value@ function above is implemented as @*(p + _offsetof_pair[1])@, where @p@ is a @void *@, and @_offsetof_pair@ is the offset array passed into @value@ for @pair( const char *, T )@.
+The offset array @_offsetof_pair@ is generated at the call site as @size_t _offsetof_pair[] = { offsetof(_pair_conc1, first), offsetof(_pair_conc1, second) }@.
+In some cases the offset arrays cannot be statically generated.
+For instance, modularity is generally provided in C by including an opaque forward-declaration of a structure and associated accessor and mutator functions in a header file, with the actual implementations in a separately-compiled @.c@ file.
+\CFA supports this pattern for generic types, but the caller does not know the actual layout or size of the dynamic generic-type, and only holds it by a pointer.
+The \CFA translator automatically generates \emph{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller.
+These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic structure (un@sized@ parameters are forbidden from being used in a context that affects layout).
+Results of these layout functions are cached so that they are only computed once per type per function. %, as in the example below for @pair@.
+Layout functions also allow generic types to be used in a function definition without reflecting them in the function signature.
+For instance, a function that strips duplicate values from an unsorted @vector(T)@ would likely have a pointer to the vector as its only explicit parameter, but use some sort of @set(T)@ internally to test for duplicate values.
+This function could acquire the layout for @set(T)@ by calling its layout function with the layout of @T@ implicitly passed into the function.
+Whether a type is concrete, dtype-static, or dynamic is decided solely on the type parameters and @forall@ clause on a declaration.
+This design allows opaque forward declarations of generic types, \eg @forall(otype T) struct Box@ -- like in C, all uses of @Box(T)@ can be separately compiled, and callers from other translation units know the proper calling conventions to use.
+If the definition of a structure type is included in deciding whether a generic type is dynamic or concrete, some further types may be recognized as dtype-static (\eg @forall(otype T) struct unique_ptr { T * p }@ does not depend on @T@ for its layout, but the existence of an @otype@ parameter means that it \emph{could}.), but preserving separate compilation (and the associated C compatibility) in the existing design is judged to be an appropriate trade-off.
 \subsection{Applications}
 \label{sec:generic-apps}
+The reuse of dtype-static struct instantiations enables some useful programming patterns at zero runtime cost. The most important such pattern is using @forall(dtype T) T*@ as a type-checked replacement for @void*@, as in this example, which takes a @qsort@ or @bsearch@-compatible comparison routine and creates a similar lexicographic comparison for pairs of pointers:
+\begin{lstlisting}
+forall(dtype T)
+int lexcmp( pair(T*, T*)* a, pair(T*, T*)* b, int (*cmp)(T*, T*) ) {
+        int c = cmp(a->first, b->first);
+        if ( c == 0 ) c = cmp(a->second, b->second);
+        return c;
+}
+\end{lstlisting}
+Since @pair(T*, T*)@ is a concrete type, there are no added implicit parameters to @lexcmp@, so the code generated by \CFA is effectively identical to a version of this function written in standard C using @void*@, yet the \CFA version is type-checked to ensure that the fields of both pairs and the arguments to the comparison function match in type.
+Another useful pattern enabled by reused dtype-static type instantiations is zero-cost ``tag'' structs. Sometimes a particular bit of information is only useful for type-checking, and can be omitted at runtime. Tag structs can be used to provide this information to the compiler without further runtime overhead, as in the following example:
+The reuse of dtype-static structure instantiations enables useful programming patterns at zero runtime cost.
+The most important such pattern is using @forall(dtype T) T *@ as a type-checked replacement for @void *@, \eg creating a lexicographic comparison for pairs of pointers used by @bsearch@ or @qsort@:
+\begin{lstlisting}
+forall(dtype T) int lexcmp( pair( T *, T * ) * a, pair( T *, T * ) * b, int (* cmp)( T *, T * ) ) {
+        return cmp( a->first, b->first ) ? : cmp( a->second, b->second );
+}
+\end{lstlisting}
+Since @pair(T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the fields of both pairs and the arguments to the comparison function match in type.
+Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \emph{tag-structures}.
+Sometimes information is only used for type-checking and can be omitted at runtime, \eg:
 \begin{lstlisting}
 forall(dtype Unit) struct scalar { unsigned long value; };
 struct metres {};
 struct litres {};
+forall(dtype U)
+scalar(U) ?+?(scalar(U) a, scalar(U) b) {
+forall(dtype U) scalar(U) ?+?( scalar(U) a, scalar(U) b ) {
         return (scalar(U)){ a.value + b.value };
+}
 scalar(metres) half_marathon = { 21093 };
 scalar(litres) swimming_pool = { 2500000 };
 scalar(metres) marathon = half_marathon + half_marathon;
 scalar(litres) two_pools = swimming_pool + swimming_pool;
+marathon + swimming_pool; // ERROR -- caught by compiler
+\end{lstlisting}
+@scalar@ is a dtype-static type, so all uses of it use a single struct definition, containing only a single @unsigned long@, and can share the same implementations of common routines like @?+?@ -- these implementations may even be separately compiled, unlike \CC template functions. However, the \CFA type-checker ensures that matching types are used by all calls to @?+?@, preventing nonsensical computations like adding the length of a marathon to the volume of an olympic pool.
+marathon + swimming_pool;                                       $\C{// compilation ERROR}$
+\end{lstlisting}
+@scalar@ is a dtype-static type, so all uses have a single structure definition, containing @unsigned long@, and can share the same implementations of common functions like @?+?@.
+These implementations may even be separately compiled, unlike \CC template functions.
+However, the \CFA type-checker ensures matching types are used by all calls to @?+?@, preventing nonsensical computations like adding a length to a volume.
 \section{Tuples}
 \label{sec:tuples}
+The @pair(R, S)@ generic type used as an example in the previous section can be considered a special case of a more general \emph{tuple} data structure. The authors have implemented tuples in \CFA, with a design particularly motivated by two use cases: \emph{multiple-return-value functions} and \emph{variadic functions}.
+In standard C, functions can return at most one value. This restriction results in code that emulates functions with multiple return values by \emph{aggregation} or by \emph{aliasing}. In the former situation, the function designer creates a record type that combines all of the return values into a single type. Unfortunately, the designer must come up with a name for the return type and for each of its fields. Unnecessary naming is a common programming language issue, introducing verbosity and a complication of the user's mental model. As such, this technique is effective when used sparingly, but can quickly get out of hand if many functions need to return different combinations of types. In the latter approach, the designer simulates multiple return values by passing the additional return values as pointer parameters. The pointer parameters are assigned inside of the routine body to emulate a return. Using this approach, the caller is directly responsible for allocating storage for the additional temporary return values. This responsibility complicates the call site with a sequence of variable declarations leading up to the call. Also, while a disciplined use of @const@ can give clues about whether a pointer parameter is going to be used as an out parameter, it is not immediately obvious from only the routine signature whether the callee expects such a parameter to be initialized before the call. Furthermore, while many C routines that accept pointers are designed so that it is safe to pass @NULL@ as a parameter, there are many C routines that are not null-safe. On a related note, C does not provide a standard mechanism to state that a parameter is going to be used as an additional return value, which makes the job of ensuring that a value is returned more difficult for the compiler.
+C does provide a mechanism for variadic functions through manipulation of @va_list@ objects, but it is notoriously type-unsafe. A variadic function is one that contains at least one parameter, followed by @...@ as the last token in the parameter list. In particular, some form of \emph{argument descriptor} is needed to inform the function of the number of arguments and their types, commonly a format string or counter parameter. It is important to note that both of these mechanisms are inherently redundant, because they require the user to specify information that the compiler knows explicitly. This required repetition is error prone, because it is easy for the user to add or remove arguments without updating the argument descriptor. In addition, C requires the programmer to hard code all of the possible expected types. As a result, it is cumbersome to write a variadic function that is open to extension. For example, consider a simple function that sums $N$ @int@s:
+\begin{lstlisting}
+int sum(int N, ...) {
+  va_list args;
+  va_start(args, N);  // must manually specify last non-variadic argument
+  int ret = 0;
+  while(N) {
+    ret += va_arg(args, int);  // must specify type
+    N--;
+  }
+  va_end(args);
+  return ret;
+}
+sum(3, 10, 20, 30);  // must keep initial counter argument in sync
+\end{lstlisting}
+The @va_list@ type is a special C data type that abstracts variadic argument manipulation. The @va_start@ macro initializes a @va_list@, given the last named parameter. Each use of the @va_arg@ macro allows access to the next variadic argument, given a type. Since the function signature does not provide any information on what types can be passed to a variadic function, the compiler does not perform any error checks on a variadic call. As such, it is possible to pass any value to the @sum@ function, including pointers, floating-point numbers, and structures. In the case where the provided type is not compatible with the argument's actual type after default argument promotions, or if too many arguments are accessed, the behaviour is undefined~\citep{C11}. Furthermore, there is no way to perform the necessary error checks in the @sum@ function at run-time, since type information is not carried into the function body. Since they rely on programmer convention rather than compile-time checks, variadic functions are inherently unsafe.
+In practice, compilers can provide warnings to help mitigate some of the problems. For example, GCC provides the @format@ attribute to specify that a function uses a format string, which allows the compiler to perform some checks related to the standard format specifiers. Unfortunately, this attribute does not permit extensions to the format string syntax, so a programmer cannot extend it to warn for mismatches with custom types.
+In many languages, functions can return at most one value;
+however, many operations have multiple outcomes, some exceptional.
+Consider C's @div@ and @remquo@ functions, which return the quotient and remainder for a division of integer and floating-point values, respectively.
+\begin{lstlisting}
+typedef struct { int quo, rem; } div_t;         $\C{// from include stdlib.h}$
+div_t div( int num, int den );
+double remquo( double num, double den, int * quo );
+div_t qr = div( 13, 5 );                                        $\C{// return quotient/remainder aggregate}$
+int q;
+double r = remquo( 13.5, 5.2, &q );                     $\C{// return remainder, alias quotient}$
+\end{lstlisting}
+@div@ aggregates the quotient/remainder in a structure, while @remquo@ aliases a parameter to an argument.
+Both approaches are awkward.
+Alternatively, a programming language can directly support returning multiple values, \eg in \CFA:
+\begin{lstlisting}
+[ int, int ] div( int num, int den );           $\C{// return two integers}$
+[ double, double ] div( double num, double den ); $\C{// return two doubles}$
+int q, r;                                                                       $\C{// overloaded variable names}$
+double q, r;
+[ q, r ] = div( 13, 5 );                                        $\C{// select appropriate div and q, r}$
+[ q, r ] = div( 13.5, 5.2 );                            $\C{// assign into tuple}$
+\end{lstlisting}
+Clearly, this approach is straightforward to understand and use;
+therefore, why do few programming languages support this obvious feature or provide it awkwardly?
+The answer is that there are complex consequences that cascade through multiple aspects of the language, especially the type-system.
+This section show these consequences and how \CFA handles them.
 \subsection{Tuple Expressions}
+The tuple extensions in \CFA can express multiple return values and variadic function parameters in an efficient and type-safe manner. \CFA introduces \emph{tuple expressions} and \emph{tuple types}. A tuple expression is an expression producing a fixed-size, ordered list of values of heterogeneous types. The type of a tuple expression is the tuple of the subexpression types, or a \emph{tuple type}. In \CFA, a tuple expression is denoted by a comma-separated list of expressions enclosed in square brackets. For example, the expression @[5, 'x', 10.5]@ has type @[int, char, double]@. The previous expression has three \emph{components}. Each component in a tuple expression can be any \CFA expression, including another tuple expression. The order of evaluation of the components in a tuple expression is unspecified, to allow a compiler the greatest flexibility for program optimization. It is, however, guaranteed that each component of a tuple expression is evaluated for side-effects, even if the result is not used. Multiple-return-value functions can equivalently be called \emph{tuple-returning functions}.
+\CFA allows declaration of \emph{tuple variables}, variables of tuple type. For example:
+\begin{lstlisting}
+[int, char] most_frequent(const char*);
+const char* str = "hello, world!";
+[int, char] freq = most_frequent(str);
+printf("%s -- %d %c\n", str, freq);
+\end{lstlisting}
+In this example, the type of the @freq@ and the return type of @most_frequent@ are both tuple types. Also of note is how the tuple expression @freq@ is implicitly flattened into separate @int@ and @char@ arguments to @printf@; this code snippet could have been shortened by replacing the last two lines with @printf("%s -- %d %c\n", str, most_frequent(str));@ using exactly the same mechanism.
+In addition to variables of tuple type, it is also possible to have pointers to tuples, and arrays of tuples. Tuple types can be composed of any types, except for array types, since arrays are not of fixed size, which makes tuple assignment difficult when a tuple contains an array.
+\begin{lstlisting}
+[double, int] di;
+[double, int] * pdi
+[double, int] adi[10];
+\end{lstlisting}
+This example declares a variable of type @[double, int]@, a variable of type pointer to @[double, int]@, and an array of ten @[double, int]@.
+The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site.
+The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly.
+As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \emph{tuple}.
+However, functions also use \emph{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF), \eg:
+\begin{lstlisting}
+printf( "%d %d\n", div( 13, 5 ) );                      $\C{// return values seperated into arguments}$
+\end{lstlisting}
+Here, the values returned by @div@ are composed with the call to @printf@ by flattening the tuple into separate arguments.
+However, the \CFA type-system must support significantly more complex composition:
+\begin{lstlisting}
+[ int, int ] foo$\(_1\)$( int );
+[ double ] foo$\(_2\)$( int );
+void bar( int, double, double );
+bar( foo( 3 ), foo( 3 ) );
+\end{lstlisting}
+The type-resolver only has the tuple return-types to resolve the call to @bar@ as the @foo@ parameters are identical, which involves unifying the possible @foo@ functions with @bar@'s parameter list.
+No combination of @foo@s are an exact match with @bar@'s parameters, so the resolver applies C conversions.
+The minimal cost is @bar( foo@$_1$@( 3 ), foo@$_2$@( 3 ) )@, giving (@int@, {\color{ForestGreen}@int@}, @double@) to (@int@, {\color{ForestGreen}@double@}, @double@) with one {\color{ForestGreen}safe} (widening) conversion from @int@ to @double@ versus ({\color{red}@double@}, {\color{ForestGreen}@int@}, {\color{ForestGreen}@int@}) to ({\color{red}@int@}, {\color{ForestGreen}@double@}, {\color{ForestGreen}@double@}) with one {\color{red}unsafe} (narrowing) conversion from @double@ to @int@ and two safe conversions.
+\subsection{Tuple Variables}
+An important observation from function composition is that new variable names are not required to initialize parameters from an MRVF.
+\CFA also allows declaration of tuple variables that can be initialized from an MRVF, since it can be awkward to declare multiple variables of different types, \eg:
+\begin{lstlisting}
+[ int, int ] qr = div( 13, 5 );                         $\C{// tuple-variable declaration and initialization}$
+[ double, double ] qr = div( 13.5, 5.2 );
+\end{lstlisting}
+where the tuple variable-name serves the same purpose as the parameter name(s).
+Tuple variables can be composed of any types, except for array types, since array sizes are generally unknown.
+One way to access the tuple-variable components is with assignment or composition:
+\begin{lstlisting}
+[ q, r ] = qr;                                                          $\C{// access tuple-variable components}$
+printf( "%d %d\n", qr );
+\end{lstlisting}
+\CFA also supports \emph{tuple indexing} to access single components of a tuple expression:
+\begin{lstlisting}
+[int, int] * p = &qr;                                           $\C{// tuple pointer}$
+int rem = qr.1;                                                         $\C{// access remainder}$
+int quo = div( 13, 5 ).0;                                       $\C{// access quotient}$
+p->0 = 5;                                                                       $\C{// change quotient}$
+bar( qr.1, qr );                                                        $\C{// pass remainder and quotient/remainder}$
+rem = [42, div( 13, 5 )].0.1;                           $\C{// access 2nd component of 1st component of tuple expression}$
+\end{lstlisting}
 \subsection{Flattening and Restructuring}
+In function call contexts, tuples support implicit flattening and restructuring conversions. Tuple flattening recursively expands a tuple into the list of its basic components. Tuple structuring packages a list of expressions into a value of tuple type.
+\begin{lstlisting}
+int f(int, int);
+int g([int, int]);
+int h(int, [int, int]);
+In function call contexts, tuples support implicit flattening and restructuring conversions.
+Tuple flattening recursively expands a tuple into the list of its basic components.
+Tuple structuring packages a list of expressions into a value of tuple type, \eg:
+%\lstDeleteShortInline@%
+%\par\smallskip
+%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
+\begin{lstlisting}
+int f( int, int );
+int g( [int, int] );
+int h( int, [int, int] );
 [int, int] x;
 int y;
+f(x);      // flatten
+g(y, 10);  // structure
+h(x, y);   // flatten & structure
+\end{lstlisting}
+In \CFA, each of these calls is valid. In the call to @f@, @x@ is implicitly flattened so that the components of @x@ are passed as the two arguments to @f@. For the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the type of the parameter of @g@. Finally, in the call to @h@, @y@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@. The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both single- and multiple-return-value functions, and with any number of arguments of arbitrarily complex structure.
+% In {K-W C} \citep{Buhr94a,Till89}, a precursor to \CFA, there were 4 tuple coercions: opening, closing, flattening, and structuring. Opening coerces a tuple value into a tuple of values, while closing converts a tuple of values into a single tuple value. Flattening coerces a nested tuple into a flat tuple, \ie it takes a tuple with tuple components and expands it into a tuple with only non-tuple components. Structuring moves in the opposite direction, \ie it takes a flat tuple value and provides structure by introducing nested tuple components.
+In \CFA, the design has been simplified to require only the two conversions previously described, which trigger only in function call and return situations. Specifically, the expression resolution algorithm examines all of the possible alternatives for an expression to determine the best match. In resolving a function call expression, each combination of function value and list of argument alternatives is examined. Given a particular argument list and function value, the list of argument alternatives is flattened to produce a list of non-tuple valued expressions. Then the flattened list of expressions is compared with each value in the function's parameter list. If the parameter's type is not a tuple type, then the current argument value is unified with the parameter type, and on success the next argument and parameter are examined. If the parameter's type is a tuple type, then the structuring conversion takes effect, recursively applying the parameter matching algorithm using the tuple's component types as the parameter list types. Assuming a successful unification, eventually the algorithm gets to the end of the tuple type, which causes all of the matching expressions to be consumed and structured into a tuple expression. For example, in
+\begin{lstlisting}
+int f(int, [double, int]);
+f([5, 10.2], 4);
+\end{lstlisting}
+There is only a single definition of @f@, and 3 arguments with only single interpretations. First, the argument alternative list @[5, 10.2], 4@ is flattened to produce the argument list @5, 10.2, 4@. Next, the parameter matching algorithm begins, with $P =~$@int@ and $A =~$@int@, which unifies exactly. Moving to the next parameter and argument, $P =~$@[double, int]@ and $A =~$@double@. This time, the parameter is a tuple type, so the algorithm applies recursively with $P' =~$@double@ and $A =~$@double@, which unifies exactly. Then $P' =~$@int@ and $A =~$@double@, which again unifies exactly. At this point, the end of $P'$ has been reached, so the arguments @10.2, 4@ are structured into the tuple expression @[10.2, 4]@. Finally, the end of the parameter list $P$ has also been reached, so the final expression is @f(5, [10.2, 4])@.
+f( x );                 $\C{// flatten}$
+g( y, 10 );             $\C{// structure}$
+h( x, y );              $\C{// flatten and structure}$
+\end{lstlisting}
+%\end{lstlisting}
+%&
+%\begin{lstlisting}
+%\end{tabular}
+%\smallskip\par\noindent
+%\lstMakeShortInline@%
+In the call to @f@, @x@ is implicitly flattened so the components of @x@ are passed as the two arguments.
+In the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the parameter type of @g@.
+Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.
+The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both SRVF and MRVF, and with any number of arguments of arbitrarily complex structure.
+\subsection{Tuple Assignment}
+An assignment where the left side is a tuple type is called \emph{tuple assignment}.
+There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \emph{multiple} and \emph{mass assignment}, respectively.
+%\lstDeleteShortInline@%
+%\par\smallskip
+%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
+\begin{lstlisting}
+int x = 10;
+double y = 3.5;
+[int, double] z;
+z = [x, y];                                                                     $\C{// multiple assignment}$
+[x, y] = z;                                                                     $\C{// multiple assignment}$
+z = 10;                                                                         $\C{// mass assignment}$
+[y, x] = 3.14;                                                          $\C{// mass assignment}$
+\end{lstlisting}
+%\end{lstlisting}
+%&
+%\begin{lstlisting}
+%\end{tabular}
+%\smallskip\par\noindent
+%\lstMakeShortInline@%
+Both kinds of tuple assignment have parallel semantics, so that each value on the left and right side is evaluated before any assignments occur.
+As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function, \eg, @[x, y] = [y, x]@.
+This semantics means mass assignment differs from C cascading assignment (\eg @a = b = c@) in that conversions are applied in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
+For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, yielding @y == 3.14@ and @x == 3@;
+whereas C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, yielding @3@ in @y@ and @x@.
+Finally, tuple assignment is an expression where the result type is the type of the left-hand side of the assignment, just like all other assignment expressions in C.
+This example shows mass, multiple, and cascading assignment used in one expression:
+\begin{lstlisting}
+void f( [int, int] );
+f( [x, y] = z = 1.5 );                                          $\C{// assignments in parameter list}$
+\end{lstlisting}
 \subsection{Member Access}
+At times, it is desirable to access a single component of a tuple-valued expression without creating unnecessary temporary variables to assign to. Given a tuple-valued expression @e@ and a compile-time constant integer $i$ where $0 \leq i < n$, where $n$ is the number of components in @e@, @e.i@ accesses the $i$\textsuperscript{th} component of @e@. For example,
+\begin{lstlisting}
+[int, double] x;
+[char *, int] f();
+void g(double, int);
+[int, double] * p;
+int y = x.0;  // access int component of x
+y = f().1;  // access int component of f
+p->0 = 5;  // access int component of tuple pointed-to by p
+g(x.1, x.0);  // rearrange x to pass to g
+double z = [x, f()].0.1;  // access second component of first component of tuple expression
+\end{lstlisting}
+As seen above, tuple-index expressions can occur on any tuple-typed expression, including tuple-returning functions, square-bracketed tuple expressions, and other tuple-index expressions, provided the retrieved component is also a tuple. This feature was proposed for {K-W C}, but never implemented~\citep[p.~45]{Till89}.
+It is possible to access multiple fields from a single expression using a \emph{member-access tuple expression}. The result is a single tuple expression whose type is the tuple of the types of the members. For example,
+It is also possible to access multiple fields from a single expression using a \emph{member-access}.
+The result is a single tuple-valued expression whose type is the tuple of the types of the members, \eg:
 \begin{lstlisting}
 struct S { int x; double y; char * z; } s;
+s.[x, y, z];
+\end{lstlisting}
+Here, the type of @s.[x, y, z]@ is @[int, double, char *]@. A member tuple expression has the form @a.[x, y, z];@ where @a@ is an expression with type @T@, where @T@ supports member access expressions, and @x, y, z@ are all members of @T@ with types @T$_x$@, @T$_y$@, and @T$_z$@ respectively. Then the type of @a.[x, y, z]@ is @[T$_x$, T$_y$, T$_z$]@.
+Since tuple index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg rearrange components, drop components, duplicate components, etc.):
+s.[x, y, z] = 0;
+\end{lstlisting}
+Here, the mass assignment sets all members of @s@ to zero.
+Since tuple-index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg rearrange, drop, and duplicate components).
+%\lstDeleteShortInline@%
+%\par\smallskip
+%\begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}}
 \begin{lstlisting}
 [int, int, long, double] x;
+void f(double, long);
+f(x.[0, 3]);          // f(x.0, x.3)
+x.[0, 1] = x.[1, 0];  // [x.0, x.1] = [x.1, x.0]
+[long, int, long] y = x.[2, 0, 2];
+\end{lstlisting}
+It is possible for a member tuple expression to contain other member access expressions:
+void f( double, long );
+x.[0, 1] = x.[1, 0];                                            $\C{// rearrange: [x.0, x.1] = [x.1, x.0]}$
+f( x.[0, 3] );                                                          $\C{// drop: f(x.0, x.3)}$
+[int, int, int] y = x.[2, 0, 2];                        $\C{// duplicate: [y.0, y.1, y.2] = [x.2, x.0.x.2]}$
+\end{lstlisting}
+%\end{lstlisting}
+%&
+%\begin{lstlisting}
+%\end{tabular}
+%\smallskip\par\noindent
+%\lstMakeShortInline@%
+It is also possible for a member access to contain other member accesses, \eg:
 \begin{lstlisting}
 struct A { double i; int j; };
 struct B { int * k; short l; };
 struct C { int x; A y; B z; } v;
+v.[x, y.[i, j], z.k];
+\end{lstlisting}
+This expression is equivalent to @[v.x, [v.y.i, v.y.j], v.z.k]@. That is, the aggregate expression is effectively distributed across the tuple, which allows simple and easy access to multiple components in an aggregate, without repetition. It is guaranteed that the aggregate expression to the left of the @.@ in a member tuple expression is evaluated exactly once. As such, it is safe to use member tuple expressions on the result of a side-effecting function.
+\subsection{Tuple Assignment}
+In addition to tuple-index expressions, individual components of tuples can be accessed by a \emph{destructuring assignment} which has a tuple expression with lvalue components on its left-hand side. More generally, an assignment where the left-hand side of the assignment operator has a tuple type is called \emph{tuple assignment}. There are two kinds of tuple assignment depending on whether the right-hand side of the assignment operator has a tuple type or a non-tuple type, called \emph{multiple assignment} and \emph{mass assignment}, respectively.
+\begin{lstlisting}
+int x;
+double y;
+[int, double] z;
+[y, x] = 3.14;  // mass assignment
+[x, y] = z;     // multiple assignment
+z = 10;         // mass assignment
+z = [x, y];     // multiple assignment
+\end{lstlisting}
+Let $L_i$ for $i$ in $[0, n)$ represent each component of the flattened left-hand side, $R_i$ represent each component of the flattened right-hand side of a multiple assignment, and $R$ represent the right-hand side of a mass assignment.
+For a multiple assignment to be valid, both tuples must have the same number of elements when flattened. Multiple assignment assigns $R_i$ to $L_i$ for each $i$.
+That is, @?=?(&$L_i$, $R_i$)@ must be a well-typed expression. In the previous example, @[x, y] = z@, @z@ is flattened into @z.0, z.1@, and the assignments @x = z.0@ and @y = z.1@ are executed.
+A mass assignment assigns the value $R$ to each $L_i$. For a mass assignment to be valid, @?=?(&$L_i$, $R$)@ must be a well-typed expression. This rule differs from C cascading assignment (\eg @a=b=c@) in that conversions are applied to $R$ in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment. For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, which results in the value @3.14@ in @y@ and the value @3@ in @x@. On the other hand, the C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, which results in the value @3@ in @x@, and as a result the value @3@ in @y@ as well.
+Both kinds of tuple assignment have parallel semantics, such that each value on the left side and right side is evaluated \emph{before} any assignments occur. As a result, it is possible to swap the values in two variables without explicitly creating any temporary variables or calling a function:
+\begin{lstlisting}
+int x = 10, y = 20;
+[x, y] = [y, x];
+\end{lstlisting}
+After executing this code, @x@ has the value @20@ and @y@ has the value @10@.
+Tuple assignment is an expression where the result type is the type of the left-hand side of the assignment, just like all other assignment expressions in C. This definition allows cascading tuple assignment and use of tuple assignment in other expression contexts, an occasionally useful idiom to keep code succinct and reduce repetition.
+% In \CFA, tuple assignment is an expression where the result type is the type of the left-hand side of the assignment, as in normal assignment. That is, a tuple assignment produces the value of the left-hand side after assignment. These semantics allow cascading tuple assignment to work out naturally in any context where a tuple is permitted. These semantics are a change from the original tuple design in {K-W C}~\citep{Till89}, wherein tuple assignment was a statement that allows cascading assignments as a special case. This decision was made in an attempt to fix what was seen as a problem with assignment, wherein it can be used in many different locations, such as in function-call argument position. While permitting assignment as an expression does introduce the potential for subtle complexities, it is impossible to remove assignment expressions from \CFA without affecting backwards compatibility with C. Furthermore, there are situations where permitting assignment as an expression improves readability by keeping code succinct and reducing repetition, and complicating the definition of tuple assignment puts a greater cognitive burden on the user. In another language, tuple assignment as a statement could be reasonable, but it would be inconsistent for tuple assignment to be the only kind of assignment in \CFA that is not an expression.
+v.[x, y.[i, j], z.k];                                           $\C{// [v.x, [v.y.i, v.y.j], v.z.k]}$
+\end{lstlisting}
+\begin{comment}
 \subsection{Casting}
+In C, the cast operator is used to explicitly convert between types. In \CFA, the cast operator has a secondary use as type ascription. That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function:
+In C, the cast operator is used to explicitly convert between types.
+In \CFA, the cast operator has a secondary use as type ascription.
+That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function:
 \begin{lstlisting}
 int f();     // (1)
 …
 \end{lstlisting}
+Since casting is a fundamental operation in \CFA, casts should be given a meaningful interpretation in the context of tuples. Taking a look at standard C provides some guidance with respect to the way casts should work with tuples:
+Since casting is a fundamental operation in \CFA, casts should be given a meaningful interpretation in the context of tuples.
+Taking a look at standard C provides some guidance with respect to the way casts should work with tuples:
 \begin{lstlisting}
 int f();
 …
 (int)g();  // (2)
 \end{lstlisting}
+In C, (1) is a valid cast, which calls @f@ and discards its result. On the other hand, (2) is invalid, because @g@ does not produce a result, so requesting an @int@ to materialize from nothing is nonsensical. Generalizing these principles, any cast wherein the number of components increases as a result of the cast is invalid, while casts that have the same or fewer number of components may be valid.
+Formally, a cast to tuple type is valid when $T_n \leq S_m$, where $T_n$ is the number of components in the target type and $S_m$ is the number of components in the source type, and for each $i$ in $[0, n)$, $S_i$ can be cast to $T_i$. Excess elements ($S_j$ for all $j$ in $[n, m)$) are evaluated, but their values are discarded so that they are not included in the result expression. This approach follows naturally from the way that a cast to @void@ works in C.
+In C, (1) is a valid cast, which calls @f@ and discards its result.
+On the other hand, (2) is invalid, because @g@ does not produce a result, so requesting an @int@ to materialize from nothing is nonsensical.
+Generalizing these principles, any cast wherein the number of components increases as a result of the cast is invalid, while casts that have the same or fewer number of components may be valid.
+Formally, a cast to tuple type is valid when $T_n \leq S_m$, where $T_n$ is the number of components in the target type and $S_m$ is the number of components in the source type, and for each $i$ in $[0, n)$, $S_i$ can be cast to $T_i$.
+Excess elements ($S_j$ for all $j$ in $[n, m)$) are evaluated, but their values are discarded so that they are not included in the result expression.
+This approach follows naturally from the way that a cast to @void@ works in C.
 For example, in
 \begin{lstlisting}
+  [int, int, int] f();
+  [int, [int, int], int] g();
+  ([int, double])f();           $\C{// (1)}$
+  ([int, int, int])g();         $\C{// (2)}$
+  ([void, [int, int]])g();      $\C{// (3)}$
+  ([int, int, int, int])g();    $\C{// (4)}$
+  ([int, [int, int, int]])g();  $\C{// (5)}$
+\end{lstlisting}
+(1) discards the last element of the return value and converts the second element to @double@. Since @int@ is effectively a 1-element tuple, (2) discards the second component of the second element of the return value of @g@. If @g@ is free of side effects, this expression is equivalent to @[(int)(g().0), (int)(g().1.0), (int)(g().2)]@.
+[int, int, int] f();
+[int, [int, int], int] g();
+([int, double])f();           $\C{// (1)}$
+([int, int, int])g();         $\C{// (2)}$
+([void, [int, int]])g();      $\C{// (3)}$
+([int, int, int, int])g();    $\C{// (4)}$
+([int, [int, int, int]])g();  $\C{// (5)}$
+\end{lstlisting}
+(1) discards the last element of the return value and converts the second element to @double@.
+Since @int@ is effectively a 1-element tuple, (2) discards the second component of the second element of the return value of @g@.
+If @g@ is free of side effects, this expression is equivalent to @[(int)(g().0), (int)(g().1.0), (int)(g().2)]@.
 Since @void@ is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to @[(int)(g().1.0), (int)(g().1.1)]@).
+Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions would require more precise matching of types than allowed for function arguments and parameters.}. As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3. Similarly, (5) is invalid because the cast @([int, int, int])(g().1)@ is invalid. That is, it is invalid to cast @[int, int]@ to @[int, int, int]@.
+Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions\footnote{User-defined conversions have been considered, but for compatibility with C and the existing use of casts as type ascription, any future design for such conversions would require more precise matching of types than allowed for function arguments and parameters.}.
+As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3.
+Similarly, (5) is invalid because the cast @([int, int, int])(g().1)@ is invalid.
+That is, it is invalid to cast @[int, int]@ to @[int, int, int]@.
+\end{comment}
 \subsection{Polymorphism}
+Tuples also integrate with \CFA polymorphism as a special sort of generic type. Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non-tuple types.
+\begin{lstlisting}
+forall(otype T, dtype U)
+void f(T x, U * y);
+f([5, "hello"]);
+\end{lstlisting}
+In this example, @[5, "hello"]@ is flattened, so that the argument list appears as @5, "hello"@. The argument matching algorithm binds @T@ to @int@ and @U@ to @const char*@, and calls the function as normal.
+Tuples, however, may contain polymorphic components. For example, a plus operator can be written to add two triples of a type together.
+\begin{lstlisting}
+forall(otype T | { T ?+?(T, T); })
+[T, T, T] ?+?([T, T, T] x, [T, T, T] y) {
+  return [x.0+y.0, x.1+y.1, x.2+y.2];
+Tuples also integrate with \CFA polymorphism as a kind of generic type.
+Due to the implicit flattening and structuring conversions involved in argument passing, @otype@ and @dtype@ parameters are restricted to matching only with non-tuple types, \eg:
+\begin{lstlisting}
+forall(otype T, dtype U) void f( T x, U * y );
+f( [5, "hello"] );
+\end{lstlisting}
+where @[5, "hello"]@ is flattened, giving argument list @5, "hello"@, and @T@ binds to @int@ and @U@ binds to @const char@.
+Tuples, however, may contain polymorphic components.
+For example, a plus operator can be written to add two triples together.
+\begin{lstlisting}
+forall(otype T | { T ?+?( T, T ); }) [T, T, T] ?+?( [T, T, T] x, [T, T, T] y ) {
+        return [x.0 + y.0, x.1 + y.1, x.2 + y.2];
+}
 [int, int, int] x;
 …
 \end{lstlisting}
+Flattening and restructuring conversions are also applied to tuple types in polymorphic type assertions. Previously in \CFA, it has been assumed that assertion arguments must match the parameter type exactly, modulo polymorphic specialization (\ie no implicit conversions are applied to assertion arguments). In the example below:
+\begin{lstlisting}
+int f([int, double], double);
+forall(otype T, otype U | { T f(T, U, U); })
+void g(T, U);
+g(5, 10.21);
+\end{lstlisting}
+If assertion arguments must match exactly, then the call to @g@ cannot be resolved, since the expected type of @f@ is flat, while the only @f@ in scope requires a tuple type. Since tuples are fluid, this requirement reduces the usability of tuples in polymorphic code. To ease this pain point, function parameter and return lists are flattened for the purposes of type unification, which allows the previous example to pass expression resolution.
+This relaxation is made possible by extending the existing thunk generation scheme, as described by \citet{Bilson03}. Now, whenever a candidate's parameter structure does not exactly match the formal parameter's structure, a thunk is generated to specialize calls to the actual function:
+\begin{lstlisting}
+int _thunk(int _p0, double _p1, double _p2) {
+  return f([_p0, _p1], _p2);
+}
+\end{lstlisting}
+Essentially, this thunk provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism. These thunks take advantage of GCC C nested functions to produce closures that have the usual function pointer signature.
+Flattening and restructuring conversions are also applied to tuple types in polymorphic type assertions.
+\begin{lstlisting}
+int f( [int, double], double );
+forall(otype T, otype U | { T f( T, U, U ); }) void g( T, U );
+g( 5, 10.21 );
+\end{lstlisting}
+Hence, function parameter and return lists are flattened for the purposes of type unification allowing the example to pass expression resolution.
+This relaxation is possible by extending the thunk scheme described by \citet{Bilson03}.
+Whenever a candidate's parameter structure does not exactly match the formal parameter's structure, a thunk is generated to specialize calls to the actual function:
+\begin{lstlisting}
+int _thunk( int _p0, double _p1, double _p2 ) { return f( [_p0, _p1], _p2 ); }
+\end{lstlisting}
+so the thunk provides flattening and structuring conversions to inferred functions, improving the compatibility of tuples and polymorphism.
+These thunks take advantage of GCC C nested-functions to produce closures that have the usual function pointer signature.
 \subsection{Variadic Tuples}
+To define variadic functions, \CFA adds a new kind of type parameter, @ttype@. Matching against a @ttype@ (``tuple type'') parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types. In a given parameter list, there should be at most one @ttype@ parameter that must occur last, otherwise the call can never resolve, given the previous rule. This idea essentially matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates. As such, @ttype@ variables are also referred to as \emph{argument} or \emph{parameter packs} in this paper.
+Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is through recursion. Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful. Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
+For example, the C @sum@ function at the beginning of Section~\ref{sec:tuples} could be written using @ttype@ as:
+\begin{lstlisting}
+int sum(){ return 0; }        // (0)
+forall(ttype Params | { int sum(Params); })
+int sum(int x, Params rest) { // (1)
+  return x+sum(rest);
+}
+sum(10, 20, 30);
+\end{lstlisting}
+Since (0) does not accept any arguments, it is not a valid candidate function for the call @sum(10, 20, 30)@.
+In order to call (1), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.
+In order to finish the resolution of @sum@, an assertion parameter that matches @int sum(int, int)@ is required.
+Like in the previous iteration, (0) is not a valid candidate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.
+Next, (0) fails, and to satisfy (1) @Params@ is bound to @[]@, requiring an assertion @int sum()@.
+Finally, (0) matches and (1) fails, which terminates the recursion.
+Effectively, this algorithm traces as @sum(10, 20, 30)@ $\rightarrow$ @10+sum(20, 30)@ $\rightarrow$ @10+(20+sum(30))@ $\rightarrow$ @10+(20+(30+sum()))@ $\rightarrow$ @10+(20+(30+0))@.
+As a point of note, this version does not require any form of argument descriptor, since the \CFA type system keeps track of all of these details. It might be reasonable to take the @sum@ function a step further to enforce a minimum number of arguments:
+\begin{lstlisting}
+int sum(int x, int y){
+  return x+y;
+}
+forall(ttype Params | { int sum(int, Params); })
+int sum(int x, int y, Params rest) {
+  return sum(x+y, rest);
+}
+\end{lstlisting}
+One more iteration permits the summation of any summable type, as long as all arguments are the same type:
+\label{sec:variadic-tuples}
+To define variadic functions, \CFA adds a new kind of type parameter, @ttype@ (tuple type).
+Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types.
+In a given parameter list, there must be at most one @ttype@ parameter that occurs last, which matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates.
+As such, @ttype@ variables are also called \emph{argument packs}.
+Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is via recursion.
+Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful.
+Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
+For example, a generalized @sum@ function written using @ttype@:
+\begin{lstlisting}
+int sum$\(_0\)$() { return 0; }
+forall(ttype Params | { int sum( Params ); } ) int sum$\(_1\)$( int x, Params rest ) {
+        return x + sum( rest );
+}
+sum( 10, 20, 30 );
+\end{lstlisting}
+Since @sum@\(_0\) does not accept any arguments, it is not a valid candidate function for the call @sum(10, 20, 30)@.
+In order to call @sum@\(_1\), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.
+The process continues, @Params@ is bound to @[]@, requiring an assertion @int sum()@, which matches @sum@\(_0\) and terminates the recursion.
+Effectively, this algorithm traces as @sum(10, 20, 30)@ $\rightarrow$ @10 + sum(20, 30)@ $\rightarrow$ @10 + (20 + sum(30))@ $\rightarrow$ @10 + (20 + (30 + sum()))@ $\rightarrow$ @10 + (20 + (30 + 0))@.
+It is reasonable to take the @sum@ function a step further to enforce a minimum number of arguments:
+\begin{lstlisting}
+int sum( int x, int y ) { return x + y; }
+forall(ttype Params | { int sum( int, Params ); } ) int sum( int x, int y, Params rest ) {
+        return sum( x + y, rest );
+}
+\end{lstlisting}
+One more step permits the summation of any summable type with all arguments of the same type:
 \begin{lstlisting}
 trait summable(otype T) {
   T ?+?(T, T);
+        T ?+?( T, T );
 };
+forall(otype R | summable(R))
+R sum(R x, R y){
+  return x+y;
+}
+forall(otype R, ttype Params
+  | summable(R)
+  | { R sum(R, Params); })
+R sum(R x, R y, Params rest) {
+  return sum(x+y, rest);
+}
+\end{lstlisting}
+Unlike C, it is not necessary to hard code the expected type. This code is naturally open to extension, in that any user-defined type with a @?+?@ operator is automatically able to be used with the @sum@ function. That is to say, the programmer who writes @sum@ does not need full program knowledge of every possible data type, unlike what is necessary to write an equivalent function using the standard C mechanisms. Summing arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators.
+It is also possible to write a type-safe variadic print routine which can replace @printf@:
+forall(otype R | summable( R ) ) R sum( R x, R y ) {
+        return x + y;
+}
+forall(otype R, ttype Params | summable(R) | { R sum(R, Params); } ) R sum(R x, R y, Params rest) {
+        return sum( x + y, rest );
+}
+\end{lstlisting}
+Unlike C variadic functions, it is unnecessary to hard code the number and expected types.
+Furthermore, this code is extendable so any user-defined type with a @?+?@ operator.
+Summing arbitrary heterogeneous lists is possible with similar code by adding the appropriate type variables and addition operators.
+It is also possible to write a type-safe variadic print function to replace @printf@:
 \begin{lstlisting}
 struct S { int x, y; };
+forall(otype T, ttype Params |
+  { void print(T); void print(Params); })
+void print(T arg, Params rest) {
+  print(arg);
+  print(rest);
+}
+void print(char * x) { printf("%s", x); }
+void print(int x) { printf("%d", x);  }
+void print(S s) { print("{ ", s.x, ",", s.y, " }"); }
+print("s = ", (S){ 1, 2 }, "\n");
+\end{lstlisting}
+This example routine showcases a variadic-template-like decomposition of the provided argument list. The individual @print@ routines allow printing a single element of a type. The polymorphic @print@ allows printing any list of types, as long as each individual type has a @print@ function. The individual print functions can be used to build up more complicated @print@ routines, such as for @S@, which is something that cannot be done with @printf@ in C.
+It is also possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions. For example, it is possible to write @new@ as a library function:
+\begin{lstlisting}
+struct Pair(otype R, otype S);
+forall(otype R, otype S)
+void ?{}(Pair(R, S) *, R, S);  // (1)
+forall(dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); })
+T * new(Params p) {
+  return ((T*)malloc( sizeof(T) )){ p }; // construct into result of malloc
+}
+Pair(int, char) * x = new(42, '!');
+\end{lstlisting}
+The @new@ function provides the combination of type-safe @malloc@ with a constructor call, so that it becomes impossible to forget to construct dynamically allocated objects. This function provides the type-safety of @new@ in \CC, without the need to specify the allocated type again, thanks to return-type inference.
+In the call to @new@, @Pair(double, char)@ is selected to match @T@, and @Params@ is expanded to match @[double, char]@. The constructor (1) may be specialized to  satisfy the assertion for a constructor with an interface compatible with @void ?{}(Pair(int, char) *, int, char)@.
+\TODO{Check if we actually can use ttype parameters on generic types (if they set the complete flag, it should work, or nearly so).}
+forall(otype T, ttype Params | { void print(T); void print(Params); }) void print(T arg, Params rest) {
+        print(arg);  print(rest);
+}
+void print( char * x ) { printf( "%s", x ); }
+void print( int x ) { printf( "%d", x ); }
+void print( S s ) { print( "{ ", s.x, ",", s.y, " }" ); }
+print( "s = ", (S){ 1, 2 }, "\n" );
+\end{lstlisting}
+This example showcases a variadic-template-like decomposition of the provided argument list.
+The individual @print@ functions allow printing a single element of a type.
+The polymorphic @print@ allows printing any list of types, where as each individual type has a @print@ function.
+The individual print functions can be used to build up more complicated @print@ functions, such as @S@, which cannot be done with @printf@ in C.
+Finally, it is possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions.
+For example, it is possible to write @new@ as a library function:
+\begin{lstlisting}
+forall( otype R, otype S ) void ?{}( pair(R, S) *, R, S );
+forall( dtype T, ttype Params | sized(T) | { void ?{}( T *, Params ); } ) T * new( Params p ) {
+        return ((T *)malloc()){ p };                    $\C{// construct into result of malloc}$
+}
+pair( int, char ) * x = new( 42, '!' );
+\end{lstlisting}
+The @new@ function provides the combination of type-safe @malloc@ with a \CFA constructor call, making it impossible to forget constructing dynamically allocated objects.
+This function provides the type-safety of @new@ in \CC, without the need to specify the allocated type again, thanks to return-type inference.
 \subsection{Implementation}
+Tuples are implemented in the \CFA translator via a transformation into generic types. For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated. For example:
+Tuples are implemented in the \CFA translator via a transformation into generic types.
+For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated, \eg:
 \begin{lstlisting}
 [int, int] f() {
+  [double, double] x;
+  [int, double, int] y;
+}
+\end{lstlisting}
+Is transformed into:
+\begin{lstlisting}
+forall(dtype T0, dtype T1 | sized(T0) | sized(T1))
+struct _tuple2 {  // generated before the first 2-tuple
+  T0 field_0;
+  T1 field_1;
+        [double, double] x;
+        [int, double, int] y;
+}
+\end{lstlisting}
+is transformed into:
+\begin{lstlisting}
+forall(dtype T0, dtype T1 | sized(T0) | sized(T1)) struct _tuple2 {
+        T0 field_0;                                                             $\C{// generated before the first 2-tuple}$
+        T1 field_1;
 };
 _tuple2(int, int) f() {
+  _tuple2(double, double) x;
+  forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2))
+  struct _tuple3 {  // generated before the first 3-tuple
+    T0 field_0;
+    T1 field_1;
+    T2 field_2;
+  };
+  _tuple3_(int, double, int) y;
+}
+\end{lstlisting}
+Tuple expressions are then simply converted directly into compound literals:
+\begin{lstlisting}
+[5, 'x', 1.24];
+\end{lstlisting}
+Becomes:
+\begin{lstlisting}
+(_tuple3(int, char, double)){ 5, 'x', 1.24 };
+\end{lstlisting}
+        _tuple2(double, double) x;
+        forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2)) struct _tuple3 {
+                T0 field_0;                                                     $\C{// generated before the first 3-tuple}$
+                T1 field_1;
+                T2 field_2;
+        };
+        _tuple3(int, double, int) y;
+}
+\end{lstlisting}
+Tuple expressions are then simply converted directly into compound literals, \eg @[5, 'x', 1.24]@ becomes @(_tuple3(int, char, double)){ 5, 'x', 1.24 }@.
+\begin{comment}
 Since tuples are essentially structures, tuple indexing expressions are just field accesses:
 \begin{lstlisting}
 …
 f(x.field_0, (_tuple2){ x.field_1, 'z' });
 \end{lstlisting}
+Note that due to flattening, @x@ used in the argument position is converted into the list of its fields. In the call to @f@, the second and third argument components are structured into a tuple argument. Similarly, tuple member expressions are recursively expanded into a list of member access expressions.
+Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion. Each unique expression is assigned an identifier and is guaranteed to be executed exactly once:
+Note that due to flattening, @x@ used in the argument position is converted into the list of its fields.
+In the call to @f@, the second and third argument components are structured into a tuple argument.
+Similarly, tuple member expressions are recursively expanded into a list of member access expressions.
+Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion.
+Each unique expression is assigned an identifier and is guaranteed to be executed exactly once:
 \begin{lstlisting}
 void g(int, double);
 …
 [int, double] _unq0;
 g(
   (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).0,
   (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).1,
+        (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).0,
+        (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).1,
 );
 \end{lstlisting}
+Since argument evaluation order is not specified by the C programming language, this scheme is built to work regardless of evaluation order. The first time a unique expression is executed, the actual expression is evaluated and the accompanying boolean is set to true. Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression. Tuple member expressions also take advantage of unique expressions in the case of possible impurity.
+Currently, the \CFA translator has a very broad, imprecise definition of impurity, where any function call is assumed to be impure. This notion could be made more precise for certain intrinsic, auto-generated, and builtin functions, and could analyze function bodies when they are available to recursively detect impurity, to eliminate some unique expressions.
+The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions. A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression. The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language. However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new.
+Since argument evaluation order is not specified by the C programming language, this scheme is built to work regardless of evaluation order.
+The first time a unique expression is executed, the actual expression is evaluated and the accompanying boolean is set to true.
+Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression.
+Tuple member expressions also take advantage of unique expressions in the case of possible impurity.
+Currently, the \CFA translator has a very broad, imprecise definition of impurity, where any function call is assumed to be impure.
+This notion could be made more precise for certain intrinsic, auto-generated, and builtin functions, and could analyze function bodies when they are available to recursively detect impurity, to eliminate some unique expressions.
+The various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions.
+A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg in a unique expression.
+The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language.
+However, there are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this restriction is not new.
+\end{comment}
 \section{Evaluation}
+\TODO{Magnus suggests we need some graphs, it's kind of a done thing that the reviewers will be looking for. Also, we've made some unsubstantiated claims about the runtime performance of \CFA, which some micro-benchmarks could help with. I'm thinking a simple stack push and pop, with an idiomatic \lstinline@void*@, \CFA, \CC template and \CC virtual inheritance versions (the void* and virtual inheritance versions likely need to be linked lists, or clumsy in their API -- possibly both versions) to test generics, and variadic print to test tuples. We measure SLOC, runtime performance, executable size (making sure to include benchmarks for multiple types in the executable), and possibly manually count the number of places where the programmer must provide un-type-checked type information. Appendices don't count against our page limit, so we might want to include the source code for the benchmarks (or at least the relevant implementation details) in one.}
+\label{sec:eval}
+Though \CFA provides significant added functionality over C, these features have a low runtime penalty.
+In fact, \CFA's features for generic programming can enable faster runtime execution than idiomatic @void *@-based C code.
+This claim is demonstrated through a set of generic-code-based micro-benchmarks in C, \CFA, and \CC (see stack implementations in Appendix~\ref{sec:BenchmarkStackImplementation}).
+Since all these languages share a subset essentially comprising standard C, maximal-performance benchmarks would show little runtime variance, other than in length and clarity of source code.
+A more illustrative benchmark measures the costs of idiomatic usage of each language's features.
+Figure~\ref{fig:BenchmarkTest} shows the \CFA benchmark tests for a generic stack based on a singly linked-list, a generic pair-data-structure, and a variadic @print@ routine similar to that in Section~\ref{sec:variadic-tuples}.
+The benchmark test is similar for C and \CC.
+The experiment uses element types @int@ and @pair(_Bool, char)@, and pushes $N=40M$ elements on a generic stack, copies the stack, clears one of the stacks, finds the maximum value in the other stack, and prints $N/2$ (to reduce graph height) constants.
+\begin{figure}
+\begin{lstlisting}[xleftmargin=3\parindentlnth,aboveskip=0pt,belowskip=0pt]
+int main( int argc, char * argv[] ) {
+        FILE * out = fopen( "cfa-out.txt", "w" );
+        int maxi = 0, vali = 42;
+        stack(int) si, ti;
+        REPEAT_TIMED( "push_int", N, push( &si, vali ); )
+        TIMED( "copy_int", ti = si; )
+        TIMED( "clear_int", clear( &si ); )
+        REPEAT_TIMED( "pop_int", N,
+                int xi = pop( &ti ); if ( xi > maxi ) { maxi = xi; } )
+        REPEAT_TIMED( "print_int", N/2, print( out, vali, ":", vali, "\n" ); )
+        pair(_Bool, char) maxp = { (_Bool)0, '\0' }, valp = { (_Bool)1, 'a' };
+        stack(pair(_Bool, char)) sp, tp;
+        REPEAT_TIMED( "push_pair", N, push( &sp, valp ); )
+        TIMED( "copy_pair", tp = sp; )
+        TIMED( "clear_pair", clear( &sp ); )
+        REPEAT_TIMED( "pop_pair", N,
+                pair(_Bool, char) xp = pop( &tp ); if ( xp > maxp ) { maxp = xp; } )
+        REPEAT_TIMED( "print_pair", N/2, print( out, valp, ":", valp, "\n" ); )
+        fclose(out);
+}
+\end{lstlisting}
+\caption{\CFA Benchmark Test}
+\label{fig:BenchmarkTest}
+\end{figure}
+The structure of each benchmark implemented is: C with @void *@-based polymorphism, \CFA with the presented features, \CC with templates, and \CC using only class inheritance for polymorphism, called \CCV.
+The \CCV variant illustrates an alternative object-oriented idiom where all objects inherit from a base @object@ class, mimicking a Java-like interface;
+hence runtime checks are necessary to safely down-cast objects.
+The most notable difference among the implementations is in memory layout of generic types: \CFA and \CC inline the stack and pair elements into corresponding list and pair nodes, while C and \CCV lack such a capability and instead must store generic objects via pointers to separately-allocated objects.
+For the print benchmark, idiomatic printing is used: the C and \CFA variants used @stdio.h@, while the \CC and \CCV variants used @iostream@; preliminary tests show this distinction has negligible runtime impact.
+Note, the C benchmark uses unchecked casts as there is no runtime mechanism to perform such checks, while \CFA and \CC provide type-safety statically.
+Figure~\ref{fig:eval} and Table~\ref{tab:eval} show the results of running the benchmark in Figure~\ref{fig:BenchmarkTest} and its C, \CC, and \CCV equivalents.
+The graph plots the median of 5 consecutive runs of each program, with an initial warm-up run omitted.
+All code is compiled at \texttt{-O2} by GCC or G++ 6.2.0, with all \CC code compiled as \CCfourteen.
+The benchmarks are run on an Ubuntu 16.04 workstation with 16 GB of RAM and a 6-core AMD FX-6300 CPU with 3.5 GHz maximum clock frequency.
+\begin{figure}
+\centering
+\input{timing}
+\caption{Benchmark Timing Results (smaller is better)}
+\label{fig:eval}
+\end{figure}
+\begin{table}
+\caption{Properties of benchmark code}
+\label{tab:eval}
+\newcommand{\CT}[1]{\multicolumn{1}{c}{#1}}
+\begin{tabular}{rrrrr}
+                                                                        & \CT{C}        & \CT{\CFA}     & \CT{\CC}      & \CT{\CCV}             \\ \hline
+maximum memory usage (MB)                       & 10001         & 2502          & 2503          & 11253                 \\
+source code size (lines)                        & 247           & 222           & 165           & 339                   \\
+redundant type annotations (lines)      & 39            & 2                     & 2                     & 15                    \\
+binary size (KB)                                        & 14            & 229           & 18            & 38                    \\
+\end{tabular}
+\end{table}
+The C and \CCV variants are generally the slowest with the largest memory footprint, because of their less-efficient memory layout and the pointer-indirection necessary to implement generic types;
+this inefficiency is exacerbated by the second level of generic types in the pair-based benchmarks.
+By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair of @_Bool@ and @char@ because the storage layout is equivalent, with the inlined libraries (\ie no separate compilation) and greater maturity of the \CC compiler contributing to its lead.
+\CCV is slower than C largely due to the cost of runtime type-checking of down-casts (implemented with @dynamic_cast@);
+There are two outliers in the graph for \CFA: all prints and pop of @pair@.
+Both of these cases result from the complexity of the C-generated polymorphic code, so that the GCC compiler is unable to optimize some dead code and condense nested calls.
+A compiler designed for \CFA could easily perform these optimizations.
+Finally, the binary size for \CFA is larger because of static linking with the \CFA libraries.
+\CFA is also competitive in terms of source code size, measured as a proxy for programmer effort. The line counts in Table~\ref{tab:eval} include implementations of @pair@ and @stack@ types for all four languages for purposes of direct comparison, though it should be noted that \CFA and \CC have pre-written data structures in their standard libraries that programmers would generally use instead. Use of these standard library types has minimal impact on the performance benchmarks, but shrinks the \CFA and \CC benchmarks to 73 and 54 lines, respectively.
+On the other hand, C does not have a generic collections-library in its standard distribution, resulting in frequent reimplementation of such collection types by C programmers.
+\CCV does not use the \CC standard template library by construction, and in fact includes the definition of @object@ and wrapper classes for @bool@, @char@, @int@, and @const char *@ in its line count, which inflates this count somewhat, as an actual object-oriented language would include these in the standard library;
+with their omission the \CCV line count is similar to C.
+We justify the given line count by noting that many object-oriented languages do not allow implementing new interfaces on library types without subclassing or wrapper types, which may be similarly verbose.
+Raw line-count, however, is a fairly rough measure of code complexity;
+another important factor is how much type information the programmer must manually specify, especially where that information is not checked by the compiler.
+Such unchecked type information produces a heavier documentation burden and increased potential for runtime bugs, and is much less common in \CFA than C, with its manually specified function pointers arguments and format codes, or \CCV, with its extensive use of un-type-checked downcasts (\eg @object@ to @integer@ when popping a stack, or @object@ to @printable@ when printing the elements of a @pair@).
+To quantify this, the ``redundant type annotations'' line in Table~\ref{tab:eval} counts the number of lines on which the type of a known variable is re-specified, either as a format specifier, explicit downcast, type-specific function, or by name in a @sizeof@, struct literal, or @new@ expression.
+The \CC benchmark uses two redundant type annotations to create a new stack nodes, while the C and \CCV benchmarks have several such annotations spread throughout their code.
+The two instances in which the \CFA benchmark still uses redundant type specifiers are to cast the result of a polymorphic @malloc@ call (the @sizeof@ argument is inferred by the compiler).
+These uses are similar to the @new@ expressions in \CC, though the \CFA compiler's type resolver should shortly render even these type casts superfluous.
 \section{Related Work}
+\CC is the existing language it is most natural to compare \CFA to, as they are both more modern extensions to C with backwards source compatibility. The most fundamental difference in approach between \CC and \CFA is their approach to this C compatibility. \CC does provide fairly strong source backwards compatibility with C, but is a dramatically more complex language than C, and imposes a steep learning curve to use many of its extension features. For instance, in a break from general C practice, template code is typically written in header files, with a variety of subtle restrictions implied on its use by this choice, while the other polymorphism mechanism made available by \CC, class inheritance, requires programmers to learn an entirely new object-oriented programming paradigm; the interaction between templates and inheritance is also quite complex. \CFA, by contrast, has a single facility for polymorphic code, one which supports separate compilation and the existing procedural paradigm of C code. A major difference between the approaches of \CC and \CFA to polymorphism is that the set of assumed properties for a type is \emph{explicit} in \CFA. One of the major limiting factors of \CC's approach is that templates cannot be separately compiled, and, until concepts~\citep{C++Concepts} are standardized (currently anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors for template expansion failures. By contrast, the explicit nature of assertions in \CFA allows polymorphic functions to be separately compiled, and for their requirements to be checked by the compiler; similarly, \CFA generic types may be opaque, unlike \CC template classes.
+Cyclone also provides capabilities for polymorphic functions and existential types~\citep{Grossman06}, similar in concept to \CFA's @forall@ functions and generic types. Cyclone existential types can include function pointers in a construct similar to a virtual function table, but these pointers must be explicitly initialized at some point in the code, a tedious and potentially error-prone process. Furthermore, Cyclone's polymorphic functions and types are restricted in that they may only abstract over types with the same layout and calling convention as @void*@, in practice only pointer types and @int@ - in \CFA terms, all Cyclone polymorphism must be dtype-static. This design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, but is more restrictive than \CFA's more general model.
+Apple's Objective-C \citep{obj-c-book} is another industrially successful set of extensions to C. The Objective-C language model is a fairly radical departure from C, adding object-orientation and message-passing. Objective-C implements variadic functions using the C @va_arg@ mechanism, and did not support type-checked generics until recently \citep{xcode7}, historically using less-efficient and more error-prone runtime checking of object types instead. The GObject framework \citep{GObject} also adds object-orientation with runtime type-checking and reference-counting garbage-collection to C; these are much more intrusive feature additions than those provided by \CFA, in addition to the runtime overhead of reference-counting. The Vala programming language \citep{Vala} compiles to GObject-based C, and so adds the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases. Java \citep{Java8} has had generic types and variadic functions since Java~5; Java's generic types are type-checked at compilation and type-erased at runtime, similar to \CFA's, though in Java each object carries its own table of method pointers, while \CFA passes the method pointers separately so as to maintain a C-compatible struct layout. Java variadic functions are simply syntactic sugar for an array of a single type, and therefore less useful than \CFA's heterogeneously-typed variadic functions. Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
+D \citep{D}, Go \citep{Go}, and Rust \citep{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust. However, each language represents dramatic departures from C in terms of language model, and none has the same level of compatibility with C as \CFA. D and Go are garbage-collected languages, imposing the associated runtime overhead. The necessity of accounting for data transfer between the managed Go runtime and the unmanaged C runtime complicates foreign-function interface between Go and C. Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more. D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime that is more easily interoperable with C. Rust also possesses much more powerful abstraction capabilities for writing generic code than Go. On the other hand, Rust's borrow-checker, while it does provide strong safety guarantees, is complex and difficult to learn, and imposes a distinctly idiomatic programming style on Rust. \CFA, with its more modest safety features, is significantly easier to port C code to, while maintaining the idiomatic style of the original source.
+\section{Conclusion \& Future Work}
+There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, and concurrent programming primitives. In addition to this work, there are some interesting future directions the polymorphism design could take. Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions. \CFA polymorphic functions, by contrast, use an approach that is essentially dynamic virtual dispatch. The runtime overhead of this approach is low, but not as low as \CC template functions, and it may be beneficial to provide a mechanism for particularly performance-sensitive code to close this gap. Further research is needed, but two promising approaches are to allow an annotation on polymorphic function call sites that tells the translator to create a template-specialization of the function (provided the code is visible in the current translation unit) or placing an annotation on polymorphic function definitions that instantiates a version of the polymorphic function specialized to some set of types. These approaches are not mutually exclusive, and would allow these performance optimizations to be applied only where most useful to increase performance, without suffering the code bloat or loss of generality of a template expansion approach where it is unnecessary.
+In conclusion, the authors' design for generic types and tuples, unlike those available in existing work, is both reusable and type-checked, while still supporting a full range of C features, including separately-compiled modules. We have experimentally validated the performance of our design against both \CC and standard C, showing it is \TODO{shiny, cap'n}.
+\subsection{Polymorphism}
+\CC is the most similar language to \CFA;
+both are extensions to C with source and runtime backwards compatibility.
+The fundamental difference is in their engineering approach to C compatibility and programmer expectation.
+While \CC provides good backwards compatibility with C, it has a steep learning curve for many of its extensions.
+For example, polymorphism is provided via three disjoint mechanisms: overloading, inheritance, and templates.
+The overloading is restricted because resolution does not using the return type, inheritance requires learning object-oriented programming and coping with a restricted nominal-inheritance hierarchy, templates cannot be separately compiled resulting in compilation/code bloat and poor error messages, and determining how these mechanisms interact and which to use is confusing.
+In contrast, \CFA has a single facility for polymorphic code supporting type-safe separate-compilation of polymorphic functions and generic (opaque) types, which uniformly leverage the C procedural paradigm.
+The key mechanism to support separate compilation is \CFA's \emph{explicit} use of assumed properties for a type.
+Until \CC~\citet{C++Concepts} are standardized (anticipated for \CCtwenty), \CC provides no way to specify the requirements of a generic function in code beyond compilation errors during template expansion;
+furthermore, \CC concepts are restricted to template polymorphism.
+Cyclone~\citep{Grossman06} also provides capabilities for polymorphic functions and existential types, similar to \CFA's @forall@ functions and generic types.
+Cyclone existential types can include function pointers in a construct similar to a virtual function-table, but these pointers must be explicitly initialized at some point in the code, a tedious and potentially error-prone process.
+Furthermore, Cyclone's polymorphic functions and types are restricted to abstraction over types with the same layout and calling convention as @void *@, \ie only pointer types and @int@.
+In \CFA terms, all Cyclone polymorphism must be dtype-static.
+While the Cyclone design provides the efficiency benefits discussed in Section~\ref{sec:generic-apps} for dtype-static polymorphism, it is more restrictive than \CFA's general model.
+\citet{Smith98} present Polymorphic C, an ML dialect with polymorphic functions and C-like syntax and pointer types; it lacks many of C's features, however, most notably structure types, and so is not a practical C replacement.
+\citet{obj-c-book} is an industrially successful extension to C.
+However, Objective-C is a radical departure from C, using an object-oriented model with message-passing.
+Objective-C did not support type-checked generics until recently \citet{xcode7}, historically using less-efficient runtime checking of object types.
+The~\citet{GObject} framework also adds object-oriented programming with runtime type-checking and reference-counting garbage-collection to C;
+these features are more intrusive additions than those provided by \CFA, in addition to the runtime overhead of reference-counting.
+\citet{Vala} compiles to GObject-based C, adding the burden of learning a separate language syntax to the aforementioned demerits of GObject as a modernization path for existing C code-bases.
+Java~\citep{Java8} included generic types in Java~5, which are type-checked at compilation and type-erased at runtime, similar to \CFA's.
+However, in Java, each object carries its own table of method pointers, while \CFA passes the method pointers separately to maintain a C-compatible layout.
+Java is also a garbage-collected, object-oriented language, with the associated resource usage and C-interoperability burdens.
+D~\citep{D}, Go, and~\citet{Rust} are modern, compiled languages with abstraction features similar to \CFA traits, \emph{interfaces} in D and Go and \emph{traits} in Rust.
+However, each language represents a significant departure from C in terms of language model, and none has the same level of compatibility with C as \CFA.
+D and Go are garbage-collected languages, imposing the associated runtime overhead.
+The necessity of accounting for data transfer between managed runtimes and the unmanaged C runtime complicates foreign-function interfaces to C.
+Furthermore, while generic types and functions are available in Go, they are limited to a small fixed set provided by the compiler, with no language facility to define more.
+D restricts garbage collection to its own heap by default, while Rust is not garbage-collected, and thus has a lighter-weight runtime more interoperable with C.
+Rust also possesses much more powerful abstraction capabilities for writing generic code than Go.
+On the other hand, Rust's borrow-checker provides strong safety guarantees but is complex and difficult to learn and imposes a distinctly idiomatic programming style.
+\CFA, with its more modest safety features, allows direct ports of C code while maintaining the idiomatic style of the original source.
+\subsection{Tuples/Variadics}
+Many programming languages have some form of tuple construct and/or variadic functions, \eg SETL, C, KW-C, \CC, D, Go, Java, ML, and Scala.
+SETL~\cite{SETL} is a high-level mathematical programming language, with tuples being one of the primary data types.
+Tuples in SETL allow subscripting, dynamic expansion, and multiple assignment.
+C provides variadic functions through @va_list@ objects, but the programmer is responsible for managing the number of arguments and their types, so the mechanism is type unsafe.
+KW-C~\cite{Buhr94a}, a predecessor of \CFA, introduced tuples to C as an extension of the C syntax, taking much of its inspiration from SETL.
+The main contributions of that work were adding MRVF, tuple mass and multiple assignment, and record-field access.
+\CCeleven introduced @std::tuple@ as a library variadic template structure.
+Tuples are a generalization of @std::pair@, in that they allow for arbitrary length, fixed-size aggregation of heterogeneous values.
+Operations include @std::get<N>@ to extract vales, @std::tie@ to create a tuple of references used for assignment, and lexicographic comparisons.
+\CCseventeen proposes \emph{structured bindings}~\cite{Sutter15} to eliminate pre-declaring variables and use of @std::tie@ for binding the results.
+This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must be documented with some other mechanism.
+Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
+Like \CC, D provides tuples through a library variadic-template structure.
+Go does not have tuples but supports MRVF.
+Java's variadic functions appear similar to C's but are type-safe using homogeneous arrays, which are less useful than \CFA's heterogeneously-typed variadic functions.
+Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML~\cite{sml} and~\cite{Scala}, which decompose tuples using pattern matching.
+\section{Conclusion and Future Work}
+The goal of \CFA is to provide an evolutionary pathway for large C development-environments to be more productive and safer, while respecting the talent and skill of C programmers.
+While other programming languages purport to be a better C, they are in fact new and interesting languages in their own right, but not C extensions.
+The purpose of this paper is to introduce \CFA, and showcase two language features that illustrate the \CFA type-system and approaches taken to achieve the goal of evolutionary C extension.
+The contributions are a powerful type-system using parametric polymorphism and overloading, generic types, and tuples, which all have complex interactions.
+The work is a challenging design, engineering, and implementation exercise.
+On the surface, the project may appear as a rehash of similar mechanisms in \CC.
+However, every \CFA feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supporting separate compilation.
+All of these new features are being used by the \CFA development-team to build the \CFA runtime-system.
+Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is practically applicable.
+There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, concurrent primitives and modules.
+(While all examples in the paper compile and run, a public beta-release of \CFA will take another 8--12 months to finalize these additional extensions.)
+In addition, there are interesting future directions for the polymorphism design.
+Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions.
+\CFA polymorphic functions use dynamic virtual-dispatch;
+the runtime overhead of this approach is low, but not as low as inlining, and it may be beneficial to provide a mechanism for performance-sensitive code.
+Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template-specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function-definitions to instantiate a specialized version for some set of types.
+These approaches are not mutually exclusive and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
+In general, we believe separate compilation, producing smaller code, works well with loaded hardware-caches, which may offset the benefit of larger inlined-code.
 \begin{acks}
 The authors would like to thank Magnus Madsen for valuable editorial feedback.
 This work is supported in part by a corporate partnership with \grantsponsor{Huawei}{Huawei Ltd.}{http://www.huawei.com}\ and the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
+The authors would like to recognize the design assistance of Glen Ditchfield, Richard Bilson, and Thierry Delisle on the features described in this paper, and thank Magnus Madsen and the three anonymous reviewers for valuable feedback.
+This work is supported in part by a corporate partnership with \grantsponsor{Huawei}{Huawei Ltd.}{http://www.huawei.com}, and Aaron Moss and Peter Buhr are funded by the \grantsponsor{Natural Sciences and Engineering Research Council} of Canada.
+% the first author's \grantsponsor{NSERC-PGS}{NSERC PGS D}{http://www.nserc-crsng.gc.ca/Students-Etudiants/PG-CS/BellandPostgrad-BelletSuperieures_eng.asp} scholarship.
 \end{acks}
 \bibliographystyle{ACM-Reference-Format}
 \bibliography{cfa}
+\appendix
+\section{Benchmark Stack Implementation}
+\label{sec:BenchmarkStackImplementation}
+\lstset{basicstyle=\linespread{0.9}\sf\small}
+Throughout, @/***/@ designates a counted redundant type annotation.
+\medskip\noindent
+\CFA
+\begin{lstlisting}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
+forall(otype T) struct stack_node {
+        T value;
+        stack_node(T) * next;
+};
+forall(otype T) void ?{}(stack(T) * s) { (&s->head){ 0 }; }
+forall(otype T) void ?{}(stack(T) * s, stack(T) t) {
+        stack_node(T) ** crnt = &s->head;
+        for ( stack_node(T) * next = t.head; next; next = next->next ) {
+                *crnt = ((stack_node(T) *)malloc()){ next->value }; /***/
+                stack_node(T) * acrnt = *crnt;
+                crnt = &acrnt->next;
+        }
+        *crnt = 0;
+}
+forall(otype T) stack(T) ?=?(stack(T) * s, stack(T) t) {
+        if ( s->head == t.head ) return *s;
+        clear(s);
+        s{ t };
+        return *s;
+}
+forall(otype T) void ^?{}(stack(T) * s) { clear(s); }
+forall(otype T) _Bool empty(const stack(T) * s) { return s->head == 0; }
+forall(otype T) void push(stack(T) * s, T value) {
+        s->head = ((stack_node(T) *)malloc()){ value, s->head }; /***/
+}
+forall(otype T) T pop(stack(T) * s) {
+        stack_node(T) * n = s->head;
+        s->head = n->next;
+        T x = n->value;
+        ^n{};
+        free(n);
+        return x;
+}
+forall(otype T) void clear(stack(T) * s) {
+        for ( stack_node(T) * next = s->head; next; ) {
+                stack_node(T) * crnt = next;
+                next = crnt->next;
+                delete(crnt);
+        }
+        s->head = 0;
+}
+\end{lstlisting}
+\medskip\noindent
+\CC
+\begin{lstlisting}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
+template<typename T> class stack {
+        struct node {
+                T value;
+                node * next;
+                node( const T & v, node * n = nullptr ) : value(v), next(n) {}
+        };
+        node * head;
+        void copy(const stack<T>& o) {
+                node ** crnt = &head;
+                for ( node * next = o.head;; next; next = next->next ) {
+                        *crnt = new node{ next->value }; /***/
+                        crnt = &(*crnt)->next;
+                }
+                *crnt = nullptr;
+        }
+  public:
+        stack() : head(nullptr) {}
+        stack(const stack<T>& o) { copy(o); }
+        stack(stack<T> && o) : head(o.head) { o.head = nullptr; }
+        ~stack() { clear(); }
+        stack & operator= (const stack<T>& o) {
+                if ( this == &o ) return *this;
+                clear();
+                copy(o);
+                return *this;
+        }
+        stack & operator= (stack<T> && o) {
+                if ( this == &o ) return *this;
+                head = o.head;
+                o.head = nullptr;
+                return *this;
+        }
+        bool empty() const { return head == nullptr; }
+        void push(const T & value) { head = new node{ value, head };  /***/ }
+        T pop() {
+                node * n = head;
+                head = n->next;
+                T x = std::move(n->value);
+                delete n;
+                return x;
+        }
+        void clear() {
+                for ( node * next = head; next; ) {
+                        node * crnt = next;
+                        next = crnt->next;
+                        delete crnt;
+                }
+                head = nullptr;
+        }
+};
+\end{lstlisting}
+\medskip\noindent
+C
+\begin{lstlisting}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
+struct stack_node {
+        void * value;
+        struct stack_node * next;
+};
+struct stack new_stack() { return (struct stack){ NULL }; /***/ }
+void copy_stack(struct stack * s, const struct stack * t, void * (*copy)(const void *)) {
+        struct stack_node ** crnt = &s->head;
+        for ( struct stack_node * next = t->head; next; next = next->next ) {
+                *crnt = malloc(sizeof(struct stack_node)); /***/
+                **crnt = (struct stack_node){ copy(next->value) }; /***/
+                crnt = &(*crnt)->next;
+        }
+        *crnt = 0;
+}
+_Bool stack_empty(const struct stack * s) { return s->head == NULL; }
+void push_stack(struct stack * s, void * value) {
+        struct stack_node * n = malloc(sizeof(struct stack_node)); /***/
+        *n = (struct stack_node){ value, s->head }; /***/
+        s->head = n;
+}
+void * pop_stack(struct stack * s) {
+        struct stack_node * n = s->head;
+        s->head = n->next;
+        void * x = n->value;
+        free(n);
+        return x;
+}
+void clear_stack(struct stack * s, void (*free_el)(void *)) {
+        for ( struct stack_node * next = s->head; next; ) {
+                struct stack_node * crnt = next;
+                next = crnt->next;
+                free_el(crnt->value);
+                free(crnt);
+        }
+        s->head = NULL;
+}
+\end{lstlisting}
+\medskip\noindent
+\CCV
+\begin{lstlisting}[xleftmargin=2\parindentlnth,aboveskip=0pt,belowskip=0pt]
+stack::node::node( const object & v, node * n ) : value( v.new_copy() ), next( n ) {}
+void stack::copy(const stack & o) {
+        node ** crnt = &head;
+        for ( node * next = o.head; next; next = next->next ) {
+                *crnt = new node{ *next->value };
+                crnt = &(*crnt)->next;
+        }
+        *crnt = nullptr;
+}
+stack::stack() : head(nullptr) {}
+stack::stack(const stack & o) { copy(o); }
+stack::stack(stack && o) : head(o.head) { o.head = nullptr; }
+stack::~stack() { clear(); }
+stack & stack::operator= (const stack & o) {
+        if ( this == &o ) return *this;
+        clear();
+        copy(o);
+        return *this;
+}
+stack & stack::operator= (stack && o) {
+        if ( this == &o ) return *this;
+        head = o.head;
+        o.head = nullptr;
+        return *this;
+}
+bool stack::empty() const { return head == nullptr; }
+void stack::push(const object & value) { head = new node{ value, head }; /***/ }
+ptr<object> stack::pop() {
+        node * n = head;
+        head = n->next;
+        ptr<object> x = std::move(n->value);
+        delete n;
+        return x;
+}
+void stack::clear() {
+        for ( node * next = head; next; ) {
+                node * crnt = next;
+                next = crnt->next;
+                delete crnt;
+        }
+        head = nullptr;
+}
+\end{lstlisting}
+\begin{comment}
+\subsubsection{bench.h}
+(\texttt{bench.hpp} is similar.)
+\lstinputlisting{evaluation/bench.h}
+\subsection{C}
+\subsubsection{c-stack.h} ~
+\lstinputlisting{evaluation/c-stack.h}
+\subsubsection{c-stack.c} ~
+\lstinputlisting{evaluation/c-stack.c}
+\subsubsection{c-pair.h} ~
+\lstinputlisting{evaluation/c-pair.h}
+\subsubsection{c-pair.c} ~
+\lstinputlisting{evaluation/c-pair.c}
+\subsubsection{c-print.h} ~
+\lstinputlisting{evaluation/c-print.h}
+\subsubsection{c-print.c} ~
+\lstinputlisting{evaluation/c-print.c}
+\subsubsection{c-bench.c} ~
+\lstinputlisting{evaluation/c-bench.c}
+\subsection{\CFA}
+\subsubsection{cfa-stack.h} ~
+\lstinputlisting{evaluation/cfa-stack.h}
+\subsubsection{cfa-stack.c} ~
+\lstinputlisting{evaluation/cfa-stack.c}
+\subsubsection{cfa-print.h} ~
+\lstinputlisting{evaluation/cfa-print.h}
+\subsubsection{cfa-print.c} ~
+\lstinputlisting{evaluation/cfa-print.c}
+\subsubsection{cfa-bench.c} ~
+\lstinputlisting{evaluation/cfa-bench.c}
+\subsection{\CC}
+\subsubsection{cpp-stack.hpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-stack.hpp}
+\subsubsection{cpp-print.hpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-print.hpp}
+\subsubsection{cpp-bench.cpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-bench.cpp}
+\subsection{\CCV}
+\subsubsection{object.hpp} ~
+\lstinputlisting[language=c++]{evaluation/object.hpp}
+\subsubsection{cpp-vstack.hpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-vstack.hpp}
+\subsubsection{cpp-vstack.cpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-vstack.cpp}
+\subsubsection{cpp-vprint.hpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-vprint.hpp}
+\subsubsection{cpp-vbench.cpp} ~
+\lstinputlisting[language=c++]{evaluation/cpp-vbench.cpp}
+\end{comment}
 \end{document}

doc/proposals/concurrency/concurrency.tex

-                      r221c2de7
+                      r154fdc8
 \newcommand{\uC}{$\mu$\CC}
 \newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
 \newcommand{\code}[1]{\lstinline{#1}}
+\newcommand{\code}[1]{\lstinline[language=CFA]{#1}}
 \newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}}
 …
 Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
 Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without wualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
+Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without quualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
 The next semantic decision is to establish when mutex/nomutex may be used as a type qualifier. Consider the following declarations:
 …
 \subsection{Internal scheduling} \label{insched}
+Monitors also need to schedule waiting threads internally as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
+\begin{lstlisting}
+        mutex struct A {
+                condition e;
+        }
+        void foo(A & mutex a) {
+                //...
+                wait(a.e);
+                //...
+        }
+        void bar(A & mutex a) {
+                signal(a.e);
+        }
+\end{lstlisting}
+Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
 \begin{center}
 \begin{tabular}{ c @{\hskip 0.65in} c }
+Thread 1 & Thread 2 \\
+\begin{lstlisting}
+void foo(monitor & mutex a,
+           monitor & mutex b) {
+        //...
+        wait(a.e);
+        //...
+}
+foo(a, b);
+\end{lstlisting} &\begin{lstlisting}
+void bar(monitor & mutex a,
+           monitor & mutex b) {
+        signal(a.e);
+}
+bar(a, b);
+\begin{lstlisting}[language=Pseudo]
+acquire A
+        wait A
+release A
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire A
+        signal A
+release A
 \end{lstlisting}
 \end{tabular}
 \end{center}
+A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
+Easy : like uC++
 \begin{center}
+\begin{tabular}{|c|c|c|}
+Context 1 & Context 2 & Context 3 \\
+\hline
+\begin{lstlisting}
+condition e;
+//acquire a & b
+void foo(monitor & mutex a,
+           monitor & mutex b) {
+        wait(e); //release a & b
+}
+foo(a,b);
+\end{lstlisting} &\begin{lstlisting}
+condition e;
+//acquire a
+void bar(monitor & mutex a,
+           monitor & nomutex b) {
+        foo(a,b);
+}
+//acquire a & b
+void foo(monitor & mutex a,
+           monitor & mutex b) {
+        wait(e);  //release a & b
+}
+bar(a, b);
+\end{lstlisting} &\begin{lstlisting}
+condition e;
+//acquire a
+void bar(monitor & mutex a,
+           monitor & nomutex b) {
+        baz(a,b);
+}
+//acquire b
+void baz(monitor & nomutex a,
+           monitor & mutex b) {
+        wait(e);  //release b
+}
+bar(a, b);
+\begin{tabular}{ c @{\hskip 0.65in} c }
+\begin{lstlisting}[language=Pseudo]
+acquire A
+        acquire B
+                wait B
+        release B
+release A
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire A
+        acquire B
+                signal B
+        release B
+release A
 \end{lstlisting}
 \end{tabular}
 \end{center}
+Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
+Also easy : like uC++
 \begin{center}
+\begin{tabular}{|c|c|c|}
+\begin{lstlisting}
+condition e;
+//acquire b
+void foo(monitor & nomutex a,
+           monitor & mutex b) {
+        bar(a,b);
+}
+//acquire a
+void bar(monitor & mutex a,
+           monitor & nomutex b) {
+        wait(e); //release a
+                  //keep b
+}
+foo(a, b);
+\end{lstlisting} &\begin{lstlisting}
+condition e;
+//acquire a & b
+void foo(monitor & mutex a,
+           monitor & mutex b) {
+        bar(a,b);
+}
+//acquire b
+void bar(monitor & mutex a,
+           monitor & nomutex b) {
+        wait(e); //release b
+                  //keep a
+}
+foo(a, b);
+\end{lstlisting} &\begin{lstlisting}
+condition e;
+//acquire a & b
+void foo(monitor & mutex a,
+           monitor & mutex b) {
+        bar(a,b);
+}
+//acquire none
+void bar(monitor & nomutex a,
+           monitor & nomutex b) {
+        wait(e); //release a & b
+                  //keep none
+}
+foo(a, b);
+\begin{tabular}{ c @{\hskip 0.65in} c }
+\begin{lstlisting}[language=Pseudo]
+acquire A & B
+        wait A & B
+release A & B
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire A & B
+        signal A & B
+release A & B
 \end{lstlisting}
 \end{tabular}
 \end{center}
+Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
+These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
+Simplest extension : can be made like uC++ by tying B to A
 \begin{center}
+\begin{tabular}{ c c c }
+\begin{lstlisting}
+        condition e;
+        //acquire a & b
+        void foo(monitor & mutex a,
+                   monitor & mutex b) {
+                bar(a,b);
+        }
+        //acquire b
+        void bar(monitor & mutex a,
+                   monitor & nomutex b) {
+                wait(e); //release b
+                          //keep a
+        }
+        foo(a, b);
+\end{lstlisting} &\begin{lstlisting}
+        =>
+\end{lstlisting} &\begin{lstlisting}
+        condition e;
+        //acquire a & b
+        void foo(monitor & mutex a,
+                   monitor & mutex b) {
+                wait_release(e,b); //release b
+                                         //keep a
+        }
+        foo(a, b);
+\begin{tabular}{ c @{\hskip 0.65in} c }
+\begin{lstlisting}[language=Pseudo]
+acquire A
+        // Code Section 1
+        acquire B
+                // Code Section 2
+                wait A & B
+                // Code Section 3
+        release B
+        // Code Section 4
+release A
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire A
+        // Code Section 5
+        acquire B
+                // Code Section 6
+                signal A & B
+                // Code Section 7
+        release B
+        // Code Section 8
+release A
 \end{lstlisting}
 \end{tabular}
 \end{center}
+Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
+Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
+\\
+Hard extension :
+Incorrect options for the signal :
+\begin{description}
+ \item[-] Release B and baton pass after Code Section 8 : Passing b without having it
+ \item[-] Keep B during Code Section 8 : Can lead to deadlocks since we secretly keep a lock longer than specified by the user
+ \item[-] Instead of release B transfer A and B to waiter then try to reacquire A before running Code Section 8 : This allows barging
+\end{description}
+Since we don't want barging we need to pass A \& B and somehow block and get A back.
+\begin{center}
+\begin{tabular}{ c @{\hskip 0.65in} c }
+\begin{lstlisting}[language=Pseudo]
+acquire A
+        acquire B
+                acquire C
+                        wait A & B & C
+: release C
+: release B
+: release A
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire A
+        acquire B
+                acquire C
+                        signal A & B & C
+: release C
+: release B
+: release A
+\end{lstlisting}
+\end{tabular}
+\end{center}
+To prevent barging :
+\begin{description}
+ \item[-] When the signaller hits 4 : pass A, B, C to waiter
+ \item[-] When the waiter hits 2 : pass A, B to signaller
+ \item[-] When the signaller hits 5 : pass A to waiter
+\end{description}
+\begin{center}
+\begin{tabular}{ c @{\hskip 0.65in} c }
+\begin{lstlisting}[language=Pseudo]
+acquire A
+        acquire C
+                acquire B
+                        wait A & B & C
+: release B
+: release C
+: release A
+\end{lstlisting}&\begin{lstlisting}[language=Pseudo]
+acquire B
+        acquire A
+                acquire C
+                        signal A & B & C
+: release C
+: release A
+: release B
+\end{lstlisting}
+\end{tabular}
+\end{center}
+To prevent barging : When the signaller hits 4 : pass A, B, C to waiter. When the waiter hits 1 it must release B,
+\begin{description}
+ \item[-]
+ \item[-] When the waiter hits 1 : pass A, B to signaller
+ \item[-] When the signaller hits 5 : pass A, B to waiter
+ \item[-] When the waiter hits 2 : pass A to signaller
+\end{description}
+% Monitors also need to schedule waiting threads internally as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
+% \begin{lstlisting}
+%       mutex struct A {
+%               condition e;
+%       }
+%       void foo(A & mutex a) {
+%               //...
+%               wait(a.e);
+%               //...
+%       }
+%       void bar(A & mutex a) {
+%               signal(a.e);
+%       }
+% \end{lstlisting}
+% Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering.
+% As for simple mutual exclusion, these semantics must also be extended to include \gls{group-acquire} :
+% \begin{center}
+% \begin{tabular}{ c @{\hskip 0.65in} c }
+% Thread 1 & Thread 2 \\
+% \begin{lstlisting}
+% void foo(A & mutex a,
+%            A & mutex b) {
+%       //...
+%       wait(a.e);
+%       //...
+% }
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% void bar(A & mutex a,
+%            A & mutex b) {
+%       signal(a.e);
+% }
+% bar(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+% To define the semantics of internal scheduling, it is important to look at nesting and \gls{group-acquire}. Indeed, beyond concerns about lock ordering, without scheduling the two following pseudo codes are mostly equivalent. In fact, if we assume monitors are ordered alphabetically, these two pseudo codes would probably lead to exactly the same implementation :
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{c c}
+% \begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% acquire A
+%       acquire B & C
+%                       //Do stuff
+%       release B & C
+% release A
+% \end{lstlisting} &\begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% acquire A
+%       acquire B
+%               acquire C
+%                       //Do stuff
+%               release C
+%       release B
+% release A
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+% Once internal scheduling is introduce however, semantics of \gls{group-acquire} become relevant. For example, let us look into the semantics of the following pseudo-code :
+% \begin{lstlisting}[language=Pseudo]
+% 1: monitor A, B, C
+% 2: condition c1
+% 3:
+% 4: acquire A
+% 5:            acquire A & B & C
+% 6:                            signal c1
+% 7:            release A & B & C
+% 8: release A
+% \end{lstlisting}
+% Without \gls{group-acquire} signal simply baton passes the monitor lock on the next release. In the case above, we therefore need to indentify the next release. If line 8 is picked at the release point, then the signal will attempt to pass A \& B \& C, without having ownership of B \& C. Since this violates mutual exclusion, we conclude that line 7 is the only valid location where signalling can occur. The traditionnal meaning of signalling is to transfer ownership of the monitor(s) and immediately schedule the longest waiting task. However, in the discussed case, the signalling thread expects to maintain ownership of monitor A. This can be expressed in two differents ways : 1) the thread transfers ownership of all locks and reacquires A when it gets schedulled again or 2) it transfers ownership of all three monitors and then expects the ownership of A to be transferred back.
+% However, the question is does these behavior motivate supporting acquireing non-disjoint set of monitors. Indeed, if the previous example was modified to only acquire B \& C at line 5 (an release the accordingly) then in respects to scheduling, we could add the simplifying constraint that all monitors in a bulk will behave the same way, simplifying the problem back to a single monitor problem which has already been solved. For this constraint to be acceptble however, we need to demonstrate that in does not prevent any meaningful possibilities. And, indeed, we can look at the two previous interpretation of the above pseudo-code and conclude that supporting the acquiring of non-disjoint set of monitors does not add any expressiveness to the language.
+% Option 1 reacquires the lock after the signal statement, this can be rewritten as follows without the need for non-disjoint sets :
+% \begin{lstlisting}[language=Pseudo]
+% monitor A, B, C
+% condition c1
+% acquire A & B & C
+%       signal c1
+% release A & B & C
+% acquire A
+% release A
+% \end{lstlisting}
+% This pseudo code has almost exaclty the same semantics as the code acquiring intersecting sets of monitors.
+% Option 2 uses two-way lock ownership transferring instead of reacquiring monitor A. Two-way monitor ownership transfer is normally done using signalBlock semantics, which immedietely transfers ownership of a monitor before getting the ownership back when the other thread no longer needs the monitor. While the example pseudo-code for Option 2 seems toe transfer ownership of A, B and C and only getting A back, this is not a requirement. Getting back all 3 monitors and releasing B and C differs only in performance. For this reason, the second option could arguably be rewritten as :
+% \begin{lstlisting}[language=Pseudo]
+% monitor A, B, C
+% condition c1
+% acquire A
+%       acquire B & C
+%               signalBlock c1
+%       release B & C
+% release A
+% \end{lstlisting}
+% Obviously, the difference between these two snippets of pseudo code is that the first one transfers ownership of A, B and C while the second one only transfers ownership of B and C. However, this limitation can be removed by allowing user to release extra monitors when using internal scheduling, referred to as extended internal scheduling (pattent pending) from this point on. Extended internal scheduling means the two following pseudo-codes are functionnaly equivalent :
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{c @{\hskip 0.65in} c}
+% \begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% condition c1
+% acquire A
+%       acquire B & C
+%               signalBlock c1 with A
+%       release B & C
+% release A
+% \end{lstlisting} &\begin{lstlisting}[language=pseudo]
+% monitor A, B, C
+% condition c1
+% acquire A
+%       acquire A & B & C
+%               signal c1
+%       release A & B & C
+% release A
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+% It must be stated that the extended internal scheduling only makes sense when using wait and signalBlock, since they need to prevent barging, which cannot be done in the context of signal since the ownership transfer is strictly one-directionnal.
+% One critic that could arise is that extended internal schedulling is not composable since signalBlock must be explicitly aware of which context it is in. However, this argument is not relevant since acquire A, B and C in a context where a subset of them is already acquired cannot be achieved without spurriously releasing some locks or having an oracle aware of all monitors. Therefore, composability of internal scheduling is no more an issue than composability of monitors in general.
+% The main benefit of using extended internal scheduling is that it offers the same expressiveness as intersecting monitor set acquiring but greatly simplifies the selection of a leader (or representative) for a group of monitor. Indeed, when using intersecting sets, it is not obvious which set intersects with other sets which means finding a leader representing only the smallest scope is a hard problem. Where as when using disjoint sets, any monitor that would be intersecting must be specified in the extended set, the leader can be chosen as any monitor in the primary set.
+% We need to make sure the semantics for internally scheduling N monitors are a natural extension of the single monitor semantics. For this reason, we introduce the concept of \gls{mon-ctx}. In terms of context internal scheduling means "releasing a \gls{mon-ctx} and waiting for an other thread to acquire the same \gls{mon-ctx} and baton-pass it back to the initial thread". This definitions requires looking into what a \gls{mon-ctx} is and what the semantics of waiting and baton-passing are.
+% \subsubsection{Internal scheduling: Context} \label{insched-context}
+% Monitor scheduling operations are defined in terms of the context they are in. In languages that only supports operations on a single monitor at once, the context is completly defined by which most recently acquired monitors. Indeed, acquiring several monitors will form a stack of monitors which will be released in FILO order. In \CFA, a \gls{mon-ctx} cannot be simply defined by the last monitor that was acquired since \gls{group-acquire} means multiple monitors can be "the last monitor acquired". The \gls{mon-ctx} is therefore defined as the last set of monitors to have been acquired. This means taht when any new monitor is acquired, the group it belongs to is the new \gls{mon-ctx}. Correspondingly, if any monitor is released, the \gls{mon-ctx} reverts back to the context that was used prior to the monitor being acquired. In the most common case, \gls{group-acquire} means every monitor of a group will be acquired in released at the same time. However, since every monitor has its own recursion level, \gls{group-acquire} does not prevent users from reacquiring certain monitors while acquireing new monitors in the same operation. For example :
+% \begin{lstlisting}
+% //Forward declarations
+% monitor a, b, c
+% void foo( monitor & mutex a,
+%             monitor & mutex b);
+% void bar( monitor & mutex a,
+%             monitor & mutex b);
+% void baz( monitor & mutex a,
+%             monitor & mutex b,
+%             monitor & mutex c);
+% //Routines defined inline to illustrate context changed compared to the stack
+% //main thread
+% foo(a, b) {
+%       //thread calls foo
+%       //acquiring context a & b
+%       baz(a, b) {
+%               //thread calls baz
+%               //no context change
+%               bar(a, b, c) {
+%                       //thread calls bar
+%                       //acquiring context a & b & c
+%                       //Do stuff
+%                       return;
+%                       //call to bar returns
+%               }
+%               //context back to a & b
+%               return;
+%               //call to baz returns
+%       }
+%       //no context change
+%       return;
+%       //call to foo returns
+% }
+% //context back to initial state
+% \end{lstlisting}
+% As illustrated by the previous example, context changes can be caused by only one of the monitors comming into context or going out of context.
+% \subsubsection{Internal scheduling: Waiting} \label{insched-wait}
+% \subsubsection{Internal scheduling: Baton Passing} \label{insched-signal}
+% Baton passing in internal scheduling is done in terms of \code{signal} and \code{signalBlock}\footnote{Arguably, \code{signal_now} is a more evocative name and \code{signal} could be changed appropriately. }. While \code{signalBlock} is the more straight forward way of baton passing, transferring ownership immediately, it must rely on \code{signal} which is why t is discussed first.
+% \code{signal} has for effect to transfer the current context to another thread when the context would otherwise be released. This means that instead of releasing the concerned monitors, the first thread on the condition ready-queue is scheduled to run. The monitors are not released and when the signalled thread runs, it assumes it regained ownership of all the monitors it had in its context.
+% \subsubsection{Internal scheduling: Implementation} \label{insched-impl}
+% Too implement internal scheduling, three things are need : a data structure for waiting tasks, a data structure for signalled task and a leaving procedure to run the signalled task. In the case of both data structures, it is desireable to have to use intrusive data structures in order to prevent the need for any dynamic allocation. However, in both cases being able to queue several items in the same position in a queue is non trivial, even more so in the presence of concurrency. However, within a given \gls{mon-ctx}, all monitors have exactly the same behavior in regards to scheduling. Therefore, the problem of queuing multiple monitors at once can be ignored by choosing one monitor to represent every monitor in a context. While this could prove difficult in other situations, \gls{group-acquire} requires that the monitors be sorted according to some stable predicate. Since monitors are sorted in all contexts, the representative can simply be the first in the list. Choosing a representative means a simple intrusive queue inside the condition is sufficient to implement the data structure for both waiting and signalled monitors.
+% Since \CFA monitors don't have a complete image of the \gls{mon-ctx}, choosing the representative and maintaning the current context information cannot easily be done by any single monitors. However, as discussed in section [Missing section here], monitor mutual exclusion is implemented using an raii object which is already in charge of sorting monitors. This object has a complete picture of the \gls{mon-ctx} which means it is well suited to choose the reprensentative and detect context changes.
+% \newpage
+% \begin{lstlisting}
+% void ctor( monitor ** _monitors, int _count ) {
+%       bool ctx_changed = false;
+%       for( mon in _monitors ) {
+%               ctx_changed = acquire( mon ) || ctx_changed;
+%       }
+%       if( ctx_changed ) {
+%               set_representative();
+%               set_context();
+%       }
+% }
+% void dtor( monitor ** _monitors, int _count ) {
+%       if( context_will_exit( _monitors, count ) ) {
+%               baton_pass();
+%               return;
+%       }
+%       for( mon in _monitors ) {
+%               release( mon );
+%       }
+% }
+% \end{lstlisting}
+% A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
+% \begin{table}[h!]
+% \centering
+% \begin{tabular}{|c|c|c|}
+% Context 1 & Context 2 & Context 3 \\
+% \hline
+% \begin{lstlisting}
+% condition e;
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+%       wait(e); //release a & b
+% }
+% foo(a,b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+%       foo(a,b);
+% }
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+%       wait(e);  //release a & b
+% }
+% bar(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+%       baz(a,b);
+% }
+% //acquire b
+% void baz(monitor & nomutex a,
+%            monitor & mutex b) {
+%       wait(e);  //release b
+% }
+% bar(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{table}
+% Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
+% \begin{center}
+% \begin{tabular}{|c|c|c|}
+% \begin{lstlisting}
+% condition e;
+% //acquire b
+% void foo(monitor & nomutex a,
+%            monitor & mutex b) {
+%       bar(a,b);
+% }
+% //acquire a
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+%       wait(e); //release a
+%                 //keep b
+% }
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+%       bar(a,b);
+% }
+% //acquire b
+% void bar(monitor & mutex a,
+%            monitor & nomutex b) {
+%       wait(e); //release b
+%                 //keep a
+% }
+% foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+% condition e;
+% //acquire a & b
+% void foo(monitor & mutex a,
+%            monitor & mutex b) {
+%       bar(a,b);
+% }
+% //acquire none
+% void bar(monitor & nomutex a,
+%            monitor & nomutex b) {
+%       wait(e); //release a & b
+%                 //keep none
+% }
+% foo(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+% Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
+% These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
+% \begin{center}
+% \begin{tabular}{ c c c }
+% \begin{lstlisting}
+%       condition e;
+%       //acquire a & b
+%       void foo(monitor & mutex a,
+%                  monitor & mutex b) {
+%               bar(a,b);
+%       }
+%       //acquire b
+%       void bar(monitor & mutex a,
+%                  monitor & nomutex b) {
+%               wait(e); //release b
+%                         //keep a
+%       }
+%       foo(a, b);
+% \end{lstlisting} &\begin{lstlisting}
+%       =>
+% \end{lstlisting} &\begin{lstlisting}
+%       condition e;
+%       //acquire a & b
+%       void foo(monitor & mutex a,
+%                  monitor & mutex b) {
+%               wait_release(e,b); //release b
+%                                        //keep a
+%       }
+%       foo(a, b);
+% \end{lstlisting}
+% \end{tabular}
+% \end{center}
+% Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
+% Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
+% \\
 % ####### #     # #######         #####   #####  #     # ####### ######

doc/proposals/concurrency/glossary.tex

-                      r221c2de7
+                      r154fdc8
 \longnewglossaryentry{group-acquire}
 {name={bulked acquiring}}
+{name={bulk acquiring}}
+{
 Implicitly acquiring several monitors when entering a monitor.
+}
+\longnewglossaryentry{mon-ctx}
+{name={monitor context}}
+{
+The state of the current thread regarding which monitors are owned.
+}

doc/proposals/concurrency/style.tex

r221c2de7	r154fdc8
1	1	\input{common} % bespoke macros used in the document
	2
	3	% \CFADefaultStyle
2	4
3	5	\lstset{

doc/proposals/concurrency/version

r221c2de7	r154fdc8
1		0.7.61
	1	0.7.141

doc/rob_thesis/cfa-format.tex

-                      r221c2de7
+                      r154fdc8
   morecomment=[n]{/+}{+/},
   morecomment=[n][\color{blue}]{/++}{+/},
+  % Options
+  sensitive=true
+}
+\lstdefinelanguage{rust}{
+  % Keywords
+  morekeywords=[1]{
+    abstract, alignof, as, become, box,
+    break, const, continue, crate, do,
+    else, enum, extern, false, final,
+    fn, for, if, impl, in,
+    let, loop, macro, match, mod,
+    move, mut, offsetof, override, priv,
+    proc, pub, pure, ref, return,
+    Self, self, sizeof, static, struct,
+    super, trait, true,  type, typeof,
+    unsafe, unsized, use, virtual, where,
+    while, yield
+  },
+  % Strings
+  morestring=[b]{"},
+  % Comments
+  comment=[l]{//},
+  morecomment=[s]{/*}{*/},
   % Options
   sensitive=true
 …
   style=defaultStyle
+}
 \lstMakeShortInline[basewidth=0.5em,breaklines=true]@  % single-character for \lstinline
+\lstMakeShortInline[basewidth=0.5em,breaklines=true,basicstyle=\normalsize\ttfamily\color{basicCol}]@  % single-character for \lstinline
 \lstnewenvironment{cfacode}[1][]{
 …
   \lstset{
     language = D,
+    style=defaultStyle,
+    #1
+  }
+}{}
+\lstnewenvironment{rustcode}[1][]{
+  \lstset{
+    language = rust,
     style=defaultStyle,
     #1

doc/rob_thesis/conclusions.tex

-                      r221c2de7
+                      r154fdc8
 %======================================================================
+Conclusion paragraphs.
+Adding resource management and tuples to \CFA has been a challenging design, engineering, and implementation exercise.
+On the surface, the work may appear as a rehash of similar mechanisms in \CC.
+However, every added feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supports separate compilation.
+All of these new features are being used by the \CFA development-team to build the \CFA runtime system.
+\section{Constructors and Destructors}
+\CFA supports the RAII idiom using constructors and destructors.
+There are many engineering challenges in introducing constructors and destructors, partially since \CFA is not an object-oriented language.
+By making use of managed types, \CFA programmers are afforded an extra layer of safety and ease of use in comparison to C programmers.
+While constructors and destructors provide a sensible default behaviour, \CFA allows experienced programmers to declare unmanaged objects to take control of object management for performance reasons.
+Constructors and destructors as named functions fit the \CFA polymorphism model perfectly, allowing polymorphic code to use managed types seamlessly.
+\section{Tuples}
+\CFA can express functions with multiple return values in a way that is simple, concise, and safe.
+The addition of multiple-return-value functions naturally requires a way to use multiple return values, which begets tuple types.
+Tuples provide two useful notions of assignment: multiple assignment, allowing simple, yet expressive assignment between multiple variables, and mass assignment, allowing a lossless assignment of a single value across multiple variables.
+Tuples have a flexible structure that allows the \CFA type-system to decide how to restructure tuples, making it syntactically simple to pass tuples between functions.
+Tuple types can be combined with polymorphism and tuple conversions can apply during assertion inference to produce a cohesive feel.
+\section{Variadic Functions}
+Type-safe variadic functions, with a similar feel to variadic templates, are added to \CFA.
+The new variadic functions can express complicated recursive algorithms.
+Unlike variadic templates, it is possible to write @new@ as a library routine and to separately compile @ttype@ polymorphic functions.
+Variadic functions are statically type checked and provide a user experience that is consistent with that of tuples and polymorphic functions.
+\section{Future Work}
+\subsection{Constructors and Destructors}
+Both \CC and Rust support move semantics, which expand the user's control of memory management by providing the ability to transfer ownership of large data, rather than forcing potentially expensive copy semantics.
+\CFA currently does not support move semantics, partially due to the complexity of the model.
+The design space is currently being explored with the goal of finding an alternative to move semantics that provides necessary performance benefits, while reducing the amount of repetition required to create a new type, along with the cognitive burden placed on the user.
+% One technique being evaluated is whether named return-values can be used to eliminate unnecessary temporaries \cite{Buhr94a}.
+% For example,
+% \begin{cfacode}
+% struct A { ... };
+% [A x] f(A x);
+% [A y] g(A y);
+% [A z] h(A z);
+% struct A a1, a2;
+% a2 = h(g(f(a1)));
+% \end{cfacode}
+% Here, since both @f@'s argument and return value have the same name and type, the compiler can infer that @f@ returns its argument.
+% With this knowledge, the compiler can reuse the storage for the argument to @f@ as the argument to @g@.  % TODO: cite Till thesis?
+Exception handling is among the features expected to be added to \CFA in the near future.
+For exception handling to properly interact with the rest of the language, it must ensure all RAII guarantees continue to be met.
+That is, when an exception is raised, it must properly unwind the stack by calling the destructors for any objects that live between the raise and the handler.
+This can be accomplished either by augmenting the translator to properly emit code that executes the destructors, or by switching destructors to hook into the GCC @cleanup@ attribute \cite[6.32.1]{GCCExtensions}.
+The @cleanup@ attribute, which is attached to a variable declaration, takes a function name as an argument and schedules that routine to be executed when the variable goes out of scope.
+\begin{cfacode}
+struct S { int x; };
+void __dtor_S(struct S *);
+{
+  __attribute__((cleanup(__dtor_S))) struct S s;
+} // calls __dtor_S(&s)
+\end{cfacode}
+This mechanism is known and understood by GCC, so that the destructor is properly called in any situation where a variable goes out of scope, including function returns, branches, and built-in GCC exception handling mechanisms using libunwind.
+A caveat of this approach is that the @cleanup@ attribute only permits a function that consumes a single argument of type @T *@ for a variable of type @T@.
+This restriction means that any destructor that consumes multiple arguments (\eg, because it is polymorphic) or any destructor that is a function pointer (\eg, because it is an assertion parameter) must be called through a local thunk.
+For example,
+\begin{cfacode}
+forall(otype T)
+struct Box {
+  T x;
+};
+forall(otype T) void ^?{}(Box(T) * x); // has implicit parameters
+forall(otype T)
+void f(T x) {
+  T y = x;  // destructor is a function-pointer parameter
+  Box(T) z = { x }; // destructor has multiple parameters
+}
+\end{cfacode}
+currently generates the following
+\begin{cfacode}
+void _dtor_BoxT(  // consumes more than 1 parameter due to assertions
+  void (*_adapter_PTT)(void (*)(), void *, void *),
+  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
+  long unsigned int _sizeof_T,
+  long unsigned int _alignof_T,
+  void *(*_assign_T_PTT)(void *, void *),
+  void (*_ctor_PT)(void *),
+  void (*_ctor_PTT)(void *, void *),
+  void (*_dtor_PT)(void *),
+  void *x
+);
+void f(
+  void (*_adapter_PTT)(void (*)(), void *, void *),
+  void (*_adapter_T_PTT)(void (*)(), void *, void *, void *),
+  long unsigned int _sizeof_T,
+  long unsigned int _alignof_T,
+  void *(*_assign_TT)(void *, void *),
+  void (*_ctor_T)(void *),
+  void (*_ctor_TT)(void *, void *),
+  void (*_dtor_T)(void *),
+  void *x
+){
+  void *y = __builtin_alloca(_sizeof_T);
+  // constructor call elided
+  // generic layout computation elided
+  long unsigned int _sizeof_BoxT = ...;
+  void *z = __builtin_alloca(_sizeof_BoxT);
+  // constructor call elided
+  _dtor_BoxT(  // ^?{}(&z); -- _dtor_BoxT has > 1 arguments
+    _adapter_PTT,
+    _adapter_T_PTT,
+    _sizeof_T,
+    _alignof_T,
+    _assign_TT,
+    _ctor_T,
+    _ctor_TT,
+    _dtor_T,
+    z
+  );
+  _dtor_T(y);  // ^?{}(&y); -- _dtor_T is a function pointer
+}
+\end{cfacode}
+Further to this point, every distinct array type will require a thunk for its destructor, where array destructor code is currently inlined, since array destructors hard code the length of the array.
+For function call temporaries, new scopes have to be added for destructor ordering to remain consistent.
+In particular, the translator currently destroys argument and return value temporary objects as soon as the statement they were created for ends.
+In order for this behaviour to be maintained, new scopes have to be added around every statement that contains a function call.
+Since a nested expression can raise an exception, care must be taken when destroying temporary objects.
+One way to achieve this is to split statements at every function call, to provide the correct scoping to destroy objects as necessary.
+For example,
+\begin{cfacode}
+struct S { ... };
+void ?{}(S *, S);
+void ^?{}(S *);
+S f();
+S g(S);
+g(f());
+\end{cfacode}
+would generate
+\begin{cfacode}
+struct S { ... };
+void _ctor_S(struct S *, struct S);
+void _dtor_S(struct S *);
+{
+  __attribute__((cleanup(_dtor_S))) struct S _tmp1 = f();
+  __attribute__((cleanup(_dtor_S))) struct S _tmp2 =
+    (_ctor_S(&_tmp2, _tmp1), _tmp2);
+  __attribute__((cleanup(_dtor_S))) struct S _tmp3 = g(_tmp2);
+} // destroy _tmp3, _tmp2, _tmp1
+\end{cfacode}
+Note that destructors must be registered after the temporary is fully initialized, since it is possible for initialization expressions to raise exceptions, and a destructor should never be called on an uninitialized object.
+This requires a slightly strange looking initializer for constructor calls, where a comma expression is used to produce the value of the object being initialized, after the constructor call, conceptually bitwise copying the initialized data into itself.
+Since this copy is wholly unnecessary, it is easily optimized away.
+A second approach is to attach an accompanying boolean to every temporary that records whether the object contains valid data, and thus whether the value should be destructed.
+\begin{cfacode}
+struct S { ... };
+void _ctor_S(struct S *, struct S);
+void _dtor_S(struct S *);
+struct _tmp_bundle_S {
+  bool valid;
+  struct S value;
+};
+void _dtor_tmpS(struct _tmp_bundle_S * ret) {
+  if (ret->valid) {
+    _dtor_S(&ret->value);
+  }
+}
+{
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp1 = { 0 };
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp2 = { 0 };
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp3 = { 0 };
+  _tmp2.value = g(
+    (_ctor_S(
+      &_tmp2.value,
+      (_tmp1.value = f(), _tmp1.valid = 1, _tmp1.value)
+    ), _tmp2.valid = 1, _tmp2.value)
+  ), _tmp3.valid = 1, _tmp3.value;
+} // destroy _tmp3, _tmp2, _tmp1
+\end{cfacode}
+In particular, the boolean is set immediately after argument construction and immediately after return value copy.
+The boolean is checked as a part of the @cleanup@ routine, forwarding to the object's destructor if the object is valid.
+One such type and @cleanup@ routine needs to be generated for every type used in a function parameter or return value.
+The former approach generates much simpler code, however splitting expressions requires care to ensure that expression evaluation order does not change.
+Expression ordering has to be performed by a full compiler, so it is possible that the latter approach would be more suited to the \CFA prototype, whereas the former approach is clearly the better option in a full compiler.
+More investigation is needed to determine whether the translator's current design can easily handle proper expression ordering.
+As discussed in Section \ref{s:implicit_copy_construction}, return values are destructed with a different @this@ pointer than they are constructed with.
+This problem can be easily fixed once a full \CFA compiler is built, since it would have full control over the call/return mechanism.
+In particular, since the callee is aware of where it needs to place the return value, it can construct the return value directly, rather than bitwise copy the internal data.
+Currently, the special functions are always auto-generated, except for generic types where the type parameter does not have assertions for the corresponding operation.
+For example,
+\begin{cfacode}
+forall(dtype T | sized(T) | { void ?{}(T *); })
+struct S { T x; };
+\end{cfacode}
+only auto-generates the default constructor for @S@, since the member @x@ is missing the other 3 special functions.
+Once deleted functions have been added, function generation can make use of this information to disable generation of special functions when a member has a deleted function.
+For example,
+\begin{cfacode}
+struct A {};
+void ?{}(A *) = delete;
+struct S { A x; };  // does not generate void ?{}(S *);
+\end{cfacode}
+Unmanaged objects and their interactions with the managed \CFA environment are an open problem that deserves greater attention.
+In particular, the interactions between unmanaged objects and copy semantics are subtle and can easily lead to errors.
+It is possible that the compiler should mark some of these situations as errors by default, and possibly conditionally emit warnings for some situations.
+Another possibility is to construct, destruct, and assign unmanaged objects using the intrinsic and auto-generated functions.
+A more thorough examination of the design space for this problem is required.
+Currently, the \CFA translator does not support any warnings.
+Ideally, the translator should support optional warnings in the case where it can detect that an object has been constructed twice.
+For example, forwarding constructor calls are guaranteed to initialize the entire object, so redundant constructor calls can cause problems such as memory leaks, while looking innocuous to a novice user.
+\begin{cfacode}
+struct B { ... };
+struct A {
+  B x, y, z;
+};
+void ?{}(A * a, B x) {
+  // y, z implicitly default constructed
+  (&a->x){ ... }; // explicitly construct x
+} // constructs an entire A
+void ?{}(A * a) {
+  (&a->y){}; // initialize y
+  a{ (B){ ... } }; // forwarding constructor call
+                   // initializes entire object, including y
+}
+\end{cfacode}
+Finally, while constructors provide a mechanism for establishing invariants, there is currently no mechanism for maintaining invariants without resorting to opaque types.
+That is, structure fields can be accessed and modified by any block of code without restriction, so while it is possible to ensure that an object is initially set to a valid state, it is not possible to ensure that it remains in a consistent state throughout its lifetime.
+A popular technique for ensuring consistency in object-oriented programming languages is to provide access modifiers such as @private@, which provides compile-time checks that only privileged code accesses private data.
+This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged.
+One possibility is to tie access control into an eventual module system.
+\subsection{Tuples}
+Named result values are planned, but not yet implemented.
+This feature ties nicely into named tuples, as seen in D and Swift.
+Currently, tuple flattening and structuring conversions are 0-cost.
+This makes tuples conceptually very simple to work with, but easily causes unnecessary ambiguity in situations where the type system should be able to differentiate between alternatives.
+Adding an appropriate cost function to tuple conversions will allow tuples to interact with the rest of the programming language more cohesively.
+\subsection{Variadic Functions}
+Use of @ttype@ functions currently relies heavily on recursion.
+\CC has opened variadic templates up so that recursion is not strictly necessary in some cases, and it would be interesting to see if any such cases can be applied to \CFA.
+\CC supports variadic templated data-types, making it possible to express arbitrary length tuples, arbitrary parameter function objects, and more with generic types.
+Currently, \CFA does not support @ttype@-parameter generic-types, though there does not appear to be a technical reason that it cannot.
+Notably, opening up support for this makes it possible to implement the exit form of scope guard (see section \ref{s:ResMgmt}), making it possible to call arbitrary functions at scope exit in idiomatic \CFA.

doc/rob_thesis/ctordtor.tex

-                      r221c2de7
+                      r154fdc8
 %======================================================================
+% TODO: discuss move semantics; they haven't been implemented, but could be. Currently looking at alternative models. (future work)
+% TODO: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2
+% TODO now: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2
 % doesn't seem possible to do this without allowing ttype on generic structs?
-% If a Cforall constructor is in scope, C style initialization is
-% disabled by default.
-% * initialization rule: if any constructor is in scope for type T, try
-%   to find a matching constructor for the call. If there are no
-%   constructors in scope for type T, then attempt to fall back on
-%   C-style initialization.
-% + if this rule was not in place, it would be easy to accidentally
-%   use C-style initialization in certain cases, which could lead to
-%   subtle errors [2]
-% - this means we need special syntax if we want to allow users to force
-%   a C-style initialization (to give users more control)
-% - two different declarations in the same scope can be implicitly
-%   initialized differently. That is, there may be two objects of type
-%   T that are initialized differently because there is a constructor
-%   definition between them. This is not technically specific to
-%   constructors.
-% C-style initializers can be accessed with @= syntax
-% + provides a way to get around the requirement of using a constructor
-%   (for advanced programmers only)
-% - can break invariants in the type => unsafe
-% * provides a way of asserting that a variable is an instance of a
-%   C struct (i.e. a POD struct), and so will not be implicitly
-%   destructed (this can be useful at times, maybe mitigates the need
-%   for move semantics?) [3]
-% + can modernize a code base one step at a time
-% Cforall constructors can be used in expressions to initialize any
-% piece of memory.
-% + malloc() { ... } calls the appropriate constructor on the newly
-%   allocated space; the argument is moved into the constructor call
-%   without taking its address [4]
-% - with the above form, there is still no way to ensure that
-%   dynamically allocated objects are constructed. To resolve this,
-%   we might want a stronger "new" function which always calls the
-%   constructor, although how we accomplish that is currently still
-%   unresolved (compiler magic vs. better variadic functions?)
-% + This can be used as a placement syntax [5]
-% - can call the constructor on an object more than once, which could
-%   cause resource leaks and reinitialize const fields (can try to
-%   detect and prevent this in some cases)
-%   * compiler always tries to implicitly insert a ctor/dtor pair for
-%     non-@= objects.
-%     * For POD objects, this will resolve to an autogenerated or
-%       intrinsic function.
-%     * Intrinsic functions are not automatically called. Autogenerated
-%       are, because they may call a non-autogenerated function.
-%     * destructors are automatically inserted at appropriate branches
-%       (e.g. return, break, continue, goto) and at the end of the block
-%       in which they are declared.
-%   * For @= objects, the compiler never tries to interfere and insert
-%     constructor and destructor calls for that object. Copy constructor
-%     calls do not count, because the object is not the target of the copy
-%     constructor.
-% A constructor is declared with the name ?{}
-% + combines the look of C initializers with the precedent of ?() being
-%   the name for the function call operator
-% + it is possible to easily search for all constructors in a project
-%   and immediately know that a function is a constructor by seeing the
-%   name "?{}"
-% A destructor is declared with the name ^?{}
-% + name mirrors a constructor's name, with an extra symbol to
-%   distinguish it
-% - the symbol '~' cannot be used due to parsing conflicts with the
-%   unary '~' (bitwise negation) operator - this conflict exists because
-%   we want to allow users to write ^x{}; to destruct x, rather than
-%   ^?{}(&x);
-% The first argument of a constructor must be a pointer. The constructed
-% type is the base type of the pointer. E.g. void ?{}(T *) is a default
-% constructor for a T.
-% + can name the argument whatever you like, so not constrained by
-%   language keyword "this" or "self", etc.
-% - have to explicitly qualify all object members to initialize them
-%   (e.g. this->x = 0, rather than just x = 0)
-% Destructors can take arguments other than just the destructed pointer
-% * open research problem: not sure how useful this is
-% Pointer constructors
-% + can construct separately compiled objects (opaque types) [6]
-% + orthogonal design, follows directly from the definition of the first
-%   argument of a constructor
-% - may require copy constructor or move constructor (or equivalent)
-%   for correct implementation, which may not be obvious to everyone
-% + required feature for the prelude to specify as much behavior as possible
-%   (similar to pointer assignment operators in this respect)
-% Designations can only be used for C-style initialization
-% * designation for constructors is equivalent to designation for any
-%   general function call. Since a function prototype can be redeclared
-%   many times, with arguments named differently each time (or not at
-%   all!), this is considered to be an undesirable feature. We could
-%   construct some set of rules to allow this behaviour, but it is
-%   probably more trouble than it's worth, and no matter what we choose,
-%   it is not likely to be obvious to most people.
-% Constructing an anonymous member [7]
-% + same as with calling any other function on an anonymous member
-%   (implicit conversion by the compiler)
-% - may be some cases where this is ambiguous => clarify with a cast
-%   (try to design APIs to avoid sharing function signatures between
-%   composed types to avoid this)
-% Default Constructors and Destructors are called implicitly
-% + cannot forget to construct or destruct an object
-% - requires special syntax to specify that an object is not to be
-%   constructed (@=)
-% * an object will not be implicitly constructed OR destructed if
-%   explicitly initialized like a C object (@= syntax)
-% * an object will be destructed if there are no constructors in scope
-%   (even though it is initialized like a C object) [8]
-% An object which changes from POD type to non POD type will not change
-% the semantics of a type containing it by composition
-% * That is, constructors will not be regenerated at the point where
-%   an object changes from POD type to non POD type, because this could
-%   cause a cascade of constructors being regenerated for many other
-%   types. Further, there is precedence for this behaviour in other
-%   facets of Cforall's design, such as how nested functions interact.
-% * This behaviour can be simplified in a language without declaration
-%   before use, because a type can be classified as POD or non POD
-%   (rather than potentially changing between the two at some point) at
-%   at the global scope (which is likely the most common case)
-% * [9]
-% Changes to polymorphic type classes
-% * dtype and ftype remain the same
-% * forall(otype T) is currently essentially the same as
-%   forall(dtype T | { @size(T); void ?=?(T *, T); }).
-%   The big addition is that you can declare an object of type T, rather
-%   than just a pointer to an object of type T since you know the size,
-%   and you can assign into a T.
-%   * this definition is changed to add default constructor and
-%     destructor declarations, to remain consistent with what type meant
-%     before the introduction of constructors and destructors.
-%     * that is, forall(type T) is now essentially the same as
-%       forall(dtype T | { @size(T); void ?=?(T *, T);
-%                          void ?{}(T *); void ^?{}(T *); })
-%     + this is required to make generic types work correctly in
-%       polymorphic functions
-%     ? since declaring a constructor invalidates the autogenerated
-%       routines, it is possible for a type to have constructors, but
-%       not default constructors. That is, it might be the case that
-%       you want to write a polymorphic function for a type which has
-%       a size, but non-default constructors? Some options:
-%       * declaring a constructor as a part of the assertions list for
-%         a type declaration invalidates the default, so
-%         forall(otype T | { void ?{}(T *, int); })
-%         really means
-%         forall(dtype T | { @size(T); void ?=?(T *, T);
-%                            void ?{}(T *, int); void ^?{}(T *); })
-%       * force users to fully declare the assertions list like the
-%         above in this case (this seems very undesirable)
-%       * add another type class with the current desugaring of type
-%         (just size and assignment)
-%       * provide some way of subtracting from an existing assertions
-%         list (this might be useful to have in general)
-% Implementation issues:
-% Changes to prelude/autogen or built in defaults?
-% * pointer ctors/dtors [prelude]
-%   * other pointer type routines are declared in the prelude, and this
-%     doesn't seem like it should be any different
-% * basic type ctors/dtors [prelude]
-%   * other basic type routines are declared in the prelude, and this
-%     doesn't seem like it should be any different
-% ? aggregate types [undecided, but leaning towards autogenerate]
-%   * prelude
-%     * routines specific to aggregate types cannot be predeclared in
-%       the prelude because we don't know the name of every
-%       aggregate type in the entire program
-%   * autogenerate
-%     + default assignment operator is already autogenerated for
-%       aggregate types
-%       * this seems to lead us in the direction of autogenerating,
-%         because we may have a struct which contains other objects
-%         that require construction [10]. If we choose not to
-%         autogenerate in this case, then objects which are part of
-%         other objects by composition will not be constructed unless
-%         a constructor for the outer type is explicitly defined
-%       * in this case, we would always autogenerate the appropriate
-%         constructor(s) for an aggregate type, but just like with
-%         basic types, pointer types, and enum types, the constructor
-%         call can be elided when when it is not necessary.
-%     + constructors will have to be explicitly autogenerated
-%       in the case where they are required for a polymorphic function,
-%       when no user defined constructor is in scope, which may make it
-%       easiest to always autogenerate all appropriate constructors
-%     - n+2 constructors would have to be generated for a POD type
-%       * one constructor for each number of valid arguments [0, n],
-%         plus the copy constructor
-%         * this is taking a simplified approach: in C, it is possible
-%           to omit the enclosing braces in a declaration, which would
-%           lead to a combinatorial explosion of generated constructors.
-%           In the interest of keeping things tractable, Cforall may be
-%           incompatible with C in this case. [11]
-%       * for non-POD types, only autogenerate the default and copy
-%         constructors
-%       * alternative: generate only the default constructor and
-%         special case initialization for any other constructor when
-%         only the autogenerated one exists
-%         - this is not very sensible, as by the previous point, these
-%           constructors may be needed for polymorphic functions
-%           anyway.
-%     - must somehow distinguish in resolver between autogenerated and
-%       user defined constructors (autogenerated should never be chosen
-%       when a user defined option exists [check first parameter], even
-%       if full signature differs) (this may also have applications
-%       to other autogenerated routines?)
-%     - this scheme does not naturally support designation (i.e. general
-%       functions calls do not support designation), thus these cases
-%       will have to be treated specially in either case
-%   * defaults
-%     * i.e. hardcode a new set of rules for some "appropriate" default
-%       behaviour for
-%     + when resolving an initialization expression, explicitly check to
-%       see if any constructors are in scope. If yes, attempt to resolve
-%       to a constructor, and produce an error message if a match is not
-%       found. If there are no constructors in scope, resolve to
-%       initializing each field individually (C-style)
-%     + does not attempt to autogenerate constructors for POD types,
-%       which can be seen as a space optimization for the program
-%       binary
-%     - as stated previously, a polymorphic routine may require these
-%       autogenerated constructors, so this doesn't seem like a big win,
-%       because this leads to more complicated logic and tracking of
-%       which constructors have already been generated
-%     - even though a constructor is not explicitly declared or used
-%       polymorphically, we might still need one for all uses of a
-%       struct (e.g. in the case of composition).
-%   * the biggest tradeoff in autogenerating vs. defaulting appears to
-%     be in where and how the special code to check if constructors are
-%     present is handled. It appears that there are more reasons to
-%     autogenerate than not.
-% --- examples
-% [1] As an example of using constructors polymorphically, consider a
-% slight modification on the foldl example I put on the mailing list a
-% few months ago:
-% context iterable(type collection, type element, type iterator) {
-%   void ?{}(iterator *, collection); // used to be makeIterator, but can
-%                             // idiomatically use constructor
-%   int hasNext(iterator);
-%   iterator ++?(iterator *);
-%   lvalue element *?(iterator);
-% };
-% forall(type collection, type element, type result, type iterator
-%   | iterable(collection, element, iterator))
-% result foldl(collection c, result acc,
-%     result (*reduce)(result, element)) {
-%   iterator it = { c };
-%   while (hasNext(it)) {
-%     acc = reduce(acc, *it);
-%     ++it;
-%   }
-%   return acc;
-% }
-% Now foldl makes use of the knowledge that the iterator type has a
-% single argument constructor which takes the collection to iterate
-% over. This pattern allows polymorphic code to look more natural
-% (constructors are generally preferred to named initializer/creation
-% routines, e.g. "makeIterator")
-% [2] An example of some potentially dangerous code that we don't want
-% to let easily slip through the cracks - if this is really what you
-% want, then use @= syntax for the second declaration to quiet the
-% compiler.
-% struct A { int x, y, z; }
-% ?{}(A *, int);
-% ?{}(A *, int, int, int);
-% A a1 = { 1 };         // uses ?{}(A *, int);
-% A a2 = { 2, 3 };      // C-style initialization -> no invariants!
-% A a3 = { 4, 5, 6 };   // uses ?{}(A *, int, int, int);
-% [3] Since @= syntax creates a C object (essentially a POD, as far as
-% the compiler is concerned), the object will not be destructed
-% implicitly when it leaves scope, nor will it be copy constructed when
-% it is returned. In this case, a memcpy should be equivalent to a move.
-% // Box.h
-% struct Box;
-% void ?{}(Box **, int};
-% void ^?{}(Box **);
-% Box * make_fortytwo();
-% // Box.cfa
-% Box * make_fortytwo() {
-%   Box *b @= {};
-%   (&b){ 42 }; // construct explicitly
-%   return b; // no destruction, essentially a move?
-% }
-% [4] Cforall's typesafe malloc can be composed with constructor
-% expressions. It is possible for a user to define their own functions
-% similar to malloc and achieve the same effects (e.g. Aaron's example
-% of an arena allocator)
-% // CFA malloc
-% forall(type T)
-% T * malloc() { return (T *)malloc(sizeof(T)); }
-% struct A { int x, y, z; };
-% void ?{}(A *, int);
-% int foo(){
-%   ...
-%   // desugars to:
-%   // A * a = ?{}(malloc(), 123);
-%   A * a = malloc() { 123 };
-%   ...
-% }
-% [5] Aaron's example of combining function calls with constructor
-% syntax to perform an operation similar to C++'s std::vector::emplace
-% (i.e. to construct a new element in place, without the need to
-% copy)
-% forall(type T)
-% struct vector {
-%   T * elem;
-%   int len;
-%   ...
-% };
-% ...
-% forall(type T)
-% T * vector_new(vector(T) * v) {
-%   // reallocate if needed
-%   return &v->elem[len++];
-% }
-% int main() {
-%   vector(int) * v = ...
-%   vector_new(v){ 42 };  // add element to the end of vector
-% }
-% [6] Pointer Constructors. It could be useful to use the existing
-% constructor syntax even more uniformly for ADTs. With this, ADTs can
-% be initialized in the same manor as any other object in a polymorphic
-% function.
-% // vector.h
-% forall(type T) struct vector;
-% forall(type T) void ?{}(vector(T) **);
-% // adds an element to the end
-% forall(type T) vector(T) * ?+?(vector(T) *, T);
-% // vector.cfa
-% // don't want to expose the implementation to the user and/or don't
-% // want to recompile the entire program if the struct definition
-% // changes
-% forall(type T) struct vector {
-%   T * elem;
-%   int len;
-%   int capacity;
-% };
-% forall(type T) void resize(vector(T) ** v) { ... }
-% forall(type T) void ?{}(vector(T) ** v) {
-%   vector(T) * vect = *v = malloc();
-%   vect->capacity = 10;
-%   vect->len = 0;
-%   vect->elem = malloc(vect->capacity);
-% }
-% forall(type T) vector(T) * ?+?(vector(T) *v, T elem) {
-%   if (v->len == v->capacity) resize(&v);
-%   v->elem[v->len++] = elem;
-% }
-% // main.cfa
-% #include "adt.h"
-% forall(type T | { T ?+?(T, int); }
-% T sumRange(int lower, int upper) {
-%   T x;    // default construct
-%   for (int i = lower; i <= upper; i++) {
-%     x = x + i;
-%   }
-%   return x;
-% }
-% int main() {
-%   vector(int) * numbers = sumRange(1, 10);
-%   // numbers is now a vector containing [1..10]
-%   int sum = sumRange(1, 10);
-%   // sum is now an int containing the value 55
-% }
-% [7] The current proposal is to use the plan 9 model of inheritance.
-% Under this model, all of the members of an unnamed struct instance
-% become members of the containing struct. In addition, an object
-% can be passed as an argument to a function expecting one of its
-% base structs.
-% struct Point {
-%   double x;
-%   double y;
-% };
-% struct ColoredPoint {
-%   Point;        // anonymous member (no identifier)
-%                 // => a ColoredPoint has an x and y of type double
-%   int color;
-% };
-% ColoredPoint cp = ...;
-% cp.x = 10.3;    // x from Point is accessed directly
-% cp.color = 0x33aaff; // color is accessed normally
-% foo(cp);        // cp can be used directly as a Point
-% void ?{}(Point *p, double x, double y) {
-%   p->x = x;
-%   p->y = y;
-% }
-% void ?{}(ColoredPoint *cp, double x, double y, int color) {
-%   (&cp){ x, y };  // unambiguous, no ?{}(ColoredPoint*,double,double)
-%   cp->color = color;
-% }
-% struct Size {
-%   double width;
-%   double height;
-% };
-% void ?{}(Size *s, double w, double h) {
-%   p->width = w;
-%   p->height = h;
-% }
-% struct Foo {
-%   Point;
-%   Size;
-% }
-% ?{}(Foo &f, double x, double y, double w, double h) {
-%   // (&F,x,y) is ambiguous => is it ?{}(Point*,double,double) or
-%   // ?{}(Size*,double,double)? Solve with a cast:
-%   ((Point*)&F){ x, y };
-%   ((Size*)&F){ w, h };
-% }
-% [8] Destructors will be called on objects that were not constructed.
-% struct A { ... };
-% ^?{}(A *);
-% {
-%   A x;
-%   A y @= {};
-% } // x is destructed, even though it wasn't constructed
-%   // y is not destructed, because it is explicitly a C object
-% [9] A type's constructor is generated at declaration time using
-% current information about an object's members. This is analogous to
-% the treatment of other operators. For example, an object's assignment
-% operator will not change to call the override of a member's assignment
-% operator unless the object's assignment is also explicitly overridden.
-% This problem can potentially be treated differently in Do, since each
-% compilation unit is passed over at least twice (once to gather
-% symbol information, once to generate code - this is necessary to
-% achieve the "No declarations" goal)
-% struct A { ... };
-% struct B { A x; };
-% ...
-% void ?{}(A *);  // from this point on, A objects will be constructed
-% B b1;           // b1 and b1.x are both NOT constructed, because B
-%                 // objects are not constructed
-% void ?{}(B *);  // from this point on, B objects will be constructed
-% B b2;           // b2 and b2.x are both constructed
-% struct C { A x; };
-% // implicit definition of ?{}(C*), because C is not a POD type since
-% // it contains a non-POD type by composition
-% C c;            // c and c.x are both constructed
-% [10] Requiring construction by composition
-% struct A {
-%   ...
-% };
-% // declared ctor disables default c-style initialization of
-% // A objects; A is no longer a POD type
-% void ?{}(A *);
-% struct B {
-%   A x;
-% };
-% // B objects can not be C-style initialized, because A objects
-% // must be constructed => B objects are transitively not POD types
-% B b; // b.x must be constructed, but B is not constructible
-%      // => must autogenerate ?{}(B *) after struct B definition,
-%      // which calls ?{}(&b.x)
-% [11] Explosion in the number of generated constructors, due to strange
-% C semantics.
-% struct A { int x, y; };
-% struct B { A u, v, w; };
-% A a = { 0, 0 };
-% // in C, you are allowed to do this
-% B b1 = { 1, 2, 3, 4, 5, 6 };
-% B b2 = { 1, 2, 3 };
-% B b3 = { a, a, a };
-% B b4 = { a, 5, 4, a };
-% B b5 = { 1, 2, a, 3 };
-% // we want to disallow b1, b2, b4, and b5 in Cforall.
-% // In particular, we will autogenerate these constructors:
-% void ?{}(A *);             // default/0 parameters
-% void ?{}(A *, int);        // 1 parameter
-% void ?{}(A *, int, int);   // 2 parameters
-% void ?{}(A *, const A *);  // copy constructor
-% void ?{}(B *);             // default/0 parameters
-% void ?{}(B *, A);          // 1 parameter
-% void ?{}(B *, A, A);       // 2 parameters
-% void ?{}(B *, A, A, A);    // 3 parameters
-% void ?{}(B *, const B *);  // copy constructor
-% // we will not generate constructors for every valid combination
-% // of members in C. For example, we will not generate
-% void ?{}(B *, int, int, int, int, int, int);   // b1 would need this
-% void ?{}(B *, int, int, int);                  // b2 would need this
-% void ?{}(B *, A, int, int, A);                 // b4 would need this
-% void ?{}(B *, int, int, A, int);               // b5 would need this
-% // and so on
-% TODO: talk somewhere about compound literals?
 Since \CFA is a true systems language, it does not provide a garbage collector.
 As well, \CFA is not an object-oriented programming language, i.e. structures cannot have routine members.
+As well, \CFA is not an object-oriented programming language, \ie, structures cannot have routine members.
 Nevertheless, one important goal is to reduce programming complexity and increase safety.
 To that end, \CFA provides support for implicit pre/post-execution of routines for objects, via constructors and destructors.
-% TODO: this is old. remove or refactor
-% Manual resource management is difficult.
-% Part of the difficulty results from not having any guarantees about the current state of an object.
-% Objects can be internally composed of pointers that may reference resources which may or may not need to be manually released, and keeping track of that state for each object can be difficult for the end user.
-% Constructors and destructors provide a mechanism to bookend the lifetime of an object, allowing the designer of a type to establish invariants for objects of that type.
-% Constructors guarantee that object initialization code is run before the object can be used, while destructors provide a mechanism that is guaranteed to be run immediately before an object's lifetime ends.
-% Constructors and destructors can help to simplify resource management when used in a disciplined way.
-% In particular, when all resources are acquired in a constructor, and all resources are released in a destructor, no resource leaks are possible.
-% This pattern is a popular idiom in several languages, such as \CC, known as RAII (Resource Acquisition Is Initialization).
 This chapter details the design of constructors and destructors in \CFA, along with their current implementation in the translator.
 Generated code samples have been edited to provide comments for clarity and to save on space.
+Generated code samples have been edited for clarity and brevity.
 \section{Design Criteria}
 …
 Next, @x@ is assigned the value of @y@.
 In the last line, @z@ is implicitly initialized to 0 since it is marked @static@.
 The key difference between assignment and initialization being that assignment occurs on a live object (i.e. an object that contains data).
+The key difference between assignment and initialization being that assignment occurs on a live object (\ie, an object that contains data).
 It is important to note that this means @x@ could have been used uninitialized prior to being assigned, while @y@ could not be used uninitialized.
+Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs. % TODO: *citation*
+Declaration initialization is insufficient, because it permits uninitialized variables to exist and because it does not allow for the insertion of arbitrary code before the variable is live.
+Many C compilers give good warnings most of the time, but they cannot in all cases.
+\begin{cfacode}
+int f(int *);  // never reads the parameter, only writes
+int g(int *);  // reads the parameter - expects an initialized variable
+Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs.
+Initialization of a declaration is strictly optional, permitting uninitialized variables to exist.
+Furthermore, declaration initialization is limited to expressions, so there is no way to insert arbitrary code before a variable is live, without delaying the declaration.
+Many C compilers give good warnings for uninitialized variables most of the time, but they cannot in all cases.
+\begin{cfacode}
+int f(int *);  // output parameter: never reads, only writes
+int g(int *);  // input parameter: never writes, only reads,
+               // so requires initialized variable
 int x, y;
 f(&x);  // okay - only writes to x
 g(&y);  // will use y uninitialized
 \end{cfacode}
 Other languages are able to give errors in the case of uninitialized variable use, but due to backwards compatibility concerns, this cannot be the case in \CFA.
 In C, constructors and destructors are often mimicked by providing routines that create and teardown objects, where the teardown function is typically only necessary if the type modifies the execution environment.
+g(&y);  // uses y uninitialized
+\end{cfacode}
+Other languages are able to give errors in the case of uninitialized variable use, but due to backwards compatibility concerns, this is not the case in \CFA.
+In C, constructors and destructors are often mimicked by providing routines that create and tear down objects, where the tear down function is typically only necessary if the type modifies the execution environment.
 \begin{cfacode}
 struct array_int {
 …
 };
 struct array_int create_array(int sz) {
   return (struct array_int) { malloc(sizeof(int)*sz) };
+  return (struct array_int) { calloc(sizeof(int)*sz) };
+}
 void destroy_rh(struct resource_holder * rh) {
 …
 Furthermore, even with this idiom it is easy to make mistakes, such as forgetting to destroy an object or destroying it multiple times.
 A constructor provides a way of ensuring that the necessary aspects of object initialization is performed, from setting up invariants to providing compile-time checks for appropriate initialization parameters.
+A constructor provides a way of ensuring that the necessary aspects of object initialization is performed, from setting up invariants to providing compile- and run-time checks for appropriate initialization parameters.
 This goal is achieved through a guarantee that a constructor is called implicitly after every object is allocated from a type with associated constructors, as part of an object's definition.
 Since a constructor is called on every object of a managed type, it is impossible to forget to initialize such objects, as long as all constructors perform some sensible form of initialization.
 In \CFA, a constructor is a function with the name @?{}@.
+Like other operators in \CFA, the name represents the syntax used to call the constructor, \eg, @struct S = { ... };@.
 Every constructor must have a return type of @void@ and at least one parameter, the first of which is colloquially referred to as the \emph{this} parameter, as in many object-oriented programming-languages (however, a programmer can give it an arbitrary name).
 The @this@ parameter must have a pointer type, whose base type is the type of object that the function constructs.
 …
 In C, if the user creates an @Array@ object, the fields @data@ and @len@ are uninitialized, unless an explicit initializer list is present.
 It is the user's responsibility to remember to initialize both of the fields to sensible values.
+It is the user's responsibility to remember to initialize both of the fields to sensible values, since there are no implicit checks for invalid values or reasonable defaults.
 In \CFA, the user can define a constructor to handle initialization of @Array@ objects.
 …
 This constructor initializes @x@ so that its @length@ field has the value 10, and its @data@ field holds a pointer to a block of memory large enough to hold 10 @int@s, and sets the value of each element of the array to 0.
 This particular form of constructor is called the \emph{default constructor}, because it is called on an object defined without an initializer.
 In other words, a default constructor is a constructor that takes a single argument, the @this@ parameter.
 In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}!.
 A destructor for the @Array@ type can be defined as such.
+In other words, a default constructor is a constructor that takes a single argument: the @this@ parameter.
+In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}! and it takes only one argument.
+A destructor for the @Array@ type can be defined as:
 \begin{cfacode}
 void ^?{}(Array * arr) {
 …
+}
 \end{cfacode}
+Since the destructor is automatically called at deallocation for all objects of type @Array@, the memory associated with an @Array@ is automatically freed when the object's lifetime ends.
+The destructor is automatically called at deallocation for all objects of type @Array@.
+Hence, the memory associated with an @Array@ is automatically freed when the object's lifetime ends.
 The exact guarantees made by \CFA with respect to the calling of destructors are discussed in section \ref{sub:implicit_dtor}.
 …
 \end{cfacode}
 By the previous definition of the default constructor for @Array@, @x@ and @y@ are initialized to valid arrays of length 10 after their respective definitions.
 On line 3, @z@ is initialized with the value of @x@, while on line @4@, @y@ is assigned the value of @x@.
+On line 2, @z@ is initialized with the value of @x@, while on line 3, @y@ is assigned the value of @x@.
 The key distinction between initialization and assignment is that a value to be initialized does not hold any meaningful values, whereas an object to be assigned might.
 In particular, these cases cannot be handled the same way because in the former case @z@ does not currently own an array, while @y@ does.
 …
 The first function is called a \emph{copy constructor}, because it constructs its argument by copying the values from another object of the same type.
 The second function is the standard copy-assignment operator.
 These four functions are special in that they control the state of most objects.
+The four functions (default constructor, destructor, copy constructor, and assignment operator) are special in that they safely control the state of most objects.
 It is possible to define a constructor that takes any combination of parameters to provide additional initialization options.
 For example, a reasonable extension to the array type would be a constructor that allocates the array to a given initial capacity and initializes the array to a given @fill@ value.
+For example, a reasonable extension to the array type would be a constructor that allocates the array to a given initial capacity and initializes the elements of the array to a given @fill@ value.
 \begin{cfacode}
 void ?{}(Array * arr, int capacity, int fill) {
 …
+}
 \end{cfacode}
 In \CFA, constructors are called implicitly in initialization contexts.
 \begin{cfacode}
 Array x, y = { 20, 0xdeadbeef }, z = y;
 \end{cfacode}
 In \CFA, constructor calls look just like C initializers, which allows them to be inserted into legacy C code with minimal code changes, and also provides a very simple syntax that veteran C programmers are familiar with.
 One downside of reusing C initialization syntax is that it isn't possible to determine whether an object is constructed just by looking at its declaration, since that requires knowledge of whether the type is managed at that point.
+Constructor calls look just like C initializers, which allows them to be inserted into legacy C code with minimal code changes, and also provides a very simple syntax that veteran C programmers are familiar with.
+One downside of reusing C initialization syntax is that it is not possible to determine whether an object is constructed just by looking at its declaration, since that requires knowledge of whether the type is managed at that point in the program.
 This example generates the following code
 …
 Destructors are implicitly called in reverse declaration-order so that objects with dependencies are destructed before the objects they are dependent on.
 \subsection{Syntax}
 \label{sub:syntax} % TODO: finish this section
+\subsection{Calling Syntax}
+\label{sub:syntax}
 There are several ways to construct an object in \CFA.
 As previously introduced, every variable is automatically constructed at its definition, which is the most natural way to construct an object.
 …
 A * y = malloc();  // copy construct: ?{}(&y, malloc())
 ?{}(&x);    // explicit construct x
 ?{}(y, x);  // explit construct y from x
 ^?{}(&x);   // explicit destroy x
+?{}(&x);    // explicit construct x, second construction
+?{}(y, x);  // explit construct y from x, second construction
+^?{}(&x);   // explicit destroy x, in different order
 ^?{}(y);    // explicit destroy y
 …
 // implicit ^?{}(&x);
 \end{cfacode}
 Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of a piece of storage.
+Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of storage.
 In particular, constructors double as a placement syntax.
 \begin{cfacode}
 …
 \end{cfacode}
 Finally, constructors and destructors support \emph{operator syntax}.
+Like other operators in \CFA, the function name mirrors the use-case, in that the first $N$ arguments fill in the place of the question mark.
+Like other operators in \CFA, the function name mirrors the use-case, in that the question marks are placeholders for the first $N$ arguments.
+This syntactic form is similar to the new initialization syntax in \CCeleven, except that it is used in expression contexts, rather than declaration contexts.
 \begin{cfacode}
 struct A { ... };
 …
 Destructor operator syntax is actually an statement, and requires parentheses for symmetry with constructor syntax.
+One of these three syntactic forms should appeal to either C or \CC programmers using \CFA.
+\subsection{Constructor Expressions}
+In \CFA, it is possible to use a constructor as an expression.
+Like other operators, the function name @?{}@ matches its operator syntax.
+For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result.
+A key example for this capability is the use of constructor expressions to initialize the result of a call to @malloc@.
+\begin{cfacode}
+struct X { ... };
+void ?{}(X *, double);
+X * x = malloc(){ 1.5 };
+\end{cfacode}
+In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@.
+If this extension is not present, constructing dynamically allocated objects is much more cumbersome, requiring separate initialization of the pointer and initialization of the pointed-to memory.
+\begin{cfacode}
+X * x = malloc();
+x{ 1.5 };
+\end{cfacode}
+Not only is this verbose, but it is also more error prone, since this form allows maintenance code to easily sneak in between the initialization of @x@ and the initialization of the memory that @x@ points to.
+This feature is implemented via a transformation producing the value of the first argument of the constructor, since constructors do not themselves have a return value.
+Since this transformation results in two instances of the subexpression, care is taken to allocate a temporary variable to hold the result of the subexpression in the case where the subexpression may contain side effects.
+The previous example generates the following code.
+\begin{cfacode}
+struct X *_tmp_ctor;
+struct X *x = ?{}(  // construct result of malloc
+  _tmp_ctor=malloc_T( // store result of malloc
+    sizeof(struct X),
+    _Alignof(struct X)
+  ),
+.5
+), _tmp_ctor; // produce constructed result of malloc
+\end{cfacode}
+It should be noted that this technique is not exclusive to @malloc@, and allows a user to write a custom allocator that can be idiomatically used in much the same way as a constructed @malloc@ call.
+It should be noted that while it is possible to use operator syntax with destructors, destructors invalidate their argument, thus operator syntax with destructors is a statement and does not produce a value.
 \subsection{Function Generation}
 In \CFA, every type is defined to have the core set of four functions described previously.
+In \CFA, every type is defined to have the core set of four special functions described previously.
 Having these functions exist for every type greatly simplifies the semantics of the language, since most operations can simply be defined directly in terms of function calls.
 In addition to simplifying the definition of the language, it also simplifies the analysis that the translator must perform.
 …
 There are several options for user-defined types: structures, unions, and enumerations.
 To aid in ease of use, the standard set of four functions is automatically generated for a user-defined type after its definition is completed.
 By auto-generating these functions, it is ensured that legacy C code will continue to work correctly in every context where \CFA expects these functions to exist, since they are generated for every complete type.
+By auto-generating these functions, it is ensured that legacy C code continues to work correctly in every context where \CFA expects these functions to exist, since they are generated for every complete type.
 The generated functions for enumerations are the simplest.
+Since enumerations in C are essentially just another integral type, the generated functions behave in the same way that the builtin functions for the basic types work.
+% TODO: examples for enums
+Since enumerations in C are essentially just another integral type, the generated functions behave in the same way that the built-in functions for the basic types work.
 For example, given the enumeration
 \begin{cfacode}
 …
+}
 void ?{}(enum Colour *_dst, enum Colour _src){
   (*_dst)=_src;  // bitwise copy
+  *_dst=_src;  // bitwise copy
+}
 void ^?{}(enum Colour *_dst){
 …
+}
 enum Colour ?=?(enum Colour *_dst, enum Colour _src){
   return (*_dst)=_src; // bitwise copy
+  return *_dst=_src; // bitwise copy
+}
 \end{cfacode}
 In the future, \CFA will introduce strongly-typed enumerations, like those in \CC.
 The existing generated routines will be sufficient to express this restriction, since they are currently set up to take in values of that enumeration type.
+The existing generated routines are sufficient to express this restriction, since they are currently set up to take in values of that enumeration type.
 Changes related to this feature only need to affect the expression resolution phase, where more strict rules will be applied to prevent implicit conversions from integral types to enumeration types, but should continue to permit conversions from enumeration types to @int@.
 In this way, it will still be possible to add an @int@ to an enumeration, but the resulting value will be an @int@, meaning that it won't be possible to reassign the value into an enumeration without a cast.
+In this way, it is still possible to add an @int@ to an enumeration, but the resulting value is an @int@, meaning it cannot be reassigned to an enumeration without a cast.
 For structures, the situation is more complicated.
 For a structure @S@ with members @M$_0$@, @M$_1$@, ... @M$_{N-1}$@, each function @f@ in the standard set calls \lstinline{f(s->M$_i$, ...)} for each @$i$@.
 That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor with copy construct them, and so on.
 For example given the struct definition
+Given a structure @S@ with members @M$_0$@, @M$_1$@, ... @M$_{N-1}$@, each function @f@ in the standard set calls \lstinline{f(s->M$_i$, ...)} for each @$i$@.
+That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor copy constructs them, and so on.
+For example, given the structure definition
 \begin{cfacode}
 struct A {
 …
+}
 \end{cfacode}
 It is important to note that the destructors are called in reverse declaration order to resolve conflicts in the event there are dependencies among members.
+It is important to note that the destructors are called in reverse declaration order to prevent conflicts in the event there are dependencies among members.
 In addition to the standard set, a set of \emph{field constructors} is also generated for structures.
 The field constructors are constructors that consume a prefix of the struct's member list.
+The field constructors are constructors that consume a prefix of the structure's member-list.
 That is, $N$ constructors are built of the form @void ?{}(S *, T$_{\text{M}_0}$)@, @void ?{}(S *, T$_{\text{M}_0}$, T$_{\text{M}_1}$)@, ..., @void ?{}(S *, T$_{\text{M}_0}$, T$_{\text{M}_1}$, ..., T$_{\text{M}_{N-1}}$)@, where members are copy constructed if they have a corresponding positional argument and are default constructed otherwise.
 The addition of field constructors allows structs in \CFA to be used naturally in the same ways that they could be used in C (i.e. to initialize any prefix of the struct), e.g., @A a0 = { b }, a1 = { b, c }@.
+The addition of field constructors allows structures in \CFA to be used naturally in the same ways as used in C (\ie, to initialize any prefix of the structure), \eg, @A a0 = { b }, a1 = { b, c }@.
 Extending the previous example, the following constructors are implicitly generated for @A@.
 \begin{cfacode}
 …
 \end{cfacode}
 For unions, the default constructor and destructor do nothing, as it is not obvious which member if any should be constructed.
+For unions, the default constructor and destructor do nothing, as it is not obvious which member, if any, should be constructed.
 For copy constructor and assignment operations, a bitwise @memcpy@ is applied.
 In standard C, a union can also be initialized using a value of the same type as its first member, and so a corresponding field constructor is generated to perform a bitwise @memcpy@ of the object.
 An alterantive to this design is to always construct and destruct the first member of a union, to match with the C semantics of initializing the first member of the union.
+An alternative to this design is to always construct and destruct the first member of a union, to match with the C semantics of initializing the first member of the union.
 This approach ultimately feels subtle and unsafe.
 Another option is to, like \CC, disallow unions from containing members that are themselves managed types.
 …
 % This feature works in the \CFA model, since constructors are simply special functions and can be called explicitly, unlike in \CC. % this sentence isn't really true => placement new
 In \CCeleven, this restriction has been loosened to allow unions with managed members, with the caveat that any if there are any members with a user-defined operation, then that operation is not implicitly defined, forcing the user to define the operation if necessary.
+In \CCeleven, unions may have managed members, with the caveat that if there are any members with a user-defined operation, then that operation is not implicitly defined, forcing the user to define the operation if necessary.
 This restriction could easily be added into \CFA once \emph{deleted} functions are added.
 \subsection{Using Constructors and Destructors}
 Implicitly generated constructor and destructor calls ignore the outermost type qualifiers, e.g. @const@ and @volatile@, on a type by way of a cast on the first argument to the function.
+Implicitly generated constructor and destructor calls ignore the outermost type qualifiers, \eg @const@ and @volatile@, on a type by way of a cast on the first argument to the function.
 For example,
 \begin{cfacode}
 …
 Here, @&s@ and @&s2@ are cast to unqualified pointer types.
 This mechanism allows the same constructors and destructors to be used for qualified objects as for unqualified objects.
+Since this applies only to implicitly generated constructor calls, the language does not allow qualified objects to be re-initialized with a constructor without an explicit cast.
+This rule applies only to implicitly generated constructor calls.
+Hence, explicitly re-initializing qualified objects with a constructor requires an explicit cast.
+As discussed in Section \ref{sub:c_background}, compound literals create unnamed objects.
+This mechanism can continue to be used seamlessly in \CFA with managed types to create temporary objects.
+The object created by a compound literal is constructed using the provided brace-enclosed initializer-list, and is destructed at the end of the scope it is used in.
+For example,
+\begin{cfacode}
+struct A { int x; };
+void ?{}(A *, int, int);
+{
+  int x = (A){ 10, 20 }.x;
+}
+\end{cfacode}
+is equivalent to
+\begin{cfacode}
+struct A { int x, y; };
+void ?{}(A *, int, int);
+{
+  A _tmp;
+  ?{}(&_tmp, 10, 20);
+  int x = _tmp.x;
+  ^?{}(&tmp);
+}
+\end{cfacode}
 Unlike \CC, \CFA provides an escape hatch that allows a user to decide at an object's definition whether it should be managed or not.
 …
 A a2 @= { 0 };  // unmanaged
 \end{cfacode}
+In this example, @a1@ is a managed object, and thus is default constructed and destructed at the end of @a1@'s lifetime, while @a2@ is an unmanaged object and is not implicitly constructed or destructed.
+Instead, @a2->x@ is initialized to @0@ as if it were a C object, due to the explicit initializer.
+Existing constructors are ignored when \ateq is used, so that any valid C initializer is able to initialize the object.
+In addition to freedom, \ateq provides a simple path to migrating legacy C code to Cforall, in that objects can be moved from C-style initialization to \CFA gradually and individually.
+In this example, @a1@ is a managed object, and thus is default constructed and destructed at the start/end of @a1@'s lifetime, while @a2@ is an unmanaged object and is not implicitly constructed or destructed.
+Instead, @a2->x@ is initialized to @0@ as if it were a C object, because of the explicit initializer.
+In addition to freedom, \ateq provides a simple path for migrating legacy C code to \CFA, in that objects can be moved from C-style initialization to \CFA gradually and individually.
 It is worth noting that the use of unmanaged objects can be tricky to get right, since there is no guarantee that the proper invariants are established on an unmanaged object.
 It is recommended that most objects be managed by sensible constructors and destructors, except where absolutely necessary.
 When the user declares any constructor or destructor, the corresponding intrinsic/generated function and all field constructors for that type are hidden, so that they will not be found during expression resolution unless the user-defined function goes out of scope.
 Furthermore, if the user declares any constructor, then the intrinsic/generated default constructor is also hidden, making it so that objects of a type may not be default constructable.
 This closely mirrors the rule for implicit declaration of constructors in \CC, wherein the default constructor is implicitly declared if there is no user-declared constructor. % TODO: cite C++98 page 186??
+When a user declares any constructor or destructor, the corresponding intrinsic/generated function and all field constructors for that type are hidden, so that they are not found during expression resolution until the user-defined function goes out of scope.
+Furthermore, if the user declares any constructor, then the intrinsic/generated default constructor is also hidden, precluding default construction.
+These semantics closely mirror the rule for implicit declaration of constructors in \CC, wherein the default constructor is implicitly declared if there is no user-declared constructor \cite[p.~186]{ANSI98:C++}.
 \begin{cfacode}
 struct S { int x, y; };
 …
   S s0, s1 = { 0 }, s2 = { 0, 2 }, s3 = s2;  // okay
+  {
     void ?{}(S * s, int i) { s->x = i*2; }
     S s4;  // error
     S s5 = { 3 };  // okay
     S s6 = { 4, 5 };  // error
+    void ?{}(S * s, int i) { s->x = i*2; } // locally hide autogen ctors
+    S s4;  // error, no default constructor
+    S s5 = { 3 };  // okay, local constructor
+    S s6 = { 4, 5 };  // error, no field constructor
     S s7 = s5; // okay
+  }
 …
 In this example, the inner scope declares a constructor from @int@ to @S@, which hides the default constructor and field constructors until the end of the scope.
 When defining a constructor or destructor for a struct @S@, any members that are not explicitly constructed or destructed are implicitly constructed or destructed automatically.
+When defining a constructor or destructor for a structure @S@, any members that are not explicitly constructed or destructed are implicitly constructed or destructed automatically.
 If an explicit call is present, then that call is taken in preference to any implicitly generated call.
 A consequence of this rule is that it is possible, unlike \CC, to precisely control the order of construction and destruction of subobjects on a per-constructor basis, whereas in \CC subobject initialization and destruction is always performed based on the declaration order.
+A consequence of this rule is that it is possible, unlike \CC, to precisely control the order of construction and destruction of sub-objects on a per-constructor basis, whereas in \CC sub-object initialization and destruction is always performed based on the declaration order.
 \begin{cfacode}
 struct A {
 …
+}
 \end{cfacode}
 Finally, it is illegal for a subobject to be explicitly constructed for the first time after it is used for the first time.
+Finally, it is illegal for a sub-object to be explicitly constructed for the first time after it is used for the first time.
 If the translator cannot be reasonably sure that an object is constructed prior to its first use, but is constructed afterward, an error is emitted.
 More specifically, the translator searches the body of a constructor to ensure that every subobject is initialized.
+More specifically, the translator searches the body of a constructor to ensure that every sub-object is initialized.
 \begin{cfacode}
 void ?{}(A * a, double x) {
 …
+}
 \end{cfacode}
 However, if the translator sees a subobject used within the body of a constructor, but does not see a constructor call that uses the subobject as the target of a constructor, then the translator assumes the object is to be implicitly constructed (copy constructed in a copy constructor and default constructed in any other constructor).
+However, if the translator sees a sub-object used within the body of a constructor, but does not see a constructor call that uses the sub-object as the target of a constructor, then the translator assumes the object is to be implicitly constructed (copy constructed in a copy constructor and default constructed in any other constructor).
 \begin{cfacode}
 void ?{}(A * a) {
 …
 } // z, y, w implicitly destructed, in this order
 \end{cfacode}
 If at any point, the @this@ parameter is passed directly as the target of another constructor, then it is assumed that constructor handles the initialization of all of the object's members and no implicit constructor calls are added. % TODO: confirm that this is correct. It might be possible to get subtle errors if you initialize some members then call another constructor... -- in fact, this is basically always wrong. if anything, I should check that such a constructor does not initialize any members, otherwise it'll always initialize the member twice (once locally, once by the called constructor).
+If at any point, the @this@ parameter is passed directly as the target of another constructor, then it is assumed that constructor handles the initialization of all of the object's members and no implicit constructor calls are added.
 To override this rule, \ateq can be used to force the translator to trust the programmer's discretion.
 This form of \ateq is not yet implemented.
 …
 Despite great effort, some forms of C syntax do not work well with constructors in \CFA.
 In particular, constructor calls cannot contain designations (see \ref{sub:c_background}), since this is equivalent to allowing designations on the arguments to arbitrary function calls.
-In C, function prototypes are permitted to have arbitrary parameter names, including no names at all, which may have no connection to the actual names used at function definition.
-Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.
 \begin{cfacode}
 // all legal forward declarations in C
 …
 f(b:10, a:20, c:30);  // which parameter is which?
 \end{cfacode}
+In C, function prototypes are permitted to have arbitrary parameter names, including no names at all, which may have no connection to the actual names used at function definition.
+Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.
 As a result, it was decided that any attempt to resolve designated function calls with C's function prototype rules would be brittle, and thus it is not sensible to allow designations in constructor calls.
+% Many other languages do allow named arguments, such as Python and Scala, but they do not allow multiple arbitrarily named forward declarations of a function.
+In addition, constructor calls cannot have a nesting depth greater than the number of array components in the type of the initialized object, plus one.
+\begin{sloppypar}
+In addition, constructor calls do not support unnamed nesting.
+\begin{cfacode}
+struct B { int x; };
+struct C { int y; };
+struct A { B b; C c; };
+void ?{}(A *, B);
+void ?{}(A *, C);
+A a = {
+  { 10 },  // construct B? - invalid
+};
+\end{cfacode}
+In C, nesting initializers means that the programmer intends to initialize sub-objects with the nested initializers.
+The reason for this omission is to both simplify the mental model for using constructors, and to make initialization simpler for the expression resolver.
+If this were allowed, it would be necessary for the expression resolver to decide whether each argument to the constructor call could initialize to some argument in one of the available constructors, making the problem highly recursive and potentially much more expensive.
+That is, in the previous example the line marked as an error could mean construct using @?{}(A *, B)@ or with @?{}(A *, C)@, since the inner initializer @{ 10 }@ could be taken as an intermediate object of type @B@ or @C@.
+In practice, however, there could be many objects that can be constructed from a given @int@ (or, indeed, any arbitrary parameter list), and thus a complete solution to this problem would require fully exploring all possibilities.
+\end{sloppypar}
+More precisely, constructor calls cannot have a nesting depth greater than the number of array dimensions in the type of the initialized object, plus one.
 For example,
 \begin{cfacode}
 …
   { {14 }, { 15 } }   // a2[1]
 };
 A a3[4] = {
   { { 11 }, { 12 } },  // error
+A a3[4] = { // 1 dimension => max depth 2
+  { { 11 }, { 12 } },  // error, three levels deep
   { 80 }, { 90 }, { 100 }
+}
 \end{cfacode}
-% TODO: in CFA if the array dimension is empty, no object constructors are added -- need to fix this.
 The body of @A@ has been omitted, since only the constructor interfaces are important.
+In C, having a greater nesting depth means that the programmer intends to initialize subobjects with the nested initializer.
+The reason for this omission is to both simplify the mental model for using constructors, and to make initialization simpler for the expression resolver.
+If this were allowed, it would be necessary for the expression resolver to decide whether each argument to the constructor call could initialize to some argument in one of the available constructors, making the problem highly recursive and potentially much more expensive.
+That is, in the previous example the line marked as an error could mean construct using @?{}(A *, A, A)@, since the inner initializer @{ 11 }@ could be taken as an intermediate object of type @A@ constructed with @?{}(A *, int)@.
+In practice, however, there could be many objects that can be constructed from a given @int@ (or, indeed, any arbitrary parameter list), and thus a complete solution to this problem would require fully exploring all possibilities.
 It should be noted that unmanaged objects can still make use of designations and nested initializers in \CFA.
+It is simple to overcome this limitation for managed objects by making use of compound literals, so that the arguments to the constructor call are explicitly typed.
 \subsection{Implicit Destructors}
 \label{sub:implicit_dtor}
 Destructors are automatically called at the end of the block in which the object is declared.
 In addition to this, destructors are automatically called when statements manipulate control flow to leave a block in which the object is declared, e.g., with return, break, continue, and goto statements.
+In addition to this, destructors are automatically called when statements manipulate control flow to leave a block in which the object is declared, \eg, with return, break, continue, and goto statements.
 The example below demonstrates a simple routine with multiple return statements.
 \begin{cfacode}
 …
     if (i == 2) return; // destruct x, y
   } // destruct y
+}
+\end{cfacode}
+%% having this feels excessive, but it's here if necessary
+% This procedure generates the following code.
+% \begin{cfacode}
+% void f(int i){
+%   struct A x;
+%   ?{}(&x);
+%   {
+%     struct A y;
+%     ?{}(&y);
+%     {
+%       struct A z;
+%       ?{}(&z);
+%       {
+%         if ((i==0)!=0) {
+%           ^?{}(&z);
+%           ^?{}(&y);
+%           ^?{}(&x);
+%           return;
+%         }
+%       }
+%       if (((i==1)!=0) {
+%           ^?{}(&z);
+%           ^?{}(&y);
+%           ^?{}(&x);
+%           return ;
+%       }
+%       ^?{}(&z);
+%     }
+%     if ((i==2)!=0) {
+%       ^?{}(&y);
+%       ^?{}(&x);
+%       return;
+%     }
+%     ^?{}(&y);
+%   }
+%   ^?{}(&x);
+% }
+% \end{cfacode}
+} // destruct x
+\end{cfacode}
 The next example illustrates the use of simple continue and break statements and the manner that they interact with implicit destructors.
 …
 \end{cfacode}
 Since a destructor call is automatically inserted at the end of the block, nothing special needs to happen to destruct @x@ in the case where control reaches the end of the loop.
 In the case where @i@ is @2@, the continue statement runs the loop update expression and attemps to begin the next iteration of the loop.
 Since continue is a C statement, which does not understand destructors, a destructor call is added just before the continue statement to ensure that @x@ is destructed.
+In the case where @i@ is @2@, the continue statement runs the loop update expression and attempts to begin the next iteration of the loop.
+Since continue is a C statement, which does not understand destructors, it is transformed into a @goto@ statement that branches to the end of the loop, just before the block's destructors, to ensure that @x@ is destructed.
 When @i@ is @3@, the break statement moves control to just past the end of the loop.
 Like the previous case, a destructor call for @x@ is inserted just before the break statement.
 \CFA also supports labelled break and continue statements, which allow more precise manipulation of control flow.
 Labelled break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure.
+Unlike the previous case, the destructor for @x@ cannot be reused, so a destructor call for @x@ is inserted just before the break statement.
+\CFA also supports labeled break and continue statements, which allow more precise manipulation of control flow.
+Labeled break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure.
 \begin{cfacode}[emph={L1,L2}, emphstyle=\color{red}]
 L1: for (int i = 0; i < 10; i++) {
   A x;
   L2: for (int j = 0; j < 10; j++) {
+  for (int j = 0; j < 10; j++) {
     A y;
+    if (j == 0) {
+      continue;    // destruct y
+    } else if (j == 1) {
+      break;       // destruct y
+    } else if (i == 1) {
+    if (i == 1) {
       continue L1; // destruct y
     } else if (i == 2) {
 …
 \end{cfacode}
 The statement @continue L1@ begins the next iteration of the outer for-loop.
 Since the semantics of continue require the loop update expression to execute, control branches to the \emph{end} of the outer for loop, meaning that the block destructor for @x@ can be reused, and it is only necessary to generate the destructor for @y@.
 Break, on the other hand, requires jumping out of the loop, so the destructors for both @x@ and @y@ are generated and inserted before the @break L1@ statement.
+Since the semantics of continue require the loop update expression to execute, control branches to the end of the outer for loop, meaning that the block destructor for @x@ can be reused, and it is only necessary to generate the destructor for @y@.
+Break, on the other hand, requires jumping out of both loops, so the destructors for both @x@ and @y@ are generated and inserted before the @break L1@ statement.
 Finally, an example which demonstrates goto.
 …
+}
 \end{cfacode}
 Labelled break and continue are implemented in \CFA in terms of goto statements, so the more constrained forms are precisely goverened by these rules.
+All break and continue statements are implemented in \CFA in terms of goto statements, so the more constrained forms are precisely governed by these rules.
 The next example demonstrates the error case.
 …
 \subsection{Implicit Copy Construction}
+\label{s:implicit_copy_construction}
 When a function is called, the arguments supplied to the call are subject to implicit copy construction (and destruction of the generated temporary), and the return value is subject to destruction.
 When a value is returned from a function, the copy constructor is called to pass the value back to the call site.
 Exempt from these rules are intrinsic and builtin functions.
+Exempt from these rules are intrinsic and built-in functions.
 It should be noted that unmanaged objects are subject to copy constructor calls when passed as arguments to a function or when returned from a function, since they are not the \emph{target} of the copy constructor call.
+This is an important detail to bear in mind when using unmanaged objects, and could produce unexpected results when mixed with objects that are explicitly constructed.
+That is, since the parameter is not marked as an unmanaged object using \ateq, it is be copy constructed if it is returned by value or passed as an argument to another function, so to guarantee consistent behaviour, unmanaged objects must be copy constructed when passed as arguments.
+These semantics are important to bear in mind when using unmanaged objects, and could produce unexpected results when mixed with objects that are explicitly constructed.
 \begin{cfacode}
 struct A;
 …
 void ^?{}(A *);
 A f(A x) {
   return x;
+A identity(A x) { // pass by value => need local copy
+  return x;       // return by value => make call-site copy
+}
 A y, z @= {};
 identity(y);
 identity(z);
 \end{cfacode}
 Note that @z@ is copy constructed into a temporary variable to be passed as an argument, which is also destructed after the call.
 A special syntactic form, such as a variant of \ateq, could be implemented to specify at the call site that an argument should not be copy constructed, to regain some control for the C programmer.
+identity(y);  // copy construct y into x
+identity(z);  // copy construct z into x
+\end{cfacode}
+Note that unmanaged argument @z@ is logically copy constructed into managed parameter @x@; however, the translator must copy construct into a temporary variable to be passed as an argument, which is also destructed after the call.
+A compiler could by-pass the argument temporaries since it is in control of the calling conventions and knows exactly where the called-function's parameters live.
 This generates the following
 \begin{cfacode}
 struct A f(struct A x){
   struct A _retval_f;
   ?{}((&_retval_f), x);
+  struct A _retval_f;    // return value
+  ?{}((&_retval_f), x);  // copy construct return value
   return _retval_f;
+}
 struct A y;
+?{}(&y);
+struct A z = { 0 };
+struct A _tmp_cp1;     // argument 1
+struct A _tmp_cp_ret0; // return value
+_tmp_cp_ret0=f((?{}(&_tmp_cp1, y) , _tmp_cp1)), _tmp_cp_ret0;
+^?{}(&_tmp_cp_ret0);   // return value
+^?{}(&_tmp_cp1);       // argument 1
+struct A _tmp_cp2;     // argument 1
+struct A _tmp_cp_ret1; // return value
+_tmp_cp_ret1=f((?{}(&_tmp_cp2, z), _tmp_cp2)), _tmp_cp_ret1;
+^?{}(&_tmp_cp_ret1);   // return value
+^?{}(&_tmp_cp2);       // argument 1
+?{}(&y);                 // default construct
+struct A z = { 0 };      // C default
+struct A _tmp_cp1;       // argument 1
+struct A _tmp_cp_ret0;   // return value
+_tmp_cp_ret0=f(
+  (?{}(&_tmp_cp1, y) , _tmp_cp1)  // argument is a comma expression
+), _tmp_cp_ret0;         // return value for cascading
+^?{}(&_tmp_cp_ret0);     // destruct return value
+^?{}(&_tmp_cp1);         // destruct argument 1
+struct A _tmp_cp2;       // argument 1
+struct A _tmp_cp_ret1;   // return value
+_tmp_cp_ret1=f(
+  (?{}(&_tmp_cp2, z), _tmp_cp2)  // argument is a common expression
+), _tmp_cp_ret1;         // return value for cascading
+^?{}(&_tmp_cp_ret1);     // destruct return value
+^?{}(&_tmp_cp2);         // destruct argument 1
 ^?{}(&y);
 \end{cfacode}
+A known issue with this implementation is that the return value of a function is not guaranteed to have the same address for its entire lifetime.
+Specifically, since @_retval_f@ is allocated and constructed in @f@ then returned by value, the internal data is bitwise copied into the caller's stack frame.
+A special syntactic form, such as a variant of \ateq, can be implemented to specify at the call site that an argument should not be copy constructed, to regain some control for the C programmer.
+\begin{cfacode}
+identity(z@);  // do not copy construct argument
+               // - will copy construct/destruct return value
+A@ identity_nocopy(A @ x) {  // argument not copy constructed or destructed
+  return x;  // not copy constructed
+             // return type marked @ => not destructed
+}
+\end{cfacode}
+It should be noted that reference types will allow specifying that a value does not need to be copied, however reference types do not provide a means of preventing implicit copy construction from uses of the reference, so the problem is still present when passing or returning the reference by value.
+A known issue with this implementation is that the argument and return value temporaries are not guaranteed to have the same address for their entire lifetimes.
+In the previous example, since @_retval_f@ is allocated and constructed in @f@, then returned by value, the internal data is bitwise copied into the caller's stack frame.
 This approach works out most of the time, because typically destructors need to only access the fields of the object and recursively destroy.
 It is currently the case that constructors and destructors which use the @this@ pointer as a unique identifier to store data externally will not work correctly for return value objects.
 Thus is it not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.
+It is currently the case that constructors and destructors that use the @this@ pointer as a unique identifier to store data externally do not work correctly for return value objects.
+Thus, it is currently not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.
 \begin{cfacode}
 A * external_data[32];
 …
+  }
+}
+A makeA() {
+  A x;  // stores &x in external_data
+  return x;
+}
+makeA();  // return temporary has a different address than x
+// equivalent to:
+//   A _tmp;
+//   _tmp = makeA(), _tmp;
+//   ^?{}(&_tmp);
 \end{cfacode}
 In the above example, a global array of pointers is used to keep track of all of the allocated @A@ objects.
 Due to copying on return, the current object being destructed will not exist in the array if an @A@ object is ever returned by value from a function.
 This problem could be solved in the translator by mutating the function signatures so that the return value is moved into the parameter list.
+Due to copying on return, the current object being destructed does not exist in the array if an @A@ object is ever returned by value from a function, such as in @makeA@.
+This problem could be solved in the translator by changing the function signatures so that the return value is moved into the parameter list.
 For example, the translator could restructure the code like so
 \begin{cfacode}
 …
 \end{cfacode}
 This transformation provides @f@ with the address of the return variable so that it can be constructed into directly.
 It is worth pointing out that this kind of signature rewriting already occurs in polymorphic functions which return by value, as discussed in \cite{Bilson03}.
 A key difference in this case is that every function would need to be rewritten like this, since types can switch between managed and unmanaged at different scope levels, e.g.
+It is worth pointing out that this kind of signature rewriting already occurs in polymorphic functions that return by value, as discussed in \cite{Bilson03}.
+A key difference in this case is that every function would need to be rewritten like this, since types can switch between managed and unmanaged at different scope levels, \eg
 \begin{cfacode}
 struct A { int v; };
 A x; // unmanaged
+A x; // unmanaged, since only trivial constructors are available
+{
   void ?{}(A * a) { ... }
 …
 A z; // unmanaged
 \end{cfacode}
 Hence there is not enough information to determine at function declaration to determine whether a type is managed or not, and thus it is the case that all signatures have to be rewritten to account for possible copy constructor and destructor calls.
+Hence there is not enough information to determine at function declaration whether a type is managed or not, and thus it is the case that all signatures have to be rewritten to account for possible copy constructor and destructor calls.
 Even with this change, it would still be possible to declare backwards compatible function prototypes with an @extern "C"@ block, which allows for the definition of C-compatible functions within \CFA code, however this would require actual changes to the way code inside of an @extern "C"@ function is generated as compared with normal code generation.
 Furthermore, it isn't possible to overload C functions, so using @extern "C"@ to declare functions is of limited use.
 It would be possible to regain some control by adding an attribute to structs which specifies whether they can be managed or not (perhaps \emph{manageable} or \emph{unmanageable}), and to emit an error in the case that a constructor or destructor is declared for an unmanageable type.
 Ideally, structs should be manageable by default, since otherwise the default case becomes more verbose.
+Furthermore, it is not possible to overload C functions, so using @extern "C"@ to declare functions is of limited use.
+It would be possible to regain some control by adding an attribute to structures that specifies whether they can be managed or not (perhaps \emph{manageable} or \emph{unmanageable}), and to emit an error in the case that a constructor or destructor is declared for an unmanageable type.
+Ideally, structures should be manageable by default, since otherwise the default case becomes more verbose.
 This means that in general, function signatures would have to be rewritten, and in a select few cases the signatures would not be rewritten.
 \begin{cfacode}
 __attribute__((manageable)) struct A { ... };   // can declare constructors
 __attribute__((unmanageable)) struct B { ... }; // cannot declare constructors
 struct C { ... };                               // can declare constructors
+__attribute__((manageable)) struct A { ... };   // can declare ctors
+__attribute__((unmanageable)) struct B { ... }; // cannot declare ctors
+struct C { ... };                               // can declare ctors
 A f();  // rewritten void f(A *);
 …
 C h();  // rewritten void h(C *);
 \end{cfacode}
 An alternative is to instead make the attribute \emph{identifiable}, which states that objects of this type use the @this@ parameter as an identity.
 This strikes more closely to the visibile problem, in that only types marked as identifiable would need to have the return value moved into the parameter list, and every other type could remain the same.
+An alternative is to make the attribute \emph{identifiable}, which states that objects of this type use the @this@ parameter as an identity.
+This strikes more closely to the visible problem, in that only types marked as identifiable would need to have the return value moved into the parameter list, and every other type could remain the same.
 Furthermore, no restrictions would need to be placed on whether objects can be constructed.
 \begin{cfacode}
 __attribute__((identifiable)) struct A { ... };  // can declare constructors
 struct B { ... };                                // can declare constructors
+__attribute__((identifiable)) struct A { ... };  // can declare ctors
+struct B { ... };                                // can declare ctors
 A f();  // rewritten void f(A *);
 …
 \end{cfacode}
 Ultimately, this is the type of transformation that a real compiler would make when generating assembly code.
 Since a compiler has full control over its calling conventions, it can seamlessly allow passing the return parameter without outwardly changing the signature of a routine.
 As such, it has been decided that this issue is not currently a priority.
+Ultimately, both of these are patchwork solutions.
+Since a real compiler has full control over its calling conventions, it can seamlessly allow passing the return parameter without outwardly changing the signature of a routine.
+As such, it has been decided that this issue is not currently a priority and will be fixed when a full \CFA compiler is implemented.
 \section{Implementation}
 \subsection{Array Initialization}
 Arrays are a special case in the C type system.
+Arrays are a special case in the C type-system.
 C arrays do not carry around their size, making it impossible to write a standalone \CFA function that constructs or destructs an array while maintaining the standard interface for constructors and destructors.
 Instead, \CFA defines the initialization and destruction of an array recursively.
 …
 \subsection{Global Initialization}
+In standard C, global variables can only be initialized to compile-time constant expressions.
+This places strict limitations on the programmer's ability to control the default values of objects.
+In standard C, global variables can only be initialized to compile-time constant expressions, which places strict limitations on the programmer's ability to control the default values of objects.
 In \CFA, constructors and destructors are guaranteed to be run on global objects, allowing arbitrary code to be run before and after the execution of the main routine.
 By default, objects within a translation unit are constructed in declaration order, and destructed in the reverse order.
 The default order of construction of objects amongst translation units is unspecified.
+% TODO: not yet implemented, but g++ provides attribute init_priority, which allows specifying the order of global construction on a per object basis
+%   https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
+% suggestion: implement this in CFA by picking objects with a specified priority and pulling them into their own init functions (could even group them by priority level -> map<int, list<ObjectDecl*>>) and pull init_priority forward into constructor and destructor attributes with the same priority level
+It is, however, guaranteed that any global objects in the standard library are initialized prior to the initialization of any object in the user program.
+This feature is implemented in the \CFA translator by grouping every global constructor call into a function with the GCC attribute \emph{constructor}, which performs most of the heavy lifting. % CITE: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
+It is, however, guaranteed that any global objects in the standard library are initialized prior to the initialization of any object in a user program.
+This feature is implemented in the \CFA translator by grouping every global constructor call into a function with the GCC attribute \emph{constructor}, which performs most of the heavy lifting \cite[6.31.1]{GCCExtensions}.
 A similar function is generated with the \emph{destructor} attribute, which handles all global destructor calls.
 At the time of writing, initialization routines in the library are specified with priority \emph{101}, which is the highest priority level that GCC allows, whereas initialization routines in the user's code are implicitly given the default priority level, which ensures they have a lower priority than any code with a specified priority level.
 This mechanism allows arbitrarily complicated initialization to occur before any user code runs, making it possible for library designers to initialize their modules without requiring the user to call specific startup or teardown routines.
+This mechanism allows arbitrarily complicated initialization to occur before any user code runs, making it possible for library designers to initialize their modules without requiring the user to call specific startup or tear-down routines.
 For example, given the following global declarations.
 …
 \end{cfacode}
+%   https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
+% suggestion: implement this in CFA by picking objects with a specified priority and pulling them into their own init functions (could even group them by priority level -> map<int, list<ObjectDecl*>>) and pull init_priority forward into constructor and destructor attributes with the same priority level
+GCC provides an attribute @init_priority@ in \CC, which allows specifying the relative priority for initialization of global objects on a per-object basis.
+A similar attribute can be implemented in \CFA by pulling marked objects into global constructor/destructor-attribute functions with the specified priority.
+For example,
+\begin{cfacode}
+struct A { ... };
+void ?{}(A *, int);
+void ^?{}(A *);
+__attribute__((init_priority(200))) A x = { 123 };
+\end{cfacode}
+would generate
+\begin{cfacode}
+A x;
+__attribute__((constructor(200))) __init_x() {
+  ?{}(&x, 123);  // construct x with priority 200
+}
+__attribute__((destructor(200))) __destroy_x() {
+  ?{}(&x);       // destruct x with priority 200
+}
+\end{cfacode}
 \subsection{Static Local Variables}
 In standard C, it is possible to mark variables that are local to a function with the @static@ storage class.
 Unlike normal local variables, a @static@ local variable is defined to live for the entire duration of the program, so that each call to the function has access to the same variable with the same address and value as it had in the previous call to the function. % TODO: mention dynamic loading caveat??
 Much like global variables, in C @static@ variables must be initialized to a \emph{compile-time constant value} so that a compiler is able to create storage for the variable and initialize it before the program begins running.
+Unlike normal local variables, a @static@ local variable is defined to live for the entire duration of the program, so that each call to the function has access to the same variable with the same address and value as it had in the previous call to the function.
+Much like global variables, @static@ variables can only be initialized to a \emph{compile-time constant value} so that a compiler is able to create storage for the variable and initialize it at compile-time.
 Yet again, this rule is too restrictive for a language with constructors and destructors.
 Instead, \CFA modifies the definition of a @static@ local variable so that objects are guaranteed to be live from the time control flow reaches their declaration, until the end of the program, since the initializer expression is not necessarily a compile-time constant, but can depend on the current execution state of the function.
 Since standard C does not allow access to a @static@ local variable before the first time control flow reaches the declaration, this restriction does not preclude any valid C code.
+Since the initializer expression is not necessarily a compile-time constant and can depend on the current execution state of the function, \CFA modifies the definition of a @static@ local variable so that objects are guaranteed to be live from the time control flow reaches their declaration, until the end of the program.
+Since standard C does not allow access to a @static@ local variable before the first time control flow reaches the declaration, this change does not preclude any valid C code.
 Local objects with @static@ storage class are only implicitly constructed and destructed once for the duration of the program.
 The object is constructed when its declaration is reached for the first time.
 …
 Construction of @static@ local objects is implemented via an accompanying @static bool@ variable, which records whether the variable has already been constructed.
 A conditional branch checks the value of the companion @bool@, and if the variable has not yet been constructed then the object is constructed.
 The object's destructor is scheduled to be run when the program terminates using @atexit@, and the companion @bool@'s value is set so that subsequent invocations of the function will not reconstruct the object.
+The object's destructor is scheduled to be run when the program terminates using @atexit@ \footnote{When using the dynamic linker, it is possible to dynamically load and unload a shared library. Since glibc 2.2.3 \cite{atexit}, functions registered with @atexit@ within the shared library are called when unloading the shared library. As such, static local objects can be destructed using this mechanism even in shared libraries on Linux systems.}, and the companion @bool@'s value is set so that subsequent invocations of the function do not reconstruct the object.
 Since the parameter to @atexit@ is a parameter-less function, some additional tweaking is required.
 First, the @static@ variable must be hoisted up to global scope and uniquely renamed to prevent name clashes with other global objects.
+Second, a function is built which calls the destructor for the newly hoisted variable.
+If necessary, a local structure may need to be hoisted, as well.
+Second, a function is built that calls the destructor for the newly hoisted variable.
 Finally, the newly generated function is registered with @atexit@, instead of registering the destructor directly.
 Since @atexit@ calls functions in the reverse order in which they are registered, @static@ local variables are guaranteed to be destructed in the reverse order that they are constructed, which may differ between multiple executions of the same program.
 Extending the previous example
 \begin{cfacode}
 …
 \end{cfacode}
+\subsection{Constructor Expressions}
+In \CFA, it is possible to use a constructor as an expression.
+Like other operators, the function name @?{}@ matches its operator syntax.
+For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result.
+The significance of constructors as expressions rather than as statements is that the result of a constructor expression can be used as part of a larger expression.
+A key example is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@.
+\begin{cfacode}
+struct X { ... };
+void ?{}(X *, double);
+X * x = malloc(sizeof(X)){ 1.5 };
+\end{cfacode}
+In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@.
+If this extension is not present, constructing dynamically allocated objects is much more cumbersome, requiring separate initialization of the pointer and initialization of the pointed-to memory.
+\begin{cfacode}
+X * x = malloc(sizeof(X));
+x{ 1.5 };
+\end{cfacode}
+Not only is this verbose, but it is also more error prone, since this form allows maintenance code to easily sneak in between the initialization of @x@ and the initialization of the memory that @x@ points to.
+This feature is implemented via a transformation produceing the value of the first argument of the constructor, since constructors do not themslves have a return value.
+Since this transformation results in two instances of the subexpression, care is taken to allocate a temporary variable to hold the result of the subexpression in the case where the subexpression may contain side effects.
+The previous example generates the following code.
+\begin{cfacode}
+struct X *_tmp_ctor;
+struct X *x = ?{}((_tmp_ctor=((_tmp_cp_ret0=
+  malloc(sizeof(struct X))), _tmp_cp_ret0))), 1.5), _tmp_ctor);
+\end{cfacode}
+It should be noted that this technique is not exclusive to @malloc@, and allows a user to write a custom allocator that can be idiomatically used in much the same way as a constructed @malloc@ call.
+It is also possible to use operator syntax with destructors.
+Unlike constructors, operator syntax with destructors is a statement and thus does not produce a value, since the destructed object is invalidated by the use of a destructor.
+For example, \lstinline!^(&x){}! calls the destructor on the variable @x@.
+\subsection{Polymorphism}
+As mentioned in section \ref{sub:polymorphism}, \CFA currently has 3 type-classes that are used to designate polymorphic data types: @otype@, @dtype@, and @ftype@.
+In previous versions of \CFA, @otype@ was syntactic sugar for @dtype@ with known size/alignment information and an assignment function.
+That is,
+\begin{cfacode}
+forall(otype T)
+void f(T);
+\end{cfacode}
+was equivalent to
+\begin{cfacode}
+forall(dtype T | sized(T) | { T ?=?(T *, T); })
+void f(T);
+\end{cfacode}
+This allows easily specifying constraints that are common to all complete object-types very simply.
+Now that \CFA has constructors and destructors, more of a complete object's behaviour can be specified than was previously possible.
+As such, @otype@ has been augmented to include assertions for a default constructor, copy constructor, and destructor.
+That is, the previous example is now equivalent to
+\begin{cfacode}
+forall(dtype T | sized(T) |
+  { T ?=?(T *, T); void ?{}(T *); void ?{}(T *, T); void ^?{}(T *); })
+void f(T);
+\end{cfacode}
+These additions allow @f@'s body to create and destroy objects of type @T@, and pass objects of type @T@ as arguments to other functions, following the normal \CFA rules.
+A point of note here is that objects can be missing default constructors (and eventually other functions through deleted functions), so it is important for \CFA programmers to think carefully about the operations needed by their function, as to not over-constrain the acceptable parameter types and prevent potential reuse.

doc/rob_thesis/intro.tex

-                      r221c2de7
+                      r154fdc8
 \section{\CFA Background}
 \label{s:background}
 \CFA is a modern extension to the C programming language.
+\CFA \footnote{Pronounced ``C-for-all'', and written \CFA or Cforall.} is a modern non-object-oriented extension to the C programming language.
 As it is an extension of C, there is already a wealth of existing C code and principles that govern the design of the language.
 Among the goals set out in the original design of \CFA, four points stand out \cite{Bilson03}.
 …
 Therefore, these design principles must be kept in mind throughout the design and development of new language features.
 In order to appeal to existing C programmers, great care must be taken to ensure that new features naturally feel like C.
+The remainder of this section describes some of the important new features that currently exist in \CFA, to give the reader the necessary context in which the new features presented in this thesis must dovetail. % TODO: harmonize with?
+These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used.
+Unfortunately, \CC is actively diverging from C, so incremental additions require significant effort and training, coupled with multiple legacy design-choices that cannot be updated.
+The remainder of this section describes some of the important new features that currently exist in \CFA, to give the reader the necessary context in which the new features presented in this thesis must dovetail.
 \subsection{C Background}
 …
 A a1 = { 1, .y:7, 6 };
 A a2[4] = { [2]:a0, [0]:a1, { .z:3 } };
 // equvialent to
+// equivalent to
 // A a0 = { 0, 8, 0, 1 };
 // A a1 = { 1, 0, 7, 6 };
 …
 Designations allow specifying the field to initialize by name, rather than by position.
 Any field not explicitly initialized is initialized as if it had static storage duration \cite[p.~141]{C11}.
 A designator specifies the current object for initialization, and as such any undesignated subobjects pick up where the last initialization left off.
 For example, in the initialization of @a1@, the initializer of @y@ is @7@, and the unnamed initializer @6@ initializes the next subobject, @z@.
 Later initializers override earlier initializers, so a subobject for which there is more than one initializer is only initailized by its last initializer.
 This can be seen in the initialization of @a0@, where @x@ is designated twice, and thus initialized to @8@.
 Note that in \CFA, designations use a colon separator, rather than an equals sign as in C.
+A designator specifies the current object for initialization, and as such any undesignated sub-objects pick up where the last initialization left off.
+For example, in the initialization of @a1@, the initializer of @y@ is @7@, and the unnamed initializer @6@ initializes the next sub-object, @z@.
+Later initializers override earlier initializers, so a sub-object for which there is more than one initializer is only initialized by its last initializer.
+These semantics can be seen in the initialization of @a0@, where @x@ is designated twice, and thus initialized to @8@.
+Note that in \CFA, designations use a colon separator, rather than an equals sign as in C, because this syntax is one of the few places that conflicts with the new language features.
 C also provides \emph{compound literal} expressions, which provide a first-class mechanism for creating unnamed objects.
 …
 \end{cfacode}
 Compound literals create an unnamed object, and result in an lvalue, so it is legal to assign a value into a compound literal or to take its address \cite[p.~86]{C11}.
 Syntactically, compound literals look like a cast operator followed by a brace-enclosed initializer, but semantically are different from a C cast, which only applies basic conversions and is never an lvalue.
+Syntactically, compound literals look like a cast operator followed by a brace-enclosed initializer, but semantically are different from a C cast, which only applies basic conversions and coercions and is never an lvalue.
 \subsection{Overloading}
 …
 Overloading is the ability to specify multiple entities with the same name.
 The most common form of overloading is function overloading, wherein multiple functions can be defined with the same name, but with different signatures.
+Like in \CC, \CFA allows overloading based both on the number of parameters and on the types of parameters.
+C provides a small amount of built-in overloading, \eg + is overloaded for the basic types.
+Like in \CC, \CFA allows user-defined overloading based both on the number of parameters and on the types of parameters.
   \begin{cfacode}
   void f(void);  // (1)
 …
 There are times when a function should logically return multiple values.
+Since a function in standard C can only return a single value, a programmer must either take in additional return values by address, or the function's designer must create a wrapper structure t0 package multiple return-values.
+Since a function in standard C can only return a single value, a programmer must either take in additional return values by address, or the function's designer must create a wrapper structure to package multiple return-values.
+For example, the first approach:
 \begin{cfacode}
 int f(int * ret) {        // returns a value through parameter ret
 …
 int res1 = g(&res2);      // explicitly pass storage
 \end{cfacode}
+The former solution is awkward because it requires the caller to explicitly allocate memory for $n$ result variables, even if they are only temporary values used as a subexpression, or even not used at all.
+is awkward because it requires the caller to explicitly allocate memory for $n$ result variables, even if they are only temporary values used as a subexpression, or even not used at all.
+The second approach:
 \begin{cfacode}
 struct A {
 …
 ... res3.x ... res3.y ... // use result values
 \end{cfacode}
 The latter approach requires the caller to either learn the field names of the structure or learn the names of helper routines to access the individual return values.
 Both solutions are syntactically unnatural.
 In \CFA, it is possible to directly declare a function returning mutliple values.
 This provides important semantic information to the caller, since return values are only for output.
 \begin{cfacode}
 [int, int] f() {       // don't need to create a new type
+is awkward because the caller has to either learn the field names of the structure or learn the names of helper routines to access the individual return values.
+Both approaches are syntactically unnatural.
+In \CFA, it is possible to directly declare a function returning multiple values.
+This extension provides important semantic information to the caller, since return values are only for output.
+\begin{cfacode}
+[int, int] f() {       // no new type
   return [123, 37];
+}
 \end{cfacode}
+However, the ability to return multiple values requires a syntax for accepting the results from a function.
+However, the ability to return multiple values is useless without a syntax for accepting the results from the function.
 In standard C, return values are most commonly assigned directly into local variables, or are used as the arguments to another function call.
 \CFA allows both of these contexts to accept multiple return values.
 …
   g(f());             // selects (2)
   \end{cfacode}
 In this example, the only possible call to @f@ that can produce the two @int@s required by @g@ is the second option.
 A similar reasoning holds for assigning into multiple variables.
+In this example, the only possible call to @f@ that can produce the two @int@s required for assigning into the variables @x@ and @y@ is the second option.
+A similar reasoning holds calling the function @g@.
 In \CFA, overloading also applies to operator names, known as \emph{operator overloading}.
 …
   \begin{cfacode}
   struct A { int i; };
   int ?+?(A x, A y);
+  int ?+?(A x, A y);    // '?'s represent operands
   bool ?<?(A x, A y);
   \end{cfacode}
 Notably, the only difference in this example is syntax.
+Notably, the only difference is syntax.
 Most of the operators supported by \CC for operator overloading are also supported in \CFA.
 Of notable exception are the logical operators (e.g. @||@), the sequence operator (i.e. @,@), and the member-access operators (e.g. @.@ and \lstinline{->}).
+Of notable exception are the logical operators (\eg @||@), the sequence operator (\ie @,@), and the member-access operators (\eg @.@ and \lstinline{->}).
 Finally, \CFA also permits overloading variable identifiers.
 This feature is not available in \CC.
   \begin{cfacode} % TODO: pick something better than x? max, zero, one?
+  \begin{cfacode}
   struct Rational { int numer, denom; };
   int x = 3;               // (1)
 …
 In this example, there are three definitions of the variable @x@.
 Based on the context, \CFA attempts to choose the variable whose type best matches the expression context.
+When used judiciously, this feature allows names like @MAX@, @MIN@, and @PI@ to apply across many types.
 Finally, the values @0@ and @1@ have special status in standard C.
 …
+}
 \end{cfacode}
 Every if statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
+Every if- and iteration-statement in C compares the condition with @0@, and every increment and decrement operator is semantically equivalent to adding or subtracting the value @1@ and storing the result.
 Due to these rewrite rules, the values @0@ and @1@ have the types \zero and \one in \CFA, which allow for overloading various operations that connect to @0@ and @1@ \footnote{In the original design of \CFA, @0@ and @1@ were overloadable names \cite[p.~7]{cforall}.}.
 The types \zero and \one have special built in implicit conversions to the various integral types, and a conversion to pointer types for @0@, which allows standard C code involving @0@ and @1@ to work as normal.
+The types \zero and \one have special built-in implicit conversions to the various integral types, and a conversion to pointer types for @0@, which allows standard C code involving @0@ and @1@ to work as normal.
   \begin{cfacode}
   // lvalue is similar to returning a reference in C++
 …
   template<typename T>
   T sum(T *arr, int n) {
     T t;
+    T t;  // default construct => 0
     for (; n > 0; n--) t += arr[n-1];
     return t;
 …
   \end{cfacode}
 The first thing to note here is that immediately following the declaration of @otype T@ is a list of \emph{type assertions} that specify restrictions on acceptable choices of @T@.
 In particular, the assertions above specify that there must be a an assignment from \zero to @T@ and an addition assignment operator from @T@ to @T@.
+In particular, the assertions above specify that there must be an assignment from \zero to @T@ and an addition assignment operator from @T@ to @T@.
 The existence of an assignment operator from @T@ to @T@ and the ability to create an object of type @T@ are assumed implicitly by declaring @T@ with the @otype@ type-class.
 In addition to @otype@, there are currently two other type-classes.
 …
 A major difference between the approaches of \CC and \CFA to polymorphism is that the set of assumed properties for a type is \emph{explicit} in \CFA.
 One of the major limiting factors of \CC's approach is that templates cannot be separately compiled.
+In contrast, the explicit nature of assertions allows \CFA's polymorphic functions to be separately compiled.
+In contrast, the explicit nature of assertions allows \CFA's polymorphic functions to be separately compiled, as the function prototype states all necessary requirements separate from the implementation.
+For example, the prototype for the previous sum function is
+  \begin{cfacode}
+  forall(otype T | **R**{ T ?=?(T *, zero_t); T ?+=?(T *, T); }**R**)
+  T sum(T *arr, int n);
+  \end{cfacode}
+With this prototype, a caller in another translation unit knows all of the constraints on @T@, and thus knows all of the operations that need to be made available to @sum@.
 In \CFA, a set of assertions can be factored into a \emph{trait}.
 …
 This capability allows specifying the same set of assertions in multiple locations, without the repetition and likelihood of mistakes that come with manually writing them out for each function declaration.
+An interesting application of return-type resolution and polymorphism is a type-safe version of @malloc@.
+\begin{cfacode}
+forall(dtype T | sized(T))
+T * malloc() {
+  return (T*)malloc(sizeof(T)); // call C malloc
+}
+int * x = malloc();     // malloc(sizeof(int))
+double * y = malloc();  // malloc(sizeof(double))
+struct S { ... };
+S * s = malloc();       // malloc(sizeof(S))
+\end{cfacode}
+The built-in trait @sized@ ensures that size and alignment information for @T@ is available in the body of @malloc@ through @sizeof@ and @_Alignof@ expressions respectively.
+In calls to @malloc@, the type @T@ is bound based on call-site information, allowing \CFA code to allocate memory without the potential for errors introduced by manually specifying the size of the allocated block.
 \section{Invariants}
+% TODO: discuss software engineering benefits of ctor/dtors: {pre/post} conditions, invariants
+% an important invariant is the state of the environment (memory, resources)
+% some objects pass their contract to the object user
+An \emph{invariant} is a logical assertion that true for some duration of a program's execution.
+An \emph{invariant} is a logical assertion that is true for some duration of a program's execution.
 Invariants help a programmer to reason about code correctness and prove properties of programs.
+\begin{sloppypar}
 In object-oriented programming languages, type invariants are typically established in a constructor and maintained throughout the object's lifetime.
 This is typically achieved through a combination of access control modifiers and a restricted interface.
+These assertions are typically achieved through a combination of access-control modifiers and a restricted interface.
 Typically, data which requires the maintenance of an invariant is hidden from external sources using the \emph{private} modifier, which restricts reads and writes to a select set of trusted routines, including member functions.
 It is these trusted routines that perform all modifications to internal data in a way that is consistent with the invariant, by ensuring that the invariant holds true at the end of the routine call.
+\end{sloppypar}
 In C, the @assert@ macro is often used to ensure invariants are true.
 Using @assert@, the programmer can check a condition and abort execution if the condition is not true.
 This is a powerful tool that forces the programmer to deal with logical inconsistencies as they occur.
+This powerful tool forces the programmer to deal with logical inconsistencies as they occur.
 For production, assertions can be removed by simply defining the preprocessor macro @NDEBUG@, making it simple to ensure that assertions are 0-cost for a performance intensive application.
 \begin{cfacode}
 …
 \end{dcode}
 The D compiler is able to assume that assertions and invariants hold true and perform optimizations based on those assumptions.
+An important invariant is the state of the execution environment, including the heap, the open file table, the state of global variables, etc.
+Since resources are finite, it is important to ensure that objects clean up properly when they are finished, restoring the execution environment to a stable state so that new objects can reuse resources.
+Note, these invariants are internal to the type's correct behaviour.
+Types also have external invariants with the state of the execution environment, including the heap, the open-file table, the state of global variables, etc.
+Since resources are finite and shared (concurrency), it is important to ensure that objects clean up properly when they are finished, restoring the execution environment to a stable state so that new objects can reuse resources.
 \section{Resource Management}
 …
 The program stack grows and shrinks automatically with each function call, as needed for local variables.
 However, whenever a program needs a variable to outlive the block it is created in, the storage must be allocated dynamically with @malloc@ and later released with @free@.
 This pattern is extended to more complex objects, such as files and sockets, which also outlive the block where they are created, but at their core is resource management.
 Once allocated storage escapes a block, the responsibility for deallocating the storage is not specified in a function's type, that is, that the return value is owned by the caller.
+This pattern is extended to more complex objects, such as files and sockets, which can also outlive the block where they are created, and thus require their own resource management.
+Once allocated storage escapes\footnote{In garbage collected languages, such as Java, escape analysis \cite{Choi:1999:EAJ:320385.320386} is used to determine when dynamically allocated objects are strictly contained within a function, which allows the optimizer to allocate them on the stack.} a block, the responsibility for deallocating the storage is not specified in a function's type, that is, that the return value is owned by the caller.
 This implicit convention is provided only through documentation about the expectations of functions.
 In other languages, a hybrid situation exists where resources escape the allocation block, but ownership is precisely controlled by the language.
 This pattern requires a strict interface and protocol for a data structure, where the protocol consists of a pre-initialization and a post-termination call, and all intervening access is done via interface routines.
 This kind of encapsulation is popular in object-oriented programming languages, and like the stack, it contains a significant portion of resource management cases.
+This pattern requires a strict interface and protocol for a data structure, consisting of a pre-initialization and a post-termination call, and all intervening access is done via interface routines.
+This kind of encapsulation is popular in object-oriented programming languages, and like the stack, it takes care of a significant portion of resource-management cases.
 For example, \CC directly supports this pattern through class types and an idiom known as RAII \footnote{Resource Acquisition is Initialization} by means of constructors and destructors.
 …
 On the other hand, destructors provide a simple mechanism for tearing down an object and resetting the environment in which the object lived.
 RAII ensures that if all resources are acquired in a constructor and released in a destructor, there are no resource leaks, even in exceptional circumstances.
 A type with at least one non-trivial constructor or destructor will henceforth be referred to as a \emph{managed type}.
 In the context of \CFA, a non-trivial constructor is either a user defined constructor or an auto generated constructor that calls a non-trivial constructor.
 For the remaining resource ownership cases, programmer must follow a brittle, explicit protocol for freeing resources or an implicit porotocol implemented via the programming language.
+A type with at least one non-trivial constructor or destructor is henceforth referred to as a \emph{managed type}.
+In the context of \CFA, a non-trivial constructor is either a user defined constructor or an auto-generated constructor that calls a non-trivial constructor.
+For the remaining resource ownership cases, a programmer must follow a brittle, explicit protocol for freeing resources or an implicit protocol enforced by the programming language.
 In garbage collected languages, such as Java, resources are largely managed by the garbage collector.
 Still, garbage collectors are typically focus only on memory management.
+Still, garbage collectors typically focus only on memory management.
 There are many kinds of resources that the garbage collector does not understand, such as sockets, open files, and database connections.
 In particular, Java supports \emph{finalizers}, which are similar to destructors.
+Sadly, finalizers come with far fewer guarantees, to the point where a completely conforming JVM may never call a single finalizer. % TODO: citation JVM spec; http://stackoverflow.com/a/2506514/2386739
 Due to operating system resource limits, this is unacceptable for many long running tasks. % TODO: citation?
 Instead, the paradigm in Java requires programmers manually keep track of all resource \emph{except} memory, leading many novices and experts alike to forget to close files, etc.
 Complicating the picture, uncaught exceptions can cause control flow to change dramatically, leaking a resource which appears on first glance to be closed.
+Unfortunately, finalizers are only guaranteed to be called before an object is reclaimed by the garbage collector \cite[p.~373]{Java8}, which may not happen if memory use is not contentious.
+Due to operating-system resource-limits, this is unacceptable for many long running programs.
+Instead, the paradigm in Java requires programmers to manually keep track of all resources \emph{except} memory, leading many novices and experts alike to forget to close files, etc.
+Complicating the picture, uncaught exceptions can cause control flow to change dramatically, leaking a resource that appears on first glance to be released.
 \begin{javacode}
 void write(String filename, String msg) throws Exception {
 …
+}
 \end{javacode}
+Any line in this program can throw an exception.
+This leads to a profusion of finally blocks around many function bodies, since it isn't always clear when an exception may be thrown.
+Any line in this program can throw an exception, which leads to a profusion of finally blocks around many function bodies, since it is not always clear when an exception may be thrown.
 \begin{javacode}
 public void write(String filename, String msg) throws Exception {
 …
 \end{javacode}
 In Java 7, a new \emph{try-with-resources} construct was added to alleviate most of the pain of working with resources, but ultimately it still places the burden squarely on the user rather than on the library designer.
 Furthermore, for complete safety this pattern requires nested objects to be declared separately, otherwise resources which can throw an exception on close can leak nested resources. % TODO: cite oracle article http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html?
+Furthermore, for complete safety this pattern requires nested objects to be declared separately, otherwise resources that can throw an exception on close can leak nested resources \cite{TryWithResources}.
 \begin{javacode}
 public void write(String filename, String msg) throws Exception {
   try (
+  try (  // try-with-resources
     FileOutputStream out = new FileOutputStream(filename);
     FileOutputStream log = new FileOutputStream("log.txt");
 …
+}
 \end{javacode}
+On the other hand, the Java compiler generates more code if more resources are declared, meaning that users must be more familiar with each type and library designers must provide better documentation.
+Variables declared as part of a try-with-resources statement must conform to the @AutoClosable@ interface, and the compiler implicitly calls @close@ on each of the variables at the end of the block.
+Depending on when the exception is raised, both @out@ and @log@ are null, @log@ is null, or both are non-null, therefore, the cleanup for these variables at the end is automatically guarded and conditionally executed to prevent null-pointer exceptions.
+While Rust \cite{Rust} does not enforce the use of a garbage collector, it does provide a manual memory management environment, with a strict ownership model that automatically frees allocated memory and prevents common memory management errors.
+In particular, a variable has ownership over its associated value, which is freed automatically when the owner goes out of scope.
+Furthermore, values are \emph{moved} by default on assignment, rather than copied, which invalidates the previous variable binding.
+\begin{rustcode}
+struct S {
+  x: i32
+}
+let s = S { x: 123 };
+let z = s;           // move, invalidate s
+println!("{}", s.x); // error, s has been moved
+\end{rustcode}
+Types can be made copyable by implementing the @Copy@ trait.
+Rust allows multiple unowned views into an object through references, also known as borrows, provided that a reference does not outlive its referent.
+A mutable reference is allowed only if it is the only reference to its referent, preventing data race errors and iterator invalidation errors.
+\begin{rustcode}
+let mut x = 10;
+{
+  let y = &x;
+  let z = &x;
+  println!("{} {}", y, z); // prints 10 10
+}
+{
+  let y = &mut x;
+  // let z1 = &x;     // not allowed, have mutable reference
+  // let z2 = &mut x; // not allowed, have mutable reference
+  *y = 5;
+  println!("{}", y); // prints 5
+}
+println!("{}", x); // prints 5
+\end{rustcode}
+Since references are not owned, they do not release resources when they go out of scope.
+There is no runtime cost imposed on these restrictions, since they are enforced at compile-time.
+Rust provides RAII through the @Drop@ trait, allowing arbitrary code to execute when the object goes out of scope, providing automatic clean up of auxiliary resources, much like a \CC program.
+\begin{rustcode}
+struct S {
+  name: &'static str
+}
+impl Drop for S {  // RAII for S
+  fn drop(&mut self) {  // destructor
+    println!("dropped {}", self.name);
+  }
+}
+{
+  let x = S { name: "x" };
+  let y = S { name: "y" };
+} // prints "dropped y" "dropped x"
+\end{rustcode}
 % D has constructors and destructors that are worth a mention (under classes) https://dlang.org/spec/spec.html
 …
 The programming language, D, also manages resources with constructors and destructors \cite{D}.
 In D, @struct@s are stack allocated and managed via scoping like in \CC, whereas @class@es are managed automatically by the garbage collector.
 Like Java, using the garbage collector means that destructors may never be called, requiring the use of finally statements to ensure dynamically allocated resources that are not managed by the garbage collector, such as open files, are cleaned up.
+Like Java, using the garbage collector means that destructors are called indeterminately, requiring the use of finally statements to ensure dynamically allocated resources that are not managed by the garbage collector, such as open files, are cleaned up.
 Since D supports RAII, it is possible to use the same techniques as in \CC to ensure that resources are released in a timely manner.
+Finally, D provides a scope guard statement, which allows an arbitrary statement to be executed at normal scope exit with \emph{success}, at exceptional scope exit with \emph{failure}, or at normal and exceptional scope exit with \emph{exit}. % cite? https://dlang.org/spec/statement.html#ScopeGuardStatement
+It has been shown that the \emph{exit} form of the scope guard statement can be implemented in a library in \CC. % cite: http://www.drdobbs.com/184403758
+% TODO: discussion of lexical scope vs. dynamic
+% see Peter's suggestions
+% RAII works in both cases. Guaranteed to work in stack case, works in heap case if root is deleted (but it's dangerous to rely on this, because of exceptions)
+Finally, D provides a scope guard statement, which allows an arbitrary statement to be executed at normal scope exit with \emph{success}, at exceptional scope exit with \emph{failure}, or at normal and exceptional scope exit with \emph{exit}. % https://dlang.org/spec/statement.html#ScopeGuardStatement
+It has been shown that the \emph{exit} form of the scope guard statement can be implemented in a library in \CC \cite{ExceptSafe}.
+To provide managed types in \CFA, new kinds of constructors and destructors are added to \CFA and discussed in Chapter 2.
 \section{Tuples}
 \label{s:Tuples}
 In mathematics, tuples are finite-length sequences which, unlike sets, allow duplicate elements.
 In programming languages, tuples are a construct that provide fixed-sized heterogeneous lists of elements.
+In mathematics, tuples are finite-length sequences which, unlike sets, are ordered and allow duplicate elements.
+In programming languages, tuples provide fixed-sized heterogeneous lists of elements.
 Many programming languages have tuple constructs, such as SETL, \KWC, ML, and Scala.
 …
 Adding tuples to \CFA has previously been explored by Esteves \cite{Esteves04}.
 The design of tuples in \KWC took much of its inspiration from SETL.
+The design of tuples in \KWC took much of its inspiration from SETL \cite{SETL}.
 SETL is a high-level mathematical programming language, with tuples being one of the primary data types.
 Tuples in SETL allow a number of operations, including subscripting, dynamic expansion, and multiple assignment.
 …
 \begin{cppcode}
 tuple<int, int, int> triple(10, 20, 30);
 get<1>(triple); // access component 1 => 30
+get<1>(triple); // access component 1 => 20
 tuple<int, double> f();
 …
 Tuples are simple data structures with few specific operations.
 In particular, it is possible to access a component of a tuple using @std::get<N>@.
 Another interesting feature is @std::tie@, which creates a tuple of references, which allows assigning the results of a tuple-returning function into separate local variables, without requiring a temporary variable.
+Another interesting feature is @std::tie@, which creates a tuple of references, allowing assignment of the results of a tuple-returning function into separate local variables, without requiring a temporary variable.
 Tuples also support lexicographic comparisons, making it simple to write aggregate comparators using @std::tie@.
 There is a proposal for \CCseventeen called \emph{structured bindings}, that introduces new syntax to eliminate the need to pre-declare variables and use @std::tie@ for binding the results from a function call. % TODO: cite http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0144r0.pdf
+There is a proposal for \CCseventeen called \emph{structured bindings} \cite{StructuredBindings}, that introduces new syntax to eliminate the need to pre-declare variables and use @std::tie@ for binding the results from a function call.
 \begin{cppcode}
 tuple<int, double> f();
 …
 tuple<int, int, int> triple(10, 20, 30);
 auto & [t1, t2, t3] = triple;
 t2 = 0; // changes triple
+t2 = 0; // changes middle element of triple
 struct S { int x; double y; };
 …
 auto [x, y] = s; // unpack s
 \end{cppcode}
 Structured bindings allow unpacking any struct with all public non-static data members into fresh local variables.
+Structured bindings allow unpacking any structure with all public non-static data members into fresh local variables.
 The use of @&@ allows declaring new variables as references, which is something that cannot be done with @std::tie@, since \CC references do not support rebinding.
 This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must documented with some other mechanism.
+This extension requires the use of @auto@ to infer the types of the new variables, so complicated expressions with a non-obvious type must be documented with some other mechanism.
 Furthermore, structured bindings are not a full replacement for @std::tie@, as it always declares new variables.
 Like \CC, D provides tuples through a library variadic template struct.
+Like \CC, D provides tuples through a library variadic-template structure.
 In D, it is possible to name the fields of a tuple type, which creates a distinct type.
+\begin{dcode} % TODO: cite http://dlang.org/phobos/std_typecons.html
+% http://dlang.org/phobos/std_typecons.html
+\begin{dcode}
 Tuple!(float, "x", float, "y") point2D;
 Tuple!(float, float) float2;  // different types
+Tuple!(float, float) float2;  // different type from point2D
 point2D[0]; // access first element
 …
 The @expand@ method produces the components of the tuple as a list of separate values, making it possible to call a function that takes $N$ arguments using a tuple with $N$ components.
 Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML.
+Tuples are a fundamental abstraction in most functional programming languages, such as Standard ML \cite{sml}.
 A function in SML always accepts exactly one argument.
 There are two ways to mimic multiple argument functions: the first through currying and the second by accepting tuple arguments.
 …
 \end{smlcode}
 Here, the function @binco@ appears to take 2 arguments, but it actually takes a single argument which is implicitly decomposed via pattern matching.
 Tuples are a foundational tool in SML, allowing the creation of arbitrarily complex structured data types.
 Scala, like \CC, provides tuple types through the standard library.
+Tuples are a foundational tool in SML, allowing the creation of arbitrarily-complex structured data-types.
+Scala, like \CC, provides tuple types through the standard library \cite{Scala}.
 Scala provides tuples of size 1 through 22 inclusive through generic data structures.
 Tuples support named access and subscript access, among a few other operations.
 \begin{scalacode}
 val a = new Tuple3[Int, String, Double](0, "Text", 2.1)  // explicit creation
 val b = (6, 'a', 1.1f)       // syntactic sugar for Tuple3[Int, Char, Float]
+val a = new Tuple3(0, "Text", 2.1) // explicit creation
+val b = (6, 'a', 1.1f)       // syntactic sugar: Tuple3[Int, Char, Float]
 val (i, _, d) = triple       // extractor syntax, ignore middle element
 …
 \end{scalacode}
 In Scala, tuples are primarily used as simple data structures for carrying around multiple values or for returning multiple values from a function.
 The 22-element restriction is an odd and arbitrary choice, but in practice it doesn't cause problems since large tuples are uncommon.
+The 22-element restriction is an odd and arbitrary choice, but in practice it does not cause problems since large tuples are uncommon.
 Subscript access is provided through the @productElement@ method, which returns a value of the top-type @Any@, since it is impossible to receive a more precise type from a general subscripting method due to type erasure.
 The disparity between named access beginning at @_1@ and subscript access starting at @0@ is likewise an oddity, but subscript access is typically avoided since it discards type information.
 …
 \Csharp has similarly strange limitations, allowing tuples of size up to 7 components. % TODO: cite https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx
+\Csharp also has tuples, but has similarly strange limitations, allowing tuples of size up to 7 components. % https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx
 The officially supported workaround for this shortcoming is to nest tuples in the 8th component.
 \Csharp allows accessing a component of a tuple by using the field @Item$N$@ for components 1 through 7, and @Rest@ for the nested tuple.
+% TODO: cite 5.3 https://docs.python.org/3/tutorial/datastructures.html
+In Python, tuples are immutable sequences that provide packing and unpacking operations.
+In Python \cite{Python}, tuples are immutable sequences that provide packing and unpacking operations.
 While the tuple itself is immutable, and thus does not allow the assignment of components, there is nothing preventing a component from being internally mutable.
 The components of a tuple can be accessed by unpacking into multiple variables, indexing, or via field name, like D.
 Tuples support multiple assignment through a combination of packing and unpacking, in addition to the common sequence operations.
+% TODO: cite https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-ID448
+Swift, like D, provides named tuples, with components accessed by name, index, or via extractors.
+Swift \cite{Swift}, like D, provides named tuples, with components accessed by name, index, or via extractors.
 Tuples are primarily used for returning multiple values from a function.
 In Swift, @Void@ is an alias for the empty tuple, and there are no single element tuples.
+Tuples comparable to those described above are added to \CFA and discussed in Chapter 3.
 \section{Variadic Functions}
 …
 printf("%d %g %c %s", 10, 3.5, 'X', "a string");
 \end{cfacode}
 Through the use of a format string, @printf@ allows C programmers to print any of the standard C data types.
+Through the use of a format string, C programmers can communicate argument type information to @printf@, allowing C programmers to print any of the standard C data types.
 Still, @printf@ is extremely limited, since the format codes are specified by the C standard, meaning users cannot define their own format codes to extend @printf@ for new data types or new formatting rules.
+\begin{sloppypar}
 C provides manipulation of variadic arguments through the @va_list@ data type, which abstracts details of the manipulation of variadic arguments.
 Since the variadic arguments are untyped, it is up to the function to interpret any data that is passed in.
 Additionally, the interface to manipulate @va_list@ objects is essentially limited to advancing to the next argument, without any built-in facility to determine when the last argument is read.
 This requires the use of an \emph{argument descriptor} to pass information to the function about the structure of the argument list, including the number of arguments and their types.
+This limitation requires the use of an \emph{argument descriptor} to pass information to the function about the structure of the argument list, including the number of arguments and their types.
 The format string in @printf@ is one such example of an argument descriptor.
 \begin{cfacode}
 …
 Furthermore, if the user makes a mistake, compile-time checking is typically restricted to standard format codes and their corresponding types.
 In general, this means that C's variadic functions are not type-safe, making them difficult to use properly.
+\end{sloppypar}
 % When arguments are passed to a variadic function, they undergo \emph{default argument promotions}.
 …
 A parameter pack matches 0 or more elements, which can be types or expressions depending on the context.
 Like other templates, variadic template functions rely on an implicit set of constraints on a type, in this example a @print@ routine.
 That is, it is possible to use the @f@ routine any any type provided there is a corresponding @print@ routine, making variadic templates fully open to extension, unlike variadic functions in C.
+That is, it is possible to use the @f@ routine on any type provided there is a corresponding @print@ routine, making variadic templates fully open to extension, unlike variadic functions in C.
 Recent \CC standards (\CCfourteen, \CCseventeen) expand on the basic premise by allowing variadic template variables and providing convenient expansion syntax to remove the need for recursion in some cases, amongst other things.
 …
 Unfortunately, Java's use of nominal inheritance means that types must explicitly inherit from classes or interfaces in order to be considered a subclass.
 The combination of these two issues greatly restricts the usefulness of variadic functions in Java.
+Type-safe variadic functions are added to \CFA and discussed in Chapter 4.

doc/rob_thesis/thesis-frontpgs.tex

-                      r221c2de7
+                      r154fdc8
         \Large
         Rob Schluntz \\
+        Robert Schluntz \\
         \vspace*{3.0cm}
 …
         \vspace*{1.0cm}
         \copyright\ Rob Schluntz 2017 \\
+        \copyright\ Robert Schluntz 2017 \\
         \end{center}
 \end{titlepage}
 …
 \begin{center}\textbf{Abstract}\end{center}
+% \CFA is a modern extension to the C programming language.
+% Some of the features of \CFA include parametric polymorphism, overloading, and .
+TODO
+\CFA is a modern, non-object-oriented extension of the C programming language.
+This thesis addresses several critical deficiencies of C, notably: resource management, a limited function-return mechanism, and unsafe variadic functions.
+To solve these problems, two fundamental language features are introduced: tuples and constructors/destructors.
+While these features exist in prior programming languages, the contribution of this work is engineering these features into a highly complex type system.
+C is an established language with a dedicated user-base.
+An important goal is to add new features in a way that naturally feels like C, to appeal to this core user-base, and due to huge amounts of legacy code, maintaining backwards compatibility is crucial.
 \cleardoublepage
 %\newpage
 % A C K N O W L E D G E M E N T S
 % -------------------------------
+% % A C K N O W L E D G E M E N T S
+% % -------------------------------
 \begin{center}\textbf{Acknowledgements}\end{center}
+% \begin{center}\textbf{Acknowledgements}\end{center}
 % I would like to thank all the little people who made this possible.
 TODO
 \cleardoublepage
 %\newpage
+% % I would like to thank all the little people who made this possible.
+% TODO
+% \cleardoublepage
+% %\newpage
 % D E D I C A T I O N
 % -------------------
+% % D E D I C A T I O N
+% % -------------------
 \begin{center}\textbf{Dedication}\end{center}
+% \begin{center}\textbf{Dedication}\end{center}
 % This is dedicated to the one I love.
 TODO
 \cleardoublepage
 %\newpage
+% % This is dedicated to the one I love.
+% TODO
+% \cleardoublepage
+% %\newpage
 % T A B L E   O F   C O N T E N T S
 …
 %\newpage
 % L I S T   O F   F I G U R E S
 % -----------------------------
 \addcontentsline{toc}{chapter}{List of Figures}
 \listoffigures
 \cleardoublepage
 \phantomsection         % allows hyperref to link to the correct page
 %\newpage
+% % L I S T   O F   F I G U R E S
+% % -----------------------------
+% \addcontentsline{toc}{chapter}{List of Figures}
+% \listoffigures
+% \cleardoublepage
+% \phantomsection               % allows hyperref to link to the correct page
+% %\newpage
 % L I S T   O F   S Y M B O L S

doc/rob_thesis/thesis.tex

-                      r221c2de7
+                      r154fdc8
 \documentclass[letterpaper,12pt,titlepage,oneside,final]{book}
+% For PDF, suitable for double-sided printing, change the PrintVersion variable below
+% to "true" and use this \documentclass line instead of the one above:
+% \documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
 \usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
 \usepackage{textcomp}
 % \usepackage[utf8]{inputenc}
 \usepackage[latin1]{inputenc}
+% \usepackage[latin1]{inputenc}
 \usepackage{fullpage,times,comment}
 % \usepackage{epic,eepic}
 …
 \interfootnotelinepenalty=10000
-% For PDF, suitable for double-sided printing, change the PrintVersion variable below
-% to "true" and use this \documentclass line instead of the one above:
-%\documentclass[letterpaper,12pt,titlepage,openright,twoside,final]{book}
 % Some LaTeX commands I define for my own nomenclature.
 % If you have to, it's better to change nomenclature once here than in a
 …
     pdffitwindow=false,     % window fit to page when opened
     pdfstartview={FitH},    % fits the width of the page to the window
     pdftitle={uWaterloo\ LaTeX\ Thesis\ Template},    % title: CHANGE THIS TEXT!
+    pdftitle={Resource Management and Tuples in \CFA},    % title: CHANGE THIS TEXT!
     pdfauthor={Rob Schluntz},    % author: CHANGE THIS TEXT! and uncomment this line
 %    pdfsubject={Subject},  % subject: CHANGE THIS TEXT! and uncomment this line
 …
 \input{tuples}
+\input{variadic}
 \input{conclusions}
 …
 \addcontentsline{toc}{chapter}{\textbf{References}}
 \bibliography{cfa}
+\bibliography{cfa,thesis}
 % Tip 5: You can create multiple .bib files to organize your references.
 % Just list them all in the \bibliogaphy command, separated by commas (no spaces).

doc/rob_thesis/tuples.tex

-                      r221c2de7
+                      r154fdc8
 \chapter{Tuples}
 %======================================================================
-\section{Introduction}
-% TODO: named return values are not currently implemented in CFA - tie in with named tuples? (future work)
-% TODO: no passing input parameters by assignment, instead will have reference types => this is not a very C-like model and greatly complicates syntax for likely little gain (and would cause confusion with already supported return-by-rerefence)
-% TODO: tuples are allowed in expressions, exact meaning is defined by operator overloading (e.g. can add tuples). An important caveat to note is that it is currently impossible to allow adding two triples but prevent adding a pair with a quadruple (single flattening/structuring conversions are implicit, only total number of components matters). May be able to solve this with more nuanced conversion rules (future work)
-% TODO: benefits (conclusion) by Till: reduced number of variables and statements; no specified order of execution for multiple assignment (more optimzation freedom); can store parameter lists in variable; MRV routines (natural code); more convenient assignment statements; simple and efficient access of record fields; named return values more legible and efficient in use of storage
 \section{Multiple-Return-Value Functions}
 …
 This restriction results in code which emulates functions with multiple return values by \emph{aggregation} or by \emph{aliasing}.
 In the former situation, the function designer creates a record type that combines all of the return values into a single type.
+For example, consider a function returning the most frequently occuring letter in a string, and its frequency.
+% TODO: consider simplifying the example!
+%   Two things I like about this example:
+%   * it uses different types to illustrate why an array is insufficient (this is not necessary, but is nice)
+%   * it's complicated enough to show the uninitialized pitfall that exists in the aliasing example.
+%   Still, it may be a touch too complicated. Is there a simpler example with these two properties?
+For example, consider a function returning the most frequently occurring letter in a string, and its frequency.
+This example is complex enough to illustrate that an array is insufficient, since arrays are homogeneous, and demonstrates a potential pitfall that exists with aliasing.
 \begin{cfacode}
 struct mf_ret {
 …
 const char * str = "hello world";
 char ch;                            // pre-allocate return value
 int freq = most_frequent(str, &ch); // pass return value as parameter
+int freq = most_frequent(str, &ch); // pass return value as out parameter
 printf("%s -- %d %c\n", str, freq, ch);
 \end{cfacode}
+Notably, using this approach, the caller is directly responsible for allocating storage for the additional temporary return values.
+This complicates the call site with a sequence of variable declarations leading up to the call.
+Notably, using this approach, the caller is directly responsible for allocating storage for the additional temporary return values, which complicates the call site with a sequence of variable declarations leading up to the call.
 Also, while a disciplined use of @const@ can give clues about whether a pointer parameter is going to be used as an out parameter, it is not immediately obvious from only the routine signature whether the callee expects such a parameter to be initialized before the call.
 Furthermore, while many C routines that accept pointers are designed so that it is safe to pass @NULL@ as a parameter, there are many C routines that are not null-safe.
 On a related note, C does not provide a standard mechanism to state that a parameter is going to be used as an additional return value, which makes the job of ensuring that a value is returned more difficult for the compiler.
+There is a subtle bug in the previous example, in that @ret_ch@ is never assigned for a string that does not contain any letters, which can lead to undefined behaviour.
+Interestingly, there is a subtle bug in the previous example, in that @ret_ch@ is never assigned for a string that does not contain any letters, which can lead to undefined behaviour.
+In this particular case, it turns out that the frequency return value also doubles as an error code, where a frequency of 0 means the character return value should be ignored.
+Still, not every routine with multiple return values should be required to return an error code, and error codes are easily ignored, so this is not a satisfying solution.
 As with the previous approach, this technique can simulate multiple return values, but in practice it is verbose and error prone.
 …
 The expression resolution phase of the \CFA translator ensures that the correct form is used depending on the values being returned and the return type of the current function.
 A multiple-returning function with return type @T@ can return any expression that is implicitly convertible to @T@.
 Using the running example, the @most_frequent@ function can be written in using multiple return values as such,
+Using the running example, the @most_frequent@ function can be written using multiple return values as such,
 \begin{cfacode}
 [int, char] most_frequent(const char * str) {
   char freqs [26] = { 0 };
   int ret_freq = 0;
   char ret_ch = 'a';
+  char ret_ch = 'a';  // arbitrary default value for consistent results
   for (int i = 0; str[i] != '\0'; ++i) {
     if (isalpha(str[i])) {        // only count letters
 …
+}
 \end{cfacode}
 This approach provides the benefits of compile-time checking for appropriate return statements as in aggregation, but without the required verbosity of declaring a new named type.
+This approach provides the benefits of compile-time checking for appropriate return statements as in aggregation, but without the required verbosity of declaring a new named type, which precludes the bug seen with out-parameters.
 The addition of multiple-return-value functions necessitates a syntax for accepting multiple values at the call-site.
 …
 In this case, there is only one option for a function named @most_frequent@ that takes a string as input.
 This function returns two values, one @int@ and one @char@.
 There are four options for a function named @process@, but only two which accept two arguments, and of those the best match is (3), which is also an exact match.
+There are four options for a function named @process@, but only two that accept two arguments, and of those the best match is (3), which is also an exact match.
 This expression first calls @most_frequent("hello world")@, which produces the values @3@ and @'l'@, which are fed directly to the first and second parameters of (3), respectively.
 …
 The previous expression has 3 \emph{components}.
 Each component in a tuple expression can be any \CFA expression, including another tuple expression.
-% TODO: Tuple expressions can appear anywhere that any other expression can appear (...?)
 The order of evaluation of the components in a tuple expression is unspecified, to allow a compiler the greatest flexibility for program optimization.
 It is, however, guaranteed that each component of a tuple expression is evaluated for side-effects, even if the result is not used.
 Multiple-return-value functions can equivalently be called \emph{tuple-returning functions}.
-% TODO: does this statement still apply, and if so to what extent?
-%   Tuples are a compile-time phenomenon and have little to no run-time presence.
 \subsection{Tuple Variables}
 …
 These variables can be used in any of the contexts where a tuple expression is allowed, such as in the @printf@ function call.
 As in the @process@ example, the components of the tuple value are passed as separate parameters to @printf@, allowing very simple printing of tuple expressions.
 If the individual components are required, they can be extracted with a simple assignment, as in previous examples.
+One way to access the individual components is with a simple assignment, as in previous examples.
 \begin{cfacode}
 int freq;
 …
 In the call to @f@, @x@ is implicitly flattened so that the components of @x@ are passed as the two arguments to @f@.
 For the call to @g@, the values @y@ and @10@ are structured into a single argument of type @[int, int]@ to match the type of the parameter of @g@.
 Finally, in the call to @h@, @y@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.
 The flexible structure of tuples permits a simple and expressive function call syntax to work seamlessly with both single- and multiple-return-value functions, and with any number of arguments of arbitrarily complex structure.
+Finally, in the call to @h@, @x@ is flattened to yield an argument list of length 3, of which the first component of @x@ is passed as the first parameter of @h@, and the second component of @x@ and @y@ are structured into the second argument of type @[int, int]@.
+The flexible structure of tuples permits a simple and expressive function-call syntax to work seamlessly with both single- and multiple-return-value functions, and with any number of arguments of arbitrarily complex structure.
 In \KWC \cite{Buhr94a,Till89}, a precursor to \CFA, there were 4 tuple coercions: opening, closing, flattening, and structuring.
 Opening coerces a tuple value into a tuple of values, while closing converts a tuple of values into a single tuple value.
 Flattening coerces a nested tuple into a flat tuple, i.e. it takes a tuple with tuple components and expands it into a tuple with only non-tuple components.
 Structuring moves in the opposite direction, i.e. it takes a flat tuple value and provides structure by introducing nested tuple components.
+Flattening coerces a nested tuple into a flat tuple, \ie it takes a tuple with tuple components and expands it into a tuple with only non-tuple components.
+Structuring moves in the opposite direction, \ie it takes a flat tuple value and provides structure by introducing nested tuple components.
 In \CFA, the design has been simplified to require only the two conversions previously described, which trigger only in function call and return situations.
 …
 \label{s:TupleAssignment}
 An assignment where the left side of the assignment operator has a tuple type is called tuple assignment.
 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called Multiple and Mass Assignment, respectively.
+There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \emph{Multiple} and \emph{Mass} Assignment, respectively.
 \begin{cfacode}
 int x;
 …
 A mass assignment assigns the value $R$ to each $L_i$.
 For a mass assignment to be valid, @?=?(&$L_i$, $R$)@ must be a well-typed expression.
 This differs from C cascading assignment (e.g. @a=b=c@) in that conversions are applied to $R$ in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
+These semantics differ from C cascading assignment (\eg @a=b=c@) in that conversions are applied to $R$ in each individual assignment, which prevents data loss from the chain of conversions that can happen during a cascading assignment.
 For example, @[y, x] = 3.14@ performs the assignments @y = 3.14@ and @x = 3.14@, which results in the value @3.14@ in @y@ and the value @3@ in @x@.
 On the other hand, the C cascading assignment @y = x = 3.14@ performs the assignments @x = 3.14@ and @y = x@, which results in the value @3@ in @x@, and as a result the value @3@ in @y@ as well.
 …
 These semantics allow cascading tuple assignment to work out naturally in any context where a tuple is permitted.
 These semantics are a change from the original tuple design in \KWC \cite{Till89}, wherein tuple assignment was a statement that allows cascading assignments as a special case.
 This decision wa made in an attempt to fix what was seen as a problem with assignment, wherein it can be used in many different locations, such as in function-call argument position.
+Restricting tuple assignment to statements was an attempt to to fix what was seen as a problem with side-effects, wherein assignment can be used in many different locations, such as in function-call argument position.
 While permitting assignment as an expression does introduce the potential for subtle complexities, it is impossible to remove assignment expressions from \CFA without affecting backwards compatibility.
 Furthermore, there are situations where permitting assignment as an expression improves readability by keeping code succinct and reducing repetition, and complicating the definition of tuple assignment puts a greater cognitive burden on the user.
 …
 \end{cfacode}
 The tuple expression begins with a mass assignment of @1.5@ into @[b, d]@, which assigns @1.5@ into @b@, which is truncated to @1@, and @1.5@ into @d@, producing the tuple @[1, 1.5]@ as a result.
 That tuple is used as the right side of the multiple assignment (i.e., @[c, a] = [1, 1.5]@) that assigns @1@ into @c@ and @1.5@ into @a@, which is truncated to @1@, producing the result @[1, 1]@.
+That tuple is used as the right side of the multiple assignment (\ie, @[c, a] = [1, 1.5]@) that assigns @1@ into @c@ and @1.5@ into @a@, which is truncated to @1@, producing the result @[1, 1]@.
 Finally, the tuple @[1, 1]@ is used as an expression in the call to @f@.
 …
 void ?{}(S *, S);      // (4)
 [S, S] x = [3, 6.28];  // uses (2), (3)
 [S, S] y;              // uses (1), (1)
 [S, S] z = x.0;        // uses (4), (4)
 \end{cfacode}
 In this example, @x@ is initialized by the multiple constructor calls @?{}(&x.0, 3)@ and @?{}(&x.1, 6.28)@, while @y@ is initilaized by two default constructor calls @?{}(&y.0)@ and @?{}(&y.1)@.
+[S, S] x = [3, 6.28];  // uses (2), (3), specialized constructors
+[S, S] y;              // uses (1), (1), default constructor
+[S, S] z = x.0;        // uses (4), (4), copy constructor
+\end{cfacode}
+In this example, @x@ is initialized by the multiple constructor calls @?{}(&x.0, 3)@ and @?{}(&x.1, 6.28)@, while @y@ is initialized by two default constructor calls @?{}(&y.0)@ and @?{}(&y.1)@.
 @z@ is initialized by mass copy constructor calls @?{}(&z.0, x.0)@ and @?{}(&z.1, x.0)@.
 Finally, @x@, @y@, and @z@ are destructed, i.e. the calls @^?{}(&x.0)@, @^?{}(&x.1)@, @^?{}(&y.0)@, @^?{}(&y.1)@, @^?{}(&z.0)@, and @^?{}(&z.1)@.
+Finally, @x@, @y@, and @z@ are destructed, \ie the calls @^?{}(&x.0)@, @^?{}(&x.1)@, @^?{}(&y.0)@, @^?{}(&y.1)@, @^?{}(&z.0)@, and @^?{}(&z.1)@.
 It is possible to define constructors and assignment functions for tuple types that provide new semantics, if the existing semantics do not fit the needs of an application.
 …
 S s = t;
 \end{cfacode}
 The initialization of @s@ with @t@ works by default, because @t@ is flattened into its components, which satisfies the generated field constructor @?{}(S *, int, double)@ to initialize the first two values.
+The initialization of @s@ with @t@ works by default because @t@ is flattened into its components, which satisfies the generated field constructor @?{}(S *, int, double)@ to initialize the first two values.
 \section{Member-Access Tuple Expression}
 …
 Then the type of @a.[x, y, z]@ is @[T_x, T_y, T_z]@.
 Since tuple index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (e.g. rearrange components, drop components, duplicate components, etc.).
+Since tuple index expressions are a form of member-access expression, it is possible to use tuple-index expressions in conjunction with member tuple expressions to manually restructure a tuple (\eg, rearrange components, drop components, duplicate components, etc.).
 \begin{cfacode}
 [int, int, long, double] x;
 …
 Since \CFA permits these tuple-access expressions using structures, unions, and tuples, \emph{member tuple expression} or \emph{field tuple expression} is more appropriate.
 It could be possible to extend member-access expressions further.
+It is possible to extend member-access expressions further.
 Currently, a member-access expression whose member is a name requires that the aggregate is a structure or union, while a constant integer member requires the aggregate to be a tuple.
 In the interest of orthogonal design, \CFA could apply some meaning to the remaining combinations as well.
 …
 z.y;  // ???
 \end{cfacode}
 One possiblity is for @s.1@ to select the second member of @s@.
+One possibility is for @s.1@ to select the second member of @s@.
 Under this interpretation, it becomes possible to not only access members of a struct by name, but also by position.
 Likewise, it seems natural to open this mechanism to enumerations as well, wherein the left side would be a type, rather than an expression.
 One benefit of this interpretation is familiar, since it is extremely reminiscent of tuple-index expressions.
+One benefit of this interpretation is familiarity, since it is extremely reminiscent of tuple-index expressions.
 On the other hand, it could be argued that this interpretation is brittle in that changing the order of members or adding new members to a structure becomes a brittle operation.
 This problem is less of a concern with tuples, since modifying a tuple affects only the code which directly uses that tuple, whereas modifying a structure has far reaching consequences with every instance of the structure.
 As for @z.y@, a natural interpretation would be to extend the meaning of member tuple expressions.
 That is, currently the tuple must occur as the member, i.e. to the right of the dot.
+This problem is less of a concern with tuples, since modifying a tuple affects only the code that directly uses the tuple, whereas modifying a structure has far reaching consequences for every instance of the structure.
+As for @z.y@, one interpretation is to extend the meaning of member tuple expressions.
+That is, currently the tuple must occur as the member, \ie to the right of the dot.
 Allowing tuples to the left of the dot could distribute the member across the elements of the tuple, in much the same way that member tuple expressions distribute the aggregate across the member tuple.
 In this example, @z.y@ expands to @[z.0.y, z.1.y]@, allowing what is effectively a very limited compile-time field-sections map operation, where the argument must be a tuple containing only aggregates having a member named @y@.
 It is questionable how useful this would actually be in practice, since generally structures are not designed to have names in common with other structures, and further this could cause maintainability issues in that it encourages programmers to adopt very simple naming conventions, to maximize the amount of overlap between different types.
+It is questionable how useful this would actually be in practice, since structures often do not have names in common with other structures, and further this could cause maintainability issues in that it encourages programmers to adopt very simple naming conventions to maximize the amount of overlap between different types.
 Perhaps more useful would be to allow arrays on the left side of the dot, which would likewise allow mapping a field access across the entire array, producing an array of the contained fields.
 The immediate problem with this idea is that C arrays do not carry around their size, which would make it impossible to use this extension for anything other than a simple stack allocated array.
 Supposing this feature works as described, it would be necessary to specify an ordering for the expansion of member access expressions versus member tuple expressions.
+Supposing this feature works as described, it would be necessary to specify an ordering for the expansion of member-access expressions versus member-tuple expressions.
 \begin{cfacode}
 struct { int x, y; };
 …
 \end{cfacode}
 Depending on exactly how the two tuples are combined, different results can be achieved.
+As such, a specific ordering would need to be imposed in order for this feature to be useful.
+Furthermore, this addition moves a member tuple expression's meaning from being clear statically to needing resolver support, since the member name needs to be distributed appropriately over each member of the tuple, which could itself be a tuple.
+Ultimately, both of these extensions introduce complexity into the model, with relatively little peceived benefit.
+As such, a specific ordering would need to be imposed to make this feature useful.
+Furthermore, this addition moves a member-tuple expression's meaning from being clear statically to needing resolver support, since the member name needs to be distributed appropriately over each member of the tuple, which could itself be a tuple.
+A second possibility is for \CFA to have named tuples, as they exist in Swift and D.
+\begin{cfacode}
+typedef [int x, int y] Point2D;
+Point2D p1, p2;
+p1.x + p1.y + p2.x + p2.y;
+p1.0 + p1.1 + p2.0 + p2.1;  // equivalent
+\end{cfacode}
+In this simpler interpretation, a tuple type carries with it a list of possibly empty identifiers.
+This approach fits naturally with the named return-value feature, and would likely go a long way towards implementing it.
+Ultimately, the first two extensions introduce complexity into the model, with relatively little perceived benefit, and so were dropped from consideration.
+Named tuples are a potentially useful addition to the language, provided they can be parsed with a reasonable syntax.
 \section{Casting}
 In C, the cast operator is used to explicitly convert between types.
 In \CFA, the cast operator has a secondary use, which is type ascription.
+In \CFA, the cast operator has a secondary use, which is type ascription, since it force the expression resolution algorithm to choose the lowest cost conversion to the target type.
 That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function.
 \begin{cfacode}
 …
 (int)f();  // choose (2)
 \end{cfacode}
 Since casting is a fundamental operation in \CFA, casts should be given a meaningful interpretation in the context of tuples.
+Since casting is a fundamental operation in \CFA, casts need to be given a meaningful interpretation in the context of tuples.
 Taking a look at standard C provides some guidance with respect to the way casts should work with tuples.
 \begin{cfacode}[numbers=left]
 …
 void g();
 (void)f();
 (int)g();
+(void)f();  // valid, ignore results
+(int)g();   // invalid, void cannot be converted to int
 struct A { int x; };
 (struct A)f();
+(struct A)f();  // invalid, int cannot be converted to A
 \end{cfacode}
 In C, line 4 is a valid cast, which calls @f@ and discards its result.
 On the other hand, line 5 is invalid, because @g@ does not produce a result, so requesting an @int@ to materialize from nothing is nonsensical.
 Finally, line 8 is also invalid, because in C casts only provide conversion between scalar types \cite{C11}.
 For consistency, this implies that any case wherein the number of components increases as a result of the cast is invalid, while casts which have the same or fewer number of components may be valid.
+Finally, line 8 is also invalid, because in C casts only provide conversion between scalar types \cite[p.~91]{C11}.
+For consistency, this implies that any case wherein the number of components increases as a result of the cast is invalid, while casts that have the same or fewer number of components may be valid.
 Formally, a cast to tuple type is valid when $T_n \leq S_m$, where $T_n$ is the number of components in the target type and $S_m$ is the number of components in the source type, and for each $i$ in $[0, n)$, $S_i$ can be cast to $T_i$.
 …
   [int, [int, int], int] g();
   ([int, double])f();           // (1)
   ([int, int, int])g();         // (2)
   ([void, [int, int]])g();      // (3)
   ([int, int, int, int])g();    // (4)
   ([int, [int, int, int]])g();  // (5)
+  ([int, double])f();           // (1) valid
+  ([int, int, int])g();         // (2) valid
+  ([void, [int, int]])g();      // (3) valid
+  ([int, int, int, int])g();    // (4) invalid
+  ([int, [int, int, int]])g();  // (5) invalid
 \end{cfacode}
 …
 If @g@ is free of side effects, this is equivalent to @[(int)(g().0), (int)(g().1.0), (int)(g().2)]@.
 Since @void@ is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to @[(int)(g().1.0), (int)(g().1.1)]@).
 % will this always hold true? probably, as constructors should give all of the conversion power we need. if casts become function calls, what would they look like? would need a way to specify the target type, which seems awkward. Also, C++ basically only has this because classes are closed to extension, while we don't have that problem (can have floating constructors for any type).
 Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions.
 …
 \end{cfacode}
 Note that due to the implicit tuple conversions, this function is not restricted to the addition of two triples.
 A call to this plus operator type checks as long as a total of 6 non-tuple arguments are passed after flattening, and all of the arguments have a common type which can bind to @T@, with a pairwise @?+?@ over @T@.
 For example, these expressions will also succeed and produce the same value.
 \begin{cfacode}
 ([x.0, x.1]) + ([x.2, 10, 20, 30]);
 x.0 + ([x.1, x.2, 10, 20, 30]);
+A call to this plus operator type checks as long as a total of 6 non-tuple arguments are passed after flattening, and all of the arguments have a common type that can bind to @T@, with a pairwise @?+?@ over @T@.
+For example, these expressions also succeed and produce the same value.
+\begin{cfacode}
+([x.0, x.1]) + ([x.2, 10, 20, 30]);  // x + ([10, 20, 30])
+x.0 + ([x.1, x.2, 10, 20, 30]);      // x + ([10, 20, 30])
 \end{cfacode}
 This presents a potential problem if structure is important, as these three expressions look like they should have different meanings.
 Further, these calls can be made ambiguous by adding seemingly different functions.
+Furthermore, these calls can be made ambiguous by introducing seemingly different functions.
 \begin{cfacode}
 forall(otype T | { T ?+?(T, T); })
 …
 \end{cfacode}
 It is also important to note that these calls could be disambiguated if the function return types were different, as they likely would be for a reasonable implementation of @?+?@, since the return type is used in overload resolution.
 Still, this is a deficiency of the current argument matching algorithm, and depending on the function, differing return values may not always be appropriate.
 It's possible that this could be rectified by applying an appropriate cost to the structuring and flattening conversions, which are currently 0-cost conversions.
+Still, these semantics are a deficiency of the current argument matching algorithm, and depending on the function, differing return values may not always be appropriate.
+These issues could be rectified by applying an appropriate cost to the structuring and flattening conversions, which are currently 0-cost conversions.
 Care would be needed in this case to ensure that exact matches do not incur such a cost.
 \begin{cfacode}
 …
 \end{cfacode}
 Until this point, it has been assumed that assertion arguments must match the parameter type exactly, modulo polymorphic specialization (i.e. no implicit conversions are applied to assertion arguments).
+Until this point, it has been assumed that assertion arguments must match the parameter type exactly, modulo polymorphic specialization (\ie, no implicit conversions are applied to assertion arguments).
 This decision presents a conflict with the flexibility of tuples.
 \subsection{Assertion Inference}
 …
+}
 \end{cfacode}
 Is transformed into
+is transformed into
 \begin{cfacode}
 forall(dtype T0, dtype T1 | sized(T0) | sized(T1))
 struct _tuple2 {  // generated before the first 2-tuple
+struct _tuple2_ {  // generated before the first 2-tuple
   T0 field_0;
   T1 field_1;
 …
   _tuple2_(double, double) x;
   forall(dtype T0, dtype T1, dtype T2 | sized(T0) | sized(T1) | sized(T2))
   struct _tuple3 {  // generated before the first 3-tuple
+  struct _tuple3_ {  // generated before the first 3-tuple
     T0 field_0;
     T1 field_1;
 …
 [5, 'x', 1.24];
 \end{cfacode}
 Becomes
+becomes
 \begin{cfacode}
 (_tuple3_(int, char, double)){ 5, 'x', 1.24 };
 …
 f(x, 'z');
 \end{cfacode}
 Is transformed into
+is transformed into
 \begin{cfacode}
 void f(int, _tuple2_(double, char));
 …
 In the call to @f@, the second and third argument components are structured into a tuple argument.
 Expressions which may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion.
+Expressions that may contain side effects are made into \emph{unique expressions} before being expanded by the flattening conversion.
 Each unique expression is assigned an identifier and is guaranteed to be executed exactly once.
 \begin{cfacode}
 …
 g(h());
 \end{cfacode}
 Interally, this is converted to
+Internally, this is converted to pseudo-\CFA
 \begin{cfacode}
 void g(int, double);
 [int, double] h();
+let unq<0> = f() : g(unq<0>.0, unq<0>.1);  // notation?
+\end{cfacode}
+lazy [int, double] unq0 = h(); // deferred execution
+g(unq0.0, unq0.1);             // execute h() once
+\end{cfacode}
+That is, the function @h@ is evaluated lazily and its result is stored for subsequent accesses.
 Ultimately, unique expressions are converted into two variables and an expression.
 \begin{cfacode}
 …
 [int, double] _unq0;
 g(
   (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).0,
   (_unq0_finished_ ? _unq0 : (_unq0 = f(), _unq0_finished_ = 1, _unq0)).1,
+  (_unq0_finished_ ? _unq0 : (_unq0 = h(), _unq0_finished_ = 1, _unq0)).0,
+  (_unq0_finished_ ? _unq0 : (_unq0 = h(), _unq0_finished_ = 1, _unq0)).1,
 );
 \end{cfacode}
 …
 Every subsequent evaluation of the unique expression then results in an access to the stored result of the actual expression.
 Currently, the \CFA translator has a very broad, imprecise definition of impurity, where any function call is assumed to be impure.
 This notion could be made more precise for certain intrinsic, autogenerated, and builtin functions, and could analyze function bodies when they are available to recursively detect impurity, to eliminate some unique expressions.
 It's possible that unique expressions could be exposed to the user through a language feature, but it's not immediately obvious that there is a benefit to doing so.
 Tuple member expressions are recursively expanded into a list of member access expressions.
+Currently, the \CFA translator has a very broad, imprecise definition of impurity (side-effects), where every function call is assumed to be impure.
+This notion could be made more precise for certain intrinsic, auto-generated, and built-in functions, and could analyze function bodies, when they are available, to recursively detect impurity, to eliminate some unique expressions.
+It is possible that lazy evaluation could be exposed to the user through a lazy keyword with little additional effort.
+Tuple-member expressions are recursively expanded into a list of member-access expressions.
 \begin{cfacode}
 [int, [double, int, double], int]] x;
 x.[0, 1.[0, 2]];
 \end{cfacode}
 Which becomes
+becomes
 \begin{cfacode}
 [x.0, [x.1.0, x.1.2]];
 \end{cfacode}
 Tuple member expressions also take advantage of unique expressions in the case of possible impurity.
+Tuple-member expressions also take advantage of unique expressions in the case of possible impurity.
 Finally, the various kinds of tuple assignment, constructors, and destructors generate GNU C statement expressions.
 …
 [x, y, z] = 1.5;            // mass assignment
 \end{cfacode}
 Generates the following
+generates the following
 \begin{cfacode}
 // [x, y, z] = 1.5;
 _tuple3_(int, double, int) _tmp_stmtexpr_ret0;
 ({
+({ // GNU C statement expression
   // assign LHS address temporaries
   int *__massassign_L0 = &x;    // ?{}
 …
     int *__multassign_L2 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
     // assign RHS value temporaries and perform mass assignment to L0, L1, L2
     int __multassign_R0 = (*__massassign_L0=(int)__massassign_R0);   // ?{}
     double __multassign_R1 = (*__massassign_L1=__massassign_R0);     // ?{}
     int __multassign_R2 = (*__massassign_L2=(int)__massassign_R0);   // ?{}
+    // assign RHS value temporaries and mass-assign to L0, L1, L2
+    int __multassign_R0 = (*__massassign_L0=(int)__massassign_R0); // ?{}
+    double __multassign_R1 = (*__massassign_L1=__massassign_R0);   // ?{}
+    int __multassign_R2 = (*__massassign_L2=(int)__massassign_R0); // ?{}
     // perform construction of statement expr return variable using
 …
 });
 \end{cfacode}
 A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, e.g. in a unique expression.
+A variable is generated to store the value produced by a statement expression, since its fields may need to be constructed with a non-trivial constructor and it may need to be referred to multiple time, \eg, in a unique expression.
 $N$ LHS variables are generated and constructed using the address of the tuple components, and a single RHS variable is generated to store the value of the RHS without any loss of precision.
 A nested statement expression is generated that performs the individual assignments and constructs the return value using the results of the individual assignments.
 …
 [x, y, z] = [f(), 3];       // multiple assignment
 \end{cfacode}
+Generates
+generates the following
 \begin{cfacode}
 // [x, y, z] = [f(), 3];
 …
       _tmp_cp_ret0 :
       (_tmp_cp_ret0=f(), _unq0_finished_=1, _tmp_cp_ret0)).1; // ?{}
   ({ // tuple destruction - destruct f() return temporary - tuple destruction
+  ({ // tuple destruction - destruct f() return temporary
     // assign LHS address temporaries
     double *__massassign_L3 = (double *)&_tmp_cp_ret0.0;  // ?{}
 …
     int *__multassign_L5 = (int *)&_tmp_stmtexpr_ret0.2;       // ?{}
     // assign RHS value temporaries and perform multiple assignment to L0, L1, L2
+    // assign RHS value temporaries and multiple-assign to L0, L1, L2
     int __multassign_R3 = (*__multassign_L0=(int)__multassign_R0);  // ?{}
     double __multassign_R4 = (*__multassign_L1=__multassign_R1);    // ?{}
 …
 The use of statement expressions allows the translator to arbitrarily generate additional temporary variables as needed, but binds the implementation to a non-standard extension of the C language.
 There are other places where the \CFA translator makes use of GNU C extensions, such as its use of nested functions, so this is not a new restriction.
-\section{Variadic Functions}
-% TODO: should this maybe be its own chapter?
-C provides variadic functions through the manipulation of @va_list@ objects.
-A variadic function is one which contains at least one parameter, followed by @...@ as the last token in the parameter list.
-In particular, some form of \emph{argument descriptor} is needed to inform the function of the number of arguments and their types.
-Two common argument descriptors are format strings or and counter parameters.
-It's important to note that both of these mechanisms are inherently redundant, because they require the user to specify information that the compiler knows explicitly.
-This required repetition is error prone, because it's easy for the user to add or remove arguments without updating the argument descriptor.
-In addition, C requires the programmer to hard code all of the possible expected types.
-As a result, it is cumbersome to write a function that is open to extension.
-For example, a simple function which sums $N$ @int@s,
-\begin{cfacode}
-int sum(int N, ...) {
-  va_list args;
-  va_start(args, N);
-  int ret = 0;
-  while(N) {
-    ret += va_arg(args, int);  // have to specify type
-    N--;
+  }
-  va_end(args);
-  return ret;
+}
-sum(3, 10, 20, 30);  // need to keep counter in sync
-\end{cfacode}
-The @va_list@ type is a special C data type that abstracts variadic argument manipulation.
-The @va_start@ macro initializes a @va_list@, given the last named parameter.
-Each use of the @va_arg@ macro allows access to the next variadic argument, given a type.
-Since the function signature does not provide any information on what types can be passed to a variadic function, the compiler does not perform any error checks on a variadic call.
-As such, it is possible to pass any value to the @sum@ function, including pointers, floating-point numbers, and structures.
-In the case where the provided type is not compatible with the argument's actual type after default argument promotions, or if too many arguments are accessed, the behaviour is undefined \cite{C11}.
-Furthermore, there is no way to perform the necessary error checks in the @sum@ function at run-time, since type information is not carried into the function body.
-Since they rely on programmer convention rather than compile-time checks, variadic functions are generally unsafe.
-In practice, compilers can provide warnings to help mitigate some of the problems.
-For example, GCC provides the @format@ attribute to specify that a function uses a format string, which allows the compiler to perform some checks related to the standard format specifiers.
-Unfortunately, this does not permit extensions to the format string syntax, so a programmer cannot extend the attribute to warn for mismatches with custom types.
-Needless to say, C's variadic functions are a deficient language feature.
-Two options were examined to provide better, type-safe variadic functions in \CFA.
-\subsection{Whole Tuple Matching}
-Option 1 is to change the argument matching algorithm, so that type parameters can match whole tuples, rather than just their components.
-This option could be implemented with two phases of argument matching when a function contains type parameters and the argument list contains tuple arguments.
-If flattening and structuring fail to produce a match, a second attempt at matching the function and argument combination is made where tuple arguments are not expanded and structure must match exactly, modulo non-tuple implicit conversions.
-For example:
-\begin{cfacode}
-  forall(otype T, otype U | { T g(U); })
-  void f(T, U);
-  [int, int] g([int, int, int, int]);
-  f([1, 2], [3, 4, 5, 6]);
-\end{cfacode}
-With flattening and structuring, the call is first transformed into @f(1, 2, 3, 4, 5, 6)@.
-Since the first argument of type @T@ does not have a tuple type, unification decides that @T=int@ and @1@ is matched as the first parameter.
-Likewise, @U@ does not have a tuple type, so @U=int@ and @2@ is accepted as the second parameter.
-There are now no remaining formal parameters, but there are remaining arguments and the function is not variadic, so the match fails.
-With the addition of an exact matching attempt, @T=[int,int]@ and @U=[int,int,int,int]@ and so the arguments type check.
-Likewise, when inferring assertion @g@, an exact match is found.
-This approach is strict with respect to argument structure by nature, which makes it syntactically awkward to use in ways that the existing tuple design is not.
-For example, consider a @new@ function which allocates memory using @malloc@ and constructs the result, using arbitrary arguments.
-\begin{cfacode}
-struct Array;
-void ?{}(Array *, int, int, int);
-forall(dtype T, otype Params | sized(T) | { void ?{}(T *, Params); })
-T * new(Params p) {
-  return malloc(){ p };
+}
-Array(int) * x = new([1, 2, 3]);
-\end{cfacode}
-The call to @new@ is not particularly appealing, since it requires the use of square brackets at the call-site, which is not required in any other function call.
-This shifts the burden from the compiler to the programmer, which is almost always wrong, and creates an odd inconsistency within the language.
-Similarly, in order to pass 0 variadic arguments, an explicit empty tuple must be passed into the argument list, otherwise the exact matching rule would not have an argument to bind against.
-It should be otherwise noted that the addition of an exact matching rule only affects the outcome for polymorphic type binding when tuples are involved.
-For non-tuple arguments, exact matching and flattening \& structuring are equivalent.
-For tuple arguments to a function without polymorphic formal parameters, flattening and structuring work whenever an exact match would have worked, since the tuple is flattened and implicitly restructured to its original structure.
-Thus there is nothing to be gained from permitting the exact matching rule to take effect when a function does not contain polymorphism and none of the arguments are tuples.
-Overall, this option takes a step in the right direction, but is contrary to the flexibility of the existing tuple design.
-\subsection{A New Typeclass}
-A second option is the addition of another kind of type parameter, @ttype@.
-Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types.
-In a given parameter list, there should be at most one @ttype@ parameter that must occur last, otherwise the call can never resolve, given the previous rule.
-% TODO: a similar rule exists in C/C++ for "..."
-This idea essentially matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates.
-As such, @ttype@ variables will also be referred to as argument packs.
-This is the option that has been added to \CFA.
-Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is through recursion.
-Since nothing is known about a parameter pack by default, assertion parameters are key to doing anything meaningful.
-Unlike variadic templates, @ttype@ polymorphic functions can be separately compiled.
-For example, a simple translation of the C sum function using @ttype@ would look like
-\begin{cfacode}
-int sum(){ return 0; }        // (0)
-forall(ttype Params | { int sum(Params); })
-int sum(int x, Params rest) { // (1)
-  return x+sum(rest);
+}
-sum(10, 20, 30);
-\end{cfacode}
-Since (0) does not accept any arguments, it is not a valid candidate function for the call @sum(10, 20, 30)@.
-In order to call (1), @10@ is matched with @x@, and the argument resolution moves on to the argument pack @rest@, which consumes the remainder of the argument list and @Params@ is bound to @[20, 30]@.
-In order to finish the resolution of @sum@, an assertion parameter which matches @int sum(int, int)@ is required.
-Like in the previous iteration, (0) is not a valid candiate, so (1) is examined with @Params@ bound to @[int]@, requiring the assertion @int sum(int)@.
-Next, (0) fails, and to satisfy (1) @Params@ is bound to @[]@, requiring an assertion @int sum()@.
-Finally, (0) matches and (1) fails, which terminates the recursion.
-Effectively, this traces as @sum(10, 20, 30)@ $\rightarrow$ @10+sum(20, 30)@ $\rightarrow$ @10+(20+sum(30))@ $\rightarrow$ @10+(20+(30+sum()))@ $\rightarrow$ @10+(20+(30+0))@.
-A point of note is that this version does not require any form of argument descriptor, since the \CFA type system keeps track of all of these details.
-It might be reasonable to take the @sum@ function a step further to enforce a minimum number of arguments, which could be done simply
-\begin{cfacode}
-int sum(int x, int y){
-  return x+y;
+}
-forall(ttype Params | { int sum(int, Params); })
-int sum(int x, int y, Params rest) {
-  return sum(x+y, rest);
+}
-sum(10, 20, 30);
-\end{cfacode}
-One more iteration permits the summation of any summable type, as long as all arguments are the same type.
-\begin{cfacode}
-trait summable(otype T) {
-  T ?+?(T, T);
-};
-forall(otype R | summable(R))
-R sum(R x, R y){
-  return x+y;
+}
-forall(otype R, ttype Params
-  | summable(R)
-  | { R sum(R, Params); })
-R sum(R x, R y, Params rest) {
-  return sum(x+y, rest);
+}
-sum(3, 10, 20, 30);
-\end{cfacode}
-Unlike C, it is not necessary to hard code the expected type.
-This is naturally open to extension, in that any user-defined type with a @?+?@ operator is automatically able to be used with the @sum@ function.
-That is to say, the programmer who writes @sum@ does not need full program knowledge of every possible data type, unlike what is necessary to write an equivalent function using the standard C mechanisms.
-Going one last step, it is possible to achieve full generality in \CFA, allowing the summation of arbitrary lists of summable types.
-\begin{cfacode}
-trait summable(otype T1, otype T2, otype R) {
-  R ?+?(T1, T2);
-};
-forall(otype T1, otype T2, otype R | summable(T1, T2, R))
-R sum(T1 x, T2 y) {
-  return x+y;
+}
-forall(otype T1, otype T2, otype T3, ttype Params, otype R
-  | summable(T1, T2, T3)
-  | { R sum(T3, Params); })
-R sum(T1 x, T2 y, Params rest ) {
-  return sum(x+y, rest);
+}
-sum(3, 10.5, 20, 30.3);
-\end{cfacode}
-The \CFA translator requires adding explicit @double ?+?(int, double)@ and @double ?+?(double, int)@ functions for this call to work, since implicit conversions are not supported for assertions.
-C variadic syntax and @ttype@ polymorphism probably should not be mixed, since it is not clear where to draw the line to decide which arguments belong where.
-Furthermore, it might be desirable to disallow polymorphic functions to use C variadic syntax to encourage a Cforall style.
-Aside from calling C variadic functions, it is not obvious that there is anything that can be done with C variadics that could not also be done with @ttype@ parameters.
-Variadic templates in \CC require an ellipsis token to express that a parameter is a parameter pack and to expand a parameter pack.
-\CFA does not need an ellipsis in either case, since the type class @ttype@ is only used for variadics.
-An alternative design could have used an ellipsis combined with an existing type class.
-This approach was not taken because the largest benefit of the ellipsis token in \CC is the ability to expand a parameter pack within an expression, e.g. in fold expressions, which requires compile-time knowledge of the structure of the parameter pack, which is not available in \CFA.
-\begin{cppcode}
-template<typename... Args>
-void f(Args &... args) {
-  g(&args...);  // expand to addresses of pack elements
+}
-\end{cppcode}
-As such, the addition of an ellipsis token would be purely an aesthetic change in \CFA today.
-It is possible to write a type-safe variadic print routine, which can replace @printf@
-\begin{cfacode}
-struct S { int x, y; };
-forall(otype T, ttype Params |
-  { void print(T); void print(Params); })
-void print(T arg, Params rest) {
-  print(arg);
-  print(rest);
+}
-void print(char * x) { printf("%s", x); }
-void print(int x) { printf("%d", x);  }
-void print(S s) { print("{ ", s.x, ",", s.y, " }"); }
-print("s = ", (S){ 1, 2 }, "\n");
-\end{cfacode}
-This example routine showcases a variadic-template-like decomposition of the provided argument list.
-The individual @print@ routines allow printing a single element of a type.
-The polymorphic @print@ allows printing any list of types, as long as each individual type has a @print@ function.
-The individual print functions can be used to build up more complicated @print@ routines, such as for @S@, which is something that cannot be done with @printf@ in C.
-It is also possible to use @ttype@ polymorphism to provide arbitrary argument forwarding functions.
-For example, it is possible to write @new@ as a library function.
-Example 2: new (i.e. type-safe malloc + constructors)
-\begin{cfacode}
-struct Array;
-void ?{}(Array *, int, int, int);
-forall(dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); })
-T * new(Params p) {
-  return malloc(){ p }; // construct result of malloc
+}
-Array * x = new(1, 2, 3);
-\end{cfacode}
-The @new@ function provides the combination of type-safe @malloc@ with a constructor call, so that it becomes impossible to forget to construct dynamically allocated objects.
-This provides the type-safety of @new@ in \CC, without the need to specify the allocated type, thanks to return-type inference.
-In the call to @new@, @Array@ is selected to match @T@, and @Params@ is expanded to match @[int, int, int, int]@. To satisfy the assertions, a constructor with an interface compatible with @void ?{}(Array *, int, int, int)@ must exist in the current scope.
-\subsection{Implementation}
-The definition of @new@
-\begin{cfacode}
-forall(dtype T | sized(T)) T * malloc();
-forall(dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); })
-T * new(Params p) {
-  return malloc(){ p }; // construct result of malloc
+}
-\end{cfacode}
-Generates the following
-\begin{cfacode}
-void *malloc(long unsigned int _sizeof_T, long unsigned int _alignof_T);
-void *new(
-  void (*_adapter_)(void (*)(), void *, void *),
-  long unsigned int _sizeof_T,
-  long unsigned int _alignof_T,
-  long unsigned int _sizeof_Params,
-  long unsigned int _alignof_Params,
-  void (* _ctor_T)(void *, void *),
-  void *p
-){
-  void *_retval_new;
-  void *_tmp_cp_ret0;
-  void *_tmp_ctor_expr0;
-  _retval_new=
-    (_adapter_(_ctor_T,
-      (_tmp_ctor_expr0=(_tmp_cp_ret0=malloc(_sizeof_2tT, _alignof_2tT),
-        _tmp_cp_ret0)),
-      p),
-    _tmp_ctor_expr0); // ?{}
-  *(void **)&_tmp_cp_ret0; // ^?{}
-  return _retval_new;
+}
-\end{cfacode}
-The constructor for @T@ is called indirectly through the adapter function on the result of @malloc@ and the parameter pack.
-The variable that was allocated and constructed is then returned from @new@.
-A call to @new@
-\begin{cfacode}
-struct S { int x, y; };
-void ?{}(S *, int, int);
-S * s = new(3, 4);
-\end{cfacode}
-Generates the following
-\begin{cfacode}
-struct _tuple2_ {  // _tuple2_(T0, T1)
-  void *field_0;
-  void *field_1;
-};
-struct _conc__tuple2_0 {  // _tuple2_(int, int)
-  int field_0;
-  int field_1;
-};
-struct _conc__tuple2_0 _tmp_cp1;  // tuple argument to new
-struct S *_tmp_cp_ret1;           // return value from new
-void _thunk0(  // ?{}(S *, [int, int])
-  struct S *_p0,
-  struct _conc__tuple2_0 _p1
-){
-  _ctor_S(_p0, _p1.field_0, _p1.field_1);  // restructure tuple parameter
+}
-void _adapter(void (*_adaptee)(), void *_p0, void *_p1){
-  // apply adaptee to arguments after casting to actual types
-  ((void (*)(struct S *, struct _conc__tuple2_0))_adaptee)(
-    _p0,
-    *(struct _conc__tuple2_0 *)_p1
-  );
+}
-struct S *s = (struct S *)(_tmp_cp_ret1=
-  new(
-    _adapter,
-    sizeof(struct S),
-    __alignof__(struct S),
-    sizeof(struct _conc__tuple2_0),
-    __alignof__(struct _conc__tuple2_0),
-    (void (*)(void *, void *))&_thunk0,
-    (({ // copy construct tuple argument to new
-      int *__multassign_L0 = (int *)&_tmp_cp1.field_0;
-      int *__multassign_L1 = (int *)&_tmp_cp1.field_1;
-      int __multassign_R0 = 3;
-      int __multassign_R1 = 4;
-      ((*__multassign_L0=__multassign_R0 /* ?{} */) ,
-       (*__multassign_L1=__multassign_R1 /* ?{} */));
-    }), &_tmp_cp1)
-  ), _tmp_cp_ret1);
-*(struct S **)&_tmp_cp_ret1; // ^?{}  // destroy return value from new
-({  // destroy argument temporary
-  int *__massassign_L0 = (int *)&_tmp_cp1.field_0;
-  int *__massassign_L1 = (int *)&_tmp_cp1.field_1;
-  ((*__massassign_L0 /* ^?{} */) , (*__massassign_L1 /* ^?{} */));
-});
-\end{cfacode}
-Of note, @_thunk0@ is generated to translate calls to @?{}(S *, [int, int])@ into calls to @?{}(S *, int, int)@.
-The call to @new@ constructs a tuple argument using the supplied arguments.
-The @print@ function
-\begin{cfacode}
-forall(otype T, ttype Params |
-  { void print(T); void print(Params); })
-void print(T arg, Params rest) {
-  print(arg);
-  print(rest);
+}
-\end{cfacode}
-Generates
-\begin{cfacode}
-void print_variadic(
-  void (*_adapterF_7tParams__P)(void (*)(), void *),
-  void (*_adapterF_2tT__P)(void (*)(), void *),
-  void (*_adapterF_P2tT2tT__MP)(void (*)(), void *, void *),
-  void (*_adapterF2tT_P2tT2tT_P_MP)(void (*)(), void *, void *, void *),
-  long unsigned int _sizeof_T,
-  long unsigned int _alignof_T,
-  long unsigned int _sizeof_Params,
-  long unsigned int _alignof_Params,
-  void *(*_assign_TT)(void *, void *),
-  void (*_ctor_T)(void *),
-  void (*_ctor_TT)(void *, void *),
-  void (*_dtor_T)(void *),
-  void (*print_T)(void *),
-  void (*print_Params)(void *),
-  void *arg,
-  void *rest
-){
-  void *_tmp_cp0 = __builtin_alloca(_sizeof_T);
-  _adapterF_2tT__P(  // print(arg)
-    ((void (*)())print_T),
-    (_adapterF_P2tT2tT__MP( // copy construct argument
-      ((void (*)())_ctor_TT),
-      _tmp_cp0,
-      arg
-    ), _tmp_cp0)
-  );
-  _dtor_T(_tmp_cp0);  // destroy argument temporary
-  _adapterF_7tParams__P(  // print(rest)
-    ((void (*)())print_Params),
-    rest
-  );
+}
-\end{cfacode}
-The @print_T@ routine is called indirectly through an adapter function with a copy constructed argument, followed by an indirect call to @print_Params@.
-A call to print
-\begin{cfacode}
-void print(const char * x) { printf("%s", x); }
-void print(int x) { printf("%d", x);  }
-print("x = ", 123, ".\n");
-\end{cfacode}
-Generates the following
-\begin{cfacode}
-void print_string(const char *x){
-  int _tmp_cp_ret0;
-  (_tmp_cp_ret0=printf("%s", x)) , _tmp_cp_ret0;
-  *(int *)&_tmp_cp_ret0; // ^?{}
+}
-void print_int(int x){
-  int _tmp_cp_ret1;
-  (_tmp_cp_ret1=printf("%d", x)) , _tmp_cp_ret1;
-  *(int *)&_tmp_cp_ret1; // ^?{}
+}
-struct _tuple2_ {  // _tuple2_(T0, T1)
-  void *field_0;
-  void *field_1;
-};
-struct _conc__tuple2_0 {  // _tuple2_(int, const char *)
-  int field_0;
-  const char *field_1;
-};
-struct _conc__tuple2_0 _tmp_cp6;  // _tuple2_(int, const char *)
-const char *_thunk0(const char **_p0, const char *_p1){
-        // const char * ?=?(const char **, const char *)
-  return *_p0=_p1;
+}
-void _thunk1(const char **_p0){ // void ?{}(const char **)
-  *_p0; // ?{}
+}
-void _thunk2(const char **_p0, const char *_p1){
-        // void ?{}(const char **, const char *)
-  *_p0=_p1; // ?{}
+}
-void _thunk3(const char **_p0){ // void ^?{}(const char **)
-  *_p0; // ^?{}
+}
-void _thunk4(struct _conc__tuple2_0 _p0){ // void print([int, const char *])
-  struct _tuple1_ { // _tuple1_(T0)
-    void *field_0;
-  };
-  struct _conc__tuple1_1 { // _tuple1_(const char *)
-    const char *field_0;
-  };
-  void _thunk5(struct _conc__tuple1_1 _pp0){ // void print([const char *])
-    print_string(_pp0.field_0);  // print(rest.0)
+  }
-  void _adapter_i_pii_(void (*_adaptee)(), void *_ret, void *_p0, void *_p1){
-    *(int *)_ret=((int (*)(int *, int))_adaptee)(_p0, *(int *)_p1);
+  }
-  void _adapter_pii_(void (*_adaptee)(), void *_p0, void *_p1){
-    ((void (*)(int *, int ))_adaptee)(_p0, *(int *)_p1);
+  }
-  void _adapter_i_(void (*_adaptee)(), void *_p0){
-    ((void (*)(int))_adaptee)(*(int *)_p0);
+  }
-  void _adapter_tuple1_5_(void (*_adaptee)(), void *_p0){
-    ((void (*)(struct _conc__tuple1_1 ))_adaptee)(*(struct _conc__tuple1_1 *)_p0);
+  }
-  print_variadic(
-    _adapter_tuple1_5,
-    _adapter_i_,
-    _adapter_pii_,
-    _adapter_i_pii_,
-    sizeof(int),
-    __alignof__(int),
-    sizeof(struct _conc__tuple1_1),
-    __alignof__(struct _conc__tuple1_1),
-    (void *(*)(void *, void *))_assign_i,     // int ?=?(int *, int)
-    (void (*)(void *))_ctor_i,                // void ?{}(int *)
-    (void (*)(void *, void *))_ctor_ii,       // void ?{}(int *, int)
-    (void (*)(void *))_dtor_ii,               // void ^?{}(int *)
-    (void (*)(void *))print_int,              // void print(int)
-    (void (*)(void *))&_thunk5,               // void print([const char *])
-    &_p0.field_0,                             // rest.0
-    &(struct _conc__tuple1_1 ){ _p0.field_1 } // [rest.1]
-  );
+}
-struct _tuple1_ {  // _tuple1_(T0)
-  void *field_0;
-};
-struct _conc__tuple1_6 {  // _tuple_1(const char *)
-  const char *field_0;
-};
-const char *_temp0;
-_temp0="x = ";
-void _adapter_pstring_pstring_string(
-  void (*_adaptee)(),
-  void *_ret,
-  void *_p0,
-  void *_p1
-){
-  *(const char **)_ret=
-    ((const char *(*)(const char **, const char *))_adaptee)(
-      _p0,
-      *(const char **)_p1
-    );
+}
-void _adapter_pstring_string(void (*_adaptee)(), void *_p0, void *_p1){
-  ((void (*)(const char **, const char *))_adaptee)(_p0, *(const char **)_p1);
+}
-void _adapter_string_(void (*_adaptee)(), void *_p0){
-  ((void (*)(const char *))_adaptee)(*(const char **)_p0);
+}
-void _adapter_tuple2_0_(void (*_adaptee)(), void *_p0){
-  ((void (*)(struct _conc__tuple2_0 ))_adaptee)(*(struct _conc__tuple2_0 *)_p0);
+}
-print_variadic(
-  _adapter_tuple2_0_,
-  _adapter_string_,
-  _adapter_pstring_string_,
-  _adapter_pstring_pstring_string_,
-  sizeof(const char *),
-  __alignof__(const char *),
-  sizeof(struct _conc__tuple2_0 ),
-  __alignof__(struct _conc__tuple2_0 ),
-  (void *(*)(void *, void *))&_thunk0, // const char * ?=?(const char **, const char *)
-  (void (*)(void *))&_thunk1,          // void ?{}(const char **)
-  (void (*)(void *, void *))&_thunk2,  // void ?{}(const char **, const char *)
-  (void (*)(void *))&_thunk3,          // void ^?{}(const char **)
-  (void (*)(void *))print_string,      // void print(const char *)
-  (void (*)(void *))&_thunk4,          // void print([int, const char *])
-  &_temp0,                             // "x = "
-  (({  // copy construct tuple argument to print
-    int *__multassign_L0 = (int *)&_tmp_cp6.field_0;
-    const char **__multassign_L1 = (const char **)&_tmp_cp6.field_1;
-    int __multassign_R0 = 123;
-    const char *__multassign_R1 = ".\n";
-    ((*__multassign_L0=__multassign_R0 /* ?{} */),
-     (*__multassign_L1=__multassign_R1 /* ?{} */));
-  }), &_tmp_cp6)                        // [123, ".\n"]
-);
-({  // destroy argument temporary
-  int *__massassign_L0 = (int *)&_tmp_cp6.field_0;
-  const char **__massassign_L1 = (const char **)&_tmp_cp6.field_1;
-  ((*__massassign_L0 /* ^?{} */) , (*__massassign_L1 /* ^?{} */));
-});
-\end{cfacode}
-The type @_tuple2_@ is generated to allow passing the @rest@ argument to @print_variadic@.
-Thunks 0 through 3 provide wrappers for the @otype@ parameters for @const char *@, while @_thunk4@ translates a call to @print([int, const char *])@ into a call to @print_variadic(int, [const char *])@.
-This all builds to a call to @print_variadic@, with the appropriate copy construction of the tuple argument.
-\section{Future Work}

doc/user/user.tex

-                      r221c2de7
+                      r154fdc8
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Wed Apr  5 23:19:40 2017
 %% Update Count     : 1412
+%% Last Modified On : Wed Apr 12 12:18:58 2017
+%% Update Count     : 1415
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 % Names used in the document.
 \newcommand{\Version}{\input{../../version}}
-\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}}}}
 …
 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 \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC} 6.7\%, \CS 4.3\%, \Index*{Python} 4.3\%, and all other programming languages below 3\%.
+The TIOBE index (\url{http://www.tiobe.com/tiobe_index}) for March 2016 shows programming-language popularity, with \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC} 6.7\%, \Csharp 4.3\%, \Index*{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}

src/ControlStruct/LabelGenerator.cc

-                      r221c2de7
+                      r154fdc8
 #include "SynTree/Label.h"
 #include "SynTree/Attribute.h"
+#include "SynTree/Statement.h"
 namespace ControlStruct {
 …
+        }
         Label LabelGenerator::newLabel( std::string suffix ) {
+        Label LabelGenerator::newLabel( std::string suffix, Statement * stmt ) {
                 std::ostringstream os;
                 os << "__L" << current++ << "__" << suffix;
+                if ( stmt && ! stmt->get_labels().empty() ) {
+                        os << "_" << stmt->get_labels().front() << "__";
+                }
                 std::string ret = os.str();
                 Label l( ret );

src/ControlStruct/LabelGenerator.h

-                      r221c2de7
+                      r154fdc8
 // file "LICENCE" distributed with Cforall.
 //
 // LabelGenerator.h --
+// LabelGenerator.h --
 //
 // Author           : Rodolfo G. Esteves
 …
           public:
                 static LabelGenerator *getGenerator();
                 Label newLabel(std::string suffix = "");
+                Label newLabel(std::string suffix, Statement * stmt = nullptr);
                 void reset() { current = 0; }
                 void rewind() { current--; }

src/ControlStruct/MLEMutator.cc

-                      r221c2de7
+                      r154fdc8
                 bool labeledBlock = !(cmpndStmt->get_labels().empty());
                 if ( labeledBlock ) {
                         Label brkLabel = generator->newLabel("blockBreak");
+                        Label brkLabel = generator->newLabel("blockBreak", cmpndStmt);
                         enclosingControlStructures.push_back( Entry( cmpndStmt, brkLabel ) );
                 } // if
 …
                 // whether brkLabel and contLabel are used with branch statements and will recursively do the same to nested
                 // loops
                 Label brkLabel = generator->newLabel("loopBreak");
                 Label contLabel = generator->newLabel("loopContinue");
+                Label brkLabel = generator->newLabel("loopBreak", loopStmt);
+                Label contLabel = generator->newLabel("loopContinue", loopStmt);
                 enclosingControlStructures.push_back( Entry( loopStmt, brkLabel, contLabel ) );
                 loopStmt->set_body ( loopStmt->get_body()->acceptMutator( *this ) );
+                assert( ! enclosingControlStructures.empty() );
                 Entry &e = enclosingControlStructures.back();
                 // sanity check that the enclosing loops have been popped correctly
 …
                 bool labeledBlock = !(ifStmt->get_labels().empty());
                 if ( labeledBlock ) {
                         Label brkLabel = generator->newLabel("blockBreak");
+                        Label brkLabel = generator->newLabel("blockBreak", ifStmt);
                         enclosingControlStructures.push_back( Entry( ifStmt, brkLabel ) );
                 } // if
                 Parent::mutate( ifStmt );
                 if ( labeledBlock ) {
                         if ( ! enclosingControlStructures.back().useBreakExit().empty() ) {
 …
         Statement *MLEMutator::handleSwitchStmt( SwitchClass *switchStmt ) {
                 // generate a label for breaking out of a labeled switch
                 Label brkLabel = generator->newLabel("switchBreak");
+                Label brkLabel = generator->newLabel("switchBreak", switchStmt);
                 enclosingControlStructures.push_back( Entry(switchStmt, brkLabel) );
                 mutateAll( switchStmt->get_statements(), *this );
 …
                 std::list< Entry >::reverse_iterator targetEntry;
+                if ( branchStmt->get_type() == BranchStmt::Goto ) {
+                        return branchStmt;
+                } else if ( branchStmt->get_type() == BranchStmt::Continue) {
+                        // continue target must be a loop
+                        if ( branchStmt->get_target() == "" ) {
+                                targetEntry = std::find_if( enclosingControlStructures.rbegin(), enclosingControlStructures.rend(), [](Entry &e) { return isLoop( e.get_controlStructure() ); } );
+                        } else {
+                                // labelled continue - lookup label in table ot find attached control structure
+                                targetEntry = std::find( enclosingControlStructures.rbegin(), enclosingControlStructures.rend(), (*targetTable)[branchStmt->get_target()] );
+                        } // if
+                        if ( targetEntry == enclosingControlStructures.rend() || ! isLoop( targetEntry->get_controlStructure() ) ) {
+                                throw SemanticError( "'continue' target must be an enclosing loop: " + originalTarget );
+                        } // if
+                } else if ( branchStmt->get_type() == BranchStmt::Break ) {
+                        if ( enclosingControlStructures.empty() ) throw SemanticError( "'break' outside a loop, switch, or labelled block" );
+                        targetEntry = enclosingControlStructures.rbegin();
+                } else {
+                        assert( false );
+                } // if
+                if ( branchStmt->get_target() != "" && targetTable->find( branchStmt->get_target() ) == targetTable->end() ) {
+                        throw SemanticError("The label defined in the exit loop statement does not exist: " + originalTarget );  // shouldn't happen (since that's already checked)
+                } // if
+                switch ( branchStmt->get_type() ) {
+                        case BranchStmt::Goto:
+                                return branchStmt;
+                        case BranchStmt::Continue:
+                        case BranchStmt::Break: {
+                                bool isContinue = branchStmt->get_type() == BranchStmt::Continue;
+                                // unlabeled break/continue
+                                if ( branchStmt->get_target() == "" ) {
+                                        if ( isContinue ) {
+                                                // continue target is outermost loop
+                                                targetEntry = std::find_if( enclosingControlStructures.rbegin(), enclosingControlStructures.rend(), [](Entry &e) { return isLoop( e.get_controlStructure() ); } );
+                                        } else {
+                                                // break target is outmost control structure
+                                                if ( enclosingControlStructures.empty() ) throw SemanticError( "'break' outside a loop, switch, or labelled block" );
+                                                targetEntry = enclosingControlStructures.rbegin();
+                                        } // if
+                                } else {
+                                        // labeled break/continue - lookup label in table to find attached control structure
+                                        targetEntry = std::find( enclosingControlStructures.rbegin(), enclosingControlStructures.rend(), (*targetTable)[branchStmt->get_target()] );
+                                } // if
+                                // ensure that selected target is valid
+                                if ( targetEntry == enclosingControlStructures.rend() || (isContinue && ! isLoop( targetEntry->get_controlStructure() ) ) ) {
+                                        throw SemanticError( toString( (isContinue ? "'continue'" : "'break'"), " target must be an enclosing ", (isContinue ? "loop: " : "control structure: "), originalTarget ) );
+                                } // if
+                                break;
+                        }
+                        default:
+                                assert( false );
+                } // switch
                 // branch error checks, get the appropriate label name and create a goto
 …
                 } // switch
+                if ( branchStmt->get_target() == "" && branchStmt->get_type() != BranchStmt::Continue ) {
+                        // unlabelled break/continue - can keep branch as break/continue for extra semantic information, but add
+                        // exitLabel as its destination so that label passes can easily determine where the break/continue goes to
+                        branchStmt->set_target( exitLabel );
+                        return branchStmt;
+                } else {
+                        // labelled break/continue - can't easily emulate this with break and continue, so transform into a goto
+                        delete branchStmt;
+                        return new BranchStmt( std::list<Label>(), exitLabel, BranchStmt::Goto );
+                } // if
+                // transform break/continue statements into goto to simplify later handling of branches
+                delete branchStmt;
+                return new BranchStmt( std::list<Label>(), exitLabel, BranchStmt::Goto );
+        }

src/GenPoly/Box.cc

-                      r221c2de7
+                      r154fdc8
 #include "Parser/ParseNode.h"
+#include "SynTree/Attribute.h"
 #include "SynTree/Constant.h"
 #include "SynTree/Declaration.h"
 …
                         using Parent::mutate;
+                        PolyGenericCalculator();
                         template< typename DeclClass >
                         DeclClass *handleDecl( DeclClass *decl, Type *type );
 …
                         ScopedSet< std::string > knownLayouts;          ///< Set of generic type layouts known in the current scope, indexed by sizeofName
                         ScopedSet< std::string > knownOffsets;          ///< Set of non-generic types for which the offset array exists in the current scope, indexed by offsetofName
+                        UniqueName bufNamer;                           ///< Namer for VLA buffers
                 };
 …
 ////////////////////////////////////////// PolyGenericCalculator ////////////////////////////////////////////////////
+                PolyGenericCalculator::PolyGenericCalculator()
+                        : Parent(), knownLayouts(), knownOffsets(), bufNamer( "_buf" ) {}
                 void PolyGenericCalculator::beginTypeScope( Type *ty ) {
                         scopeTyVars.beginScope();
 …
                         if ( ObjectDecl *objectDecl = dynamic_cast< ObjectDecl *>( declStmt->get_decl() ) ) {
                                 if ( findGeneric( objectDecl->get_type() ) ) {
                                         // change initialization of a polymorphic value object
                                         // to allocate storage with alloca
+                                        // change initialization of a polymorphic value object to allocate via a VLA
+                                        // (alloca was previously used, but can't be safely used in loops)
                                         Type *declType = objectDecl->get_type();
+                                        UntypedExpr *alloc = new UntypedExpr( new NameExpr( "__builtin_alloca" ) );
+                                        alloc->get_args().push_back( new NameExpr( sizeofName( mangleType( declType ) ) ) );
+                                        std::string bufName = bufNamer.newName();
+                                        ObjectDecl *newBuf = new ObjectDecl( bufName, Type::StorageClasses(), LinkageSpec::C, 0,
+                                                new ArrayType( Type::Qualifiers(), new BasicType( Type::Qualifiers(), BasicType::Kind::Char), new NameExpr( sizeofName( mangleType(declType) ) ),
+                                                true, false, std::list<Attribute*>{ new Attribute( std::string{"aligned"}, std::list<Expression*>{ new ConstantExpr( Constant::from_int(8) ) } ) } ), 0 );
+                                        stmtsToAdd.push_back( new DeclStmt( noLabels, newBuf ) );
                                         delete objectDecl->get_init();
+                                        std::list<Expression*> designators;
+                                        objectDecl->set_init( new SingleInit( alloc, designators, false ) ); // not constructed
+                                        objectDecl->set_init( new SingleInit( new NameExpr( bufName ) ) );
+                                }
+                        }

src/Parser/ParseNode.h

-                      r221c2de7
+                      r154fdc8
   public:
         ExpressionNode( Expression * expr = nullptr ) : expr( expr ) {}
-        ExpressionNode( const ExpressionNode &other );
         virtual ~ExpressionNode() {}
         virtual ExpressionNode * clone() const override { return expr ? new ExpressionNode( expr->clone() ) : nullptr; }
+        virtual ExpressionNode * clone() const override { return expr ? static_cast<ExpressionNode*>((new ExpressionNode( expr->clone() ))->set_next( maybeClone( get_next() ) )) : nullptr; }
         bool get_extension() const { return extension; }

src/ResolvExpr/AlternativeFinder.cc

-                      r221c2de7
+                      r154fdc8
+        }
+        // std::unordered_map< Expression *, UniqueExpr * > ;
+        void AlternativeFinder::addAnonConversions( const Alternative & alt ) {
+                // adds anonymous member interpretations whenever an aggregate value type is seen.
+                Expression * expr = alt.expr->clone();
+                std::unique_ptr< Expression > manager( expr ); // RAII for expr
+                alt.env.apply( expr->get_result() );
+                if ( StructInstType *structInst = dynamic_cast< StructInstType* >( expr->get_result() ) ) {
+                        NameExpr nameExpr( "" );
+                        addAggMembers( structInst, expr, alt.cost+Cost( 0, 0, 1 ), alt.env, &nameExpr );
+                } else if ( UnionInstType *unionInst = dynamic_cast< UnionInstType* >( expr->get_result() ) ) {
+                        NameExpr nameExpr( "" );
+                        addAggMembers( unionInst, expr, alt.cost+Cost( 0, 0, 1 ), alt.env, &nameExpr );
+                } // if
+        }
         template< typename StructOrUnionType >
 …
                 std::list< Declaration* > members;
                 aggInst->lookup( name, members );
                 for ( std::list< Declaration* >::const_iterator i = members.begin(); i != members.end(); ++i ) {
                         if ( DeclarationWithType *dwt = dynamic_cast< DeclarationWithType* >( *i ) ) {
                                 alternatives.push_back( Alternative( new MemberExpr( dwt, expr->clone() ), env, newCost ) );
                                 renameTypes( alternatives.back().expr );
+                                addAnonConversions( alternatives.back() ); // add anonymous member interpretations whenever an aggregate value type is seen as a member expression.
                         } else {
                                 assert( false );
 …
                 if ( candidates.empty() && ! errors.isEmpty() ) { throw errors; }
+                // compute conversionsion costs
                 for ( AltList::iterator withFunc = candidates.begin(); withFunc != candidates.end(); ++withFunc ) {
                         Cost cvtCost = computeConversionCost( *withFunc, indexer );
 …
                         } // if
                 } // for
+                // function may return struct or union value, in which case we need to add alternatives for implicit conversions to each of the anonymous members
+                for ( const Alternative & alt : alternatives ) {
+                        addAnonConversions( alt );
+                }
                 candidates.clear();
                 candidates.splice( candidates.end(), alternatives );
 …
+                        )
                         renameTypes( alternatives.back().expr );
+                        if ( StructInstType *structInst = dynamic_cast< StructInstType* >( (*i)->get_type() ) ) {
+                                NameExpr nameExpr( "" );
+                                addAggMembers( structInst, &newExpr, Cost( 0, 0, 1 ), env, &nameExpr );
+                        } else if ( UnionInstType *unionInst = dynamic_cast< UnionInstType* >( (*i)->get_type() ) ) {
+                                NameExpr nameExpr( "" );
+                                addAggMembers( unionInst, &newExpr, Cost( 0, 0, 1 ), env, &nameExpr );
+                        } // if
+                        addAnonConversions( alternatives.back() ); // add anonymous member interpretations whenever an aggregate value type is seen as a name expression.
                 } // for
+        }

src/ResolvExpr/AlternativeFinder.h

r221c2de7	r154fdc8
78	78	void findSubExprs( InputIterator begin, InputIterator end, OutputIterator out );
79	79
	80	/// Adds alternatives for anonymous members
	81	void addAnonConversions( const Alternative & alt );
80	82	/// Adds alternatives for member expressions, given the aggregate, conversion cost for that aggregate, and name of the member
81	83	template< typename StructOrUnionType > void addAggMembers( StructOrUnionType aggInst, Expression expr, const Cost &newCost, const TypeEnvironment & env, Expression * member );

src/SymTab/Autogen.cc

r221c2de7	r154fdc8
498	498	makeUnionFieldsAssignment( srcParam, dstParam, back_inserter( funcDecl->get_statements()->get_kids() ) );
499	499	if ( returnVal ) {
500		if ( isDynamicLayout ) makeUnionFieldsAssignment( srcParam, returnVal, back_inserter( funcDecl->get_statements()->get_kids() ) );
501		else funcDecl->get_statements()->get_kids().push_back( new ReturnStmt( noLabels, new VariableExpr( srcParam ) ) );
	500	funcDecl->get_statements()->get_kids().push_back( new ReturnStmt( noLabels, new VariableExpr( srcParam ) ) );
502	501	}
503	502	}

src/SymTab/Validate.cc

-                      r221c2de7
+                      r154fdc8
         };
+        class ArrayLength : public Visitor {
+        public:
+                /// for array types without an explicit length, compute the length and store it so that it
+                /// is known to the rest of the phases. For example,
+                ///   int x[] = { 1, 2, 3 };
+                ///   int y[][2] = { { 1, 2, 3 }, { 1, 2, 3 } };
+                /// here x and y are known at compile-time to have length 3, so change this into
+                ///   int x[3] = { 1, 2, 3 };
+                ///   int y[3][2] = { { 1, 2, 3 }, { 1, 2, 3 } };
+                static void computeLength( std::list< Declaration * > & translationUnit );
+                virtual void visit( ObjectDecl * objDecl );
+        };
         class CompoundLiteral final : public GenPoly::DeclMutator {
                 Type::StorageClasses storageClasses;
 …
                 acceptAll( translationUnit, pass3 );
                 VerifyCtorDtorAssign::verify( translationUnit );
+                ArrayLength::computeLength( translationUnit );
+        }
 …
+                }
+        }
+        void ArrayLength::computeLength( std::list< Declaration * > & translationUnit ) {
+                ArrayLength len;
+                acceptAll( translationUnit, len );
+        }
+        void ArrayLength::visit( ObjectDecl * objDecl ) {
+                if ( ArrayType * at = dynamic_cast< ArrayType * >( objDecl->get_type() ) ) {
+                        if ( at->get_dimension() != nullptr ) return;
+                        if ( ListInit * init = dynamic_cast< ListInit * >( objDecl->get_init() ) ) {
+                                at->set_dimension( new ConstantExpr( Constant::from_ulong( init->get_initializers().size() ) ) );
+                        }
+                }
+        }
 } // namespace SymTab

src/SynTree/Expression.cc

r221c2de7	r154fdc8
339	339	return TypeSubstitution( aggInst->get_baseParameters()->begin(), aggInst->get_baseParameters()->end(), aggInst->get_parameters().begin() );
340	340	} else {
341		assertf( false, "makeSub expects struct or union type for aggregate" );
	341	assertf( false, "makeSub expects struct or union type for aggregate, but got: %s", toString( t ).c_str() );
342	342	}
343	343	}

src/libcfa/Makefile.am

r221c2de7	r154fdc8
41	41	CC = ${abs_top_srcdir}/src/driver/cfa
42	42
43		headers = limits stdlib math iostream fstream iterator rational assert containers/vector
	43	headers = limits stdlib math iostream fstream iterator rational assert containers/pair containers/vector
44	44
45	45	# not all platforms support concurrency, add option do disable it

src/libcfa/Makefile.in

-                      r221c2de7
+                      r154fdc8
 am__libcfa_d_a_SOURCES_DIST = libcfa-prelude.c interpose.c \
         libhdr/libdebug.c limits.c stdlib.c math.c iostream.c \
+        fstream.c iterator.c rational.c assert.c containers/vector.c \
+        concurrency/coroutine.c concurrency/thread.c \
+        concurrency/kernel.c concurrency/monitor.c \
+        concurrency/CtxSwitch-@MACHINE_TYPE@.S concurrency/invoke.c
+        fstream.c iterator.c rational.c assert.c containers/pair.c \
+        containers/vector.c concurrency/coroutine.c \
+        concurrency/thread.c concurrency/kernel.c \
+        concurrency/monitor.c concurrency/CtxSwitch-@MACHINE_TYPE@.S \
+        concurrency/invoke.c
 am__dirstamp = $(am__leading_dot)dirstamp
 @BUILD_CONCURRENCY_TRUE@am__objects_1 = concurrency/libcfa_d_a-coroutine.$(OBJEXT) \
 …
         libcfa_d_a-iterator.$(OBJEXT) libcfa_d_a-rational.$(OBJEXT) \
         libcfa_d_a-assert.$(OBJEXT) \
+        containers/libcfa_d_a-pair.$(OBJEXT) \
         containers/libcfa_d_a-vector.$(OBJEXT) $(am__objects_1)
 @BUILD_CONCURRENCY_TRUE@am__objects_3 = concurrency/CtxSwitch-@MACHINE_TYPE@.$(OBJEXT) \
 …
 am__libcfa_a_SOURCES_DIST = libcfa-prelude.c interpose.c \
         libhdr/libdebug.c limits.c stdlib.c math.c iostream.c \
+        fstream.c iterator.c rational.c assert.c containers/vector.c \
+        concurrency/coroutine.c concurrency/thread.c \
+        concurrency/kernel.c concurrency/monitor.c \
+        concurrency/CtxSwitch-@MACHINE_TYPE@.S concurrency/invoke.c
+        fstream.c iterator.c rational.c assert.c containers/pair.c \
+        containers/vector.c concurrency/coroutine.c \
+        concurrency/thread.c concurrency/kernel.c \
+        concurrency/monitor.c concurrency/CtxSwitch-@MACHINE_TYPE@.S \
+        concurrency/invoke.c
 @BUILD_CONCURRENCY_TRUE@am__objects_5 = concurrency/libcfa_a-coroutine.$(OBJEXT) \
 @BUILD_CONCURRENCY_TRUE@        concurrency/libcfa_a-thread.$(OBJEXT) \
 …
         libcfa_a-fstream.$(OBJEXT) libcfa_a-iterator.$(OBJEXT) \
         libcfa_a-rational.$(OBJEXT) libcfa_a-assert.$(OBJEXT) \
+        containers/libcfa_a-pair.$(OBJEXT) \
         containers/libcfa_a-vector.$(OBJEXT) $(am__objects_5)
 @BUILD_CONCURRENCY_TRUE@am__objects_7 = concurrency/CtxSwitch-@MACHINE_TYPE@.$(OBJEXT) \
 …
         $(am__libcfa_a_SOURCES_DIST)
 am__nobase_cfa_include_HEADERS_DIST = limits stdlib math iostream \
         fstream iterator rational assert containers/vector \
         concurrency/coroutine concurrency/thread concurrency/kernel \
         concurrency/monitor ${shell echo stdhdr/*} \
+        fstream iterator rational assert containers/pair \
+        containers/vector concurrency/coroutine concurrency/thread \
+        concurrency/kernel concurrency/monitor ${shell echo stdhdr/*} \
         concurrency/invoke.h
 HEADERS = $(nobase_cfa_include_HEADERS)
 …
 AM_CCASFLAGS = @CFA_FLAGS@
 headers = limits stdlib math iostream fstream iterator rational assert \
         containers/vector $(am__append_3)
+        containers/pair containers/vector $(am__append_3)
 libobjs = ${headers:=.o}
 libsrc = libcfa-prelude.c interpose.c libhdr/libdebug.c ${headers:=.c} \
 …
         @$(MKDIR_P) containers/$(DEPDIR)
         @: > containers/$(DEPDIR)/$(am__dirstamp)
+containers/libcfa_d_a-pair.$(OBJEXT): containers/$(am__dirstamp) \
+        containers/$(DEPDIR)/$(am__dirstamp)
 containers/libcfa_d_a-vector.$(OBJEXT): containers/$(am__dirstamp) \
         containers/$(DEPDIR)/$(am__dirstamp)
 …
 libhdr/libcfa_a-libdebug.$(OBJEXT): libhdr/$(am__dirstamp) \
         libhdr/$(DEPDIR)/$(am__dirstamp)
+containers/libcfa_a-pair.$(OBJEXT): containers/$(am__dirstamp) \
+        containers/$(DEPDIR)/$(am__dirstamp)
 containers/libcfa_a-vector.$(OBJEXT): containers/$(am__dirstamp) \
         containers/$(DEPDIR)/$(am__dirstamp)
 …
         -rm -f concurrency/libcfa_d_a-monitor.$(OBJEXT)
         -rm -f concurrency/libcfa_d_a-thread.$(OBJEXT)
+        -rm -f containers/libcfa_a-pair.$(OBJEXT)
         -rm -f containers/libcfa_a-vector.$(OBJEXT)
+        -rm -f containers/libcfa_d_a-pair.$(OBJEXT)
         -rm -f containers/libcfa_d_a-vector.$(OBJEXT)
         -rm -f libhdr/libcfa_a-libdebug.$(OBJEXT)
 …
 @AMDEP_TRUE@@am__include@ @am__quote@concurrency/$(DEPDIR)/libcfa_d_a-monitor.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@concurrency/$(DEPDIR)/libcfa_d_a-thread.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@containers/$(DEPDIR)/libcfa_a-pair.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@containers/$(DEPDIR)/libcfa_a-vector.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@containers/$(DEPDIR)/libcfa_d_a-pair.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@containers/$(DEPDIR)/libcfa_d_a-vector.Po@am__quote@
 @AMDEP_TRUE@@am__include@ @am__quote@libhdr/$(DEPDIR)/libcfa_a-libdebug.Po@am__quote@
 …
 @am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -c -o libcfa_d_a-assert.obj `if test -f 'assert.c'; then $(CYGPATH_W) 'assert.c'; else $(CYGPATH_W) '$(srcdir)/assert.c'; fi`
+containers/libcfa_d_a-pair.o: containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -MT containers/libcfa_d_a-pair.o -MD -MP -MF containers/$(DEPDIR)/libcfa_d_a-pair.Tpo -c -o containers/libcfa_d_a-pair.o `test -f 'containers/pair.c' || echo '$(srcdir)/'`containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_at)$(am__mv) containers/$(DEPDIR)/libcfa_d_a-pair.Tpo containers/$(DEPDIR)/libcfa_d_a-pair.Po
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       $(AM_V_CC)source='containers/pair.c' object='containers/libcfa_d_a-pair.o' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -c -o containers/libcfa_d_a-pair.o `test -f 'containers/pair.c' || echo '$(srcdir)/'`containers/pair.c
+containers/libcfa_d_a-pair.obj: containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -MT containers/libcfa_d_a-pair.obj -MD -MP -MF containers/$(DEPDIR)/libcfa_d_a-pair.Tpo -c -o containers/libcfa_d_a-pair.obj `if test -f 'containers/pair.c'; then $(CYGPATH_W) 'containers/pair.c'; else $(CYGPATH_W) '$(srcdir)/containers/pair.c'; fi`
+@am__fastdepCC_TRUE@    $(AM_V_at)$(am__mv) containers/$(DEPDIR)/libcfa_d_a-pair.Tpo containers/$(DEPDIR)/libcfa_d_a-pair.Po
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       $(AM_V_CC)source='containers/pair.c' object='containers/libcfa_d_a-pair.obj' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -c -o containers/libcfa_d_a-pair.obj `if test -f 'containers/pair.c'; then $(CYGPATH_W) 'containers/pair.c'; else $(CYGPATH_W) '$(srcdir)/containers/pair.c'; fi`
 containers/libcfa_d_a-vector.o: containers/vector.c
 @am__fastdepCC_TRUE@    $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_d_a_CFLAGS) $(CFLAGS) -MT containers/libcfa_d_a-vector.o -MD -MP -MF containers/$(DEPDIR)/libcfa_d_a-vector.Tpo -c -o containers/libcfa_d_a-vector.o `test -f 'containers/vector.c' || echo '$(srcdir)/'`containers/vector.c
 …
 @AMDEP_TRUE@@am__fastdepCC_FALSE@       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
 @am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_a_CFLAGS) $(CFLAGS) -c -o libcfa_a-assert.obj `if test -f 'assert.c'; then $(CYGPATH_W) 'assert.c'; else $(CYGPATH_W) '$(srcdir)/assert.c'; fi`
+containers/libcfa_a-pair.o: containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_a_CFLAGS) $(CFLAGS) -MT containers/libcfa_a-pair.o -MD -MP -MF containers/$(DEPDIR)/libcfa_a-pair.Tpo -c -o containers/libcfa_a-pair.o `test -f 'containers/pair.c' || echo '$(srcdir)/'`containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_at)$(am__mv) containers/$(DEPDIR)/libcfa_a-pair.Tpo containers/$(DEPDIR)/libcfa_a-pair.Po
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       $(AM_V_CC)source='containers/pair.c' object='containers/libcfa_a-pair.o' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_a_CFLAGS) $(CFLAGS) -c -o containers/libcfa_a-pair.o `test -f 'containers/pair.c' || echo '$(srcdir)/'`containers/pair.c
+containers/libcfa_a-pair.obj: containers/pair.c
+@am__fastdepCC_TRUE@    $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_a_CFLAGS) $(CFLAGS) -MT containers/libcfa_a-pair.obj -MD -MP -MF containers/$(DEPDIR)/libcfa_a-pair.Tpo -c -o containers/libcfa_a-pair.obj `if test -f 'containers/pair.c'; then $(CYGPATH_W) 'containers/pair.c'; else $(CYGPATH_W) '$(srcdir)/containers/pair.c'; fi`
+@am__fastdepCC_TRUE@    $(AM_V_at)$(am__mv) containers/$(DEPDIR)/libcfa_a-pair.Tpo containers/$(DEPDIR)/libcfa_a-pair.Po
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       $(AM_V_CC)source='containers/pair.c' object='containers/libcfa_a-pair.obj' libtool=no @AMDEPBACKSLASH@
+@AMDEP_TRUE@@am__fastdepCC_FALSE@       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+@am__fastdepCC_FALSE@   $(AM_V_CC@am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libcfa_a_CFLAGS) $(CFLAGS) -c -o containers/libcfa_a-pair.obj `if test -f 'containers/pair.c'; then $(CYGPATH_W) 'containers/pair.c'; else $(CYGPATH_W) '$(srcdir)/containers/pair.c'; fi`
 containers/libcfa_a-vector.o: containers/vector.c

src/libcfa/stdlib.c

-                      r221c2de7
+                      r154fdc8
 // Created On       : Thu Jan 28 17:10:29 2016
 // Last Modified By : Peter A. Buhr
 // Last Modified On : Sat Apr  1 18:31:26 2017
 // Update Count     : 181
+// Last Modified On : Sun Apr 16 10:41:05 2017
+// Update Count     : 189
 //
 …
 } // posix_memalign
 forall( dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); } )
+forall( dtype T, ttype Params | sized(T) | { void ?{}( T *, Params ); } )
 T * new( Params p ) {
         return ((T*)malloc()){ p };
+        return ((T *)malloc()){ p };
+}
 …
 forall( otype T | { int ?<?( T, T ); } )
 unsigned int bsearch( T key, const T * arr, size_t dimension ) {
+        int comp( const void * t1, const void * t2 ) { return *(T *)t1 < *(T *)t2 ? -1 : *(T *)t2 < *(T *)t1 ? 1 : 0; }
+        T *result = (T *)bsearch( &key, arr, dimension, sizeof(T), comp );
+        T *result = bsearch( key, arr, dimension );
         return result ? result - arr : dimension;                       // pointer subtraction includes sizeof(T)
 } // bsearch

src/prelude/prelude.cf

-                      r221c2de7
+                      r154fdc8
 signed int ?<?( _Bool, _Bool ),                                         ?<=?( _Bool, _Bool ),
            ?>?( _Bool, _Bool ),                                         ?>=?( _Bool, _Bool );
+signed int ?<?( char, char ),                           ?<=?( char, char ),
+           ?>?( char, char ),                           ?>=?( char, char );
+signed int ?<?( signed char, signed char ),                             ?<=?( signed char, signed char ),
+           ?>?( signed char, signed char ),                             ?>=?( signed char, signed char );
 signed int ?<?( unsigned char, unsigned char ),                         ?<=?( unsigned char, unsigned char ),
            ?>?( unsigned char, unsigned char ),                         ?>=?( unsigned char, unsigned char );
+signed int ?<?( signed short, signed short ),                           ?<=?( signed short, signed short ),
+           ?>?( signed short, signed short ),                           ?>=?( signed short, signed short );
+signed int ?<?( unsigned short, unsigned short ),                       ?<=?( unsigned short, unsigned short ),
+           ?>?( unsigned short, unsigned short ),                               ?>=?( unsigned short, unsigned short );
 signed int ?<?( signed int, signed int ),                               ?<=?( signed int, signed int ),
            ?>?( signed int, signed int ),                               ?>=?( signed int, signed int );
 …
 signed int ?==?( _Bool, _Bool ),                                                        ?!=?( _Bool, _Bool );
+signed int ?==?( char, char ),                                                          ?!=?( char, char );
+signed int ?==?( signed char, signed char ),                            ?!=?( signed char, signed char );
+signed int ?==?( unsigned char, unsigned char ),                        ?!=?( unsigned char, unsigned char );
+signed int ?==?( signed short, signed short ),                          ?!=?( signed short, signed short );
+signed int ?==?( unsigned short, unsigned short ),                      ?!=?( unsigned short, unsigned short );
 signed int ?==?( signed int, signed int ),                                      ?!=?( signed int, signed int );
 signed int ?==?( unsigned int, unsigned int ),                                  ?!=?( unsigned int, unsigned int );

Context Navigation

Legend:

Download in other formats: