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,388
    • Issues 4,388
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 372
    • Merge Requests 372
  • 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
  • #3263

Closed
Open
Opened May 28, 2009 by Neil Mitchell@ndmitchellReporter

Warnings for monadic values not used

I would like two warnings. The first -fwarn-unused-monad-bind:

do doesFileExist "foo" ; return 1

doesFileExist returns a value of IO Bool, not IO (), and does not bind it's result. This warning should be applied to both do notation and >> and should fire on all values which aren't m ().

The second -fwarn-wrong-bind:

do return (doesFileExist "foo") ; return 1

doesFileExist returns a value of type IO (IO a), which is not bound. This warning should fire on all m (m a) values and also in >>.

The names of the flags are intended to be placeholders for a sensibly chosen name. I would make -fwarn-wrong-bind on as a default warning, and both turned on under -Wall. I'm not sure anyone has ever written the second construction without it being a serious error. In the case of IO it's really easy to miss that some side effects are no longer happening after a refactoring. I've just made this very mistake in fairly public way.

It seems that problems such as mapM space leaks are common, and that it is not widely known that such constructions without a named binding are always wrong. I've had to explain the problem to fairly experienced Haskell programmers.

Trac metadata
Trac field Value
Version 6.10.2
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC ndmitchell@gmail.com
Operating system
Architecture
Assignee
Assign to
6.12.1
Milestone
6.12.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#3263