From b7bc24827c15e802c867eefdc562fab0db1b49af Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Sat, 24 Apr 2021 17:50:22 -0300 Subject: Proofread TIL on CLOS --- .../_tils/2021-04-24-clojure-auto-curry.po | 42 ++++++++++++++-------- ...order-parameterization-of-a-generic-function.po | 39 +++++++++++++------- 2 files changed, 54 insertions(+), 27 deletions(-) (limited to 'locale/pt') diff --git a/locale/pt/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po b/locale/pt/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po index 67ff1b4..67c4f2e 100644 --- a/locale/pt/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po +++ b/locale/pt/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po @@ -96,20 +96,6 @@ msgstr "" 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 " @@ -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/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po b/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po index b773879..4ca9625 100644 --- a/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po +++ b/locale/pt/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po @@ -120,12 +120,6 @@ msgid "" ":FIRST-ARG-SPECIALIZED\n" 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:" @@ -168,13 +162,6 @@ msgid "" "not for class definitions makes a lot of sense." 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 " @@ -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 "" -- cgit v1.2.3