MonadComprehensions does not imply ParallelListComp?

https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/monad_comprehensions.html

... Parallel Statements ... All these features are enabled by default if the MonadComprehensions extension is enabled.

no they are not?

GHCi, version 9.12.1: https://www.haskell.org/ghc/  :? for help
ghci> :set -XMonadComprehensions 
ghci> [ (x,y,z) | x <- [1..2] , y <- [3..5] | z <-  [6..]]
<interactive>:2:13: error: [GHC-42026]
    Unexpected parallel statement in a monad comprehension

added needs triage label

added Pnormal Tbug documentation labels and removed needs triage label

Thanks for reporting this issue. Before simply fixing this logic in the compiler, we should look at the history to figure out if this is an oversight in the implementation or a change in the specification. My personal inclination is that MonadComprehensions should indeed enable ParallelListComp.

added newcomer label

I'm planning to take this on as my first issue @sheaf

Great. The first step doesn't involve writing any code: we need to figure out if this was by design, or a mistake. For example, we could look at the commit history and find out whethere there was a specification that was originally implemented.

According to the release notes for 7.2.1 (when MonadComprehensions was introduced) this was the intention. Still looking for how that was implemented at the time.

7.2.1 glasgow extensions doc

Very good. I looked at the commits a bit and found this logic:

checkParStmt :: HsStmtContext Name -> RnM ()
checkParStmt _
  = do	{ monad_comp <- xoptM Opt_MonadComprehensions
        ; unless monad_comp $ do
          { parallel_list_comp <- xoptM Opt_ParallelListComp
	  ; checkErr parallel_list_comp msg }
        }

This logic was introduced with the original MonadComprehensions patch.

So the idea in that original implementation was that MonadComprehensions should allow parallel list comprehensions to be parsed, even though it technically doesn't switch on the extension.

Given that, I think it makes sense to make the change described in the previous comment, i.e. to add the extension implication. For this, I suggest you take a look at GHC.Driver.Flags.impliedXFlags. Let me know if you have any further questions!

I'm looking to test via the build command

hadrian/build stage3:lib:ghci --build-root=_buildGhci to test something in ghci, using the nix-shell provided by ghc.nix

it fails at stage 3, not sure if this is my fault

If you are trying to run GHCi then I believe a simple invocation like the following should work:

hadrian/build -j --flavour=... --freeze1
_build/stage1/bin/ghc --interactive

mentioned in merge request !14077 (closed)

!14077 (closed) let me know if there's something I should change or improve upon, of course

mentioned in commit 64ef501f

mentioned in commit 7c3a2e4b

mentioned in commit 52bca26d

mentioned in commit 34a9b55d