Splitting MonadTrav, revisited
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:
>> 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
> 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