Hacker News Reader

Comment by cloudhead | Hacker News Reader

Nice, but it misses the point that `IO` is actually pure (referentially transparent) in Haskell:

  let x = putStrLn "hello"
  in do x ; x

is equivalent to:

  do putStrLn "hello" ; putStrLn "hello"

View on HN

I don't think it really 'misses' this point, so much as it elects not to touch on this. I think the point is that the effectfulness of a value is captured in its type, but if you're trying to explain this to someone that isn't familiar with haskell, it would be somewhat more confusing than saying what was said.

I though purity was about having no side-effects. Or, in other terms. If you call the a pure function twice with the same arguments, you get the same output.

You do get the same output. main returns a monadic data-structure which tells the Haskell runtime what to output in response to certain inputs.

See: http://conal.net/blog/posts/the-c-language-is-purely-functio...

Nitpick but technically there is not a Haskell runtime, only compiler (at least if we're talking about ghc)

GHC does have a runtime system, conveniently called RTS. This page has some more details:

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

There is most definitely a haskell runtime... what do you think handles garbage collection in haskell programs.

Haskell also needs a runtime to execute its evaluation strategy which is not call stack based, but graph reduction based.

Those two statements aren't actually equivalent.

Haskell isn't pure. A truly pure programming language would be completely useless as it wouldn't be able to actually manipulate state at all.

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.

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.

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.

there are no functions that actually execute actions. That function is in the Haskell RTS, and not in your program.

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.

> 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.

In this sense even C programs are pure.

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

The runtime manipulates (external) state, the language remains pure.

Reply on news.ycombinator.com