Henning Thielemann wrote:
We should clearly decide what "fail" is intended for - for programming errors or for exceptions. I guess that people want to use it in the second sense, e.g. something like "guard" driven by a pattern match in the Maybe or list monad. But then "fail" must not have an argument because what user related information can the compiler add automatically? Instead of removing the String argument from "fail", the compiler could simply call "mzero" instead.
And then there's ErrorT, which does actually make the information available to the user. I agree that the current situation is a bit messy, but at the same time I believe the choices made for fail make sense and are very convenient. Perhaps more importantly, I see no sane way to "clean up the mess" even if that's desired. We've already had that experience on a small scale, when the Error class constraint was removed from the Monad instance for Either e. The problem with this change was that code kept compiling, but started to raise runtime errors where previously there hadn't been any. Tracking down these uses of Either and replacing them by ErrorT was quite tedious. To summarize, I believe we should keep the current semantics of fail, even if it's moved to a new class. Cheers, Bertram