Another thing to think about is that exceptions make our code impure. [...] A referentially-transparent function will always give the same result for a given input. But we can’t say this about functions that throw exceptions. At any moment, they might throw an exception instead of returning a value.
That’s just incorrect. If it’s a pure function, it would always throw exactly the same exception given the same input. It would still be referentially transparent.
Sure, it’s a pure function with two exit paths, which is more of a hassle and possibly more error-prone to deal with. But it can still be pure, so you can still get the benefits of pure (dynamically-typed) functional programming.
Edit: to make sure we’re on the same page, I interpret “pure” as no side-effects and no non-determinism, so a call with the same arguments always has exactly the same result.
What side-effect does “catch” have? Something that’s visible externally, visible to the caller of the function doing the catch.
I suppose if you catch an exception and pull out the stack trace, that gives you some extra information about the caller. Even that doesn’t make you impure, though, if you treat the call stack as additional input.
That’s just incorrect. If it’s a pure function, it would always throw exactly the same exception given the same input. It would still be referentially transparent.
Sure, it’s a pure function with two exit paths, which is more of a hassle and possibly more error-prone to deal with. But it can still be pure, so you can still get the benefits of pure (dynamically-typed) functional programming.