Why category theory matters in programming

Post by Veedrac » Thu, Sep 14, 2017, 1:03 PM UTC

WkndTriathlete wrote: post #41

Veedrac wrote: post #26

> So, is there a simple and universal way to compose these functions? proceeds to add layers of complexity Why not just write a function to compose them? Argue against the competition, not strawmen.

Most code that is written has effects - null returns, error returns, exceptions, IO, etc., etc. We can write a custom function to compose every pair of functions we write, but some clever people figured out there were patterns to this madness - map, flatMap, lift, return, etc. - and it's far more efficient to write those patterns once and reuse them. Essentially, it's DRY at a higher level of abstraction.

Post by ebola1717 » Thu, Sep 14, 2017, 2:15 PM UTC

hota_mazi wrote: post #24

s4vi0r wrote: post #23

Earlier quoted context omitted.

Isn't a Monad just the fancy name for a type/structure that implements map and flatMap in a lawful manner?

Close: the required operations are `flatMap` and bind/pure/point/lift/return/whatever-you-want-to-call-it. You can derive `map` from these two other functions so it doesn't need to be part of the interface.

Post by dllthomas » Thu, Sep 14, 2017, 4:26 PM UTC

Veedrac wrote: post #42

WkndTriathlete wrote: post #41

Earlier quoted context omitted.

Most code that is written has effects - null returns, error returns, exceptions, IO, etc., etc. We can write a custom function to compose every pair of functions we write, but some clever people figured out there were patterns to this madness - map, flatMap, lift, return, etc. - and it's far more efficient to write those patterns once and reuse them. Essentially, it's DRY at a higher level of abstraction.

You still have to write each composition operator separately; writing the code to compose null returns doesn't give you the code to compose IO. Only difference is whether they have separate names.