Opened 3 years ago
Last modified 11 months ago
#12488 new bug
Explicit namespaces doesn't enforce namespaces
Reported by: | mpickering | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler | Version: | 8.0.1 |
Keywords: | newcomer | Cc: | |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
It seems to me that the type keyword should permanently enforce that a RdrName lives in a particular namespace. Currently it only acts as a syntactic marker so that type constructors which looks like variables can be included in export lists.
The following example is accepted by GHC. As A
is parsed as a type constructor but later put into the data constructor namespace.
{-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE TypeFamilies #-} module M ( T (type A) ) where data T = A class Foo a where type A a foo :: a -> Int
The fix is to track uses of ExplicitNamespaces in the AST and then use this information in the renamer.
Change History (4)
comment:2 Changed 3 years ago by
Owner: | set to ruperthorlick |
---|
comment:3 Changed 3 years ago by
Replying to mpickering:
Simon says that we should just reject the use of explicit namespace qualifiers in the subcomponents of the export item in the parser.
This would work and be a fairly easy change, however I stumled across the following in DynFlags.hs:
-- We turn this on so that we can export associated type -- type synonyms in subordinates (e.g. MyClass(type AssocType)) , (LangExt.TypeFamilies, turnOn, LangExt.ExplicitNamespaces)
So for the above they might want to export Foo (type A)
Does this mean we need something more complicated?
comment:4 Changed 11 months ago by
Owner: | ruperthorlick deleted |
---|
Simon says that we should just reject the use of explicit namespace qualifiers in the subcomponents of the export item in the parser.