Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,395
    • Issues 4,395
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 379
    • Merge Requests 379
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #18738

Closed
Open
Opened Sep 23, 2020 by Arnaud Spiwack@aspiwackDeveloper

Infer multiplicity of case expression

Motivation

As it stands, the following expression

case u of {…}

is always understood by the typechecker as consuming u with multiplicity Many. This was done in the first iteration of patch in order to ensure being fully compatible with regular Haskell without having to delve too much into inference issue.

This applies to case expressions and to pattern guards creating a pattern:

 | pat <- u, … = …

here u is also consumed with multiplicity Many.

(In a \case or a function definition by equations, the multiplicity is decided by the type that it is checked against, if any. So it may be any multiplicity.)

Core is already equipped to deal with arbitrary multiplicities here.

Proposal

These expressions should infer the appropriate multiplicity. So typechecking such a case expression should emit a multiplicity variable instead of choosing Many systematically.

One somewhat subtle point to keep in mind is that some patterns require that the scrutinee be consumed unrestrictedly. That's the case, for instance, of wildcard patterns (_). I believe that the current implementation will handle a variable for the pattern's multiplicity smoothly (see checkManyPattern in GHC.Tc.Gen.Pat (currently). But it's worth double-checking.

For pattern guard the relevant code is the BindStmt case of tcGuardStmt in GHC.Tc.Gen.Match.

cc @monoidal

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#18738