Changes in / [bcef6c8:599fbb6]


Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/general/Paper.tex

    rbcef6c8 r599fbb6  
    142142% replace/adjust listing characters that look bad in sanserif
    143143literate={-}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.1ex}}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1
    144         {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
     144        {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1
    145145        {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2,
    146146moredelim=**[is][\color{red}]{`}{`},
     
    12901290The object is the implicit qualifier for the open structure-fields.
    12911291
    1292 All expressions in the expression list are open in parallel within the compound statement.
     1292All expressions in the expression list are open in ``parallel'' within the compound statement.
    12931293This semantic is different from Pascal, which nests the openings from left to right.
    12941294The difference between parallel and nesting occurs for fields with the same name and type:
     
    13361336with ( (S)w ) { ... }                                           $\C{// unambiguous, cast}$
    13371337\end{cfa}
    1338 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
     1338and @with@ expressions may be pointers and references (see Section~\ref{s:References}) to aggregates:
    13391339\begin{cfa}
    13401340struct S { int i, j; } sv;
    1341 with ( sv ) {                                                           $\C{implicit reference}$
     1341with ( sv ) {                                                           $\C{variable}$
    13421342        S & sr = sv;
    1343         with ( sr ) {                                                   $\C{explicit reference}$
     1343        with ( sr ) {                                                   $\C{reference}$
    13441344                S * sp = &sv;
    1345                 with ( *sp ) {                                          $\C{computed reference}$
     1345                with ( *sp ) {                                          $\C{pointer}$
    13461346                        i = 3; j = 4;                                   $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$
    13471347                }
    1348                 i = 2; j = 3;                                           $\C{\color{red}// sr.i, sr.j}$
     1348                i = 3; j = 4;                                           $\C{\color{red}// sr.i, sr.j}$
    13491349        }
    1350         i = 1; j = 2;                                                   $\C{\color{red}// sv.i, sv.j}$
     1350        i = 3; j = 4;                                                   $\C{\color{red}// sv.i, sv.j}$
    13511351}
    13521352\end{cfa}
     
    13641364_Exception E { int fix; };
    13651365void f() {
    1366         E e;
    1367         ... _Resume e;
    1368         ... e.fix // control returns here after handler
     1366        ... _Resume E;
     1367        // control returns here after handler
    13691368try {
    13701369        f();
     
    13771376_Exception E {};
    13781377void f() {
    1379 
    1380         ... _Throw E{};
     1378        ... _Throw E;
    13811379        // control does NOT return here after handler
    13821380try {
     
    13931391\section{Declarations}
    13941392
    1395 Declarations in C have weaknesses and omissions.
    1396 \CFA attempts to correct and add to C declarations, while ensuring \CFA subjectively ``feels like'' C.
    1397 An important part of this subjective feel is maintaining C's syntax and procedural paradigm, as opposed to functional and object-oriented approaches in other systems languages such as \CC and Rust.
    1398 Maintaining the C approach means that C coding-patterns remain not only useable but idiomatic in \CFA, reducing the mental burden of retraining C programmers and switching between C and \CFA development.
    1399 Nevertheless, some features from other approaches are undeniably convenient;
    1400 \CFA attempts to adapt these features to the C paradigm.
     1393It is important that \CFA subjectively ``feel like'' C to programmers.
     1394An 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.
     1395Maintaining 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.
     1396Nonetheless, some features of object-oriented languages are undeniably convenient but are independent of object-oriented programming;
     1397\CFA adapts these features to a procedural paradigm.
    14011398
    14021399
     
    15411538\lstMakeShortInline@%
    15421539\end{cquote}
    1543 Specifiers must appear at the start of a \CFA routine declaration\footnote{\label{StorageClassSpecifier}.
     1540All specifiers must appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}
    15441541The 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}}.
    15451542
     
    16671664\end{lrbox}
    16681665Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{
    1669 While effort has been put into non-null reference checking in \CC and Java, the exercise seems moot for any non-managed languages (C/\CC), given that it only handles one of many different error situations:
     1666While effort has been put into non-null reference checking in \CC, the exercise seems moot for any non-managed languages, given that it only handles one of many different error situations:
    16701667\begin{cquote}
    16711668\usebox{\LstBox}
     
    17211718
    17221719
    1723 \subsection{Type Nesting}
    1724 
    1725 Nested types provide a mechanism to organize associated types and refactor a subset of fields into a named aggregate (\eg sub-aggregates @name@, @address@, @department@, within aggregate @employe@).
    1726 Java nested types are dynamic (apply to objects), \CC are static (apply to the \lstinline[language=C++]@class@), and C hoists (refactors) nested types into the enclosing scope, meaning there is no need for type qualification.
    1727 Since \CFA in not object-oriented, adopting dynamic scoping does not make sense;
    1728 instead \CFA adopts \CC static nesting, using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@'' (see Figure~\ref{f:TypeNestingQualification}).
    1729 \begin{figure}
    1730 \centering
    1731 \lstDeleteShortInline@%
    1732 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
    1733 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
    1734 \hline
    1735 \begin{cfa}
    1736 struct S {
    1737         enum C { R, G, B };
    1738         struct T {
    1739                 union U { int i, j; };
    1740                 enum C c;
    1741                 short int i, j;
    1742         };
    1743         struct T t;
    1744 } s;
    1745 
    1746 int rtn() {
    1747         s.t.c = R;
    1748         struct T t = { R, 1, 2 };
    1749         enum C c;
    1750         union U u;
    1751 }
    1752 \end{cfa}
    1753 &
    1754 \begin{cfa}
    1755 enum C { R, G, B };
    1756 union U { int i, j; };
    1757 struct T {
    1758         enum C c;
    1759         short int i, j;
    1760 };
    1761 struct S {
    1762         struct T t;
    1763 } s;
    1764        
    1765 
    1766 
    1767 
    1768 
    1769 
    1770 
    1771 \end{cfa}
    1772 &
    1773 \begin{cfa}
    1774 struct S {
    1775         enum C { R, G, B };
    1776         struct T {
    1777                 union U { int i, j; };
    1778                 enum C c;
    1779                 short int i, j;
    1780         };
    1781         struct T t;
    1782 } s;
    1783 
    1784 int rtn() {
    1785         s.t.c = `S.`R;  // type qualification
    1786         struct `S.`T t = { `S.`R, 1, 2 };
    1787         enum `S.`C c;
    1788         union `S.T.`U u;
    1789 }
    1790 \end{cfa}
    1791 \end{tabular}
    1792 \lstMakeShortInline@%
    1793 \caption{Type Nesting / Qualification}
    1794 \label{f:TypeNestingQualification}
    1795 \end{figure}
    1796 In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
    1797 In the right example in \CFA, the types are not hoisted and accessed .
    1798 
    1799 
    18001720\subsection{Constructors and Destructors}
    18011721
     
    18871807Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics.
    18881808The point of \lstinline|@=| is to provide a migration path from legacy C code to \CFA, by providing a mechanism to incrementally convert to implicit initialization.
     1809
     1810
     1811\subsection{Type Nesting}
     1812
     1813\CFA allows \newterm{type nesting}, and type qualification of the nested types (see Figure~\ref{f:TypeNestingQualification}), where as C hoists (refactors) nested types into the enclosing scope and has no type qualification.
     1814\begin{figure}
     1815\centering
     1816\lstDeleteShortInline@%
     1817\begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
     1818\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
     1819\hline
     1820\begin{cfa}
     1821struct S {
     1822        enum C { R, G, B };
     1823        struct T {
     1824                union U { int i, j; };
     1825                enum C c;
     1826                short int i, j;
     1827        };
     1828        struct T t;
     1829} s;
     1830
     1831int rtn() {
     1832        s.t.c = R;
     1833        struct T t = { R, 1, 2 };
     1834        enum C c;
     1835        union U u;
     1836}
     1837\end{cfa}
     1838&
     1839\begin{cfa}
     1840enum C { R, G, B };
     1841union U { int i, j; };
     1842struct T {
     1843        enum C c;
     1844        short int i, j;
     1845};
     1846struct S {
     1847        struct T t;
     1848} s;
     1849       
     1850
     1851
     1852
     1853
     1854
     1855
     1856\end{cfa}
     1857&
     1858\begin{cfa}
     1859struct S {
     1860        enum C { R, G, B };
     1861        struct T {
     1862                union U { int i, j; };
     1863                enum C c;
     1864                short int i, j;
     1865        };
     1866        struct T t;
     1867} s;
     1868
     1869int rtn() {
     1870        s.t.c = `S.`R;  // type qualification
     1871        struct `S.`T t = { `S.`R, 1, 2 };
     1872        enum `S.`C c;
     1873        union `S.T.`U u;
     1874}
     1875\end{cfa}
     1876\end{tabular}
     1877\lstMakeShortInline@%
     1878\caption{Type Nesting / Qualification}
     1879\label{f:TypeNestingQualification}
     1880\end{figure}
     1881In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.
     1882In the right example in \CFA, the types are not hoisted and accessed using the field-selection operator ``@.@'' for type qualification, as does Java, rather than the \CC type-selection operator ``@::@''.
    18891883
    18901884
Note: See TracChangeset for help on using the changeset viewer.