Newest at the top
| 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 |
| 2026-02-24 10:51:47 +0100 | <Leary> | tomsmeding: https://gist.github.com/LSLeary/c52be6739f5815d13a6774d46dcbde75 |
| 2026-02-24 10:51:43 +0100 | <int-e> | tomsmeding: 5 is the unique maximal element here |
| 2026-02-24 10:51:42 +0100 | <tomsmeding> | ah :p |
| 2026-02-24 10:51:30 +0100 | <__monty__> | tomsmeding: The conversation has moved on but I'm not sure it's not leaving dminuoso behind ; ) |
| 2026-02-24 10:51:29 +0100 | <tomsmeding> | but there's no unique maximum |
| 2026-02-24 10:51:04 +0100 | <int-e> | Is it okay if it's? 0 < 1,2 < 3,4 < 5 has minimal and maximal elements but 3,4 have no infimum and 1,2 have no supremum |
| 2026-02-24 10:50:48 +0100 | <tomsmeding> | __monty__: yes, we figured that out, but we're already at the next question: that thing is clearly a lattice, but we want a not-lattice that is nevertheless a bounded partial order |
| 2026-02-24 10:50:30 +0100 | <jreicher> | Then just "duplicate" a meet or join. It will no longer be a lattice. |
| 2026-02-24 10:50:17 +0100 | <__monty__> | but not Ord. |
| 2026-02-24 10:50:11 +0100 | <__monty__> | dminuoso: If you're looking for any example of it whatsoever I think the one tomsmeding mentioned is the easiest. Take any set with more than one element and all subsets of that set, the partial order relation is subset-of, the minBound would be the empty set, the maxBound the set you started with, some pairs of subsets won't satisfy the subset-of relation in either order. So this can implement Bounded |
| 2026-02-24 10:50:02 +0100 | <tomsmeding> | or at least, I do |
