[Haskell] Mixing monadic and non-monadic functions

Frederik Eaton frederik at a5.repetae.net
Thu Sep 8 02:41:41 EDT 2005

> Frederik,
> To do "automatic lifting" you need to do a (higher-order) effect analysis, then make sure the 
> compiler doesn't rearrange applications which have conflicting effects.

Hrm, I disagree. I don't think this is what I was advocating in my

What I'm advocating is a reasonably simple modification of the type
checker to allow a more concise syntax. Unless I'm misunderstanding
you, there is no special "effect analysis" needed.

I haven't worked it out exactly, but what you'd do is the following:

1. keep track of when you are unifying types within a "monadic
   context"; for instance when you unify "Monad m => x -> m b" with
   "Monad m => y -> m b", you have to unify "x" and "y". this second
   unification of "x" and "y" will be done within a "context" to which
   the monad "m" has been added, to make a note of the fact that
   computations in "m" within "x" or "y" can be lifted.

2. if two types don't unify, but you can get them to unify by
   inserting a lift operation from one of the current context monads,
   then do that. e.g. when you find an application where a function
   expects an argument of type "a" and the user is passing something
   of type "m a", and "m" is in the context (so we know that we can
   eventually get rid of it), then do the application with `ap`
   instead of "$".

I don't pretend that this is rigorous, but I do hope it gives a better
idea of what I'm talking about doing. The point of the last few
paragraphs of my message was to argue that even with this syntax
change, users will still be able to easily reason about the
side-effects of monadic parts of their code. Do you disagree with that
assertion? Or are you just saying that the syntax change as I propose
it is called "effect analysis"?



More information about the Haskell mailing list