2025/03/21

Newest at the top

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
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
2025-03-21 21:31:58 +0100 <EvanR> f is a function, in Haskell, so it's pure
2025-03-21 21:31:42 +0100 <sim590> ...
2025-03-21 21:31:40 +0100 <sim590> I was talking about `f`.
2025-03-21 21:31:31 +0100 <EvanR> according to my definition
2025-03-21 21:31:26 +0100 <EvanR> so pure impure doesn't even apply
2025-03-21 21:31:16 +0100 <sim590> I know, you made that point earlier.
2025-03-21 21:30:37 +0100 <EvanR> well State action isn't a function
2025-03-21 21:30:20 +0100 <sim590> That's why it's easy for me to tell that State is not impure. But, for IO, it's a bit harder. And there was a awful lot amount of text I got from both of you and I didn't understand all the explanations when I was interleaving the read from one person's explanation with the other's.
2025-03-21 21:30:03 +0100wildsalander(~wildsalan@81-175-155-97.bb.dnainternet.fi)
2025-03-21 21:29:31 +0100 <EvanR> all those functions have no state though regardless
2025-03-21 21:29:00 +0100 <EvanR> sure
2025-03-21 21:28:51 +0100 <sim590> I guess, `s :: Int`.
2025-03-21 21:28:35 +0100 <sim590> Yes, you think "like" you benefit from a state, but it's actually just an abstraction. Like the previous signature of `f` was an abstraction for `f :: Int -> s -> (Int, s)`.
2025-03-21 21:27:28 +0100 <EvanR> but when writing a State program you think of there being an ambient state (temporarily)
2025-03-21 21:26:51 +0100 <EvanR> it just passes the state around
2025-03-21 21:26:40 +0100 <EvanR> even though you're not and it's just a trick
2025-03-21 21:26:27 +0100 <EvanR> you could emulating being inside a stateful environment within the State program
2025-03-21 21:26:24 +0100 <ski> in practice, though, (a) evaluation and (b) `IO' execution are interleaved processes
2025-03-21 21:26:09 +0100 <sim590> I don't get what that means.
2025-03-21 21:25:58 +0100 <EvanR> sim590, in context
2025-03-21 21:25:55 +0100 <ski> sim590 : the other part being (b) an imperative interpreter, which inspects this the `main' recipe that we get by evaluating it, and actually performs the detailed I/O interactions
2025-03-21 21:25:44 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-03-21 21:25:39 +0100 <sim590> The state action.
2025-03-21 21:25:33 +0100 <sim590> EvanR: why would it be seen as impure?