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,869
    • Issues 4,869
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 456
    • Merge requests 456
  • 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
  • #18308
Closed
Open
Created Jun 07, 2020 by Björn Hegerfors@Bj0rnen

Order of StandaloneKindSignatures and CUSKs extensions significant

Summary

I have some code that compiles without the StandaloneKindSignatures extension, does not compile with it, but does compile again if I also add the CUSKs extension after StandaloneKindSignatures. However, if I place the CUSKs extension before StandaloneKindSignatures, then the code doesn't compile.

I'm not sure if I can avoid a CUSK in this case either, because it revolves around an associated type family, which to my understanding stand-alone kind signatures cannot (yet) be written for.

I generally try to keep my extensions arranged alphabetically, which is unfortunate in this case. But that's not at all a big worry. For now I can put CUSKs after StandaloneKindSignatures as a workaround.

Steps to reproduce

Boiling it down to a minimal demonstrative case, this compiles:

{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}

{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE CUSKs #-}

import Data.Kind (Type)
import Data.Proxy (Proxy)

class Cls where
    type Fam (k :: Type) (a :: k) :: Type
    mtd :: Proxy k -> Proxy (a :: k) -> Fam k a -> Int

but this doesn't:

{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}

{-# LANGUAGE CUSKs #-}
{-# LANGUAGE StandaloneKindSignatures #-}

import Data.Kind (Type)
import Data.Proxy (Proxy)

class Cls where
    type Fam (k :: Type) (a :: k) :: Type
    mtd :: Proxy k -> Proxy (a :: k) -> Fam k a -> Int

Expected behavior

I would expect both of the above to compile.

I should also note that it's not very clear to me what it is about the type signature for mtd that makes it problematic. The part that is sensitive here is the (a :: k) kind annotation. Whether I instead put that annotation in a forall makes no difference. If I simply remove the kind annotation for a, and let it be inferred, the code compiles regardless of which of StandaloneKindSignatures and CUSKs are enabled (and in which order). I don't know if this part behaves as expected or not.

Environment

  • GHC version used: 8.10.1
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking