Newest at the top
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 |
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 |