namespaces for values, types, and classes
Dear Café, types and values are in separate namespaces. So, we can write data Name = Name where the first `Name` is a type and the second is a value. However, classes are in the same namespace as types. We cannot write class Name a where ... instance Name Name where ... Class contexts and types appear in different contexts just like types and values (unless I'm missing something). I googled for the reason of this design choice but found nothing. Does anyone know why types and values are in separate namespaces but classes and types are not? Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
Sebastian Fischer wrote:
Does anyone know why types and values are in separate namespaces but classes and types are not?
Good question. I don't know the answer, but it is interesting to note that the report explicitly mentions this decision (but provides no reason): "An identifier must not be used as the name of a type constructor and a class in the same scope." http://www.haskell.org/onlinereport/intro.html Martijn.
On Nov 27, 2009, at 06:42 , Martijn van Steenbergen wrote:
Sebastian Fischer wrote:
Does anyone know why types and values are in separate namespaces but classes and types are not?
Good question. I don't know the answer, but it is interesting to note that the report explicitly mentions this decision (but provides no reason):
"An identifier must not be used as the name of a type constructor and a class in the same scope."
My guess is to make it easier to catch the error of using a class name as a type. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
On Fri, 2009-11-27 at 11:07 +0100, Sebastian Fischer wrote:
We cannot write
class Name a where ... instance Name Name where ...
Yes! Very annoying. I want to be able to make a type that is the most general instance of a single-parameter type class. This is a useful OOish thing to do. For example: class Compiler c where getInstalledPackages :: c -> ... compileModule :: c -> ... instance Compiler GHC where ... instance Compiler NHC where ... and sometimes I want a list of compilers... newtype Compiler where Compiler :: Compiler c => c -> Compiler deriving Compiler compilers :: [Compiler] compilers = [Compiler ghc, Compiler nhc]
Does anyone know why types and values are in separate namespaces but classes and types are not?
I think it's because you cannot currently distinguish them in module import/exports. Duncan
Duncan Coutts wrote: Does anyone know why types and *values* are in separate namespaces but classes and types are not?
I think it's because you cannot currently distinguish them in module import/exports.
My beginners understanding is that all imported types, functions, and classes must have either a unique signature or use qualified names such as; Data.List.sum [1,2,3] Question 1) How do *values* come into namespace issues? Question 2) Is the same dot notation used for types and classes? Question 3) Instances are not named so can they be imported? Pat
On Sun, Nov 29, 2009 at 8:42 AM, pbrowne
Question 3) Instances are not named so can they be imported?
Whenever you import a module, you automatically import all of its instances as well. In fact, there is no way to *not* include instances when importing a module. Furthermore, any instances you import are automatically re-exported by your own module. The upshot is that importing any module will automatically include any instances defined in the transitive closure of module dependencies, and there's nothing you can do to stop it. (Yes, this is sometimes very irritating, though I appreciate some of the motivations behind it. It's also one of the reasons why “orphan instances” are discouraged.) Stuart
Does anyone know why types and values are in separate namespaces but classes and types are not?
I think it's because you cannot currently distinguish them in module import/exports.
Ah, good point. For constructors there is special syntax which allows to distinguish them in im/exports. Even if you have data One = Uno data Two = One | Two and you want to im/export only the constructor `One` but neither the type `One` nor the constructor `Two` you can write `Two(One)` to refer to it. So, my assumption that class names and type names always appear in different contexts was wrong when it comes to im/exports and there doesn't seem to be an easy way to fix that. Thank you for clarifying! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
participants (6)
-
Brandon S. Allbery KF8NH -
Duncan Coutts -
Martijn van Steenbergen -
pbrowne -
Sebastian Fischer -
Stuart Cook