2025/03/21

Newest at the top

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?
2025-03-21 21:25:17 +0100tabaqui(~tabaqui@167.71.80.236) (Quit: WeeChat 4.5.2)
2025-03-21 21:25:00 +0100 <ski> for `main :: IO T', this means evaluating "what Input/Output operations/interactions to perform"
2025-03-21 21:24:54 +0100 <ski> sim590 : you can think of a Haskell implementation as providing a run-time which consists of two main parts. (a) a part which evaluates expressions (typically lazily, but it only needs to be non-strict, so it's e.g. allowed to evaluate things ahead of time, speculatively, as long as some kind of time-out is used, and appropriate failure catching is applied, so that no behaviour difference can be noticed).
2025-03-21 21:23:21 +0100 <EvanR> again the functions don't cause any effects
2025-03-21 21:23:11 +0100 <EvanR> the f function is pure while the State action might be seen as "impure in context"
2025-03-21 21:22:28 +0100ash3en(~Thunderbi@89.56.182.235) ash3en
2025-03-21 21:22:18 +0100 <lambdabot> (1,1)
2025-03-21 21:22:16 +0100 <EvanR> > let f n = get >>= \s -> return (n+s) in runState (f 0 >> put 1 >> f 0) 0