Newest at the top
| 2025-03-21 21:47:34 +0100 | <sim590> | Exactly. |
| 2025-03-21 21:47:29 +0100 | <EvanR> | that's just syntactic sugar |
| 2025-03-21 21:47:21 +0100 | <sim590> | and lambdas. |
| 2025-03-21 21:47:14 +0100 | <sim590> | EvanR: I don't believe that. Because, they can easily just do without the `do` operator and just use `>>=`. |
| 2025-03-21 21:46:34 +0100 | <EvanR> | so it's really expressing sentiment about imperative programming, not IO |
| 2025-03-21 21:46:14 +0100 | <EvanR> | I think whoever is saying "keep code as pure as possible" when referring to IO code, might also have similar issues if they had State everywhere |
| 2025-03-21 21:45:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 21:45:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 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 |