Newest at the top
| 2025-11-21 16:38:07 +0100 | Vajb | (~Vajb@n4bl3ovzcj023yptes7-1.v6.elisa-mobile.fi) (Ping timeout: 264 seconds) |
| 2025-11-21 16:37:31 +0100 | <haskellbridge> | <loonycyborg> But if things aren't context aware then it could be worse than showing it entirely |
| 2025-11-21 16:37:12 +0100 | Googulator75 | (~Googulato@81.183.235.203) |
| 2025-11-21 16:36:55 +0100 | Googulator75 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2025-11-21 16:36:40 +0100 | <__monty__> | As long as the diff is shorter that is. |
| 2025-11-21 16:36:21 +0100 | <haskellbridge> | <loonycyborg> but it's a hard ask honestly |
| 2025-11-21 16:36:13 +0100 | <haskellbridge> | <loonycyborg> Indeed |
| 2025-11-21 16:35:16 +0100 | <lucabtz> | it would be cool if it only sent a diff with the edit |
| 2025-11-21 16:35:00 +0100 | <lucabtz> | like not showing the edit? |
| 2025-11-21 16:34:20 +0100 | timide | (~timide@user/timide) (Remote host closed the connection) |
| 2025-11-21 16:33:57 +0100 | Googulator5 | (~Googulato@team.broadbit.hu) (Ping timeout: 250 seconds) |
| 2025-11-21 16:33:46 +0100 | <haskellbridge> | <loonycyborg> I mean not showing in the first place :P |
| 2025-11-21 16:33:17 +0100 | <lucabtz> | s/sen/sent |
| 2025-11-21 16:33:08 +0100 | <lucabtz> | once sent it is sen |
| 2025-11-21 16:33:00 +0100 | <lucabtz> | well losing them isnt really possible through IRC |
| 2025-11-21 16:32:38 +0100 | <haskellbridge> | <loonycyborg> It's better than losing them |
| 2025-11-21 16:32:11 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) |
| 2025-11-21 16:31:30 +0100 | <__monty__> | Basically repeats the entire message. |
| 2025-11-21 16:31:16 +0100 | <haskellbridge> | <loonycyborg> btw does the matrix bridge support showing edits to IRC? |
| 2025-11-21 16:31:15 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-11-21 16:30:46 +0100 | Googulator75 | (~Googulato@team.broadbit.hu) |
| 2025-11-21 16:30:42 +0100 | tromp | (~textual@2001:1c00:3487:1b00:697a:bc7a:f580:408c) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-21 16:30:04 +0100 | <haskellbridge> | <loonycyborg> And if it's "(Hashable t, Typeable t)" you can both use Hashable instance and reflect its exact type. |
| 2025-11-21 16:27:12 +0100 | <haskellbridge> | <loonycyborg> But obviously it can get less maintainable because compiler won't warn you if you change types in the origin but forget to update uses of Typeable. |
| 2025-11-21 16:26:16 +0100 | <haskellbridge> | <loonycyborg> And if it's "(Hashable t, Dynamic t)" you can both use Hashable instance and reflect its exact type. |
| 2025-11-21 16:26:09 +0100 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) (Read error: Connection reset by peer) |
| 2025-11-21 16:26:04 +0100 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2025-11-21 16:23:21 +0100 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) sam113101 |
| 2025-11-21 16:22:37 +0100 | FragByte | (~christian@user/fragbyte) FragByte |
| 2025-11-21 16:22:27 +0100 | <kuribas> | It restrict t to a hashable, but it's also a guarantee that the type is hashable. |
| 2025-11-21 16:22:13 +0100 | <kuribas> | Like "Hashable t => t ** t" |
| 2025-11-21 16:21:42 +0100 | <kuribas> | __monty__: the existential can carry more information and guarantees. Restrict is a funny word for "guarantee". |
| 2025-11-21 16:21:29 +0100 | <haskellbridge> | <loonycyborg> but with Typeable/Dynamic they're equivalent |
| 2025-11-21 16:21:25 +0100 | <__monty__> | But kuribas' comment of "dynamic types are existentials, but not all existentials are dynamic types" is the other way around, no? |
| 2025-11-21 16:20:38 +0100 | FragByte | (~christian@user/fragbyte) (Quit: Quit) |
| 2025-11-21 16:20:34 +0100 | <__monty__> | That's what I assumed. |
| 2025-11-21 16:20:29 +0100 | <haskellbridge> | <loonycyborg> existentials can restric more than dynamic types |
| 2025-11-21 16:20:16 +0100 | <haskellbridge> | <loonycyborg> It's the other way around |
| 2025-11-21 16:19:33 +0100 | <__monty__> | What can existentials express that dynamic types restrict? |
| 2025-11-21 16:19:08 +0100 | <kuribas> | merijn: but you hide the tag, and make primitive functions partial. |
| 2025-11-21 16:18:45 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-11-21 16:18:35 +0100 | sam113101 | (~sam@modemcable200.189-202-24.mc.videotron.ca) (Read error: Connection reset by peer) |
| 2025-11-21 16:18:28 +0100 | <haskellbridge> | <Zemyla> newtype FreeMonoid a = FreeMonoid { runFreeMonoid :: forall r. Monoid r => (a -> r) -> r } |
| 2025-11-21 16:18:24 +0100 | <kuribas> | merijn: A dynamic language just means every value is (Tag t ** t), Where Tag :: Type -> Type |
| 2025-11-21 16:18:19 +0100 | <haskellbridge> | <loonycyborg> that way they're not dynamic types but more like C++ virtual functions and abstract classes |
| 2025-11-21 16:17:55 +0100 | <haskellbridge> | <loonycyborg> If you don't use type.reflection then typeclass entirely determines what can you do with existential |
| 2025-11-21 16:17:41 +0100 | <haskellbridge> | <Zemyla> Thinking about the free monoid now. |
| 2025-11-21 16:17:35 +0100 | yin | (~zero@user/zero) zero |
| 2025-11-21 16:17:13 +0100 | yin | (~zero@user/zero) (Ping timeout: 246 seconds) |
| 2025-11-21 16:17:11 +0100 | <merijn> | loonycyborg: You don't have to do that yourself, Dynamic exists already :) |