Newest at the top
| 2025-05-05 21:24:11 +0200 | <c_wraith> | It's abstracting over the wrong (for most use cases) thing, so it needs more and more pieces to cover common cases |
| 2025-05-05 21:23:33 +0200 | <c_wraith> | Where this difference really pays off is that Bifunctor's first also works with Either, but if you're using Arrow you need to switch to left instead |
| 2025-05-05 21:20:58 +0200 | <c_wraith> | Or really, functions on values that can be tupled. |
| 2025-05-05 21:19:28 +0200 | <c_wraith> | Arrow is about abstracting over functions on tuples |
| 2025-05-05 21:18:55 +0200 | <c_wraith> | Also, Arrow is a weird fit. like Bifunctor is very directly just giving you access to a covariant functor on two type variables instead of one. That's its whole purpose. |
| 2025-05-05 21:16:41 +0200 | <c_wraith> | that's a corollary to the principle of least power, at least for abstract interfaces. The more things that can implement an interface, the less powerful it is. |
| 2025-05-05 21:15:26 +0200 | <tomsmeding> | I guess |
| 2025-05-05 21:15:21 +0200 | <EvanR> | use the most general thing that would work? |
| 2025-05-05 21:14:47 +0200 | <tomsmeding> | Arrow is a much stronger requirement than Bifunctor is, on a type -- but in a sense Arrow is _too_ strong: there are too few types that usefully implement Arrow |
| 2025-05-05 21:14:15 +0200 | <hellwolf> | that makes sense. |
| 2025-05-05 21:14:08 +0200 | <hellwolf> | okay. So BiFunctor is more general, so it's better. |
| 2025-05-05 21:14:05 +0200 | <tomsmeding> | did that make any sense? |
| 2025-05-05 21:13:55 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-05-05 21:13:45 +0200 | <tomsmeding> | Data.Bifunctor is a small subset of what Data.Arrow does -- a subset that's much more directly useful than arrows in its full generality |
| 2025-05-05 21:13:20 +0200 | <tomsmeding> | but it's not, it's just `first` |
| 2025-05-05 21:13:16 +0200 | <tomsmeding> | if you import Data.Arrow, it looks like you're using arrows -- usage of arrows is very rare these days, because people have figured out that the Arrow class is not a good fit for the majority of cases where arrow-like things could be good. So seeing Data.Arrow makes the reader think "hey, is this a special case where arrows _do_ work?" |
| 2025-05-05 21:12:26 +0200 | <hellwolf> | yea |
| 2025-05-05 21:12:21 +0200 | <tomsmeding> | over arrow, you mean? |
| 2025-05-05 21:12:07 +0200 | <hellwolf> | I can see that too, but I can't articulate it. |
| 2025-05-05 21:11:58 +0200 | <hellwolf> | can you articulate your aesthetic preference... |
| 2025-05-05 21:11:27 +0200 | <c_wraith> | Yeah, Bifunctor is generally the way to go. |
| 2025-05-05 21:11:26 +0200 | <hellwolf> | I see |
| 2025-05-05 21:11:17 +0200 | <haskellbridge> | <sm> 👆️ |
| 2025-05-05 21:11:15 +0200 | <monochrom> | Oh, Bifunctor. That's better. |
| 2025-05-05 21:11:01 +0200 | <monochrom> | But normally I just write that lambda. :) |
| 2025-05-05 21:10:54 +0200 | <tomsmeding> | hellwolf: use first from Data.Bifunctor |
| 2025-05-05 21:10:31 +0200 | <monochrom> | I only know of first for this. |
| 2025-05-05 21:09:44 +0200 | <hellwolf> | "\(x, y) -> (show x, y)", pointfree program tell me to use "first" from Arrow. But I don't want to. |
| 2025-05-05 21:09:30 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-05-05 21:04:20 +0200 | tromp | (~textual@2001:1c00:3487:1b00:cdc3:f42b:30fc:1c61) |
| 2025-05-05 21:02:41 +0200 | tromp | (~textual@2001:1c00:3487:1b00:cdc3:f42b:30fc:1c61) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-05 21:01:04 +0200 | euleritian | (~euleritia@ip5f5ad197.dynamic.kabel-deutschland.de) |
| 2025-05-05 21:00:43 +0200 | caconym7 | (~caconym@user/caconym) caconym |
| 2025-05-05 21:00:42 +0200 | euleritian | (~euleritia@dynamic-176-000-054-130.176.0.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-05-05 21:00:01 +0200 | caconym7 | (~caconym@user/caconym) (Quit: bye) |
| 2025-05-05 20:54:41 +0200 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) sam113101 |
| 2025-05-05 20:53:52 +0200 | Guest52 | (~Guest52@148.63.10.187) (Quit: Client closed) |
| 2025-05-05 20:50:23 +0200 | user363627 | (~user@user/user363627) (Remote host closed the connection) |
| 2025-05-05 20:48:18 +0200 | <hellwolf> | I had similar issue when doing nix related --help a while ago. Now the problems have all just happily disappeared. I still dont' know what happened. |
| 2025-05-05 20:43:46 +0200 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) (Quit: WeeChat 4.5.1) |
| 2025-05-05 20:40:43 +0200 | tolgo | (~Thunderbi@199.115.144.130) (Ping timeout: 276 seconds) |
| 2025-05-05 20:39:45 +0200 | chele | (~chele@user/chele) (Read error: Connection reset by peer) |
| 2025-05-05 20:38:49 +0200 | <monochrom> | spelling gnu |
| 2025-05-05 20:38:31 +0200 | <hellwolf> | from spelling bee to gnulongoptions bee |
| 2025-05-05 20:37:54 +0200 | <tomsmeding> | hellwolf: also, you have to get much more primitive than xterm for plain 3-bit ansi color escapes to not work |
| 2025-05-05 20:36:43 +0200 | <tomsmeding> | (`env -u PAGER cabal man` works for me) |
| 2025-05-05 20:36:21 +0200 | <tomsmeding> | perhaps I'll try unsetting PAGER for a while and seeing whether anything uses more(1) |
| 2025-05-05 20:36:16 +0200 | <haskellbridge> | <sm> it's a bit out of control |
| 2025-05-05 20:36:09 +0200 | <tomsmeding> | it seems man(1) defaults to less(1) these days |
| 2025-05-05 20:36:05 +0200 | <haskellbridge> | <sm> less has _so many_ options.. |