Newest at the top
| 2025-05-04 00:09:27 +0200 | tromp | (~textual@2001:1c00:3487:1b00:25b8:e34c:8097:c1c7) |
| 2025-05-04 00:04:06 +0200 | P1RATEZ | (piratez@user/p1ratez) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2025-05-04 00:00:15 +0200 | tromp | (~textual@2001:1c00:3487:1b00:31c9:5f27:18bf:4d4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-03 23:47:33 +0200 | ColinRobinson | JuanDaugherty |
| 2025-05-03 23:47:28 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-05-03 23:45:16 +0200 | <geekosaur> | "sonic boom" wouldn't that just be inertia? |
| 2025-05-03 23:42:56 +0200 | <geekosaur> | (or possibly both but then there needs to be a formalization of how they both interact) |
| 2025-05-03 23:42:14 +0200 | <geekosaur> | (IIRC the folks who occasionally try to standardize Haskell extensions deadlocked over whether to standardize fundeps or tyfams along with MPTC) |
| 2025-05-03 23:41:09 +0200 | <geekosaur> | the former is why base avoids it |
| 2025-05-03 23:40:50 +0200 | <geekosaur> | only that it's not formally standardized, and that you need either fundeps or type families to use it effectively |
| 2025-05-03 23:37:07 +0200 | <haskellbridge> | <hellwolf> I probably over use it. |
| 2025-05-03 23:36:48 +0200 | <haskellbridge> | <hellwolf> What caveats one should know about MPTC |
| 2025-05-03 23:36:01 +0200 | JuanDaugherty | ColinRobinson |
| 2025-05-03 23:35:25 +0200 | <monochrom> | Yes I think base avoids MPTC. |
| 2025-05-03 23:34:22 +0200 | <haskellbridge> | <loonycyborg> probably overloading spaces will be in C++50 |
| 2025-05-03 23:33:52 +0200 | <monochrom> | EvanR: Is that a physics joke? Lifting ( really fast leading to < because sonic boom? :) I mean :> |
| 2025-05-03 23:33:38 +0200 | <haskellbridge> | <loonycyborg> btw in C++ you can overload "," :P |
| 2025-05-03 23:32:38 +0200 | <haskellbridge> | <hellwolf> Is multiparameter type class avoided in base/core libraries deliberately? |
| 2025-05-03 23:28:41 +0200 | <EvanR> | that was the joke |
| 2025-05-03 23:28:07 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-05-03 23:26:52 +0200 | <haskellbridge> | <loonycyborg> for example you can already use <> for many seemingly unrelated things :P |
| 2025-05-03 23:24:22 +0200 | <haskellbridge> | <loonycyborg> there's already an overloading mechanism. It's called typeclasses |
| 2025-05-03 23:20:57 +0200 | <EvanR> | overloaded whitespace is something else |
| 2025-05-03 23:20:51 +0200 | <haskellbridge> | <hellwolf> overloaded whitespaces |
| 2025-05-03 23:20:42 +0200 | <haskellbridge> | <hellwolf> whitespace programming language? |
| 2025-05-03 23:20:17 +0200 | <EvanR> | there's too many different operators. Somebody should make an overloading mechanism so you can just use 1 |
| 2025-05-03 23:19:49 +0200 | <haskellbridge> | <hellwolf> I was devastated that I couldn't use <$_> |
| 2025-05-03 23:19:25 +0200 | <haskellbridge> | single $ or & are aliases of them for single category, sometimes helpful to type inference, direction of the >> is a convenient way to say where the function is. |
| 2025-05-03 23:19:25 +0200 | <haskellbridge> | <hellwolf> $$ && for functors of two different categories |
| 2025-05-03 23:19:23 +0200 | <EvanR> | you'll have to rotate the monitor 90 degrees like old smiley :) |
| 2025-05-03 23:19:12 +0200 | <EvanR> | if you lift a ( really fast it becomes a < |
| 2025-05-03 23:18:01 +0200 | <monochrom> | and <$> = liftA2 ($). Who would have thought. :) |
| 2025-05-03 23:17:31 +0200 | <monochrom> | To be sure, my heuristic fails with <*> = liftA2 (*) :) |
| 2025-05-03 23:16:07 +0200 | <monochrom> | I will guess <&&> = liftA2 (&&). I won't guess the others, there is no point. |
| 2025-05-03 23:15:24 +0200 | <monochrom> | Lisp/Scheme's call/cc is my first encounter with "continuation". :) |
| 2025-05-03 23:15:22 +0200 | <haskellbridge> | <hellwolf> guess the meaning of the operators of the day: <$$> <$>> <&&> <<&> |
| 2025-05-03 23:11:57 +0200 | TMA | (tma@twin.jikos.cz) TMA |
| 2025-05-03 23:11:18 +0200 | Square | (~Square@user/square) Square |
| 2025-05-03 23:10:44 +0200 | <EvanR> | ^ |
| 2025-05-03 23:10:00 +0200 | TMA | (tma@twin.jikos.cz) (Ping timeout: 260 seconds) |
| 2025-05-03 23:09:52 +0200 | <hellwolf> | so, that might start to make sense, someone from C++ committee played too much Diablo. |
| 2025-05-03 23:09:16 +0200 | <int-e> | (Charsi in Diablo II was my first encounter with the word "imbue") |
| 2025-05-03 23:09:08 +0200 | <hellwolf> | at the time of diablo, I wouldn't follow english conversation much :D |
| 2025-05-03 23:08:41 +0200 | <int-e> | . o O ( Somebody never played Diablo ) |
| 2025-05-03 23:08:30 +0200 | <hellwolf> | imbue |
| 2025-05-03 23:08:15 +0200 | <hellwolf> | I think it's a good candidate for IO monad at least |
| 2025-05-03 23:06:41 +0200 | <EvanR> | yeah it is |
| 2025-05-03 23:06:36 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-05-03 23:06:16 +0200 | <hellwolf> | is that even a word. |
| 2025-05-03 23:06:03 +0200 | <hellwolf> | "imbue" confused the hell out of me |