Changeset 5479e63
- Timestamp:
- Jul 13, 2016, 8:22:11 AM (9 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- ed9ecda
- Parents:
- e4d3ceb
- Location:
- doc
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/LaTeXmacros/common.tex
re4d3ceb r5479e63 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sun Jul 10 12:34:09201614 %% Update Count : 20 513 %% Last Modified On : Tue Jul 12 20:37:57 2016 14 %% Update Count : 206 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 238 238 \lstMakeShortInline© % single-character for \lstinline 239 239 240 \let\Oldthebibliography\thebibliography 241 \renewcommand\thebibliography[1]{ 242 \Oldthebibliography{#1} 243 \setlength{\parskip}{0pt} % reduce vertical spacing between references 244 \setlength{\itemsep}{5pt plus 0.3ex} 245 }% 246 240 247 % Local Variables: % 241 248 % tab-width: 4 % -
doc/user/user.tex
re4d3ceb r5479e63 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sun Jul 10 12:52:09 201614 %% Update Count : 12 0013 %% Last Modified On : Wed Jul 13 08:14:39 2016 14 %% Update Count : 1247 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 294 294 \item 295 295 \Indexc{-nodebug}\index{compilation option!-nodebug@©-nodebug©} 296 The program is linked with the non-debugging version of the unikernel or multikernel, so the execution of the program is faster.296 The program is linked with the non-debugging version of the runtime system, so the execution of the program is faster. 297 297 \Emph{However, no runtime checks or ©assert©s are performed so errors usually result in abnormal program termination.} 298 298 … … 721 721 ®&®crc = &cx; §\C{// error, cannot change crc}§ 722 722 \end{lstlisting} 723 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}. 724 In effect, 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. 723 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}, e.g.: 724 \begin{lstlisting} 725 int & const r = *0; §\C{// where 0 is the int * zero}§ 726 \end{lstlisting} 727 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. 725 728 726 729 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object. … … 735 738 \begin{lstlisting} 736 739 int & f( int & rp ); §\C{// reference parameter and return}§ 737 z = f( x ) + f( y ); §\C{// reference operator added }§740 z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§ 738 741 \end{lstlisting} 739 742 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©. 740 The return reference from ©f© is copied into a compiler generated temporary, which is treated as an initialization.743 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. 741 744 742 745 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. … … 1646 1649 \end{lstlisting} 1647 1650 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: 1651 \begin{quote2} 1652 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1648 1653 \begin{lstlisting} 1649 1654 switch ( argc ) { … … 1658 1663 } 1659 1664 \end{lstlisting} 1665 & 1666 \begin{lstlisting} 1667 1668 if ( argc == 3 ) { 1669 // open output file 1670 ®// open input file 1671 ®} else if ( argc == 2 ) { 1672 ®// open input file 1673 1674 ®} else { 1675 // usage message 1676 } 1677 \end{lstlisting} 1678 \end{tabular} 1679 \end{quote2} 1660 1680 In this example, case 2 is always done if case 3 is done. 1661 1681 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. … … 1672 1692 \end{lstlisting} 1673 1693 However, this situation is handled in other languages without fall-through by allowing a list of case values. 1674 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is not intuitive to mostprogrammers and is different from virtually all other programming languages with a ©switch© statement.1694 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. 1675 1695 Hence, default fall-through semantics results in a large number of programming errors as programmers often forget the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through. 1676 1696 … … 1682 1702 if ( j < k ) { 1683 1703 ... 1684 case 1: // transfer into "if" statement 1685 if ( j < m ) { 1686 ... 1687 case 2: // transfer into "if" statement 1688 ... 1689 } 1690 } 1691 case 3: 1704 ®case 1:® // transfer into "if" statement 1705 ... 1706 } // if 1707 case 2: 1692 1708 while ( j < 5 ) { 1693 1709 ... 1694 case 4:// transfer into "while" statement1710 ®case 3:® // transfer into "while" statement 1695 1711 ... 1696 } 1697 } 1712 } // while 1713 } // switch 1698 1714 \end{lstlisting} 1699 1715 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties. … … 1734 1750 \begin{lstlisting} 1735 1751 switch ( x ) { 1736 int y = 1;§\C{// unreachable initialization}§1737 x = 7; §\C{// unreachable code}§1752 ®int y = 1;® §\C{// unreachable initialization}§ 1753 ®x = 7;® §\C{// unreachable code without label/branch}§ 1738 1754 case 3: ... 1739 y = 3;1740 1755 ... 1756 ®int z = 0;® §\C{// unreachable initialization, cannot appear after case}§ 1757 z = 2; 1758 case 3: 1759 ®x = z;® §\C{// without fall through, z is uninitialized}§ 1741 1760 } 1742 1761 \end{lstlisting} 1743 1762 While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. 1744 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transfered to using a ©goto©, either from outside or inside of the ©switch©. 1745 As mentioned, transfer into control structures should be forbidden. 1746 Transfers from within the ©switch© body using a ©goto© are equally unpalatable. 1763 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©. 1764 As mentioned, transfer into control structures should be forbidden; 1765 transfers from within the ©switch© body using a ©goto© are equally unpalatable. 1766 As well, the declaration of ©z© is cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1747 1767 \end{enumerate} 1768 1748 1769 Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program: 1749 1770 \begin{itemize} … … 1757 1778 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound. 1758 1779 \end{itemize} 1759 These observations help to put the effects of suggested changesinto perspective.1780 These observations help to put the suggested changes to the ©switch© into perspective. 1760 1781 \begin{enumerate} 1761 1782 \item … … 1767 1788 still work. 1768 1789 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. 1769 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no fall-through semantics. 1770 The ©choose© statement is identical to the new ©switch© statement, except there is no implicit fall-through between case-clauses and the ©break© statement applies to the enclosing loop construct (as for the ©continue© statement in a ©switch© statement). 1771 It is still possible to fall-through if a case-clause ends with the new keyword ©fallthru©, e.g.: 1790 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 ©fallthru©, e.g.: 1772 1791 \begin{lstlisting} 1773 1792 ®choose® ( i ) { 1774 case 3:1793 case 1: case 2: case 3: 1775 1794 ... 1776 ®fallthru®; §\C{// explicit fall through}§ 1777 case 5: 1778 ... §\C{// implicit end of switch}§ 1795 ®// implicit end of switch (break) 1796 ®case 5: 1797 ... 1798 ®fallthru®; §\C{// explicit fall through}§ 1779 1799 case 7: 1780 1800 ... 1781 ®break® §\C{// transfer to end of enclosing loop /switch}§1801 ®break® §\C{// explicit end of switch}§ 1782 1802 default: 1783 1803 j = 3; 1784 1804 } 1785 1805 \end{lstlisting} 1786 The ability to fall-through is retained because it is a sufficient C-idiom that most C programmers simply expect it, and its absence might discourage these programmers from using the ©choose© statement. 1787 \item 1788 Eliminating \Index*{Duff's device} is straightforward and only invalidates a small amount of very questionable code. 1789 The solution is to allow ©case© clauses to only appear at the same nesting level as the ©switch© body, as is done in most other programming languages with ©switch© statements. 1806 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses; 1807 the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause. 1808 The explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement. 1809 As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers. 1810 \item 1811 \Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code. 1812 Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements. 1790 1813 \item 1791 1814 The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end. 1792 Therefore, no language change is made for this issue. 1793 \item 1794 Dealing with unreachable code at the start of a ©switch© statement is solved by defining the declaration-list, including any associated initialization, at the start of a ©switch© statement body to be executed \emph{before} the transfer to the appropriate ©case© clause. 1795 This semantics is the same as for declarations at the start of a loop body, which are executed before each iteration of the loop body. 1796 As well, statements cannot appear before the first ©case© clause. 1797 The change is compatible for declarations with initialization in this context because existing code cannot assume the initialization has occurred. 1798 The change is incompatible for statements, but any existing code using it is highly questionable, as in: 1799 \begin{lstlisting} 1800 switch ( i ) { 1801 L: x = 5; §\C{// questionable code}§ 1815 Therefore, no change is made for this issue. 1816 \item 1817 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause.\footnote{ 1818 Essentially, these declarations are hoisted before the statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause. 1819 Further declaration in the statement body are disallowed. 1820 \begin{lstlisting} 1821 switch ( x ) { 1822 ®int i = 0;® §\C{// allowed}§ 1802 1823 case 0: 1803 1824 ... 1804 } 1805 \end{lstlisting} 1806 The statement after the ©switch© can never be executed unless it is labelled. 1807 If it is labelled, it must be transfered to from outside or inside the ©switch© statement, neither of which is acceptable control flow. 1825 ®int i = 0;® §\C{// disallowed}§ 1826 case 1: 1827 { 1828 ®int i = 0;® §\C{// allowed in any compound statement}§ 1829 ... 1830 } 1831 ... 1832 } 1833 \end{lstlisting} 1808 1834 \end{enumerate} 1809 1835 … … 1887 1913 \section{Exception Handling} 1888 1914 1889 Exception handling provides two mechani m: change of control flow from a raise to a handler, and commumication from the riase to the handler.1915 Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler. 1890 1916 \begin{lstlisting} 1891 1917 exception void h( int i ); … … 2140 2166 A facility that let programmers declare specific constants..const Rational 12., for instance. would not be much of an improvement. 2141 2167 Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed. 2142 The complexity of such a feature does n.t seem worth the gain.2168 The complexity of such a feature does not seem worth the gain. 2143 2169 2144 2170 For example, to define the constants for a complex type, the programmer would define the following: … … 2668 2694 } s; 2669 2695 \end{lstlisting} 2670 The problem occurs in acces ing these fields using the selection operation ``©.©'':2696 The problem occurs in accessing these fields using the selection operation ``©.©'': 2671 2697 \begin{lstlisting} 2672 2698 s.0 = 0; // ambiguity with floating constant .0 … … 2678 2704 ®s.§\textvisiblespace§1® = 1; 2679 2705 \end{lstlisting} 2680 While this sy tact is awkward, it is unlikely many programers will name fields of a structure 0 or 1.2706 While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1. 2681 2707 Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser. 2682 2708 … … 2990 3016 In \CFA, multiple definitions are not necessary. 2991 3017 Within a module, all of the module's global definitions are visible throughout the module. 2992 For example, the following code compiles, even though isOddwas not declared before being called:3018 For example, the following code compiles, even though ©isOdd© was not declared before being called: 2993 3019 \begin{lstlisting} 2994 3020 bool isEven(unsigned int x) { … … 4330 4356 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism: 4331 4357 \begin{lstlisting} 4332 int `otype` = 3; // make keyword an i ndentifier4358 int `otype` = 3; // make keyword an identifier 4333 4359 double `choose` = 3.5; 4334 4360 \end{lstlisting} … … 4467 4493 \begin{description} 4468 4494 \item[Change:] comma expression is disallowed as subscript 4469 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new sty ple arrays.4495 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays. 4470 4496 \item[Effect on original feature:] change to semantics of well-defined feature. 4471 4497 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© … … 4479 4505 \index{input/output library} 4480 4506 4481 The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting pol morphism and user defined types in a consistent way.4507 The goal for the \CFA I/O is to make I/O as simple as possible in the common cases, while fully supporting polymorphism and user defined types in a consistent way. 4482 4508 The common case is printing out a sequence of variables separated by whitespace. 4483 4509 \begin{quote2} … … 4516 4542 Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, although data flows in the opposite direction. 4517 4543 4518 The implicit sep erator\index{I/O separator} character (space/blank) is a separator not a terminator.4544 The implicit separator\index{I/O separator} character (space/blank) is a separator not a terminator. 4519 4545 The rules for implicitly adding the separator are: 4520 4546 \begin{enumerate} 4521 4547 \item 4522 A sep erator does not appear at the start or end of a line.4548 A separator does not appear at the start or end of a line. 4523 4549 \begin{lstlisting}[belowskip=0pt] 4524 4550 sout | 1 | 2 | 3 | endl; … … 4528 4554 \end{lstlisting} 4529 4555 \item 4530 A sep erator does not appear before or after a character literal or variable.4556 A separator does not appear before or after a character literal or variable. 4531 4557 \begin{lstlisting} 4532 4558 sout | '1' | '2' | '3' | endl; … … 4534 4560 \end{lstlisting} 4535 4561 \item 4536 A sep erator does not appear before or after a null (empty) C string4562 A separator does not appear before or after a null (empty) C string 4537 4563 \begin{lstlisting} 4538 4564 sout | 1 | "" | 2 | "" | 3 | endl; … … 4541 4567 which is a local mechanism to disable insertion of the separator character. 4542 4568 \item 4543 A sep erator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{$£¥¡¿«@4569 A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{$£¥¡¿«@ 4544 4570 %$ 4545 4571 \begin{lstlisting}[mathescape=off] … … 4744 4770 4745 4771 4746 \subsection{min / max / swap}4772 \subsection{min / max / clamp / swap} 4747 4773 4748 4774 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] … … 4752 4778 forall( otype T | { int ?>?( T, T ); } ) 4753 4779 T max( const T t1, const T t2 );§\indexc{max}§ 4780 4781 forall( otype T | { T min( T, T ); T max( T, T ); } ) 4782 T clamp( T value, T min_val, T max_val );§\indexc{clamp}§ 4754 4783 4755 4784 forall( otype T ) … … 5136 5165 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible. 5137 5166 5138 \begin{lstlisting}[ aboveskip=0pt,belowskip=0pt]5167 \begin{lstlisting}[belowskip=0pt] 5139 5168 // implementation 5140 5169 struct Rational {§\indexc{Rational}§
Note: See TracChangeset
for help on using the changeset viewer.