Proofread TIL on CLOS

1 files changed, 2 insertions, 2 deletions

diff --git a/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md b/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md
index 67a6799..eb19b38 100644
--- a/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md
+++ b/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md
@@ -98,7 +98,7 @@ Combining the order of inheritance with generic functions with multiple argument
 ```
 
 CLOS has to make a choice between the first and the second definition of `yet-another-fn`, but its choice is just a heuristic.
-What if we want to the choice to be based on the second argument first?
+What if we want the choice to be based on the second argument, instead of the first?
 
 For that, we use the `:argument-precedence-order` option when declaring a generic function:
 
@@ -126,7 +126,7 @@ Since the dispatch function is required, there is no need for a default behaviou
 Making the argument precedence order configurable for generic functions but not for class definitions makes a lot of sense.
 
 When declaring a class, we can choose the precedence order, and that is about it.
-But when defining a generic function, the order of argumentws is more important to the function semantics, and the argument precedence being left-to-right is just the default behaviour.
+But when defining a generic function, the order of arguments is more important to the function semantics, and the argument precedence being left-to-right is just the default behaviour.
 
 One shouldn't change the order of arguments of a generic function for the sake of tailoring it to the CLOS priority ranking algorithm, but doing it for a class definition is just fine.