Splitting MonadTrav, revisited

Aaron Tomb aarontomb at gmail.com
Thu Jul 23 21:19:53 EDT 2009

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.


More information about the Language-c mailing list