[throwawaymaths]

Honestly a pragmatic solution would be to have printing to stderr (debug print, logs, whatever) not be an "effect". then as an added benefit if its context is elided out in an optimization you know.

[maleldil]

This is similar to what Haskell has with trace[1]. It pretends to be a pure function (so it doesn't need the IO monad), but prints to stderr.

[1] https://hackage.haskell.org/package/base-4.21.0.0/docs/Debug...

[JoelMcCracken]

And, just like tfa alludes, it is awkward because of laziness; in non trivial scenarios it can be quite surprising how your trace isn’t tracing.

This is bc of non strict eval in Haskell, but still the core is that the lang is designed to not eval stuff when it’s not necessary.

[jorkadeen]

The challenge is that the compiler uses the type-and-effect system for many of its tasks, including whole-program optimization and code generation.

If printing- or logging statements have no effect, the compiler might reorder them or even remove them.

[naasking]

It needs to be an effect so the compiler knows how optimizations are permitted to handle it. Otherwise your print statements might appear in totally the wrong order or even not at all.

Imagine saying that certain memory stores are allowed to cross a memory barrier operation, you'd completely lose the ability to reason about concurrency around those stores.

[throwawaymaths]

debugging must be a nightmare if you can't get a good mental model of how the compiler is transforming your code