Context Navigation

← Previous Change
Next Change →

intro.tex

Timestamp:

Sep 27, 2021, 2:09:55 PM (3 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, enum, forall-pointer-decay, master, pthread-emulation, qualifiedEnum

Children:

cc287800

Parents:

4e28d2e9 (diff), 056cbdb (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

: 1 edited

doc/theses/andrew_beach_MMath/intro.tex (modified) (18 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/theses/andrew_beach_MMath/intro.tex

-                      r4e28d2e9
+                      r949339b
 All types of exception handling link a raise with a handler.
 Both operations are usually language primitives, although raises can be
 treated as a primitive function that takes an exception argument.
 Handlers are more complex as they are added to and removed from the stack
 during execution, must specify what they can handle and give the code to
+treated as a function that takes an exception argument.
+Handlers are more complex, as they are added to and removed from the stack
+during execution, must specify what they can handle and must give the code to
 handle the exception.
 …
 it returns control to that function.
 \begin{center}
+\input{termination}
+%\input{termination}
+%
+%\medskip
+\input{termhandle.pstex_t}
+% I hate these diagrams, but I can't access xfig to fix them and they are
+% better than the alternative.
 \end{center}
 …
 The handler is run on top of the existing stack, often as a new function or
 closure capturing the context in which the handler was defined.
 After the handler has finished running it returns control to the function
+After the handler has finished running, it returns control to the function
 that preformed the raise, usually starting after the raise.
 \begin{center}
+\input{resumption}
+%\input{resumption}
+%
+%\medskip
+\input{resumhandle.pstex_t}
+% The other one.
 \end{center}
 Although a powerful feature, exception handling tends to be complex to set up
 and expensive to use
+and expensive to use,
 so it is often limited to unusual or ``exceptional" cases.
 The classic example is error handling, exceptions can be used to
+The classic example is error handling; exceptions can be used to
 remove error handling logic from the main execution path, and pay
 most of the cost only when the error actually occurs.
 …
 The \CFA EHM implements all of the common exception features (or an
 equivalent) found in most other EHMs and adds some features of its own.
 The design of all the features had to be adapted to \CFA's feature set as
+The design of all the features had to be adapted to \CFA's feature set, as
 some of the underlying tools used to implement and express exception handling
 in other languages are absent in \CFA.
 Still the resulting syntax resembles that of other languages:
+Still, the resulting syntax resembles that of other languages:
 \begin{cfa}
 try {
 …
 covering both changes to the compiler and the run-time.
 In addition, a suite of test cases and performance benchmarks were created
 along side the implementation.
+alongside the implementation.
 The implementation techniques are generally applicable in other programming
 languages and much of the design is as well.
 …
 \item Implementing stack unwinding and the \CFA EHM, including updating
 the \CFA compiler and the run-time environment.
 \item Designed and implemented a prototype virtual system.
+\item Designing and implementing a prototype virtual system.
 % I think the virtual system and per-call site default handlers are the only
 % "new" features, everything else is a matter of implementation.
 \item Creating tests to check the behaviour of the EHM.
 \item Creating benchmarks to check the performances of the EHM,
+\item Creating benchmarks to check the performance of the EHM,
 as compared to other languages.
 \end{enumerate}
 …
 The rest of this thesis is organized as follows.
 The current state of exceptions is covered in \autoref{s:background}.
 The existing state of \CFA is also covered in \autoref{c:existing}.
+The existing state of \CFA is covered in \autoref{c:existing}.
 New EHM features are introduced in \autoref{c:features},
 covering their usage and design.
 …
 message as a payload\cite{Ada12}.
 The modern flag-ship for termination exceptions is \Cpp,
+The modern flagship for termination exceptions -- if one exists -- is \Cpp,
 which added them in its first major wave of non-object-orientated features
 in 1990.\cite{CppHistory}
 …
 inheriting from
 \code{C++}{std::exception}.
 Although there is a special catch-all syntax (@catch(...)@) there are no
+Although there is a special catch-all syntax (@catch(...)@), there are no
 operations that can be performed on the caught value, not even type inspection.
 Instead the base exception-type \code{C++}{std::exception} defines common
+Instead, the base exception-type \code{C++}{std::exception} defines common
 functionality (such as
 the ability to describe the reason the exception was raised) and all
 …
 Java was the next popular language to use exceptions.\cite{Java8}
 Its exception system largely reflects that of \Cpp, except that requires
+Its exception system largely reflects that of \Cpp, except that it requires
 you throw a child type of \code{Java}{java.lang.Throwable}
 and it uses checked exceptions.
 Checked exceptions are part of a function's interface,
 the exception signature of the function.
 Every function that could be raised from a function, either directly or
+Every exception that could be raised from a function, either directly or
 because it is not handled from a called function, is given.
 Using this information, it is possible to statically verify if any given
 exception is handled and guarantee that no exception will go unhandled.
+exception is handled, and guarantee that no exception will go unhandled.
 Making exception information explicit improves clarity and safety,
 but can slow down or restrict programming.
 …
 recovery or repair. In theory that could be good enough to properly handle
 the exception, but more often is used to ignore an exception that the
 programmer does not feel is worth the effort of handling it, for instance if
+programmer does not feel is worth the effort of handling, for instance if
 they do not believe it will ever be raised.
 If they are incorrect the exception will be silenced, while in a similar
+If they are incorrect, the exception will be silenced, while in a similar
 situation with unchecked exceptions the exception would at least activate
 the language's unhandled exception code (usually program abort with an
+the language's unhandled exception code (usually, a program abort with an
 error message).
 %\subsection
 Resumption exceptions are less popular,
 although resumption is as old as termination; hence, few
+although resumption is as old as termination; that is, few
 programming languages have implemented them.
 % http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/
 …
 included in the \Cpp standard.
 % https://en.wikipedia.org/wiki/Exception_handling
 Since then resumptions have been ignored in main-stream programming languages.
+Since then, resumptions have been ignored in mainstream programming languages.
 However, resumption is being revisited in the context of decades of other
 developments in programming languages.
 While rejecting resumption may have been the right decision in the past,
 the situation has changed since then.
 Some developments, such as the function programming equivalent to resumptions,
+Some developments, such as the functional programming equivalent to resumptions,
 algebraic effects\cite{Zhang19}, are enjoying success.
 A complete reexamination of resumptions is beyond this thesis,
 but there reemergence is enough to try them in \CFA.
+A complete reexamination of resumption is beyond this thesis,
+but their reemergence is enough reason to try them in \CFA.
 % Especially considering how much easier they are to implement than
 % termination exceptions and how much Peter likes them.
 …
 %\subsection
 More recently exceptions seem to be vanishing from newer programming
+More recently, exceptions seem to be vanishing from newer programming
 languages, replaced by ``panic".
 In Rust, a panic is just a program level abort that may be implemented by
 unwinding the stack like in termination exception
 handling.\cite{RustPanicMacro}\cite{RustPanicModule}
 Go's panic through is very similar to a termination, except it only supports
+Go's panic though is very similar to a termination, except it only supports
 a catch-all by calling \code{Go}{recover()}, simplifying the interface at
 the cost of flexibility.\cite{Go:2021}
 %\subsection
 While exception handling's most common use cases are in error handling,
+As exception handling's most common use cases are in error handling,
 here are some other ways to handle errors with comparisons with exceptions.
 \begin{itemize}
 …
 is discarded to avoid this problem.
 Checking error codes also bloats the main execution path,
 especially if the error is not handled immediately hand has to be passed
+especially if the error is not handled immediately and has to be passed
 through multiple functions before it is addressed.
+Here is an example of the pattern in Bash, where commands can only  ``return"
+numbers and most output is done through streams of text.
+\begin{lstlisting}[language=bash,escapechar={}]
+# Immediately after running a command:
+case $? in
+)
+        # Success
+        ;;
+)
+        # Error Code 1
+        ;;
+|3)
+        # Error Code 2 or Error Code 3
+        ;;
+# Add more cases as needed.
+asac
+\end{lstlisting}
 \item\emph{Special Return with Global Store}:
 Similar to the error codes pattern but the function itself only returns
 that there was an error
 and store the reason for the error in a fixed global location.
 For example many routines in the C standard library will only return some
+that there was an error,
+and stores the reason for the error in a fixed global location.
+For example, many routines in the C standard library will only return some
 error value (such as -1 or a null pointer) and the error code is written into
 the standard variable @errno@.
 This approach avoids the multiple results issue encountered with straight
+error codes but otherwise has the same disadvantages and more.
+error codes as only a single error value has to be returned,
+but otherwise has the same disadvantages and more.
 Every function that reads or writes to the global store must agree on all
 possible errors and managing it becomes more complex with concurrency.
+This example shows some of what has to be done to robustly handle a C
+standard library function that reports errors this way.
+\begin{lstlisting}[language=C]
+// Now a library function can set the error.
+int handle = open(path_name, flags);
+if (-1 == handle) {
+        switch (errno) {
+    case ENAMETOOLONG:
+                // path_name is a bad argument.
+                break;
+        case ENFILE:
+                // A system resource has been exausted.
+                break;
+        // And many more...
+    }
+}
+\end{lstlisting}
+% cite open man page?
 \item\emph{Return Union}:
 …
 Success is one tag and the errors are another.
 It is also possible to make each possible error its own tag and carry its own
 additional information, but the two branch format is easy to make generic
+additional information, but the two-branch format is easy to make generic
 so that one type can be used everywhere in error handling code.
 This pattern is very popular in any functional or semi-functional language
 with primitive support for tagged unions (or algebraic data types).
+Return unions can also be expressed as monads (evaluation in a context)
+and often are in languages with special syntax for monadic evaluation,
+such as Haskell's \code{haskell}{do} blocks.
+The main advantage is that an arbitrary object can be used to represent an
+error, so it can include a lot more information than a simple error code.
+The disadvantages include that the it does have to be checked along the main
+execution, and if there aren't primitive tagged unions proper, usage can be
+hard to enforce.
 % We need listing Rust/rust to format code snippets from it.
 % Rust's \code{rust}{Result<T, E>}
+The main advantage is that an arbitrary object can be used to represent an
+error so it can include a lot more information than a simple error code.
+The disadvantages include that the it does have to be checked along the main
+execution and if there aren't primitive tagged unions proper usage can be
+hard to enforce.
+This is a simple example of examining the result of a failing function in
+Haskell, using its \code{haskell}{Either} type.
+Examining \code{haskell}{error} further would likely involve more matching,
+but the type of \code{haskell}{error} is user defined so there are no
+general cases.
+\begin{lstlisting}[language=haskell]
+case failingFunction argA argB of
+    Right value -> -- Use the successful computed value.
+    Left error -> -- Handle the produced error.
+\end{lstlisting}
+Return unions as monads will result in the same code, but can hide most
+of the work to propagate errors in simple cases. The code to actually handle
+the errors, or to interact with other monads (a common case in these
+languages) still has to be written by hand.
+If \code{haskell}{failingFunction} is implemented with two helpers that
+use the same error type, then it can be implemented with a \code{haskell}{do}
+block.
+\begin{lstlisting}[language=haskell,literate={}]
+failingFunction x y = do
+        z <- helperOne x
+        helperTwo y z
+\end{lstlisting}
 \item\emph{Handler Functions}:
 …
 variable).
 C++ uses this approach as its fallback system if exception handling fails,
+such as \snake{std::terminate_handler} and, for a time,
+\snake{std::unexpected_handler}.
+such as \snake{std::terminate} and, for a time,
+\snake{std::unexpected}.\footnote{\snake{std::unexpected} was part of the
+Dynamic Exception Specification, which has been removed from the standard
+as of C++20.\cite{CppExceptSpec}}
 Handler functions work a lot like resumption exceptions,
 …
 function calls, but cheaper (constant time) to call,
 they are more suited to more frequent (less exceptional) situations.
+Although, in \Cpp and other languages that do not have checked exceptions,
+they can actually be enforced by the type system be more reliable.
+This is a more local example in \Cpp, using a function to provide
+a default value for a mapping.
+\begin{lstlisting}[language=C++]
+ValueT Map::key_or_default(KeyT key, ValueT(*make_default)(KeyT)) {
+        ValueT * value = find_value(key);
+        if (nullptr != value) {
+                return *value;
+        } else {
+                return make_default(key);
+        }
+}
+\end{lstlisting}
 \end{itemize}
 …
 Because of their cost, exceptions are rarely used for hot paths of execution.
 Hence, there is an element of self-fulfilling prophecy as implementation
 techniques have been focused on making them cheap to set-up,
+techniques have been focused on making them cheap to set up,
 happily making them expensive to use in exchange.
 This difference is less important in higher-level scripting languages,
 where using exception for other tasks is more common.
+where using exceptions for other tasks is more common.
 An iconic example is Python's
 \code{Python}{StopIteration}\cite{PythonExceptions} exception that
+\code{Python}{StopIteration}\cite{PythonExceptions} exception, that
 is thrown by an iterator to indicate that it is exhausted.
 When paired with Python's iterator-based for-loop this will be thrown every
+When paired with Python's iterator-based for-loop, this will be thrown every
 time the end of the loop is reached.\cite{PythonForLoop}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 949339b for doc/theses/andrew_beach_MMath/intro.tex

Legend:

doc/theses/andrew_beach_MMath/intro.tex

Download in other formats: