Hacker News Reader

Comment by quux | Hacker News Reader

John Carmack wrote a nice article about experiences writing functional code in C++ here:

http://www.altdevblogaday.com/2012/04/26/functional-programm...

"a function can still be pure even if it calls impure functions, as long as the side effects don’t escape the outer function"

This is a very good point that probably could be systematically exploited. Does anyone know examples of this?

I think caching/memoization is one of the most typical cases of this.

In Haskell there is the ST monad can be used to write stateful implementations for pure functions. The type system guarantees that side effects can't escape their scope.

http://www.haskell.org/haskellwiki/Monad/ST

Although this is great information I primarily had 'less pure' languages' in mind when I asked.

Come to think of it, restricting mutable access to only the relevant objects as per function call using const seems to allow just this!

A function having only const input and output "should be" free of side effects (if no global mutables); while still being allowed to run all manner of unpure processes local to its own calling context.

Clojure has "transient" (mutable) forms of its immutable datastructures, which can be bashed in place, but they're not allowed beyond function boundaries in either direction (I think). So you convert (copy?) to transient, mutate it in-place, then convert back to "persistent" before returning it.

Here's a pretty trivial example in Haskell - computing the factorial function using a mutable variable.

    import Control.Monad.ST
    import Data.STRef

    fact :: Int -> Int
    fact n = runST (fact' n)

    fact' :: Int -> ST s Int
    fact' n = do a <- newSTRef 1
                 mapM_ (\x -> modifySTRef a (*x)) [1..n]
                 readSTRef a

Here the function `fact'` uses mutable variables (encoded in the use of `ST` in its type -- `ST` stands for State Thread) but the function `fact` is pure -- the call to `runST` ensures that none of the side effects leak out of `fact'`.

As with most Haskell code, the types are optional - I included them for clarity.

> As with most Haskell code, the types are optional - I included them for clarity.

I'd just like to make it clear to anyone else reading this. The types aren't optional, but because Haskell has type inference, specifying them is optional.

That very link was at the bottom of his original response.

Ah, didn't notice it. Thanks.

If I missed it, I can't be the only one.

Reply on news.ycombinator.com