Why functional programming matters (1990) [pdf]

Re:Why functional programming matters (1990) [pdf] by wz1000 on Thursday May 07, 2015 @06:25AM (#9504074)

It is an absence of side effects because side effects are defined as effects that cannot be accounted for. As soon as you have a mechanism to document those effects, they are not "side effects" any more.

hello :: IO () hello = putStrLn "Hello World"

`hello` is a "pure" value of type IO (). putStrLn a "pure" function of type -> IO ()

IO () is a value like any other "pure" value, like [Int].

[ Parent | on HN ]

Re:Why functional programming matters (1990) [pdf] by denim_chicken on Thursday May 07, 2015 @10:14AM (#9505162)

C is "pure" too.

The statement

   puts ("hello");

is a "pure" value of type int.

[ Parent | on HN ]

Re:Why functional programming matters (1990) [pdf] by dllthomas on Thursday May 07, 2015 @10:26AM (#9505235)

No, that statement evaluates to a pure value of type int. In the process, it does something else as well that effects the visible behavior of the program.

The C equivalent of

    putStrLn "hello"

is probably actually

    void putsHello(void) {
        puts("hello");
    }

Unfortunately, function definitions aren't something you can really manipulate at runtime in C.

[ Parent | on HN ]

Re:Why functional programming matters (1990) [pdf] by wz1000 on Thursday May 07, 2015 @12:28PM (#9506267)

Here is a comment I wrote about the same issue some time ago:

https://news.ycombinator.com/item?id=9085403

Haskell IO is severely misunderstood.

[ Parent | on HN ]