[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

[Jose Iborra]

>
>
>> When using happstack, I find it really annoying to get a  
>> Prelude.head: null list error (or similar) in my web browser window  
>> because somewhere, some library used something unsafe -- and of  
>> course, since this is haskell, no stack trace.
>
>> if c-m-e can offer benefits around this, I would be very interested  
>> in adopting it.
>
>
> That's what I meant with my post: Programming errors (like "head  
> []") are not handled by control-monad-exception. As far as I  
> understand, control-monad-exception makes _exceptions_ explicit in  
> the type signatures, not programming errors. Why and how would you  
> make possible programming errors explicit in the type? But for  
> exceptions (e.g. "file could not be found") a detailed stack trace  
> is not of much use. It seems again to me, that mixing of  
> (programming) errors and exceptions is going on, and I assumed that  
> the purpose of control-monad-exception is to separate them in a  
> better way.
>

Sorry for the confusion, I never meant that c-m-e can show stack  
traces for asynchronous exceptions. It can not.
I used the head of empty list error to draw a simile of why you would  
like to have a stack trace.

I do not share your opinion that monadic call traces are not of much  
use. Your example looks a bit conspicuous
to me. Consider a web application using HDBC to interface with a  
database, where a SQLError can arise and there is no
way to find out where it is coming from.
The safe-failure package (not officially released yet, but an early  
version is available
in Hackage) provides monadic versions of several partial functions in  
the Prelude.
An applicative interface is available which can make programming with  
those much more palatable.
That means you can in effect obtain a stack trace for a head of empty  
list error.

I would like, as much as anyone else, to see stack traces available  
for pure Haskell code. There are others already
pursuing that goal, but as the situation stands now, stack traces are  
available only through expensive program
transformations which cannot be used in production code. And I don't  
believe that situation is going to change
in the close future.

In contrast, monadic call traces have a simple implementation model by  
extending the bind operation
with source locations. They are available now through the MonadLoc  
preprocessor which is not tied
in any way to c-m-e. And moreover, they are unexpensive, can be used  
in production code, and can make your life
much easier in many, many cases.

I'm not sure if I managed to dispel your doubts, if not perhaps you  
could make your points more clear.

Thanks,
pepe