4 ms·

No! Haskell programs are actually pure! The main function returns a _description_ of the actions it's going to do; it doesn't actually execute those actions.

No! Haskell programs are actually pure! The main function returns a _description_ of the actions it's going to do; it doesn't actually execute those actions. You can pass these descriptions around as values, extend them, match on them and what not. Think of it like Command pattern in OOP. When you pass a command around the command doesn't actually execute. It's a value that at some later stage will be executed.

jstimpfle 7y ago
In this sense even C programs are pure.
- rnhmjoj 7y ago
  There is a famous blog post about this: The C language is purely functional. http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...
millstone 7y ago
Is there a way to distinguish between a main function that "actually" executes the actions, and one that does not? I think that laziness makes this a subtle question.
- Latty 7y ago
  The distinction would become rather clear if you call that function from other code, I imagine. In other languages things would happen, while here you would just get the return value to do what you want with.
- arianvanp 7y ago
  there are no functions that actually execute actions. That function is in the Haskell RTS, and not in your program.
  - Faark 7y ago
    Isn't that very close to being a vacuous semantic distinction at this point? I don't see much of a difference to "My C# main never actually executes. It's the .NET runtime that interprets the IL bytecode." I'm still a beginner, but having to figure out when and where to flush text to the console doesn't make haskell feel different from other imperative languages.
    - lmm 7y ago
      > I don't see much of a difference to "My C# main never actually executes. It's the .NET runtime that interprets the IL bytecode." You can't actually reason about C# programs in those terms - e.g. you can't really say whether two C# programs are equivalent except in the vacuous sense of being equal as strings or ASTs. Some basic C# functions offer only operational semantics, so you have to reason about how and when those functions are "actually executed" if you want to be able to understand programs that call those functions. E.g. you can't know whether "(foo(), foo())" is equivalent to "x = foo(); (x, x)" without thinking about "how foo() is actually executed". In contrast you can reason about Haskell programs that contain IO actions without having to understand how those IO actions are executed.

jstimpfle 7y ago

In this sense even C programs are pure.

rnhmjoj 7y ago
There is a famous blog post about this: The C language is purely functional. http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...

millstone 7y ago

Is there a way to distinguish between a main function that "actually" executes the actions, and one that does not? I think that laziness makes this a subtle question.

Latty 7y ago
The distinction would become rather clear if you call that function from other code, I imagine. In other languages things would happen, while here you would just get the return value to do what you want with.
arianvanp 7y ago
there are no functions that actually execute actions. That function is in the Haskell RTS, and not in your program.
- Faark 7y ago
  Isn't that very close to being a vacuous semantic distinction at this point? I don't see much of a difference to "My C# main never actually executes. It's the .NET runtime that interprets the IL bytecode." I'm still a beginner, but having to figure out when and where to flush text to the console doesn't make haskell feel different from other imperative languages.
  - lmm 7y ago
    > I don't see much of a difference to "My C# main never actually executes. It's the .NET runtime that interprets the IL bytecode." You can't actually reason about C# programs in those terms - e.g. you can't really say whether two C# programs are equivalent except in the vacuous sense of being equal as strings or ASTs. Some basic C# functions offer only operational semantics, so you have to reason about how and when those functions are "actually executed" if you want to be able to understand programs that call those functions. E.g. you can't know whether "(foo(), foo())" is equivalent to "x = foo(); (x, x)" without thinking about "how foo() is actually executed". In contrast you can reason about Haskell programs that contain IO actions without having to understand how those IO actions are executed.