Newest at the top
| 2024-11-16 22:48:17 +0100 | eax | zenmov |
| 2024-11-16 22:46:58 +0100 | <geekosaur> | I don't do videos for the most part (sensory issues) |
| 2024-11-16 22:46:40 +0100 | <hellwolf> | (if you haven't watched, check it out) |
| 2024-11-16 22:46:15 +0100 | <hellwolf> | well, I saw a recent video from bluefin, it was used there exclusively |
| 2024-11-16 22:46:13 +0100 | <geekosaur> | in patsyns it distinguishes required contexts from provided contexts |
| 2024-11-16 22:45:48 +0100 | <hellwolf> | I did not know that. Actually, I rarely used the second one, and didn't realize it was correct. |
| 2024-11-16 22:45:41 +0100 | <geekosaur> | so I wouldn't want to rely on it working because it might suddenly start to mean something different in the future |
| 2024-11-16 22:45:22 +0100 | <hellwolf> | oh? |
| 2024-11-16 22:45:08 +0100 | <hellwolf> | *flavors war |
| 2024-11-16 22:45:07 +0100 | <geekosaur> | strictly speaking the latter is wrong, and it means something different in some contexts (notably pattern synonyms) |
| 2024-11-16 22:44:22 +0100 | <hellwolf> | I just found that my emacs default formatter coping with the latter better. |
| 2024-11-16 22:43:55 +0100 | <hellwolf> | rapid file mode... is this a Haskellite flame war: (a, b) => ... vs. a => b => ... |
| 2024-11-16 22:40:08 +0100 | <hellwolf> | right. makes sense. |
| 2024-11-16 22:37:26 +0100 | <int-e> | you'll either have to hide the import or use qualified names if you want to use such a function though |
| 2024-11-16 22:36:11 +0100 | <geekosaur> | correct, because they're not defined within the same module/scope. |
| 2024-11-16 22:34:59 +0100 | <hellwolf> | Overlapping function names from Prelude does not generate warnings, it seems acceptable? |
| 2024-11-16 22:34:23 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.50) (Quit: Leaving) |
| 2024-11-16 22:31:07 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-11-16 22:21:42 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2024-11-16 22:20:27 +0100 | Guest28 | (~Guest63@2800:a4:10c5:4200:c0d2:e4ff:567a:64d8) |
| 2024-11-16 22:20:00 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 272 seconds) |
| 2024-11-16 22:15:23 +0100 | eax | (~eax@user/zenmov) zenmov |
| 2024-11-16 22:03:37 +0100 | troojg | (~troojg@user/troojg) troojg |
| 2024-11-16 22:02:07 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-16 22:01:06 +0100 | <hellwolf> | I think I found a solution, maybe it is common for eDSLs: say I have a keyword "match", I just need to do (BlockArguments alert) `match a \case -> Maybe a' -> a'; Nothing -> some_def`, where by a just needs to be constrained by an imaginary "EnumerablePatternMatchingCases", such that the codegen can just enumerate through the cases and generate code for all branches accordingly. |
| 2024-11-16 21:55:51 +0100 | <geekosaur> | especially in Haskell, because that is strict by default and therefore drives evaluation |
| 2024-11-16 21:54:11 +0100 | <geekosaur> | but yes, the base assumption is pattern matching on constructors |
| 2024-11-16 21:53:26 +0100 | <geekosaur> | this is alos why MukltiWayIf has the syntax it does, since the conversion to such a case with multiple guards is trivial |
| 2024-11-16 21:52:51 +0100 | <geekosaur> | `if` normally becomes a guard in a dummy `case` (`case () of () | …`) |
| 2024-11-16 21:52:20 +0100 | <hellwolf> | Without, you may emulate with if isConstructorA a then .. else if isCOnstructorB .. and so on. |
| 2024-11-16 21:51:33 +0100 | <hellwolf> | Maybe a bad formulation of the question. I guess ADT by definition needs pattern-matching/case analysis. |
| 2024-11-16 21:50:31 +0100 | _xor5 | _xor |
| 2024-11-16 21:50:30 +0100 | _xor | (~xor@ip-66-42-132-175.dynamic.fuse.net) (Ping timeout: 252 seconds) |
| 2024-11-16 21:50:04 +0100 | <hellwolf> | Is the advantage of case/pattern matching, over the if-then-else chains, in its ability to do exhaustiveness checking? |
| 2024-11-16 21:50:03 +0100 | _xor5 | (~xor@ip-66-42-132-175.dynamic.fuse.net) _xor |
| 2024-11-16 21:46:23 +0100 | <geekosaur> | but where Haskell-level `let` defaults to lazy pattern matching, in STG it's strict |
| 2024-11-16 21:45:49 +0100 | <geekosaur> | well, actually, slight lie. `let` does pattern matching, and by the time you reach STG `case` has become `let` |
| 2024-11-16 21:43:35 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-16 21:41:02 +0100 | <geekosaur> | there is some desugaring of `case` because nested patterns aren't supported by Core or lower levels, but in the end it's still `case` |
| 2024-11-16 21:40:15 +0100 | <geekosaur> | `if` is syntax sugar |
| 2024-11-16 21:40:05 +0100 | <geekosaur> | `case` is primitive (and in fact goes all the way down to STG) |
| 2024-11-16 21:40:04 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2024-11-16 21:37:54 +0100 | <hellwolf> | Do I have to forego the case expression for this embedded language? |
| 2024-11-16 21:37:00 +0100 | <hellwolf> | "Conditionals (e.g. “if e1 then e2 else e3”) means “ifThenElse e1 e2 e3”. However case expressions are unaffected." -- what, is actually a case expression, then? |
| 2024-11-16 21:34:10 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-16 21:32:05 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard |
| 2024-11-16 21:29:42 +0100 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2024-11-16 21:27:05 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection) |
| 2024-11-16 21:26:36 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-16 21:25:25 +0100 | Everything | (~Everythin@178-133-144-115.mobile.vf-ua.net) Everything |