Wednesday, February 12, 2020

Anaphoric if

An anaphoric if expression binds the identifier “it” to the value of the conditional in the scope of the consequent
(aif (find-broken-computer)
     (fix it))
I have two objections to anaphoric macros. The first is that the binding of “it” isn't obvious, the second is the inflexibility of the variable name. You are kind of stuck with “it”. What if you wanted to use “it” to mean something else? Maybe you have an IT department to fix your computers
(let ((it (find-department "IT")))
  (aif (find-broken-computer)
       (tell it (fix it))))   ; name conflict
or maybe you want to nest two anaphoric conditionals
(aif (find-broken-computer)
     (aif (find-broken-component it)
          (repair it)
          (replace it)))
In this case, I want to replace the computer if I cannot repair the broken component, but the inner binding of “it” shadows the outer binding and makes it inaccessible.

The solution is pretty obvious if you think about it (though sometimes it takes me a while to see the obvious). Just replace the conditional test form with a binding form
(aif (it (find-broken-computer))
     (fix it))
This makes it obvious we are binding the variable “it” to the value returned by (find-broken-computer), and it lets us choose the name we bind. If we want to nest these, it would look like this
(aif (computer (find-broken-computer))
     (aif (component (find-broken-component computer))
          (repair component)
          (replace computer)))
But I'm not sure if this is so much more concise and clear than simply using a let expression that it is worth adding this syntax to the language. It's one more thing the reader of the code has to be prepared to encounter.

A slightly different approach would move the binding form closer to where it is used. Note that there is no point in binding a name in the alternative clause to the conditional because it will always have the value nil.
(aif (find-broken-computer)
     (it (fix it)))
and instead of using a let binding, I could use a lambda binding
(aif (find-broken-computer)
     (λ (it) (fix it)))
aif no longer needs to be a macro but can be an ordinary function, which might be handy if your language doesn't have macros
(defun aif (it consequent &optional alternative)
  (if it
      (funcall consequent it)
      (if alternative
          (funcall alternative)

(aif (find-broken-computer)
     (λ (computer)
        (aif (find-broken-component computer)
             (λ (component) (fix component))
             (λ () (replace computer)))))
The explicit lambdas make it obvious what is being bound and what the scope of the binding is, but they do add a bit of visual noise.

Instead of using anaphoric if, I just write the slightly more verbose
(let ((computer (find-broken-computer)))
  (if computer
      (let ((component (find-broken-component)))
        (if component
            (repair component)
            (replace computer)))))
The binding is obvious, and I get to choose the variable being bound; both problems solved. I don't see a compelling reason to use the anaphoric version.


Hexstream suggests that “No discussion of anaphoric macros can be complete without at least mentioning anaphoric-variants:” I wouldn't want to be incomplete, so consider it mentioned.


Hans said...

Joe, is there a particular reason why you use "anamorphic" instead of the more common "anaphoric" to describe macros that implicitly bind?

Clément said...

The binding version of aif is called "if-let" (or "when-let") in Emacs Lisp and Clojure.

Joe Marshall said...

I accidentally called them “anamorphic” I read the name incorrectly and it got stuck in my head that way. The correct word is anaphoric. Thanks, Hans!

Hexstream said...

I believe no discussion of anaphoric macros is complete without at least mentioning anaphoric-variants:

John Cowan said...

IMAO, the best way to do anaphoric macros is to avoid them. They are obscure and they don't nest. It's just not that big a deal to have to declare names before using them, a principle accepted in other contexts since about 1960.

John Cowan said...

There's a trick using syntax-case macros that allows for inlining procedures without compiler support. The trick is that syntax-case allows an identifier as a top-level pattern, not just a list or vector. In that case it will be expanded even in operand position.

So you can write a syntax-case macro with two clauses: one that matches the arguments (which must wind up being evaluated) and one that is just underscore, which invokes an equivalent procedure. When you use the keyword in operator position, the macro is expanded; when you use it in operand position you get the procedure, which can then be applied.