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,385
    • Issues 4,385
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 371
    • Merge Requests 371
  • 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
  • #1537

Closed
Open
Opened Jul 16, 2007 by Isaac Dupree@trac-Isaac_Dupree

do notation translation

& Really there are two things:

Normally, (do True) fails to compile in GHC because there is no Monad Bool, whereas Haskell-98 translates it to (True).

With -fno-implicit-prelude, ( according to http://comonad.com/reader/2007/parameterized-monads-in-haskell/ ):

""" Caveat: It appears that GHC enforces the fact that the arguments and results of (>>=) must have a signature like

(>>=) :: forall m a. (...) => m a -> (a -> m b) -> m b

insofar as when you use the do-sugar, your types will not be able to vary. Ideally it should be able to get by with a more liberal signature, but it seems like no one has needed it before now. """

I think do-notation will be the simplest sugar (from one point of view at least) when it just translates to (>;=), (>>), fail, and let..in.. as specified in Haskell98 (or non-Prelude-qualified when -fno-implicit-prelude, of course).

It appears #303 (closed) was an older similar problem. Also, maybe the behavior (in the new version) should be explicitly documented somewhere in the User's Guide.

Edited Mar 09, 2019 by mnislaih
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#1537