Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • 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,968
    • Issues 4,968
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 474
    • Merge requests 474
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10928
Closed
Open
Created Oct 03, 2015 by Matthew Pickering@mpickeringDeveloper

Refine pattern synonym signatures

I think that the current state of pattern synonym signatures is quite confusing, especially regarding the constraints. For those unfamiliar, a signature looks like the following,

pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a

The first constraint being the "provided constraints" and the second the "required constraints".

My main concern is when only a single constraint is specified then these are treated as the provided constraints. The manual gives the reason that this is the "more common" choice. It seems that this motivation is driven by the original ticket which had a lengthy discussion about GADTs. In my experience, the opposite is true, it is more common to have required constraints.

This is true especially in a few common cases such as pattern Foo = 27, where users define pattern synonyms which have (overloaded) literals on the RHS. The most general signature for such a pattern is pattern :: () => (Eq a, Num a) => a.

For this reason, I think it would be better if either

  1. Only specifying one constraint corresponded to the required constraints
  2. We required users to specify both sets of constraints, even if the provided constraints are empty.

In terms of breakage, I don't think that pattern synonym signatures are widely used yet. In both schemes it is possible to write backwards compatible code by writing both sets of constraints.

I think a lot of the confusion also arises from the unusual form of the signature, it is unusual to specify two sets of constraints and I suspect users tends to assume that a single set of constraints is either provided or required depending on what they want it to mean. Forcing the specification of both, forces the user to make the distinction earlier rather than trying to decipher error messages.

This is copied from a message sent to ghc-devs. This ticket is to track the progress. But read the email thread for other comments!

Edited Mar 10, 2019 by Simon Peyton Jones
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking