Newest at the top
| 2024-04-28 12:19:12 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-28 12:18:35 +0200 | mima | (~mmh@eduroam-pool4-264.wlan.uni-bremen.de) (Ping timeout: 260 seconds) |
| 2024-04-28 12:18:14 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-28 12:18:02 +0200 | <ski> | iow, i'd prefer to be given the choice of using the usual type signatures, or a more C-style mixed definiendum & type ascriptions. (or both, or neither) |
| 2024-04-28 12:16:55 +0200 | <ski> | (otoh, the MLs doesn't have separate type signatures, interleaved with implementation. you can only put those in signatures (/ module types)) |
| 2024-04-28 12:16:02 +0200 | <yin> | i see |
| 2024-04-28 12:15:46 +0200 | <ski> | unlike in the MLs, where this works just fine |
| 2024-04-28 12:15:35 +0200 | <ski> | yea, but that only works for pattern bindings, yin |
| 2024-04-28 12:15:23 +0200 | <ski> | yea, but i'd rather have the option to express a full signature in this style, in addition to the usual separate type signature. rather than *almost*, but not quite, being able to do this |
| 2024-04-28 12:15:21 +0200 | <yin> | e |
| 2024-04-28 12:15:16 +0200 | <yin> | foo :: Bool = True -- works just fin |
| 2024-04-28 12:14:41 +0200 | <yin> | we can't do that anymore? |
| 2024-04-28 12:14:26 +0200 | <tomsmeding> | at that point just write a type signature :p |
| 2024-04-28 12:14:23 +0200 | <ski> | the ` :: [b]' there, specifically |
| 2024-04-28 12:14:13 +0200 | <ski> | map (f :: a -> b) (xs0 :: [a]) :: [b] = case xs0 of ... |
| 2024-04-28 12:13:56 +0200 | <yin> | ski: wdym? |
| 2024-04-28 12:13:46 +0200 | <ski> | .. i miss the ability to put a type ascription on the whole definiendum |
| 2024-04-28 12:13:21 +0200 | <yin> | forget the | |
| 2024-04-28 12:13:15 +0200 | <yin> | *i mean |
| 2024-04-28 12:13:15 +0200 | <tomsmeding> | it's never strictly necessary, but can be very convenient in some cases |
| 2024-04-28 12:13:13 +0200 | <ski> | the definiendum of the defining equation |
| 2024-04-28 12:13:13 +0200 | <yin> | i man |
| 2024-04-28 12:13:12 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-28 12:13:02 +0200 | <yin> | or | |
| 2024-04-28 12:12:59 +0200 | <yin> | tomsmeding: left of the = on a function definition |
| 2024-04-28 12:12:54 +0200 | <tomsmeding> | a type annotation in a pattern? |
| 2024-04-28 12:12:47 +0200 | <tomsmeding> | what does "function head" mean? |
| 2024-04-28 12:12:47 +0200 | <yin> | or is it just a convenience |
| 2024-04-28 12:12:32 +0200 | <yin> | i guess my question is: do we really need the ability to annotate on the function head? |
| 2024-04-28 12:09:28 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-28 12:08:51 +0200 | <tomsmeding> | it's a workaround to be sure |
| 2024-04-28 12:08:47 +0200 | <tomsmeding> | that helper function could have a type signature from which you can get your type variables with ScopedTypeVariables |
| 2024-04-28 12:08:34 +0200 | mima | (~mmh@eduroam-pool4-264.wlan.uni-bremen.de) |
| 2024-04-28 12:08:25 +0200 | <tomsmeding> | you could also write a helper function that you pass your matched things to |
| 2024-04-28 12:07:19 +0200 | <ski> | "I think it's never actually necessary" -- introducing a type variable for an opened existential |
| 2024-04-28 12:05:36 +0200 | mima | (~mmh@eduroam-pool4-264.wlan.uni-bremen.de) (Ping timeout: 268 seconds) |
| 2024-04-28 12:04:09 +0200 | <tomsmeding> | yin: indeed, it's a type annotation that you can put in a convenient spot |
| 2024-04-28 12:03:52 +0200 | <int-e> | (wrong channel) |
| 2024-04-28 12:03:45 +0200 | <lambdabot> | -9223372036854775808 |
| 2024-04-28 12:03:43 +0200 | <yin> | > minBound :: Int |
| 2024-04-28 12:03:38 +0200 | <yin> | somehow i don't consider that to be patter matching. it's just like |
| 2024-04-28 12:03:26 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-28 12:03:10 +0200 | <int-e> | tomsmeding: oh the cloudatacost.com fan page is gone, so sad. https://web.archive.org/web/20220811231349/https://cloudatacost.com/mystory/original-story-2014 |
| 2024-04-28 12:02:51 +0200 | <yin> | oh i see |
| 2024-04-28 12:02:25 +0200 | <tomsmeding> | it's nicer to write `catch _ (\(e :: IOException) -> ...)` |
| 2024-04-28 12:02:14 +0200 | <tomsmeding> | you typically have to manually constrain e somehow, and having to do that on some occurrence in the body is kind of clunky |
| 2024-04-28 12:02:08 +0200 | <yin> | yes |
| 2024-04-28 12:01:54 +0200 | <tomsmeding> | yin: do you see the `(e :: IOException)` in the example in the haddocks? |
| 2024-04-28 12:01:34 +0200 | <tomsmeding> | so then ghc asks you to say precisely what you mean -- some specific instantiation, or an actual polymorphic type where it's then on you to write down what ghc should do |
| 2024-04-28 12:01:14 +0200 | <yin> | tomsmeding: where's the type annotation on pattern matching in 'catch'? |