The H98 report is pretty clear about there being a single name space for type constructors and classes. Yes, in certain circumstances it's unambiguous. In Hugs, can you write module M where class C a data C = MkC f :: C a => C -> C which is also unambiguous. I'm inclined to stick to the H98 story. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Iavor Diatchki | Sent: 15 October 2007 20:35 | To: haskell@haskell.org | Subject: [Haskell] Module system question | | Hello, | | I have a question concerning Haskell's module system. | Consider the following example which defines three modules A,B, and C: | | > module A where { data X = X } | > module B where { class X a } | > module C where { import A; import B; data Y = Y X } | | The question is: "Is there an ambiguity error in module C?". It seems | that the answer depends on how we interpret "ambiguous". In the | context of module C, the name X may refer to either the class defined | in module B, or the datatype defined in module A. Therefore, we could | consider X to be ambiguous, and indeed, this is what happens in GHC | 6.6. On the other hand, the name X is used in a context where we are | expecting a type constructor and not a class name, and therefore the | name X could be unambiguously taken to refer to the datatype X, which | is what seems to happen in Hugs. | | I like the Hugs behavior because it accepts more programs. OTOH, | GHC's behavior may be a bit simpler to explain and implement(?). Any | thoughts? | | -Iavor | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell