Changeset ec8bcc4

Timestamp:

Feb 17, 2018, 7:17:15 PM (6 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

29f47139

Parents:

d4933b3

Message:

update alternate declaration syntax

File:

• doc/papers/general/Paper.tex (modified) (8 diffs)

doc/papers/general/Paper.tex

@@ -90 +90 @@
 \newcommand*{\etc}{%
         \@ifnextchar{.}{\ETC}%
-        {\ETC\xspace}%
+        {\ETC.\xspace}%
 }%
-\newcommand{\ETAL}{\abbrevFont{et}\hspace{2pt}\abbrevFont{al}}
+\newcommand{\ETAL}{\abbrevFont{et}~\abbrevFont{al}}
 \newcommand*{\etal}{%
         \@ifnextchar{.}{\protect\ETAL}%
-                {\abbrevFont{\protect\ETAL}.\xspace}%
+                {\protect\ETAL.\xspace}%
 }%
 \newcommand{\VIZ}{\abbrevFont{viz}}
 \newcommand*{\viz}{%
         \@ifnextchar{.}{\VIZ}%
-                {\abbrevFont{\VIZ}.\xspace}%
+                {\VIZ.\xspace}%
 }%
 \makeatother
@@ -120 +120 @@
                 otype, restrict, _Static_assert, throw, throwResume, trait, try, ttype, typeof, __typeof,
                 __typeof__, virtual, with, zero_t},
+        morekeywords=[2]{
+                _Atomic, coroutine, is_coroutine, is_monitor, is_thread, monitor, mutex, nomutex, or,
+                resume, suspend, thread, _Thread_local, waitfor, when, yield},
         moredirectives={defined,include_next}%
-}%
+}
 
 \lstset{
@@ -1361 +1364 @@
 \section{Declarations}
 
-It is important to the design team that \CFA subjectively ``feel like'' C to user programmers.
-An important part of this subjective feel is maintaining C's procedural programming paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust.
-Maintaining this procedural paradigm means that coding patterns that work in C will remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
-Nonetheless, some features of object-oriented languages are undeniably convienient, and the \CFA design team has attempted to adapt them to a procedural paradigm so as to incorporate their benefits into \CFA; two of these features are resource management and name scoping.
+It is important that \CFA subjectively ``feel like'' C to user programmers.
+An important part of this subjective feel is maintaining C's procedural paradigm, as opposed to the object-oriented paradigm of other systems languages such as \CC and Rust.
+Maintaining this procedural paradigm means that C coding-patterns remain not only functional but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
+Nonetheless, some features of object-oriented languages are undeniably convienient but are independent of object-oriented programming;
+\CFA adapts these features to a procedural paradigm.
 
 
 \subsection{Alternative Declaration Syntax}
-
-\newcommand{\R}[1]{\Textbf{#1}}
-\newcommand{\B}[1]{{\Textbf[blue]{#1}}}
-\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}}
 
 C declaration syntax is notoriously confusing and error prone.
@@ -1399 +1399 @@
 \CFA provides its own type, variable and routine declarations, using a different syntax.
 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
-In the following example, \R{red} is the base type and \B{blue} is qualifiers.
-The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
+The qualifiers have the same meaning but are ordered left to right to specify a variable's type.
 \begin{cquote}
 \lstDeleteShortInline@%
-\lstset{moredelim=**[is][\color{blue}]{+}{+}}
 \begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{}}
 \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{C}}        \\
 \begin{cfa}
-+[5] *+ `int` x1;
-+* [5]+ `int` x2;
-`[* [5] int]` f+( int p )+;
-\end{cfa}
-&
-\begin{cfa}
-`int` +*+ x1 +[5]+;
-`int` +(*+x2+)[5]+;
-`int (*`f+( int p )+`)[5]`;
+`[5] *` int x1;
+`* [5]` int x2;
+`[* [5] int]` f( int p );
+\end{cfa}
+&
+\begin{cfa}
+int `*` x1 `[5]`;
+int `(*`x2`)[5]`;
+`int (*`f( int p )`)[5]`;
 \end{cfa}
 \end{tabular}
@@ -1456 +1454 @@
 \end{cquote}
 which is prescribing a safety benefit.
+
+\begin{comment}
 Other examples are:
 \begin{cquote}
@@ -1496 +1496 @@
 \lstMakeShortInline@%
 \end{cquote}
-
-All type qualifiers, \eg @const@, @volatile@, etc., are used in the normal way with the new declarations and also appear left to right, \eg:
+\end{comment}
+
+All specifiers (@extern@, @static@, \etc) and qualifiers (@const@, @volatile@, \etc) are used in the normal way with the new declarations and also appear left to right, \eg:
 \begin{cquote}
 \lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{C}}      \\
-\begin{cfa}
-const * const int x;
-const * [ 5 ] const int y;
-\end{cfa}
-&
-\begin{cfa}
-int const * const x;
-const int (* const y)[ 5 ]
-\end{cfa}
-&
-\begin{cfa}
-// const pointer to const integer
-// const pointer to array of 5 const integers
+\begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}}
+\multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\
+\begin{cfa}
+extern const * const int x;
+static const * [ 5 ] const int y;
+\end{cfa}
+&
+\begin{cfa}
+int extern const * const x;
+static const int (* const y)[ 5 ]
+\end{cfa}
+&
+\begin{cfa}
+// external const pointer to const int
+// internal const pointer to array of 5 const int
 \end{cfa}
 \end{tabular}
 \lstMakeShortInline@%
 \end{cquote}
-All declaration qualifiers, \eg @extern@, @static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
-The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg:
-\begin{cquote}
-\lstDeleteShortInline@%
-\begin{tabular}{@{}l@{\hspace{\parindentlnth}}l@{\hspace{\parindentlnth}}l@{}}
-\multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}}     & \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{C}}      \\
-\begin{cfa}
-extern [ 5 ] int x;
-static * const int y;
-\end{cfa}
-&
-\begin{cfa}
-int extern x[ 5 ];
-const int static * y;
-\end{cfa}
-&
-\begin{cfa}
-// externally visible array of 5 integers
-// internally visible pointer to constant int
-\end{cfa}
-\end{tabular}
-\lstMakeShortInline@%
-\end{cquote}
+All specifiers must appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
+The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}}.
 
 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine @sizeof@:
@@ -1561 +1541 @@
 \end{cquote}
 
-Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
-Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
-Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems.
-
 The syntax of the new routine prototype declaration follows directly from the new routine definition syntax;
 as well, parameter names are optional, \eg:
 \begin{cfa}
 [ int x ] f ();                                                 $\C{// returning int with no parameters}$
-[ * int ] g (int y);                                    $\C{// returning pointer to int with int parameter}$
+[ int x ] f (...);                                              $\C{// returning int with unknown 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}$
@@ -1589 +1566 @@
 \lstMakeShortInline@%
 \end{cquote}
-\CFA allows the last routine in the list to define its body.
-
-Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
-\begin{cfa}
-extern [ int ] f ( int );
-static [ int ] g ( int );
-\end{cfa}
+where \CFA allows the last routine in the list to define its body.
 
 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
 \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{cfa}
-While parameter names are optional, \emph{a routine name cannot be specified};
-for example, the following is incorrect:
-\begin{cfa}
-* [ int x ] f () fp;                                    $\C{// routine name "f" is not allowed}$
-\end{cfa}
+* [ * 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{cfa}
+Note, \emph{a routine name cannot be specified}:
+\begin{cfa}
+* [ int x ] f () fp;                                    $\C{// routine name "f" is disallowed}$
+\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.
+Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style.
+Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems.