| 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) |
| 2025-01-31 11:47:22 +0100 | kmein | (~weechat@user/kmein) kmein |
| 2025-01-31 11:50:49 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-31 11:56:23 +0100 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |
| 2025-01-31 11:56:44 +0100 | kmein | (~weechat@user/kmein) kmein |
| 2025-01-31 12:00:15 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-01-31 12:01:09 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 260 seconds) |
| 2025-01-31 12:01:09 +0100 | monochrm | monochrom |
| 2025-01-31 12:03:20 +0100 | zmt01 | (~zmt00@user/zmt00) zmt00 |
| 2025-01-31 12:07:12 +0100 | swamp_ | (~zmt00@user/zmt00) (Ping timeout: 276 seconds) |
| 2025-01-31 12:08:53 +0100 | mange | (~user@user/mange) (Remote host closed the connection) |
| 2025-01-31 12:12:21 +0100 | tv | (~tv@user/tv) tv |
| 2025-01-31 12:18:46 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-31 12:21:10 +0100 | auri | (~auri@fsf/member/auri) (Quit: No Ping reply in 210 seconds.) |
| 2025-01-31 12:25:01 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 12:25:26 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-31 12:28:30 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2025-01-31 12:28:30 +0100 | ljdarj1 | ljdarj |
| 2025-01-31 12:29:03 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-01-31 12:37:33 +0100 | danza | (~danza@user/danza) (Ping timeout: 252 seconds) |
| 2025-01-31 12:37:33 +0100 | nckx | (nckx@libera/staff/owl/nckx) (Ping timeout: 608 seconds) |
| 2025-01-31 12:38:16 +0100 | ell | (~ellie@user/ellie) (Quit: Ping timeout (120 seconds)) |
| 2025-01-31 12:38:34 +0100 | ell | (~ellie@user/ellie) ellie |
| 2025-01-31 12:38:37 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-31 12:44:21 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2025-01-31 12:48:10 +0100 | troydm | (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset) |
| 2025-01-31 12:51:00 +0100 | Digit | (~user@user/digit) (Ping timeout: 244 seconds) |
| 2025-01-31 12:53:29 +0100 | JuanDaugherty | ColinRobinson |
| 2025-01-31 12:57:05 +0100 | AkechiShiro | (~licht@user/akechishiro) AkechiShiro |
| 2025-01-31 12:59:21 +0100 | Guest64 | (~Guest64@2600:387:f:7e17::1) |
| 2025-01-31 13:00:21 +0100 | Guest64 | (~Guest64@2600:387:f:7e17::1) (Client Quit) |
| 2025-01-31 13:00:28 +0100 | Guest94 | (~Guest64@2600:387:f:7e12::b) |
| 2025-01-31 13:04:12 +0100 | Guest94 | (~Guest64@2600:387:f:7e12::b) (Client Quit) |
| 2025-01-31 13:04:31 +0100 | Guest64 | (~Guest64@2600:387:f:7e12::b) |
| 2025-01-31 13:04:47 +0100 | jespada | (~jespada@2800:a4:2213:dd00:8c24:32fa:8fb8:ea12) jespada |
| 2025-01-31 13:05:22 +0100 | <kaol> | My favorite thing about ghci is :set -freverse-errors. |
| 2025-01-31 13:10:53 +0100 | Guest64 | (~Guest64@2600:387:f:7e12::b) (Quit: Client closed) |
| 2025-01-31 13:13:13 +0100 | <merijn> | kaol: That's one of my default GHC settings :p |
| 2025-01-31 13:13:44 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 13:15:16 +0100 | <haskellbridge> | <sm> interesting |
| 2025-01-31 13:15:32 +0100 | <haskellbridge> | <sm> why is it better ? |
| 2025-01-31 13:15:44 +0100 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-01-31 13:16:51 +0100 | <kaol> | Because lines earlier in a source file are more likely to cause further errors later. |
| 2025-01-31 13:17:24 +0100 | <kaol> | If there are a lot of errors they have all scrolled into oblivion. |
| 2025-01-31 13:18:14 +0100 | xff0x | (~xff0x@ai096095.d.east.v6connect.net) |
| 2025-01-31 13:18:19 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-01-31 13:18:41 +0100 | <kaol> | And the first error is going to be in a fixed place in a regular terminal. With the default I have to scan vertically to even find it. |
| 2025-01-31 13:19:29 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-31 13:20:41 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-31 13:20:54 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Quit: Leaving) |
| 2025-01-31 13:20:56 +0100 | ft | (~ft@p3e9bcd97.dip0.t-ipconnect.de) ft |
| 2025-01-31 13:22:16 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-31 13:26:09 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-01-31 13:36:37 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 248 seconds) |
| 2025-01-31 13:39:27 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-31 13:40:25 +0100 | monochrom | (trebla@216.138.220.146) |
| 2025-01-31 13:44:40 +0100 | AlexNoo__ | AlexNoo |
| 2025-01-31 13:48:04 +0100 | laxmik | (~laxmik@wifi-gate-eduroam.fzu.cz) laxmik |
| 2025-01-31 13:48:31 +0100 | laxmik | michals |
| 2025-01-31 13:49:36 +0100 | michals | (~laxmik@wifi-gate-eduroam.fzu.cz) (Client Quit) |
| 2025-01-31 13:51:00 +0100 | iamsleepy | (~weechat@2a01:4f9:3070:feff:a9de:dfff:cd7f:fdcd) (Read error: Connection reset by peer) |
| 2025-01-31 13:51:25 +0100 | iamsleepy | (~weechat@2a01:4f9:3070:feff:d8a:11d8:7a8b:29a2) iamsleepy |
| 2025-01-31 13:51:29 +0100 | <dminuoso> | c_wraith, tomsmeding: Mmm okay, this is not very satisfying. The actual answer is buried behind CMM implementation details of some primops then. |
| 2025-01-31 13:51:43 +0100 | <dminuoso> | Maybe I need to consult the Haskell Report. |
| 2025-01-31 13:52:10 +0100 | <dminuoso> | instance Num Word8 where |
| 2025-01-31 13:52:15 +0100 | <dminuoso> | fromInteger i = W8# (wordToWord8# (integerToWord# i)) |
| 2025-01-31 13:53:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-01-31 13:54:08 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-31 13:54:50 +0100 | <haskellbridge> | <sm> kaol: I can't quite relate to that. I feel the first error is more likely to be the causative one, and I am generally using either VS code or ghcid which shows it |
| 2025-01-31 13:55:32 +0100 | <dminuoso> | And the Haskell Report has no guidance on the behavior of fromInteger either. |
| 2025-01-31 13:55:40 +0100 | <dminuoso> | I'm not impressed. |
| 2025-01-31 13:55:48 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-01-31 13:56:21 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-8116-f81b-81aa-4344-3e67.rev.sfr.net) alexherbo2 |
| 2025-01-31 13:57:16 +0100 | <tomsmeding> | kaol: this is what ghcid does correctly, it shows only the top screenful of errors :p |
| 2025-01-31 14:02:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-31 14:03:34 +0100 | <kaol> | ghcid doesn't really fit my use patterns. Once I get it to compile I usually want to try out a few things with my new functions in the repl. |
| 2025-01-31 14:03:58 +0100 | <haskellbridge> | <sm> ghcid gets its own window, of course |
| 2025-01-31 14:04:17 +0100 | <__monty__> | You can invert the order of errors reported by GHC FYI. |
| 2025-01-31 14:05:08 +0100 | <geekosaur> | that was what started this thread |
| 2025-01-31 14:06:07 +0100 | <__monty__> | Ah, carry on. |
| 2025-01-31 14:06:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-01-31 14:07:09 +0100 | <kaol> | I'm thinking of using inotify to use xdotool to send that :r up enter. Then I would have the code loaded in it already and not have to look at two windows and still do :r up enter. |
| 2025-01-31 14:08:08 +0100 | <kaol> | No wait, up enter is only relevat if I use history. |
| 2025-01-31 14:08:13 +0100 | <geekosaur> | that sounds like a hacky way to reinvent ghcid/ghciwatch |
| 2025-01-31 14:08:23 +0100 | <kaol> | ghcid is the hack. |
| 2025-01-31 14:09:02 +0100 | <kaol> | Give me something that integrates with the repl. |
| 2025-01-31 14:14:55 +0100 | jespada | (~jespada@2800:a4:2213:dd00:8c24:32fa:8fb8:ea12) (Ping timeout: 244 seconds) |
| 2025-01-31 14:17:44 +0100 | jespada | (~jespada@2800:a4:2215:4d00:20a9:6cd:d7c4:a65f) jespada |
| 2025-01-31 14:19:59 +0100 | AlexZenon_2 | AlexZenon |
| 2025-01-31 14:27:35 +0100 | <haskellbridge> | <sm> ghcid is a hack of the gods, then :) |
| 2025-01-31 14:27:39 +0100 | <haskellbridge> | <sm> love it |
| 2025-01-31 14:28:25 +0100 | <haskellbridge> | <sm> kaol: you might like this small improvement in .ghci, I find it very useful: |
| 2025-01-31 14:28:25 +0100 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/sCYnuCtwPTknTRbDePLKlYOX/yxjBbcu9HSA (3 lines) |
| 2025-01-31 14:29:01 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-8116-f81b-81aa-4344-3e67.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-31 14:29:15 +0100 | <haskellbridge> | <sm> it means I can just CTRL-p, enter after a change |
| 2025-01-31 14:29:52 +0100 | <haskellbridge> | <sm> or up enter, as you say |
| 2025-01-31 14:30:24 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-31 14:31:14 +0100 | CiaoSen | (~Jura@2a05:5800:263:8800:ca4b:d6ff:fec1:99da) (Ping timeout: 260 seconds) |
| 2025-01-31 14:31:30 +0100 | <haskellbridge> | <sm> what about https://hackage.haskell.org/package/rapid-0.1.5.3/docs/Rapid.html |
| 2025-01-31 14:31:52 +0100 | swamp_ | (~zmt00@user/zmt00) zmt00 |
| 2025-01-31 14:32:24 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-01-31 14:35:19 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 260 seconds) |
| 2025-01-31 14:36:48 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-31 14:42:35 +0100 | johnjaye | (~pi@syn-035-146-235-019.res.spectrum.com) (Read error: Connection reset by peer) |