How do you correctly compile the chained comparison operators like ones that exist in Python (`a < b < c`), if `b` might have side-effects?

So this one depends on your operational semantics, in particular on whether your language exhibits Lazy or Eager Evaluation.
That said, please bear in mind that even in most eagerly-evaluated languages, the Boolean conjunction and disjunction operators (and and or) are exhibiting lazy evaluation.

x ∧ y sometimes mean that false ∧ (x/0) is legal and equal to false, while sometimes it is illegal.
This will become important in what follows.

Memoising And Rewriting

That one is simple enough: you just rewrite comparison chains to conjunctions or disjunctions.

x < y < z becomes x < y ∧ y < z.
Then, assuming Lazy Evaluation, this further gets lowered to force x < force y ∧ force y < force z where each term is memoised.
Assuming Eager Evaluation, the uses of force are explicitated using temporaries as so:
let x' = /*force*/ x;; y' = /*force*/ y in x' < y' ∧ y' < z.

Now, what 3 < 0 < explode() is supposed to do is up to whether Boolean conjunction is lazy or not.

Binary Comparisons Do Not Result In Booleans

That one is a bit more funky but works in existing languages and relies on the binary comparison operators returning a type that can both be turned into Booleans and be used in comparison chains.
It's simple: it holds a reference to its RHS and has the operators compare against the RHS.

Here is the approach illustrated in C++:

template<typename T> struct ComparisonVariable { const bool r; const T &rhs; operator bool() const { return r; } ComparisonVariable<T> operator <(const T &arg) const { return ComparisonVariable<T> { r && (bool) (rhs < arg), arg }; } }; struct Int { int val; ComparisonVariable<Int> operator <(const Int &arg) const { return ComparisonVariable<Int> { val < arg.val, arg }; } }; /* ... */ extern "C" int printf(const char*, ...); int main(int argc, char *argv[]) { Int x = { 1 }, y = { 2 }, z = { 3 }; bool fst = x < y < z; bool snd = z < y < x; printf("%d %d", fst, snd); } 

x < y < z is (x.Int::operator <(y)).ComparisonVariable<Int>::operator <(z), where, as you can see, each operand only appears once.

You've got some good answers already but I'll just point out that I've had to do this twice, and done it in two different ways; both work.

Method one:

When I was writing a Python-to-Python compiler at Facebook we rewrote r = a() < b() < c() via the following steps:

• Does the first operand possibly have a side effect? If no, we're done. If yes, rewrite to _a = a() ; r = _a < b() < c().

• Does the second operand possibly have a side effect? Rewrite similarly, so now we have _a = a() ; _b = b(); r = _a < _b < c()

• Is there more than one operator? If yes, it is now safe to rewrite the assignment as r = _a < _b and _b < c().

Method two:

C# does not have this kind of chained comparison but it has many other expressions where the specification says "... but the expression is only evaluated once". Our intermediate form after parsing but before IL generation has a pair of special nodes: one means "evaluate the referred-to expression and store it to a temp", the other means "fetch the value of the temp in the referred-to store expression". That makes the lowered form a DAG rather than a tree but that's not a big deal. The IL generator then decides whether to turn the temp into an unnamed local or a dup instruction or whatever.

Both work. In the first case I was already writing a Python-to-Python compiler so it made sense to do the lowering entirely in Python, in the second case it was just easier to have a custom intermediate format that we could special-case later; do whatever works best for your application.

You can translate it to

(a < (temp_b := b)) and (temp_b < c) 

before code generation. temp_b should be a unique identifier generated by the compiler. Repeat this replacement for each step in the chained comparisons.