# Wondering about Typeclasses

**URL:** <https://discourse.elm-lang.org/t/wondering-about-typeclasses/7286>\
**Category:** Request Feedback\
**Created:** [April 24, 2021, 4:42am UTC](https://discourse.elm-lang.org/t/wondering-about-typeclasses/7286 "2021-04-24T04:42:21Z")\
**Posts on this page:** 1\
**Showing post:** 79

<div class="post-metadata">

**Author:** ![eike](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/eike/32/749_2.png) [@eike](https://discourse.elm-lang.org/u/eike)\
**Post date:** [May 11, 2021, 3:45pm UTC](https://discourse.elm-lang.org/t/wondering-about-typeclasses/7286/79 "2021-05-11T15:45:20Z")

</div>

> [@mattf](#):
>
> “The syntax for using the implementations” is more than just syntax. It actually lets multiple types pass through. A contrived example would be `fmap show` to convert a boxed type to a boxed string. I had issues with this type of thing when trying to write functions to act on numbers.

This is more a lack of higher-kinded types than type classes, though. I would be fine with writing

```auto
mapIntsToStrings : ((a -> b) -> f a -> f b) -> f Int -> f String
mapIntsToStrings fmap = fmap String.fromInt

```

So you get the added abstraction power without the implicit parameters type classes essentially provide. (And you need these for (your example using) type classes anyway.)

---

_[View the full topic](https://discourse.elm-lang.org/t/wondering-about-typeclasses/7286)._