top | item 43656312

(no title)

yogsototh | 10 months ago

"Purely Functional Programming", I guess mostly Haskell/Purescript.

So this only really mean:

Purely Functional Programming by default.

In most programming languages you can write

"hello " + readLine()

And this would intermix pure function (string concatenation) and impure effect (asking the user to write some text). And this would work perfectly.

By doing so, the order of evaluation becomes essential.

With a pure functional programming (by default).

you must explicitely separate the part of your program doing I/O and the part of your program doing only pure computation. And this is enforced using a type system focusing on I/O. Thus the difference between Haskell default `IO` and OCamL that does not need it for example.

in Haskell you are forced by the type system to write something like:

    do 
      name <- getLine
      let s = "Hello " <> name <> "!"
      putStrLn s
you cannot mix the `getLine` directly in the middle of the concatenation operation.

But while this is a very different style of programming, I/O are just more explicit, and they "cost" more, because writing code with I/O is not as elegant, and easy to manipulate than pure code. Thus it naturally induce a way of coding that try to really makes you conscious about the part of your program that need IO and the part that you could do with only pure function.

In practice, ... yep, you endup working in a "Specific to your application domain" Monad that looks a lot like the IO Monad, but will most often contains IO.

Another option is to use a free monad for your entire program that makes you able to write in your own domain language and control its evaluation (either using IO or another system that simulates IO but is not really IO, typically for testing purpose).

discuss

order

lukaslalinsky|10 months ago

This is a good write up. Thank you for it. My experience with Haskell only comes from university and the focus there was primarily on the pure side of the code. I'll have a look at how Haskell deals with the pure/inpure split for some real-world tasks. The Lisp way of doing it just seems weird to me, too ad hoc, not really structured.