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,323
    • Issues 4,323
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 388
    • Merge Requests 388
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #8171

Closed
Open
Opened Aug 24, 2013 by Edward Kmett@ekmett

Extending ExtendedDefaultRules

The current ExtendedDefaultRules (see manual page) is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today.

It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3.

class Defaulting a

The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is Show, Eq, Ord or Defaulting.

I went with Defaulting rather than Default, because Default is a common class in use across the ecosystem from the data-default package, and I wanted to avoid gratuitous fallout.

This would permit projects like Shae Erisson's ghclive from last year that need to use defaulting to not have to shoe-horn unnecessary Show constraints onto functions.

Even better would be for that class to be polykinded!

That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR.

Edited Mar 09, 2019 by Simon Peyton Jones
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#8171