On Thu, Oct 8, 2009 at 1:42 PM, Andrew Coppin <andrewcop...@btinternet.com> wrote: > Heinrich Apfelmus wrote: >> >> Alternatively, you can use algebraic data types instead of type classes >> to generalize one program to different implementations. For monads, this >> can be achieved with >> >> http://hackage.haskell.org/package/MonadPrompt >> >> In particular, the idea is to turn every effect like >> >> getLine >> >> into a constructor >> >> GetLine >> >> and have different implementations pattern match on that. >> > > Ooo, that's interesting... > > I did wonder for a moment whether this would allow you to analyse what the > monadic action does without actually "doing" it, but on reflection this is > fundamentally impossible. The action that happens next can (and often does) > depend on the result of a previous effect. > > I guess if you wanted to run your action through an optimiser before > actually running it, you'd need to use arrows (and all the terrifying syntax > that entails)...
Or Applicatives, or some other action algebra which is appropriate for the kind of actions you are trying to encode. Don't fool yourself into thinking that Monads and Arrows are all there are; those are just two formalisms for which we have discovered a lot of uses. But if what you're trying to encode doesn't match those, then don't use them. If you want to encode actions that can be optimized before usage, expose just enough so you can find the information you need to optimize it. Luke _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
