Newest at the top
| 2026-02-24 11:32:21 +0100 | hsw | (~hsw@106.104.102.45) hsw |
| 2026-02-24 11:31:37 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
| 2026-02-24 11:31:16 +0100 | hsw | (~hsw@106.104.102.45) (Remote host closed the connection) |
| 2026-02-24 11:29:22 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 252 seconds) |
| 2026-02-24 11:27:05 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-02-24 11:26:50 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-02-24 11:23:43 +0100 | <Leary> | Re the extended argument, it's really about typeclasses with laws being used to implement operations that /don't require/ those laws and are useful in their absence; the typeclass method merely being a default choice. |
| 2026-02-24 11:21:57 +0100 | <Leary> | Even in such a case, `Arg` should be handrolled in the guts of containers, not exposed from base. |
| 2026-02-24 11:20:56 +0100 | int-e | ponders extending this argument to saying that type classes are useles; people could just pass around the right operations explicitly. :-P |
| 2026-02-24 11:20:38 +0100 | morj_away | (~morj@user/morj) (Client Quit) |
| 2026-02-24 11:18:20 +0100 | <int-e> | (So it's not just programmer laziness.) |
| 2026-02-24 11:17:10 +0100 | <int-e> | `fooBy` is awful when you have data structures with invariants (consider an implementation of containers that implements Data.Map using Data.Set with `Arg k v` elements) |
| 2026-02-24 11:16:37 +0100 | morj | (~morj@user/morj) (Ping timeout: 272 seconds) |
| 2026-02-24 11:16:01 +0100 | morj_away | (~morj@user/morj) morj |
| 2026-02-24 11:13:29 +0100 | xdminsy | (~xdminsy@112.10.231.192) (Quit: Konversation terminated!) |
| 2026-02-24 11:13:02 +0100 | petrichor | (~jez@user/petrichor) petrichor |
| 2026-02-24 11:11:52 +0100 | <Leary> | At least, not useful enough to justify its existence. |
| 2026-02-24 11:11:25 +0100 | <Leary> | It's occasionally pragmatic to break the law, yes. `Arg` actually wouldn't be useful if people always remembered to write `fooBy` instead of just `foo :: Ord a => ...`. |
| 2026-02-24 11:08:35 +0100 | morj | (~morj@user/morj) morj |
| 2026-02-24 11:08:16 +0100 | <__monty__> | Leary: But things like Arg exist and they exist because they are useful, I assume. |
| 2026-02-24 11:08:00 +0100 | xdminsy | (~xdminsy@112.10.231.192) xdminsy |
| 2026-02-24 11:02:35 +0100 | tomsmeding | has a meeting -> afk |
| 2026-02-24 11:02:13 +0100 | <Leary> | __monty__: `==` values aren't supposed to be distinguishable in the first place. |
| 2026-02-24 11:01:58 +0100 | <tomsmeding> | int-e: yes |
| 2026-02-24 11:01:25 +0100 | <__monty__> | I assume that's for some sort of canonicalization? |
| 2026-02-24 11:01:03 +0100 | <__monty__> | TIL, min and max can return a value that is distinct from their arguments, as long as it is == to one of their arguments. |
| 2026-02-24 10:59:28 +0100 | <int-e> | tomsmeding: here is what it looks like properly: https://int-e.eu/~bf3/tmp/hapo.png |
| 2026-02-24 10:57:21 +0100 | <__monty__> | tomsmeding: Oh, obviously, darn, less interesting than I thought. |
| 2026-02-24 10:56:52 +0100 | <tomsmeding> | yes, which is also what dminuoso made of it |
| 2026-02-24 10:56:24 +0100 | <Leary> | tomsmeding: Cross connections. Bit hard in slapdash asci. I revised it with an X if that's clearer. |
| 2026-02-24 10:56:14 +0100 | <jreicher> | __monty__: if the order is transitive and antisymmetric it can't be cyclical |
| 2026-02-24 10:55:11 +0100 | <tomsmeding> | __monty__: Integer? |
| 2026-02-24 10:54:55 +0100 | <tomsmeding> | dminuoso: the x must be a crossing of lines without a node, yes |
| 2026-02-24 10:54:53 +0100 | <dminuoso> | Not sure if it makes it less or more ambiguous |
| 2026-02-24 10:54:51 +0100 | <merijn> | __monty__: Clearly we need a PartialOrd superclass of Ord that implement "a -> a -> Maybe Ordering" |
| 2026-02-24 10:54:43 +0100 | <dminuoso> | Or well, maybe without that x even |
| 2026-02-24 10:54:34 +0100 | <__monty__> | I'm also interested in kind of the reverse question, are there structures that can implement Ord but not Bounded? Something like a cyclical ordering? I suppose only if we put the "laws" of the class aside. |
| 2026-02-24 10:54:13 +0100 | <dminuoso> | Leary: Did you mean it like https://paste.tomsmeding.com/ayvscggm ? |
| 2026-02-24 10:53:19 +0100 | <int-e> | Hasse diagram, meh. |
| 2026-02-24 10:53:18 +0100 | <tomsmeding> | Leary: that notation in your gist is a bit ambiguous, what do the /\ on line 4 mean :p |
| 2026-02-24 10:52:55 +0100 | <jreicher> | int-e: have I understood you correctly? |
| 2026-02-24 10:52:51 +0100 | <int-e> | the translation is a bit lossy ;) |
| 2026-02-24 10:52:41 +0100 | <int-e> | tomsmeding: sorry, I'm trying to cast a Hesse diagram in ASCII here |
| 2026-02-24 10:52:37 +0100 | tomsmeding | closes the image editor |
| 2026-02-24 10:52:36 +0100 | <jreicher> | I think int-e and I are thinking the same. 0 is one end and 5 is the other. The join of 1 and 2 is not unique |
| 2026-02-24 10:52:27 +0100 | <tomsmeding> | yes perfect |
| 2026-02-24 10:52:14 +0100 | <tomsmeding> | yes |
| 2026-02-24 10:52:07 +0100 | <tomsmeding> | oh notation |
| 2026-02-24 10:52:00 +0100 | <int-e> | tomsmeding: it's transitive |
| 2026-02-24 10:51:53 +0100 | <tomsmeding> | int-e: no, because 2 !< 5 |
