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
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
Hello, On 10/16/07, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
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.
My version of Hugs (20050308) rejects this because it does not allow the definition of a class and a datatype with the same name in the same module. If the class and datatype are imported from different modules (as in the example I gave), then a type signature in Hugs gives a rather strange error which to me looks like a bug :-) ERROR "C.hs":1 - Ambiguous class occurrence "X" *** Could refer to: B.X case.case
I'm inclined to stick to the H98 story.
Seems reasonable---the situations where the extra cleverness is useful are probably not that many and, in any case, one can always work around by using a qualified name. I recently noticed that the alternative rule would be quite easy to implement in a compiler that I sometimes play around with, and was wondering if that was what Haskell implementations did anyways. -- Iavor
On Mon, Oct 15, 2007 at 10:34:37PM +0300, Iavor Diatchki wrote:
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?
Currently, the class and datatype namespaces are considered the same by the standard. There is no particular reason this needs to be the case as they can always be disambiguated syntactically except in the one case of export/import lists. Some of the proposed module system changes for haskell' address this issue, which would allow fully separate namespaces for the two. Although I am not sure exactly what form it will take, I would like some reworking of the module system to allow this change in haskell'. There are some concrete proposals on the wiki, I have been meaning to make a grand unified proposal at some point that incorperates all the proposed changes (and incidentally, more importantly, proves compatibility between them) to the module system so that we may consider it. Not that I think all the proposals should go in or not as a unit, but it will give us a concrete theoretically implementable superset of all the proposals to think about and illuminate any interactions between proposals that might not be obvious when considered separately. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Iavor Diatchki -
John Meacham -
Simon Peyton-Jones