Newest at the top
2024-05-03 17:01:37 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 17:00:18 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-03 16:58:43 +0200 | onion | (~yin@user/zero) (Ping timeout: 268 seconds) |
2024-05-03 16:56:27 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 16:55:10 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-03 16:54:01 +0200 | <kuribas> | RankN types are undecidable. |
2024-05-03 16:53:40 +0200 | <kuribas> | onion: what do you mean "it should be implicit"? |
2024-05-03 16:53:15 +0200 | Square | (~Square@user/square) (Ping timeout: 245 seconds) |
2024-05-03 16:52:12 +0200 | <onion> | kuribas: i know what forall means, but it should be implicit. i was testing lambdabot to try and understand which extensions were being used |
2024-05-03 16:51:33 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 16:50:02 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-03 16:46:27 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2024-05-03 16:45:22 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-03 16:44:50 +0200 | Square | (~Square@user/square) |
2024-05-03 16:41:28 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
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. |