transfer commit

notes/papers/project_synopsis/main.tex

@@ -57,16 +57,16 @@ provisional feature set.
 A working type system should have the following parts, which I will implement in roughly this order
 
 \begin{itemize}
-    \item \textbf{Type inference engine and type checker} This will be an extension of
-        the Hindley-Milner algorithm, which simultaneously unifies and completes partial type
-        annotations, and recognizes conflicts.
-    \item \textbf{Typeclass solver} At the moment this appears to be a relatively simple piece of
-        code but I'm not entirely confident that complications won't arise as its responsibilities
-        become clearer, so I consider it a separate component
-    \item \textbf{Executor} Orchid is a statically typed language so it should eventually be compiled
-        with LLVM, but in order to demonstrate the usability of my type system I will have to write
-        an experimental interpreter. Since types are already basically expressions of type type,
-        parts of the executor will coincide with parts of the type inference engine.
+  \item \textbf{Type inference engine and type checker} This will be an extension of
+    the Hindley-Milner algorithm, which simultaneously unifies and completes partial type
+    annotations, and recognizes conflicts.
+  \item \textbf{Typeclass solver} At the moment this appears to be a relatively simple piece of
+    code but I'm not entirely confident that complications won't arise as its responsibilities
+    become clearer, so I consider it a separate component
+  \item \textbf{Executor} Orchid is a statically typed language so it should eventually be compiled
+    with LLVM, but in order to demonstrate the usability of my type system I will have to write
+    an experimental interpreter. Since types are already basically expressions of type type,
+    parts of the executor will coincide with parts of the type inference engine.
 \end{itemize}
 
 \section{Literature Review}
@@ -99,12 +99,12 @@ in the same group.
 At a minimum, the following must be valid reduction steps:
 
 \begin{itemize}
-    \item $\beta$-reduction
-    \item fixed point normalization, which simply means identifying that a subexpression has
-        reduced to an expression that contains the original. When a fixed point is detected, the
-        recursive expression is converted to a form that uses the Y-combinator. This operation
-        is ordered before $\beta$-reductions of the expression in the BFS tree but otherwise has
-        the same precedence.
+  \item $\beta$-reduction
+  \item fixed point normalization, which simply means identifying that a subexpression has
+    reduced to an expression that contains the original. When a fixed point is detected, the
+    recursive expression is converted to a form that uses the Y-combinator. This operation
+    is ordered before $\beta$-reductions of the expression in the BFS tree but otherwise has
+    the same precedence.
 \end{itemize}
 
 \subsection{Typeclass solver}

notes/papers/project_synopsis/references.bib

@@ -1,20 +1,20 @@
 @online{suckerpinch,
-    title = {Generalized kerning is undecidable! But anagraphing is possible.},
-    author = {suckerpinch},
-    date = {dec, 2017},
-    organization = {YouTube},
-    url = {https://www.youtube.com/watch?v=8\_npHZbe3qM}
+  title = {Generalized kerning is undecidable! But anagraphing is possible.},
+  author = {suckerpinch},
+  date = {dec, 2017},
+  organization = {YouTube},
+  url = {https://www.youtube.com/watch?v=8\_npHZbe3qM}
 }
 
 @phdthesis{tubella,
-    author = {Jordi Tubella and Antonio González},
-    school = {Universitat Politechnica de Catalunya},
-    title = {A Partial Breadth-First Execution Model for Prolog},
-    year = {1994}
+  author = {Jordi Tubella and Antonio González},
+  school = {Universitat Politechnica de Catalunya},
+  title = {A Partial Breadth-First Execution Model for Prolog},
+  year = {1994}
 }
 
 @misc{yallop,
-    author = {Jeremy Yallop and Leo White},
-    howpublished = {University of Cambridge},
-    title = {Lightweight higher-kinded polymorphism}
+  author = {Jeremy Yallop and Leo White},
+  howpublished = {University of Cambridge},
+  title = {Lightweight higher-kinded polymorphism}
 }

notes/type_system/unification.md

@@ -4,13 +4,13 @@
 - enqueue evaluation steps for each of them and put them in a unification group
 - evaluation step refers to previous step, complete expression tree
   - unification **succeeds** if either
-    - the trees are syntactically identical in any two steps between the targets
-    - unification succeeds for all substeps:
-      - try to find an ancestor step that provably produces the same value as any lambda in this
-        step (for example, by syntactic equality)
-        - if found, substitute it with the recursive normal form of the lambda
-          - recursive normal form is `Apply(Y, \r.[body referencing r on point of recursion])`
-      - find all `Apply(\x.##, ##)` nodes in the tree and execute them
+  - the trees are syntactically identical in any two steps between the targets
+  - unification succeeds for all substeps:
+    - try to find an ancestor step that provably produces the same value as any lambda in this
+      step (for example, by syntactic equality)
+    - if found, substitute it with the recursive normal form of the lambda
+      - recursive normal form is `Apply(Y, \r.[body referencing r on point of recursion])`
+    - find all `Apply(\x.##, ##)` nodes in the tree and execute them
   - unification **fails** if a member of the concrete tree differs (only outermost steps add to
     the concrete tree so it belongs to the group and not the resolution) or no substeps are found
     for a resolution step _(failure: unresolved higher kinded type)_