separate class and type namespace

older
Re: [Haskell-cafe] Re[2]: strict...

John Meacham

30 Jan 2006 30 Jan '06

10:42 p.m.

What do people think about seperating the class and type namespaces? one can always tell the difference syntactically which is meant, the only thing keeping them in the same space in jhc is an artificial check to ensure you don't create some of the same name. the only issue is in export/import lists if you wanted to allow import/export of the type independently of the class. however the proposed explicit namespace change to the import/export syntax would solve this too and it is unlikely to actually be a problem in practice. this would allow things like one to have a class and a data type holding an arbitrary member of said class to have the same name. it is unwieldy to have things like FooClass and Foo be separate. John -- John Meacham - ⑆repetae.net⑆john⑈

Show replies by date

Taral

31 Jan 31 Jan

2:52 a.m.

On 1/30/06, John Meacham wrote:

...

What do people think about seperating the class and type namespaces? one can always tell the difference syntactically which is meant, the only thing keeping them in the same space in jhc is an artificial check to ensure you don't create some of the same name.

I like the idea. It would merge well with the existential type for single-parameter classes proposal. -- Taral "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

Bulat Ziganshin

9:16 a.m.

New subject: give equal rights to types and classes! :)

Hello John, Tuesday, January 31, 2006, 6:42:14 AM, you wrote: JM> What do people think about seperating the class and type namespaces? one i have exactly opposite idea - give the class and type names equal rights :) instead of writing foo :: (Num a, Monad m) => a -> m () allow to write foo :: Num -> Monad () and vice versa - instead of bar :: Int -> [Int] allow to write bar :: (Int a, [] b) => a -> b a That this gives? 1) significantly simplifies declarations using typeclasses. i was seriously bitten by those huge declarations, and think that simplification in this area will lead to much wider use of type classes by the ordibary users (like me :) . ideally, i just don't need to think whether a Foo is a class or type in most cases - both can be used interchangeably (like interfaces and classes in Java) 2) this allows to refactor existing code without changing type signatures. just for example - imagine that [] is now a typeclass implementing only several basic operations, namely head/tail/(:)/null. nevertheless, all those huge number of list-processing functions still work because [] in their type signatures now means that parameter/result belong to the some instance of this class. cool? i think so :) of course, that also need possibility to define pattern matching (meaning of []/a:b) inside this class, but that's a different proposal :) two uses of the same class in one declaration should mean the same type, as in: reverse :: [a] -> [a] what is equivalent to reverse :: ([] c) => c a -> c a Of course, refactoring of [] is just amazing example. what i basically mean - when program grows and some T becomes an interface instead of type, there should be no need to change all the T usages - they will continue to work, work and work. The only exception will be type signatures, where T is used ywo times or more and different T's usages can mean different types. in this case, we need to switch to expanded signature, what nevertheless should work even if T is still just a type: cvt :: (T a, T b) => a->b JM> this would allow things like one to have a class and a data type holding JM> an arbitrary member of said class to have the same name _may be_, my proposal can even solve your problem -- Best regards, Bulat mailto:bulatz@HotPOP.com

Johannes Waldmann

9:34 a.m.

New subject: give equal rights to types and classes! :)

Bulat Ziganshin wrote:

...

instead of writing foo :: (Num a, Monad m) => a -> m () allow to write foo :: Num -> Monad ()

as has been noted, that would be special treatment for unary type classes with argument of kind *. Also, *if* we want such a shorthand, it is not clear whether we want existential or forall typing per default. Referring to your example, the "foo" function must be able to return a value in *each* monad that the caller specifies at the call site, while we were discussing functions that make their own choice of returning *some* monad instance. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

Bulat Ziganshin

1 Feb 1 Feb

11:58 a.m.

New subject: Re[2]: give equal rights to types and classes! :)

Hello Johannes, Tuesday, January 31, 2006, 5:34:44 PM, you wrote: JW> Bulat Ziganshin wrote:

...

...
instead of writing foo :: (Num a, Monad m) => a -> m () allow to write foo :: Num -> Monad ()

JW> as has been noted, that would be special treatment JW> for unary type classes with argument of kind *. not sure. multi-parameter type classes will be equivalent to parametric types: class (Monad m) => Stream m h ... foo :: Stream m h -> m () equals to foo :: (Stream m h) => h -> m () JW> Also, *if* we want such a shorthand, it is not clear whether we want JW> existential or forall typing per default. Referring to your example, JW> the "foo" function must be able to return a value in *each* monad JW> that the caller specifies at the call site, while we were discussing JW> functions that make their own choice of returning *some* monad instance. *i* mean just syntax sugar, short-hand for existing forall declarations, which i'm using a lot just now btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs author mean using underscore for "(exists a . a)" types -- Best regards, Bulat mailto:bulatz@HotPOP.com

Philippa Cowderoy

7:38 p.m.

New subject: Re[2]: give equal rights to types and classes! :)

On Wed, 1 Feb 2006, Bulat Ziganshin wrote:

...

btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs author mean using underscore for "(exists a . a)" types

No I don't, for a number of technical reasons. -- flippa@flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances.

Bulat Ziganshin

2 Feb 2 Feb

6:45 a.m.

New subject: Re[3]: give equal rights to types and classes! :)

Hello Philippa, Thursday, February 02, 2006, 3:38:15 AM, you wrote:

...

...
btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs author mean using underscore for "(exists a . a)" types

PC> No I don't, for a number of technical reasons. are you sure? this "_" means "any type that compiler will find appropriate". is it not the same as "exists a . a" ? -- Best regards, Bulat mailto:bulatz@HotPOP.com

Philippa Cowderoy

11:59 a.m.

New subject: Re[3]: give equal rights to types and classes! :)

On Thu, 2 Feb 2006, Bulat Ziganshin wrote:

...

Hello Philippa,

Thursday, February 02, 2006, 3:38:15 AM, you wrote:

...
...
btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs author mean using underscore for "(exists a . a)" types

PC> No I don't, for a number of technical reasons.

are you sure? this "_" means "any type that compiler will find appropriate". is it not the same as "exists a . a" ?

Not in the context of a predicative type system. Also, if we treat it simply as an annotation (exists a . a), we end up throwing away the additional information inferred. -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

Taral

3:10 p.m.

New subject: Re[3]: give equal rights to types and classes! :)

On 2/2/06, Philippa Cowderoy wrote:

...

Not in the context of a predicative type system. Also, if we treat it simply as an annotation (exists a . a), we end up throwing away the additional information inferred.

There's that word again. Can someone explain what "predicative" means, in detail? -- Taral "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

Philippa Cowderoy

4:11 p.m.

New subject: Re[3]: give equal rights to types and classes! :)

On Thu, 2 Feb 2006, Taral wrote:

...

On 2/2/06, Philippa Cowderoy wrote:

...
Not in the context of a predicative type system. Also, if we treat it simply as an annotation (exists a . a), we end up throwing away the additional information inferred.

There's that word again. Can someone explain what "predicative" means, in detail?

For historical reasons that's hard work. The short version is "type variables can only be instantiated to monotypes", whereas in an impredicative system type variables can be instantiated to types including quantifiers. -- flippa@flippac.org 'In Ankh-Morpork even the shit have a street to itself... Truly this is a land of opportunity.' - Detritus, Men at Arms

Wolfgang Jeltsch

6:22 p.m.

New subject: give equal rights to types and classes! :)

Am Dienstag, 31. Januar 2006 15:16 schrieb Bulat Ziganshin:

...

[...]

...

1) significantly simplifies declarations using typeclasses. i was seriously bitten by those huge declarations, and think that simplification in this area will lead to much wider use of type classes by the ordibary users (like me :) .

"Simple" doesn't necessarily mean "small". In my opinion, your smaller type declarations are confusing since they mix up classes and types. Classes and types are two totally different things. A class corresponds to a set of types, not to a single type, and a class has methods which a type has not.

...

[...]

Best wishes, Wolfgang

Bulat Ziganshin

3 Feb 3 Feb

4:30 a.m.

New subject: Re[2]: give equal rights to types and classes! :)

Hello Wolfgang, Friday, February 03, 2006, 2:22:17 AM, you wrote:

...

...
1) significantly simplifies declarations using typeclasses. i was seriously bitten by those huge declarations, and think that simplification in this area will lead to much wider use of type classes by the ordibary users (like me :) .

WJ> "Simple" doesn't necessarily mean "small". In my opinion, your smaller type WJ> declarations are confusing since they mix up classes and types. Classes and WJ> types are two totally different things. A class corresponds to a set of WJ> types, not to a single type, and a class has methods which a type has not. type have the same methods, they are just not expressed directly. are you know history of Array -> IArray change? functions "(!)", "bounds" and so on in magic way round to class methods. if my idea was incorporated in Haskell, this change don't require even changing signatures of most functions working with arrays - just Array type become Array interface, what a much difference? Now i'm trying to generalize my functions parameters/results to type classes instead of single types. for example, getFileSize function can return any numeric value, be it Integer, Word or Int64. This, naturally, results in those long and awkward signatures. Allowing to write type of result as just "Integral" makes signature smaller and more understandable for me: getFileSize :: Stream Monad h -> Monad Integral -- Best regards, Bulat mailto:bulatz@HotPOP.com

Marcin 'Qrczak' Kowalczyk

6:23 p.m.

New subject: give equal rights to types and classes! :)

Bulat Ziganshin writes:

...

if my idea was incorporated in Haskell, this change don't require even changing signatures of most functions working with arrays - just Array type become Array interface, what a much difference?

What would 'Eq -> Eq -> Ord -> Bool' mean? '(Eq a, Eq b, Ord c) => a -> b -> c -> Bool'? '(Eq a, Ord b) => a -> a -> b -> Bool'? '(Eq a, Ord a) => a -> a -> a -> Bool'? -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Bulat Ziganshin

4 Feb 4 Feb

5:48 a.m.

New subject: Re[2]: give equal rights to types and classes! :)

Hello Marcin, Saturday, February 04, 2006, 2:23:50 AM, you wrote:

...

...
if my idea was incorporated in Haskell, this change don't require even changing signatures of most functions working with arrays - just Array type become Array interface, what a much difference?

What would 'Eq -> Eq -> Ord -> Bool' mean? MQK> '(Eq a, Eq b, Ord c) => a -> b -> c -> Bool'? MQK> '(Eq a, Ord b) => a -> a -> b -> Bool'? MQK> '(Eq a, Ord a) => a -> a -> a -> Bool'? as i stated in the post, the one class name instantiates one variable. so the proper variant will be second i know that this syntax can't substitute ALL possible uses of preconsitions, it's just for most common, in my sense. moreover, it will help to convert currently used types to classes, and to easily refactor user programs back and forth between using types and classes -- Best regards, Bulat mailto:bulatz@HotPOP.com

Dave Menendez

3 Feb 3 Feb

7:52 p.m.

New subject: Re[2]: give equal rights to types and classes! :)

Bulat Ziganshin writes:

...

Now i'm trying to generalize my functions parameters/results to type classes instead of single types. for example, getFileSize function can return any numeric value, be it Integer, Word or Int64. This, naturally, results in those long and awkward signatures. Allowing to write type of result as just "Integral" makes signature smaller and more understandable for me:

getFileSize :: Stream Monad h -> Monad Integral

How does that type translate back into current Haskell? Assuming "Stream" is a type, and not a class, I see at least three possibilities: (Integral a, Monad m) => Stream m h -> m a (Integral a, Monad m1, Monad m2) => Stream m1 h -> m2 a (Integral a, Monad m) => (forall m. Monad m => Stream m h) -> m a -- David Menendez | "In this house, we obey the laws http://www.eyrie.org/~zednenem | of thermodynamics!"

7045

Age (days ago)

7049

Last active (days ago)

List overview

Download

14 comments

8 participants

participants (8)

Bulat Ziganshin
Dave Menendez
Johannes Waldmann
John Meacham
Marcin 'Qrczak' Kowalczyk
Philippa Cowderoy
Taral
Wolfgang Jeltsch