Index: doc/LaTeXmacros/lstlang.sty =================================================================== --- doc/LaTeXmacros/lstlang.sty (revision ff98952225b16a68fb22c007b5495c78ef23158e) +++ doc/LaTeXmacros/lstlang.sty (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) @@ -8,6 +8,6 @@ %% Created On : Sat May 13 16:34:42 2017 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Sat May 13 16:49:09 2017 -%% Update Count : 4 +%% Last Modified On : Fri May 26 12:47:09 2017 +%% Update Count : 8 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -118,4 +118,12 @@ } +% uC++ programming language, based on ANSI C++ +\lstdefinelanguage{uC++}[ANSI]{C++}{ + morekeywords={ + _Accept, _AcceptReturn, _AcceptWait, _Actor, _At, _CatchResume, _Cormonitor, _Coroutine, _Disable, + _Else, _Enable, _Event, _Finally, _Monitor, _Mutex, _Nomutex, _PeriodicTask, _RealTimeTask, + _Resume, _Select, _SporadicTask, _Task, _Timeout, _When, _With, _Throw}, +} + % Local Variables: % % tab-width: 4 % Index: doc/bibliography/cfa.bib =================================================================== --- doc/bibliography/cfa.bib (revision ff98952225b16a68fb22c007b5495c78ef23158e) +++ doc/bibliography/cfa.bib (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) @@ -3035,4 +3035,14 @@ year = 1992, pages = {T1-53}, +} + +@manual{GMP, + keywords = {GMP arbitrary-precision library}, + contributer = {pabuhr@plg}, + title = {{GNU} Multiple Precision Arithmetic Library}, + author = {GMP}, + organization= {GNU}, + year = 2016, + note = {\href{https://gmplib.org}{https://\-gmplib.org}}, } Index: doc/proposals/user_conversions.md =================================================================== --- doc/proposals/user_conversions.md (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) +++ doc/proposals/user_conversions.md (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) @@ -0,0 +1,205 @@ +## User-defined Conversions ## +C's implicit "usual arithmetic conversions" define a structure among the +built-in types consisting of _unsafe_ narrowing conversions and a hierarchy of +_safe_ widening conversions. +There is also a set of _explicit_ conversions that are only allowed through a +cast expression. +Based on Glen's notes on conversions [1], I propose that safe and unsafe +conversions be expressed as constructor variants, though I make explicit +(cast) conversions a constructor variant as well rather than a dedicated +operator. +Throughout this article, I will use the following operator names for +constructors and conversion functions from `From` to `To`: + + void ?{} ( To*, To ); // copy constructor + void ?{} ( To*, From ); // explicit constructor + void ?{explicit} ( To*, From ); // explicit cast conversion + void ?{safe} ( To*, From ); // implicit safe conversion + void ?{unsafe} ( To*, From ); // implicit unsafe conversion + +[1] http://plg.uwaterloo.ca/~cforall/Conversions/index.html + +Glen's design made no distinction between constructors and unsafe implicit +conversions; this is elegant, but interacts poorly with tuples. +Essentially, without making this distinction, a constructor like the following +would add an interpretation of any two `int`s as a `Coord`, needlessly +multiplying the space of possible interpretations of all functions: + + void ?{}( Coord *this, int x, int y ); + +That said, it would certainly be possible to make a multiple-argument implicit +conversion, as below, though the argument above suggests this option should be +used infrequently: + + void ?{unsafe}( Coord *this, int x, int y ); + +An alternate possibility would be to only count two-arg constructors +`void ?{} ( To*, From )` as unsafe conversions; under this semantics, safe and +explicit conversions should also have a compiler-enforced restriction to +ensure that they are two-arg functions (this restriction may be valuable +regardless). + +Regardless of syntax, there should be a type assertion that expresses `From` +is convertable to `To`. +If user-defined conversions are not added to the language, +`void ?{} ( To*, From )` may be a suitable representation, relying on +conversions on the argument types to account for transitivity. +On the other hand, `To*` should perhaps match its target type exactly, so +another assertion syntax specific to conversions may be required, e.g. +`From -> To`. + +### Constructor Idiom ### +Basing our notion of conversions off otherwise normal Cforall functions means +that we can use the full range of Cforall features for conversions, including +polymorphism. +Glen [1] defines a _constructor idiom_ that can be used to create chains of +safe conversions without duplicating code; given a type `Safe` which members +of another type `From` can be directly converted to, the constructor idiom +allows us to write a conversion for any type `To` which `Safe` converts to: + + forall(otype To | { void ?{safe}( To*, Safe ) }) + void ?{safe}( To *this, From that ) { + Safe tmp = /* some expression involving that */; + *this = tmp; // uses assertion parameter + } + +This idiom can also be used with only minor variations for a parallel set of +unsafe conversions. + +What selective non-use of the constructor idiom gives us is the ability to +define a conversion that may only be the *last* conversion in a chain of such. +Constructing a conversion graph able to unambiguously represent the full +hierarchy of implicit conversions in C is provably impossible using only +single-step conversions with no additional information (see Appendix A), but +this mechanism is sufficiently powerful (see [1], though the design there has +some minor bugs; the general idea is to use the constructor idiom to define +two chains of conversions, one among the signed integral types, another among +the unsigned, and to use monomorphic conversions to allow conversions between +signed and unsigned integer types). + +### Appendix A: Partial and Total Orders ### +The `<=` relation on integers is a commonly known _total order_, and +intuitions based on how it works generally apply well to other total orders. +Formally, a total order is some binary relation `<=` over a set `S` such that +for any two members `a` and `b` of `S`, `a <= b` or `b <= a` (if both, `a` and +`b` must be equal, the _antisymmetry_ property); total orders also have a +_transitivity_ property, that if `a <= b` and `b <= c`, then `a <= c`. +If `a` and `b` are distinct elements and `a <= b`, we may write `a < b`. + +A _partial order_ is a generalization of this concept where the `<=` relation +is not required to be defined over all pairs of elements in `S` (though there +is a _reflexivity_ requirement that for all `a` in `S`, `a <= a`); in other +words, it is possible for two elements `a` and `b` of `S` to be +_incomparable_, unable to be ordered with respect to one another (any `a` and +`b` for which either `a <= b` or `b <= a` are called _comparable_). +Antisymmetry and transitivity are also required for a partial order, so all +total orders are also partial orders by definition. +One fairly natural partial order is the "subset of" relation over sets from +the same universe; `{ }` is a subset of both `{ 1 }` and `{ 2 }`, which are +both subsets of `{ 1, 2 }`, but neither `{ 1 }` nor `{ 2 }` is a subset of the +other - they are incomparable under this relation. + +We can compose two (or more) partial orders to produce a new partial order on +tuples drawn from both (or all the) sets. +For example, given `a` and `c` from set `S` and `b` and `d` from set `R`, +where both `S` and `R` both have partial orders defined on them, we can define +a ordering relation between `(a, b)` and `(c, d)`. +One common order is the _lexicographical order_, where `(a, b) <= (c, d)` iff +`a < c` or both `a = c` and `b <= d`; this can be thought of as ordering by +the first set and "breaking ties" by the second set. +Another common order is the _product order_, which can be roughly thought of +as "all the components are ordered the same way"; formally `(a, b) <= (c, d)` +iff `a <= c` and `b <= d`. +One difference between the lexicographical order and the product order is that +in the lexicographical order if both `a` and `c` and `b` and `d` are +comparable then `(a, b)` and `(c, d)` will be comparable, while in the product +order you can have `a <= c` and `d <= b` (both comparable) which will make +`(a, b)` and `(c, d)` incomparable. +The product order, on the other hand, has the benefit of not prioritizing one +order over the other. + +Any partial order has a natural representation as a directed acyclic graph +(DAG). +Each element `a` of the set becomes a node of the DAG, with an arc pointing to +its _covering_ elements, any element `b` such that `a < b` but where there is +no `c` such that `a < c` and `c < b`. +Intuitively, the covering elements are the "next ones larger", where you can't +fit another element between the two. +Under this construction, `a < b` is equivalent to "there is a path from `a` to +`b` in the DAG", and the lack of cycles in the directed graph is ensured by +the antisymmetry property of the partial order. + +Partial orders can be generalized to _preorders_ by removing the antisymmetry +property. +In a preorder the relation is generally called `<~`, and it is possible for +two distict elements `a` and `b` to have `a <~ b` and `b <~ a` - in this case +we write `a ~ b`; `a <~ b` and not `a ~ b` is written `a < b`. +Preorders may also be represented as directed graphs, but in this case the +graph may contain cycles. + +### Appendix B: Building a Conversion Graph from Un-annotated Single Steps ### +The short answer is that it's impossible. + +The longer answer is that it has to do with what's essentially a diamond +inheritance problem. +In C, `int` converts to `unsigned int` and also `long` "safely"; both convert +to `unsigned long` safely, and it's possible to chain the conversions to +convert `int` to `unsigned long`. +There are two constraints here; one is that the `int` to `unsigned long` +conversion needs to cost more than the other two (because the types aren't as +"close" in a very intuitive fashion), and the other is that the system needs a +way to choose which path to take to get to the destination type. +Now, a fairly natural solution for this would be to just say "C knows how to +convert from `int` to `unsigned long`, so we just put in a direct conversion +and make the compiler smart enough to figure out the costs" - this is the +approach taken by the existing compipler, but given that in a user-defined +conversion proposal the users can build an arbitrary graph of conversions, +this case still needs to be handled. + +We can define a preorder over the types by saying that `a <~ b` if there +exists a chain of conversions from `a` to `b` (see Appendix A for description +of preorders and related constructs). +This preorder corresponds roughly to a more usual type-theoretic concept of +subtyping ("if I can convert `a` to `b`, `a` is a more specific type than +`b`"); however, since this graph is arbitrary, it may contain cycles, so if +there is also a path to convert `b` to `a` they are in some sense equivalently +specific. + +Now, to compare the cost of two conversion chains `(s, x1, x2, ... xn)` and +`(s, y1, y2, ... ym)`, we have both the length of the chains (`n` versus `m`) +and this conversion preorder over the destination types `xn` and `ym`. +We could define a preorder by taking chain length and breaking ties by the +conversion preorder, but this would lead to unexpected behaviour when closing +diamonds with an arm length of longer than 1. +Consider a set of types `A`, `B1`, `B2`, `C` with the arcs `A->B1`, `B1->B2`, +`B2->C`, and `A->C`. +If we are comparing conversions from `A` to both `B2` and `C`, we expect the +conversion to `B2` to be chosen because it's the more specific type under the +conversion preorder, but since its chain length is longer than the conversion +to `C`, it loses and `C` is chosen. +However, taking the conversion preorder and breaking ties or ambiguities by +chain length also doesn't work, because of cases like the following example +where the transitivity property is broken and we can't find a global maximum: + + `X->Y1->Y2`, `X->Z1->Z2->Z3->W`, `X->W` + +In this set of arcs, if we're comparing conversions from `X` to each of `Y2`, +`Z3` and `W`, converting to `Y2` is cheaper than converting to `Z3`, because +there are no conversions between `Y2` and `Z3`, and `Y2` has the shorter chain +length. +Also, comparing conversions from `X` to `Z3` and to `W`, we find that the +conversion to `Z3` is cheaper, because `Z3 < W` by the conversion preorder, +and so is considered to be the nearer type. +By transitivity, then, the conversion from `X` to `Y2` should be cheaper than +the conversion from `X` to `W`, but in this case the `X` and `W` are +incomparable by the conversion preorder, so the tie is broken by the shorter +path from `X` to `W` in favour of `W`, contradicting the transitivity property +for this proposed order. + +Without transitivity, we would need to compare all pairs of conversions, which +would be expensive, and possibly not yield a minimal-cost conversion even if +all pairs were comparable. +In short, this ordering is infeasible, and by extension I believe any ordering +composed solely of single-step conversions between types with no further +user-supplied information will be insufficiently powerful to express the +built-in conversions between C's types. Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision ff98952225b16a68fb22c007b5495c78ef23158e) +++ doc/user/user.tex (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Sun May 21 23:36:42 2017 -%% Update Count : 1822 +%% Last Modified On : Wed May 24 22:21:42 2017 +%% Update Count : 1994 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -151,5 +151,5 @@ Like \Index*[C++]{\CC}, there may be both an old and new ways to achieve the same effect. -For example, the following programs compare the \CFA and C I/O mechanisms. +For example, the following programs compare the \CFA, C, nad \CC I/O mechanisms, where the programs output the same result. \begin{quote2} \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}} @@ -183,5 +183,4 @@ \end{tabular} \end{quote2} -The programs output the same result. While the \CFA I/O looks similar to the \Index*[C++]{\CC} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}). @@ -1426,5 +1425,28 @@ -\section{Type/Routine Nesting} +\section{Unnamed Structure Fields} + +C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg: +\begin{cfa} +struct { + int f1; §\C{// named field}§ + int f2 : 4; §\C{// named field with bit field size}§ + int : 3; §\C{// unnamed field for basic type with bit field size}§ + int ; §\C{// disallowed, unnamed field}§ + int *; §\C{// disallowed, unnamed field}§ + int (*)(int); §\C{// disallowed, unnamed field}§ +}; +\end{cfa} +This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. +As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. +A list of unnamed fields is also supported, \eg: +\begin{cfa} +struct { + int , , ; §\C{// 3 unnamed fields}§ +} +\end{cfa} + + +\section{Nesting} Nesting of types and routines is useful for controlling name visibility (\newterm{name hiding}). @@ -1796,27 +1818,4 @@ -\section{Unnamed Structure Fields} - -C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg: -\begin{cfa} -struct { - int f1; §\C{// named field}§ - int f2 : 4; §\C{// named field with bit field size}§ - int : 3; §\C{// unnamed field for basic type with bit field size}§ - int ; §\C{// disallowed, unnamed field}§ - int *; §\C{// disallowed, unnamed field}§ - int (*)(int); §\C{// disallowed, unnamed field}§ -}; -\end{cfa} -This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. -As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. -A list of unnamed fields is also supported, \eg: -\begin{cfa} -struct { - int , , ; §\C{// 3 unnamed fields}§ -} -\end{cfa} - - \section{Field Tuples} @@ -1861,58 +1860,33 @@ While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure. -Unfortunately, this restriction forces programmers to use ©goto© to achieve the equivalent control-flow for more than one level of nesting. -To prevent having to switch to the ©goto©, \CFA extends the ©continue©\index{continue@©continue©}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and ©break©\index{break@©break©}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}. +Unfortunately, this restriction forces programmers to use \Indexc{goto} to achieve the equivalent control-flow for more than one level of nesting. +To prevent having to switch to the ©goto©, \CFA extends the \Indexc{continue}\index{continue@©continue©!labelled}\index{labelled!continue@©continue©} and \Indexc{break}\index{break@©break©!labelled}\index{labelled!break@©break©} with a target label to support static multi-level exit\index{multi-level exit}\index{static multi-level exit}~\cite{Buhr85,Java}. For both ©continue© and ©break©, the target label must be directly associated with a ©for©, ©while© or ©do© statement; for ©break©, the target label can also be associated with a ©switch©, ©if© or compound (©{}©) statement. - -The following example shows the labelled ©continue© specifying which control structure is the target for the next loop iteration: -\begin{quote2} -\begin{tabular}{@{}l@{\hspace{3em}}l@{}} -\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{cfa} -®L1:® do { - ®L2:® while ( ... ) { - ®L3:® for ( ... ) { - ... continue ®L1®; ... // continue do - ... continue ®L2®; ... // continue while - ... continue ®L3®; ... // continue for - } // for - } // while -} while ( ... ); -\end{cfa} -& -\begin{cfa} -do { - while ( ... ) { - for ( ... ) { - ... goto L1; ... - ... goto L2; ... - ... goto L3; ... - L3: ; } - L2: ; } -L1: ; } while ( ... ); -\end{cfa} -\end{tabular} -\end{quote2} -The innermost loop has three restart points, which cause the next loop iteration to begin. - -The following example shows the labelled ©break© specifying which control structure is the target for exit: -\begin{quote2} -\begin{tabular}{@{}l@{\hspace{3em}}l@{}} -\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ -\begin{cfa} -®L1:® { +\VRef[Figure]{f:MultiLevelResumeTermination} shows the labelled ©continue© and ©break©, specifying which control structure is the target for exit, and the corresponding C program using only ©goto©. +The innermost loop has 7 exit points, which cause resumption or termination of one or more of the 7 \Index{nested control-structure}s. + +\begin{figure} +\begin{tabular}{@{\hspace{\parindentlnth}}l@{\hspace{1.5em}}l@{}} +\multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ +\begin{cfa} +®LC:® { ... §declarations§ ... - ®L2:® switch ( ... ) { + ®LS:® switch ( ... ) { case 3: - ®L3:® if ( ... ) { - ®L4:® for ( ... ) { - ... break ®L1®; ... // exit compound statement - ... break ®L2®; ... // exit switch - ... break ®L3®; ... // exit if - ... break ®L4®; ... // exit loop + ®LIF:® if ( ... ) { + ®LF:® for ( ... ) { + ®LW:® while ( ... ) { + ... break ®LC®; ... // terminate compound + ... break ®LS®; ... // terminate switch + ... break ®LIF®; ... // terminate if + ... continue ®LF;® ... // resume loop + ... break ®LF®; ... // terminate loop + ... continue ®LW®; ... // resume loop + ... break ®LW®; ... // terminate loop + } // while } // for } else { - ... break ®L3®; ... // exit if + ... break ®LIF®; ... // terminate if } // if } // switch @@ -1925,31 +1899,37 @@ switch ( ... ) { case 3: - if ( ... ) { + if ( ... ) { for ( ... ) { - ... goto L1; ... - ... goto L2; ... - ... goto L3; ... - ... goto L4; ... - } L4: ; + for ( ... ) { + ... goto ®LC®; ... + ... goto ®LS®; ... + ... goto ®LIF®; ... + ... goto ®LFC®; ... + ... goto ®LFB®; ... + ... goto ®LWC®; ... + ... goto ®LWB®; ... + ®LWC®: ; } ®LWB:® ; + ®LFC:® ; } ®LFB:® ; } else { - ... goto L3; ... - } L3: ; - } L2: ; -} L1: ; + ... goto ®LIF®; ... + } ®L3:® ; + } ®LS:® ; +} ®LC:® ; \end{cfa} \end{tabular} -\end{quote2} -The innermost loop has four exit points, which cause termination of one or more of the four \Index{nested control structure}s. - -Both ©continue© and ©break© with target labels are simply a ©goto©\index{goto@©goto©!restricted} restricted in the following ways: +\caption{Multi-level Resume/Termination} +\label{f:MultiLevelResumeTermination} +\end{figure} + +Both labelled ©continue© and ©break© are a ©goto©\index{goto@©goto©!restricted} restricted in the following ways: \begin{itemize} \item -They cannot be used to create a loop. -This means that only the looping construct can be used to create a loop. -This restriction is important since all situations that can result in repeated execution of statements in a program are clearly delineated. -\item -Since they always transfer out of containing control structures, they cannot be used to branch into a control structure. +They cannot create a loop, which means only the looping constructs cause looping. +This restriction means all situations resulting in repeated execution are clearly delineated. +\item +They cannot branch into a control structure. +This restriction prevents missing initialization at the start of a control structure resulting in undefined behaviour. \end{itemize} -The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement and tying control flow to the target control structure rather than an arbitrary point in a program. +The advantage of the labelled ©continue©/©break© is allowing static multi-level exits without having to use the ©goto© statement, and tying control flow to the target control structure rather than an arbitrary point in a program. Furthermore, the location of the label at the \emph{beginning} of the target control structure informs the reader that complex control-flow is occurring in the body of the control structure. With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. @@ -2268,5 +2248,5 @@ \index{input/output library} -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. +The goal of \CFA I/O is to simplify the common cases\index{I/O!common case}, while fully supporting polymorphism and user defined types in a consistent way. The common case is printing out a sequence of variables separated by whitespace. \begin{quote2} @@ -2274,5 +2254,5 @@ \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{\CC}} \\ \begin{cfa} -int x = 0, y = 1, z = 2; +int x = 1, y = 2, z = 3; sout | x ®|® y ®|® z | endl; \end{cfa} @@ -2281,10 +2261,25 @@ cout << x ®<< " "® << y ®<< " "® << z << endl; +\end{cfa} +\\ +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +1 2 3 +\end{cfa} +& +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +1 2 3 \end{cfa} \end{tabular} \end{quote2} The \CFA form has half as many characters as the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators. - -The logical-or operator is used because it is the lowest-priority overloadable operator, other than assignment. +A tuple prints all the tuple's values, each separated by ©", "©. +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] +[int, int] t1 = [1, 2], t2 = [3, 4]; +sout | t1 | t2 | endl; §\C{// print tuples}§ +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,belowskip=0pt] +1, 2, 3, 4 +\end{cfa} +\CFA uses the logical-or operator for I/O because it is the lowest-priority overloadable operator, other than assignment. Therefore, fewer output expressions require parenthesis. \begin{quote2} @@ -2299,5 +2294,10 @@ & \begin{cfa} -cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl; +cout << x * 3 << y + 1 << ®(®z << 2®)® << ®(®x == y®)® << (x | y) << (x || y) << (x > z ? 1 : 2) << endl; +\end{cfa} +\\ +& +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] +3 3 12 0 3 1 2 \end{cfa} \end{tabular} @@ -2305,4 +2305,5 @@ Finally, the logical-or operator has a link with the Shell pipe-operator for moving data, where data flows in the correct direction for input but the opposite direction for output. + The implicit separator\index{I/O separator} character (space/blank) is a separator not a terminator. The rules for implicitly adding the separator are: @@ -2316,4 +2317,5 @@ 1 2 3 \end{cfa} + \item A separator does not appear before or after a character literal or variable. @@ -2322,6 +2324,7 @@ 123 \end{cfa} -\item -A separator does not appear before or after a null (empty) C string + +\item +A separator does not appear before or after a null (empty) C string. \begin{cfa} sout | 1 | "" | 2 | "" | 3 | endl; @@ -2329,6 +2332,7 @@ \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]@([{=$£¥¡¿«@ + +\item +A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off,basicstyle=\tt]@([{=$£¥¡¿«@ %$ \begin{cfa}[mathescape=off] @@ -2337,29 +2341,64 @@ \end{cfa} %$ -\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 +\begin{cfa}[mathescape=off,basicstyle=\tt,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{cfa} %$ +where \lstinline[basicstyle=\tt]@¡¿@ are inverted opening exclamation and question marks, and \lstinline[basicstyle=\tt]@«@ is an opening citation mark. + \item {\lstset{language=CFA,deletedelim=**[is][]{¢}{¢}} -A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.;!?)]}%¢»© +A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[basicstyle=\tt]@,.;!?)]}%¢»@ \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" | endl; \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§\textcent§ x 8» x 9) x 10] x 11} x +\begin{cfa}[basicstyle=\tt,showspaces=true,aboveskip=0pt,belowskip=0pt] +1®,® x 2®.® x 3®;® x 4®!® x 5®?® x 6®%® x 7§\color{red}\textcent§ x 8®»® x 9®)® x 10®]® x 11®}® x \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@ +where \lstinline[basicstyle=\tt]@»@ is a closing citation mark. + +\item +A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[basicstyle=\tt,showspaces=true]@`'": \t\v\f\r\n@ \begin{cfa}[belowskip=0pt] sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl; \end{cfa} -\begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] -x`1`x'2'x"3"x:4:x 5 x 6 x +\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] +x®`®1®`®x§\color{red}\texttt{'}§2§\color{red}\texttt{'}§x§\color{red}\texttt{"}§3§\color{red}\texttt{"}§x®:®4®:®x® ®5® ®x® ®6® ®x +\end{cfa} + +\item +If a space is desired before or after one of the special string start/end characters, simply insert a space. +\begin{cfa}[belowskip=0pt] +sout | "x (§\color{red}\texttt{\textvisiblespace}§" | 1 | "§\color{red}\texttt{\textvisiblespace}§) x" | 2 | "§\color{red}\texttt{\textvisiblespace}§, x" | 3 | "§\color{red}\texttt{\textvisiblespace}§:x:§\color{red}\texttt{\textvisiblespace}§" | 4 | endl; +\end{cfa} +\begin{cfa}[basicstyle=\tt,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] +x (® ®1® ®) x 2® ®, x 3® ®:x:® ®4 \end{cfa} \end{enumerate} -The following \CC-style \Index{manipulator}s allow control over implicit seperation. +The following routines and \CC-style \Index{manipulator}s control implicit seperation. +\begin{enumerate} +\item +Routines \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} and \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} set and get the separator string. +The separator string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters). +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] +sepSet( sout, ", $" ); §\C{// set separator from " " to ", \$"}§ +sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl; +\end{cfa} +%$ +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] +1, $2, $3 ®", $"® +\end{cfa} +%$ +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] +sepSet( sout, " " ); §\C{// reset separator to " "}§ +sout | 1 | 2 | 3 | " \"" | ®sepGet( sout )® | "\"" | endl; +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] +1 2 3 ®" "® +\end{cfa} + +\item Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item. \begin{cfa}[mathescape=off,belowskip=0pt] @@ -2375,4 +2414,6 @@ 12 3 \end{cfa} + +\item Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted. \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] @@ -2394,51 +2435,33 @@ 1 2 3 \end{cfa} -Printing a tuple outputs all the tuple's values separated by ©", "©: + +\item +Routine \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} and \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} get and set the tuple separator-string. +The tuple separator-string can be at most 16 characters including the ©'\0'© string terminator (15 printable characters). \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] -sout | [2, 3] | [4, 5] | endl; §\C{// print tuple}§ +sepSetTuple( sout, " " ); §\C{// set tuple separator from ", " to " "}§ +sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl; +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] +1 2 3 4 ®" "® +\end{cfa} +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] +sepSetTuple( sout, ", " ); §\C{// reset tuple separator to ", "}§ +sout | t1 | t2 | " \"" | ®sepGetTuple( sout )® | "\"" | endl; +\end{cfa} +\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] +1, 2, 3, 4 ®", "® +\end{cfa} + +\item +The tuple separator can also be turned on and off. +\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] +sout | sepOn | t1 | sepOff | t2 | endl; §\C{// locally turn on/off implicit separation}§ \end{cfa} \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] -2, 3, 4, 5 -\end{cfa} -The tuple separator can also be turned on and off: -\begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] -sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; §\C{// locally turn on/off implicit separation}§ -\end{cfa} -\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] -, 2, 34, 5 +, 1, 23, 4 \end{cfa} Notice a tuple seperator starts the line because the next item is a tuple. -Finally, the stream routines \Indexc{sepGet}\index{manipulator!sepGet@©sepGet©} and \Indexc{sepSet}\index{manipulator!sepSet@©sepSet©} get and set the basic separator-string. -\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] -sepSet( sout, ", $" ); §\C{// set separator from " " to ", \$"}§ -sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl; -\end{cfa} -%$ -\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] -1, $2, $3 ", $" -\end{cfa} -%$ -\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] -sepSet( sout, " " ); §\C{// reset separator to " "}§ -sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl; -\end{cfa} -\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] -1 2 3 " " -\end{cfa} -and the stream routines \Indexc{sepGetTuple}\index{manipulator!sepGetTuple@©sepGetTuple©} and \Indexc{sepSetTuple}\index{manipulator!sepSetTuple@©sepSetTuple©} get and set the tuple separator-string. -\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] -sepSetTuple( sout, " " ); §\C{// set tuple separator from ", " to " "}§ -sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl; -\end{cfa} -\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] -2 3 4 5 " " -\end{cfa} -\begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] -sepSetTuple( sout, ", " ); §\C{// reset tuple separator to ", "}§ -sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl; -\end{cfa} -\begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] -2, 3, 4, 5 ", " -\end{cfa} +\end{enumerate} \begin{comment} @@ -2446,6 +2469,9 @@ int main( void ) { - int x = 0, y = 1, z = 2; - sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl | endl; + int x = 1, y = 2, z = 3; + sout | x | y | z | endl; + [int, int] t1 = [1, 2], t2 = [3, 4]; + sout | t1 | t2 | endl; // print tuple + sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl; sout | 1 | 2 | 3 | endl; sout | '1' | '2' | '3' | endl; @@ -2456,13 +2482,5 @@ | 7 | "¢ x" | 8 | "» x" | 9 | ") x" | 10 | "] x" | 11 | "} x" | endl; sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x:" | 4 | ":x " | 5 | " x\t" | 6 | "\tx" | endl; - - sout | sepOn | 1 | 2 | 3 | sepOn | endl; // separator at start of line - sout | 1 | sepOff | 2 | 3 | endl; // locally turn off implicit separator - sout | sepDisable | 1 | 2 | 3 | endl; // globally turn off implicit separation - sout | 1 | sepOn | 2 | 3 | endl; // locally turn on implicit separator - sout | sepEnable | 1 | 2 | 3 | endl; // globally turn on implicit separation - - sout | [2, 3] | [4, 5] | endl; // print tuple - sout | sepOn | [2, 3] | sepOff | [4, 5] | endl; // locally turn on/off implicit separation + sout | "x ( " | 1 | " ) x" | 2 | " , x" | 3 | " :x: " | 4 | endl; sepSet( sout, ", $" ); // set separator from " " to ", $" @@ -2471,12 +2489,23 @@ sout | 1 | 2 | 3 | " \"" | sepGet( sout ) | "\"" | endl; + sout | sepOn | 1 | 2 | 3 | sepOn | endl; // separator at start of line + sout | 1 | sepOff | 2 | 3 | endl; // locally turn off implicit separator + + sout | sepDisable | 1 | 2 | 3 | endl; // globally turn off implicit separation + sout | 1 | sepOn | 2 | 3 | endl; // locally turn on implicit separator + sout | sepEnable | 1 | 2 | 3 | endl; // globally turn on implicit separation + sepSetTuple( sout, " " ); // set tuple separator from ", " to " " - sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl; + sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl; sepSetTuple( sout, ", " ); // reset tuple separator to ", " - sout | [2, 3] | [4, 5] | " \"" | sepGetTuple( sout ) | "\"" | endl; + sout | t1 | t2 | " \"" | sepGetTuple( sout ) | "\"" | endl; + + sout | t1 | t2 | endl; // print tuple + sout | sepOn | t1 | sepOff | t2 | endl; // locally turn on/off implicit separation } // Local Variables: // // tab-width: 4 // +// fill-column: 100 // // End: // \end{comment} @@ -2972,5 +3001,5 @@ generic (type T | bool ??( T, T ); } ) -T max( const T t1, const T t2 );§\indexc{max}§ +T max( T t1, T t2 );§\indexc{max}§ forall( otype T | { T min( T, T ); T max( T, T ); } ) @@ -5232,5 +5307,5 @@ \label{s:Math Library} -The \CFA math-library wraps many existing explicitly-polymorphic C math-routines into implicitly-polymorphic versions. +The \CFA math-library wraps explicitly-polymorphic C math-routines into implicitly-polymorphic versions. @@ -5239,11 +5314,4 @@ \leavevmode \begin{cfa}[aboveskip=0pt,belowskip=0pt] -float fabs( float );§\indexc{fabs}§ -double fabs( double ); -long double fabs( long double ); -float cabs( float _Complex ); -double cabs( double _Complex ); -long double cabs( long double _Complex ); - float ?%?( float, float );§\indexc{fmod}§ float fmod( float, float ); @@ -5600,4 +5668,258 @@ +\section{Multi-precision Integers} +\label{s:MultiPrecisionIntegers} + +\CFA has an interface to the \Index{GMP} \Index{multi-precision} signed-integers~\cite{GMP}, similar to the \CC interface provided by GMP. +The \CFA interface wraps GMP routines into operator routines to make programming with multi-precision integers identical to using fixed-sized integers. +The \CFA type name for multi-precision signed-integers is \Indexc{Int}. + +\begin{cfa} +void ?{}( Int * this ); §\C{// constructor}§ +void ?{}( Int * this, Int init ); +void ?{}( Int * this, zero_t ); +void ?{}( Int * this, one_t ); +void ?{}( Int * this, signed long int init ); +void ?{}( Int * this, unsigned long int init ); +void ?{}( Int * this, const char * val ); +void ^?{}( Int * this ); + +Int ?=?( Int * lhs, Int rhs ); §\C{// assignment}§ +Int ?=?( Int * lhs, long int rhs ); +Int ?=?( Int * lhs, unsigned long int rhs ); +Int ?=?( Int * lhs, const char * rhs ); + +char ?=?( char * lhs, Int rhs ); +short int ?=?( short int * lhs, Int rhs ); +int ?=?( int * lhs, Int rhs ); +long int ?=?( long int * lhs, Int rhs ); +unsigned char ?=?( unsigned char * lhs, Int rhs ); +unsigned short int ?=?( unsigned short int * lhs, Int rhs ); +unsigned int ?=?( unsigned int * lhs, Int rhs ); +unsigned long int ?=?( unsigned long int * lhs, Int rhs ); + +long int narrow( Int val ); +unsigned long int narrow( Int val ); + +int ?==?( Int oper1, Int oper2 ); §\C{// comparison}§ +int ?==?( Int oper1, long int oper2 ); +int ?==?( long int oper2, Int oper1 ); +int ?==?( Int oper1, unsigned long int oper2 ); +int ?==?( unsigned long int oper2, Int oper1 ); + +int ?!=?( Int oper1, Int oper2 ); +int ?!=?( Int oper1, long int oper2 ); +int ?!=?( long int oper1, Int oper2 ); +int ?!=?( Int oper1, unsigned long int oper2 ); +int ?!=?( unsigned long int oper1, Int oper2 ); + +int ??( Int oper1, Int oper2 ); +int ?>?( Int oper1, long int oper2 ); +int ?>?( long int oper1, Int oper2 ); +int ?>?( Int oper1, unsigned long int oper2 ); +int ?>?( unsigned long int oper1, Int oper2 ); + +int ?>=?( Int oper1, Int oper2 ); +int ?>=?( Int oper1, long int oper2 ); +int ?>=?( long int oper1, Int oper2 ); +int ?>=?( Int oper1, unsigned long int oper2 ); +int ?>=?( unsigned long int oper1, Int oper2 ); + +Int +?( Int oper ); §\C{// arithmetic}§ +Int -?( Int oper ); +Int ~?( Int oper ); + +Int ?&?( Int oper1, Int oper2 ); +Int ?&?( Int oper1, long int oper2 ); +Int ?&?( long int oper1, Int oper2 ); +Int ?&?( Int oper1, unsigned long int oper2 ); +Int ?&?( unsigned long int oper1, Int oper2 ); +Int ?&=?( Int * lhs, Int rhs ); + +Int ?|?( Int oper1, Int oper2 ); +Int ?|?( Int oper1, long int oper2 ); +Int ?|?( long int oper1, Int oper2 ); +Int ?|?( Int oper1, unsigned long int oper2 ); +Int ?|?( unsigned long int oper1, Int oper2 ); +Int ?|=?( Int * lhs, Int rhs ); + +Int ?^?( Int oper1, Int oper2 ); +Int ?^?( Int oper1, long int oper2 ); +Int ?^?( long int oper1, Int oper2 ); +Int ?^?( Int oper1, unsigned long int oper2 ); +Int ?^?( unsigned long int oper1, Int oper2 ); +Int ?^=?( Int * lhs, Int rhs ); + +Int ?+?( Int addend1, Int addend2 ); +Int ?+?( Int addend1, long int addend2 ); +Int ?+?( long int addend2, Int addend1 ); +Int ?+?( Int addend1, unsigned long int addend2 ); +Int ?+?( unsigned long int addend2, Int addend1 ); +Int ?+=?( Int * lhs, Int rhs ); +Int ?+=?( Int * lhs, long int rhs ); +Int ?+=?( Int * lhs, unsigned long int rhs ); +Int ++?( Int * lhs ); +Int ?++( Int * lhs ); + +Int ?-?( Int minuend, Int subtrahend ); +Int ?-?( Int minuend, long int subtrahend ); +Int ?-?( long int minuend, Int subtrahend ); +Int ?-?( Int minuend, unsigned long int subtrahend ); +Int ?-?( unsigned long int minuend, Int subtrahend ); +Int ?-=?( Int * lhs, Int rhs ); +Int ?-=?( Int * lhs, long int rhs ); +Int ?-=?( Int * lhs, unsigned long int rhs ); +Int --?( Int * lhs ); +Int ?--( Int * lhs ); + +Int ?*?( Int multiplicator, Int multiplicand ); +Int ?*?( Int multiplicator, long int multiplicand ); +Int ?*?( long int multiplicand, Int multiplicator ); +Int ?*?( Int multiplicator, unsigned long int multiplicand ); +Int ?*?( unsigned long int multiplicand, Int multiplicator ); +Int ?*=?( Int * lhs, Int rhs ); +Int ?*=?( Int * lhs, long int rhs ); +Int ?*=?( Int * lhs, unsigned long int rhs ); + +Int ?/?( Int dividend, Int divisor ); +Int ?/?( Int dividend, unsigned long int divisor ); +Int ?/?( unsigned long int dividend, Int divisor ); +Int ?/?( Int dividend, long int divisor ); +Int ?/?( long int dividend, Int divisor ); +Int ?/=?( Int * lhs, Int rhs ); +Int ?/=?( Int * lhs, long int rhs ); +Int ?/=?( Int * lhs, unsigned long int rhs ); + +[ Int, Int ] div( Int dividend, Int divisor ); +[ Int, Int ] div( Int dividend, unsigned long int divisor ); + +Int ?%?( Int dividend, Int divisor ); +Int ?%?( Int dividend, unsigned long int divisor ); +Int ?%?( unsigned long int dividend, Int divisor ); +Int ?%?( Int dividend, long int divisor ); +Int ?%?( long int dividend, Int divisor ); +Int ?%=?( Int * lhs, Int rhs ); +Int ?%=?( Int * lhs, long int rhs ); +Int ?%=?( Int * lhs, unsigned long int rhs ); + +Int ?<>?( Int shiften, mp_bitcnt_t shift ); +Int ?>>=?( Int * lhs, mp_bitcnt_t shift ); + +Int abs( Int oper ); §\C{// number functions}§ +Int fact( unsigned long int N ); +Int gcd( Int oper1, Int oper2 ); +Int pow( Int base, unsigned long int exponent ); +Int pow( unsigned long int base, unsigned long int exponent ); +void srandom( gmp_randstate_t state ); +Int random( gmp_randstate_t state, mp_bitcnt_t n ); +Int random( gmp_randstate_t state, Int n ); +Int random( gmp_randstate_t state, mp_size_t max_size ); +int sgn( Int oper ); +Int sqrt( Int oper ); + +forall( dtype istype | istream( istype ) ) istype * ?|?( istype * is, Int * mp ); §\C{// I/O}§ +forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype * os, Int mp ); +\end{cfa} + +The following factorial programs contrast using GMP with the \CFA and C interfaces, where the output from these programs appears in \VRef[Figure]{f:MultiPrecisionFactorials}. +(Compile with flag \Indexc{-lgmp} to link with the GMP library.) +\begin{quote2} +\begin{tabular}{@{}l@{\hspace{\parindentlnth}}|@{\hspace{\parindentlnth}}l@{}} +\multicolumn{1}{c|@{\hspace{\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}} \\ +\hline +\begin{cfa} +#include +int main( void ) { + sout | "Factorial Numbers" | endl; + Int fact; + fact = 1; + sout | 0 | fact | endl; + for ( unsigned int i = 1; i <= 40; i += 1 ) { + fact *= i; + sout | i | fact | endl; + } +} +\end{cfa} +& +\begin{cfa} +#include +int main( void ) { + ®gmp_printf®( "Factorial Numbers\n" ); + ®mpz_t® fact; + ®mpz_init_set_ui®( fact, 1 ); + ®gmp_printf®( "%d %Zd\n", 0, fact ); + for ( unsigned int i = 1; i <= 40; i += 1 ) { + ®mpz_mul_ui®( fact, fact, i ); + ®gmp_printf®( "%d %Zd\n", i, fact ); + } +} +\end{cfa} +\end{tabular} +\end{quote2} + +\begin{figure} +\begin{cfa} +Factorial Numbers +0 1 +1 1 +2 2 +3 6 +4 24 +5 120 +6 720 +7 5040 +8 40320 +9 362880 +10 3628800 +11 39916800 +12 479001600 +13 6227020800 +14 87178291200 +15 1307674368000 +16 20922789888000 +17 355687428096000 +18 6402373705728000 +19 121645100408832000 +20 2432902008176640000 +21 51090942171709440000 +22 1124000727777607680000 +23 25852016738884976640000 +24 620448401733239439360000 +25 15511210043330985984000000 +26 403291461126605635584000000 +27 10888869450418352160768000000 +28 304888344611713860501504000000 +29 8841761993739701954543616000000 +30 265252859812191058636308480000000 +31 8222838654177922817725562880000000 +32 263130836933693530167218012160000000 +33 8683317618811886495518194401280000000 +34 295232799039604140847618609643520000000 +35 10333147966386144929666651337523200000000 +36 371993326789901217467999448150835200000000 +37 13763753091226345046315979581580902400000000 +38 523022617466601111760007224100074291200000000 +39 20397882081197443358640281739902897356800000000 +40 815915283247897734345611269596115894272000000000 +\end{cfa} +\caption{Multi-precision Factorials} +\label{f:MultiPrecisionFactorials} +\end{figure} + + \section{Rational Numbers} \label{s:RationalNumbers} @@ -5612,21 +5934,16 @@ }; // Rational -// constants -extern struct Rational 0; -extern struct Rational 1; - -// constructors -Rational rational(); +Rational rational(); §\C{// constructors}§ Rational rational( long int n ); Rational rational( long int n, long int d ); - -// getter/setter for numerator/denominator -long int numerator( Rational r ); +void ?{}( Rational * r, zero_t ); +void ?{}( Rational * r, one_t ); + +long int numerator( Rational r ); §\C{// numerator/denominator getter/setter}§ long int numerator( Rational r, long int n ); long int denominator( Rational r ); long int denominator( Rational r, long int d ); -// comparison -int ?==?( Rational l, Rational r ); +int ?==?( Rational l, Rational r ); §\C{// comparison}§ int ?!=?( Rational l, Rational r ); int ?=?( Rational l, Rational r ); -// arithmetic -Rational -?( Rational r ); +Rational -?( Rational r ); §\C{// arithmetic}§ Rational ?+?( Rational l, Rational r ); Rational ?-?( Rational l, Rational r ); @@ -5642,10 +5958,8 @@ Rational ?/?( Rational l, Rational r ); -// conversion -double widen( Rational r ); +double widen( Rational r ); §\C{// conversion}§ Rational narrow( double f, long int md ); -// I/O -forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); +forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); // I/O forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational ); \end{cfa} Index: doc/working/resolver_design.md =================================================================== --- doc/working/resolver_design.md (revision ff98952225b16a68fb22c007b5495c78ef23158e) +++ doc/working/resolver_design.md (revision 4a3685479ce3ea742a9282c31d31ce031849e49c) @@ -41,4 +41,13 @@ ensure that they are two-arg functions (this restriction may be valuable regardless). + +Regardless of syntax, there should be a type assertion that expresses `From` +is convertable to `To`. +If user-defined conversions are not added to the language, +`void ?{} ( To*, From )` may be a suitable representation, relying on +conversions on the argument types to account for transitivity. +On the other hand, `To*` should perhaps match its target type exactly, so +another assertion syntax specific to conversions may be required, e.g. +`From -> To`. ### Constructor Idiom ###