diff options
Diffstat (limited to '')
7 files changed, 164 insertions, 83 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. 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 "" diff --git a/locale/fr/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po b/locale/fr/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po index 67ff1b4..67c4f2e 100644 --- a/locale/fr/LC_MESSAGES/_tils/2021-04-24-clojure-auto-curry.po +++ b/locale/fr/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/fr/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po b/locale/fr/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po index b773879..4ca9625 100644 --- a/locale/fr/LC_MESSAGES/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.po +++ b/locale/fr/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 "" 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 @@ -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/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 @@ -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 "" |