Opened 19 months ago

Last modified 19 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:

Description

{-# 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
42

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 19 months ago by adamgundry

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

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 19 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’

becomes

    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 19 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 19 months ago by simonpj

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