
#13680: Can't use TypeApplications with empty list expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A have a (very slight) hunch what might be happening here. `[]` is wired in to GHC [http://git.haskell.org/ghc.git/blob/4d9167b087abd2f4dad4ccfaba7bbde177fd2797... here]: {{{#!hs nilDataCon :: DataCon nilDataCon = pcDataCon nilDataConName alpha_tyvar [] listTyCon }}} And if you follow the definition of `pcDataCon` deep enough, you'll discover it eventually calls [http://git.haskell.org/ghc.git/blob/4d9167b087abd2f4dad4ccfaba7bbde177fd2797... this code]: {{{#!hs pcDataConWithFixity' :: Bool -> Name -> Unique -> RuntimeRepInfo -> [TyVar] -> [TyVar] -> [Type] -> TyCon -> DataCon -- The Name should be in the DataName name space; it's the name -- of the DataCon itself. pcDataConWithFixity' declared_infix dc_name wrk_key rri tyvars ex_tyvars arg_tys tycon = data_con where data_con = mkDataCon dc_name declared_infix prom_info (map (const no_bang) arg_tys) [] -- No labelled fields (mkTyVarBinders Specified tyvars) (mkTyVarBinders Specified ex_tyvars) [] -- No equality spec [] -- No theta arg_tys (mkTyConApp tycon (mkTyVarTys tyvars)) rri tycon [] -- No stupid theta (mkDataConWorkId wrk_name data_con) NoDataConRep -- Wired-in types are too simple to need wrappers no_bang = HsSrcBang NoSourceText NoSrcUnpack NoSrcStrict wrk_name = mkDataConWorkerName data_con wrk_key prom_info = mkPrelTyConRepName dc_name }}} The use of `Specified` is a tad suspicious. I tried changing it to `Required`, but unfortunately, the bug still persists after this. So there must be something else that explains this behavior, but it eludes me for now... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13680#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler