Changes in / [8da3cc4d:5b643ea]

Location:

doc/theses/mike_brooks_MMath

Files:

• array.tex (modified) (4 diffs)
• programs/hello-accordion.cfa (modified) (3 diffs)
• programs/school1 (added)
• programs/school2 (added)
• string.tex (modified) (2 diffs)

doc/theses/mike_brooks_MMath/array.tex

@@ -205 +205 @@
 Orthogonally, the new @array@ type works with \CFA's generic types, providing argument safety and the associated implicit communication of array length.
 Specifically, \CFA allows aggregate types to be generalized with multiple type parameters, including parameterized element types and lengths.
-Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within other structures.
+Doing so gives a refinement of C's ``flexible array member'' pattern, allowing nesting structures with array members anywhere within the structures.
 \lstinput{10-15}{hello-accordion.cfa}
-This structure's layout has the starting offset of @municipalities@ varying in @NprovTerty@, and the offset of @total_pt@ and @total_mun@ varying in both generic parameters.
-For a function that operates on a @CanPop@ structure, the type system handles this variation transparently.
+This structure's layout has the starting offset of @studentIds@ varying in generic parameter @C@, and the offset of @preferences@ varying in both generic parameters.
+For a function that operates on a @School@ structure, the type system handles this memory layout transparently.
 \lstinput{40-45}{hello-accordion.cfa}
-\VRef[Figure]{f:checkHarness} shows the @CanPop@ harness and results with different array sizes, if the municipalities changed after a census.
+\VRef[Figure]{f:checkHarness} shows the @School@ harness and results with different array sizes, where multidimensional arrays are discussed next.
 
 \begin{figure}
-\lstinput{60-68}{hello-accordion.cfa}
-\lstinput{70-75}{hello-accordion.cfa}
-\caption{\lstinline{check} Harness}
+% super hack to get this to line up
+\begin{tabular}{@{}ll@{\hspace{25pt}}l@{}}
+\begin{tabular}{@{}p{3.25in}@{}}
+\lstinput{60-66}{hello-accordion.cfa}
+\vspace*{-3pt}
+\lstinput{73-80}{hello-accordion.cfa}
+\end{tabular}
+&
+\raisebox{0.32\totalheight}{%
+\lstinput{85-93}{hello-accordion.cfa}
+}%
+&
+\lstinput{95-109}{hello-accordion.cfa}
+\end{tabular}
+\caption{\lstinline{school} Harness and Output}
 \label{f:checkHarness}
 \end{figure}
@@ -488 +500 @@
 From there, @x[all]@ itself is simply a two-dimensional array, in the strict C sense, of these building blocks.
 An atom (like the bottommost value, @x[all][3][2]@), is the contained value (in the square box)
-and a lie about its size (the wedge above it, growing upward).
+and a lie about its size (the left diagonal above it, growing upward).
 An array of these atoms (like the intermediate @x[all][3]@) is just a contiguous arrangement of them, done according to their size;
 call such an array a column.
 A column is almost ready to be arranged into a matrix;
 it is the \emph{contained value} of the next-level building block, but another lie about size is required.
-At first, an atom needs to be arranged as if it were bigger, but now a column needs to be arranged as if it is smaller (the wedge above it, shrinking upward).
+At first, an atom needs to be arranged as if it were bigger, but now a column needs to be arranged as if it is smaller (the left diagonal above it, shrinking upward).
 These lying columns, arranged contiguously according to their size (as announced) form the matrix @x[all]@.
 Because @x[all]@ takes indices, first for the fine stride, then for the coarse stride, it achieves the requirement of representing the transpose of @x@.
@@ -502 +514 @@
 compared with where analogous rows appear when the row-level option is presented for @x@.
 
-\PAB{I don't understand this paragraph: These size lies create an appearance of overlap.
-For example, in \lstinline{x[all]}, the shaded band touches atoms 2.0, 2.1, 2.2, 2.3, 1.4, 1.5 and 1.6.
+For example, in \lstinline{x[all]}, the shaded band touches atoms 2.0, 2.1, 2.2, 2.3, 1.4, 1.5 and 1.6 (left diagonal).
 But only the atom 2.3 is storing its value there.
-The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.}
+The rest are lying about (conflicting) claims on this location, but never exercising these alleged claims.
 
 Lying is implemented as casting.
@@ -511 +522 @@
 This structure uses one type in its internal field declaration and offers a different type as the return of its subscript operator.
 The field within is a plain-C array of the fictional type, which is 7 floats long for @x[all][3][2]@ and 1 float long for @x[all][3]@.
-The subscript operator presents what is really inside, by casting to the type below the wedge of the lie.
+The subscript operator presents what is really inside, by casting to the type below the left diagonal of the lie.
 
 %  Does x[all] have to lie too?  The picture currently glosses over how it it advertises a size of 7 floats.  I'm leaving that as an edge case benignly misrepresented in the picture.  Edge cases only have to be handled right in the code.

doc/theses/mike_brooks_MMath/programs/hello-accordion.cfa

@@ -8 +8 @@
 
 
-forall( T, @[NprovTerty]@, @[Nmunicipalities]@ )
-struct CanPop {
-        array( T, @NprovTerty@ ) provTerty; $\C{// nested VLA}$
-        array( T, @Nmunicipalities@ ) municipalities; $\C{// nested VLA}$
-        int total_pt, total_mun;
+forall( [C], [S] ) $\C{// Class size, Students in class}$
+struct School {
+        @array( int, C )@ classIds; $\C{// nested VLAs}$
+        @array( int, S )@ studentIds;
+        @array( int, C, S )@ preferences; $\C{// multidimensional}$
 };
+
 
 
 // TODO: understand (fix?) why these are needed (autogen seems to be failing ... is typeof as struct member nayok?)
 
-forall( T, [NprovTerty], [Nmunicipalities] )
-        void ?{}( T &, CanPop( T, NprovTerty, Nmunicipalities ) & this ) {}
+forall( [C], [S] )
+void ?{}( School( C, S ) & this ) {}
 
-forall( T &, [NprovTerty], [Nmunicipalities] )
-        void ^?{}( CanPop( T, NprovTerty, Nmunicipalities ) & this ) {}
+forall( [C], [S] )
+        void ^?{}( School( C, S ) & this ) {}
 
 
@@ -37 +38 @@
 
 
-
-forall( T, [NprovTerty], [Nmunicipalities] )
-void check( CanPop( T, NprovTerty, Nmunicipalities ) & pop ) with( pop ) {
-        total_pt = total_mun = 0;
-        for ( i; NprovTerty ) total_pt += provTerty[i];
-        for ( i; Nmunicipalities ) total_mun += municipalities[i];
+forall( [C], [S] )
+void init( @School( C, S ) & classes@, int class, int student, int pref ) with( classes ) {
+        classIds[class] = class; $\C{// handle dynamic offsets of fields within structure}$
+        studentIds[student] = student;
+        preferences[class][student] = pref;
 }
 
@@ -58 +58 @@
 
 
-int main( int argc, char * argv[] ) {
-        const int npt = ato( argv[1] ), nmun = ato( argv[2] );
-        @CanPop( int, npt, nmun ) pop;@
-        // read in population numbers
-        @check( pop );@
-        sout | setlocale( LC_NUMERIC, getenv( "LANG" ) );
-        sout | "Total province/territory:" | pop.total_pt;
-        sout | "Total municipalities:" | pop.total_mun;
+int main() {
+        int classes, students;
+        sin | classes | students;
+        @School( classes, students ) school;@
+        int class, student, preference;
+        // read data into school calling init
+        // for each student's class/preferences
+        try {
+                for ( ) {
+                        sin | class | student | preference;
+                        init( school, class, student, preference );
+                }
+        } catch( end_of_file * ) {}
+        for ( s; students ) {
+                sout | "student" | s | nonl;
+                for ( c; classes ) {
+                        sout | school.preferences[c][s] | nonl;
+                }
+                sout | nl;
+        }
 }
+
+
+
 /*
-$\$$ ./a.out  13  3573
-Total province/territory: 36,991,981
-Total municipalities: 36,991,981
-$\$$ ./a.out  13  3654
-Total province/territory: 36,991,981
-Total municipalities: 36,991,981
+$\$$ cat school1
+2 2
+0 0 1
+1 0 7
+0 1 12
+1 1 13
+$\$$ a.out < school1
+student 0 1 7
+student 1 12 13
+
+$\$$ cat school2
+3 3
+0 0 1
+1 0 7
+2 0 8
+0 1 12
+1 1 13
+2 1 14
+0 2 26
+1 2 27
+2 2 28
+$\$$ a.out < school2
+student 0 1 7 8
+student 1 12 13 14
+student 2 26 27 28
 */
 

doc/theses/mike_brooks_MMath/string.tex

@@ -1 +1 @@
 \chapter{String}
 
-
-
-
-
-\subsection{Logical overlap}
+This chapter presents my work on designing and building a modern string type in \CFA.
+The discussion starts with examples of interesting string problems, followed by examples of how these issues are solved in my design.
+
+
+\section{Logical overlap}
 
 \input{sharing-demo.tex}
@@ -20 +20 @@
 \subsection{RAII limitations}
 
-Earlier work on \CFA [to cite Schluntz] implemented the feature of constructors and destructors.  A constructor is a user-defined function that runs implicitly, when control passes an object's declaration, while a destructor runs at the exit of the declaration's lexical scope.  The feature allows programmers to assume that, whenever a runtime object of a certain type is accessible, the system called one of the programmer's constuctor functions on that object, and a matching destructor call will happen in the future.  The feature helps programmers know that their programs' invariants obtain.
-
-The purposes of such invariants go beyond ensuring authentic values for the bits inside the object.   These invariants can track occurrences of the managed objects in other data structures.  Reference counting is a typical application of the latter invariant type.  With a reference-counting smart pointer, the consturctor and destructor \emph{of the pointer type} track the lifecycles of occurrences of these pointers, by incrementing and decrementing a counter (ususally) on the referent object, that is, they maintain a that is state separate from the objects to whose lifecycles they are attached.  Both the \CC and \CFA RAII systems ares powerful enough to achive such reference counting.
-
-The \CC RAII system supports a more advanced application.  A lifecycle function has access to the object under managamanet, by location; constructors and destuctors receive a @this@ parameter providing its memory address.  A lifecycle-function implementation can then add its objects to a collection upon creation, and remove them at destruction.  A modulue that provides such objects, by using and encapsulating such a collection, can traverse the collection at relevant times, to keep the objects ``good.''  Then, if you are the user of such an module, declaring an object of its type means not only receiving an authentically ``good'' value at initialization, but receiving a subscription to a service that will keep the value ``good'' until you are done with it.
+Earlier work on \CFA [to cite Schluntz] implemented the feature of constructors and destructors.  A constructor is a user-defined function that runs implicitly, when control passes an object's declaration, while a destructor runs at the exit of the declaration's lexical scope.  The feature allows programmers to assume that, whenever a runtime object of a certain type is accessible, the system called one of the programmer's constructor functions on that object, and a matching destructor call will happen in the future.  The feature helps programmers know that their programs' invariants obtain.
+
+The purposes of such invariants go beyond ensuring authentic values for the bits inside the object.   These invariants can track occurrences of the managed objects in other data structures.  Reference counting is a typical application of the latter invariant type.  With a reference-counting smart pointer, the constructor and destructor \emph{of the pointer type} track the life cycles of occurrences of these pointers, by incrementing and decrementing a counter (usually) on the referent object, that is, they maintain a that is state separate from the objects to whose life cycles they are attached.  Both the \CC and \CFA RAII systems ares powerful enough to achieve such reference counting.
+
+The \CC RAII system supports a more advanced application.  A life cycle function has access to the object under management, by location; constructors and destuctors receive a @this@ parameter providing its memory address.  A lifecycle-function implementation can then add its objects to a collection upon creation, and remove them at destruction.  A modulue that provides such objects, by using and encapsulating such a collection, can traverse the collection at relevant times, to keep the objects ``good.''  Then, if you are the user of such an module, declaring an object of its type means not only receiving an authentically ``good'' value at initialization, but receiving a subscription to a service that will keep the value ``good'' until you are done with it.
 
 In many cases, the relationship between memory location and lifecycle is simple.  But with stack-allocated objects being used as parameters and returns, there is a sender version in one stack frame and a receiver version in another.  \CC is able to treat those versions as distinct objects and guarantee a copy-constructor call for communicating the value from one to the other.  This ability has implications on the language's calling convention.  Consider an ordinary function @void f( Vehicle x )@, which receives an aggregate by value.  If the type @Vehicle@ has custom lifecycle functions, then a call to a user-provided copy constructor occurs, after the caller evaluates its argument expression, after the callee's stack frame exists, with room for its variable @x@ (which is the location that the copy-constructor must target), but before the user-provided body of @f@ begins executing.  \CC achieves this ordering by changing the function signature, in the compiled form, to pass-by-reference and having the callee invoke the copy constructor in its preamble.  On the other hand, if @Vehicle@ is a simple structure then the C calling convention is applied as the code originally appeared, that is, the callsite implementation code performs a bitwise copy from the caller's expression result, into the callee's x.