haskell - What is practical use of monoids? -

haskell - What is practical use of monoids? -

i'm reading learn haskell , i've covered applicative , i'm on monoids. have no problem understanding both, although found applicative useful in practice , monoid isn't quite so. think don't understand haskell.

first, speaking of applicative, creates uniform syntax perform various actions on 'containers'. can utilize normal functions perform actions on maybe, lists, io (should have said monads? don't know monads yet), functions:

λ> :m + control.applicative λ> (+) <$> (just 10) <*> (just 13) 23 λ> (+) <$> [1..5] <*> [1..5] [2,3,4,5,6,3,4,5,6,7,4,5,6,7,8,5,6,7,8,9,6,7,8,9,10] λ> (++) <$> getline <*> getline 1 line , 1 "one line , one" λ> (+) <$> (* 7) <*> (+ 7) $ 10 87

so applicative abstraction. think can live without helps express ideas mode , that's fine.

now, let's take @ monoid. abstraction , pretty simple one. help us? every illustration book seems obvious there more clear way things:

λ> :m + data.monoid λ> mempty :: [a] [] λ> [1..3] `mappend` [4..6] [1,2,3,4,5,6] λ> [1..3] ++ [4..6] [1,2,3,4,5,6] λ> mconcat [[1,2],[3,6],[9]] [1,2,3,6,9] λ> concat [[1,2],[3,6],[9]] [1,2,3,6,9] λ> getproduct $ product 3 `mappend` product 9 27 λ> 3 * 9 27 λ> getproduct $ product 3 `mappend` product 4 `mappend` product 2 24 λ> product [3,4,2] 24 λ> getsum . mconcat . map sum $ [1,2,3] 6 λ> sum [1..3] 6 λ> getany . mconcat . map $ [false, false, false, true] true λ> or [false, false, false, true] true λ> getall . mconcat . map $ [true, true, true] true λ> , [true, true, true] true

so have noticed patterns , created new type class... fine, math. practical point of view, point of monoid? how help improve express ideas?

gabriel gonzalez wrote in blog great info why should care, , should care. can read here (and see this).

it's scalability, architecture & design of api. thought there's "conventional architecture" says:

combine several components of type generate "network" or "topology" of type b

the issue kind of design programme scales, hell when refactor.

so want alter module improve design or domain, do. oh, module b & c depend on broke. prepare b, great. prepare c. b broke again, b used of c's functionality. , can go on forever, , if ever used oop - can you.

then there's gabriel calls "haskell architecture":

combine several components of type generate new component of same type a, indistinguishable in character substituent parts

this solves issue, elegantly too. basically: not layer modules or extend create specialized ones. instead, combine.

so now, what's encouraged instead of saying things "i have multiple x, let's create type represent union", "i have multiple x, let's combine them x". or in simple english: "let's create composable types in first place." (do sense monoids' lurking yet?).

imagine want create form webpage or application, , have module "personal info form" created because needed personal information. later found need "change image form" wrote that. , want combine them, let's create "personal info & image form" module. , in real life scalable applications can , out of hand. not forms demonstrate, need compose , compose end "personal info & alter image & alter password & alter status & manage friends & manage wishlist & alter view settings & please don't extend me anymore & please & please stop! & stop!!!!" module. not pretty, , have manage complexity in api. oh, , if want alter - has dependencies. so.. yeah.. welcome hell.

now let's @ other option, first let's @ benefit because guide it:

these abstractions scale limitlessly because preserve combinability, hence never need layer farther abstractions on top. 1 reason why should larn haskell: larn how build flat architectures.

sounds good, so, instead of making "personal info form" / "change image form" module, stop , think if can create here composable. well, can create "form", right? more abstract too. can create sense build 1 want, combine them , 1 form other.

and so, don't messy complex tree anymore, because of key take 2 forms , 1 form. form -> form -> form. , can see clearly, signature instance of mappend.

the alternative, , conventional architecture a -> b -> c , c -> d -> e , then...

now, forms it's not challenging; challenge work in real world applications. , inquire much can (because pays off, can see): how can create concept composable? , since monoids such simple way accomplish (we want simple) inquire first: how concept monoid?

sidenote: thankfully haskell much discourage extend types functional language (no inheritance). it's still possible create type something, type something, , in 3rd type have both types fields. if composition - see if can avoid it.

haskell monoids