Newest at the top
2025-03-21 22:02:17 +0100 | <EvanR> | no I messed it up |
2025-03-21 22:02:09 +0100 | kimiamania8 | (~65804703@user/kimiamania) (Quit: PegeLinux) |
2025-03-21 22:01:55 +0100 | <EvanR> | :: Tele () |
2025-03-21 22:01:44 +0100 | <EvanR> | would be a possible imperative program in haskell, if you defined the right Monad instance |
2025-03-21 22:01:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-21 22:01:27 +0100 | <EvanR> | PutC '?' >> GetC >>= \c -> PutC c >> PutC '!' >> Done () |
2025-03-21 22:01:24 +0100 | <EvanR> | data Tele a = GetC (Char -> Tele a) | PutC Char (Tele a) | Done a |
2025-03-21 22:00:08 +0100 | <ski> | (or the imperative programming, or the imperative behaviour, if you prefer) |
2025-03-21 21:59:07 +0100 | <ski> | but that's not how the imperative instructions here are being expressed |
2025-03-21 21:58:59 +0100 | <EvanR> | imperative programming is a vibe, not a strict concrete thing |
2025-03-21 21:58:51 +0100 | <ski> | that kind of lambda nesting can be used to express a kind of sequencing (from data-dependencies), yes |
2025-03-21 21:58:24 +0100 | <ski> | no |
2025-03-21 21:58:18 +0100 | <ski> | "You could say that lambdas inside lambdas are imperative programming which doesn't make sense." -- yea, i don't think this would make any sense |
2025-03-21 21:58:16 +0100 | <sim590> | You are saying that `(\ x -> (\ y -> x + y) 1) 1` for example is imperative programming? |
2025-03-21 21:56:40 +0100 | <ski> | the value of `main' itself is inert, doesn't "do" anything. only when the run-time system interprets these imperative instructions, does any actual input/output behaviour commence |
2025-03-21 21:56:33 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-03-21 21:55:59 +0100 | <ski> | the same holds for `main'. the value of `main' is a "set of instructions describing how to" interact with the OS, in order to effect some observable behaviour on the OS |
2025-03-21 21:55:07 +0100 | <ski> | the contents of the file `/bin/ls' on an Un*x system is not a list of files, but it's a set of instructions describing how to obtain a list of files, if/when executed (interacting with the OS) at some point |
2025-03-21 21:53:17 +0100 | <ski> | does not matter whether you express this with `do' or `>>=' |
2025-03-21 21:53:00 +0100 | <ski> | if you write `main = getLine >>= putStrLn', then the value of `main' is an `IO'-action, a recipe, a "sequence of I/O instructions" (although "sequence" is, in general, a bit inaccurate), effectively in an imperative language. this is the imperative programming we're talking about here |
2025-03-21 21:52:30 +0100 | michalz | (~michalz@185.246.207.203) |
2025-03-21 21:52:00 +0100 | <EvanR> | cmd1 >>= \result1 -> cmd2 >>= \result2 -> ... return 0 |
2025-03-21 21:51:31 +0100 | <ski> | "When you talk about Imperative programming, you talk about `do`, no ?" -- no. talking about reasoning where you have to think about implicit effects of computations, and where ordering (and possible duplication, and omisssion) of computations can have observable behavioural effects on the program |
2025-03-21 21:50:59 +0100 | <EvanR> | concrete syntax is besides the point |
2025-03-21 21:50:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
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 |