User loginNavigation |
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'? By bryanedds at 2012-06-14 14:30 | LtU Forum | previous forum topic | next forum topic | other blogs | 14201 reads
|
Browse archives
Active forum topics |
Recent comments
3 weeks 5 days ago
44 weeks 11 hours ago
44 weeks 15 hours ago
44 weeks 15 hours ago
1 year 14 weeks ago
1 year 18 weeks ago
1 year 19 weeks ago
1 year 19 weeks ago
1 year 22 weeks ago
1 year 27 weeks ago