Typos

1 files changed, 2 insertions, 2 deletions

diff --git a/implementation/codfns.md b/implementation/codfns.md
index 659f655c..45cede0e 100644
--- a/implementation/codfns.md
+++ b/implementation/codfns.md
@@ -23,6 +23,6 @@ Initially, the BQN compiler was written with a similar style to Co-dfns, primari
 - Optimization
 - Testing and debugging the compiler
 
-So far the most notable difference is the addition of per-line comments. Aaron advocates the almost complete separation of code from comments (thesis) in addition to his very terse style as a general programming methodology. I find that this practice makes it hard to connect the documentation to the code and is very slow in providing a summary or reminder of functionality that a comment might. However, I do plan to write long-form material providing the necessary context and explainations required to understand the compiler.
+So far the most notable difference is the addition of per-line comments. Aaron advocates the almost complete separation of code from comments (thesis) in addition to his very terse style as a general programming methodology. I find that this practice makes it hard to connect the documentation to the code and is very slow in providing a summary or reminder of functionality that a comment might. However, I do plan to write long-form material providing the necessary context and explanations required to understand the compiler.
 
-Co-dfns doesn't check for compilation errors, while BQN has complete error checking and good error messages, and includes source positions in compiler errors as well as in the compiled code for use in runtime errors. I have found that such checking imposes a low cost on compilation speed (perhaps 25%), but a greater cost on the compiler codebase size and legibility. Maintaining source locations is also a small expense relative to other compilation. Aside from that maintainance, more user-friendly error reporting has almost no performance cost for working programs, because error reporting code only needs to be run when compilation fails. This leaves room for potentially very sophisticated error analysis to attempt to track down the root cause of a compilation error, but I haven't yet done any work along these lines.
+Co-dfns doesn't check for compilation errors, while BQN has complete error checking and good error messages, and includes source positions in compiler errors as well as in the compiled code for use in runtime errors. I have found that such checking imposes a low cost on compilation speed (perhaps 25%), but a greater cost on the compiler codebase size and legibility. Maintaining source locations is also a small expense relative to other compilation. Aside from that maintenance, more user-friendly error reporting has almost no performance cost for working programs, because error reporting code only needs to be run when compilation fails. This leaves room for potentially very sophisticated error analysis to attempt to track down the root cause of a compilation error, but I haven't yet done any work along these lines.