`ApplicativeDo` needlessly uses `join` too much

foo = do
  A 1
  B 2
  C 3
  return () 

produces very different code than

foo = do
  A 1
  B 2
  C 3

for no good reason. Currently we check to see if the last clause is a return or something else, and then bolt a join in if it isn't return. But this check is too conservative. If it isn't a return but doesn't reference any of the variables above, you can still desugar it with (<*>).

We found this during a twitch livestream in front of an audience of 127 people. =)

Trac metadata

Trac field	Value
Version	8.4.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (CodeGen)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed milestone to %8.6.1

changed weight to 5

added Tbug Trac import code generation labels

added ApplicativeDo label

This is all around stmtTreeToStmts in compiler/rename/RnExpr, and needJoin seems rather relevant.

Another thing that should work doesn't quite:

foo a b c = do
  a
  b
  res <- c
  return res

This is even more surprising, because it desugars without join (and without >>=), but with >>!

Trac metadata

Trac field	Value
CC	- → dfeuer

cc'ing Simon Marlow, the king of ApplicativeDo.

Whatever emerges, I'd love to see it expressed in the language of the paper. I found the division in the paper (into a dependency analysis followed by desugaring) to be very helpful. If we could have a typeset appendix that gives the actual rules followed by GHC (including improvements described above) that would be incredibly helpful. Both for understanding the code, and for helping others who implement ApplicativeDo in their compilers.

We can easily make the paper source code available.

changed milestone to %8.8.1

These won't be addressed for GHC 8.6.

changed milestone to %8.10.1

Bumping milestones of low-priority tickets.

added Pnormal label

removed milestone