Index: doc/LaTeXmacros/common.tex =================================================================== --- doc/LaTeXmacros/common.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/LaTeXmacros/common.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -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 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/bibliography/cfa.bib (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -3645,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}, } @@ -4563,20 +4563,22 @@ } -@book{obj-c-book, +@manual{obj-c-book, keywords = {objective-c}, contributor = {a3moss@uwaterloo.ca}, author = {{Apple Computer Inc.}}, title = {The {Objective-C} Programming Language}, - year = 2002 + 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, - url = {https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html}, - urldate = {2017-04-04} + 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} } @@ -4867,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 @@ -5879,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}}, } @@ -6577,10 +6581,9 @@ } -@unpublished{TIOBE, +@online{TIOBE, contributer = {pabuhr@plg}, author = {{TIOBE Index}}, - title = {}, year = {March 2017}, - note = {\url{http://www.tiobe.com/tiobe_index}}, + url = {http://www.tiobe.com/tiobe_index}, } Index: doc/generic_types/acmart.cls =================================================================== --- doc/generic_types/acmart.cls (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/generic_types/acmart.cls (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -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/generic_types.tex =================================================================== --- doc/generic_types/generic_types.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/generic_types/generic_types.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -51,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 @@ -167,7 +167,7 @@ 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 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 @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 is similar to \CC virtual function calls. An advantage of this design is that, unlike \CC template functions, \CFA @forall@ functions are compatible with C \emph{separate} compilation. +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: @@ -176,25 +176,9 @@ int val = twice( twice( 3.7 ) ); \end{lstlisting} -which works for any type @T@ with a matching addition operator. The polymorphism is achieved by creating a wrapper function for calling @+@ with @T@ bound to @double@, then passing this function to the first call of @twice@. There is now the option of using the same @twice@ and converting the result to @int@ on assignment, or creating another @twice@ with type parameter @T@ bound to @int@ because \CFA uses the return type in its type analysis. The first approach has a late conversion from @int@ to @double@ on the final assignment, while the second has an eager conversion to @int@. \CFA minimizes the number of conversions and their potential to lose information, so it selects the first approach, which corresponds with C-programmer intuition. - -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}$ } @@ -251,4 +244,15 @@ \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. @@ -262,12 +266,10 @@ T ?+=?( T *, T ); T ++?( T * ); - T ?++( T * ); -}; + T ?++( T * ); }; forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) { // use trait `T` total = { `0` }; $\C{// instantiate T from 0 by calling its constructor}$ for ( unsigned int i = 0; i < size; i += 1 ) total `+=` a[i]; $\C{// select appropriate +}$ - return total; -} + return total; } \end{lstlisting} @@ -278,6 +280,5 @@ void ?{}( T *, T ); $\C{// copy constructor}$ void ?=?( T *, T ); $\C{// assignment operator}$ - void ^?{}( T * ); $\C{// destructor}$ -}; + void ^?{}( T * ); }; $\C{// destructor}$ \end{lstlisting} Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack-allocatable, default or copy-initialized, assigned, and deleted. @@ -385,4 +386,5 @@ \end{lstlisting} + \subsection{Dynamic Generic Types} Index: doc/proposals/concurrency/concurrency.tex =================================================================== --- doc/proposals/concurrency/concurrency.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/proposals/concurrency/concurrency.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -61,5 +61,5 @@ \newcommand{\uC}{$\mu$\CC} \newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace} -\newcommand{\code}[1]{\lstinline{#1}} +\newcommand{\code}[1]{\lstinline[language=CFA]{#1}} \newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}} @@ -160,5 +160,5 @@ Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not. -Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without wualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity. +Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without quualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity. The next semantic decision is to establish when mutex/nomutex may be used as a type qualifier. Consider the following declarations: @@ -368,11 +368,13 @@ \end{lstlisting} -Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee. +Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. + +As for simple mutual exclusion, these semantics must also be extended to include \gls{group-acquire} : \begin{center} \begin{tabular}{ c @{\hskip 0.65in} c } Thread 1 & Thread 2 \\ \begin{lstlisting} -void foo(monitor & mutex a, - monitor & mutex b) { +void foo(A & mutex a, + A & mutex b) { //... wait(a.e); @@ -382,6 +384,6 @@ foo(a, b); \end{lstlisting} &\begin{lstlisting} -void bar(monitor & mutex a, - monitor & mutex b) { +void bar(A & mutex a, + A & mutex b) { signal(a.e); } @@ -393,168 +395,368 @@ \end{tabular} \end{center} -A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling): - -\begin{center} -\begin{tabular}{|c|c|c|} -Context 1 & Context 2 & Context 3 \\ -\hline -\begin{lstlisting} -condition e; - -//acquire a & b -void foo(monitor & mutex a, - monitor & mutex b) { - - wait(e); //release a & b -} - - - - - - -foo(a,b); -\end{lstlisting} &\begin{lstlisting} -condition e; - -//acquire a -void bar(monitor & mutex a, - monitor & nomutex b) { - foo(a,b); -} - -//acquire a & b -void foo(monitor & mutex a, - monitor & mutex b) { - wait(e); //release a & b -} - -bar(a, b); -\end{lstlisting} &\begin{lstlisting} -condition e; - -//acquire a -void bar(monitor & mutex a, - monitor & nomutex b) { - baz(a,b); -} - -//acquire b -void baz(monitor & nomutex a, - monitor & mutex b) { - wait(e); //release b -} - -bar(a, b); + +To define the semantics of internal scheduling, it is important to look at nesting and \gls{group-acquire}. Indeed, beyond concerns about lock ordering, without scheduling the two following pseudo codes are mostly equivalent. In fact, if we assume monitors are ordered alphabetically, these two pseudo codes would probably lead to exactly the same implementation : + +\begin{table}[h!] +\centering +\begin{tabular}{c c} +\begin{lstlisting}[language=pseudo] +monitor A, B, C + +acquire A + acquire B & C + + //Do stuff + + release B & C +release A +\end{lstlisting} &\begin{lstlisting}[language=pseudo] +monitor A, B, C + +acquire A + acquire B + acquire C + //Do stuff + release C + release B +release A \end{lstlisting} \end{tabular} -\end{center} - -Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior. - - -\begin{center} -\begin{tabular}{|c|c|c|} -\begin{lstlisting} -condition e; - -//acquire b -void foo(monitor & nomutex a, - monitor & mutex b) { - bar(a,b); -} - -//acquire a -void bar(monitor & mutex a, - monitor & nomutex b) { - - wait(e); //release a - //keep b -} - -foo(a, b); -\end{lstlisting} &\begin{lstlisting} -condition e; - -//acquire a & b -void foo(monitor & mutex a, - monitor & mutex b) { - bar(a,b); -} - -//acquire b -void bar(monitor & mutex a, - monitor & nomutex b) { - - wait(e); //release b - //keep a -} - -foo(a, b); -\end{lstlisting} &\begin{lstlisting} -condition e; - -//acquire a & b -void foo(monitor & mutex a, - monitor & mutex b) { - bar(a,b); -} - -//acquire none -void bar(monitor & nomutex a, - monitor & nomutex b) { - - wait(e); //release a & b - //keep none -} - -foo(a, b); +\end{table} + +Once internal scheduling is introduce however, semantics of \gls{group-acquire} become relevant. For example, let us look into the semantics of the following pseudo-code : + +\begin{lstlisting}[language=Pseudo] +1: monitor A, B, C +2: condition c1 +3: +4: acquire A +5: acquire A & B & C +6: signal c1 +7: release A & B & C +8: release A +\end{lstlisting} + +Without \gls{group-acquire} signal simply baton passes the monitor lock on the next release. In the case above, we therefore need to indentify the next release. If line 8 is picked at the release point, then the signal will attempt to pass A \& B \& C, without having ownership of B \& C. Since this violates mutual exclusion, we conclude that line 7 is the only valid location where signalling can occur. The traditionnal meaning of signalling is to transfer ownership of the monitor(s) and immediately schedule the longest waiting task. However, in the discussed case, the signalling thread expects to maintain ownership of monitor A. This can be expressed in two differents ways : 1) the thread transfers ownership of all locks and reacquires A when it gets schedulled again or 2) it transfers ownership of all three monitors and then expects the ownership of A to be transferred back. + +However, the question is does these behavior motivate supporting acquireing non-disjoint set of monitors. Indeed, if the previous example was modified to only acquire B \& C at line 5 (an release the accordingly) then in respects to scheduling, we could add the simplifying constraint that all monitors in a bulk will behave the same way, simplifying the problem back to a single monitor problem which has already been solved. For this constraint to be acceptble however, we need to demonstrate that in does not prevent any meaningful possibilities. And, indeed, we can look at the two previous interpretation of the above pseudo-code and conclude that supporting the acquiring of non-disjoint set of monitors does not add any expressiveness to the language. + +Option 1 reacquires the lock after the signal statement, this can be rewritten as follows without the need for non-disjoint sets : +\begin{lstlisting}[language=Pseudo] +monitor A, B, C +condition c1 + +acquire A & B & C + signal c1 +release A & B & C +acquire A + +release A +\end{lstlisting} + +This pseudo code has almost exaclty the same semantics as the code acquiring intersecting sets of monitors. + +Option 2 uses two-way lock ownership transferring instead of reacquiring monitor A. Two-way monitor ownership transfer is normally done using signalBlock semantics, which immedietely transfers ownership of a monitor before getting the ownership back when the other thread no longer needs the monitor. While the example pseudo-code for Option 2 seems toe transfer ownership of A, B and C and only getting A back, this is not a requirement. Getting back all 3 monitors and releasing B and C differs only in performance. For this reason, the second option could arguably be rewritten as : + +\begin{lstlisting}[language=Pseudo] +monitor A, B, C +condition c1 + +acquire A + acquire B & C + signalBlock c1 + release B & C +release A +\end{lstlisting} + +Obviously, the difference between these two snippets of pseudo code is that the first one transfers ownership of A, B and C while the second one only transfers ownership of B and C. However, this limitation can be removed by allowing user to release extra monitors when using internal scheduling, referred to as extended internal scheduling (pattent pending) from this point on. Extended internal scheduling means the two following pseudo-codes are functionnaly equivalent : +\begin{table}[h!] +\centering +\begin{tabular}{c @{\hskip 0.65in} c} +\begin{lstlisting}[language=pseudo] +monitor A, B, C +condition c1 + +acquire A + acquire B & C + signalBlock c1 with A + release B & C +release A +\end{lstlisting} &\begin{lstlisting}[language=pseudo] +monitor A, B, C +condition c1 + +acquire A + acquire A & B & C + signal c1 + release A & B & C +release A \end{lstlisting} \end{tabular} -\end{center} -Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined. - -These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines : -\begin{center} -\begin{tabular}{ c c c } -\begin{lstlisting} - condition e; - - //acquire a & b - void foo(monitor & mutex a, - monitor & mutex b) { - bar(a,b); - } - - //acquire b - void bar(monitor & mutex a, - monitor & nomutex b) { - - wait(e); //release b - //keep a - } - - foo(a, b); -\end{lstlisting} &\begin{lstlisting} - => -\end{lstlisting} &\begin{lstlisting} - condition e; - - //acquire a & b - void foo(monitor & mutex a, - monitor & mutex b) { - wait_release(e,b); //release b - //keep a - } - - foo(a, b); -\end{lstlisting} -\end{tabular} -\end{center} - -Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor. - -Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section. -\\ +\end{table} + +It must be stated that the extended internal scheduling only makes sense when using wait and signalBlock, since they need to prevent barging, which cannot be done in the context of signal since the ownership transfer is strictly one-directionnal. + +One critic that could arise is that extended internal schedulling is not composable since signalBlock must be explicitly aware of which context it is in. However, this argument is not relevant since acquire A, B and C in a context where a subset of them is already acquired cannot be achieved without spurriously releasing some locks or having an oracle aware of all monitors. Therefore, composability of internal scheduling is no more an issue than composability of monitors in general. + +The main benefit of using extended internal scheduling is that it offers the same expressiveness as intersecting monitor set acquiring but greatly simplifies the selection of a leader (or representative) for a group of monitor. Indeed, when using intersecting sets, it is not obvious which set intersects with other sets which means finding a leader representing only the smallest scope is a hard problem. Where as when using disjoint sets, any monitor that would be intersecting must be specified in the extended set, the leader can be chosen as any monitor in the primary set. + +% We need to make sure the semantics for internally scheduling N monitors are a natural extension of the single monitor semantics. For this reason, we introduce the concept of \gls{mon-ctx}. In terms of context internal scheduling means "releasing a \gls{mon-ctx} and waiting for an other thread to acquire the same \gls{mon-ctx} and baton-pass it back to the initial thread". This definitions requires looking into what a \gls{mon-ctx} is and what the semantics of waiting and baton-passing are. + +% \subsubsection{Internal scheduling: Context} \label{insched-context} +% Monitor scheduling operations are defined in terms of the context they are in. In languages that only supports operations on a single monitor at once, the context is completly defined by which most recently acquired monitors. Indeed, acquiring several monitors will form a stack of monitors which will be released in FILO order. In \CFA, a \gls{mon-ctx} cannot be simply defined by the last monitor that was acquired since \gls{group-acquire} means multiple monitors can be "the last monitor acquired". The \gls{mon-ctx} is therefore defined as the last set of monitors to have been acquired. This means taht when any new monitor is acquired, the group it belongs to is the new \gls{mon-ctx}. Correspondingly, if any monitor is released, the \gls{mon-ctx} reverts back to the context that was used prior to the monitor being acquired. In the most common case, \gls{group-acquire} means every monitor of a group will be acquired in released at the same time. However, since every monitor has its own recursion level, \gls{group-acquire} does not prevent users from reacquiring certain monitors while acquireing new monitors in the same operation. For example : + +% \begin{lstlisting} +% //Forward declarations +% monitor a, b, c +% void foo( monitor & mutex a, +% monitor & mutex b); +% void bar( monitor & mutex a, +% monitor & mutex b); +% void baz( monitor & mutex a, +% monitor & mutex b, +% monitor & mutex c); + +% //Routines defined inline to illustrate context changed compared to the stack + +% //main thread +% foo(a, b) { +% //thread calls foo +% //acquiring context a & b + +% baz(a, b) { +% //thread calls baz +% //no context change + +% bar(a, b, c) { +% //thread calls bar +% //acquiring context a & b & c + +% //Do stuff + +% return; +% //call to bar returns +% } +% //context back to a & b + +% return; +% //call to baz returns +% } +% //no context change + +% return; +% //call to foo returns +% } +% //context back to initial state + +% \end{lstlisting} + +% As illustrated by the previous example, context changes can be caused by only one of the monitors comming into context or going out of context. + +% \subsubsection{Internal scheduling: Waiting} \label{insched-wait} + +% \subsubsection{Internal scheduling: Baton Passing} \label{insched-signal} +% Baton passing in internal scheduling is done in terms of \code{signal} and \code{signalBlock}\footnote{Arguably, \code{signal_now} is a more evocative name and \code{signal} could be changed appropriately. }. While \code{signalBlock} is the more straight forward way of baton passing, transferring ownership immediately, it must rely on \code{signal} which is why t is discussed first. +% \code{signal} has for effect to transfer the current context to another thread when the context would otherwise be released. This means that instead of releasing the concerned monitors, the first thread on the condition ready-queue is scheduled to run. The monitors are not released and when the signalled thread runs, it assumes it regained ownership of all the monitors it had in its context. + +% \subsubsection{Internal scheduling: Implementation} \label{insched-impl} +% Too implement internal scheduling, three things are need : a data structure for waiting tasks, a data structure for signalled task and a leaving procedure to run the signalled task. In the case of both data structures, it is desireable to have to use intrusive data structures in order to prevent the need for any dynamic allocation. However, in both cases being able to queue several items in the same position in a queue is non trivial, even more so in the presence of concurrency. However, within a given \gls{mon-ctx}, all monitors have exactly the same behavior in regards to scheduling. Therefore, the problem of queuing multiple monitors at once can be ignored by choosing one monitor to represent every monitor in a context. While this could prove difficult in other situations, \gls{group-acquire} requires that the monitors be sorted according to some stable predicate. Since monitors are sorted in all contexts, the representative can simply be the first in the list. Choosing a representative means a simple intrusive queue inside the condition is sufficient to implement the data structure for both waiting and signalled monitors. + +% Since \CFA monitors don't have a complete image of the \gls{mon-ctx}, choosing the representative and maintaning the current context information cannot easily be done by any single monitors. However, as discussed in section [Missing section here], monitor mutual exclusion is implemented using an raii object which is already in charge of sorting monitors. This object has a complete picture of the \gls{mon-ctx} which means it is well suited to choose the reprensentative and detect context changes. + +% \newpage +% \begin{lstlisting} +% void ctor( monitor ** _monitors, int _count ) { +% bool ctx_changed = false; +% for( mon in _monitors ) { +% ctx_changed = acquire( mon ) || ctx_changed; +% } + +% if( ctx_changed ) { +% set_representative(); +% set_context(); +% } +% } + +% void dtor( monitor ** _monitors, int _count ) { +% if( context_will_exit( _monitors, count ) ) { +% baton_pass(); +% return; +% } + +% for( mon in _monitors ) { +% release( mon ); +% } +% } + +% \end{lstlisting} + + + +% A direct extension of the single monitor semantics is to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling): + +% \begin{table}[h!] +% \centering +% \begin{tabular}{|c|c|c|} +% Context 1 & Context 2 & Context 3 \\ +% \hline +% \begin{lstlisting} +% condition e; + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { + +% wait(e); //release a & b +% } + + + + + + +% foo(a,b); +% \end{lstlisting} &\begin{lstlisting} +% condition e; + +% //acquire a +% void bar(monitor & mutex a, +% monitor & nomutex b) { +% foo(a,b); +% } + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { +% wait(e); //release a & b +% } + +% bar(a, b); +% \end{lstlisting} &\begin{lstlisting} +% condition e; + +% //acquire a +% void bar(monitor & mutex a, +% monitor & nomutex b) { +% baz(a,b); +% } + +% //acquire b +% void baz(monitor & nomutex a, +% monitor & mutex b) { +% wait(e); //release b +% } + +% bar(a, b); +% \end{lstlisting} +% \end{tabular} +% \end{table} + +% Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior. + + +% \begin{center} +% \begin{tabular}{|c|c|c|} +% \begin{lstlisting} +% condition e; + +% //acquire b +% void foo(monitor & nomutex a, +% monitor & mutex b) { +% bar(a,b); +% } + +% //acquire a +% void bar(monitor & mutex a, +% monitor & nomutex b) { + +% wait(e); //release a +% //keep b +% } + +% foo(a, b); +% \end{lstlisting} &\begin{lstlisting} +% condition e; + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { +% bar(a,b); +% } + +% //acquire b +% void bar(monitor & mutex a, +% monitor & nomutex b) { + +% wait(e); //release b +% //keep a +% } + +% foo(a, b); +% \end{lstlisting} &\begin{lstlisting} +% condition e; + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { +% bar(a,b); +% } + +% //acquire none +% void bar(monitor & nomutex a, +% monitor & nomutex b) { + +% wait(e); //release a & b +% //keep none +% } + +% foo(a, b); +% \end{lstlisting} +% \end{tabular} +% \end{center} +% Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined. + +% These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines : +% \begin{center} +% \begin{tabular}{ c c c } +% \begin{lstlisting} +% condition e; + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { +% bar(a,b); +% } + +% //acquire b +% void bar(monitor & mutex a, +% monitor & nomutex b) { + +% wait(e); //release b +% //keep a +% } + +% foo(a, b); +% \end{lstlisting} &\begin{lstlisting} +% => +% \end{lstlisting} &\begin{lstlisting} +% condition e; + +% //acquire a & b +% void foo(monitor & mutex a, +% monitor & mutex b) { +% wait_release(e,b); //release b +% //keep a +% } + +% foo(a, b); +% \end{lstlisting} +% \end{tabular} +% \end{center} + +% Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor. + +% Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section. +% \\ % ####### # # ####### ##### ##### # # ####### ###### Index: doc/proposals/concurrency/glossary.tex =================================================================== --- doc/proposals/concurrency/glossary.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/proposals/concurrency/glossary.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -14,7 +14,13 @@ \longnewglossaryentry{group-acquire} -{name={bulked acquiring}} +{name={bulk acquiring}} { Implicitly acquiring several monitors when entering a monitor. +} + +\longnewglossaryentry{mon-ctx} +{name={monitor context}} +{ +The state of the current thread regarding which monitors are owned. } Index: doc/proposals/concurrency/lit-review.md =================================================================== --- doc/proposals/concurrency/lit-review.md (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) +++ doc/proposals/concurrency/lit-review.md (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -0,0 +1,25 @@ +lit review : + +Lister77 : nested monitor calls + - explains the problem + - no solution + - Lister : An implementation of monitors. + - Lister : Hierarchical monitors. + +Haddon77 : Nested monitor calls + - monitors should be release before acquiring a new one. + +Horst Wettstein : The problem of nested monitor calls revisited + - Solves nested monitor by allowing barging + +David L. Parnas : The non problem of nesied monitor calls + - not an actual problem in real life + +M. Joseph and VoR. Prasad : More on nested monitor call + - WTF... don't use monitors, use pure classes instead, whatever that is + +Joseph et al, 1978). + +Toby bloom : Evaluating Synchronization Mechanisms + - Methods to evaluate concurrency + Index: doc/proposals/concurrency/notes.md =================================================================== --- doc/proposals/concurrency/notes.md (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) +++ doc/proposals/concurrency/notes.md (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -0,0 +1,14 @@ +Internal scheduling notes. + +Internal scheduling requires a stack or queue to make sense. +We also need a stack of "monitor contexts" to be able to restuore stuff. + +Multi scheduling try 1 + - adding threads to many monitors and synching the monitors + - Too hard + +Multi scheduling try 2 + - using a leader when in a group + - it's hard but doable to manage who is the leader and keep the current context + - basically __monitor_guard_t always saves an restore the leader and current context + Index: doc/proposals/concurrency/style.tex =================================================================== --- doc/proposals/concurrency/style.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/proposals/concurrency/style.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -1,3 +1,5 @@ \input{common} % bespoke macros used in the document + +\CFADefaultStyle \lstset{ Index: doc/proposals/concurrency/version =================================================================== --- doc/proposals/concurrency/version (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/proposals/concurrency/version (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -1,1 +1,1 @@ -0.7.61 +0.7.134 Index: doc/refrat/refrat.tex =================================================================== --- doc/refrat/refrat.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/refrat/refrat.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:52:25 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Mon Feb 20 13:08:11 2017 -%% Update Count : 78 +%% Last Modified On : Wed Apr 5 23:23:28 2017 +%% Update Count : 79 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -48,5 +48,5 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\CFADefaultStyle % use default CFA format-style +\CFAStyle % use default CFA format-style % inline code ©...© (copyright symbol) emacs: C-q M-) Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 122aecd1d7210e548fcc07170850004dd4eb2e64) +++ doc/user/user.tex (revision 3a48e283f52a273668725dbaba2755c0ab637ed1) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Thu Mar 23 09:53:57 2017 -%% Update Count : 1399 +%% Last Modified On : Wed Apr 5 23:19:40 2017 +%% Update Count : 1412 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -50,5 +50,5 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\CFADefaultStyle % use default CFA format-style +\CFAStyle % use default CFA format-style % inline code ©...© (copyright symbol) emacs: C-q M-) @@ -154,5 +154,5 @@ \begin{tabular}{@{}l@{\hspace{3em}}l@{}} \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{lstlisting} +\begin{cfa} #include 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 ?