Newest at the top
2025-03-21 21:43:08 +0100 | <EvanR> | not in the sense of pure function |
2025-03-21 21:42:52 +0100 | <ski> | in this imperative language, you couldn't use the usual replacing-equals-by-equals reasoning that you'd do in Haskell, so it'd be side-effectful. but the implementation would compile it to (non-side-effectful) Haskell, that expresses the same effects (and behaviour in general) |
2025-03-21 21:42:47 +0100 | <EvanR> | in the sense of not having the IO type anywhere at all |
2025-03-21 21:42:37 +0100 | <EvanR> | they're using the jargon "pure" in a different sense |
2025-03-21 21:42:20 +0100 | <sim590> | I don't understand how I can consider that functions in IO are pure while I see a lot on the Web people saying they try to "keep their code pure" by doing the less they can inside IO. Why would you try to do the less you can inside IO if ALL haskell functions are pure. It seems like those two statements are incompatible. |
2025-03-21 21:41:35 +0100 | <ski> | "the State action might be seen as \"impure in context\"" -- this can be interpreted as meaning you can have a (state-)side-effectful language (perhaps you could have `main = let _ = f 0; _ = put 1 in f 0', which is compiled to the Haskell expresion, EvanR provided above |
2025-03-21 21:41:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-03-21 21:41:23 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
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? |