2025/03/21

Newest at the top

2025-03-21 21:56:33 +0100jmcantrell(~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 +0100michalz(~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 +0100merijn(~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 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-03-21 21:45:39 +0100alfiee(~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 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-03-21 21:41:23 +0100alfiee(~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 +0100merijn(~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