Newest at the top
| 2024-04-28 12:26:59 +0200 | <tomsmeding> | ah no I'm not surprised about foo3 |
| 2024-04-28 12:26:26 +0200 | <tomsmeding> | and I'm even more surprised that foo1 works but foo3 doesn't |
| 2024-04-28 12:26:13 +0200 | <tomsmeding> | to be honest I'm kind of surprised that foo3 doesn't work; I'm not sure what to expect with foo0 |
| 2024-04-28 12:25:43 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-28 12:24:35 +0200 | <tomsmeding> | in your last parenthetical |
| 2024-04-28 12:24:27 +0200 | <ski> | i'm pretty sure the former (or another example that also tested the same thing) also didn't work, at some point |
| 2024-04-28 12:24:21 +0200 | <tomsmeding> | ski: were you talking about the foo0 behaviour? |
| 2024-04-28 12:24:06 +0200 | <tomsmeding> | https://play.haskell.org/saved/AwWkZI0A |
| 2024-04-28 12:23:27 +0200 | Square | (~Square@user/square) |
| 2024-04-28 12:22:16 +0200 | <yin> | awful error message :p |
| 2024-04-28 12:22:15 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-04-28 12:21:39 +0200 | <lambdabot> | <hint>:1:5: error: Parse error in pattern: map |
| 2024-04-28 12:21:38 +0200 | <ski> | > let map (f :: a -> b) (xs0 :: [a]) :: [b] = case xs0 of [] -> []; x:xs -> f x : map f xs in map (^ 2) [2,3,5,7] |
| 2024-04-28 12:21:36 +0200 | <lambdabot> | [4,9,25,49] |
| 2024-04-28 12:21:35 +0200 | <ski> | > let map (f :: a -> b) (xs0 :: [a]) = (case xs0 of [] -> []; x:xs -> f x : map f xs) :: [b] in map (^ 2) [2,3,5,7] |
| 2024-04-28 12:21:13 +0200 | <ski> | hm. maybe they changed it so it works, now ? |
| 2024-04-28 12:20:29 +0200 | <tomsmeding> | I guess it only does if the body already inferred to the annotated types? |
| 2024-04-28 12:19:54 +0200 | <yin> | also news t ome |
| 2024-04-28 12:19:47 +0200 | <tomsmeding> | wait it doesn't? |
| 2024-04-28 12:19:24 +0200 | <ski> | (i'd also like the above to be able to bind tyvars `a' and `b', without a separate type signature. as, iirc, `PatternSignatures' originally allowed, but the current `ScopedTypeVariables' doesn't. but that's a separate issue) |
| 2024-04-28 12:19:22 +0200 | <tomsmeding> | you're right, for functions with many arguments it would sometimes be nice to be able to interleave the types with the argument names |
| 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? |