ApplicativeDo transformation
ClosedPublic

Authored by simonmar on Mar 13 2015, 11:49 AM.

Details

Summary

This is an implementation of the ApplicativeDo
proposals See the Note [ApplicativeDo] in RnExpr for details on the
current implementation, and the wiki page
https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo for design notes.

Test Plan

validate
ran all the typechecker tests with -XApplicativeDo turned on

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
simonmar retitled this revision from to Simple ApplicativeDo transformation.Mar 13 2015, 11:49 AM
simonmar updated this object.
simonmar edited the test plan for this revision. (Show Details)
simonmar added reviewers: simonpj, goldfire, austin.

I imagine this might need to go a few rounds. One thing that isn't quite right is that if there's a type error in the ApplicativeStmt then we'll report the context wrongly, it needs to be reported in terms of the original binds. I'm grateful for any advice on how best to make that happen.

simonmar updated this revision to Diff 2465.Mar 18 2015, 10:05 AM
  • Refactor ApplicativeStmt to include complete stmts
  • Improve types error messages
simonmar updated this revision to Diff 2537.Mar 27 2015, 7:15 AM
  • Add a few more tests
  • Refactoring/comments etc.

I believe this is nearly ready to go. I still need a user manual
entry of course, and I'll be doing some testing with our use case to
make sure it does what we want.

simonmar updated this revision to Diff 2538.Mar 27 2015, 8:58 AM

fix a warning

simonmar updated this revision to Diff 2539.Mar 27 2015, 9:05 AM

fix a warning

simonmar updated this revision to Diff 2540.Mar 27 2015, 10:18 AM

temp fix for T4437

simonmar updated this revision to Diff 2549.Mar 27 2015, 5:20 PM

Add support for the rest of the proposal (the latter part of step 2).

hvr added a subscriber: hvr.EditedMar 28 2015, 8:08 AM

@simonmar, have you considered in any way how ApplicativeDo would interact (i.e. if there any potential synergies) with MonadFail which is also being worked on?

simonmar added a comment.EditedMar 29 2015, 3:48 PM

I believe this should still work fine if fail is moved to a separate type class. fail is used only if any of the pattern matches are refutable, as with the plain do syntax.

simonmar updated this revision to Diff 2571.Mar 30 2015, 7:07 AM
  • Improve error messages
  • Improve debug ppr for ApplicativeLastStmt
simonmar updated this revision to Diff 2589.Mar 31 2015, 5:22 AM

Fix a bug that appeared with RebindableSyntax

simonmar updated this revision to Diff 2592.Mar 31 2015, 7:52 AM
  • Generate nested tuples
  • Simplify things, now that I realise you can generate some of the types on the fly
simonmar updated this revision to Diff 2605.Apr 1 2015, 7:13 AM

fix a bug

simonmar updated this revision to Diff 2612.Apr 1 2015, 1:41 PM

Fix a bug in zonking

simonmar updated this revision to Diff 2628.Apr 2 2015, 7:46 AM

Simplify - we don't need to store the arg_tys in ApplicativeLastStmt

simonmar updated this revision to Diff 2804.Apr 19 2015, 6:23 PM
  • Completely rewritten, handles many more cases than before
  • Removed ApplicativeBindStmt, we can do everything with join
  • Generalised ApplicativeLastStmt to allow lists of statements in the argument and body positions. This was necessary for the more general transformation.
  • lots more comments
  • lots more tests
simonmar retitled this revision from Simple ApplicativeDo transformation to ApplicativeDo transformation.Apr 19 2015, 6:25 PM
simonmar updated this object.
simonmar edited the test plan for this revision. (Show Details)
simonmar updated this revision to Diff 2805.Apr 20 2015, 7:47 AM
simonmar edited the test plan for this revision. (Show Details)

validate fixes

simonmar updated this revision to Diff 2894.May 7 2015, 8:34 AM

expand Note

zyla added a subscriber: zyla.Jul 2 2015, 12:12 AM
bgamari requested changes to this revision.Jul 5 2015, 12:00 PM
bgamari added a reviewer: bgamari.

It looks like there are still validation issues so I'm going to mark this as "needs changes" to get it out of the review queue. I'm looking forward to being able to land this though!

This revision now requires changes to proceed.Jul 5 2015, 12:00 PM

@simonmar, take note of the validation issues before merging.

simonmar updated this revision to Diff 3978.Aug 29 2015, 9:23 PM

Refactor with @simonpj's suggestions

simonmar updated this revision to Diff 3985.Aug 30 2015, 7:18 AM

Use fmap when we see do { x <- E; return x }

simonmar updated this revision to Diff 3986.Aug 30 2015, 10:08 AM

User docs

simonmar updated this revision to Diff 3999.Sep 1 2015, 8:16 AM

Changes following in-person code review with @simonpj

  • Remember the coercion arising when type-checking ApplicativeArgMany
  • Handle refutable patterns correctly
  • Sync comments & wiki
  • Improve docs

With any luck, this will be the final update!

simonmar updated this revision to Diff 4000.Sep 1 2015, 1:06 PM

Fix warning

So it appears that this validates. Are we ready to commit it? I'll do another pass over the patch either way.

yes, but there have been quite a few changes relative to the version I've been using for the last few months, so I wanted to test out the new version more thoroughly before committing.

simonmar updated this revision to Diff 4161.Sep 15 2015, 10:29 AM

remove bogus ASSERT

simonmar updated this revision to Diff 4174.Sep 17 2015, 9:29 AM

Refactored after finding a bug related to polymorphic let bindings.
Now we keep the whole "return (v1,..,vn)" expression and also the
corresponding pattern in ApplicativeArgMany; this simplifies a few
things and fixes the bug, which is now tested for in ado007.hs.

This revision was automatically updated to reflect the committed changes.