Desugar do-notation into Applicative operations (ApplicativeDo)

[zudov]

The paper describes many details and all that is easily mapped to purescript.

Essentially the process of desugaring is about splitting the do-notation statements into subsequences (parallel blocks) in such a way that the blocks don't share any binders. Those parallel blocks are then combined with map, apply and join.

That allows to make use of all the applicative benefits while still being able to use do-notation sugar.

It comes at cost of making do-notation desugaring much harder for understanding, though you could still use the simple bind desugaring as a mental model until you need to know more.

This would cause some breaking changes too:

• the imports of map and apply would have to be added in relevant places;
• the rebindable syntax trick would get more involved. Previously you could just define the bind, but now you'd have to also define the map and apply;
• when apply's semantic differs from ap's the meaning of a program might get changed.

[paf31]

I would rather add an ado keyword or something like that. The reason is that switching to Applicative can change the evaluation order. And if the Applicative instance is dodgy, it can change behavior too.

[zudov]

I would rather add an ado keyword or something like that.

I agree, with all the possible dodgyness, it would be nicer to have a special syntax form. This would avoid all the compatibility problems and make a release much-much safer.

The reason is that switching to Applicative can change the evaluation order.

I wouldn't have thought that this would be a problem unless with Haxl-like (or just any dodgy) type whose Applicative is parallelized, and Monad is sequential. Maybe you have some example to illustrate?
Of course, dodgy Applicative instances do exist and we don't want to potentially involve them in normal do-blocks.

The rules used in the paper never explicitly reorder the statements (which could be useful for getting better parallel-block splitting). I understand that this kind of reordering is not the same as effect/evaluation order that you are talking about (I guess).

Reordering the statements is only valid in a commutative
monad, where the order of effects is not observable. The Haxl
monad is not commutative, because it supports effects in the form
of exceptions, so reordering statements can change which excep-
tions are reported. In our design, we therefore never reorder com-
putations. We leave for future work the possiblity of allowing re-
ordering for commutative monads.

It might be quite fun to also have intentional reorderings under a commutative constraint of some sort...

[paf31]

Even with Maybe, do would evaluate less up front, since the evaluation of everything after the first bind is guarded by the function call.

[zudov]

Ah, true. I now actually recall hitting such things a few times. Thanks.

[ElvishJerricco]

On this front: I would suggest avoiding the pure desugaring that GHC implemented. It has lead to a number of problems. For example, pure $ ... now must be special cased in the desugarrer, because it looks like ($) pure (...), which it doesn't know how to desugar (because pure is not in front). I would suggest the use of the in keyword.

ado
  x <- foo
  y <- bar
  in x + y