- Timestamp:
- Feb 21, 2018, 12:38:14 PM (6 years ago)
- 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:
- 1ccc599, bcef6c8
- Parents:
- b060aba
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/general/Paper.tex
rb060aba r6c7c63c 142 142 % replace/adjust listing characters that look bad in sanserif 143 143 literate={-}{\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 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1144 {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {@}{\small{@}}1 % {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 145 145 {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {->}{\makebox[1ex][c]{\raisebox{0.4ex}{\rule{0.8ex}{0.075ex}}}\kern-0.2ex\textgreater}2, 146 146 moredelim=**[is][\color{red}]{`}{`}, … … 1290 1290 The object is the implicit qualifier for the open structure-fields. 1291 1291 1292 All expressions in the expression list are open in ``parallel''within the compound statement.1292 All expressions in the expression list are open in parallel within the compound statement. 1293 1293 This semantic is different from Pascal, which nests the openings from left to right. 1294 1294 The difference between parallel and nesting occurs for fields with the same name and type: … … 1336 1336 with ( (S)w ) { ... } $\C{// unambiguous, cast}$ 1337 1337 \end{cfa} 1338 and @with@ expressions may be pointers and references (see Section~\ref{s:References}) to aggregates:1338 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate: 1339 1339 \begin{cfa} 1340 1340 struct S { int i, j; } sv; 1341 with ( sv ) { $\C{ variable}$1341 with ( sv ) { $\C{implicit reference}$ 1342 1342 S & sr = sv; 1343 with ( sr ) { $\C{ reference}$1343 with ( sr ) { $\C{explicit reference}$ 1344 1344 S * sp = &sv; 1345 with ( *sp ) { $\C{ pointer}$1345 with ( *sp ) { $\C{computed reference}$ 1346 1346 i = 3; j = 4; $\C{\color{red}// sp-{\textgreater}i, sp-{\textgreater}j}$ 1347 1347 } 1348 i = 3; j = 4; $\C{\color{red}// sr.i, sr.j}$1348 i = 2; j = 3; $\C{\color{red}// sr.i, sr.j}$ 1349 1349 } 1350 i = 3; j = 4; $\C{\color{red}// sv.i, sv.j}$1350 i = 1; j = 2; $\C{\color{red}// sv.i, sv.j}$ 1351 1351 } 1352 1352 \end{cfa} … … 1364 1364 _Exception E { int fix; }; 1365 1365 void f() { 1366 ... _Resume E; 1367 // control returns here after handler 1366 E e; 1367 ... _Resume e; 1368 ... e.fix // control returns here after handler 1368 1369 try { 1369 1370 f(); … … 1376 1377 _Exception E {}; 1377 1378 void f() { 1378 ... _Throw E; 1379 1380 ... _Throw E{}; 1379 1381 // control does NOT return here after handler 1380 1382 try { … … 1391 1393 \section{Declarations} 1392 1394 1393 It is important that \CFA subjectively ``feel like'' C to programmers. 1394 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. 1395 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. 1396 Nonetheless, 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. 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. 1398 1401 1399 1402 … … 1538 1541 \lstMakeShortInline@% 1539 1542 \end{cquote} 1540 All specifiers must appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier} 1543 Specifiers must appear at the start of a \CFA routine declaration\footnote{\label{StorageClassSpecifier}. 1541 1544 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}}. 1542 1545 … … 1664 1667 \end{lrbox} 1665 1668 Rebinding allows \CFA references to be default-initialized (\eg to a null pointer\footnote{ 1666 While 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: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: 1667 1670 \begin{cquote} 1668 1671 \usebox{\LstBox} … … 1718 1721 1719 1722 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 1720 1800 \subsection{Constructors and Destructors} 1721 1801 … … 1807 1887 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|VLA a @= { 0, 0x0 }|, with the usual C initialization semantics. 1808 1888 The 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 \centering1816 \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 \hline1820 \begin{cfa}1821 struct 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 1831 int 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}1840 enum C { R, G, B };1841 union U { int i, j; };1842 struct T {1843 enum C c;1844 short int i, j;1845 };1846 struct S {1847 struct T t;1848 } s;1849 1850 1851 1852 1853 1854 1855 1856 \end{cfa}1857 &1858 \begin{cfa}1859 struct 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 1869 int rtn() {1870 s.t.c = `S.`R; // type qualification1871 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}1881 In the left example in C, types @C@, @U@ and @T@ are implicitly hoisted outside of type @S@ into the containing block scope.1882 In 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 ``@::@''.1883 1889 1884 1890
Note: See TracChangeset
for help on using the changeset viewer.