Re: [Haskell-cafe] typeclass woes...how to constain a typeclass to be "closed" under an operation....

(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 mailto:dgomez1092@gmail.com> 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 javascript:> 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 javascript:> 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 javascript:> 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 javascript:> 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.orgjavascript: 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.orgjavascript: http://www.haskell.org/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskel...@haskell.orgjavascript: 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.orgjavascript: 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.