Re: Factor

Asserting Implications is a short, but thought-provoking, blog post by the Tigerbeetle team about writing some asserts differently – along with some interesting lobste.rs discussions. Their main conclusion was made using an example code change in Zig:

// Before:
assert(header_b != null or replica.commit_min == replica.op_checkpoint);

// After:
if (header_b == null) assert(replica.commit_min == replica.op_checkpoint);

Directly translation into Factor using local variables might look like this:

! Before
header_b not replica commit-min>> replica checkpoint>> = or t assert=

While using short-circuit combinators looks both less and more readable:

{
    [ header_b not ]
    [ replica commit-min>> replica checkpoint>> = ]
} 0|| t assert=

And writing it awkwardly with dataflow combinators looks inscrutable:

2dup [ not ] [ [ commit-min>> ] [ checkpoint>> ] bi = ] bi* or t assert=

Nesting the assertion does indeed look much better:

! After
header_b [ replica commit-min>> replica checkpoint>> assert= ] when

Alternatively, using implicit arguments on the stack that are preserved:

2dup '[ _ [ commit-min>> ] [ checkpoint>> ] bi assert= ] when

Neat idea!