|
|
|
|
|
by cryptonector
1510 days ago
|
|
Perhaps I should have written "imperative" rather than "procedural", except no one really writes imperative non-procedural code now. > Also, “procedural” (or “imperative” or “functional”) is an attribute of programming languages, not applications/systems: It can be an attribute of programs regardless of language. It is possible to write functional-style code in C and procedural code in Haskell (just do everything in the IO monad!). > Haskell is a pure functional programming languages, in which evaluating functions has no side effects, but it can define systems that have effects. That's a bit of a fiction. Pure functions are pure, yes, but you can have impure functions -- Haskell is only interesting because you can have impure functions (otherwise every Haskell program would compile down into a constant), and what's really interesting about Haskell is the ideas that have evolved in its community about how to deal with impure functions. |
|
Not in Haskell, you can't.
> Haskell is only interesting because you can have impure functions
No, it's interesting because it provides a way of representing series of effectful operations that are distinct from its functions, which are pure.
> otherwise every Haskell program would compile down into a constant
Every program in any language that is compiled compiles down to a constant (which is, itself, usually a program, often an imperative one in a native or virtual machine language); but in Haskell, each program is (in the model of the language, not merely what they compile to) normally a constant, non-function expression, most commonly of type IO ().
It's true that values of type IO a are isomorphic to “impure nullary functions returning a” in a language which has impure functions, but they aren't functions in Haskell, and can't be called from functions, they can only be operated on as values within the language.