Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,844
    • Issues 4,844
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 453
    • Merge requests 453
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #13906

Closed
Open
Created Jun 30, 2017 by David Feuer@treeowlReporter

ApplicativeDo doesn't handle existentials as well as it could

ApplicativeDo doesn't work nicely with existentials or GADTs. This was first considered in #13242 (closed), but I think it's worth reconsidering in light of #13875 (closed). In particular, we no longer need to think specially about whether a particular pattern match reveals evidence, as any pattern match that does so must necessarily be strict. Simon Marlow explains (in revised, I-think-unmerged, documentation) that

    data T where A :: forall a . Eq a => a -> T

    test = do
      A x <- undefined
      _ <- return 'a'
      _ <- return 'b'
      return (x == x)

will not typecheck because it is first rearranged to

    test =
      (\x _ -> x == x)
        <$> do A x <- undefined; _ <- return 'a'; return x
        <*> return 'b'

This is weird! The more human-obvious rearrangement would work just fine:

    test = do
      A x <- undefined
      (\_ _ -> x == x) <$> return 'a' <*> return 'b'

How can we get there? I think it's actually easy. Suppose we have

  do
    p1 <- e1
    p2 <- e2
    p3 <- e3
    p4 <- e4
    p5 <- e5
    e6

Before starting the detailed dependency analysis and such, let's look just at which patterns are strict. If a pattern is strict, then every following action must be seen as depending on it, and therefore its bindings and evidence can scope over everything else. Let's say that p3 is strict. Then we can immediately transform the expression to

  do
    p1 <- e1
    p2 <- e2
    e3 >>= \case
              p3 -> do
                      p4 <- e4
                      p5 <- e5
                      e6
              -- if refutable
              _ -> fail ...

and then continue the process in the inner do block.

If this is done as an initial pass, then further rearrangement doesn't need to consider the possibility of strict patterns; there won't be any.

Trac metadata
Trac field Value
Version 8.0.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC simonmar
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking