Newest at the top
| 2024-09-30 18:19:09 +0200 | <Inst> | That said: |
| 2024-09-30 18:19:03 +0200 | <Inst> | f Bar = ...; f Baz = ...; f :: ??? |
| 2024-09-30 18:18:59 +0200 | <tomsmeding> | that syntax is indeed free, but typing indeed presents a problem |
| 2024-09-30 18:18:39 +0200 | <tomsmeding> | `f Bar = ...`? |
| 2024-09-30 18:18:33 +0200 | <Inst> | I mean data Foo = Bar Int | Baz Char |
| 2024-09-30 18:18:20 +0200 | <tomsmeding> | `f Left = ...`? |
| 2024-09-30 18:18:11 +0200 | <Inst> | i pointed out there's a possible syntax but it makes no sense in a statically typed language |
| 2024-09-30 18:17:53 +0200 | <Inst> | you asked "what would you expect the syntax to even be" |
| 2024-09-30 18:17:34 +0200 | <tomsmeding> | there's nothing "partially applied" going on here |
| 2024-09-30 18:17:28 +0200 | <tomsmeding> | the {} syntax is just from record syntax; it just allows you to elide the actual fields |
| 2024-09-30 18:16:55 +0200 | <Inst> | Bar :: Int -> Foo; Baz :: Char -> Foo |
| 2024-09-30 18:16:38 +0200 | <Inst> | what is the type of your function? |
| 2024-09-30 18:16:32 +0200 | <c_wraith> | You'd use positional match syntax if you want to reconsider your definition when the type changes. You'd use record match syntax when you want to ignore changes to the definition. |
| 2024-09-30 18:16:29 +0200 | <Inst> | if you're trying to top level pattern match on a constructor from Foo |
| 2024-09-30 18:16:26 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-09-30 18:15:45 +0200 | <c_wraith> | It mostly depends on what kinds of changes you're expecting. Like, you'd never expect Either to change its definition, so it really doesn't matter. But if you have some domain type that might frequently change during development it can matter. |
| 2024-09-30 18:14:21 +0200 | <tomsmeding> | still not sure where the inconsistent types come from or what you really mean :p |
| 2024-09-30 18:14:10 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-30 18:14:00 +0200 | <tomsmeding> | sometimes, yes |
| 2024-09-30 18:13:47 +0200 | <c_wraith> | sometimes. |
| 2024-09-30 18:13:42 +0200 | <Inst> | c_wraith: wait, do people actually use that syntax? |
| 2024-09-30 18:13:34 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2024-09-30 18:13:26 +0200 | <Inst> | tomsmeding: something like just parensing a partially applied data constructor, but either case, Left / Right is like a special case, otherwise it's usually just begging for inconsistent types |
| 2024-09-30 18:13:01 +0200 | <lambdabot> | 1 |
| 2024-09-30 18:13:00 +0200 | <c_wraith> | > case Left "hello" of Left{} -> 1 ; Right{} -> 2 -- Inst |
| 2024-09-30 18:11:52 +0200 | <ski> | __monty__ : sometimes `join' is easier or clearer to write directly, rather than `(>>=)'. i was wondering what you similarly thought about `liftA2' vs. `(<*>)' |
| 2024-09-30 18:10:08 +0200 | <tomsmeding> | and without <*>? :p |
| 2024-09-30 18:09:33 +0200 | <__monty__> | ski: Presuming <*>, yes. |
| 2024-09-30 18:09:16 +0200 | <tomsmeding> | what would you expect the syntax to even be |
| 2024-09-30 18:09:04 +0200 | <Inst> | in this case, though, it'd be a simple type violation, no? |
| 2024-09-30 18:08:56 +0200 | <tomsmeding> | on a *partially applied data constructor, I guess you mean? |
| 2024-09-30 18:08:51 +0200 | <Inst> | data Foo = Bar Int | Baz Char |
| 2024-09-30 18:08:39 +0200 | <Inst> | tomsmeding: i'm actually hard-pressed to imagine a case where being able to match on data constructosr would be useful |
| 2024-09-30 18:06:36 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-09-30 18:06:36 +0200 | <ski> | __monty__ : `liftA2's simpler ? |
| 2024-09-30 18:06:35 +0200 | <tomsmeding> | __monty__: (<*>) = ap |
| 2024-09-30 18:06:29 +0200 | <tomsmeding> | Inst: hence that won't work |
| 2024-09-30 18:06:26 +0200 | <tomsmeding> | *alone |
| 2024-09-30 18:06:24 +0200 | <tomsmeding> | and also, we want stuff like "you can match on this" to be determinable from types alonr |
| 2024-09-30 18:06:09 +0200 | <tomsmeding> | if we'd allow matching on partially-applied data constructors, then somehow "C" would behave differently from "\x -> C x", which is not a partially-applied datacon but instead a function |
| 2024-09-30 18:06:05 +0200 | <__monty__> | I wonder why I always have the most trouble implementing <*> of all the Functor to Monad concepts. |
| 2024-09-30 18:05:31 +0200 | <tomsmeding> | i.e. we'd like "\x -> f x" and "f" to behave the same |
| 2024-09-30 18:05:19 +0200 | <tomsmeding> | in haskell we like eta-reduction/eta-abstraction to not do anything semantically |
| 2024-09-30 18:05:18 +0200 | <ski> | how ? |
| 2024-09-30 18:04:46 +0200 | <Inst> | hmmm, but in theory, it makes sense that Haskell could match on data constructors and partially applied data constructors, no? |
| 2024-09-30 18:02:26 +0200 | <monochrom> | Eventually you will find that my trick is to use dynamic scoping! >:) |
| 2024-09-30 18:01:01 +0200 | <monochrom> | There is a second instance of the same typo. But a second upload fixed it. |
| 2024-09-30 17:59:35 +0200 | <tomsmeding> | yay! |
| 2024-09-30 17:59:30 +0200 | <monochrom> | Fixed! |
| 2024-09-30 17:58:42 +0200 | <monochrom> | Ooohhhh I thought I caught all typos. |