Why are exceptions not described as 'purely functional'?
Say we have the expression -(/ 1 0)
In my purely functional programming language (with strict evaluation), I currently handle the evaluation by returning a 'violation' value that describes the problem like so -(violation :v/contract/divByZero "Division by zero." ())
This â€˜preservesâ€™ referential transparency for all expressions by making all them replaceable by their value, if only by a violation. But this different than other purely functional languages I've seen.
Whenever I read a description of the properties of impure functional languages (such as ML), exceptions are described under the imperative section as an imperative feature. I find this a little odd as I'm not sure how a purely functional language would handle a division by zero error without exceptions (or without violations like I use).
Haskell has exceptions, but they can only be handled in the IO context. This makes sense to me because Haskell is lazy. My language is strict, so I don't see why I would be violating purity by having exceptions. After all, what makes a language purely functional is the pervasiveness of referential transparency (replacement of any expression with its resulting value). But why would we care about preserving referential transparency for the set of expressions that have no possible value in the first place? Would the replacement of violations in my language with exceptions technically render it 'impure'?
Active forum topics
New forum topics