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,252
    • Issues 4,252
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 398
    • Merge Requests 398
  • 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
  • #18756

Closed
Open
Opened Sep 27, 2020 by Krzysztof Gogolewski@monoidalDeveloper

Linear types: use a predicate to check submultiplicity

Linear types currently do not support multiplicity coercions (test LinearPolyType). This restriction is enforced with a special wrapper called WpMultCoercion and by checking for reflexivity in the desugarer.

This is rather ugly. A more principled solution, once we have the predicate refactor !2857, is to use a special predicate. Then, the error can be raised during typechecking.

As a result of this ticket, the error message in LinearPolyType should be improved by pointing at the source. The error message should be shown just once (currently it is duplicated). A testcase f :: a %1 -> (); f x = () with -fdefer-type-errors is worth adding (currently it shows "Multiplicity coercions are not supported"). This ticket has no other user-visible effects. We should be able to revert the hack added in !4593 (closed).

This is blocked on the predicate refactor.

Later, we could add support for multiplicity coercions; then, this predicate would become a normal constraint. This requires changing Core and is much harder, though.

Edited Jan 04, 2021 by Krzysztof Gogolewski
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#18756