[Haskell-cafe] Typeclasses vs simple functions?

[Olex P]

Cool. It's more and more clear guys.
Thanks a lot. I'll check that "expression problem".
"Existential types" sounds a bit scary :)


On Tue, Sep 15, 2009 at 3:26 PM, Sean Leather <leather at cs.uu.nl> wrote:

>
>
>> Perimeter doesn't make sense for Sphere or Cylinder. So we could define a
>> type class for objects that have perimeter and make an instance of it only
>> for Circle (data Circle = Circle Position Radius). Make sense. But these
>> three functions above have desired behaviour. If user has a list of objects
>> like [Sphere, Circle, Circle, Cylinder] he would like to calculate
>> perimeters of each object using map perimerer list (in this case we also
>> have to modify Geometry data type).
>> So we could make instances of "perimeter" type class for all objects and
>> return zero in case if perimeter doesn't make sense.
>> Same as previous version but with typeclasses and with additional
>> constructors (constructors for each type of object + constructors in
>> Geometry data). Looks a bit overcomplicated.
>> Any reasons to use type classes in this case? Maybe there is something I'm
>> missing?
>>
>
> If you're talking about a single datatype with multiple constructors, then
> the function 'perimeter :: Geometry -> Maybe Double' makes sense. If you're
> talking about multiple datatypes, then you probably want to go type class
> route.
>
> data Sphere = Sphere ...
> data Circle = Circle ...
>
> class Perimeter a where perimeter :: a -> Double
> instance Perimeter Circle where perimeter (Circle ...) = ...
> -- No instance for Sphere
>
> class Volume a where volume :: a -> Double
> instance Volume Sphere where volume (Sphere ...) = ...
> -- No instance for Circle
>
> You have to decide whether (1) a datatype Geometry makes sense or (2) a
> datatype per geometric entity is better. One advantage to #1 is that writing
> functions over the datatype is easy. One advantage to #2 is that you have
> fewer (partial) 'Maybe' functions. This is also related to the "expression
> problem," a Googleable term.
>
> As for having a list of objects, you can do it with either approach. The
> second approach may require existential types.
>
> Regards,
> Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090915/b30e3a92/attachment.html