Newest at the top
| 2024-10-30 10:26:01 +0100 | <Inst> | (remember back when people were bragging that GHC was 80% of C++ performance? ;_;) |
| 2024-10-30 10:25:47 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 255 seconds) |
| 2024-10-30 10:25:29 +0100 | <mauke> | cool, so that's working again |
| 2024-10-30 10:25:23 +0100 | <preflex> | <bos> i'm very pleased by the recent progress of the C++ standard. it's gradually eroding the performance advantage of C++ compilers over GHC, without the simons having to do anything. |
| 2024-10-30 10:25:23 +0100 | <mauke> | preflex: quote |
| 2024-10-30 10:24:39 +0100 | <tomsmeding> | some things are faster for Set, some things are slower |
| 2024-10-30 10:24:37 +0100 | AlexZenon | (~alzenon@178.34.150.252) |
| 2024-10-30 10:24:30 +0100 | AlexNoo | (~AlexNoo@178.34.150.252) |
| 2024-10-30 10:24:25 +0100 | <tomsmeding> | for what operations? |
| 2024-10-30 10:24:11 +0100 | <Inst> | is Set generally (not always) more performant than list, given that it's an ordered size-balanced binary tree? |
| 2024-10-30 10:24:01 +0100 | preflex | (~preflex@user/preflex) preflex |
| 2024-10-30 10:23:53 +0100 | <Inst> | so it's a performance optimization |
| 2024-10-30 10:18:15 +0100 | <tomsmeding> | and you can create a singleton set without needing the dictionary, so why ask for it? |
| 2024-10-30 10:17:53 +0100 | <tomsmeding> | so Set doesn't need to "save" the dictionary somehow when creating a new set, it can just request it whenever it needs it |
| 2024-10-30 10:17:38 +0100 | <tomsmeding> | the type class system ensures that if you ask for an Ord a dictionary, then you'll always get the same one |
| 2024-10-30 10:17:07 +0100 | <Inst> | thanks for showing i'm probably wrong about Set being weird |
| 2024-10-30 10:16:49 +0100 | <tomsmeding> | though it's not terribly useful |
| 2024-10-30 10:16:44 +0100 | <tomsmeding> | not sure what's wrong with that |
| 2024-10-30 10:16:27 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-10-30 10:16:25 +0100 | <tomsmeding> | you can fully consistently create a one-element set and then request a list of all elements in the set in increasing order |
| 2024-10-30 10:15:41 +0100 | <tomsmeding> | why is that a problem? |
| 2024-10-30 10:15:38 +0100 | <tomsmeding> | that is possible |
| 2024-10-30 10:13:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-30 10:12:02 +0100 | <Inst> | i mean, unless i'm wrong about Set, i'm going to stop kicking the tires, I don't think much of containers |
| 2024-10-30 10:09:44 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-10-30 10:09:30 +0100 | <Inst> | it's possible to create a Set using Set.singleton that, ummm, can't have elements added to or removed from it |
| 2024-10-30 10:09:03 +0100 | <Inst> | empty :: Set a; i.e, without constraint |
| 2024-10-30 10:08:56 +0100 | preflex | (~preflex@schedar.uberspace.de) (Remote host closed the connection) |
| 2024-10-30 10:08:31 +0100 | <Inst> | what's going on with Set, anyways? |
| 2024-10-30 10:07:24 +0100 | AlexNoo | (~AlexNoo@178.34.150.252) (Quit: Leaving) |
| 2024-10-30 10:06:41 +0100 | AlexZenon | (~alzenon@178.34.150.252) (Quit: ;-) |
| 2024-10-30 10:06:32 +0100 | alphazone | (~alphazone@2.219.56.221) |
| 2024-10-30 10:05:56 +0100 | <tomsmeding> | the constructors are only exposed from the .Internal module, which seems fine |
| 2024-10-30 10:05:47 +0100 | <tomsmeding> | Inst: looking at the haddocks is easier :p |
| 2024-10-30 10:05:45 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2024-10-30 10:05:35 +0100 | <Inst> | ah, I misread the CPP, Set only exports the type if it's not ni Testing, so it's opaque |
| 2024-10-30 10:03:31 +0100 | <tomsmeding> | ph88: if you don't like the case then a pattern guard also suffices https://play.haskell.org/saved/HDgQPO9u, and you can even put the `let childName2` as a guard too |
| 2024-10-30 10:01:24 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-10-30 09:59:15 +0100 | <tomsmeding> | something to do with scoping of existential type variables, probably |
| 2024-10-30 09:59:04 +0100 | <tomsmeding> | (indeed, a bang pattern is insufficient, you really need a case) |
| 2024-10-30 09:58:20 +0100 | <tomsmeding> | GHC goes even further and disallows the let-binding altogether, I'm not sure what the technical reason for that is, but it couldn't work anyway |
| 2024-10-30 09:58:16 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-10-30 09:57:37 +0100 | <tomsmeding> | ph88: a let-binding is lazy, so it cannot generate any type evidence: to be certain that the type evidence you discover (such as equalities) is actually valid, you have to evaluate the proof (the GADT constructor) to WHNF |
| 2024-10-30 09:56:29 +0100 | <tomsmeding> | ph88: https://play.haskell.org/saved/gbALp3A0 |
| 2024-10-30 09:55:15 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-10-30 09:53:15 +0100 | <Inst> | hmmm, weird, Set(..) should import all the constructors |
| 2024-10-30 09:50:32 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-10-30 09:46:24 +0100 | <ph88> | Could any type wizards have a look at this code? https://play.haskell.org/saved/io5gf3oy |
| 2024-10-30 09:45:52 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:3808:5ad1:785a:e722) ph88 |
| 2024-10-30 09:39:22 +0100 | <Inst> | i.e, all state is explicit and is notated in the type system (IO / State / Reader ... etc) |