[Haskell] Mixing monadic and non-monadic functions
frederik at a5.repetae.net
Thu Sep 8 03:38:13 EDT 2005
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.
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
> 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"?
> Haskell mailing list
> Haskell at haskell.org
More information about the Haskell