> 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 message. 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"? Frederik -- http://ofb.net/~frederik/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell