Newest at the top
| 2024-06-30 20:00:54 +0200 | <mreh> | nhar: I'm working on that |
| 2024-06-30 20:00:43 +0200 | <mreh> | I'm generating GLSL and want to see if I can statically check all the vertex buffers and uniforms are there when it comes to run it |
| 2024-06-30 20:00:36 +0200 | <nhar> | mreh: np! Not sure how user friendly it is - but if all else fails you could implement your own if your type-level-fu is up to it |
| 2024-06-30 20:00:07 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 260 seconds) |
| 2024-06-30 19:59:49 +0200 | <mreh> | nhar: thx |
| 2024-06-30 19:59:45 +0200 | <mreh> | google is your friend |
| 2024-06-30 19:58:57 +0200 | dcoutts | (~duncan@ip-185-104-136-57.ptr.icomera.net) (Ping timeout: 256 seconds) |
| 2024-06-30 19:58:53 +0200 | <nhar> | mreh: i found this: https://hackage.haskell.org/package/type-level-sets-0.7 |
| 2024-06-30 19:57:36 +0200 | <mreh> | Is there an equivalent to a Map at the type level? |
| 2024-06-30 19:53:51 +0200 | <Lawrence1erkheim> | I think I get currying now* |
| 2024-06-30 19:53:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-30 19:53:46 +0200 | <Lawrence1erkheim> | Wait no, let me fix that |
| 2024-06-30 19:53:41 +0200 | <Lawrence1erkheim> | I get currying now |
| 2024-06-30 19:53:33 +0200 | <Lawrence1erkheim> | Oh my lord computerphile are so goated |
| 2024-06-30 19:53:16 +0200 | <monochrom> | A while ago I also thought about how to make >>= more theoretically pleasing. I haven't finished, but I think the first step is to flip the argument order, (a -> m b) -> (m a -> m b). Then it is just the unsurprising functor from the Kleisli category back to the original category. |
| 2024-06-30 19:48:10 +0200 | <lambdabot> | (a -> b) -> a -> b |
| 2024-06-30 19:48:09 +0200 | <probie> | :t ($) |
| 2024-06-30 19:48:07 +0200 | <lambdabot> | Monad m => (a -> m b) -> m a -> m b |
| 2024-06-30 19:48:06 +0200 | <probie> | :t (=<<) |
| 2024-06-30 19:48:02 +0200 | <lambdabot> | a -> (a -> b) -> b |
| 2024-06-30 19:48:01 +0200 | <probie> | :t (&) |
| 2024-06-30 19:48:00 +0200 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2024-06-30 19:47:58 +0200 | <probie> | :t (>>=) |
| 2024-06-30 19:47:44 +0200 | <probie> | I'd say it's closer to `(.)`/`(&)` |
| 2024-06-30 19:47:35 +0200 | <lambdabot> | Functor f => f a -> (a -> b) -> f b |
| 2024-06-30 19:47:33 +0200 | <mreh> | :t (<&>) |
| 2024-06-30 19:47:17 +0200 | <Rembane> | It's sadly quite hard to mix (<&>) and (>=>) |
| 2024-06-30 19:46:55 +0200 | <geekosaur> | ) |
| 2024-06-30 19:46:52 +0200 | <geekosaur> | (the former being (>>=) |
| 2024-06-30 19:46:43 +0200 | <geekosaur> | right, but you more often use pure computations in monadic contexts than you compose monadic operations |
| 2024-06-30 19:46:40 +0200 | <Rembane> | ncf: Yes! Just add monads! |
| 2024-06-30 19:46:26 +0200 | <ncf> | the (>=>)/(>>=) debate should be entirely analogous to the (.)/($) debate |
| 2024-06-30 19:46:17 +0200 | <Rembane> | Monad composition |
| 2024-06-30 19:46:14 +0200 | <Rembane> | Nah, it's composition |
| 2024-06-30 19:46:12 +0200 | <probie> | I use `(>>=)` a lot more than `(>=>)`. `(>=>)` is nice for stating the laws because it's pretty much composition, but using it is about as ergonomic as writing all functions point-free |
| 2024-06-30 19:46:07 +0200 | <lambdabot> | Monad m => (a -> m b) -> (b -> m c) -> a -> m c |
| 2024-06-30 19:46:06 +0200 | <Rembane> | :t (>=>) |
| 2024-06-30 19:46:03 +0200 | <jackdk> | I find that teaching is good for highlighting how `do`-notation works, and the sort of code that people usually write. I find that `(>=>)` is good for highlighting the laws in an obvious way, and highlighting `join` makes it map more cleanly to the traditional definitions. It is often a good exercise to ask people to write each in terms of the other two. |
| 2024-06-30 19:46:02 +0200 | <Rembane> | I don't think you have to interact with tuples, let me see... |
| 2024-06-30 19:45:59 +0200 | <ncf> | tuples? |
| 2024-06-30 19:45:13 +0200 | <monochrom> | And you know it's true because why else the Arrow people went out of their way to invent do-proc notation. |
| 2024-06-30 19:44:46 +0200 | <monochrom> | With >=>, you have to introduce tuples and then eliminate them. It is indirect, it's an encoding. I am not even commenting on efficiency performance. I am commenting on whether you write what you mean or you write a translation and then the reader has to untranslate. |
| 2024-06-30 19:44:38 +0200 | <Rembane> | That's true, there's a quite straightforward mechanical translation between them that can be done in the head too! |
| 2024-06-30 19:43:00 +0200 | <monochrom> | You often need the equivalent of "... >>= \x -> ... x occurs a million times in a million levels of scopes ...". With >>= or do, you just write exactly that directly. |
| 2024-06-30 19:42:27 +0200 | nhar | (~noah@99-112-0-41.lightspeed.tukrga.sbcglobal.net) |
| 2024-06-30 19:42:15 +0200 | <Rembane> | Sweet! |
| 2024-06-30 19:41:55 +0200 | <monochrom> | But I think I can describe why it's more pragmatic. |
| 2024-06-30 19:40:53 +0200 | dcoutts | (~duncan@ip-185-104-136-57.ptr.icomera.net) |
| 2024-06-30 19:40:48 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-06-30 19:38:08 +0200 | <monochrom> | Just frequency in code people write. |