aboutsummaryrefslogtreecommitdiff
path: root/_tils
diff options
context:
space:
mode:
Diffstat (limited to '_tils')
-rw-r--r--_tils/2020-08-14-browse-a-git-repository-at-a-specific-commit.md2
-rw-r--r--_tils/2021-04-24-clojure-auto-curry.md135
-rw-r--r--_tils/2021-04-24-common-lisp-argument-precedence-order-parameterization-of-a-generic-function.md137
-rw-r--r--_tils/2021-04-24-three-way-conditional-for-number-signs.md61
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