Ah, yeah, wasn't as aware of those as I should have been. Still suffers from the "where did that NaN come from?" issue, but looks like good stuff. Any idea why it's not used more?
Haskell actually has three (or four) competing exception handling mechanisms nowadays.
If you use the Either error result approach, you can conceivable put a stack trace (or something similarly identifying) in the Error data-type, so you can avoid the "Where did that NaN come from?" issue.
I think we need to see Algebraic data types in more languages, before we will see this approach used more often. (In my opinion algebraic datatypes and the pattern matching they enable rank in the same league as garbage collection in that they are a feature originally invented in and for functional languages, but useful outside as well.)
> Haskell actually has three (or four) competing exception handling mechanisms nowadays.
Yeah, knew about Either in general (see my top-level comment about sums vs. products), just not the monadic bits around it (MonadError and ErrorT, in particular).
> If you use the Either error result approach, you can conceivable put a stack trace (or something similarly identifying) in the Error data-type, so you can avoid the "Where did that NaN come from?" issue.
True - even just making exceptions take a Loc parameter seems like it could be a good step, but that would be basically requiring TemplateHaskell, which would ruffle feathers for sure...
> I think we need to see Algebraic data types in more languages, before we will see this approach used more often. (In my opinion algebraic datatypes and the pattern matching they enable rank in the same league as garbage collection in that they are a feature originally invented in and for functional languages, but useful outside as well.)
I agree wholeheartedly. Lack of easy-to-use algebraic datatypes is my biggest pain-point in languages that lack 'em.
I was talking more about the (Either Error) monad, which has not much to do with "fail".
(Edited first sentence.)