Changeset 0111dc7 for doc/rob_thesis/intro.tex

Timestamp:

Apr 13, 2017, 8:29:38 PM (6 years ago)

Author:

Rob Schluntz <rschlunt@…>

Branches:

ADT, aaron-thesis, arm-eh, 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:

1a16e9d

Parents:

c87eb50

Message:

penultimate thesis draft

File:

• doc/rob_thesis/intro.tex (modified) (4 diffs)

doc/rob_thesis/intro.tex

@@ -326 +326 @@
 Invariants help a programmer to reason about code correctness and prove properties of programs.
 
+\begin{sloppypar}
 In object-oriented programming languages, type invariants are typically established in a constructor and maintained throughout the object's lifetime.
 These assertions are typically achieved through a combination of access-control modifiers and a restricted interface.
 Typically, data which requires the maintenance of an invariant is hidden from external sources using the \emph{private} modifier, which restricts reads and writes to a select set of trusted routines, including member functions.
 It is these trusted routines that perform all modifications to internal data in a way that is consistent with the invariant, by ensuring that the invariant holds true at the end of the routine call.
+\end{sloppypar}
 
 In C, the @assert@ macro is often used to ensure invariants are true.
@@ -617 +619 @@
 Tuples support named access and subscript access, among a few other operations.
 \begin{scalacode}
-val a = new Tuple3[Int, String, Double](0, "Text", 2.1)  // explicit creation
-val b = (6, 'a', 1.1f)       // syntactic sugar for Tuple3[Int, Char, Float]
+val a = new Tuple3(0, "Text", 2.1) // explicit creation
+val b = (6, 'a', 1.1f)       // syntactic sugar: Tuple3[Int, Char, Float]
 val (i, _, d) = triple       // extractor syntax, ignore middle element
 
@@ -661 +663 @@
 Still, @printf@ is extremely limited, since the format codes are specified by the C standard, meaning users cannot define their own format codes to extend @printf@ for new data types or new formatting rules.
 
+\begin{sloppypar}
 C provides manipulation of variadic arguments through the @va_list@ data type, which abstracts details of the manipulation of variadic arguments.
 Since the variadic arguments are untyped, it is up to the function to interpret any data that is passed in.
@@ -695 +698 @@
 Furthermore, if the user makes a mistake, compile-time checking is typically restricted to standard format codes and their corresponding types.
 In general, this means that C's variadic functions are not type-safe, making them difficult to use properly.
+\end{sloppypar}
 
 % When arguments are passed to a variadic function, they undergo \emph{default argument promotions}.