Newest at the top
2025-03-21 21:37:04 +0100 | <EvanR> | same lack of side effects |
2025-03-21 21:36:58 +0100 | <EvanR> | same implementation behind the scenes |
2025-03-21 21:36:42 +0100 | <EvanR> | just returning different types |
2025-03-21 21:36:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-21 21:36:27 +0100 | <EvanR> | you're making a mistake there, since A -> B and A -> IO () are the same kind of thing |
2025-03-21 21:36:13 +0100 | <sim590> | If that resource exists? |
2025-03-21 21:36:07 +0100 | <sim590> | I would require to read something thourugh about it (not in a IRC chat where conversations are interleaving and hard to follow). Yet, I don't wish to read a scientific paper. Yet, I'd like it rigourous enough. |
2025-03-21 21:35:21 +0100 | <EvanR> | I'll take that as a yes |
2025-03-21 21:35:04 +0100 | <sim590> | And I agree with the lemma that considers functions of the sets of all Haskell functions F minus the set of functions which have a return type `IO a` or `IO ()`. |
2025-03-21 21:34:46 +0100 | <EvanR> | are you still thinking that some functions are not pure? The ones that return IO ? |
2025-03-21 21:34:09 +0100 | <sim590> | But you can separate functions in subsets. |
2025-03-21 21:33:59 +0100 | <EvanR> | you can build programs that way |
2025-03-21 21:33:59 +0100 | <sim590> | I know that this is a function-thing. |
2025-03-21 21:33:49 +0100 | <EvanR> | you can access State or IO using Applicative |
2025-03-21 21:33:40 +0100 | <EvanR> | it's not even a monad thing |
2025-03-21 21:32:47 +0100 | <EvanR> | or put :: s -> State a () |
2025-03-21 21:32:44 +0100 | <sim590> | That's a theorem of yours, but for now I'm only accepting the lemma about Monads such as State and others that are not IO. |
2025-03-21 21:32:24 +0100 | <EvanR> | same as putChar |
2025-03-21 21:31:58 +0100 | <EvanR> | f is a function, in Haskell, so it's pure |
2025-03-21 21:31:42 +0100 | <sim590> | ... |
2025-03-21 21:31:40 +0100 | <sim590> | I was talking about `f`. |
2025-03-21 21:31:31 +0100 | <EvanR> | according to my definition |
2025-03-21 21:31:26 +0100 | <EvanR> | so pure impure doesn't even apply |
2025-03-21 21:31:16 +0100 | <sim590> | I know, you made that point earlier. |
2025-03-21 21:30:37 +0100 | <EvanR> | well State action isn't a function |
2025-03-21 21:30:20 +0100 | <sim590> | That's why it's easy for me to tell that State is not impure. But, for IO, it's a bit harder. And there was a awful lot amount of text I got from both of you and I didn't understand all the explanations when I was interleaving the read from one person's explanation with the other's. |
2025-03-21 21:30:03 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
2025-03-21 21:29:31 +0100 | <EvanR> | all those functions have no state though regardless |
2025-03-21 21:29:00 +0100 | <EvanR> | sure |
2025-03-21 21:28:51 +0100 | <sim590> | I guess, `s :: Int`. |
2025-03-21 21:28:35 +0100 | <sim590> | Yes, you think "like" you benefit from a state, but it's actually just an abstraction. Like the previous signature of `f` was an abstraction for `f :: Int -> s -> (Int, s)`. |
2025-03-21 21:27:28 +0100 | <EvanR> | but when writing a State program you think of there being an ambient state (temporarily) |
2025-03-21 21:26:51 +0100 | <EvanR> | it just passes the state around |
2025-03-21 21:26:40 +0100 | <EvanR> | even though you're not and it's just a trick |
2025-03-21 21:26:27 +0100 | <EvanR> | you could emulating being inside a stateful environment within the State program |
2025-03-21 21:26:24 +0100 | <ski> | in practice, though, (a) evaluation and (b) `IO' execution are interleaved processes |
2025-03-21 21:26:09 +0100 | <sim590> | I don't get what that means. |
2025-03-21 21:25:58 +0100 | <EvanR> | sim590, in context |
2025-03-21 21:25:55 +0100 | <ski> | sim590 : the other part being (b) an imperative interpreter, which inspects this the `main' recipe that we get by evaluating it, and actually performs the detailed I/O interactions |
2025-03-21 21:25:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-03-21 21:25:39 +0100 | <sim590> | The state action. |
2025-03-21 21:25:33 +0100 | <sim590> | EvanR: why would it be seen as impure? |
2025-03-21 21:25:17 +0100 | tabaqui | (~tabaqui@167.71.80.236) (Quit: WeeChat 4.5.2) |
2025-03-21 21:25:00 +0100 | <ski> | for `main :: IO T', this means evaluating "what Input/Output operations/interactions to perform" |
2025-03-21 21:24:54 +0100 | <ski> | sim590 : you can think of a Haskell implementation as providing a run-time which consists of two main parts. (a) a part which evaluates expressions (typically lazily, but it only needs to be non-strict, so it's e.g. allowed to evaluate things ahead of time, speculatively, as long as some kind of time-out is used, and appropriate failure catching is applied, so that no behaviour difference can be noticed). |
2025-03-21 21:23:21 +0100 | <EvanR> | again the functions don't cause any effects |
2025-03-21 21:23:11 +0100 | <EvanR> | the f function is pure while the State action might be seen as "impure in context" |
2025-03-21 21:22:28 +0100 | ash3en | (~Thunderbi@89.56.182.235) ash3en |
2025-03-21 21:22:18 +0100 | <lambdabot> | (1,1) |
2025-03-21 21:22:16 +0100 | <EvanR> | > let f n = get >>= \s -> return (n+s) in runState (f 0 >> put 1 >> f 0) 0 |