Newest at the top
| 2025-03-21 20:52:34 +0100 | <EvanR> | e.g. getChar :: IO Char will get a char, it's not a function |
| 2025-03-21 20:52:28 +0100 | <ski> | equivalent to `{ puts("foo"); puts("foo") }' |
| 2025-03-21 20:52:22 +0100 | <ski> | sim590 : the main point here is that, unless in languages with side-effects, we have reasoning (including for refactoring) laws which doesn't have to take potential side-effects into account, can be more general ("aggressive"), you can "replace equals by equals". `let x = putStrLn "foo" in do x; x' is equal (equivalent) to `do putStrLn "foo"; putStrLn "foo";'. in C, `{ int n = puts("foo"); n; n }' is not |
| 2025-03-21 20:52:18 +0100 | <sim590> | For e.g. |
| 2025-03-21 20:52:17 +0100 | <EvanR> | sim590, you're focusing on functions returning IO, but that's not how you get side effects |
| 2025-03-21 20:52:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-21 20:52:14 +0100 | <sim590> | And depending on that circumstance, the function might return 0 or else 1. |
| 2025-03-21 20:51:11 +0100 | jespada | (~jespada@2800:a4:228e:4800:8c77:166d:4542:2a56) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-21 20:50:30 +0100 | <sim590> | This is the kind of side-effects which I see IO allowing. |
| 2025-03-21 20:50:13 +0100 | <sim590> | EvanR: to me, IO functions have side effects. I can call some IO action which will act on a MVar value and at some point my program, it might terminate and at some other point it might not because another thread has not acted on that MVar value also. |
| 2025-03-21 20:48:19 +0100 | <ski> | otherwise i'll assume we agree to disregard these) |
| 2025-03-21 20:48:13 +0100 | <ski> | "the set of functions that CAN be impure" -- there are zero such functions, in Haskell (unless you unsafe escape hatches like `unsafePerformIO', which comes with proof obligations for the programmer in order to use safely) (there is also an argument that non-termination (and partiality) can be viewed as a side-effect, albeit more "benign" than most other ones. if you want to, we could discuss this, but |
| 2025-03-21 20:47:55 +0100 | <EvanR> | it's purely functional |
| 2025-03-21 20:47:41 +0100 | <EvanR> | since all functions in haskell are pure |
| 2025-03-21 20:47:36 +0100 | tv | (~tv@user/tv) tv |
| 2025-03-21 20:47:35 +0100 | <EvanR> | all those functions are pure |
| 2025-03-21 20:47:25 +0100 | <sim590> | I'm talkinga bout THE SET of functions which have a return type `IO a`. |
| 2025-03-21 20:47:19 +0100 | tv | (~tv@user/tv) (Quit: derp) |
| 2025-03-21 20:47:12 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2025-03-21 20:47:10 +0100 | <sim590> | I'm not saying IO is a set |
| 2025-03-21 20:47:03 +0100 | <EvanR> | sim590, IO doesn't contain functions... I just get the feeling you're down the wrong path a few miles with the concepts |
| 2025-03-21 20:46:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-21 20:46:43 +0100 | <sim590> | s/why/which/ |
| 2025-03-21 20:46:29 +0100 | <sim590> | I'm talking about the functions inside the set of functions why have a return type `IO a` where `a` can be `()` also. |
| 2025-03-21 20:45:47 +0100 | <ski> | there is no "`IO' is side-effectful, but other monads are not". this is not a relevant distinction, in Haskell |
| 2025-03-21 20:45:34 +0100 | wildsalander | (~wildsalan@81-175-155-97.bb.dnainternet.fi) |
| 2025-03-21 20:44:45 +0100 | <sim590> | by "reside", I mean contained in. |
| 2025-03-21 20:44:35 +0100 | <ski> | sim590 : yes. but it's important to try to better understand the relevant concepts and distinctions (and non-distinctions), and to that end it helps being more strict about terminology, for beginners, to understand what is being claimed and not claimed, to understand the essentials of the situaation, and to ensure that we have a common ground for further conversation |
| 2025-03-21 20:44:25 +0100 | <sim590> | EvanR: I'm just saying that the set of functions that CAN be impure reside in the set that contains functions of the return type that is `IO a` where a could also be `()`. |
| 2025-03-21 20:44:24 +0100 | laurapigeon | (~laura@205.124.7.51.dyn.plus.net) (Quit: Konversation terminated!) |
| 2025-03-21 20:43:03 +0100 | <sim590> | ski: I'm not writing a scientific paper here. I'm discussing and I hope people can grasp what I mean, assuming that I have read and wrote Haskell for at least 5 years now. |
| 2025-03-21 20:41:30 +0100 | <EvanR> | calling that function doesn't execute anything |
| 2025-03-21 20:41:17 +0100 | <EvanR> | but you're calling the IO impure |
| 2025-03-21 20:41:10 +0100 | <EvanR> | that function is pure |
| 2025-03-21 20:41:06 +0100 | <EvanR> | sim590, well if you have putChar :: Char -> IO (), the important part here is the IO, not the -> |
| 2025-03-21 20:40:41 +0100 | <ski> | sim590 : "am I right to say that only IO is impure" -- `IO' is not impure |
| 2025-03-21 20:40:34 +0100 | <ski> | sim590 : "in the end, there were no side effects, just some computation abstracted away" -- you could perhaps phrase it like this, depending on what you mean by this. "calls of a function that is wrapped in a monad" is vague/confusing phrasing (specifically "wrapped in a monad", although also potentially "call") |
| 2025-03-21 20:40:32 +0100 | <sim590> | w`e mauke said is what I mean. Any function `f :: [[...] A -> ] IO a` if I can write it like that where `[]` means it's optional.. |
| 2025-03-21 20:40:24 +0100 | <ski> | sim590 : "\"side effects\" of monads are actually just behind the scene just like with the do operator, it is syntaxic sugar" -- `do' is indeed syntactic sugar, but you can't invoke that to claim something about side-effects or not of monads |
| 2025-03-21 20:40:18 +0100 | <EvanR> | and purity of functions is about... functions |
| 2025-03-21 20:40:13 +0100 | <ski> | sim590 : "this can only apply to IO and only IO is unpure" -- no, things like e.g. internal state, indeterminacy, continuations, could also cause being side-effects, not just Input/Output communication with the OS |
| 2025-03-21 20:40:07 +0100 | <EvanR> | it's just a thing that can be executed |
| 2025-03-21 20:39:58 +0100 | <EvanR> | but they don't take any arguments or input |
| 2025-03-21 20:39:48 +0100 | <EvanR> | IO actions are first class values you can pass around and store in structures |
| 2025-03-21 20:39:36 +0100 | <EvanR> | it's a big difference from imperative I/O code |
| 2025-03-21 20:39:05 +0100 | <EvanR> | any function wrapped inside IO |
| 2025-03-21 20:39:02 +0100 | <EvanR> | alskdjf |
| 2025-03-21 20:38:57 +0100 | <EvanR> | sim590, there's not necessarily any IO wrapped inside IO |
| 2025-03-21 20:38:51 +0100 | <sim590> | mauke: indeed. |
| 2025-03-21 20:38:31 +0100 | <mauke> | A -> IO B, I hope, not IO (A -> B) |