Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Nil-Safe Threading: some-> and some->>

Threading with nil short-circuiting. If any step produces null or undefined, the chain stops and returns the nil value.

(some-> config
  (get :database)
  (get :host))
(() => {
  const t__gensym0 = config;
  if (t__gensym0 == null) return t__gensym0;

  const t__gensym1 = t__gensym0["database"];
  if (t__gensym1 == null) return t__gensym1;

  return t__gensym1["host"];
})()

How It Works

The compiler wraps some-> in an IIFE with sequential bindings. After each step, a == null check short-circuits the chain if the value is null or undefined.

The == null Exception

some-> is one of the places where Lykn’s compiled output contains == instead of ===. The == null check catches both null and undefined in a single comparison — the only loose equality that ESLint’s eqeqeq rule explicitly exempts. The developer never writes ==; the compiler generates it.

Not Option-Aware

some-> checks for JavaScript null/undefined, not for None. For Option threading, use match or if-let with ADT patterns:

;; JS interop: nullable values
(some-> user (get :address) (get :street))

;; Lykn-native: Option values
(if-let ((Some addr) (get-address user))
  addr:street
  "no address")

The two mechanisms serve different data: some-> for JS interop (nullable APIs), match/if-let for surface-native data (Option/Result).