Index: doc/LaTeXmacros/common.tex =================================================================== --- doc/LaTeXmacros/common.tex (revision 03bb816f896612125c8f1acd78ef46603e99f236) +++ doc/LaTeXmacros/common.tex (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -11,6 +11,6 @@ %% Created On : Sat Apr 9 10:06:17 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Fri Feb 10 11:32:36 2017 -%% Update Count : 249 +%% Last Modified On : Wed Apr 5 23:19:42 2017 +%% Update Count : 255 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -256,5 +256,5 @@ }% -\newcommand{\CFADefaultStyle}{% +\newcommand{\CFADefaults}{% \lstset{ language=CFA, @@ -267,5 +267,5 @@ escapechar=§, % LaTeX escape in CFA code §...§ (section symbol), emacs: C-q M-' mathescape=true, % LaTeX math escape in CFA code $...$ -%keepspaces=true, % +keepspaces=true, % showstringspaces=false, % do not show spaces with cup showlines=true, % show blank lines at end of code @@ -281,7 +281,15 @@ moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^ }% lstset +}% CFADefaults +\newcommand{\CFAStyle}{% +\CFADefaults % inline code ©...© (copyright symbol) emacs: C-q M-) \lstMakeShortInline© % single-character for \lstinline -}%CFADefaultStyle +}% CFAStyle + +\lstnewenvironment{cfa}[1][] +{\CFADefaults\lstset{#1}} +{} + % Local Variables: % Index: doc/bibliography/cfa.bib =================================================================== --- doc/bibliography/cfa.bib (revision 03bb816f896612125c8f1acd78ef46603e99f236) +++ doc/bibliography/cfa.bib (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -3059,4 +3059,14 @@ } +@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} +} + @article{Choi91, keywords = {contra-variance, functions}, @@ -3635,8 +3645,8 @@ contributer = {pabuhr@plg}, author = {James Gosling and Bill Joy and Guy Steele and Gilad Bracha and Alex Buckley}, - title = {The {Java} Language Specification}, + title = {{Java} Language Specification}, publisher = {Oracle}, year = 2015, - edition = {Java SE 8}, + edition = {Java SE8}, } @@ -4553,4 +4563,24 @@ } +@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 +} + +@online{xcode7, + keywords = {objective-c}, + contributor = {a3moss@uwaterloo.ca}, + author = {{Apple Computer Inc.}}, + title = {{Xcode} 7 Release Notes}, + year = 2015, + note = {\href{https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html}{https://developer.apple.com/\-library/\-content/\-documentation/\-Xcode/\-Conceptual/\-RN-Xcode-Archive/\-Chapters/\-xc7\_release\_notes.html}}, + urldate = {2017-04-04} +} + @book{Beta, keywords = {Beta, object oriented, concurrency, exceptions}, @@ -4839,5 +4869,7 @@ journal = {Computer Languages}, year = 1987, - volume = 12, number = {3/4}, pages = {163-172}, + volume = 12, + number = {3/4}, + pages = {163-172}, abstract = { Packages in the Ada language provide a mechanism for extending the @@ -5851,5 +5883,5 @@ organization= {The Rust Project Developers}, year = 2015, - note = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang.org/\-reference.html}}, + note = {\href{https://doc.rust-lang.org/reference.html}{https://\-doc.rust-lang\-.org/\-reference.html}}, } @@ -6549,4 +6581,11 @@ } +@online{TIOBE, + contributer = {pabuhr@plg}, + author = {{TIOBE Index}}, + year = {March 2017}, + url = {http://www.tiobe.com/tiobe_index}, +} + @misc{Bumbulis90, keywords = {parameter inference, ForceN}, @@ -6555,5 +6594,6 @@ title = {Towards Making Signatures First-Class}, howpublished= {personal communication}, - month = sep, year = 1990, + month = sep, + year = 1990, note = {} } @@ -6861,4 +6901,14 @@ } +@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} +} + @inproceedings{Amdahl67, author = {Gene M. Amdahl}, Index: doc/generic_types/acmart.cls =================================================================== --- doc/generic_types/acmart.cls (revision 03bb816f896612125c8f1acd78ef46603e99f236) +++ doc/generic_types/acmart.cls (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -354,5 +354,5 @@ \let\@footnotemark@nolink\@footnotemark \let\@footnotetext@nolink\@footnotetext -\RequirePackage[bookmarksnumbered]{hyperref} +\RequirePackage[bookmarksnumbered,breaklinks]{hyperref} \urlstyle{rm} \ifcase\ACM@format@nr Index: doc/generic_types/evaluation/.gitignore =================================================================== --- doc/generic_types/evaluation/.gitignore (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/.gitignore (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,8 @@ +c-bench +cpp-bench +cfa-bench +c2-bench +cpp2-bench +cfa2-bench +*.o +*.d Index: doc/generic_types/evaluation/Makefile =================================================================== --- doc/generic_types/evaluation/Makefile (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/Makefile (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,101 @@ +CFA = my-cfa +DEPFLAGS = -MMD -MP + +.PHONY: all clean distclean bench + +all: c-bench cpp-bench cfa-bench c2-bench cpp2-bench cfa2-bench + +# rewrite object generation to auto-determine deps +COMPILE.c = $(CC) $(DEPFLAGS) $(CFLAGS) $(CPPFLAGS) +COMPILE.cpp = $(CXX) $(DEPFLAGS) $(CXXFLAGS) $(CPPFLAGS) +COMPILE.cfa = $(CFA) $(DEPFLAGS) $(CFLAGS) $(CPPFLAGS) + +c-%.o : c-%.c +c-%.o : c-%.c c-%.d + $(COMPILE.c) -O0 $(OUTPUT_OPTION) -c $< + +cpp-%.o : cpp-%.cpp +cpp-%.o : cpp-%.cpp cpp-%.d + $(COMPILE.cpp) -O0 $(OUTPUT_OPTION) -c $< + +cfa-%.o : cfa-%.c +cfa-%.o : cfa-%.c cfa-%.d + $(COMPILE.cfa) -O0 $(OUTPUT_OPTION) -c $< + +c2-%.o : c-%.c +c2-%.o : c-%.c c-%.d + $(COMPILE.c) -O2 $(OUTPUT_OPTION) -c $< + +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)) + +c-bench: c-bench.c c-bench.d $(COBJS) + $(COMPILE.c) -O0 -o $@ $< $(COBJS) $(LDFLAGS) + +cpp-bench: cpp-bench.cpp cpp-bench.d $(CPPOBJS) + $(COMPILE.cpp) -O0 -o $@ $< $(CPPOBJS) $(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) + +clean: + -rm $(COBJS) c-bench + -rm $(CPPOBJS) cpp-bench + -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 $(CFAOBJS:.o=.d) cfa-bench.d + +bench: c-bench cpp-bench cfa-bench c2-bench cpp2-bench cfa2-bench + @echo '## C ##' + @./c-bench + @echo '## C++ ##' + @./cpp-bench + @echo '## Cforall ##' + @./cfa-bench + @echo '## C -O2 ##' + @./c2-bench + @echo '## C++ -O2 ##' + @./cpp2-bench + @echo '## Cforall -O2 ##' + @./cfa2-bench + +# so make doesn't fail without dependency files +%.d: ; + +# so make won't delete dependency files +.PRECIOUS: %.d + +# include dependency files +-include: $(COBJS:.o=.d) +-include: $(CPPOBJS:.o=.d) +-include: $(CFAOBJS:.o=.d) +-include: c-bench.d +-include: cpp-bench.d +-include: cfa-bench.d Index: doc/generic_types/evaluation/bench.h =================================================================== --- doc/generic_types/evaluation/bench.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/bench.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,18 @@ +#include +#include + +#define N 200000000 + +long ms_between(clock_t start, clock_t end) { + return (end - start) / (CLOCKS_PER_SEC / 1000); +} + +#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 } ) Index: doc/generic_types/evaluation/c-bench.c =================================================================== --- doc/generic_types/evaluation/c-bench.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/c-bench.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,17 @@ +#include +#include "bench.h" +#include "c-stack.h" + +int main(int argc, char** argv) { + srand(20171025); + + struct stack s = new_stack(); + + REPEAT_TIMED( "push_int", + int* x = malloc(sizeof(int)); + *x = rand(); + push_stack(&s, x); + ) + + clear_stack(&s); +} Index: doc/generic_types/evaluation/c-stack.c =================================================================== --- doc/generic_types/evaluation/c-stack.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/c-stack.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,39 @@ +#include +#include "c-stack.h" + +struct stack_node { + void* value; + struct stack_node* next; +}; + +struct stack new_stack() { + return (struct stack){ NULL }; +} + +void clear_stack(struct stack* s) { + struct stack_node* next = s->head; + while ( next ) { + struct stack_node* crnt = next; + next = crnt->next; + free(crnt->value); + free(crnt); + } +} + +_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; +} Index: doc/generic_types/evaluation/c-stack.h =================================================================== --- doc/generic_types/evaluation/c-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/c-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,15 @@ +struct stack_node; + +struct stack { + struct stack_node* head; +}; + +struct stack new_stack(); + +void clear_stack(struct stack* s); + +_Bool stack_empty(const struct stack* s); + +void push_stack(struct stack* s, void* value); + +void* pop_stack(struct stack* s); Index: doc/generic_types/evaluation/cfa-bench.c =================================================================== --- doc/generic_types/evaluation/cfa-bench.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/cfa-bench.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,13 @@ +#include +#include "bench.h" +#include "cfa-stack.h" + +int main(int argc, char** argv) { + srand(20171025); + + stack(int) s; + + REPEAT_TIMED( "push_int", + push( &s, rand() ); + ) +} Index: doc/generic_types/evaluation/cfa-stack.c =================================================================== --- doc/generic_types/evaluation/cfa-stack.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/cfa-stack.c (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,36 @@ +#include +#include "cfa-stack.h" + +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_node(T)* next = s->head; + while ( next ) { + stack_node(T)* crnt = next; + next = crnt->next; + delete(crnt); + } +} + +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; +} Index: doc/generic_types/evaluation/cfa-stack.h =================================================================== --- doc/generic_types/evaluation/cfa-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/cfa-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,15 @@ +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); + +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); Index: doc/generic_types/evaluation/cpp-bench.cpp =================================================================== --- doc/generic_types/evaluation/cpp-bench.cpp (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/cpp-bench.cpp (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,13 @@ +#include +#include "bench.h" +#include "cpp-stack.h" + +int main(int argc, char** argv) { + srand(20171025); + + stack s; + + REPEAT_TIMED( "push_int", + s.push( rand() ); + ) +} Index: doc/generic_types/evaluation/cpp-stack.h =================================================================== --- doc/generic_types/evaluation/cpp-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) +++ doc/generic_types/evaluation/cpp-stack.h (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -0,0 +1,40 @@ +#include + +template class stack { + struct node { + T value; + node* next; + + node( T&& v, node* n ) : value(std::move(v)), next(n) {} + }; + + node* head; + +public: + stack() : head(nullptr) {} + + ~stack() { + node* next = head; + while ( next ) { + node* crnt = next; + next = crnt->next; + delete crnt; + } + } + + bool empty() const { + return head == nullptr; + } + + void push(T&& value) { + head = new node{ std::move(value), head }; + } + + T pop() { + node* n = head; + head = n->next; + T x = std::move(n->value); + delete n; + return x; + } +}; Index: doc/generic_types/generic_types.tex =================================================================== --- doc/generic_types/generic_types.tex (revision 03bb816f896612125c8f1acd78ef46603e99f236) +++ doc/generic_types/generic_types.tex (revision 3db60cbd3e343adbc70e28a85a8d87b7712f6c83) @@ -28,6 +28,8 @@ \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{\TODO}[1]{\textbf{TODO}: #1} % TODO included +\newcommand{\CS}{C\raisebox{-0.7ex}{\Large$^\sharp$}\xspace} +\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} @@ -49,5 +51,5 @@ stringstyle=\tt, % use typewriter font tabsize=4, % 4 space tabbing -xleftmargin=\parindent, % indent code to paragraph indentation +xleftmargin=\parindentlnth, % indent code to paragraph indentation %mathescape=true, % LaTeX math escape in CFA code $...$ escapechar=\$, % LaTeX escape in CFA code @@ -90,6 +92,6 @@ } -\terms{generic, tuple, types} -\keywords{generic types, tuple types, polymorphic functions, C, Cforall} +\terms{generic, tuple, variadic, types} +\keywords{generic types, tuple types, variadic types, polymorphic functions, C, Cforall} \begin{CCSXML} @@ -118,5 +120,5 @@ \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 only two \CFA extensions, generic and tuple types, and how they are implemented in accordance with these principles. +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} @@ -124,16 +126,35 @@ \maketitle -\section{Introduction \& Background} - -\CFA\footnote{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. Four key design goals were set out in the original design of \CFA~\citep{Bilson03}: -\begin{enumerate} -\item The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler. -\item Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler. -\item \CFA code must be at least as portable as standard C code. -\item Extensions introduced by \CFA must be translated in the most efficient way possible. -\end{enumerate} -These goals ensure existing C code-bases can be converted to \CFA incrementally and with minimal effort, and C programmers can productively generate \CFA code without training beyond the features they wish to employ. 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. - -\CFA has been previously extended with polymorphic functions and name overloading (including operator overloading) by \citet{Bilson03}, and deterministically-executed constructors and destructors by \citet{Schluntz17}. This paper describes how generic and tuple types are designed and implemented in \CFA in accordance with both the backward compatibility goals and existing features described above. + +\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@ +\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 +\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. +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: +(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. @@ -141,43 +162,23 @@ \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; such functions are written using a @forall@ clause (which gives 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 where functions are 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 object-type (or ``@otype@''). The type variable @T@ is transformed into a set of additional implicit parameters to @identity@ that encode 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 @dtype T@, where @dtype@ is short for ``data type''. - -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 to be similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA @forall@ functions are compatible with C separate compilation. - -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 instance, @twice@ can be defined using the \CFA syntax for operator overloading: -\begin{lstlisting} -forall( otype T | { T `?`+`?`(T, T); } ) $\C{// ? denotes operands}$ - T twice( T x ) { return x + x; } $\C{// (2)}$ +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: +\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 an addition operator defined. The translator accomplishes this polymorphism by creating a wrapper function for calling @+@ with @T@ bound to @double@, then providing this function to the first call of @twice@. It then has the option of using the same @twice@ again 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 in its type analysis. The first approach has a late conversion from integer to floating-point on the final assignment, while the second has an eager conversion to integer. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach. - -Monomorphic specializations of polymorphic functions can satisfy polymorphic type-assertions. -% \begin{lstlisting} -% forall(otype T `| { T twice(T); }`) $\C{// type assertion}$ -% T four_times(T x) { return twice( twice(x) ); } -% double twice(double d) { return d * 2.0; } $\C{// (1)}$ -% double magic = four_times(10.5); $\C{// T bound to double, uses (1) to satisfy type assertion}$ -% \end{lstlisting} -\begin{lstlisting} -forall( otype T `| { int ?` y; } $\C{// override behaviour}$ +\CFA has replacement libraries condensing hundreds of existing C functions into tens of \CFA overloaded functions, all without rewriting the actual computations. +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) ); } +int * ip = malloc(); $\C{// select type and size from left-hand side}$ +double * dp = malloc(); +struct S {...} * sp = malloc(); +\end{lstlisting} +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: +\begin{lstlisting} +forall( otype T | { int ?` y; } $\C{// locally override behaviour}$ qsort( vals, size ); $\C{// descending sort}$ } \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 new local environments to maximize reuse of existing functions and types. - -Finally, variables may be overloaded: +Hence, programmers can easily form a local environments, adding and modifying appropriate functions, to maximize reuse of other existing functions and types. + +Finally, \CFA allows variable overloading: \lstDeleteShortInline@ \par\smallskip @@ -233,93 +244,83 @@ \smallskip\par\noindent Hence, 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, +\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. +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. + \subsection{Traits} -\CFA provides \emph{traits} to name a group of type assertions: -% \begin{lstlisting} -% trait has_magnitude(otype T) { -% _Bool ? int main( void ) { @@ -160,5 +160,5 @@ ®sout | x | y | z | endl;® } -\end{lstlisting} +\end{cfa} & \begin{lstlisting} @@ -245,9 +245,9 @@ For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©. Whereas, \CFA wraps each of these routines into ones with the common name ©abs©: -\begin{lstlisting} +\begin{cfa} char abs( char ); -extern "C" { +®extern "C" {® int abs( int ); §\C{// use default C routine for int}§ -} // extern "C" +®}® // extern "C" long int abs( long int ); long long int abs( long long int ); @@ -258,5 +258,5 @@ double _Complex abs( double _Complex ); long double _Complex abs( long double _Complex ); -\end{lstlisting} +\end{cfa} The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©. Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}. @@ -273,7 +273,7 @@ The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg: -\begin{lstlisting} +\begin{cfa} cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ] -\end{lstlisting} +\end{cfa} \CFA programs having the following ©gcc© flags turned on: \begin{description} @@ -352,5 +352,5 @@ These preprocessor variables allow conditional compilation of programs that must work differently in these situations. For example, to toggle between C and \CFA extensions, using the following: -\begin{lstlisting} +\begin{cfa} #ifndef __CFORALL__ #include §\C{// C header file}§ @@ -358,12 +358,12 @@ #include §\C{// \CFA header file}§ #endif -\end{lstlisting} +\end{cfa} which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}. -\section{Underscores in Constants} +\section{Constants Underscores} Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg: -\begin{lstlisting} +\begin{cfa} 2®_®147®_®483®_®648; §\C{// decimal constant}§ 56_ul; §\C{// decimal unsigned long constant}§ @@ -376,5 +376,5 @@ 0x_1.ffff_ffff_p_128_l; §\C{// hexadecimal floating point long constant}§ L_"\x_ff_ee"; §\C{// wide character constant}§ -\end{lstlisting} +\end{cfa} The rules for placement of underscores is as follows: \begin{enumerate} @@ -396,4 +396,30 @@ +\section{Backquote Identifiers} +\label{s:BackquoteIdentifiers} + +\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism: +\begin{cfa} +int ®`®otype®`® = 3; §\C{// make keyword an identifier}§ +double ®`®choose®`® = 3.5; +\end{cfa} +Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name. +Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©: +\begin{cfa} +// include file uses the CFA keyword "otype". +#if ! defined( otype ) §\C{// nesting ?}§ +#define otype `otype` +#define __CFA_BFD_H__ +#endif // ! otype + +#include_next §\C{// must have internal check for multiple expansion}§ + +#if defined( otype ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§ +#undef otype +#undef __CFA_BFD_H__ +#endif // otype && __CFA_BFD_H__ +\end{cfa} + + \section{Declarations} \label{s:Declarations} @@ -403,7 +429,7 @@ \begin{quote2} \begin{tabular}{@{}ll@{}} -\begin{lstlisting} +\begin{cfa} int *x[5] -\end{lstlisting} +\end{cfa} & \raisebox{-0.75\totalheight}{\input{Cdecl}} @@ -414,8 +440,8 @@ Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site. For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way: -\begin{lstlisting} +\begin{cfa} int (*f())[5] {...}; §\C{}§ ... (*f())[3] += 1; -\end{lstlisting} +\end{cfa} Essentially, the return type is wrapped around the routine name in successive layers (like an onion). While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. @@ -428,15 +454,15 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ß[5] *ß ®int® x1; ß* [5]ß ®int® x2; ß[* [5] int]ß f®( int p )®; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} ®int® ß*ß x1 ß[5]ß; ®int® ß(*ßx2ß)[5]ß; ßint (*ßf®( int p )®ß)[5]ß; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -448,11 +474,11 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ®*® int x, y; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int ®*®x, ®*®y; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -461,13 +487,13 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ®*® int x; int y; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int ®*®x, y; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -477,5 +503,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} [ 5 ] int z; [ 5 ] * char w; @@ -486,7 +512,7 @@ [ 5 ] * int f2; }; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int z[ 5 ]; char *w[ 5 ]; @@ -497,7 +523,7 @@ int *f2[ 5 ] }; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // array of 5 integers // array of 5 pointers to char @@ -508,5 +534,5 @@ -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -516,18 +542,18 @@ \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} \multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} const * const int x; const * [ 5 ] const int y; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int const * const x; const int (* const y)[ 5 ] -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // const pointer to const integer // const pointer to array of 5 const integers -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -537,18 +563,18 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} extern [ 5 ] int x; static * const int y; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int extern x[ 5 ]; const int static *y; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // externally visible array of 5 integers // internally visible pointer to constant int -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -557,10 +583,10 @@ At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}} \eg: -\begin{lstlisting} +\begin{cfa} x; §\C{// int x}§ *y; §\C{// int *y}§ f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ f( p1, p2 ) {} §\C{// int f( int p1, int p2 ) {}}§ -\end{lstlisting} +\end{cfa} Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. @@ -583,19 +609,19 @@ \begin{quote2} \begin{tabular}{@{}lll@{}} -\begin{lstlisting} +\begin{cfa} int x; x = 3; int y; y = x; -\end{lstlisting} +\end{cfa} & \raisebox{-0.45\totalheight}{\input{pointer1}} & -\begin{lstlisting} +\begin{cfa} int * ®const® x = (int *)100 *x = 3; // implicit dereference int * ®const® y = (int *)104; *y = *x; // implicit dereference -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -606,17 +632,17 @@ \begin{quote2} \begin{tabular}{@{}l|l@{}} -\begin{lstlisting} +\begin{cfa} lda r1,100 // load address of x ld r2,(r1) // load value of x lda r3,104 // load address of y st r2,(r3) // store x into y -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} ld r2,(100) // load value of x st r2,(104) // store x into y -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -629,5 +655,5 @@ \begin{quote2} \begin{tabular}{@{}ll@{}} -\begin{lstlisting} +\begin{cfa} int x, y, ®*® p1, ®*® p2, ®**® p3; p1 = ®&®x; // p1 points to x @@ -635,5 +661,5 @@ p1 = ®&®y; // p1 points to y p3 = &p2; // p3 points to p2 -\end{lstlisting} +\end{cfa} & \raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}} @@ -643,35 +669,35 @@ Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. In many cases, a compiler might be able to infer the meaning: -\begin{lstlisting} +\begin{cfa} p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ -\end{lstlisting} +\end{cfa} because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic: -\begin{lstlisting} +\begin{cfa} p1 = p2; §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§ p1 = p1 + 1; §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§ -\end{lstlisting} +\end{cfa} Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}. In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©. -\begin{lstlisting} +\begin{cfa} p1 = p2; §\C{// pointer address assignment}§ *p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ -\end{lstlisting} +\end{cfa} which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). However, in most other situations, the pointed-to value is requested more often than the pointer address. -\begin{lstlisting} +\begin{cfa} *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15); -\end{lstlisting} +\end{cfa} In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed. It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic: -\begin{lstlisting} +\begin{cfa} p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15); -\end{lstlisting} +\end{cfa} To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©. -\begin{lstlisting} +\begin{cfa} int x, y, ®&® r1, ®&® r2, ®&&® r3; ®&®r1 = &x; §\C{// r1 points to x}§ @@ -680,15 +706,15 @@ ®&&®r3 = ®&®&r2; §\C{// r3 points to r2}§ r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ -\end{lstlisting} +\end{cfa} Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg: -\begin{lstlisting} +\begin{cfa} r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); -\end{lstlisting} +\end{cfa} is rewritten as: -\begin{lstlisting} +\begin{cfa} ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); -\end{lstlisting} +\end{cfa} When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{ The unary ©&© operator yields the address of its operand. @@ -696,13 +722,13 @@ If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}} Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): -\begin{lstlisting} +\begin{cfa} (&®*®)r1 = &x; §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§ -\end{lstlisting} +\end{cfa} Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): -\begin{lstlisting} +\begin{cfa} (&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§ -\end{lstlisting} +\end{cfa} Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. -\begin{lstlisting} +\begin{cfa} int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, &r1 = x, &&r2 = r1, &&&r3 = r2; @@ -714,5 +740,5 @@ &&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ -\end{lstlisting} +\end{cfa} Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance. @@ -724,5 +750,5 @@ As for a pointer, a reference may have qualifiers: -\begin{lstlisting} +\begin{cfa} const int cx = 5; §\C{// cannot change cx;}§ const int & cr = cx; §\C{// cannot change what cr points to}§ @@ -734,9 +760,9 @@ crc = 7; §\C{// error, cannot change cx}§ ®&®crc = &cx; §\C{// error, cannot change crc}§ -\end{lstlisting} +\end{cfa} Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg: -\begin{lstlisting} +\begin{cfa} int & const r = *0; §\C{// where 0 is the int * zero}§ -\end{lstlisting} +\end{cfa} Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented. Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers. @@ -746,13 +772,13 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ®const® * ®const® * const int ccp; ®const® & ®const® & const int ccr; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} const int * ®const® * ®const® ccp; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -762,33 +788,33 @@ There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}). -\begin{lstlisting} +\begin{cfa} int * p = &x; §\C{// both \&x and x are possible interpretations}§ int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ -\end{lstlisting} +\end{cfa} Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression. Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator. -\begin{lstlisting} +\begin{cfa} int & f( int & rp ); §\C{// reference parameter and return}§ z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§ -\end{lstlisting} +\end{cfa} Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©. Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references. When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. -\begin{lstlisting} +\begin{cfa} void f( ®const® int & crp ); void g( ®const® int * cpp ); f( 3 ); g( &3 ); f( x + y ); g( &(x + y) ); -\end{lstlisting} +\end{cfa} Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter. (The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.) \CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed. -\begin{lstlisting} +\begin{cfa} void f( int & rp ); void g( int * pp ); f( 3 ); g( &3 ); §\C{// compiler implicit generates temporaries}§ f( x + y ); g( &(x + y) ); §\C{// compiler implicit generates temporaries}§ -\end{lstlisting} +\end{cfa} Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{ This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.} @@ -796,5 +822,5 @@ While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave). -\begin{lstlisting} +\begin{cfa} void f( int p ) {...} void (*fp)( int ) = &f; §\C{// pointer initialization}§ @@ -802,41 +828,15 @@ (*fp)(3); §\C{// pointer invocation}§ fp(3); §\C{// reference invocation}§ -\end{lstlisting} +\end{cfa} A routine variable is best described by a ©const© reference: -\begin{lstlisting} +\begin{cfa} const void (&fp)( int ) = f; fp( 3 ); fp = ... §\C{// error, cannot change code}§ &fp = ...; §\C{// changing routine reference}§ -\end{lstlisting} +\end{cfa} because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{ Dynamic code rewriting is possible but only in special circumstances.} \CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them. - - -\section{Backquote Identifiers} -\label{s:BackquoteIdentifiers} - -\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism: -\begin{lstlisting} -int `otype` = 3; // make keyword an identifier -double `choose` = 3.5; -\end{lstlisting} -Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name. -Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©: -\begin{lstlisting} -// include file uses the CFA keyword "otype". -#if ! defined( otype ) // nesting ? -#define otype `otype` -#define __CFA_BFD_H__ -#endif // ! otype - -#include_next // must have internal check for multiple expansion - -#if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set -#undef otype -#undef __CFA_BFD_H__ -#endif // otype && __CFA_BFD_H__ -\end{lstlisting} @@ -847,13 +847,13 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} y = (®* int®)x; i = sizeof(®[ 5 ] * int®); -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} y = (®int *®)x; i = sizeof(®int *[ 5 ]®); -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -864,9 +864,9 @@ \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax. The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg: -\begin{lstlisting} +\begin{cfa} ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) { §\emph{routine body}§ } -\end{lstlisting} +\end{cfa} where routine ©f© has three output (return values) and three input parameters. Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications. @@ -876,31 +876,31 @@ The value of each local return variable is automatically returned at routine termination. Declaration qualifiers can only appear at the start of a routine definition, \eg: -\begin{lstlisting} +\begin{cfa} ®extern® [ int x ] g( int y ) {§\,§} -\end{lstlisting} +\end{cfa} Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified; in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in: -\begin{lstlisting} +\begin{cfa} [§\,§] g(); §\C{// no input or output parameters}§ [ void ] g( void ); §\C{// no input or output parameters}§ -\end{lstlisting} +\end{cfa} Routine f is called as follows: -\begin{lstlisting} +\begin{cfa} [ i, j, ch ] = f( 3, 'a', ch ); -\end{lstlisting} +\end{cfa} The list of return values from f and the grouping on the left-hand side of the assignment is called a \newterm{return list} and discussed in Section 12. \CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity: -\begin{lstlisting} +\begin{cfa} int (*f(x))[ 5 ] int x; {} -\end{lstlisting} +\end{cfa} The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers. Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string. As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity: -\begin{lstlisting} +\begin{cfa} typedef int foo; int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§ -\end{lstlisting} +\end{cfa} The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo. The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name. @@ -908,14 +908,14 @@ C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg: -\begin{lstlisting} +\begin{cfa} [ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§ [ * int, int * ] f( int ); §\C{// returns 2 pointers to integers, accepts an integer}§ -\end{lstlisting} +\end{cfa} The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in: -\begin{lstlisting} +\begin{cfa} #define ptoa( n, d ) int (*n)[ d ] int f( ptoa( p, 5 ) ) ... §\C{// expands to int f( int (*p)[ 5 ] )}§ [ int ] f( ptoa( p, 5 ) ) ... §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§ -\end{lstlisting} +\end{cfa} Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms. @@ -924,5 +924,5 @@ \Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in: -\begin{lstlisting} +\begin{cfa} int f() { int x; @@ -930,9 +930,9 @@ return x; } -\end{lstlisting} +\end{cfa} Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in: \newline \begin{minipage}{\linewidth} -\begin{lstlisting} +\begin{cfa} ®[ int x, int y ]® f() { int z; @@ -940,14 +940,14 @@ ®return;® §\C{// implicitly return x, y}§ } -\end{lstlisting} +\end{cfa} \end{minipage} \newline When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine. As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in: -\begin{lstlisting} +\begin{cfa} [ int x, int y ] f() { ... } §\C{// implicitly return x, y}§ -\end{lstlisting} +\end{cfa} In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered. @@ -957,10 +957,10 @@ The syntax of the new routine prototype declaration follows directly from the new routine definition syntax; as well, parameter names are optional, \eg: -\begin{lstlisting} +\begin{cfa} [ int x ] f (); §\C{// returning int with no parameters}§ [ * int ] g (int y); §\C{// returning pointer to int with int parameter}§ [ ] h (int,char); §\C{// returning no result with int and char parameters}§ [ * int,int ] j (int); §\C{// returning pointer to int and int, with int parameter}§ -\end{lstlisting} +\end{cfa} This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg: @@ -968,18 +968,18 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} [ int ] f(int), g; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} int f(int), g(int); -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg: -\begin{lstlisting} +\begin{cfa} extern [ int ] f (int); static [ int ] g (int); -\end{lstlisting} +\end{cfa} @@ -987,15 +987,15 @@ The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg: -\begin{lstlisting} +\begin{cfa} * [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§ * [ * int ] (int y) gp; §\C{// pointer to routine returning pointer to int with int parameter}§ * [ ] (int,char) hp; §\C{// pointer to routine returning no result with int and char parameters}§ * [ * int,int ] (int) jp; §\C{// pointer to routine returning pointer to int and int, with int parameter}§ -\end{lstlisting} +\end{cfa} While parameter names are optional, \emph{a routine name cannot be specified}; for example, the following is incorrect: -\begin{lstlisting} +\begin{cfa} * [ int x ] f () fp; §\C{// routine name "f" is not allowed}§ -\end{lstlisting} +\end{cfa} @@ -1010,15 +1010,15 @@ provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter. For example, given the routine: -\begin{lstlisting} +\begin{cfa} void p( int x, int y, int z ) {...} -\end{lstlisting} +\end{cfa} a positional call is: -\begin{lstlisting} +\begin{cfa} p( 4, 7, 3 ); -\end{lstlisting} +\end{cfa} whereas a named (keyword) call may be: -\begin{lstlisting} +\begin{cfa} p( z : 3, x : 4, y : 7 ); §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§ -\end{lstlisting} +\end{cfa} Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters. The compiler rewrites a named call into a positional call. @@ -1035,5 +1035,5 @@ Unfortunately, named arguments do not work in C-style programming-languages because a routine prototype is not required to specify parameter names, nor do the names in the prototype have to match with the actual definition. For example, the following routine prototypes and definition are all valid. -\begin{lstlisting} +\begin{cfa} void p( int, int, int ); §\C{// equivalent prototypes}§ void p( int x, int y, int z ); @@ -1041,5 +1041,5 @@ void p( int z, int y, int x ); void p( int q, int r, int s ) {} §\C{// match with this definition}§ -\end{lstlisting} +\end{cfa} Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming. Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports. @@ -1048,5 +1048,5 @@ Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching. For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site: -\begin{lstlisting} +\begin{cfa} int f( int i, int j ); int f( int x, double y ); @@ -1055,9 +1055,9 @@ f( x : 7, y : 8.1 ); §\C{// 2nd f}§ f( 4, 5 ); §\C{// ambiguous call}§ -\end{lstlisting} +\end{cfa} However, named arguments compound routine resolution in conjunction with conversions: -\begin{lstlisting} +\begin{cfa} f( i : 3, 5.7 ); §\C{// ambiguous call ?}§ -\end{lstlisting} +\end{cfa} Depending on the cost associated with named arguments, this call could be resolvable or ambiguous. Adding named argument into the routine resolution algorithm does not seem worth the complexity. @@ -1067,9 +1067,9 @@ provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list. For example, given the routine: -\begin{lstlisting} +\begin{cfa} void p( int x = 1, int y = 2, int z = 3 ) {...} -\end{lstlisting} +\end{cfa} the allowable positional calls are: -\begin{lstlisting} +\begin{cfa} p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ @@ -1084,5 +1084,5 @@ p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ -\end{lstlisting} +\end{cfa} Here the missing arguments are inserted from the default values in the parameter list. The compiler rewrites missing default values into explicit positional arguments. @@ -1106,9 +1106,9 @@ Default values may only appear in a prototype versus definition context: -\begin{lstlisting} +\begin{cfa} void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§ void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§ void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§ -\end{lstlisting} +\end{cfa} The reason for this restriction is to allow separate compilation. Multiple prototypes with different default values is an error. @@ -1117,14 +1117,14 @@ Ellipse (``...'') arguments present problems when used with default arguments. The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities: -\begin{lstlisting} +\begin{cfa} p( /* positional */, ... , /* named */ ); p( /* positional */, /* named */, ... ); -\end{lstlisting} +\end{cfa} While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: -\begin{lstlisting} +\begin{cfa} p( int x, int y, int z, ... ); p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ -\end{lstlisting} +\end{cfa} In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin. Hence, this approach seems significantly more difficult, and hence, confusing and error prone. @@ -1132,9 +1132,9 @@ The problem is exacerbated with default arguments, \eg: -\begin{lstlisting} +\begin{cfa} void p( int x, int y = 2, int z = 3... ); p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ -\end{lstlisting} +\end{cfa} The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; therefore, argument 5 subsequently conflicts with the named argument z : 3. @@ -1148,15 +1148,15 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}} & \multicolumn{1}{c}{\textbf{overloading}} \\ -\begin{lstlisting} +\begin{cfa} void p( int x, int y = 2, int z = 3 ) {...} -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} void p( int x, int y, int z ) {...} void p( int x ) { p( x, 2, 3 ); } void p( int x, int y ) { p( x, y, 3 ); } -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -1164,7 +1164,7 @@ In general, overloading should only be used over default arguments if the body of the routine is significantly different. Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as: -\begin{lstlisting} +\begin{cfa} p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§ -\end{lstlisting} +\end{cfa} Given the \CFA restrictions above, both named and default arguments are backwards compatible. @@ -1186,5 +1186,5 @@ \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}} & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}} & \multicolumn{1}{|c}{\textbf{\CFA}} \\ \hline -\begin{lstlisting} +\begin{cfa} struct S { enum C { R, G, B }; @@ -1203,7 +1203,7 @@ union U u; } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} enum C { R, G, B }; union U { int i, j; }; @@ -1222,7 +1222,7 @@ -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} struct S { enum C { R, G, B }; @@ -1241,5 +1241,5 @@ union ®S.T.®U u; } -\end{lstlisting} +\end{cfa} \end{tabular} \caption{Type Nesting / Qualification} @@ -1254,10 +1254,10 @@ While \CFA does not provide object programming by putting routines into structures, it does rely heavily on locally nested routines to redefine operations at or close to a call site. For example, the C quick-sort is wrapped into the following polymorphic \CFA routine: -\begin{lstlisting} +\begin{cfa} forall( otype T | { int ? [ §\emph{fieldlist}§ ] -\end{lstlisting} +\end{cfa} \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©. Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}. A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is the following: -\begin{lstlisting} +\begin{cfa} struct s { int f1, f2; @@ -1586,10 +1586,10 @@ v.[ f3, f1, f2 ] = ['x', 11, 17 ]; §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§ f( v.[ f3, f1, f2 ] ); §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§ -\end{lstlisting} +\end{cfa} Note, the fields appearing in a record-field tuple may be specified in any order; also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple. If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example: -\begin{lstlisting} +\begin{cfa} struct inner { int f2, f3; @@ -1602,5 +1602,5 @@ o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ]; -\end{lstlisting} +\end{cfa} @@ -1617,5 +1617,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ®L1:® do { ®L2:® while ( ... ) { @@ -1627,7 +1627,7 @@ } // while } while ( ... ); -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} do { while ( ... ) { @@ -1639,5 +1639,5 @@ L2: ; } L1: ; } while ( ... ); -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -1648,5 +1648,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} ®L1:® { ... §declarations§ ... @@ -1665,7 +1665,7 @@ } // switch } // compound -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} { ... §declarations§ ... @@ -1684,5 +1684,5 @@ } L2: ; } L1: ; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -1714,5 +1714,5 @@ \emph{falls through} to the next ©case© clause in the ©switch© statement; to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©: -\begin{lstlisting} +\begin{cfa} switch ( i ) { case 1: @@ -1723,9 +1723,9 @@ break; // exit switch statement } -\end{lstlisting} +\end{cfa} The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound: \begin{quote2} \begin{tabular}{@{}l@{\hspace{3em}}l@{}} -\begin{lstlisting} +\begin{cfa} switch ( argc ) { case 3: @@ -1738,7 +1738,7 @@ // usage message } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} if ( argc == 3 ) { @@ -1751,5 +1751,5 @@ // usage message } -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -1757,5 +1757,5 @@ This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine. C also uses fall-through to handle multiple case-values resulting in the same action: -\begin{lstlisting} +\begin{cfa} switch ( i ) { case 1: case 3: case 5: // odd values @@ -1766,5 +1766,5 @@ break; } -\end{lstlisting} +\end{cfa} However, this situation is handled in other languages without fall-through by allowing a list of case values. While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement. @@ -1773,5 +1773,5 @@ \item It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement: -\begin{lstlisting} +\begin{cfa} switch ( i ) { case 0: @@ -1788,5 +1788,5 @@ } // while } // switch -\end{lstlisting} +\end{cfa} The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties. The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it. @@ -1795,5 +1795,5 @@ There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it. Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}: -\begin{lstlisting} +\begin{cfa} register int n = (count + 7) / 8; switch ( count % 8 ) { @@ -1808,5 +1808,5 @@ } while ( --n > 0 ); } -\end{lstlisting} +\end{cfa} which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N. While efficient, this sort of special purpose usage is questionable: @@ -1824,5 +1824,5 @@ \item It is possible to place unreachable code at the start of a ©switch© statement, as in: -\begin{lstlisting} +\begin{cfa} switch ( x ) { ®int y = 1;® §\C{// unreachable initialization}§ @@ -1835,5 +1835,5 @@ ®x = z;® §\C{// without fall through, z is uninitialized}§ } -\end{lstlisting} +\end{cfa} While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic. @@ -1858,11 +1858,11 @@ Eliminating default fall-through has the greatest potential for affecting existing code. However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg: - \begin{lstlisting} +\begin{cfa} case 1: case 2: case 3: ... -\end{lstlisting} +\end{cfa} still works. Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments. Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.: -\begin{lstlisting} +\begin{cfa} ®choose® ( i ) { case 1: case 2: case 3: @@ -1878,5 +1878,5 @@ j = 3; } -\end{lstlisting} +\end{cfa} Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses; the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause. @@ -1893,5 +1893,5 @@ Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause. Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound. -\begin{lstlisting} +\begin{cfa} switch ( x ) { ®int i = 0;® §\C{// allowed only at start}§ @@ -1906,5 +1906,5 @@ ... } -\end{lstlisting} +\end{cfa} \end{enumerate} @@ -1919,5 +1919,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} switch ( i ) { case ®1, 3, 5®: @@ -1926,7 +1926,7 @@ ... } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} switch ( i ) { case 1: case 3 : case 5: @@ -1935,7 +1935,7 @@ ... } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // odd values @@ -1944,5 +1944,5 @@ -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -1952,5 +1952,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}} \\ -\begin{lstlisting} +\begin{cfa} switch ( i ) { case ®1~5:® @@ -1959,7 +1959,7 @@ ... } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} switch ( i ) case ®1 ... 5®: @@ -1968,7 +1968,7 @@ ... } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // 1, 2, 3, 4, 5 @@ -1977,11 +1977,11 @@ -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} Lists of subranges are also allowed. -\begin{lstlisting} +\begin{cfa} case ®1~5, 12~21, 35~42®: -\end{lstlisting} +\end{cfa} @@ -1989,5 +1989,5 @@ Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler. -\begin{lstlisting} +\begin{cfa} exception void h( int i ); exception int h( int i, double d ); @@ -2006,5 +2006,5 @@ } finally { } -\end{lstlisting} +\end{cfa} So the type raised would be the mangled name of the exception prototype and that name would be matched at the handler clauses by comparing the strings. The arguments for the call would have to be packed in a message and unpacked at handler clause and then a call made to the handler. @@ -2017,8 +2017,8 @@ \CFA allows users to define new types using the keyword type. -\begin{lstlisting} +\begin{cfa} // SensorValue is a distinct type and represented as an int type SensorValue = int; -\end{lstlisting} +\end{cfa} A type definition is different from a typedef in C because a typedef just creates an alias for a type, while Do.s type definition creates a distinct type. @@ -2026,5 +2026,5 @@ For example: -\begin{lstlisting} +\begin{cfa} type SensorValue = int; void printValue(int v) {...} @@ -2039,5 +2039,5 @@ process(s); // implicit conversion to int -\end{lstlisting} +\end{cfa} If SensorValue was defined with a typedef, then these two print functions would not have unique signatures. @@ -2047,5 +2047,5 @@ Users may override this and define a function that must be called to convert from one type to another. -\begin{lstlisting} +\begin{cfa} type SensorValue = int; // ()? is the overloaded conversion operator identifier @@ -2058,5 +2058,5 @@ SensorValue s = ...; process(s); // implicit call to conversion operator -\end{lstlisting} +\end{cfa} In many cases, it is not desired for the compiler to do this implicit conversion. @@ -2064,5 +2064,5 @@ Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error. -\begin{lstlisting} +\begin{cfa} type SensorValue = int; @@ -2077,8 +2077,8 @@ process(s); // implicit cast to int: compile-time error process((int) s); // explicit cast to int: calls conversion func -\end{lstlisting} +\end{cfa} The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to: -\begin{lstlisting} +\begin{cfa} type SensorValue = int; explicit SensorValue ()?(int); @@ -2088,5 +2088,5 @@ process(s); // compile-time error process((int) s); // type is converted, no function is called -\end{lstlisting} +\end{cfa} @@ -2096,5 +2096,5 @@ A structure is defined with the same syntax as in C. When referring to a structure in \CFA, users may omit the struct keyword. -\begin{lstlisting} +\begin{cfa} struct Point { double x; @@ -2103,5 +2103,5 @@ Point p = {0.0, 0.0}; -\end{lstlisting} +\end{cfa} \CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields. @@ -2110,5 +2110,5 @@ Embedding types is achieved using anonymous members. For example, using Point from above: -\begin{lstlisting} +\begin{cfa} void foo(Point p); @@ -2122,5 +2122,5 @@ cp.color = 0x33aaff; // color is accessed normally foo(cp); // cp can be used directly as a Point -\end{lstlisting} +\end{cfa} @@ -2132,5 +2132,5 @@ \begin{figure} -\begin{lstlisting} +\begin{cfa} struct Widget { int id; @@ -2174,5 +2174,5 @@ ^bar; // explicit call to destructor ^?(bar); // explicit call to destructor -\end{lstlisting} +\end{cfa} \caption{Constructors and Destructors} \end{figure} @@ -2211,5 +2211,5 @@ If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous. For details about type inference and overload resolution, please see the \CFA Language Specification. -\begin{lstlisting} +\begin{cfa} int foo(int a, int b) { float sum = 0.0; @@ -2224,5 +2224,5 @@ ... } -\end{lstlisting} +\end{cfa} @@ -2245,5 +2245,5 @@ For example, to define the constants for a complex type, the programmer would define the following: -\begin{lstlisting} +\begin{cfa} struct Complex { double real; @@ -2263,5 +2263,5 @@ ... } -\end{lstlisting} +\end{cfa} @@ -2271,9 +2271,9 @@ Allowing overloading of variable names enables programmers to use the same name across multiple types, simplifying naming conventions and is compatible with the other overloading that is allowed. For example, a developer may want to do the following: -\begin{lstlisting} +\begin{cfa} int pi = 3; float pi = 3.14; char pi = .p.; -\end{lstlisting} +\end{cfa} @@ -2283,5 +2283,5 @@ The examples below give some basic intuition about how the resolution works. -\begin{lstlisting} +\begin{cfa} // Choose the one with less conversions int doSomething(int value) {...} // option 1 @@ -2306,5 +2306,5 @@ f = bar(d, e); // chooses option 5 -\end{lstlisting} +\end{cfa} @@ -2376,5 +2376,5 @@ These operators are called using the normal C syntax. -\begin{lstlisting} +\begin{cfa} type Complex = struct { // define a Complex type double real; @@ -2406,5 +2406,5 @@ c = a + b; print(.sum = . + c); -\end{lstlisting} +\end{cfa} @@ -2415,24 +2415,24 @@ \begin{tabular}{@{}l@{\hspace{3em}}ll@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\ -\begin{lstlisting} +\begin{cfa} auto j = 3.0 * 4; int i; auto k = i; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} #define expr 3.0 * i typeof(expr) j = expr; int i; typeof(i) k = i; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // use type of initialization expression // use type of primary variable -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -2451,12 +2451,12 @@ Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed. For example, given -\begin{lstlisting} +\begin{cfa} auto j = ®...® -\end{lstlisting} +\end{cfa} and the need to write a routine to compute using ©j© -\begin{lstlisting} +\begin{cfa} void rtn( ®...® parm ); rtn( j ); -\end{lstlisting} +\end{cfa} A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name. In this situation, having the type name or a short alias is very useful. @@ -2488,5 +2488,5 @@ A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this: -\begin{lstlisting} +\begin{cfa} generic(type T) void swap(T &a, T &b) { @@ -2501,5 +2501,5 @@ Point p1, p2; swap(p1, p2); -\end{lstlisting} +\end{cfa} Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T. @@ -2511,5 +2511,5 @@ Some generic functions only work (or make sense) for any type that satisfies a given property. For example, here is a function to pick the minimum of two values of some type. -\begin{lstlisting} +\begin{cfa} generic (type T | bool ?>®©, this issue can be solved with a more powerful lexer/parser. @@ -2786,18 +2786,18 @@ Even with this special hack, there are 5 general cases that cannot be handled. The first case is for the function-call identifier ©?()©: -\begin{lstlisting} +\begin{cfa} int *§\textvisiblespace§?()(); // declaration: space required after '*' *§\textvisiblespace§?()(); // expression: space required after '*' -\end{lstlisting} +\end{cfa} Without the space, the string ©*?()© is ambiguous without N character look ahead; it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list. The 4 remaining cases occur in expressions: -\begin{lstlisting} +\begin{cfa} i++§\textvisiblespace§?i:0; // space required before '?' i--§\textvisiblespace§?i:0; // space required before '?' i§\textvisiblespace§?++i:0; // space required after '?' i§\textvisiblespace§?--i:0; // space required after '?' -\end{lstlisting} +\end{cfa} In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©; it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list. @@ -2835,10 +2835,10 @@ Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion. An example of the definition of a monitor is shown here: -\begin{lstlisting} +\begin{cfa} type Account = monitor { const unsigned long number; // account number float balance; // account balance }; -\end{lstlisting} +\end{cfa} Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor; @@ -2850,5 +2850,5 @@ If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the reverse order. -\begin{lstlisting} +\begin{cfa} // This function accesses a constant field, it does not require // mutual exclusion @@ -2865,5 +2865,5 @@ return a.balance; } -\end{lstlisting} +\end{cfa} Often, one function using a monitor will call another function using that same monitor. @@ -2873,5 +2873,5 @@ An example of this situation is shown below: -\begin{lstlisting} +\begin{cfa} // deleting a job from a worker requires mutual exclusion @@ -2887,5 +2887,5 @@ ... } -\end{lstlisting} +\end{cfa} @@ -2895,5 +2895,5 @@ A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control. Similar to a monitor, a task is defined like a structure: -\begin{lstlisting} +\begin{cfa} type Adder = task { int *row; @@ -2901,5 +2901,5 @@ int &subtotal; } -\end{lstlisting} +\end{cfa} A task may define a constructor, which will be called upon allocation and run on the caller.s thread. @@ -2909,5 +2909,5 @@ Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads. (Note that this example is designed to display the syntax and functionality, not the best method to solve this problem) -\begin{lstlisting} +\begin{cfa} void ?{}(Adder &a, int r[], int s, int &st) { // constructor a.row = r; @@ -2946,5 +2946,5 @@ printf(.total is %d\n., total); } -\end{lstlisting} +\end{cfa} @@ -2959,5 +2959,5 @@ Similarly, when a task tries to push something onto the list, but it is full, it will yield until another task frees some space with the pop function. -\begin{lstlisting} +\begin{cfa} // type T is used as a generic type for all definitions inside // the curly brackets @@ -2984,5 +2984,5 @@ } } -\end{lstlisting} +\end{cfa} A task can also yield indefinitely by calling yield with no arguments. @@ -2991,5 +2991,5 @@ The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods. -\begin{lstlisting} +\begin{cfa} type Ping = task { Pong *partner; @@ -3029,8 +3029,8 @@ Ping{pong}; // initialize and start ping } -\end{lstlisting} +\end{cfa} The same functionality can be accomplished by providing functions to be called by the partner task. -\begin{lstlisting} +\begin{cfa} type Pingpong = task { String msg; @@ -3060,5 +3060,5 @@ go(ping); } -\end{lstlisting} +\end{cfa} @@ -3092,5 +3092,5 @@ Within a module, all of the module's global definitions are visible throughout the module. For example, the following code compiles, even though ©isOdd© was not declared before being called: -\begin{lstlisting} +\begin{cfa} bool isEven(unsigned int x) { if (x == 0) return true; @@ -3102,5 +3102,5 @@ else return !isEven(x - 2); } -\end{lstlisting} +\end{cfa} Header files in C are used to expose the declarations from a library, so that they can be used externally. @@ -3137,5 +3137,5 @@ The following code is a simple module declaration example. -\begin{lstlisting} +\begin{cfa} module M; @@ -3150,5 +3150,5 @@ double bCounter; -\end{lstlisting} +\end{cfa} export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module. @@ -3171,5 +3171,5 @@ The following code snippets show the two situations. -\begin{lstlisting} +\begin{cfa} module util/counter; export int f(int i) { return i+1; } @@ -3185,10 +3185,10 @@ return ct.f(200); // f() from the package counter } -\end{lstlisting} +\end{cfa} Additionally, using the .as. syntax, a user can force the compiler to add the imported names into the current namespace using .as ..With these module rules, the following module definitions and imports can be achieved without any problem. -\begin{lstlisting} +\begin{cfa} module M1; export int f(int i) { return i+1;} // visible outside @@ -3208,5 +3208,5 @@ return f(3) + g(4); //f() from M1 and g() from M2; } -\end{lstlisting} +\end{cfa} @@ -3225,5 +3225,5 @@ If an aggregated module is imported, all the included modules in the aggregation are imported. -\begin{lstlisting} +\begin{cfa} module std/sequence; @@ -3237,5 +3237,5 @@ module std/stack; }; -\end{lstlisting} +\end{cfa} After importing the aggregated module, each individual name is still contained in the original name space. @@ -3341,5 +3341,5 @@ Here is an example of a package, util. -\begin{lstlisting} +\begin{cfa} + util Do.prj #package description file @@ -3357,5 +3357,5 @@ sequence.do #Case 4, module std/sequence; test.do #Case 5 -\end{lstlisting} +\end{cfa} \begin{itemize} @@ -3435,5 +3435,5 @@ Here is a simple example of the directory structure of a package, core. It contains a module std and several sub-modules under std. -\begin{lstlisting} +\begin{cfa} + core Do.prj @@ -3445,5 +3445,5 @@ vector.do #module std/container/vector; list.do #module std/container/list; -\end{lstlisting} +\end{cfa} @@ -3534,5 +3534,5 @@ Here is an example of a package, util. -\begin{lstlisting} +\begin{cfa} + util Do.prj #package description file @@ -3550,5 +3550,5 @@ sequence.do #Case 4, module std/sequence; test.do #Case 5 -\end{lstlisting} +\end{cfa} @@ -3641,5 +3641,5 @@ \subsubsection{Package and Module Locating Example} -\begin{lstlisting} +\begin{cfa} # A project's source code tree @@ -3676,8 +3676,8 @@ ---------------------------------------- -\end{lstlisting} - - -\begin{lstlisting} +\end{cfa} + + +\begin{cfa} # pkg directory's source code tree @@ -3700,5 +3700,5 @@ security.do #module security; ------------------------------------------ -\end{lstlisting} +\end{cfa} @@ -3744,5 +3744,5 @@ \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ \hline -\begin{lstlisting} +\begin{cfa} struct Line { float lnth; @@ -3771,5 +3771,5 @@ Line line1; Line line2 = { 3.4 }; -\end{lstlisting} +\end{cfa} & \begin{lstlisting}[language=C++] @@ -3831,5 +3831,5 @@ \end{lstlisting} & -\begin{lstlisting} +\begin{cfa} struct Line { length: f32 @@ -3858,5 +3858,5 @@ let line1:Line = Default::default(); Line line2( 3.4 ); -\end{lstlisting} +\end{cfa} \end{tabular} \end{flushleft} @@ -3869,5 +3869,5 @@ \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ \hline -\begin{lstlisting} +\begin{cfa} struct Cpx { double re, im; @@ -3879,7 +3879,7 @@ Cpx a, b, c; c = a + b; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} struct Cpx { double re, im; @@ -3891,7 +3891,7 @@ Cpx a, b, c; c = a + b; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // no operator overloading @@ -3902,7 +3902,7 @@ -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} struct Cpx { re: f32, @@ -3921,5 +3921,5 @@ let (a, b, mut c) = ...; c = a + b -\end{lstlisting} +\end{cfa} \end{tabular} \end{flushleft} @@ -3932,5 +3932,5 @@ \multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ \hline -\begin{lstlisting}[boxpos=t] +\begin{cfa}[boxpos=t] extern "C" { #include @@ -3943,7 +3943,7 @@ return s.st_size; } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting}[boxpos=t] +\begin{cfa}[boxpos=t] /* #cgo @@ -3962,7 +3962,7 @@ return buf._st_size } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting}[boxpos=t] +\begin{cfa}[boxpos=t] use libc::{c_int, size_t}; // translated from sys/stat.h @@ -3986,5 +3986,5 @@ } } -\end{lstlisting} +\end{cfa} \end{tabular} \end{flushleft} @@ -3997,5 +3997,5 @@ \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ \hline -\begin{lstlisting} +\begin{cfa} generic(type T, type N | { int ? T *maximize(const F &f, @@ -4043,7 +4043,7 @@ }, n, p); } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} // Go does not support generics! func maximize( @@ -4073,7 +4073,7 @@ a).(string) } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} use std::cmp::Ordering; @@ -4101,5 +4101,5 @@ maximize(|x: &String| x.len(), a) } -\end{lstlisting} +\end{cfa} \end{tabular} \end{flushleft} @@ -4109,5 +4109,5 @@ \subsubsection{Modules / Packages} -\begin{lstlisting} +\begin{cfa} \CFA \CC @@ -4185,5 +4185,5 @@ println!(.{}., M::inc(100)); } -\end{lstlisting} +\end{cfa} \end{comment} @@ -4195,5 +4195,5 @@ \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ \hline -\begin{lstlisting} +\begin{cfa} task Nonzero { int *data; @@ -4236,7 +4236,7 @@ return res; } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} #include #include @@ -4279,7 +4279,7 @@ return res; } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} package main @@ -4304,7 +4304,7 @@ fmt.Println(res) } -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} use std::thread; use std::sync:mpsc::channel; @@ -4339,5 +4339,5 @@ println!(.{}., res); } -\end{lstlisting} +\end{cfa} \end{tabular} \end{flushleft} @@ -4436,20 +4436,20 @@ \begin{description} \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: -\begin{lstlisting} +\begin{cfa} int rtn( int i ); int rtn( char c ); rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§ -\end{lstlisting} +\end{cfa} \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. -\begin{lstlisting} +\begin{cfa} sout | 'x' | " " | (int)'x' | endl; x 120 -\end{lstlisting} +\end{cfa} Having to cast ©'x'© to ©char© is non-intuitive. \item[Effect on original feature:] change to semantics of well-defined feature that depend on: -\begin{lstlisting} +\begin{cfa} sizeof( 'x' ) == sizeof( int ) -\end{lstlisting} +\end{cfa} no long work the same in \CFA programs. \item[Difficulty of converting:] simple @@ -4460,15 +4460,15 @@ \begin{description} \item[Change:] make string literals ©const©: -\begin{lstlisting} +\begin{cfa} char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§ char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§ -\end{lstlisting} +\end{cfa} The type of a string literal is changed from ©[] char© to ©const [] char©. Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. \item[Rationale:] This change is a safety issue: -\begin{lstlisting} +\begin{cfa} char * p = "abc"; p[0] = 'w'; §\C{// segment fault or change constant literal}§ -\end{lstlisting} +\end{cfa} The same problem occurs when passing a string literal to a routine that changes its argument. \item[Effect on original feature:] change to semantics of well-defined feature. @@ -4480,17 +4480,17 @@ \begin{description} \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: -\begin{lstlisting} +\begin{cfa} int i; §\C{// forward definition}§ int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§ int i = 0; §\C{// definition}§ -\end{lstlisting} +\end{cfa} is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example, -\begin{lstlisting} +\begin{cfa} struct X { int i; struct X *next; }; static struct X a; §\C{// forward definition}§ static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§ static struct X a = { 1, &b }; §\C{// definition}§ -\end{lstlisting} +\end{cfa} \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. \item[Effect on original feature:] change to semantics of well-defined feature. @@ -4502,5 +4502,5 @@ \begin{description} \item[Change:] have ©struct© introduce a scope for nested types: -\begin{lstlisting} +\begin{cfa} enum ®Colour® { R, G, B, Y, C, M }; struct Person { @@ -4516,5 +4516,5 @@ Personß.ß®Colour® pc = Personß.ßR; §\C{// type/enum defined inside}§ Personß.ßFace pretty; §\C{// type defined inside}§ -\end{lstlisting} +\end{cfa} In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. @@ -4531,10 +4531,10 @@ \item[Rationale:] C++ classes have member functions which require that classes establish scopes. \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example: -\begin{lstlisting} +\begin{cfa} struct Y; §\C{// struct Y and struct X are at the same scope}§ struct X { struct Y { /* ... */ } y; }; -\end{lstlisting} +\end{cfa} All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of the difference in scope rules, which is documented in 3.3. @@ -4602,13 +4602,13 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{\CC}} \\ -\begin{lstlisting} +\begin{cfa} int x = 0, y = 1, z = 2; ®sout® ®|® x ®|® y ®|® z ®| endl®; -\end{lstlisting} +\end{cfa} & -\begin{lstlisting} +\begin{cfa} cout << x << " " << y << " " << z << endl; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -4621,13 +4621,13 @@ \textbf{\CFA:} & -\begin{lstlisting} +\begin{cfa} sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl; -\end{lstlisting} +\end{cfa} \\ \textbf{\CC:} & -\begin{lstlisting} +\begin{cfa} cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl; -\end{lstlisting} +\end{cfa} \end{tabular} \end{quote2} @@ -4639,93 +4639,93 @@ \item A separator does not appear at the start or end of a line. -\begin{lstlisting}[belowskip=0pt] +\begin{cfa}[belowskip=0pt] sout | 1 | 2 | 3 | endl; -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 1 2 3 -\end{lstlisting} +\end{cfa} \item A separator does not appear before or after a character literal or variable. -\begin{lstlisting} +\begin{cfa} sout | '1' | '2' | '3' | endl; 123 -\end{lstlisting} +\end{cfa} \item A separator does not appear before or after a null (empty) C string -\begin{lstlisting} +\begin{cfa} sout | 1 | "" | 2 | "" | 3 | endl; 123 -\end{lstlisting} +\end{cfa} which is a local mechanism to disable insertion of the separator character. \item A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@ %$ -\begin{lstlisting}[mathescape=off] +\begin{cfa}[mathescape=off] sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl; -\end{lstlisting} +\end{cfa} %$ -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10 -\end{lstlisting} +\end{cfa} %$ \item {\lstset{deletedelim=**[is][]{¢}{¢}} A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»© -\begin{lstlisting}[belowskip=0pt] +\begin{cfa}[belowskip=0pt] sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x" | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl; -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 1, x 2. x 3: x 4; x 5! x 6? x 7% x 8¢ x 9» x 10) x 11] x 12} x -\end{lstlisting}}% +\end{cfa}}% \item A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@ -\begin{lstlisting}[belowskip=0pt] +\begin{cfa}[belowskip=0pt] sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl; -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] x`1`x'2'x"3"x x 4 x x 1 x -\end{lstlisting} +\end{cfa} \end{enumerate} The following \CC-style \Index{manipulator}s allow further control over implicit seperation. -\begin{lstlisting}[mathescape=off,belowskip=0pt] +\begin{cfa}[mathescape=off,belowskip=0pt] sout | sepOn | 1 | 2 | 3 | sepOn | endl; §\C{// separator at start of line}§ -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 1 2 3 -\end{lstlisting} -\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] sout | 1 | sepOff | 2 | 3 | endl; §\C{// turn off implicit separator locally}§ -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 12 3 -\end{lstlisting} -\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] sout | sepDisable | 1 | 2 | 3 | endl; §\C{// turn off implicit separation globally}§ -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 123 -\end{lstlisting} -\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] sout | 1 | sepOn | 2 | 3 | endl; §\C{// turn on implicit separator locally}§ -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 1 23 -\end{lstlisting} -\begin{lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] sout | sepEnable | 1 | 2 | 3 | endl; §\C{// turn on implicit separation globally}§ -\end{lstlisting} -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 1 2 3 -\end{lstlisting} -\begin{lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] sepSet( sout, ", $" ); §\C{// change separator from " " to ", \$"}§ sout | 1 | 2 | 3 | endl; -\end{lstlisting} +\end{cfa} %$ -\begin{lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt] +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] 1, $2, $3 -\end{lstlisting} +\end{cfa} %$ \begin{comment} @@ -4769,5 +4769,5 @@ \leavevmode -\begin{lstlisting}[aboveskip=0pt,belowskip=0pt] +\begin{cfa}[aboveskip=0pt,belowskip=0pt] forall( otype T ) T * malloc( void );§\indexc{malloc}§ forall( otype T ) T * malloc( char fill ); @@ -4784,5 +4784,5 @@ forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill forall( otype T ) T * memset( T * ptr ); // remove when default value available -\end{lstlisting} +\end{cfa} @@ -4790,5 +4790,5 @@ \leavevmode -\begin{lstlisting}[aboveskip=0pt,belowskip=0pt] +\begin{cfa}[aboveskip=0pt,belowskip=0pt] int ato( const char * ptr );§\indexc{ato}§ unsigned int ato( const char * ptr ); @@ -4816,5 +4816,5 @@ double _Complex strto( const char * sptr, char ** eptr ); long double _Complex strto( const char * sptr, char ** eptr ); -\end{lstlisting} +\end{cfa} @@ -4822,5 +4822,5 @@ \leavevmode -\begin{lstlisting}[aboveskip=0pt,belowskip=0pt] +\begin{cfa}[aboveskip=0pt,belowskip=0pt] forall( otype T | { int ?