<div dir="ltr"><div>Hi,</div><div><br></div>As mentioned before there are several ways of doing this.<div><br></div><div>1. Constrain the functions working with your types keeping the type itself unconstrained.</div><div><br></div><div>2. Write/Use a replacement for the Functor class that allows you to do this. This will usually involve associated type synonyms or functional dependencies. In my own work [1] I use associated type synonyms to do this. But there are other libraries that wrote similar replacements for the Functor class [2,3 and probably some more]. So if you want to use these you fill have to swap out the Functor (Applicative and Monad) hierarchy with another one that supports constraints.</div><div><br></div><div>So this is definitly possible and no limitation of GHC. The standard library just does not allow it.</div><div><br></div><div>Categorically a standard functor goes from the category Hask to Hask.</div><div>A restricted or constrained functor can be seen as a functor that goes from a category C (Hask with the constraints) to Hask together with an injective functor that embeds C in a subcategory of Hask (which allows you to use it in Haskell).</div><div><br></div><div>Best,</div><div>Jan</div><div><br></div><div>[1]: <a href="http://hackage.haskell.org/package/supermonad-0.1/docs/Control-Supermonad-Constrained-Functor.html">http://hackage.haskell.org/package/supermonad-0.1/docs/Control-Supermonad-Constrained-Functor.html</a></div><div>[2]: <a href="https://hackage.haskell.org/package/rmonad-0.8.0.2/docs/Control-RMonad.html#t:RFunctor">https://hackage.haskell.org/package/rmonad-0.8.0.2/docs/Control-RMonad.html#t:RFunctor</a></div><div>[3]: <a href="http://hackage.haskell.org/package/constrained-monads-0.1.0.0/docs/Control-Monad-Constrained.html#t:Functor">http://hackage.haskell.org/package/constrained-monads-0.1.0.0/docs/Control-Monad-Constrained.html#t:Functor</a></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">2017-02-28 12:00 GMT+00:00 <span dir="ltr"><<a href="mailto:haskell-cafe-request@haskell.org" target="_blank">haskell-cafe-request@haskell.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've done a bit of work on a library that allows you to `fmap` say over<br>
sets, (i.e. fmap :: Ord a, Ord b => (a -> b) -> Set a -> Set b) which is<br>
more powerful than Monofunctor as it doesn't require the types to be the<br>
same.<br>
<br>
And it will involve importing a new version of "Functor" and "fmap",<br>
however it should be largely backwards compatible.<br>
<br>
However, it still needs a little bit of work to be in a state ready to be<br>
uploaded to Hackage (and even then, it probably needs even more work) but<br>
I'll give you a buzz when its up, hopefully in the next week or so.<br>
<br>
On Tue, Feb 28, 2017 at 2:01 PM, Guru Devanla <<a href="mailto:gurudev.devanla@gmail.com">gurudev.devanla@gmail.com</a>><br>
wrote:<br>
<br>
> Thanks, Will. I think adding the constraint to the functions is a good<br>
> idea. Plus, it makes the intent clearer at the function level.<br>
><br>
><br>
><br>
> On Mon, Feb 27, 2017 at 6:02 PM, Will Yager <<a href="mailto:will.yager@gmail.com">will.yager@gmail.com</a>> wrote:<br>
><br>
>> 1. You could use MonoFunctor (complicated and probably not a good idea<br>
>> here) or just put the Taskable constraint on functions instead of on the<br>
>> Task definition (good and easy).<br>
>><br>
>> So it would be<br>
>><br>
>> data Task a = Task a deriving Functor<br>
>><br>
>> And then put "Taskable a" on functions that require it.<br>
>><br>
>> 2. You can't do it because it doesn't really make sense. A big part of a<br>
>> functor is that it has to be totally agnostic of what it's parametrized<br>
>> over. Otherwise you could easily violate the functor laws.<br>
>><br>
>> Good question though, I used to wonder the same thing.<br>
>><br>
>> cheers,<br>
>> Will<br>
>><br>
>> On Feb 27, 2017, at 6:48 PM, Guru Devanla <<a href="mailto:gurudev.devanla@gmail.com">gurudev.devanla@gmail.com</a>><br>
>> wrote:<br>
>><br>
>> Hello All,<br>
>><br>
>> I am working on a program that will define a bunch of tasks. Each task<br>
>> will have to implement certain methods as part of a type class.<br>
>><br>
>> -- task 1<br>
>> data UpdateAcctsTask = UpdateAccts<br>
>><br>
>> -- task 2<br>
>> data EmailConfig = EmaiConfig {someattrs::String}<br>
>> data SendEmailTask = SendEmailsTask EmailConfig<br>
>><br>
>> -- task 3<br>
>> data GeneralWriterTask a = GeneralWriterTask a<br>
>><br>
>> Each of these tasks implement a class, Taskable. The return<br>
>> values are simplified for this example.<br>
>><br>
>> class Taskable a where<br>
>> process :: a -> Bool<br>
>> can_run :: a -> Bool<br>
>><br>
>><br>
>> This works fine. I can expand on these tasks and execute them.<br>
>><br>
>> Now, I wanted to be able to defined dependencies between these<br>
>> (Taskable's). I decided<br>
>> I could create a data type for this dependency and may be also get a<br>
>> FreeMonad<br>
>> around this structure for further processing using a graph of Tasks. But,<br>
>> before that I wanted<br>
>> to create an wrapper for these Taskables and create a functor for it as<br>
>> follows<br>
>><br>
>> The first thing I did was, define a Task, which generalizes over all<br>
>> the above defined (and future Taskables)<br>
>><br>
>> data Task a where<br>
>> Task :: (Taskable a) => a -> Task a<br>
>><br>
>><br>
>> instance Functor Task where<br>
>> fmap:: (Taskable a, Taskable b) -> (a -> b) -> Task a -> Task b ---<br>
>> THIS DOES NOT WORK<br>
>> fmap f (Task a) = Task $ f a<br>
>><br>
>><br>
>> But, I realized that I cannot define an fmap over a type constraint.<br>
>><br>
>> My questions are:<br>
>><br>
>> 1. Is there any way to do this. I see there is an answer of SO. I wanted<br>
>> to make sure if there were any improvements to this since that answer'<br>
>> was posted.<br>
>> <a href="http://stackoverflow.com/questions/17157579/functor-instance" rel="noreferrer" target="_blank">http://stackoverflow.com/<wbr>questions/17157579/functor-<wbr>instance</a><br>
>> -for-a-gadt-with-type-<wbr>constraint<br>
>><br>
>> 2. Secondly, I would like to know why this is not possible. Is it a<br>
>> current<br>
>> limitation of GHC or if there is some fundamental category theory<br>
>> concepts<br>
>> that dis-allows such declarations that I need to grok!<br>
>><br>
>> Appreciate any help on this. Thank you!<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Haskell-Cafe mailing list<br>
>> To (un)subscribe, modify options or view archives go to:<br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
>> Only members subscribed via the mailman list are allowed to post.<br>
>><br>
>><br>
><br>
> ______________________________<wbr>_________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170228/0d255034/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/<wbr>pipermail/haskell-cafe/<wbr>attachments/20170228/0d255034/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Haskell-Cafe Digest, Vol 162, Issue 33<br>
******************************<wbr>***************<br>
</blockquote></div><br></div></div></div>