docs: Fix a few typos

src/py/atom.py

@@ -57,7 +57,7 @@ def eval(self, env, args=None):
 #### Strings
 
 # In McCarthy's original paper (McCarthy 1960) he uses the term *string* to mean symbols, but later on
-# he mentions them in a different context reagrding their role in something called *linear Lisp*.  I started
+# he mentions them in a different context regarding their role in something called *linear Lisp*.  I started
 # down the path of implementing linear Lisp also, but got sidetracked.  Perhaps I will find time to complete it
 # sometime in the future.  In the meantime strings are provided, but are not compliant with the Lisp 1
 # formalization.

src/py/fun.py

@@ -20,7 +20,7 @@ def eval(self, env, args):
 
 # λ λ λ
 
-# The real power of McCarthy's Lisp srpings from Alonzo Chruch's λ-calculus.
+# The real power of McCarthy's Lisp springs from Alonzo Chruch's λ-calculus.
 class Lambda(Eval):
     def __init__(self, n, b):
         # The names that occur in the arg list of the lambda are bound (or dummy) variables
@@ -33,7 +33,7 @@ def __repr__(self):
 
     # Every invocation of a lambda causes its bound variables to be pushed onto the
     # dynamic bindings stack.  McCarthy only touches briefly on the idea that combining functions
-    # built from lambda is problemmatic.  In almost a throw-away sentence he states, "different bound
+    # built from lambda is problematic.  In almost a throw-away sentence he states, "different bound
     # variables may be represented by the same symbol. This is called collision of bound variables."  If you
     # take the time to explore [core.lisp](core.html) then you will see what this means in practice.
     # The reason for these difficulties is a direct result of dynamic scoping.  McCarthy suggests that
@@ -75,8 +75,8 @@ def eval(self, env, args):
 
 # Closures
 
-# McCarthy's Lisp does not define closures and in fact the precense of closures in the context of a pervasive dynamic
-# scope is problemmatic.  However, this fact was academic to me and didn't really map conceptually to anything that I
+# McCarthy's Lisp does not define closures and in fact the presence of closures in the context of a pervasive dynamic
+# scope is problematic.  However, this fact was academic to me and didn't really map conceptually to anything that I
 # had experienced in the normal course of my programming life.  Therefore, I added closures to see what would happen.
 # It turns out that if you thought that bound variables caused issues then your head will explode to find out what
 # closures do.  Buyer beware.  However, closures are disabled by default.

src/py/lisp.py

@@ -122,7 +122,7 @@ def quote(self, env, args):
     # The original Lisp implementation was written for the IBM 704 by Steve Russell (a genius of the highest
     # order -- also the creator/discoverer of [Spacewar!](http://pdp-1.computerhistory.org/pdp-1/?f=theme&s=4&ss=3) 
     # and continuations).  The somewhat obtuse name for a function that returns the first element of an s-expression
-    # derives from the idiosyncracies of the IBM 704 on which Lisp was first implemented.  The `car` function was
+    # derives from the idiosyncrasies of the IBM 704 on which Lisp was first implemented.  The `car` function was
     # thus a shortening of the term "Contents of the Address part of Register number" that in itself has a very interesting
     # explanation.  That is, `car` was used to refer to the first half of the wordsize addressed by the IBM 704.  In this
     # particular machine (and many others at that time and since) the wordsize could address more than twice of the
@@ -210,7 +210,7 @@ def car(self, env, args):
     # It would be interesting to learn the precise genesis of the idea behind the cons cell, but I imagine that it must have provoked
     # a eureka moment.  
     #
-    # I've already discussed how the IBM 704 hardware was especially ammenable to solving this problem efficiently, but the other points
+    # I've already discussed how the IBM 704 hardware was especially amenable to solving this problem efficiently, but the other points
     # bear further consideration.  Lisp popularly stands for "LISt Processing language" but as I explained, the basic unit of data was
     # instead the cons cell structure.  The fact of the matter is that the cons cell serves as both the implementation detail for lists
     # **and** the abstraction of a pair, all named oddly as if the implementation mattered.  If Lisp had originally gone whole hog into the
@@ -260,7 +260,7 @@ def cdr(self, env, args):
     #     (cons (quote a) (quote b))
     #     ;=> Error
     # 
-    # I've agonized long and hard over wheter or not to implement McCarthy Lisp as the language described in *Recursive functions...*
+    # I've agonized long and hard over whether or not to implement McCarthy Lisp as the language described in *Recursive functions...*
     # as the anecdotal version only partially described in the *LISP 1.5 Programmer's Manual* and in most cases the former was my
     # choice.  The creation of "dotted pairs" (I believe) was not an aspect of the original description and therefore is not represented
     # in Lithp.  Sadly, I think that in some cases these version are mixed because I originally went down the path of creating a version of 

src/py/lithp.py

@@ -19,7 +19,7 @@
 # - [core.lisp](core.html)
 # 
 # The Lithp interpreter requires Python 2.6.1+ to function.
-#   please add comments, report errors, annecdotes, etc. to the [Lithp Github project page](http://github.com/fogus/lithp)
+#   please add comments, report errors, anecdotes, etc. to the [Lithp Github project page](http://github.com/fogus/lithp)
 # 
 import pdb
 import getopt, sys, io