[Haskell] Mixing monadic and non-monadic functions

[Frederik Eaton]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
> 

-- 
http://ofb.net/~frederik/