diff options
Diffstat (limited to '_tils')
4 files changed, 334 insertions, 1 deletions
diff --git a/_tils/2020-08-14-browse-a-git-repository-at-a-specific-commit.md b/_tils/2020-08-14-browse-a-git-repository-at-a-specific-commit.md index 7965d29..d06f0c1 100644 --- a/_tils/2020-08-14-browse-a-git-repository-at-a-specific-commit.md +++ b/_tils/2020-08-14-browse-a-git-repository-at-a-specific-commit.md @@ -77,7 +77,7 @@ After any of those checkouts, you have to `git reset .` to reset your current staging area back to what it was before the checkout. -## References: +## References 1. [GIT: Checkout to a specific folder][0] (StackOverflow) diff --git a/_tils/2021-04-24-clojure-auto-curry.md b/_tils/2021-04-24-clojure-auto-curry.md new file mode 100644 index 0000000..c1e277f --- /dev/null +++ b/_tils/2021-04-24-clojure-auto-curry.md @@ -0,0 +1,135 @@ +--- + +title: Clojure auto curry + +date: 2021-04-24 1 + +updated_at: 2021-04-27 + +layout: post + +lang: en + +ref: clojure-auto-curry + +--- + +Here's a simple macro defined by [Loretta He][lorettahe] to create Clojure functions that are curried on all arguments, relying on Clojure's multi-arity support: + +```clojure +(defmacro defcurry + [name args & body] + (let [partials (map (fn [n] + `(~(subvec args 0 n) (partial ~name ~@(take n args)))) + (range 1 (count args)))] + `(defn ~name + (~args ~@body) + ~@partials))) +``` + +A naive `add` definition, alongside its usage and macroexpansion: + +```clojure +user=> (defcurry add + [a b c d e] + (+ 1 2 3 4 5)) +#'user/add + +user=> (add 1) +#object[clojure.core$partial$fn__5857 0x2c708440 "clojure.core$partial$fn__5857@2c708440"] + +user=> (add 1 2 3 4) +#object[clojure.core$partial$fn__5863 0xf4c0e4e "clojure.core$partial$fn__5863@f4c0e4e"] + +user=> ((add 1) 2 3 4 5) +15 + +user=> (((add 1) 2 3) 4 5) +15 + +user=> (use 'clojure.pprint) +nil + +user=> (pprint + (macroexpand + '(defcurry add + [a b c d e] + (+ 1 2 3 4 5)))) +(def + add + (clojure.core/fn + ([a b c d e] (+ 1 2 3 4 5)) + ([a] (clojure.core/partial add a)) + ([a b] (clojure.core/partial add a b)) + ([a b c] (clojure.core/partial add a b c)) + ([a b c d] (clojure.core/partial add a b c d)))) +nil +``` + +This simplistic `defcurry` definition doesn't support optional parameters, multi-arity, `&` rest arguments, docstrings, etc., but it could certainly evolve to do so. + +I like how `defcurry` is so short, and abdicates the responsability of doing the multi-arity logic to Clojure's built-in multi-arity support. +Simple and elegant. + +Same Clojure as before, now with auto-currying via macros. + +[lorettahe]: http://lorettahe.github.io/clojure/2016/09/22/clojure-auto-curry + +## Comparison with Common Lisp + +My attempt at writing an equivalent for Common Lisp gives me: + +```lisp +(defun partial (fn &rest args) + (lambda (&rest args2) + (apply fn (append args args2)))) + +(defun curry-n (n func) + (cond ((< n 0) (error "Too many arguments")) + ((zerop n) (funcall func)) + (t (lambda (&rest rest) + (curry-n (- n (length rest)) + (apply #'partial func rest)))))) + +(defmacro defcurry (name args &body body) + `(defun ,name (&rest rest) + (let ((func (lambda ,args ,@body))) + (curry-n (- ,(length args) (length rest)) + (apply #'partial func rest))))) +``` + +Without built-in multi-arity support, we have to do more work, like tracking the number of arguments consumed so far. +We also have to write `#'partial` ourselves. +That is, without dependending on any library, sticking to ANSI Common Lisp. + +The usage is pretty similar: + +```lisp +* (defcurry add (a b c d e) + (+ a b c d e)) +ADD + +* (add 1) +#<FUNCTION (LAMBDA (&REST REST) :IN CURRY-N) {100216419B}> + +* (funcall (add 1) 2 3 4) +#<FUNCTION (LAMBDA (&REST REST) :IN CURRY-N) {100216537B}> + +* (funcall (add 1) 2 3 4 5) +15 + +* (funcall (funcall (add 1) 2 3) 4 5) +15 + +* (macroexpand-1 + '(defcurry add (a b c d e) + (+ a b c d e))) +(DEFUN ADD (&REST REST) + (LET ((FUNC (LAMBDA (A B C D E) (+ A B C D E)))) + (CURRY-N (- 5 (LENGTH REST)) (APPLY #'PARTIAL FUNC REST)))) +T +``` + +This also require `funcall`s, since we return a `lambda` that doesn't live in the function namespace. + +Like the Clojure one, it doesn't support optional parameters, `&rest` rest arguments, docstrings, etc., but it also could evolve to do so. 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 new file mode 100644 index 0000000..8051232 --- /dev/null +++ b/_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md @@ -0,0 +1,137 @@ +--- + +title: Common Lisp argument precedence order parameterization of a generic function + +date: 2021-04-24 2 + +layout: post + +lang: en + +ref: common-lisp-argument-precedence-order-parameterization-of-a-generic-function + +--- + +When CLOS dispatches a method, it picks the most specific method definition to the argument list: + +```lisp + +* (defgeneric a-fn (x)) +#<STANDARD-GENERIC-FUNCTION A-FN (0) {5815ACB9}> + +* (defmethod a-fn (x) :default-method) +#<STANDARD-METHOD A-FN (T) {581DB535}> + +* (defmethod a-fn ((x number)) :a-number) +#<STANDARD-METHOD A-FN (NUMBER) {58241645}> + +* (defmethod a-fn ((x (eql 1))) :number-1) +#<STANDARD-METHOD A-FN ((EQL 1)) {582A7D75}> + +* (a-fn nil) +:DEFAULT-METHOD + +* (a-fn "1") +:DEFAULT-METHOD + +* (a-fn 0) +:A-NUMBER + +* (a-fn 1) +:NUMBER-1 +``` + +CLOS uses a similar logic when choosing the method from parent classes, when multiple ones are available: + +```lisp +* (defclass class-a () ()) + +#<STANDARD-CLASS CLASS-A {583E0B25}> +* (defclass class-b () ()) + +#<STANDARD-CLASS CLASS-B {583E7F6D}> +* (defgeneric another-fn (obj)) + +#<STANDARD-GENERIC-FUNCTION ANOTHER-FN (0) {583DA749}> +* (defmethod another-fn ((obj class-a)) :class-a) +; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ): +; Compiling Top-Level Form: + +#<STANDARD-METHOD ANOTHER-FN (CLASS-A) {584523C5}> +* (defmethod another-fn ((obj class-b)) :class-b) +; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ): +; Compiling Top-Level Form: + +#<STANDARD-METHOD ANOTHER-FN (CLASS-B) {584B8895}> +``` + +Given the above definitions, when inheriting from `class-a` and `class-b`, the order of inheritance matters: + +```lisp +* (defclass class-a-coming-first (class-a class-b) ()) +#<STANDARD-CLASS CLASS-A-COMING-FIRST {584BE6AD}> + +* (defclass class-b-coming-first (class-b class-a) ()) +#<STANDARD-CLASS CLASS-B-COMING-FIRST {584C744D}> + +* (another-fn (make-instance 'class-a-coming-first)) +:CLASS-A + +* (another-fn (make-instance 'class-b-coming-first)) +:CLASS-B +``` + +Combining the order of inheritance with generic functions with multiple arguments, CLOS has to make a choice of how to pick a method given two competing definitions, and its default strategy is prioritizing from left to right: + +```lisp +* (defgeneric yet-another-fn (obj1 obj2)) +#<STANDARD-GENERIC-FUNCTION YET-ANOTHER-FN (0) {584D9EC9}> + +* (defmethod yet-another-fn ((obj1 class-a) obj2) :first-arg-specialized) +#<STANDARD-METHOD YET-ANOTHER-FN (CLASS-A T) {5854269D}> + +* (defmethod yet-another-fn (obj1 (obj2 class-b)) :second-arg-specialized) +#<STANDARD-METHOD YET-ANOTHER-FN (T CLASS-B) {585AAAAD}> + +* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b)) +:FIRST-ARG-SPECIALIZED +``` + +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? + +For that, we use the `:argument-precedence-order` option when declaring a generic function: + +```lisp +* (defgeneric yet-another-fn (obj1 obj2) (:argument-precedence-order obj2 obj1)) +#<STANDARD-GENERIC-FUNCTION YET-ANOTHER-FN (2) {584D9EC9}> + +* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b)) +:SECOND-ARG-SPECIALIZED +``` + +I liked that the `:argument-precedence-order` option exists. +We shouldn't have to change the arguments from `(obj1 obj2)` to `(obj2 obj1)` just to make CLOS pick the method that we want. +We can configure its default behaviour if desired, and keep the order of arguments however it best fits the generic function. + +## Comparison with Clojure + +Clojure has an equivalent, when using `defmulti`. + +Since when declaring a multi-method with `defmulti` we must define the dispatch function, Clojure uses it to pick the method definition. +Since the dispatch function is required, there is no need for a default behaviour, such as left-to-right. + +## Conclusion + +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 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. + +TIL. + +## References + +1. [Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS](https://en.wikipedia.org/wiki/Object-Oriented_Programming_in_Common_Lisp), by Sonja E. Keene diff --git a/_tils/2021-04-24-three-way-conditional-for-number-signs.md b/_tils/2021-04-24-three-way-conditional-for-number-signs.md new file mode 100644 index 0000000..ec62378 --- /dev/null +++ b/_tils/2021-04-24-three-way-conditional-for-number-signs.md @@ -0,0 +1,61 @@ +--- + +title: Three-way conditional for number signs + +date: 2021-04-24 3 + +layout: post + +lang: en + +ref: three-way-conditional-for-number-signs + +--- + +A useful macro from Paul Graham's [On Lisp][on-lisp] book: + +```lisp +(defmacro nif (expr pos zero neg) + (let ((g (gensym))) + `(let ((,g ,expr)) + (cond ((plusp ,g) ,pos) + ((zerop ,g) ,zero) + (t ,neg))))) +``` + +After I looked at this macro, I started seeing opportunities to using it in many places, and yet I didn't see anyone else using it. + +The latest example I can think of is section 1.3.3 of [Structure and Interpretation of Computer Programs][sicp], which I was reading recently: + +```scheme +(define (search f neg-point pos-point) + (let ((midpoint (average neg-point pos-point))) + (if (close-enough? neg-point post-point) + midpoint + (let ((test-value (f midpoint))) + (cond ((positive? test-value) + (search f neg-point midpoint)) + ((negative? test-value) + (search f midpoint pos-point)) + (else midpoint)))))) +``` + +Not that the book should introduce such macro this early, but I couldn't avoid feeling bothered by not using the `nif` macro, which could even remove the need for the intermediate `test-value` variable: + +```scheme +(define (search f neg-point pos-point) + (let ((midpoint (average neg-point pos-point))) + (if (close-enough? neg-point post-point) + midpoint + (nif (f midpoint) + (search f neg-point midpoint) + (midpoint) + (search f midpoint pos-point))))) +``` + +It also avoids `cond`'s extra clunky parentheses for grouping, which is unnecessary but built-in. + +As a macro, I personally feel it tilts the balance towards expressivenes despite its extra cognitive load toll. + +[on-lisp]: http://www.paulgraham.com/onlisptext.html +[sicp]: https://mitpress.mit.edu/sites/default/files/sicp/index.html |