Haskell: Would "do" notation be useful for contexts other than monads?

Question

We all love do, and I was curious if perhaps this sort of alternate syntax would theoretically be useful outside of the monad world. If so, what other sorts of computations would it simplify? Would it make sense to have something equivalent for Applicative, for example?

Answer 1

There is a preprocessor in GHC to do just that for Arrows: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/arrow-notation.html

Answer 2

Applicative has (much more limited, and more compact) Idiom Brackets, see Applicative Programming with Effects, page 4. Conor McBride's Strathclyde Haskell Environment has implemented these, I believe.

I don't see how to generalize these kinds of special syntaxes, but maybe I haven't given it enough thought.

Answer 3

My sense is that many Haskell programmers don't love do at all, and one of the common arguments in favor of using Applicative when you don't need the full power of Monad is that the combinators <$>, <*>, etc. allow a very clear and concise coding style.

Even for monadic code, many people prefer using =<< explicitly instead of do notation. camccann's answer to your previous question about <*> gives a fantastic argument for this preference.

I tend to write my first drafts using do and then replace with combinators as I revise. This is just a matter of my own (in)experience and taste: it's often easiest for me to sketch things out in a more imperative fashion (which is more convenient with do), but I think non-do code is usually prettier.

For arrows, on the other hand, I can't imagine not using proc and command do. The tuples just get so ugly so quickly.

Answer 4

The do notation is basically a way of saying "transform to lambdas as needed and distribute >>= between the lines".

When it's obvious what operator is being used to roll everything up, it's nice to omit and leverage the "newline" operator.

Programmable newline would be nice way to approach makings list, applicative chains, &c. To make lists, you'd also need a "programmable outdent". Really, you could just take the three meaningful bits and make them all overloadable:

• Begin of do.
• In between dos.
• End of do.

Then you probably shouldn't call it do anymore. Maybe it should just be a bracket.

Answer 5

Idiom brackets form one nice way to think about Applicatives, but they aren't the only possible such syntax extension.

Philippa Cowderoy posted a proposal for an "Applicative do" notation to the haskell-cafe a while back with the observation that any function that looks kind of like:

foo = do
    x <- bar
    y <- baz
    quux y 1234 x

where the variables bound by <- only occur in the last line could be implemented with Applicative -- I actually implemented a syntax-rule based macro for this in scheme, which I called 'ado'.

This is useful in the cases where the order of applicative effects differs from the "natural order" and assuming the existence of 'ado' in Haskell would just desugar to:

foo = (\x y -> quux y 1234 x) <*> bar <*> baz

However, the lexical scoping rules are a bit disconcerting.

Answer 6

It might help to consider, regarding do notation itself, what it's actually good for. As Travis Brown points out, I've previously advocated the use of a "function application" style with Monads and related types, but there's a flip side to that as well: Some expressions simply can't be written cleanly in direct function application style. For instance, the following can quickly make applicative style clumsy:

• Intermediate results used in multiple subexpressions, at different depths of nesting
• Arguments to the outermost function used deeply-nested in subexpressions
• Awkward or inconsistent argument order, i.e. needing to partially apply a function to something other than its first argument
• Deeply embedded flow control based on intermediate results, with shared subexpressions between branches
• Pattern matching on intermediate results, particularly in the case of extracting part of a result, using that for further computation, then reconstructing a modified version as the next result

Writing such a function as a single expression generally requires either multiple nested lambdas, or the kind of absurd obfuscating nonsense that gives point-free style a bad name. A do block, on the other hand, provides syntactic sugar for easy nested scoping of intermediate results with embedded control flow.

Normally you'd probably extract such subexpressions and put them in a where clause or something, but since ordinary values form a monad with function application as (>>=)--namely the Identity monad--you could conceivably write such a function in a do block instead, though people might look at you funny.

---

Besides the scoping/binding stuff, the other thing a do block does for you is elide the operator that chains subexpressions together. It's not too hard to imagine other cases where it would be nice to have a notation for "combine these expressions using this function within this block", and then let the compiler fill in the blanks.

In the easy case, where the expressions all have the same type, putting them in a list and then folding it works well--building strings in this manner using unwords and unlines, for instance. The benefit of do is that it combines expressions with common structure and compatible--but not identical--types.

In fact, the same general principle is true of the "idiom bracket" notation from the Applicative paper: Where do blocks use newlines to elide monadic construction, idiom brackets use juxtaposition to elide lifted function application. The proc notation for Arrow is also similar, and other concepts could be cleanly expressed in such fashion as well, such as:

• Composing data structures, e.g. merging result sets of some sort, eliding the merge function
• Other function application idioms, such as argument-first "forward pipe" style, eliding the application operator
• Parallel computations, eliding the result aggregation function

Although it's not too hard to make many of these into either a single type or a full Monad instance, it might be nice to have a unified, extensible bit of syntactic sugar for the general concept. There's certainly a common thread tying together all these and more, but that's a much larger topic not really related to syntax...

Answer 7

There's a generalization of monads that fits with do notation - parametrized monads. See Beyond Monads by sigfpe. Example usage:

test1' = do put 1
            x <- get
            put (show x)
            y <- get
            return (x,y)

This is a "state monad" that stores first a number, and then a string.

Answer 8

BlazeHtml is using do-notation when actually it's just a Monoid (though wrapped as a Monad to be able to use do).

So a similar notation for Monoids would be useful there.

If you look at the code of my game "Defend The King", then I also do a lot of mconcating, and like BlazeHtml, I would benefit from a nice-looking syntax for that.