Hi, While I agree that Monad is closed (under >>= and >>) and is of kind * -> *, I can't say the same for Num or Monoid. Both of them are of kind *. So, you just named a few closed classes of kind *. Is that what you want? Why do you need type families for that? Isn't type class enough? (The following seems to be random thoughts on generality of closure constraint. It would be great if someone thinks the same way or can change my mind) I believe typeclasses is not the best way to express closure. For me, closure is mostly a property of operation than set itself. i.e. it's better to express it in operation type than There are a couple of issues preventing successful generalization of closure: First one is that you can have closing unary, binary, ternary etc operation. You could actually create a typeclass for each arity of operator but that's kind of silly; you can't create classes for every arity out there. Second issue is set. For Monad I can think of two ways for defining a closed set: it's either all Monads of that kind (then Monad is closed under >>=) or all values of m a type (Maybe Int, for example). In the later case you can define a stricter version of >>= (m a -> (a -> m a) -> m a) to close it. More real-world example of the second case is MonadPlus. While it's of kind * -> *, it's closed on mplus with mplus :: m a -> m a -> m a. (Probably, it's not MonadPlus is closed, but MonadPlus m => m a is closed under mplus). The last issue is absence of rules. Most mathematical concepts have some rules. The rules is what makes them worth generalizing. For example, Semigroup has a single rule (associativity of operation), but without that rule Semigroup is worthless (BTW, it would be just a type closed under .++.) . Closure, on the other hand, is just a constraint. Absence of rules also makes it possible to close the same type in many-many ways. For example, Num is closed under nine operations from Prelude module only. I believe, it's too general concept to express in typeclass and benefit from that. Regards, Alexey 2015-01-07 10:40 GMT+02:00 Nicholls, Mark :

(Caveat) In haskell specifically, i cant say, i rarely use it, and not in anger, im trying to pick it up again.

Set closure under an operation is common, and in maths is axiomatic to many theories eg group theory, in fact at some level its probably axiomatic to all maths eg model theory

Many useful operations are trivially closed eg arithmetic.

Operatosn that are closed to the domain of the operation can be generalised to N applications, eg because + on integer is closed i can apply it N times and derive * if it werent then 6*5 may be defined but 6*6 may not be! (Undefined throws a spanner in the works, but i'll ignore it)

I think in programming you rarely explicitly think about it, but you use it (arguably) everywhere

Closure under the typeclass instance type of kind *->* (i expect thats not the right way to say it) seems common in haskell, monoid, monad, num etc...... I wanted to see if there was a way to do it using type families over types of kind *, as in some ways this seems less onerous on the user of the class and more prescriptive.....ie fill in this type family def, write the operation definitoon and your done

Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.

On 7 Jan 2015, at 07:24, Dmin wrote:

hi, i'm sorry to interject but this post caught my attention.

i understand how both classes help constrain the type ops

...

...

class Foo_ (S a) => Foo a where type S a op :: a -> (S a)

but what is really on my mind is for what purpose do you want to understand "closing" a type signature in a class. As a beginner myself I would venture to say this is common in haskell, no? Is this a good analogy to the set-theory paradigm? Which I believe was the original question, right?

On Tuesday, January 6, 2015 11:18:29 AM UTC-8, Nicholls, Mark wrote:

...

In fact i had tried somethjng very much like this but without the Foo_ and haskell wasnt happy with the cyclic definition

So maybe this is the answer!

I'll let you know

Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.

...

On 6 Jan 2015, at 19:14, Nicholls, Mark wrote:

Oooo

I'll have a go with this tomorrow

Thanks

Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.

...

On 6 Jan 2015, at 19:06, adam vogt wrote:

Hi,

You can constrain the result type to be in the same class by writing something like:

{-# LANGUAGE UndecidableInstances, FlexibleInstances #-} {-# LANGUAGE TypeFamilies, FlexibleContexts #-}

class Foo_ a -- just to prevent a cycle in superclass constraints instance Foo a => Foo_ a

class Foo_ (S a) => Foo a where type S a op :: a -> (S a)

-- and an example where you get a compile error if "op x" has an instance, -- but "op (op x)" does not have an instance. instance Foo Int where type S Int = Char op = toEnum

instance Foo Char where type S Char = (Char,Char) op x = (x,x)

instance Foo (Char,Char) where type S (Char,Char) = Int op (x,y) = fromEnum x

...

On Tue, Jan 6, 2015 at 1:53 PM, Nicholls, Mark wrote: I will post the question again properly tomorrow but your example indeed is almost a good example, but is trivially closed

If the operation on monoid was

[a]->[b]->[c]

That is also closed; ie [c] is also a monoid.... And the typeclass declaration follows the idiom ive suggested

This only works for types of kind *->*

If i wanted to do this over a type of kind * (ignoring the trivial a->a)

Can i express this in a typeclass?

Please ignore until i resubmit this question

Ps i hate phones

Excuse the spelling, sent from a phone with itty bitty keys, it like trying to sow a button on a shirt with a sausage.

...

> On 6 Jan 2015, at 18:10, Tom Ellis > wrote: > > On Tue, Jan 06, 2015 at 05:43:47PM +0000, Nicholls, Mark wrote: > Its quite common in maths to have operations in a theory that are > (set) > closed, i just want to translate that notion to a typeclass

Do you really need a typeclass (or indeed any way) of doing this? I suspect it will not work. If you consider the multiplication for the monoid of concatenation of lists

(++) :: [a] -> [a] -> [a]

you see that its type already implies that it is "closed".

Tom _______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

_______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskel...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

_______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe