Newest at the top
| 2026-02-25 19:47:05 +0100 | <haskellbridge> | <ijouw> i did not typecheck it |
| 2026-02-25 19:46:48 +0100 | <ski> | hah, ijouw :) |
| 2026-02-25 19:46:10 +0100 | <lambdabot> | *Exception: <interactive>:3:5-21: Non-exhaustive patterns in !Nothing |
| 2026-02-25 19:46:08 +0100 | <ski> | > let !Nothing = Just 3 in () |
| 2026-02-25 19:46:05 +0100 | <lambdabot> | () |
| 2026-02-25 19:46:03 +0100 | <ski> | > let Nothing = Just 3 in () |
| 2026-02-25 19:45:40 +0100 | <lambdabot> | (*Exception: <interactive>:3:5-26: Non-exhaustive patterns in x : xs |
| 2026-02-25 19:45:38 +0100 | <ski> | > let x:xs = [] :: [Integer] in (x,xs) |
| 2026-02-25 19:45:19 +0100 | <haskellbridge> | <ijouw> counter = fmap (((s,v) -> responseLBS s [(hContentType, hvApplicationJson)] v) . ((status400,) . PL.pack ||| (status200,) . encode . increment)) . lazyRequestBody |
| 2026-02-25 19:45:11 +0100 | <ski> | (and on other data constructors. however, a value of tuple type can never fail to match a tuple pattern, but for data types with multiple data constructors, you can get match failure, so it's good to only match on those, in `let'/`where'/toplevel sparingly, when you're sure that they won't actually fail ..) |
| 2026-02-25 19:44:49 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2026-02-25 19:44:33 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-25 19:44:13 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Quit: Later) |
| 2026-02-25 19:43:41 +0100 | <ski> | you can always match on tuples, in `let' and `where' (and toplevel) |
| 2026-02-25 19:43:22 +0100 | <ski> | Milan_Vanca : yes, it's same rule. `where'-block also starts at whatever column `something' is at, regardless of which column `where' is at |
| 2026-02-25 19:43:08 +0100 | <Milan_Vanca> | ski: Nicer solution.. so tuple is ok ni this case? |
| 2026-02-25 19:42:28 +0100 | <ski> | return (responseLBS status [(hContentType,hvAplicationJSON)] result) |
| 2026-02-25 19:42:15 +0100 | <ski> | Right c -> (status200,encode (increment c)) |
| 2026-02-25 19:42:02 +0100 | <ski> | Left e -> (status400,PL.pack e) |
| 2026-02-25 19:41:59 +0100 | <Milan_Vanca> | I don't think same rules apply for where I can have where\n..something or where\n..................something |
| 2026-02-25 19:41:39 +0100 | <ski> | let (status,result) = case eitherDecode body of |
| 2026-02-25 19:41:03 +0100 | wickedjargon | (~user@208.98.208.115) (Ping timeout: 246 seconds) |
| 2026-02-25 19:40:58 +0100 | <probie> | Only if you want more than one thing :p |
| 2026-02-25 19:39:30 +0100 | <__monty__> | But braces require semicolons, eww. |
| 2026-02-25 19:39:09 +0100 | wickedja` | (~user@2605:8d80:5430:818:b927:d532:959:409c) |
| 2026-02-25 19:39:05 +0100 | <ski> | Milan_Vanca : btw, if you wanted to, you could factor out some common code from the two branches |
| 2026-02-25 19:38:40 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7955:9591:6018:7ef9) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-02-25 19:38:39 +0100 | <probie> | If you don't want to indent, you can always just use braces |
| 2026-02-25 19:38:29 +0100 | <haskellbridge> | <ijouw> let x = y in and let x = y have same rules reguarding where x may be. Everything y must be indented more than x. |
| 2026-02-25 19:37:20 +0100 | <ski> | (same rule holds for `of', and for `do', and `where') |
| 2026-02-25 19:36:34 +0100 | <ski> | (in Milan_Vanca's case, the block starts at `result') |
| 2026-02-25 19:36:14 +0100 | <ski> | yea .. the block starts at the first (non-comment) token *after* the layout-introducing keyword (here `let') |
| 2026-02-25 19:36:06 +0100 | <Milan_Vanca> | TY |
| 2026-02-25 19:36:02 +0100 | <Milan_Vanca> | Yeah thy guyz now I get it. :) |
| 2026-02-25 19:35:31 +0100 | <ski> | (iow, breaking line after `let', then you can indent the followin lines a little bit less) |
| 2026-02-25 19:35:27 +0100 | <__monty__> | Indentation in do-notation always trips me up. let ... in ... has no qualms with the definitions being less indented than the let. |
| 2026-02-25 19:35:04 +0100 | <ski> | Right ... -> ... |
| 2026-02-25 19:35:00 +0100 | <ski> | Left ... -> ... |
| 2026-02-25 19:34:53 +0100 | <ski> | result = case ... of |
| 2026-02-25 19:34:49 +0100 | <EvanR> | if you want to emphasize the case, indent all the way past the case |
| 2026-02-25 19:34:48 +0100 | <ski> | let |
| 2026-02-25 19:34:45 +0100 | <ski> | you *could* do |
| 2026-02-25 19:34:31 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:37b0:d42d:8afb:890) (Remote host closed the connection) |
| 2026-02-25 19:34:22 +0100 | <EvanR> | if you don't want to just indent more |
| 2026-02-25 19:34:08 +0100 | <EvanR> | either don't try to do this case inside a let, or put the case on one line |
| 2026-02-25 19:33:49 +0100 | <Milan_Vanca> | This let can define multiple things is ugly :D |
| 2026-02-25 19:33:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-02-25 19:33:42 +0100 | <ski> | to make it clear when the next defining equation inside `let' starts, and then (after this), when the whole `let' block ends |
| 2026-02-25 19:33:38 +0100 | <Milan_Vanca> | ski: :D This is ugly |
| 2026-02-25 19:33:15 +0100 | <ski> | Foo -> ... |