Splitting MonadTrav, revisited

[Aaron Tomb]

On Jul 23, 2009, at 2:36 AM, Benedikt Huber wrote:

> Aaron Tomb wrote:
>> Hello,
>>
>> A while back, I brought up the fact that MonadTrav really serves   
>> several purposes, each of which would ideally be described by a   
>> separate class. I advocated creating one class for name  
>> generation,  one for symbol table handling, and one for the rest of  
>> what's  currently in MonadTrav.
>>
> Hi Aaron,
> I think your patch outlined below is a good idea.
>
> I had a look at our conversation about this issue - my point was  
> that due to dependencies
> we will most probably only use MonadTrav as class context in the  
> analysis, but can/should
> nevertheless split the MonadTrav class in order to modularize  
> things, keeping a common
> superclass.
> By the way, is there any reason not to have MonadError, too ?

There's no reason not to have a MonadError, too, as far as I know,  
except that the name conflicts with a class in mtl. So I separated the  
error handling, too, but called it MonadCError.

Aaron