On Sun, 2009-01-11 at 10:44 +0100, Apfelmus, Heinrich wrote: > Ertugrul Soeylemez wrote: > > Let me tell you that usually 90% of my code is > > monadic and there is really nothing wrong with that. I use especially > > State monads and StateT transformers very often, because they are > > convenient and are just a clean combinator frontend to what you would do > > manually without them: passing state. > > The insistence on avoiding monads by experienced Haskellers, in > particular on avoiding the IO monad, is motivated by the quest for elegance. >
By some experienced Haskellers. Others pile them on where they feel it's appropriate, though avoiding IO where possible is still a good principle. I often find that less is essentially stateful than it looks. However, I also find that as I decompose tasks - especially if I'm willing to 'de-fuse' things - then state-like dataflows crop up again in places where they had been eliminated. Especially if I want to eg instrument or quietly abstract some code. Spotting particular sub-cases like Reader and Writer is a gain, of course! > A good example is probably the HGL (Haskell Graphics Library), a small > vector graphics library which once shipped with Hugs. The core is the type > > Graphic > > which represents a drawing and whose semantics are roughly > > Graphic = Pixel -> Color <snip> > After having constructed a graphic, you'll also want to draw it on > screen, which can be done with the function > > drawInWindow :: Graphic -> Window -> IO () > Note that there are two different things going on here. The principle of building up 'programs' in pure code to execute via IO is good - though ironically enough, plenty of combinator libraries for such tasks form monads themselves. Finding the right domain for DSL programs is also important, but this is not necessarily as neatly functional. If you start with a deep embedding rather than a shallow one then this isn't much of a problem even if you find your first attempt was fatally flawed - the DSL code's just another piece of data. -- Philippa Cowderoy <fli...@flippac.org> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
