Newest at the top
2025-03-21 21:50:35 +0100 | <EvanR> | it's the same thing |
2025-03-21 21:50:22 +0100 | <EvanR> | with semantics, execute the command, pass the result to the next function in the chain to get a new command >>= |
2025-03-21 21:50:17 +0100 | <ski> | "they can easily just do without the `do` operator and just use `>>=`." -- whether they use `do' or not here is irrelevant. doesn't matter |
2025-03-21 21:49:54 +0100 | <EvanR> | chained with >>= sure |
2025-03-21 21:49:41 +0100 | <sim590> | You could say that lambdas inside lambdas are imperative programming which doesn't make sense. |
2025-03-21 21:49:22 +0100 | <ski> | they're reasoning at multiple levels. (a) reasoning on the level of *evaluation* of Haskell expressions (which have no side-effects), and (b) reasoning on the level of *execution* of `IO'-actions (which you can, if you wish, think of as reasoning in a different, side-effectful, language, as sketched above) |
2025-03-21 21:49:19 +0100 | <EvanR> | formatted chain of >>= and lambda for example |
2025-03-21 21:49:10 +0100 | <EvanR> | whatever the syntax for that is |
2025-03-21 21:49:08 +0100 | <sim590> | Yeah. |
2025-03-21 21:49:02 +0100 | <EvanR> | imperative programming means your writing sequences of statements to be executed in order |
2025-03-21 21:48:31 +0100 | <sim590> | When you talk about Imperative programming, you talk about `do`, no ? Else, I don't see what you are talking about because there's no imperative instructions in Haskell other than the ones that are "imperative-like" thanks to the do operator. |
2025-03-21 21:48:17 +0100 | <EvanR> | you can even format it so the code doesn't look very much different from do |
2025-03-21 21:48:11 +0100 | <ski> | in terms of such a side-effectful language, what they mean is that they try to "keep their code pure", in that language |
2025-03-21 21:47:49 +0100 | <EvanR> | using >>= and lambda will have the same issues because your pattern is still fundamentally imperative |
2025-03-21 21:47:47 +0100 | <ski> | side-effectful, and non-side-effectful functions, say), that compiles (the side-effectful functions to functions resulting in `IO' in Haskell, and the non-side-effectful functions to functions with other result types) |
2025-03-21 21:47:41 +0100 | <ski> | "a lot on the Web people saying they try to \"keep their code pure\" by doing the less they can inside IO." -- what they really mean here is that they try to express a larger portion of the functionality/behaviour of the program, outside of (not entangled with) `IO'. or, another way to express it, imagining a side-effectful language (similar to the one i hinted at, for `State Int', above. having both |
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 |