cafe, Data Constructors and Type Constructors don't share the same namespace. You see code like the following all the time:
data MyRecord = MyRecord {...}
This is possible because Data Constructors are used in different parts of the code than Type Constructors so there's never any ambiguity. Type Classes, on the other hand, share the same namespace as Type Constructors. You can't define this:
class String s where ...
instance String String where ... instance String ByteString where ... instance String Text where ...
Not that I'm running out of valid haskell identifiers or anything :P, I'm just wondering: what's the rationale behind keeping Type Classes and Type Constructors in the same namespace? I can't think of any ambiguity there would be if they each had their own namespace. And In some cases it would be convenient to be able to define both a concrete representation and an abstract one with the same name as in the String class example above. --Jonathan
2 seconds after sending I realized the issue is in module exports:
Module String where (String(..))
is that exporting some concrete ADT with all of its constructors or an abstract type class with all of its methods? Its too bad that Classes and ADTs overlap in export syntax and as such must share a namespace. I would much prefer
Module String where (class String(..), data String(..), someOtherFunction)
which I think is easier for the reader anyway. --Jonathan On Mon, Nov 15, 2010 at 8:31 PM, Jonathan Geddes <geddes.jonathan@gmail.com> wrote:
cafe,
Data Constructors and Type Constructors don't share the same namespace. You see code like the following all the time:
data MyRecord = MyRecord {...}
This is possible because Data Constructors are used in different parts of the code than Type Constructors so there's never any ambiguity.
Type Classes, on the other hand, share the same namespace as Type Constructors. You can't define this:
class String s where ...
instance String String where ... instance String ByteString where ... instance String Text where ...
Not that I'm running out of valid haskell identifiers or anything :P, I'm just wondering: what's the rationale behind keeping Type Classes and Type Constructors in the same namespace? I can't think of any ambiguity there would be if they each had their own namespace. And In some cases it would be convenient to be able to define both a concrete representation and an abstract one with the same name as in the String class example above.
--Jonathan
If I were to guess, I'd say it's because there are two major "spaces" in Haskell, the type level and the value level. They never interact directly (their terms are never juxtaposed) so there's not much chance for confusion. "Typeclass constructors" and type constructors do however live in the same space. The fact that you propose "instance String String" might be odd to some. It's still unambiguous, but isn't necessarily the most clear: (with higher-sorted kind polymorphism, MPTCs, type families, and GADTs) instance String String String String String where data String String String String String where String :: String String String String String :-) On Mon, Nov 15, 2010 at 10:37 PM, Jonathan Geddes <geddes.jonathan@gmail.com
wrote:
2 seconds after sending I realized the issue is in module exports:
Module String where (String(..))
is that exporting some concrete ADT with all of its constructors or an abstract type class with all of its methods?
Its too bad that Classes and ADTs overlap in export syntax and as such must share a namespace. I would much prefer
Module String where (class String(..), data String(..), someOtherFunction)
which I think is easier for the reader anyway.
--Jonathan
On Mon, Nov 15, 2010 at 8:31 PM, Jonathan Geddes <geddes.jonathan@gmail.com> wrote:
cafe,
Data Constructors and Type Constructors don't share the same namespace. You see code like the following all the time:
data MyRecord = MyRecord {...}
This is possible because Data Constructors are used in different parts of the code than Type Constructors so there's never any ambiguity.
Type Classes, on the other hand, share the same namespace as Type Constructors. You can't define this:
class String s where ...
instance String String where ... instance String ByteString where ... instance String Text where ...
Not that I'm running out of valid haskell identifiers or anything :P, I'm just wondering: what's the rationale behind keeping Type Classes and Type Constructors in the same namespace? I can't think of any ambiguity there would be if they each had their own namespace. And In some cases it would be convenient to be able to define both a concrete representation and an abstract one with the same name as in the String class example above.
--Jonathan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tue, 2010-11-16 at 00:55 -0500, Daniel Peebles wrote:
If I were to guess, I'd say it's because there are two major "spaces" in Haskell, the type level and the value level. They never interact directly (their terms are never juxtaposed) so there's not much chance for confusion. "Typeclass constructors" and type constructors do however live in the same space. The fact that you propose "instance String String" might be odd to some. It's still unambiguous, but isn't necessarily the most clear:
(with higher-sorted kind polymorphism, MPTCs, type families, and GADTs)
instance String String String String String where data String String String String String where String :: String String String String String
:-)
data Buffalo = Buffalo class Buffalo b where type familly Buffalo b instance Buffalo Buffalo where type familly Buffalo Buffalo = Buffalo instance Buffalo b => Buffalo (Buffalo b) where type familly Buffalo (Buffalo b) = b But: data Buffalo b = Buffalo b class Buffalo b where type familly Buffalo b -- Is it about Buffalo (type) b being buffalo or result of -- Buffalo (type function) being Buffalo? instance Buffalo b => Buffalo (Buffalo b) where type familly Buffalo (Buffalo b) = b Regards
participants (3)
-
Daniel Peebles -
Jonathan Geddes -
Maciej Piechotka