Newest at the top
| 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 |
| 2024-11-16 21:16:29 +0100 | petrichor | (~znc-user@user/petrichor) petrichor |
| 2024-11-16 21:05:39 +0100 | ChanServ | +v haskellbridge |
| 2024-11-16 21:05:39 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2024-11-16 21:00:41 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-16 21:00:05 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-16 20:59:03 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 276 seconds) |
| 2024-11-16 20:56:39 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) hgolden |
| 2024-11-16 20:56:18 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) (Quit: Leaving) |
| 2024-11-16 20:55:14 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2024-11-16 20:47:23 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-16 20:43:59 +0100 | malte | (~malte@152.89.107.66) (Remote host closed the connection) |
| 2024-11-16 20:40:26 +0100 | <Rembane> | Good luck! |
| 2024-11-16 20:40:23 +0100 | <Rembane> | np! |
| 2024-11-16 20:38:14 +0100 | <RedNifre> | Thanks! |
| 2024-11-16 20:35:06 +0100 | <Rembane> | RedNifre: https://hexdocs.pm/elixir/Enum.html#reduce_while/3 |
| 2024-11-16 20:34:29 +0100 | <RedNifre> | By the way, is this also a good place to talk about dependently typed programming? Or is there a separate channel for it? |
| 2024-11-16 20:33:28 +0100 | <RedNifre> | Oh, interesting! I'll look into reduce_while then to figure out the reason for that name. |
| 2024-11-16 20:33:25 +0100 | <Rembane> | foldrWhile? |
| 2024-11-16 20:32:56 +0100 | <RedNifre> | "reduce" is already a thing in Kotlin, it's kinda foldr for non-empty lists where the first element is used as a parameter to foldr the rest of the list. |
| 2024-11-16 20:32:40 +0100 | <Rembane> | RedNifre: Cool! I have no experience at all with that, but FWIW: Elixir calls it reduce_while. |
| 2024-11-16 20:32:28 +0100 | <RedNifre> | Also, it's a good multi platform language as in KMP (Kotlin Multi Platform) compiles for JVM, iOS and JS. |
| 2024-11-16 20:32:17 +0100 | <lxsameer> | s/anywhere/everywhere |