Newest at the top
| 2025-02-02 04:58:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 04:53:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 04:49:37 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-02-02 04:42:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-02 04:38:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 04:30:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-02 04:29:02 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-02-02 04:27:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-02 04:26:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 04:23:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 04:16:33 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 248 seconds) |
| 2025-02-02 04:12:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 04:10:34 +0100 | <sim590> | I see. I guess I'll ignore it for now. |
| 2025-02-02 04:09:51 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-02-02 04:07:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 04:07:11 +0100 | <Leary> | sim590: Haddock (not GHC) warns about a lot of things, and many of them can't or shouldn't be fixed. Pick your battles and ignore the rest. |
| 2025-02-02 04:05:34 +0100 | op_4 | (~tslil@user/op-4/x-9116473) op_4 |
| 2025-02-02 04:05:04 +0100 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2025-02-02 04:02:36 +0100 | <sim590> | it "does", but it only documents the lens corresponding to the last field of the data type. |
| 2025-02-02 04:01:36 +0100 | <haskellbridge> | <Bowuigi> Does adding a Haddock comment above the TH invocation to generate lenses work? |
| 2025-02-02 03:52:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 03:45:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 03:43:20 +0100 | <sim590> | I'm exposing a bunch of lenses generated by haskell templates and GHC complains about lack of documentation for those. What's a common way to fix that? I can't document them if they're not in my file. Can I? |
| 2025-02-02 03:42:57 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-02-02 03:38:41 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 03:34:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 03:30:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 03:30:14 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::9939) |
| 2025-02-02 03:28:05 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::2163) (Ping timeout: 252 seconds) |
| 2025-02-02 03:22:56 +0100 | <haskellbridge> | <Bowuigi> Cedille has a nice way to handle rewrite rules. It uses equality proofs that erase to an identity function. Extra safety and speed at the cost of extra theorem proving (after all, if you are using a theorem prover it's because you want to prove theorems). Cedille doesn't seem to insert those automatically tho, you need explicit casts |
| 2025-02-02 03:19:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-02 03:14:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 03:04:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-02-02 02:59:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:58:57 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-02-02 02:55:21 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-02-02 02:50:56 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 02:48:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-02 02:43:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:42:14 +0100 | <monochrom> | :) |
| 2025-02-02 02:42:00 +0100 | <int-e> | I still remember when GCC broke Linux with agressive exploitation of signed overflows. |
| 2025-02-02 02:40:45 +0100 | <int-e> | Yeah C also blames the programmers for introducing undefined behavior into their code. |
| 2025-02-02 02:40:27 +0100 | <Leary> | But yeah, sadly too late for `Functor`. |
| 2025-02-02 02:39:46 +0100 | <Leary> | I'm placing the blame solidly on the unlawful instances, and claiming only /they/ introduce undefined behaviour. :) |
| 2025-02-02 02:39:41 +0100 | <int-e> | I'm not really opposed btw, except that it's hard to do this kind of thing after the fact. |
| 2025-02-02 02:37:25 +0100 | <int-e> | You're introducing undefined behavior. |
| 2025-02-02 02:36:21 +0100 | <int-e> | hmm but assuming properties doesn't enforce them, you're just shifting blame away from the compiler ;-) |
| 2025-02-02 02:33:54 +0100 | sprotte24 | (~sprotte24@p200300d16f174a005425e35c82ecf678.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-02-02 02:33:41 +0100 | <Leary> | `Functor` should have gotten this treatment. |
| 2025-02-02 02:33:34 +0100 | <Leary> | Break the law and GHC will punish you. >:) |