2024/05/03

Newest at the top

2024-05-03 16:50:02 +0200stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:46:27 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2024-05-03 16:45:22 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:44:50 +0200Square(~Square@user/square)
2024-05-03 16:41:28 +0200stiell(~stiell@gateway/tor-sasl/stiell)
2024-05-03 16:40:21 +0200danse-nr3(~danse-nr3@151.43.124.243)
2024-05-03 16:40:14 +0200stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:39:28 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-03 16:38:27 +0200gaff(~gaff@49.207.227.255) ()
2024-05-03 16:38:06 +0200 <gaff> Hey, thanks a bunch. I didn't fully resolve this here. May be i will come back later and pose the same question again.
2024-05-03 16:36:34 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2024-05-03 16:35:42 +0200k``(~k``@136.54.34.25) (Ping timeout: 250 seconds)
2024-05-03 16:35:38 +0200 <kuribas> yes
2024-05-03 16:35:06 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:34:34 +0200 <gaff> it is a sequential computation.
2024-05-03 16:34:18 +0200 <gaff> if `p` fails, the do block will short circuit.
2024-05-03 16:33:51 +0200 <kuribas> run "p" and "many p" in parallel.
2024-05-03 16:33:06 +0200onion(~yin@user/zero)
2024-05-03 16:33:04 +0200 <gaff> kuribas: I am not sure wht you are saying there. parallel where?
2024-05-03 16:32:27 +0200 <kuribas> gaff: it could, it is not "required" to work in "parallel".
2024-05-03 16:31:38 +0200stiell(~stiell@gateway/tor-sasl/stiell)
2024-05-03 16:31:33 +0200onion(~yin@user/zero) (Ping timeout: 256 seconds)
2024-05-03 16:31:03 +0200 <gaff> so when `p` fails, for example, the monadic style can short circuit computation where as the applicative style may not.
2024-05-03 16:30:26 +0200stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:30:09 +0200 <gaff> kuribas: exactly
2024-05-03 16:29:47 +0200Sgeo(~Sgeo@user/sgeo)
2024-05-03 16:29:45 +0200 <kuribas> gaff: note that 'x' could be lazy, but it most be "produced" by effect "p", before the lambda can be evaulated, which is not true in the applicated.
2024-05-03 16:27:49 +0200 <gaff> EvanR: I mean from the standpoint of evaluation/laziness.
2024-05-03 16:27:33 +0200 <EvanR> your code might be an example where they end up doing the same thing, but definitely different in general
2024-05-03 16:27:21 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2024-05-03 16:27:05 +0200 <EvanR> if the general question is, is there any difference between do notation and applicative style, yes they end up going through two different type classes
2024-05-03 16:27:02 +0200 <kuribas> gaff: not necessarily. It could be a lazy monad.
2024-05-03 16:26:30 +0200 <gaff> kuribas: I know
2024-05-03 16:26:10 +0200 <gaff> wha I found was that the binding in the `do` block forces an evaluation while in the applicative style it may/does not. I am not sure I am right, though.
2024-05-03 16:25:12 +0200 <kuribas> gaff: the do desugars to: p >>= \x -> many p >>= \xs -> return (x:xs)
2024-05-03 16:24:50 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds)
2024-05-03 16:24:31 +0200 <EvanR> different implementations
2024-05-03 16:24:30 +0200 <kuribas> gaff: For a lawful instance the should be the same, but it isn't garanteed.
2024-05-03 16:24:25 +0200 <EvanR> oh you're right. But yeah
2024-05-03 16:24:23 +0200 <gaff> well, `some` in that example has the same type in both styles.
2024-05-03 16:23:53 +0200 <EvanR> they don't have the same type by default
2024-05-03 16:23:53 +0200 <lambdabot> Num p => p
2024-05-03 16:23:52 +0200 <kuribas> :t 4
2024-05-03 16:23:51 +0200 <lambdabot> Num p => p
2024-05-03 16:23:50 +0200 <kuribas> :t 3
2024-05-03 16:23:42 +0200 <kuribas> gaff: Some type doesn't mean the same expression.
2024-05-03 16:23:25 +0200 <lambdabot> Monad m => a -> m a
2024-05-03 16:23:25 +0200 <EvanR> :t return
2024-05-03 16:23:08 +0200tv(~tv@user/tv)
2024-05-03 16:22:58 +0200 <gaff> EvanR: I am not sure what you mena there, Both expressions have the same type.