Proofread TIL on CLOS

2 files changed, 54 insertions, 27 deletions

diff --git a/locale/eo/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po b/locale/eo/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po
index 67ff1b4..67c4f2e 100644
--- a/locale/eo/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po
+++ b/locale/eo/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po
@@ -97,20 +97,6 @@ msgid "My attempt at writing an equivalent for Common Lisp gives me:"
 msgstr ""
 
 msgid ""
-"(defun curry-n (n fn)\n"
-"  (if (= 0 n)\n"
-"            (funcall fn)\n"
-"            (lambda (&rest rest)\n"
-"                (curry-n (something n) fn))))\n"
-"\n"
-"(defun add (a b c d e)\n"
-"  (curry-n\n"
-"     (length '(a b c d e))\n"
-"     (lambda (&rest rest)\n"
-"         (apply #'+ rest))))\n"
-msgstr ""
-
-msgid ""
 "Without built-in multi-arity support, we have to do more work, like tracking"
 " the number of arguments consumed so far. That is, without dependending on "
 "any library, sticking to ANSI Common Lisp."
@@ -125,3 +111,31 @@ msgid ""
 "Like the Clojure one, it doesn't support optional parameters, `&rest` rest "
 "arguments, docstrings, etc., but it also could evolve to do so."
 msgstr ""
+
+msgid ""
+"(defun curry-n (n fn)\n"
+"  (if (= 0 n)\n"
+"      (funcall fn)\n"
+"      (lambda (&rest rest)\n"
+"        (curry-n (something n) fn))))\n"
+"\n"
+"(defun add (a b c d e)\n"
+"  (curry-n\n"
+"   (length '(a b c d e))\n"
+"   (lambda (&rest rest)\n"
+"     (apply #'+ rest))))\n"
+msgstr ""
+
+#~ msgid ""
+#~ "(defun curry-n (n fn)\n"
+#~ "  (if (= 0 n)\n"
+#~ "            (funcall fn)\n"
+#~ "            (lambda (&rest rest)\n"
+#~ "                (curry-n (something n) fn))))\n"
+#~ "\n"
+#~ "(defun add (a b c d e)\n"
+#~ "  (curry-n\n"
+#~ "     (length '(a b c d e))\n"
+#~ "     (lambda (&rest rest)\n"
+#~ "         (apply #'+ rest))))\n"
+#~ msgstr ""
diff --git a/locale/eo/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po b/locale/eo/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
index b773879..4ca9625 100644
--- a/locale/eo/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
+++ b/locale/eo/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po
@@ -121,12 +121,6 @@ msgid ""
 msgstr ""
 
 msgid ""
-"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?"
-msgstr ""
-
-msgid ""
 "For that, we use the `:argument-precedence-order` option when declaring a "
 "generic function:"
 msgstr ""
@@ -169,13 +163,6 @@ msgid ""
 msgstr ""
 
 msgid ""
-"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."
-msgstr ""
-
-msgid ""
 "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."
@@ -183,3 +170,29 @@ msgstr ""
 
 msgid "TIL."
 msgstr ""
+
+msgid ""
+"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 the "
+"choice to be based on the second argument, instead of the first?"
+msgstr ""
+
+msgid ""
+"When declaring a class, we can choose the precedence order, and that is "
+"about it. 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."
+msgstr ""
+
+#~ msgid ""
+#~ "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?"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "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."
+#~ msgstr ""