Opened 21 months ago

Last modified 21 months ago

#11352 new feature request

Allow applying type to label

Reported by: Iceland_jack Owned by:
Priority: normal Milestone:
Component: Compiler (Type checker) Version: 7.11
Keywords: ORF, TypeApplications Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: #11409 Differential Rev(s):
Wiki Page:


{-# LANGUAGE FlexibleInstances     #-}
{-# LANGUAGE FlexibleContexts      #-}
{-# LANGUAGE TypeApplications      #-}
{-# LANGUAGE OverloadedLabels      #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE DataKinds             #-}

import GHC.TypeLits
import GHC.OverloadedLabels

instance IsLabel "answer" Int where
  fromLabel _ = 42

answer :: IsLabel "answer" a => a
answer = #answer

The follow works:

>>> answer @Int

but fails with a label:

>>> #answer @Int
<interactive>:...:1: error:
     Cannot not apply expression of type t0
      to a visible type argument Int
     In the expression: #answer @Int
      In an equation for it: it = #answer @Int

Change History (4)

comment:1 Changed 21 months ago by adamgundry

Component: CompilerCompiler (Type checker)
Keywords: ORF added
Owner: set to adamgundry
Type of failure: None/UnknownGHC rejects valid program

I don't see any reason why this shouldn't work, I suspect the overloaded labels implementation just needs a bit of re-organization now that visible type application is implemented.

comment:2 Changed 21 months ago by adamgundry

Owner: adamgundry deleted

Hmm, this isn't as straightforward as I thought. We could change the type of fromLabel to be forall x a . IsLabel x a => a, and then implement #answer by replacing it with fromLabel @"answer". That gives you the behaviour you want, but it means that error messages mention applications of fromLabel, e.g.

    Could not deduce (IsLabel "y" t)
      arising from the overloaded label ‘#y’


    Could not deduce (IsLabel "y" t)
        arising from a use of ‘fromLabel’

which is somewhat undesirable. Moreover, overloaded string/numeric literals are similarly incompatible with visible type application. So I'm inclined to leave things as they are: after all, you can always write #answer :: Int.

comment:3 Changed 21 months ago by adamgundry

See also #11409, the corresponding ticket for numeric literals, in which Simon observes that it's possible to use an auxiliary definition instead of changing the type of fromLabel. Although it might still make sense to do the latter, now that we have type application, rather than have a Proxy# argument that is unnecessary.

comment:4 Changed 21 months ago by simonpj

Keywords: TypeApplications added
Note: See TracTickets for help on using tickets.