2026/02/25

Newest at the top

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 +0100bggd_(~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 +0100merijn(~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 -> ...
2026-02-25 19:33:13 +0100 <ski> anotherResult = case ... of
2026-02-25 19:33:11 +0100 <ski> Foo -> ...
2026-02-25 19:33:05 +0100 <ski> let result = case ... of
2026-02-25 19:32:59 +0100 <ski> for my example, you need to type
2026-02-25 19:32:46 +0100PaulMartensen(15a119e437@2001:bc8:1210:2cd8::3bc)
2026-02-25 19:32:24 +0100 <ski> yes
2026-02-25 19:32:24 +0100PaulMartensen(15a119e437@2001:bc8:1210:2cd8::3bc) (Ping timeout: 245 seconds)
2026-02-25 19:32:15 +0100 <ski> any line which is at *less* indentation than `result' ends the `let' block
2026-02-25 19:32:15 +0100 <EvanR> z = ...
2026-02-25 19:32:12 +0100 <EvanR> y = ...
2026-02-25 19:32:09 +0100 <EvanR> let x = ...
2026-02-25 19:32:01 +0100 <EvanR> yes
2026-02-25 19:31:59 +0100 <ski> any line which is at the same level of indentation as `result' is assumed to start a new defining equation, inside the `let'
2026-02-25 19:31:59 +0100 <Milan_Vanca> At once?
2026-02-25 19:31:50 +0100 <EvanR> Milan_Vanca, let lets you define multiple things
2026-02-25 19:31:15 +0100 <ski> Foo -> ...
2026-02-25 19:31:12 +0100 <ski> anotherResult = case ... of
2026-02-25 19:31:06 +0100 <ski> Foo -> ...
2026-02-25 19:30:59 +0100 <ski> let result = case ... of
2026-02-25 19:30:52 +0100 <ski> consider
2026-02-25 19:30:48 +0100 <ski> no
2026-02-25 19:30:42 +0100 <Milan_Vanca> I don't understand the problem with indentation. It has one more indentaion as "let" and that should be enough
2026-02-25 19:30:31 +0100 <ski> ah
2026-02-25 19:30:14 +0100 <Milan_Vanca> ski: I added bracket as I thought this is root of error..
2026-02-25 19:30:06 +0100 <EvanR> could you encode category theory
2026-02-25 19:29:47 +0100 <ski> .. also, instead of `... -> (...)', you can simply write `... -> ...' (extra brackets redundant)
2026-02-25 19:29:42 +0100 <EvanR> that is so much equality constraints now I'm imagining things to do with them
2026-02-25 19:29:15 +0100uli-fem(~uli-fem@118.210.1.123) (Ping timeout: 255 seconds)
2026-02-25 19:28:54 +0100 <ski> (one more than the `r' in `result')
2026-02-25 19:28:48 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-02-25 19:28:37 +0100 <ski> `Left' and `Right' must be indented at least three spaces more