Logs: liberachat/#haskell
| 2021-07-23 18:10:54 | <c_wraith> | You see the total lack of Ord requirement? |
| 2021-07-23 18:11:01 | <c_wraith> | elems doesn't care how things are ordered |
| 2021-07-23 18:11:10 | <c_wraith> | It just does an in-order traversal of the binary tree |
| 2021-07-23 18:11:14 | <zzz> | O(n). Return all elements of the map in the ascending order of their keys. Subject to list fusion. |
| 2021-07-23 18:11:17 | <zzz> | ^from the docs |
| 2021-07-23 18:11:26 | <c_wraith> | Types are docs, too |
| 2021-07-23 18:11:39 | <c_wraith> | The lack of an Ord constraint in the type tells you something |
| 2021-07-23 18:11:44 | fendor_ | is now known as fendor |
| 2021-07-23 18:12:06 | <zzz> | right... |
| 2021-07-23 18:12:09 | <c_wraith> | what matters is the Ord instance used when inserting values |
| 2021-07-23 18:12:28 | × | favonia quits (~favonia@user/favonia) (Ping timeout: 272 seconds) |
| 2021-07-23 18:12:38 | <c_wraith> | elems just does the trivial in-order tree traversal you'd expect. No order comparisons at all |
| 2021-07-23 18:13:09 | <zzz> | so the answer is "no" |
| 2021-07-23 18:13:32 | <zzz> | because I'm using M.insert |
| 2021-07-23 18:13:39 | <EvanR> | the implementation happens to be able to deliver the documented order without using Ord (at that point) heh |
| 2021-07-23 18:13:52 | <EvanR> | *magic hands* |
| 2021-07-23 18:14:37 | <zzz> | how can i achieve the order i intend? |
| 2021-07-23 18:14:39 | → | chris_ joins (~chris@81.96.113.213) |
| 2021-07-23 18:14:40 | <c_wraith> | In general you probably shouldn't use OverlappingInstances. It just doesn't do what you think it does |
| 2021-07-23 18:14:53 | <c_wraith> | You should create your own data type with an Ord instance that does what you want |
| 2021-07-23 18:15:29 | → | platz joins (~platz@40.122.118.113) |
| 2021-07-23 18:15:30 | <EvanR> | which could just be a newtype over another type for the purposes of changing 1 instance |
| 2021-07-23 18:15:54 | <EvanR> | and then you can newtype wrap, operate, and unwrap |
| 2021-07-23 18:15:59 | <platz> | Just upgraded Esqueleto to use the latest syntax, works well |
| 2021-07-23 18:17:10 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-23 18:18:05 | <h98> | zzz read https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/instances.html carefully |
| 2021-07-23 18:18:25 | <h98> | it's actually very clear and takes out a lot of guesswork with overlapping/overlappable etc once you understand how instance resolution works |
| 2021-07-23 18:19:55 | <zzz> | i think my misundertanding here has more to do with Data.Map |
| 2021-07-23 18:20:59 | × | chris_ quits (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-23 18:20:59 | <zzz> | no? |
| 2021-07-23 18:21:20 | <zzz> | :t M.insert |
| 2021-07-23 18:21:21 | <lambdabot> | Ord k => k -> a -> M.Map k a -> M.Map k a |
| 2021-07-23 18:21:43 | <zzz> | oh i see |
| 2021-07-23 18:21:56 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 245 seconds) |
| 2021-07-23 18:22:03 | <zzz> | nevermind |
| 2021-07-23 18:22:08 | <davean> | zzz: Don't use overlapping instances, create the nominal type you want |
| 2021-07-23 18:22:44 | → | Matthias1 joins (~Matthias1@cpe-76-170-236-166.socal.res.rr.com) |
| 2021-07-23 18:22:48 | → | dunkeln joins (~dunkeln@94.129.69.87) |
| 2021-07-23 18:23:19 | → | bitmapper joins (uid464869@id-464869.tooting.irccloud.com) |
| 2021-07-23 18:23:47 | → | favonia joins (~favonia@user/favonia) |
| 2021-07-23 18:25:18 | <EvanR> | having at most 1 instance of a given class for a given type is really nice for logic reasons |
| 2021-07-23 18:25:50 | → | chris_ joins (~chris@81.96.113.213) |
| 2021-07-23 18:26:36 | <EvanR> | and since that relationship is global, it really simplifies a lot of stuf |
| 2021-07-23 18:26:53 | <monochrom> | I do best of both worlds: Create both the nominal class and the nominal type I want. https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127147.html >:) |
| 2021-07-23 18:27:18 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-23 18:28:27 | <EvanR> | this post seems short enough for me to determine if it's a joke before I have to get on this plane! |
| 2021-07-23 18:28:28 | × | dajoer quits (~david@user/gvx) (Quit: leaving) |
| 2021-07-23 18:28:58 | <monochrom> | Hell, even I, the author, can't determine whether it's a joke or not. |
| 2021-07-23 18:29:20 | <monochrom> | I would love to use that system, and at the same time it is funny. |
| 2021-07-23 18:29:33 | <EvanR> | where does p come from in the MyOrd class |
| 2021-07-23 18:29:54 | × | chris_ quits (~chris@81.96.113.213) (Ping timeout: 240 seconds) |
| 2021-07-23 18:29:54 | <monochrom> | Usually you would use Proxy. I would. |
| 2021-07-23 18:30:20 | <monochrom> | mycmp (Proxy :: Proxy Rev) "ab" "xy" |
| 2021-07-23 18:30:32 | × | favonia quits (~favonia@user/favonia) (Ping timeout: 245 seconds) |
| 2021-07-23 18:31:11 | <monochrom> | It's a "forall p". |
| 2021-07-23 18:31:31 | <EvanR> | i see |
| 2021-07-23 18:31:59 | → | favonia joins (~favonia@user/favonia) |
| 2021-07-23 18:32:13 | <EvanR> | this goes against typeclasses vs the world, in a way that makes me sympathetic to 'the world' |
| 2021-07-23 18:34:08 | → | agua joins (~agua@2804:18:44:46ad:1:0:480e:2382) |
| 2021-07-23 18:34:09 | <davean> | EvanR: hum? How so? This keeps the properties |
| 2021-07-23 18:36:07 | <EvanR> | i was under the impression that the desire to mix and match instances on the same type was 'the problem' |
| 2021-07-23 18:36:40 | <EvanR> | how can i do this, you can't do this, you shouldn't even want to do this, sort of thing |
| 2021-07-23 18:37:08 | <davean> | EvanR: Except it doesn't mix them here - that "solution" keeps them seperate |
| 2021-07-23 18:37:13 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-23 18:37:22 | <EvanR> | yeah i see that |
| 2021-07-23 18:37:42 | <EvanR> | so i don't understand the original issue now xD |
| 2021-07-23 18:37:53 | × | pesada quits (~agua@191.177.175.57) (Ping timeout: 265 seconds) |
| 2021-07-23 18:37:57 | <davean> | EvanR: you never get the "Wrong" instance with this |
| 2021-07-23 18:38:32 | → | pesada joins (~agua@2804:14c:8793:8e2f:8013:a595:bc17:299d) |
| 2021-07-23 18:38:47 | × | pavonia quits (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2021-07-23 18:39:02 | <monochrom> | The desire is that sometimes you want one hash function for String, sometimes you want a different hash function. You can do newtyping, but it becomes annoying. |
| 2021-07-23 18:39:07 | → | pavonia joins (~user@user/siracusa) |
| 2021-07-23 18:39:36 | <davean> | Right, this creates an index on the type class, and assigns instances to types inside said index |
| 2021-07-23 18:39:46 | <davean> | this is a way of producing a matrix of type classes |
| 2021-07-23 18:41:20 | <davean> | EvanR: Efectively this is a higher kinded type class |
| 2021-07-23 18:41:20 | <monochrom> | And the same time, once you have chosen one hash function for a hash table, you don't want accidental switching to a different hash function. |
| 2021-07-23 18:41:20 | <davean> | just like Maybe is a higher kinded type |
| 2021-07-23 18:41:20 | <davean> | the actual "realish" instance is after you plug in a parameter |
| 2021-07-23 18:41:20 | × | agua quits (~agua@2804:18:44:46ad:1:0:480e:2382) (Ping timeout: 256 seconds) |
| 2021-07-23 18:41:20 | <EvanR> | and if you didn't use type classes at all, nothing stops you from having the wrong hash function at the wrong place |
| 2021-07-23 18:41:20 | <monochrom> | So I said, if I don't newtype, then I need a type marker to mark which hash function my table is using. |
| 2021-07-23 18:41:20 | × | Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Read error: Connection reset by peer) |
| 2021-07-23 18:41:20 | <davean> | EvanR: Whats good about type classes is coherence - this doesn't sacrifice that at all |
| 2021-07-23 18:41:20 | → | Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-23 18:41:22 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2021-07-23 18:41:55 | <EvanR> | yeah |
| 2021-07-23 18:42:18 | <davean> | This is basicly a way to introduce type classes "on the fly" sorta, while knowing their laws still |
| 2021-07-23 18:42:20 | <davean> | for example |
| 2021-07-23 18:42:35 | <davean> | the same way we have higher kinded laws for Maybe |
| 2021-07-23 18:43:48 | <EvanR> | i want this to be an instance of generally stating whatever you want in type classes |
| 2021-07-23 18:43:55 | <monochrom> | You can still sympathize with the world because the world uses OOP in which a hash table object comes with its own insert and delete methods and those two methods have already linked to one hash function at table creation time, not switchable, the problem doesn't even exist in the first place. |
| 2021-07-23 18:43:58 | <EvanR> | and having it be checked |
| 2021-07-23 18:46:50 | <EvanR> | encoding what you want directly, hinging on this one resolver, seems better than hoping you wrote to abstract data type correctly... but also requires a different mentality |
| 2021-07-23 18:47:01 | <EvanR> | wrote the* |
| 2021-07-23 18:50:45 | × | ralu quits (~ralu@static.211.245.203.116.clients.your-server.de) (Quit: Ping timeout (120 seconds)) |
| 2021-07-23 18:50:54 | × | p3n quits (~p3n@217.198.124.246) (Ping timeout: 252 seconds) |
| 2021-07-23 18:50:59 | → | ralu joins (~ralu@static.211.245.203.116.clients.your-server.de) |
| 2021-07-23 18:50:59 | × | fendor quits (~fendor@91.141.32.205.wireless.dyn.drei.com) (Read error: Connection reset by peer) |
| 2021-07-23 18:51:18 | → | fendor joins (~fendor@91.141.32.205.wireless.dyn.drei.com) |
| 2021-07-23 18:51:52 | → | p3n joins (~p3n@217.198.124.246) |
All times are in UTC.