Newest at the top
| 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. >:) |
| 2025-02-02 02:33:18 +0100 | <Leary> | Mmmm. Getting to write meaningful rewrite RULES is a rare and special joy, isn't it? Even better, to give a typeclass laws and declare /these laws are **enforced** by rewrite @RULES@/ in the haddocks! |
| 2025-02-02 02:32:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-02 02:27:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:22:24 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 260 seconds) |
| 2025-02-02 02:20:42 +0100 | olivial_ | (~benjaminl@2601:1c0:847f:9c70:223:24ff:fe66:4370) |
| 2025-02-02 02:19:55 +0100 | otto_s | (~user@p5b0441a3.dip0.t-ipconnect.de) |
| 2025-02-02 02:18:19 +0100 | otto_s | (~user@p5b0448ee.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-02-02 02:17:09 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-02-02 02:16:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 02:15:46 +0100 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2025-02-02 02:12:08 +0100 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb2+b2 - https://znc.in) |
| 2025-02-02 02:09:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 02:09:33 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f12b860008857e92372.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-02-02 02:07:46 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-02-02 02:07:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-02 02:06:16 +0100 | olivial | (~benjaminl@user/benjaminl) (Remote host closed the connection) |
| 2025-02-02 02:03:12 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-02 02:01:12 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-02 02:00:29 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-02-02 01:58:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-02-02 01:54:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:53:15 +0100 | monochrm | monochrom |
| 2025-02-02 01:53:11 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 244 seconds) |
| 2025-02-02 01:52:40 +0100 | monochrm | (trebla@216.138.220.146) |
| 2025-02-02 01:48:08 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) (Remote host closed the connection) |
| 2025-02-02 01:45:03 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-02 01:43:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 01:39:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-02 01:32:16 +0100 | <monochrom> | Like even in C if I don't want sin() to mess with my array then just don't give it [the address of] my array, done. |
| 2025-02-02 01:31:14 +0100 | <monochrom> | I suspect that "block access" means something that has nothing to do with "block" or "access" because supposedly everyone already knows that if you don't want a certain function to use a certain argument then just don't have that argument in the first place, so why the question. |
| 2025-02-02 01:29:17 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Client Quit) |
| 2025-02-02 01:28:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-02 01:24:39 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |