Generalising Categories - categories of tuples

Hi All I've been doing some work on generalising categories, basically so the composition operator (.) works for not just functions, but things like tuples of functions, whilst still retaining type inference. Control.Category is a bit too restrictive for such instances. You can see the details in my blog post here: https://clintonmeadprogramming.wordpress.com/2016/02/16/generalising-categor... Any comments appreciated, I hope people find it interesting. Also, a quick plug, I'm looking for work, so if there's any Haskell (and/or functional programing) work around Sydney, Australia going I'd be interested. :-) If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction. Regards, Clinton Mead

Hi Clinton,
HList has some functions that help with defining something similar: <
https://gist.github.com/aavogt/50d5313c99b7224b62dd>. It might be possible
to use less classes to define the replicate/zip/map functions needed (by
using more GADTs and type families instead) and end up being allowed to
define an instance Control.Category.Category HF.
Your code will be shorter if you make instance heads more general and use
equality constraints (~). I mean that the following instance (from my
paste) gets selected as long as the first argument to ($) is a function,
and no type families are needed:
instance (a ~ a', b ~ b') => Dollar (a -> b) a' b'
where f $ x = f x
Regards,
Adam
On Tue, Feb 16, 2016 at 12:21 AM, Clinton Mead
Hi All
I've been doing some work on generalising categories, basically so the composition operator (.) works for not just functions, but things like tuples of functions, whilst still retaining type inference. Control.Category is a bit too restrictive for such instances.
You can see the details in my blog post here:
https://clintonmeadprogramming.wordpress.com/2016/02/16/generalising-categor...
Any comments appreciated, I hope people find it interesting. Also, a quick plug, I'm looking for work, so if there's any Haskell (and/or functional programing) work around Sydney, Australia going I'd be interested. :-)
If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction.
Regards,
Clinton Mead
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi Adam
Thanks for the reply. I'm not sure what you mean however by making the code
shorter. Could you show an example that relates to category composition
which my code is about, not function application?
I considered putting the category arguments in the class head like you have
in your example, but as discussed in the blog, I found I'd lose type
inference, unless I put in all the equality constraints anyway.
Could you perhaps show how I could rewrite the class and the (f1, f2) .
(f1', f2') = (f1 . f1', f2 . f2') instance with shorter code?
Thanks,
Clinton
On Wed, Feb 17, 2016 at 3:53 PM, adam vogt
Hi Clinton,
HList has some functions that help with defining something similar: < https://gist.github.com/aavogt/50d5313c99b7224b62dd>. It might be possible to use less classes to define the replicate/zip/map functions needed (by using more GADTs and type families instead) and end up being allowed to define an instance Control.Category.Category HF.
Your code will be shorter if you make instance heads more general and use equality constraints (~). I mean that the following instance (from my paste) gets selected as long as the first argument to ($) is a function, and no type families are needed:
instance (a ~ a', b ~ b') => Dollar (a -> b) a' b' where f $ x = f x
Regards, Adam
On Tue, Feb 16, 2016 at 12:21 AM, Clinton Mead
wrote: Hi All
I've been doing some work on generalising categories, basically so the composition operator (.) works for not just functions, but things like tuples of functions, whilst still retaining type inference. Control.Category is a bit too restrictive for such instances.
You can see the details in my blog post here:
https://clintonmeadprogramming.wordpress.com/2016/02/16/generalising-categor...
Any comments appreciated, I hope people find it interesting. Also, a quick plug, I'm looking for work, so if there's any Haskell (and/or functional programing) work around Sydney, Australia going I'd be interested. :-)
If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction.
Regards,
Clinton Mead
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi Clinton,
https://gist.github.com/aavogt/d8beff1f30432f5cda4f gets around the type
inference problem I think you ran into. I'm not so sure that it's better,
since that SameKs constraint is about as complicated as the type families
you need in your version.
Regards,
Adam
On Wed, Feb 17, 2016 at 12:01 AM, Clinton Mead
Hi Adam
Thanks for the reply. I'm not sure what you mean however by making the code shorter. Could you show an example that relates to category composition which my code is about, not function application?
I considered putting the category arguments in the class head like you have in your example, but as discussed in the blog, I found I'd lose type inference, unless I put in all the equality constraints anyway.
Could you perhaps show how I could rewrite the class and the (f1, f2) . (f1', f2') = (f1 . f1', f2 . f2') instance with shorter code?
Thanks,
Clinton
On Wed, Feb 17, 2016 at 3:53 PM, adam vogt
wrote: Hi Clinton,
HList has some functions that help with defining something similar: < https://gist.github.com/aavogt/50d5313c99b7224b62dd>. It might be possible to use less classes to define the replicate/zip/map functions needed (by using more GADTs and type families instead) and end up being allowed to define an instance Control.Category.Category HF.
Your code will be shorter if you make instance heads more general and use equality constraints (~). I mean that the following instance (from my paste) gets selected as long as the first argument to ($) is a function, and no type families are needed:
instance (a ~ a', b ~ b') => Dollar (a -> b) a' b' where f $ x = f x
Regards, Adam
On Tue, Feb 16, 2016 at 12:21 AM, Clinton Mead
wrote: Hi All
I've been doing some work on generalising categories, basically so the composition operator (.) works for not just functions, but things like tuples of functions, whilst still retaining type inference. Control.Category is a bit too restrictive for such instances.
You can see the details in my blog post here:
https://clintonmeadprogramming.wordpress.com/2016/02/16/generalising-categor...
Any comments appreciated, I hope people find it interesting. Also, a quick plug, I'm looking for work, so if there's any Haskell (and/or functional programing) work around Sydney, Australia going I'd be interested. :-)
If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction.
Regards,
Clinton Mead
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Mon, Feb 15, 2016 at 11:21 PM, Clinton Mead
If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction.
You may be interested in something I have been working on along the same lines [1]. I was more immediately concerned with implementing a notion of subcategories (so, restriction rather than extension), but I think it would be relatively simple to implement product categories on top of what I have. Type inference is not usually a problem with it, but there is some manual dictionary (proof) passing internally. [1]. https://github.com/ttuegel/recategorize Regards, Tom
participants (3)
-
adam vogt
-
Clinton Mead
-
Thomas Tuegel