| 2025-01-31 00:04:43 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-31 00:06:53 +0100 | <glguy> | My favorite Data. misuse is Data.Kind |
| 2025-01-31 00:07:03 +0100 | <tomsmeding> | (re mechanisms to resolve ambiguity: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/package_qualified_imports.html#exte… ) |
| 2025-01-31 00:09:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 00:10:58 +0100 | <dminuoso> | Relatedly https://downloads.haskell.org/ghc/latest/docs/users_guide/packages.html#package-thinning-and-renam… |
| 2025-01-31 00:11:36 +0100 | <dminuoso> | Unsure how controllable that is via cabal-install |
| 2025-01-31 00:12:28 +0100 | <geekosaur> | "mixins" should handle both |
| 2025-01-31 00:12:53 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 245 seconds) |
| 2025-01-31 00:13:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-01-31 00:14:40 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 00:14:57 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-01-31 00:18:50 +0100 | <dminuoso> | A while ago transformers has received these nice diagrams to visualize what the respective transformers do: https://hackage.haskell.org/package/transformers-0.6.1.2/docs/Control-Monad-Trans-Writer-CPS.html |
| 2025-01-31 00:19:06 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-31 00:19:09 +0100 | <dminuoso> | We're just missing a diagram for Cont. Cant be that hard, right? :-) |
| 2025-01-31 00:19:28 +0100 | <geekosaur> | i,i "Cont be that hard" |
| 2025-01-31 00:19:37 +0100 | <dminuoso> | Heh. |
| 2025-01-31 00:21:02 +0100 | <EvanR> | haskell is famous for laissez faire programming. Terrible I'm outta here |
| 2025-01-31 00:21:02 +0100 | <int-e> | please pass all the details to `const "I don't want to hear it."` |
| 2025-01-31 00:21:15 +0100 | <EvanR> | looking for a language for more bondage and discipline |
| 2025-01-31 00:22:30 +0100 | <geekosaur> | surely there's an appropriate DT language |
| 2025-01-31 00:23:03 +0100 | rstromlund | (~user@user/rstromlund) (Ping timeout: 252 seconds) |
| 2025-01-31 00:24:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 00:28:15 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-31 00:31:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-01-31 00:31:59 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2025-01-31 00:32:46 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-01-31 00:32:46 +0100 | ChanServ | +v haskellbridge |
| 2025-01-31 00:35:39 +0100 | <monochrom> | You know what, I have to understand Reader and Writer first before I understand those two diagrams. |
| 2025-01-31 00:35:57 +0100 | xff0x | (~xff0x@ai096095.d.east.v6connect.net) (Ping timeout: 252 seconds) |
| 2025-01-31 00:36:07 +0100 | <monochrom> | And generally I have to understand bind first. |
| 2025-01-31 00:37:39 +0100 | <monochrom> | But State is missing a diagram and that's a well-known diagram. |
| 2025-01-31 00:38:06 +0100 | xff0x | (~xff0x@2405:6580:b080:900:704:c9bd:a645:9b1d) |
| 2025-01-31 00:38:22 +0100 | <monochrom> | Conjecture: Such a diagram exists iff the monad is of an algebraic effect. Cont is not an algebraic effect. |
| 2025-01-31 00:42:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 00:42:51 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 252 seconds) |
| 2025-01-31 00:44:14 +0100 | joeyadams | (~joeyadams@syn-184-054-105-097.res.spectrum.com) |
| 2025-01-31 00:46:35 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 252 seconds) |
| 2025-01-31 00:47:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 00:49:59 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-31 00:52:02 +0100 | <euouae> | <https://en.wikibooks.org/wiki/Haskell/Understanding_monads/State> "A monad is sometimes described as providing a value in a context." -- this is very close to what I was thinking when I said monads are like state machines |
| 2025-01-31 00:54:15 +0100 | <dminuoso> | euouae: Monads are an abstract interface. |
| 2025-01-31 00:54:36 +0100 | <dminuoso> | Comparing them to anything concrete is, at best, just likening it to that specific instance, but that prevents you from seeing what monad is about. |
| 2025-01-31 00:54:52 +0100 | <int-e> | now I want a burrito |
| 2025-01-31 00:55:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 00:57:25 +0100 | <dminuoso> | euouae: My best recommendation is to just not worry about what Monad means at all. `IO` is about side effects. `[]` is about lists. `Maybe` is about failure. `Either A` is about exceptions. Each example is trivial to explain to any beginner |
| 2025-01-31 00:58:09 +0100 | <dminuoso> | Monad is just observing that all of these things have some pattern and laws in common. There's not really any inherent meaning to it |
| 2025-01-31 00:58:40 +0100 | <dminuoso> | And if people stop trying to attach meaning to that word `Monad`, they get on learning Haskell much faster. |
| 2025-01-31 00:58:45 +0100 | <monochrom> | I do not mind specific instances that may limit one's imagination because it is part of the learning process. |
| 2025-01-31 00:59:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 01:00:31 +0100 | rstromlund | (~user@user/rstromlund) rstromlund |
| 2025-01-31 01:00:41 +0100 | <monochrom> | Consider how "numbers" are taught beginning with natural numbers and, eventually, if you go to math grad school, ending with algebraic number fields. Not the other way round. |
| 2025-01-31 01:01:00 +0100 | <dminuoso> | monochrom: Sure, but that particular wikibooks article is not about promoting any learning process. |
| 2025-01-31 01:01:22 +0100 | <dminuoso> | If Monad tutorials started with just proclamining `Monads are just IO`, this would be a feasible strategy. |
| 2025-01-31 01:01:44 +0100 | <dminuoso> | As you could gradually introduce more instances and different "flavours" |
| 2025-01-31 01:02:54 +0100 | <monochrom> | That one I agree with you. It's the equivalent of a biology tutorial saying "natural selection is described as survival of fittest" |
| 2025-01-31 01:04:03 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 01:05:18 +0100 | rstromlund | (~user@user/rstromlund) (Ping timeout: 252 seconds) |
| 2025-01-31 01:08:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 01:08:58 +0100 | <euouae> | dminuoso: I'm not trying to summarize all monads or anything of the short, just to adopt a mental mode |
| 2025-01-31 01:10:04 +0100 | <dminuoso> | euouae: Fair enough. |
| 2025-01-31 01:10:25 +0100 | <euouae> | obviously it's both tiresome to manually typecheck everything when reading code & provides no intuition. the megaparsec code I saw earlier with a bunch of >>= inside a do was clear in what it was doing: it was combining a bunch of parser combinators, starting from some initial string-to-be-parsed, and outputted either a parsed data structure or parser error |
| 2025-01-31 01:10:34 +0100 | <dminuoso> | The mental model I have settled on over the years is that `Monads` model sequencing. |
| 2025-01-31 01:10:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 01:10:43 +0100 | <euouae> | and it sort of occurred to me that a lot of uses of do/>>= are doing basically stuff like that |
| 2025-01-31 01:11:39 +0100 | <dminuoso> | Though Im a flexible, and I have some alternate intuitions that I can switch to depending on the problem. |
| 2025-01-31 01:12:02 +0100 | <euouae> | well sure, adopting just one is good enough for me. I'll adopt more if the need arises |
| 2025-01-31 01:12:10 +0100 | down200 | (~down200@shell.lug.mtu.edu) (Ping timeout: 244 seconds) |
| 2025-01-31 01:12:50 +0100 | <dminuoso> | euouae: [] seems to breaks a state machine viewpoint. |
| 2025-01-31 01:13:12 +0100 | <dminuoso> | The monad instance of [] roughly models non-determinism (with a bit of squinting) |
| 2025-01-31 01:13:19 +0100 | <euouae> | if you can elaborate? |
| 2025-01-31 01:13:27 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 01:14:31 +0100 | <dminuoso> | (I say squinting because lists are not sets and have a bit more structure) |
| 2025-01-31 01:15:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 01:15:24 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-31 01:15:24 +0100 | monochrm | monochrom |
| 2025-01-31 01:15:52 +0100 | <geekosaur> | so, the list monad models a computation that gives you all possible solutions, whereas a Maybe version of the same computation gives you at most one solution (and can be thought of as "first solution, if any") |
| 2025-01-31 01:17:35 +0100 | down200 | (~down200@shell.lug.mtu.edu) down200 |
| 2025-01-31 01:18:11 +0100 | <dminuoso> | euouae: Say if we imagine a chess computer, we could think of [move1, move2, move3, move4] as not a collection of possibilities, but rather some non-deterministic choice of *one* move. |
| 2025-01-31 01:18:24 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
| 2025-01-31 01:18:34 +0100 | <dminuoso> | And >>= lets you take a further non-determistic choice |
| 2025-01-31 01:19:09 +0100 | <euouae> | Here's how lists are state machines: No input variable, only state; its output is the state. They compose funkily, but still. |
| 2025-01-31 01:19:23 +0100 | <geekosaur> | as dminuoso said, it's acting as a "poor man's set" (for technical reasons we can't actually make a Set a Monad); all the answers are equally ranked, their position in the list isn't relevant |
| 2025-01-31 01:19:52 +0100 | <dminuoso> | euouae: But its that *funkily* behavior that is the core essence of that instance. |
| 2025-01-31 01:20:02 +0100 | <euouae> | It is no less a state machine however |
| 2025-01-31 01:20:08 +0100 | <euouae> | a composable state machine, as I said above |
| 2025-01-31 01:20:41 +0100 | <euouae> | anyway, it's been said that everything can be considered a state machine, it's just a mental mode I have... I'm just glad I put it to some test and it didn't immediately collapse |
| 2025-01-31 01:20:44 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-31 01:21:37 +0100 | <dminuoso> | I mean if you insist on that state machine model, perhaps you could think of it as a non-deterministic state machine (along the lines of an NFA) |
| 2025-01-31 01:22:08 +0100 | <dminuoso> | Im not sure about the exact mental gymnastics required to see the state machine, but thats probably because Im flexed very differently |
| 2025-01-31 01:23:01 +0100 | geekosaur | wonders if it's the same viewpoint used with the comonad |
| 2025-01-31 01:23:07 +0100 | <dminuoso> | euouae: So here's why your state machine logic does not quite work out: |
| 2025-01-31 01:23:18 +0100 | <euouae> | As long as I can squeeze real-world results from my intuition I'm not too bothered by its rough edges |
| 2025-01-31 01:23:24 +0100 | <dminuoso> | euouae: `do x <- [1,2,3]; ...` -> how do you obtain the state? |
| 2025-01-31 01:24:01 +0100 | <dminuoso> | The non-determinism approach has the benefit of accurately modelling non-deterministic algorithms. |
| 2025-01-31 01:24:57 +0100 | <dminuoso> | In the above example, `x` represents some non-deterministic choice of [1,2,3] |
| 2025-01-31 01:25:01 +0100 | <euouae> | In `do x <- [1,2,3];` you're getting a slice of that funky composability |
| 2025-01-31 01:25:24 +0100 | <dminuoso> | euouae: But Im asking about where that state machine is. What's the state here? |
| 2025-01-31 01:25:38 +0100 | <euouae> | now x <- [1,1,1] does not have enough information for you to distinguish one 1 from another 1, even though they're positionally different |
| 2025-01-31 01:26:01 +0100 | <euouae> | I think I imagine state different from State or whatever |
| 2025-01-31 01:26:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 01:26:11 +0100 | <euouae> | The state is [1,2,3] |
| 2025-01-31 01:26:41 +0100 | <dminuoso> | euouae: Thats only true in the sense that the program has to store [1,2,3], but that could be said about *any* computation of anything. |
| 2025-01-31 01:27:03 +0100 | <dminuoso> | euouae: If we want to derive meaning of Monad, we must constrain to its interface |
| 2025-01-31 01:27:05 +0100 | <dminuoso> | % :t pure |
| 2025-01-31 01:27:06 +0100 | <yahb2> | pure :: Applicative f => a -> f a |
| 2025-01-31 01:27:11 +0100 | <dminuoso> | % :t (>>=) |
| 2025-01-31 01:27:11 +0100 | <yahb2> | (>>=) :: Monad m => m a -> (a -> m b) -> m b |
| 2025-01-31 01:27:36 +0100 | <dminuoso> | If you cannot put your "state" into relationship with that interface, your intuition has nothing to do with Monad, but with something else. |
| 2025-01-31 01:27:56 +0100 | <dminuoso> | These two functions, *together with some laws* are what Monad is. Nothing more, nothing less. |
| 2025-01-31 01:28:08 +0100 | <euouae> | Like I said, it's matching some usual applications of Monad like the parser combinators |
| 2025-01-31 01:28:25 +0100 | <euouae> | You want to content that it's not matching List. I agree, but at the same time, I am not too afraid to stretch my imagination and pretend it does |
| 2025-01-31 01:28:40 +0100 | <euouae> | As long as I can get somewhere with megaparsec :P |
| 2025-01-31 01:28:49 +0100 | <euouae> | anyway sorry for wasting your time... just thoughts |
| 2025-01-31 01:28:50 +0100 | <dminuoso> | euouae: Your intuitoin is absolutely great for megaparsec. |
| 2025-01-31 01:29:10 +0100 | <dminuoso> | But its not a good general intuition, it just does not work for list. |
| 2025-01-31 01:30:37 +0100 | <dminuoso> | euouae: In fact, megaparsec under the hood could be thought of StateT and ExceptT wired together - thats state looks so fitting, because it *does* use a state monad internally. |
| 2025-01-31 01:30:59 +0100 | <euouae> | What is the role of T in StateT? I haven't quite grasped that |
| 2025-01-31 01:31:02 +0100 | <dminuoso> | (Internally it uses a different representation for performance reasons, miond you) |
| 2025-01-31 01:31:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-01-31 01:31:12 +0100 | <euouae> | I haven't seen any examples either. I know a monad goes there, but State has it to be Identity |
| 2025-01-31 01:31:25 +0100 | <hololeap> | it stands for "transformer" |
| 2025-01-31 01:33:18 +0100 | <dminuoso> | euouae: And perhaps, for IO the state notion is not too shabby either as a first try by the way, if we think of the "real world" being the state. This is an intuition I can easily prove wrong, but I think I would rob you of some valuable learning process as monochrom as pointed out earlier. |
| 2025-01-31 01:33:43 +0100 | <dminuoso> | Given that you could just `launchMissiles` and change the state of the real world with IO. |
| 2025-01-31 01:34:33 +0100 | <hololeap> | I can't remember how to do 'unmtl' in #haskell |
| 2025-01-31 01:34:34 +0100 | <euouae> | I'm not sure what you mean by proving it wrong |
| 2025-01-31 01:34:55 +0100 | <euouae> | Is IO not a state |
| 2025-01-31 01:35:03 +0100 | <dminuoso> | euouae: There's a bunch of things you can do in IO that... isnt quite about changing the real world. |
| 2025-01-31 01:35:22 +0100 | <dminuoso> | Or you would need to do some more gymnastics. |
| 2025-01-31 01:35:25 +0100 | <hololeap> | IO being (State RealWorld a) is more of a mental model |
| 2025-01-31 01:35:44 +0100 | <dminuoso> | euouae: I dont want discredit this particular intuition, because I think it *is* a good starting point |
| 2025-01-31 01:36:12 +0100 | <dminuoso> | Just like we teach newtonian physics in school, despite general relativity being more accurate. |
| 2025-01-31 01:37:03 +0100 | <dminuoso> | euouae: Anyhow. Do try to build the state intuition around `>>=` and `pure` - and then test it in the future. |
| 2025-01-31 01:37:19 +0100 | <euouae> | yup. thank you |
| 2025-01-31 01:37:24 +0100 | <euouae> | but what is transformer? |
| 2025-01-31 01:37:49 +0100 | <dminuoso> | euouae: If we think of Monads not as "state" but as some generalized idea of effects, then transformers lets us combine different effects. |
| 2025-01-31 01:37:53 +0100 | <euouae> | With a State I know I have a 'state processor' and an 'output value' but what is the transformer for? |
| 2025-01-31 01:37:55 +0100 | <dminuoso> | THat may or may not make any sense to you. |
| 2025-01-31 01:38:20 +0100 | <dminuoso> | euouae: StateT allows you to drag some state around, while ExceptT allows you to throw exceptions. |
| 2025-01-31 01:38:33 +0100 | <geekosaur> | so, StateT doesn't just model state; it adds state to something. It transforms something else by adding state to it |
| 2025-01-31 01:38:35 +0100 | <dminuoso> | Them being transformers means you can layer them ontop of each other, giving you a Monad that has both state *and* exceptions. |
| 2025-01-31 01:39:00 +0100 | <dminuoso> | And if you add ListT (which adds non-determinism), you could have non-determinism, state and exceptions |
| 2025-01-31 01:39:17 +0100 | <dminuoso> | ANd you can layer it over IO to have state, non-determinism, exceptions and real world nuclear missile effects. |
| 2025-01-31 01:40:04 +0100 | <dminuoso> | euouae: Lets pick a more concrete examplee: |
| 2025-01-31 01:40:29 +0100 | <dminuoso> | euouae: Your megaparsec parser can run either in pure mode, or it can run together with IO. |
| 2025-01-31 01:40:55 +0100 | <dminuoso> | If you use it together with IO, you can interleave your parser with IO - say print statements or database calls |
| 2025-01-31 01:41:14 +0100 | <dminuoso> | The reason you can do this, is because all this parsing effect is in a transformer ParsecT which you can layer over any other monad. |
| 2025-01-31 01:41:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 01:41:46 +0100 | <dminuoso> | If you dont want IO, you can just layer it over `Identity`, which is sort of the "does nothing monad", giving you just the parsing effects. |
| 2025-01-31 01:42:06 +0100 | <dminuoso> | https://hackage.haskell.org/package/megaparsec-9.7.0/docs/Text-Megaparsec.html#t:Parsec |
| 2025-01-31 01:42:13 +0100 | <dminuoso> | type Parsec e s = ParsecT e s Identity |
| 2025-01-31 01:43:15 +0100 | <dminuoso> | You can also use `ParsecT e s IO`, then you can suddenly do `liftIO (putStrLn "Hello world")` in the middle of your parser. Note, that because megaparsec will do backtracking this will have some interesting/strange behavior... which is non-determinism in fact. |
| 2025-01-31 01:43:29 +0100 | <dminuoso> | (Assuming you use `try` of course) |
| 2025-01-31 01:44:15 +0100 | <euouae> | right |
| 2025-01-31 01:44:32 +0100 | <euouae> | I'm going to assume that it'll leak out the details of try |
| 2025-01-31 01:45:16 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 01:45:40 +0100 | <euouae> | I think my composable state machine intuition is running into trouble with StateT. Transformers seem like a different beast, I'll have to think about it more. |
| 2025-01-31 01:45:55 +0100 | <euouae> | But your example is very helpful, to keep in mind pure computation / IO stuff inside parsing |
| 2025-01-31 01:46:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 01:46:29 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-31 01:46:30 +0100 | monochrm | monochrom |
| 2025-01-31 01:48:52 +0100 | mange | (~user@user/mange) mange |
| 2025-01-31 01:48:53 +0100 | <dminuoso> | euouae: One last thing: That "funky composition" you talked about, that's where the monad lies. :-) |
| 2025-01-31 01:49:18 +0100 | <dminuoso> | Just keep that thought mind for the future |
| 2025-01-31 01:49:55 +0100 | <dminuoso> | % :t join |
| 2025-01-31 01:49:55 +0100 | <yahb2> | <interactive>:1:1: error: [GHC-88464] Variable not in scope: join |
| 2025-01-31 01:50:01 +0100 | <dminuoso> | % import Control.Monad |
| 2025-01-31 01:50:01 +0100 | <yahb2> | <no output> |
| 2025-01-31 01:50:03 +0100 | <dminuoso> | % :t join |
| 2025-01-31 01:50:03 +0100 | <yahb2> | join :: Monad m => m (m a) -> m a |
| 2025-01-31 01:50:58 +0100 | <dminuoso> | euouae: This is an alternate description of (>>=), and it perhaps visualizes nicely that there's a sort of composition idea going on. |
| 2025-01-31 01:51:10 +0100 | <dminuoso> | Anyway. This was just meant as a teaser. |
| 2025-01-31 01:51:47 +0100 | rstromlund | (~user@user/rstromlund) rstromlund |
| 2025-01-31 01:52:28 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 01:52:40 +0100 | <int-e> | @djinn ((((a -> r) -> r) -> r) -> r) -> (a -> r) -> r |
| 2025-01-31 01:52:41 +0100 | <lambdabot> | f a b = a (\ c -> c b) |
| 2025-01-31 01:53:06 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f4679216c0ad7f4b91d.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-01-31 01:54:15 +0100 | xff0x | (~xff0x@2405:6580:b080:900:704:c9bd:a645:9b1d) (Ping timeout: 276 seconds) |
| 2025-01-31 01:56:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-01-31 01:56:40 +0100 | rstromlund | (~user@user/rstromlund) (Ping timeout: 265 seconds) |
| 2025-01-31 01:56:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 02:01:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-01-31 02:02:24 +0100 | joeyadams | (~joeyadams@syn-184-054-105-097.res.spectrum.com) (Quit: Leaving) |
| 2025-01-31 02:03:12 +0100 | <hololeap> | @unmtl StateT Int IO String |
| 2025-01-31 02:03:12 +0100 | <lambdabot> | Int -> IO (String, Int) |
| 2025-01-31 02:03:18 +0100 | <hololeap> | nice, there we go |
| 2025-01-31 02:12:12 +0100 | sprotte24 | (~sprotte24@p200300d16f0f520069bfd2b9cee1df34.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-31 02:12:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 02:16:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-01-31 02:18:49 +0100 | rstromlund | (~user@user/rstromlund) rstromlund |
| 2025-01-31 02:20:44 +0100 | otto_s | (~user@p5b0441ee.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-01-31 02:22:30 +0100 | otto_s | (~user@p5de2fd05.dip0.t-ipconnect.de) |
| 2025-01-31 02:24:26 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 02:25:58 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 252 seconds) |
| 2025-01-31 02:25:58 +0100 | monochrm | monochrom |
| 2025-01-31 02:26:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-01-31 02:27:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 02:32:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 02:34:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 02:37:55 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-01-31 02:38:26 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-31 02:38:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-01-31 02:38:58 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2025-01-31 02:39:26 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-31 02:41:13 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 02:44:56 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-31 02:45:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-01-31 02:49:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 02:51:25 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-01-31 02:54:28 +0100 | Square | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2025-01-31 02:54:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 03:04:16 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-31 03:05:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 03:06:03 +0100 | mikess | (~mikess@user/mikess) mikess |
| 2025-01-31 03:09:17 +0100 | <euouae> | why is `State s a` but `state :: a -> (a, s)`? the order is reversed |
| 2025-01-31 03:09:41 +0100 | <euouae> | sorry, I mean, state :: Monad m => (s -> (a, s)) -> StateT s m a |
| 2025-01-31 03:12:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 03:16:04 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-01-31 03:23:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 03:25:04 +0100 | mikess | (~mikess@user/mikess) (Ping timeout: 272 seconds) |
| 2025-01-31 03:26:30 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-31 03:29:10 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-31 03:29:36 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 03:31:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-01-31 03:33:37 +0100 | Tikosh | (~quassel@user/Tikosh) Tikosh |
| 2025-01-31 03:34:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 03:35:43 +0100 | <Tikosh> | https://www.youtube.com/watch?v=Qu0wtz6Z5RY |
| 2025-01-31 03:35:50 +0100 | <Tikosh> | oh sorry |
| 2025-01-31 03:35:56 +0100 | <Tikosh> | i thought this was gentoo-chat |
| 2025-01-31 03:36:00 +0100 | <Tikosh> | excuse me |
| 2025-01-31 03:43:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 03:46:01 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 03:47:28 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 245 seconds) |
| 2025-01-31 03:47:29 +0100 | monochrm | monochrom |
| 2025-01-31 03:47:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 03:55:24 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-31 03:55:54 +0100 | sarna | (~sarna@d224-221.icpnet.pl) (Ping timeout: 252 seconds) |
| 2025-01-31 03:56:32 +0100 | rstromlund | (~user@user/rstromlund) (Ping timeout: 252 seconds) |
| 2025-01-31 03:58:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 04:02:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-01-31 04:04:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-31 04:04:44 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 04:07:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 04:12:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 04:12:55 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 04:13:24 +0100 | sarna | (~sarna@d224-221.icpnet.pl) sarna |
| 2025-01-31 04:14:03 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 252 seconds) |
| 2025-01-31 04:14:04 +0100 | monochrm | monochrom |
| 2025-01-31 04:17:11 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-31 04:18:21 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 04:22:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-01-31 04:22:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 04:25:04 +0100 | <monochrom> | hololeap: @unmtl StateT s (ContT r IO) a |
| 2025-01-31 04:25:10 +0100 | <monochrom> | @unmtl StateT s (ContT r IO) a |
| 2025-01-31 04:25:10 +0100 | <lambdabot> | s -> (a -> s -> IO r) -> IO r |
| 2025-01-31 04:27:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 04:30:44 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 04:30:49 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-31 04:30:55 +0100 | monochrm | monochrom |
| 2025-01-31 04:31:25 +0100 | <monochrom> | The connection between the [] monad and state machines is at best this little: from the [] monad get the corresponding Kleisli arrow, then that would be nondeterministic state transition functions, i.e., of the form S -> [S]. |
| 2025-01-31 04:32:34 +0100 | <monochrom> | But that is as quaint as saying: endofunctions S -> S "Is" deterministic state machines just because deterministic state transition functions are of the form S->S. Clearly, in both cases, you are still missing out on: Who is the initial state? Who are accept states? |
| 2025-01-31 04:33:07 +0100 | <monochrom> | I cannot accept (pun!) the confused conflation between state transition functions and state machines. |
| 2025-01-31 04:34:50 +0100 | <monochrom> | It's like saying that Int is (Int, Char) because Int is one field of (Int, Char). |
| 2025-01-31 04:38:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 04:43:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 04:44:33 +0100 | td_ | (~td@i53870904.versanet.de) (Ping timeout: 252 seconds) |
| 2025-01-31 04:46:23 +0100 | td_ | (~td@i5387092E.versanet.de) td_ |
| 2025-01-31 04:55:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 05:00:42 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 272 seconds) |
| 2025-01-31 05:01:44 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 05:01:50 +0100 | <euouae> | so if you talk about state transition functions do you accept that monads are just composable state transition functions? |
| 2025-01-31 05:01:57 +0100 | <euouae> | and i.e. it applies to lists? |
| 2025-01-31 05:02:11 +0100 | <euouae> | as far as I can tell when you speak of the kleisli arrow you're just talking about lists of lists etc |
| 2025-01-31 05:03:38 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 252 seconds) |
| 2025-01-31 05:03:38 +0100 | monochrm | monochrom |
| 2025-01-31 05:05:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-01-31 05:05:17 +0100 | <monochrom> | S->[S] is not list of list. |
| 2025-01-31 05:06:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 05:06:47 +0100 | <euouae> | sure, [S]->[[S]] etc |
| 2025-01-31 05:06:58 +0100 | <monochrom> | And I don't see in what sense A -> Cont R A is state transition function. |
| 2025-01-31 05:07:28 +0100 | <euouae> | I'm not sure I follow but it's ok don't worry. I'm just doing some easy challenges on leetcode to get a grip on Haskell |
| 2025-01-31 05:07:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-31 05:11:04 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 05:15:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 05:20:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 05:25:40 +0100 | aforemny | (~aforemny@i577B135A.versanet.de) aforemny |
| 2025-01-31 05:26:14 +0100 | aforemny_ | (~aforemny@2001:9e8:6ce3:9600:2c48:7088:cbda:dd4) (Ping timeout: 260 seconds) |
| 2025-01-31 05:30:17 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-01-31 05:30:33 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-31 05:31:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 05:34:55 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-01-31 05:35:50 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-31 05:35:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 05:43:01 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 248 seconds) |
| 2025-01-31 05:43:08 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-01-31 05:46:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 05:48:55 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 05:50:36 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 265 seconds) |
| 2025-01-31 05:50:37 +0100 | monochrm | monochrom |
| 2025-01-31 05:51:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-01-31 05:51:15 +0100 | michalz | (~michalz@185.246.207.221) |
| 2025-01-31 05:53:07 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-31 05:55:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 05:55:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 05:59:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-01-31 06:00:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-01-31 06:02:27 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-01-31 06:04:05 +0100 | tabaqui1 | (~root@87.200.129.102) (Ping timeout: 244 seconds) |
| 2025-01-31 06:06:14 +0100 | Digit | (~user@user/digit) (Killed (copper.libera.chat (Nickname regained by services))) |
| 2025-01-31 06:06:14 +0100 | Digitteknohippie | Digit |
| 2025-01-31 06:06:56 +0100 | Guest8048 | (~user@250.88.90.146.dyn.plus.net) |
| 2025-01-31 06:07:41 +0100 | Guest8048 | (~user@250.88.90.146.dyn.plus.net) (Remote host closed the connection) |
| 2025-01-31 06:08:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 06:13:42 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-31 06:13:59 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-31 06:14:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-01-31 06:23:33 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-31 06:26:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 06:27:20 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-31 06:31:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-01-31 06:33:16 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-31 06:37:22 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-01-31 06:41:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 06:43:45 +0100 | Tikosh | (~quassel@user/Tikosh) (Remote host closed the connection) |
| 2025-01-31 06:43:49 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 06:44:13 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 06:44:44 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 265 seconds) |
| 2025-01-31 06:44:45 +0100 | monochrm | monochrom |
| 2025-01-31 06:44:48 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::64a2) |
| 2025-01-31 06:46:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 06:48:29 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 06:54:59 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-31 06:55:23 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-31 06:55:29 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
| 2025-01-31 06:55:29 +0100 | tnt2 | tnt1 |
| 2025-01-31 06:55:55 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-31 06:57:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 07:01:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 07:03:22 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 07:03:32 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-01-31 07:04:50 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2025-01-31 07:04:50 +0100 | monochrm | monochrom |
| 2025-01-31 07:09:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 07:13:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-01-31 07:15:48 +0100 | ft | (~ft@p3e9bcd97.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-01-31 07:24:06 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-31 07:24:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 07:24:48 +0100 | Square | (~Square@user/square) Square |
| 2025-01-31 07:26:18 +0100 | alp | (~alp@2001:861:8ca0:4940:465c:30a2:2211:b30f) (Remote host closed the connection) |
| 2025-01-31 07:26:35 +0100 | alp | (~alp@2001:861:8ca0:4940:465c:30a2:2211:b30f) |
| 2025-01-31 07:28:54 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-01-31 07:29:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-01-31 07:32:37 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 07:33:09 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-01-31 07:33:23 +0100 | euleritian | (~euleritia@dynamic-176-006-140-003.176.6.pool.telefonica.de) |
| 2025-01-31 07:36:53 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-31 07:36:58 +0100 | CiaoSen | (~Jura@2a05:5800:263:8800:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-31 07:38:45 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 248 seconds) |
| 2025-01-31 07:40:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 07:42:24 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2025-01-31 07:42:25 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-01-31 07:45:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 07:47:37 +0100 | <euouae> | heh, cool. I didn't expect to use the State monad so soon after I learned about it but the leetcode problem needed a list of primes |
| 2025-01-31 07:47:44 +0100 | <euouae> | and I implemented eratosthenes sieve: <https://paste.tomsmeding.com/vm6F8jXA> |
| 2025-01-31 07:48:19 +0100 | <euouae> | I'm happy with how this turned out, looks very natural |
| 2025-01-31 07:48:36 +0100 | <euouae> | I couldn't figure out if it could be done with list comprehension |
| 2025-01-31 07:52:03 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 07:54:35 +0100 | <ski> | cycle [x] = repeat x |
| 2025-01-31 07:54:59 +0100 | <ski> | you could just pass on the filtered list in an accumulator parameter of a recursive function |
| 2025-01-31 07:55:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 08:01:09 +0100 | AlexNoo_ | (~AlexNoo@5.139.233.186) |
| 2025-01-31 08:02:00 +0100 | AlexZenon | (~alzenon@178.34.150.8) (Ping timeout: 246 seconds) |
| 2025-01-31 08:02:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-01-31 08:03:19 +0100 | AlexNoo | (~AlexNoo@178.34.150.8) (Ping timeout: 260 seconds) |
| 2025-01-31 08:05:23 +0100 | <euouae> | that's true, but then how do you produce the infinite list? like (x : f rest)? |
| 2025-01-31 08:06:03 +0100 | AlexZenon | (~alzenon@5.139.233.186) |
| 2025-01-31 08:07:58 +0100 | <dminuoso> | euouae │ why is `State s a` but `state :: a -> (a, s)`? the order is reversed |
| 2025-01-31 08:08:05 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 08:08:29 +0100 | <dminuoso> | The type order is often influenced by typeclasses you want to satisfy. |
| 2025-01-31 08:08:47 +0100 | <euouae> | right, for State. but why state? |
| 2025-01-31 08:09:23 +0100 | <dminuoso> | So consider `instance Functor (State s)`, we cannot write `instance Functor (State _ a)`, so we reorder the types accordingly. |
| 2025-01-31 08:09:40 +0100 | <dminuoso> | Sorry, that second one should have read `instance Functor (State _ s)` |
| 2025-01-31 08:10:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 08:10:20 +0100 | <dminuoso> | euouae: So the order of arguments usually follows convenience with related functions. |
| 2025-01-31 08:10:27 +0100 | <dminuoso> | And that can be quite subjective |
| 2025-01-31 08:10:54 +0100 | <dminuoso> | Say you envision `state` to be used with `fmap` to map over the *state*, because that's how you (the author) like to use it, and assume others to frequently use it too. |
| 2025-01-31 08:12:24 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 08:12:31 +0100 | <dminuoso> | Since fmap on a 2-tuple maps over the second argument (which too has to do with the fact that we cant just have `instance Functor (a,)` but are forced to have `instance Functor (a,)` if we were allowed to write sections in type (we have to specify write it as `instance Functor ((,) a) in reality) |
| 2025-01-31 08:13:22 +0100 | <euouae> | I'm actually not sure what fmap with state does, I'd have to think about it |
| 2025-01-31 08:13:29 +0100 | <euouae> | but OK if fmap is one of the reasons then I can see it |
| 2025-01-31 08:13:48 +0100 | <dminuoso> | Im not sure whether that was actually the reason, keep that in mind. |
| 2025-01-31 08:14:20 +0100 | <dminuoso> | euouae: One other fact that often influence parameter order, is which parameters you expect to be partially applied. |
| 2025-01-31 08:15:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-01-31 08:15:33 +0100 | <dminuoso> | Say if you have `f :: S -> T -> A -> X`, and for some reason its likely you or other users will use it as `x (f s t)`, this is far more comfortable than writing `x (\a -> f a s t)`, so you turn things around to enable more point-free notation |
| 2025-01-31 08:15:41 +0100 | <glguy> | The order is forced because it is intended to be a Monad |
| 2025-01-31 08:15:54 +0100 | <dminuoso> | glguy: They meant why `state :: a -> (a, s)` in particular. |
| 2025-01-31 08:16:10 +0100 | anpad | (~pandeyan@user/anpad) (Client Quit) |
| 2025-01-31 08:16:45 +0100 | <glguy> | The tuple order? There's no reason one way or the other and you can find implementations using both |
| 2025-01-31 08:17:09 +0100 | <dminuoso> | Yeah. I guess no reason is also possible. |
| 2025-01-31 08:17:10 +0100 | <ski> | euouae : "like (x : f rest)?" -- yes |
| 2025-01-31 08:18:43 +0100 | <dminuoso> | glguy: In my experience the tuple order is usually picked based on how the author use fmap or sections with those tuples. |
| 2025-01-31 08:18:53 +0100 | <dminuoso> | Which can be very subjective, still. |
| 2025-01-31 08:20:01 +0100 | <euouae> | ski, isn't that less efficient? |
| 2025-01-31 08:20:08 +0100 | <ski> | than what ? |
| 2025-01-31 08:20:57 +0100 | <euouae> | than what I have, doesn't it get into N levels of stack frames? |
| 2025-01-31 08:21:17 +0100 | <ski> | dunno what you mean |
| 2025-01-31 08:21:21 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 08:21:55 +0100 | <ski> | but doing `f ... = x : f (...)' is in general not inherently inefficient |
| 2025-01-31 08:22:03 +0100 | <dminuoso> | In Haskell, anyway. |
| 2025-01-31 08:22:14 +0100 | <dminuoso> | Or GHC Haskell, one should say. |
| 2025-01-31 08:22:18 +0100 | <euouae> | I don't know how evaluation works in Haskell well enough to understand that, but (x : f rest) is not tail-called, right? It must have O(n) memory for n steps |
| 2025-01-31 08:22:34 +0100 | <euouae> | on top of the O(n) for the list itself, so arguably doesn't matter |
| 2025-01-31 08:22:34 +0100 | <ski> | it'll produce the result `x', and then, if you decide to ask for more elements, only then will the recursive call computation happen |
| 2025-01-31 08:22:54 +0100 | <dminuoso> | euouae: In GHC Haskell, evaluation model works vastly different from traditional programming languages. We dont exactly push to a stack at the beginning of a function and pop at the end. |
| 2025-01-31 08:22:55 +0100 | <ski> | it's incremental, rather than tail-calling |
| 2025-01-31 08:23:21 +0100 | <euouae> | dminuoso: is there hope to understand it for non experts or is it too difficult? |
| 2025-01-31 08:23:39 +0100 | <ski> | think of the list generated as an iterator, if you like |
| 2025-01-31 08:23:58 +0100 | <ski> | the caller controls how much of it is materialized |
| 2025-01-31 08:24:03 +0100 | <euouae> | Oh I understand that much (i.e. what you explained here ski), but in general to understand the Haskell evaluation |
| 2025-01-31 08:24:13 +0100 | <euouae> | i.e. what happens under the hood via ghc |
| 2025-01-31 08:24:32 +0100 | <dminuoso> | euouae: Imagine the program was kept *textually* as you wrote it, and evaluation is just substitution. |
| 2025-01-31 08:24:42 +0100 | <ski> | GHC does lazy evaulation, meaning demand-driven, with caching of intermediate results |
| 2025-01-31 08:25:00 +0100 | <euouae> | What does caching mean? |
| 2025-01-31 08:25:31 +0100 | <euouae> | Why would it remember intermediate results? for what purpose? |
| 2025-01-31 08:25:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 08:25:42 +0100 | <dminuoso> | Consider `let x = <expensive computation> in (x, x)` |
| 2025-01-31 08:25:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 08:26:07 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 08:26:09 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-31 08:26:21 +0100 | <euouae> | okay right. hm... |
| 2025-01-31 08:26:24 +0100 | monochrm | monochrom |
| 2025-01-31 08:26:48 +0100 | <ski> | it means that in `let x = 2 * 2 in x + x', first the `x + x' starts to happen, then that demands the result of `x', so `2 * 2' happens, result `4'. now it *remembers* (caches) that `x' resulted in `4', so that when the second `x' in `x + x' is checked, it reuses the `4', to compute `4 + 4', rather than performing the multiplication twice |
| 2025-01-31 08:27:05 +0100 | <euouae> | so about laziness, how exactly is it accomplished in ghc? |
| 2025-01-31 08:27:21 +0100 | <euouae> | does it keep track of the source code instead of computing it? and just computes when necessary? |
| 2025-01-31 08:27:22 +0100 | <ski> | same thing happens, if you define `f x = x + x', and then call `f (2 * 2)' |
| 2025-01-31 08:27:44 +0100 | <ski> | "does it keep track of the source code" -- no |
| 2025-01-31 08:27:51 +0100 | <dminuoso> | euouae: No, we encode the whole program into what we call a spineless tagless G-machine |
| 2025-01-31 08:27:58 +0100 | <dminuoso> | Which is a very efficient way of programming to native code. |
| 2025-01-31 08:28:04 +0100 | <dminuoso> | s/programming/translating/ |
| 2025-01-31 08:28:18 +0100 | <dminuoso> | euouae: Semantically you can imagine it kept the source code and just substituted. |
| 2025-01-31 08:28:36 +0100 | <dminuoso> | With sharing whenever possible |
| 2025-01-31 08:28:41 +0100 | <euouae> | <https://www.microsoft.com/en-us/research/wp-content/uploads/1992/04/spineless-tagless-gmachine.pdf> is a good intro to that? |
| 2025-01-31 08:28:43 +0100 | <euouae> | I'm kind of curious |
| 2025-01-31 08:28:45 +0100 | <dminuoso> | (Well not quite *whenever* ...) |
| 2025-01-31 08:29:22 +0100 | <dminuoso> | euouae: Give it a try, and see how far you go. If your mind explodes, put the paper aside for a future read. |
| 2025-01-31 08:29:33 +0100 | <ski> | @where lazy |
| 2025-01-31 08:29:33 +0100 | <lambdabot> | "Lazy Evaluation of Haskell" by monochrom at <http://www.vex.net/~trebla/haskell/lazy.xhtml>; "The Incomplete Guide to Lazy Evaluation (in Haskell)" by apfelmus in 2015-03-07 at <https://apfelmus. |
| 2025-01-31 08:29:33 +0100 | <lambdabot> | nfshost.com/articles/lazy-eval.html>; "Laziness, strictness, guarded recursion" by bitemyapp at <https://github.com/bitemyapp/learnhaskell/blob/master/specific_topics.md#user-content-laziness- |
| 2025-01-31 08:29:33 +0100 | <lambdabot> | strictness-guarded-recursion> |
| 2025-01-31 08:29:39 +0100 | <ski> | check that first |
| 2025-01-31 08:29:47 +0100 | <euouae> | firstlink or all? |
| 2025-01-31 08:30:04 +0100 | <ski> | first link |
| 2025-01-31 08:30:26 +0100 | <euouae> | Alright, thank you. I've got some cool stuff for the days ahead. |
| 2025-01-31 08:30:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 08:31:23 +0100 | <dminuoso> | euouae: Ultimately we can achieve very good performance with our approach, sometimes comparable to C++ or Rust with careful programming (though to be honest even those languages require careful treatment to obtain optimal performance). STG is *that* good. |
| 2025-01-31 08:33:12 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 08:33:25 +0100 | <dminuoso> | (Though GHC has a lot of other tricks up its sleeve to make that possible, so its not just STG) |
| 2025-01-31 08:35:15 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2025-01-31 08:35:15 +0100 | monochrm | monochrom |
| 2025-01-31 08:37:44 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-31 08:40:00 +0100 | <euouae> | neat, it's probably beyond what I can grasp but it's probably still worth looking into |
| 2025-01-31 08:41:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 08:46:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-01-31 08:49:36 +0100 | euouae | (~euouae@user/euouae) () |
| 2025-01-31 08:51:27 +0100 | <dminuoso> | % fromIntegral (0xffffff :: Word16) :: Word8 |
| 2025-01-31 08:51:27 +0100 | <yahb2> | <interactive>:97:15: warning: [GHC-97441] [-Woverflowed-literals] ; Literal 16777215 is out of the Word16 range 0..65535 ; ; 255 |
| 2025-01-31 08:51:52 +0100 | Square | (~Square@user/square) (Ping timeout: 272 seconds) |
| 2025-01-31 08:52:03 +0100 | <dminuoso> | I'm staring at some Haskell code that explicitly masks with 0xff before fromIntegral, is that strictly necessary or can I rely on truncation like this? |
| 2025-01-31 08:54:31 +0100 | falafel | (~falafel@syn-076-093-010-089.res.spectrum.com) falafel |
| 2025-01-31 08:56:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 08:58:51 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-31 08:59:02 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-31 08:59:02 +0100 | tnt2 | tnt1 |
| 2025-01-31 09:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-31 09:00:41 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-31 09:01:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-01-31 09:01:32 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-01-31 09:02:05 +0100 | euleritian | (~euleritia@dynamic-176-006-140-003.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-01-31 09:02:23 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-31 09:05:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-31 09:06:59 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-31 09:07:30 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-31 09:09:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 09:11:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 09:13:09 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 09:13:58 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2025-01-31 09:14:04 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-31 09:15:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-01-31 09:16:57 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-01-31 09:21:01 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 09:23:39 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2025-01-31 09:24:38 +0100 | user__ | (~user@user/fmira) (Remote host closed the connection) |
| 2025-01-31 09:25:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-01-31 09:25:37 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f830c2bc91cde612e63.dip0.t-ipconnect.de) acidjnk |
| 2025-01-31 09:27:08 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-31 09:29:36 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2025-01-31 09:30:48 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 09:30:58 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-31 09:32:40 +0100 | Googulator | (~Googulato@2a01-036d-0106-1666-e945-fd21-b920-9aa7.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-01-31 09:36:56 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard |
| 2025-01-31 09:39:50 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 09:47:41 +0100 | chele | (~chele@user/chele) chele |
| 2025-01-31 09:48:10 +0100 | nullie | (~nullie@nuremberg.nullie.name) (Read error: Connection reset by peer) |
| 2025-01-31 09:49:54 +0100 | falafel | (~falafel@syn-076-093-010-089.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-01-31 09:51:35 +0100 | nullie | (~nullie@nuremberg.nullie.name) nullie |
| 2025-01-31 09:54:37 +0100 | danz55770 | (~danza@user/danza) danza |
| 2025-01-31 09:56:36 +0100 | danza | (~danza@user/danza) (Ping timeout: 252 seconds) |
| 2025-01-31 09:58:03 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 09:58:29 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 09:59:37 +0100 | danz55770 | (~danza@user/danza) (Remote host closed the connection) |
| 2025-01-31 09:59:52 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-31 09:59:55 +0100 | AlexNoo__ | (~AlexNoo@5.139.233.186) |
| 2025-01-31 10:00:11 +0100 | AlexZenon_2 | (~alzenon@5.139.233.186) |
| 2025-01-31 10:00:32 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 10:00:33 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-31 10:00:48 +0100 | monochrm | monochrom |
| 2025-01-31 10:01:42 +0100 | AlexZenon | (~alzenon@5.139.233.186) (Ping timeout: 246 seconds) |
| 2025-01-31 10:02:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-01-31 10:03:06 +0100 | AlexNoo_ | (~AlexNoo@5.139.233.186) (Ping timeout: 246 seconds) |
| 2025-01-31 10:06:07 +0100 | CiaoSen | (~Jura@2a05:5800:263:8800:ca4b:d6ff:fec1:99da) (Ping timeout: 252 seconds) |
| 2025-01-31 10:06:35 +0100 | <c_wraith> | depends on the type you're coming from, as it's going to depend on how fromInteger is implemented |
| 2025-01-31 10:07:12 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 10:07:55 +0100 | nullie | (~nullie@nuremberg.nullie.name) (Quit: WeeChat 4.2.2) |
| 2025-01-31 10:11:32 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 10:11:39 +0100 | anpad | (~pandeyan@user/anpad) (Remote host closed the connection) |
| 2025-01-31 10:12:32 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-31 10:17:05 +0100 | danza | (~danza@user/danza) () |
| 2025-01-31 10:19:52 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 10:20:20 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 10:20:44 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-31 10:20:59 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-31 10:21:00 +0100 | monochrm | monochrom |
| 2025-01-31 10:22:36 +0100 | anpad | (~pandeyan@user/anpad) (Client Quit) |
| 2025-01-31 10:24:40 +0100 | <c_wraith> | err. that's backwards. The type you're coming from provides the toInteger implementation, which should always be exact. fromInteger depends on the destination type. |
| 2025-01-31 10:29:58 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 10:30:08 +0100 | alecs | (~alecs@nat16.software.imdea.org) alecs |
| 2025-01-31 10:35:03 +0100 | fp1 | (~Thunderbi@wireless-86-50-140-50.open.aalto.fi) fp |
| 2025-01-31 10:36:05 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 10:39:41 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-01-31 10:40:06 +0100 | fp1 | (~Thunderbi@wireless-86-50-140-50.open.aalto.fi) (Ping timeout: 276 seconds) |
| 2025-01-31 10:40:22 +0100 | swamp_ | (~zmt00@user/zmt00) zmt00 |
| 2025-01-31 10:44:00 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 276 seconds) |
| 2025-01-31 10:44:50 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-31 10:46:53 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 10:47:03 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 245 seconds) |
| 2025-01-31 10:47:59 +0100 | <tomsmeding> | dminuoso: what are the source and destination types? :p |
| 2025-01-31 10:48:17 +0100 | <tomsmeding> | oh the destination type is Word8? then what c_wraith said |
| 2025-01-31 10:51:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-01-31 10:51:41 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-31 10:51:42 +0100 | alecs | (~alecs@nat16.software.imdea.org) (Ping timeout: 252 seconds) |
| 2025-01-31 10:57:06 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 10:59:38 +0100 | anpad | (~pandeyan@user/anpad) (Client Quit) |
| 2025-01-31 11:00:54 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) kritzefitz |
| 2025-01-31 11:03:22 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 11:07:36 +0100 | CiaoSen | (~Jura@2a05:5800:263:8800:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-31 11:24:05 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a8f9:39f9:ef80:a859) ubert |
| 2025-01-31 11:35:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 11:39:00 +0100 | anpad | (~pandeyan@user/anpad) (Ping timeout: 252 seconds) |
| 2025-01-31 11:40:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-01-31 11:41:52 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2025-01-31 11:43:03 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 11:46:59 +0100 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |