Newest at the top
2024-05-03 16:40:21 +0200 | danse-nr3 | (~danse-nr3@151.43.124.243) |
2024-05-03 16:40:14 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-03 16:39:28 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2024-05-03 16:38:27 +0200 | gaff | (~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 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 16:35:42 +0200 | k`` | (~k``@136.54.34.25) (Ping timeout: 250 seconds) |
2024-05-03 16:35:38 +0200 | <kuribas> | yes |
2024-05-03 16:35:06 +0200 | stiell_ | (~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 +0200 | onion | (~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 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 16:31:33 +0200 | onion | (~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 +0200 | stiell | (~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 +0200 | Sgeo | (~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 +0200 | stiell_ | (~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 +0200 | stiell_ | (~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 +0200 | tv | (~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. |
2024-05-03 16:22:15 +0200 | <EvanR> | otherwise, one expands to Monad the other Applicative class |
2024-05-03 16:21:50 +0200 | <EvanR> | not if you enable ApplicativeDo |
2024-05-03 16:21:43 +0200 | agent314_ | (~quassel@104.193.135.218) (Ping timeout: 268 seconds) |
2024-05-03 16:21:37 +0200 | agent314 | (~quassel@185.102.218.105.adsl.inet-telecom.org) |
2024-05-03 16:21:35 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |