[Haskell-cafe] Declaring Functors for Type constrained data types

Patrick Chilton chpatrick at gmail.com
Wed Mar 1 13:24:05 UTC 2017

>  Is that thinking usually an anti-pattern.

Typeclasses choose between implementations of a method based on static
*types* known at compile time. In OOP, which implementation of an interface
method you get depends on the run-time object *instance*. They're not
really related despite the similarities.

For example, if you have a list of widgets and you want to do something
different depending on what their run-time value is, a typeclass would be
the wrong thing to use since it dispatches on types, not values. It's
possible to make them work a little bit like OOP classes, but then you end
up with the classic antipattern.

On Wed, Mar 1, 2017 at 2:16 PM, Guru Devanla <gurudev.devanla at gmail.com>

> This problem I was solving is more of a re-implementation of some code  I
> had in Python. In Python, I had a very class-based structure of this
> design. By class based structure, I mean we have class-level methods for
> each class (where each class  is a type of Task), and all of them implement
> the same set of methods. This classes are never instantiated, but all
> methods are invoked on the class.
> WIth that perspective, the record patter @Patrick recommended directly
> maps to that design. The record data type here becomes a
> abstract-representation of my class(abstract base class in OO terms)  and
> each task provides its methods.  I see that relationship.  Is that the
> approach I should be aiming for?
> Secondly, while choosing the type-class approach,  I imagined all these
> required class methods to be an interface and therefore an interface could
> directly map to a type class in Haskell.  Is that thinking usually an
> anti-pattern.
> The existential antipattern
> <https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/>.
> link was very useful and made me re-asses my inclination to defining type
> classes and embedded types right away.
> On Tue, Feb 28, 2017 at 9:55 AM, Patrick Chilton <chpatrick at gmail.com>
> wrote:
>> You could also consider representing tasks like this instead of using a
>> typeclass:
>> data Task = Task
>>   { process :: m ()
>>   , canRun :: m Bool
>>   }
>> The Taskable + existential GADT example seems like it could be an example
>> of the existential antipattern
>> <https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/>
>> .
>> If your GADT really does have a as a type parameter, it would be more
>> idiomatic to check for the typeclass when you use it:
>> doStuffWithTasks :: Taskable a => Task a -> ...
>> But then what's the point of the Task datatype?
>> On Tue, Feb 28, 2017 at 1:48 AM, Guru Devanla <gurudev.devanla at gmail.com>
>> wrote:
>>> Hello All,
>>> I am working on a program that will define a bunch of tasks. Each task
>>> will have to implement certain methods as part of a type class.
>>> -- task 1
>>> data UpdateAcctsTask = UpdateAccts
>>> -- task 2
>>> data EmailConfig = EmaiConfig {someattrs::String}
>>> data SendEmailTask = SendEmailsTask EmailConfig
>>> -- task 3
>>> data GeneralWriterTask a = GeneralWriterTask a
>>> Each of these tasks implement a class, Taskable. The return
>>> values are simplified for this example.
>>> class Taskable a where
>>>   process :: a -> Bool
>>>   can_run :: a -> Bool
>>> This works fine. I can expand on these tasks and execute them.
>>> Now, I wanted to be able to defined dependencies between these
>>> (Taskable's). I decided
>>> I could create a data type for this dependency and may be also get a
>>> FreeMonad
>>> around this structure for further processing using a graph of Tasks.
>>> But, before that I wanted
>>> to create an wrapper for these Taskables and create a functor for it as
>>> follows
>>> The first thing I did was, define a Task, which generalizes over all
>>> the above defined (and future Taskables)
>>> data Task a where
>>>   Task :: (Taskable a) => a -> Task a
>>> instance Functor Task where
>>>   fmap:: (Taskable a, Taskable b) -> (a -> b) -> Task a  -> Task b
>>>   fmap f (Task a) = Task $ f a
>>> But, I realized that I cannot define an fmap over a type constraint.
>>> My questions are:
>>> 1. Is there any way to do this. I see there is an answer of SO. I wanted
>>>    to make sure if there were any improvements to this since that answer'
>>>    was posted.
>>>    http://stackoverflow.com/questions/17157579/functor-instance
>>> -for-a-gadt-with-type-constraint
>>> 2. Secondly, I would like to know why this is not possible. Is it a
>>> current
>>>    limitation of GHC or if there is some fundamental category theory
>>> concepts
>>>    that dis-allows such declarations that I need to grok!
>>> Appreciate any help on this. Thank you!
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170301/e7ab174f/attachment.html>

More information about the Haskell-Cafe mailing list