[Haskell-beginners] Re: Monadic composition without throwing genericity under the bus?

[Dave Bayer]

Thanks for all your answers.

Yes, Stephen explains exactly what I'm doing. I had been using a literate preprocessor that could have been written in Basic, but didn't include heredocs. It was very short, but I wanted something more idiomatic, so I stared at everyone's parser tutorials, wondering about monadic -vs- applicative etc. etc. The twin irritations of do notation everywhere, and ++ everywhere, pushed me over the edge to try ShowS-valued monads, and I loved how the code looked.

Normally I accept wrappers on everything as just how one does business in Haskell. As you say, to avoid undecidable type issues. Here I was struggling for days to make the code as lean as possible, and I could almost get away without wrappers.

I've been following the migration convention of ASCII for historic Prelude, Unicode for generic version of same, so I didn't want to steal ° for this one purpose; it should be categorical composition. I like the answer that m ° (->) is simply something different, I shouldn't think of it as composition. I had been using ◊ for this, I'll probably go back to it.

For a simple parser tutorial, or my immediate application of munging text e.g. literate preprocessor, ok to hardwire ShowS-valued monads. However, when one does have to break down and go into do notation (e.g. to implement my heredocs which steal the indentation from the closing EOF, and otherwise looks cleaner with multiple parsing passes), it might be slicker to use a general (a → b) type in place of ShowS. In fact, I believe one could do anything other parsers do, this way, with the benefit of most expressions being composition not requiring do-notation.

Anyhow, going further with monads returning (a → b) required me to make my peace with this composition issue, so I thank each of you!

I will write up a tutorial on this form of parsing when I submit my literate preprocessor to Cabal.

On Feb 4, 2010, at 6:25 AM, Stephen Tetley wrote:

> The parser has a type restricted return type - always a 'Hughes
> string' with efficient concatenation (ShowS :: String -> String)
> rather than some polymorphic answer (e.g a parse tree). For formatting
> it allows you to add text without consuming any:
> 
> inserttext :: String -> Parser
> inserttext str = return (showString str)
> 
> Or rewrite matched input:
> 
> rewrite :: String -> String -> Parser
> rewrite inp out = string inp >> return (showString out)
> 
> Or drop text, I presume this is what the place combinator does.
> 
> Its a nice technique.
> 
> On 4 February 2010 10:46, Heinrich Apfelmus <apfelmus at quantentunnel.de> wrote:
>> 
>> This looks intriguing! Can you elaborate on how this works?
>