News for hackers. Stuff that matters.

A comment on Why Functional Programming Matters (1984) [pdf]. Parent comment

Re:Why Functional Programming Matters (1984) [pdf] by pka on Thursday December 08, 2016 @08:51AM (#13130228)
> This means we can exploit any efficiency trick an imperative program can do, including low-level stuff. The seasoned FP programmer will then proceed to encapsulate the efficiency trick in a abstract module such that the rest of the program doesn't have to worry about it.

You can do that in a pure language as well (i.e. ST monad.) Purity shouldn't be given up lightly.

[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by marcosdumay on Thursday December 08, 2016 @09:29AM (#13130441)
I think he was talking about something like unsafePerformIO. There are plenty of tricks you can not write on pure monads, and there are many Haskell libs that use the unsafePerformIO trick too.
[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by pka on Thursday December 08, 2016 @09:57AM (#13130626)
> There are plenty of tricks you can not write on pure monads

This made me curious, could you list some?

[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by marcosdumay on Thursday December 08, 2016 @11:56AM (#13131733)
Anything that needs rewriting a memory address without losing time by allocation and garbage collection.

Handling IO exceptions and masking them as different errors.

Thread, process, or machine coordination in parallel execution.

[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by pka on Thursday December 08, 2016 @03:21PM (#13133909)
You don't need unsafePerformIO for any of these.

> Anything that needs rewriting a memory address without losing time by allocation and garbage collection.

ST gives you mutable references. Or just use IO.

[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by marcosdumay on Thursday December 08, 2016 @07:03PM (#13135544)
You need it for doing what the OP is talking about.
[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by kazinator on Saturday December 10, 2016 @09:09PM (#13149197)
ST monad is not state; it's a convoluted way of threading a value through a chain of functions. State means we put the value into the same memory location (or CPU register, or piece of tape or whatever).
[ Parent | on HN ]
Re:Why Functional Programming Matters (1984) [pdf] by pka on Wednesday December 14, 2016 @05:46PM (#13180412)
ST is exactly that. You probably mean the State monad.
[ Parent | on HN ]