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

Wed Jan 7 16:56:42 UTC 2015

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 <nicholls.mark at vimn.com>:
> (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 <dgomez1092 at 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 <nichol... at vimn.com> 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 <vogt... at gmail.com> 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 <nichol... at vimn.com>
>> >>> 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
>> >>>>> <tom-lists-has... at jaguarpaw.co.uk> 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... at 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... at haskell.org
>> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >> _______________________________________________
>> >> Haskell-Cafe mailing list
>> >> Haskel... at 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... at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>