4

Functional programming is often explained to agree with lazy evaluation.

As far as I know lazy evaluation means that a method gets called if the evaluator/browser/etc. thinks that is the next best thing to do.

I've read about lazy evaluation here.

That makes me think; promises are designed to run, and after they are done you do the next best thing. You controll the flow.

I've read that promises are functional here.

In my tiny brain, those statements are the complete opposites.

The one is telling me to evaluate a statement whenever there is time; functional programming has no side-effects so it should not matter.

The other is telling me that you should run something when there is time, but you use Async behaviour after that. In other words, you make sure one function is done, then execute the next function.

Am I correct stating that pure functional programming should not contain promises? And that functions containing promises are by definition not pure?

I know promises and callbacks can be useful, just trying to give myself a clear view of the definition of functional programming.

Improve this question
2
  • 7
    FP and lazy evaluation are orthogonal concepts
    – Daenyth
    Jun 21, 2016 at 12:41
  • 1
    To refine @Daenyth's point: a language that uses lazy evaluation as the default needs to be pure functional, but not vice-versa.
    – sacundim
    Jun 30, 2016 at 13:07

1 Answer 1

Reset to default
5

I'm more interested in answering the questions within your post, or rather the source of your confusion.

As for the question in the title: are promises functional? yes they can be. See this page for promises in Haskell, which is the prototypical pure functional programming lanugage.

Your confusion as to the side-effecting nature of promises is well deserved. Check out the linked page above and take a look at the signatures of these functions. Notice the IO? That's Haskell's way of saying that the function may have side-effects.

Stating that "functional programming has no side-effects" is a bit harsh and technically incorrect. Imagine a programming language that is not allowed to access your harddisk, get input from the keyboard or print anything to the screen. We as users have a definitive need for side-effects at some point and functional programming only embraces purity of functions as far as possible.

As @Daenyth already pointed out, lazy evaluation and FP are different things. What is really confusing these days is that the term functional programming is used to mean a lot of these different things. Lazy evaluation is one of them, but purity, GADTs, monads, pattern matching, immutability and a lot of others are thrown into the mix as well.

Even the wikipedia article on FP is carefully not exactly defining what FP is. As far as I can tell, the only thing you cannot take away from functional programming, and still call it functional programming is the lambda calculus.

Improve this answer
3
  • 2
    Haskell doesn't have side effects in the language, but does in the runtime. The idea is that a function of type a -> IO b doesn't turn an a into a b through side effects, it turns an a into a command value that tells the runtime to do some side effects, and the result of that command has type b. You can compose these commands before executing them. So a Haskell program doesn't do IO, it just figures out all the IO commands it needs to do, strings them together, then sticks the final command in a main value which the runtime executes. It's all a bit murky.
    – Jack
    Jun 21, 2016 at 16:56
  • Haskell programs can have real side effects by using unsafePerformIO to execute an IO command.
    – Jack
    Jun 21, 2016 at 16:58
  • @Jack: I would also point out that the command assigned to main can possibly be an infinite data structure. This is not a problem because the runtime lazily constructs only the parts of the main command (action) that are needed for a particular execution.
    – Giorgio
    Jun 21, 2016 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.