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,268
    • Issues 4,268
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 408
    • Merge Requests 408
  • 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
  • #4426

Closed
Open
Opened Oct 22, 2010 by Simon Peyton Jones@simonpjDeveloper

Simplify the rules for implicit quantification

This thread http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html convinced me that GHC's rules for implicit quantification are unnecessarily complicated.


== The current spec == The current spec seems to be this:

  • Define an "implicit quantification point" to be (a) the type in a type signature f :: type if type does not start with forall; or (b) a type of form (context => type), that is not immediately enclosed by an explicit forall
  • At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty).

Note that

  • The argument of a constructor is not an implicit quantification point, so that
data Foo = MkFoo (a -> a)

is an error, and does not mean

data Foo = MkFoo (forall a. a->a)
  • Implicit quantification points may be nested but the inner ones are effectively no-ops. Example
f :: Int -> (Eq a => a -> a) -> Int

There are two quantification points: the whole type, and the (Eq a => ...). But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get

f :: forall a. Int -> (Eq a => a -> a) -> Int

== The new proposal ==

The proposed new rule is this:

  • Implicit quantification applies only to an entire user type signature that does not start with forall.
  • For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with forall a,b,c.

I believe that the only observable changes in behaviour would be

  • In a data type declaration
data Foo = MkFoo (Eq a => a -> a)

you'd get an error "a is not in scope", just as you would with

data Foo = MkFoo (a->a)

To me this seems more consistent behavour.

  • Inside an explicit forall you would get no implicit foralls:
f :: forall a. (Eq b => b->b) -> a -> a

would yield "b is not in scope", whereas at present it behaves like

f :: forall a. (forall b. Eq b => b->b) -> a -> a
Trac metadata
Trac field Value
Version 6.12.3
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
8.0.1
Milestone
8.0.1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#4426