I guess what I don't understand is what's wrong with the first alternative you mention:
> One way of preventing the compiler from rearranging effects is to > thread though a dummy variable - like a "World token", ala the IO > monad - which makes the order of operations explicit as an extra > data dependency, then compile the resulting code. which sounds sort of the same as the semantics I'm envisioning. Frederik On Wed, Sep 07, 2005 at 11:41:41PM -0700, Frederik Eaton wrote: > > 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 > -- http://ofb.net/~frederik/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell