4 ms·

I don't think that's what functional purity means. Actually I think there are a lot of huge misunderstandings about this. It's kind of like, think about gramma

by mbrock 8y ago

I don't think that's what functional purity means. Actually I think there are a lot of huge misunderstandings about this. It's kind of like, think about grammars of human languages. Obviously human communication involves commands. But you might still have a good reason to desire a grammar that is "purely functional" in its mathematical formulation. Pure functional programming is about establishing a certain level of formal discourse where expressions involving applications of functions reduce to values. It's not a fantasy where effects don't exist—it's a way of being precise about effects in a particular style of formalism. These expressions should be able to describe all kinds of systems, as indeed Haskell's IO type is extremely capable when it comes to describing multithreaded sequential computations involving mutable state and external effects. Conal is suggesting that the IO type is a bit crude compared to the full potential of "functional reactive programming" which is for sure a powerful paradigm.

lbj 8y ago
Im just going by the formal definition of purity 1. Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices). 2. Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams). As soon as I/O is involved, functional purity is technically broken and since any real-world system will have I/O I consider the quest for purity to be a fantasy in the same vein as developers who invest a lot of resources in "proving" their functions.
- mbrock 8y ago
  Functional purity isn't broken by Haskell-style I/O. In Haskell, I/O is not done through side effects, and I/O effects are not functions, so your points 1 and 2 are not violated. It's not a "fantasy." You just don't understand it.
  - platz 8y ago
    The post is really talking about choosing the best kind of composition to solve problems in (purity was a by-product of being mathmatical). You guys are arguing over the monadic io that he dismisses in the first couple couple paragraphs. All he really cares about is achieving program composition.

by mbrock 8y ago

lbj 8y ago

Im just going by the formal definition of purity 1. Its return value is the same for the same arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams from I/O devices). 2. Its evaluation has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or I/O streams). As soon as I/O is involved, functional purity is technically broken and since any real-world system will have I/O I consider the quest for purity to be a fantasy in the same vein as developers who invest a lot of resources in "proving" their functions.

mbrock 8y ago
Functional purity isn't broken by Haskell-style I/O. In Haskell, I/O is not done through side effects, and I/O effects are not functions, so your points 1 and 2 are not violated. It's not a "fantasy." You just don't understand it.
- platz 8y ago
  The post is really talking about choosing the best kind of composition to solve problems in (purity was a by-product of being mathmatical). You guys are arguing over the monadic io that he dismisses in the first couple couple paragraphs. All he really cares about is achieving program composition.