2026/01/03

Newest at the top

2026-01-03 18:38:41 +0100 <EvanR> just trace backwards where this nothing might have come from and see that it is ... nowhere
2026-01-03 18:38:36 +0100 <Milan_Vanca> EvanR: :( So true... My day to day job is with these dynamic languages.
2026-01-03 18:38:31 +0100wennefer0(~wennefer0@user/wennefer0) (Quit: My Mac has gone to sleep. ZZZzzz…)
2026-01-03 18:38:22 +0100 <EvanR> since you're dealing with a very specific algorithm, it is possible and somebody has probably done it 1000 times
2026-01-03 18:37:28 +0100 <Milan_Vanca> EvanR: This idea of proofing is interesting, but I am not proficient at math and cannot even imagine how could I proof that something will or won't happen. However I have a strong gut feeling :D
2026-01-03 18:37:25 +0100 <Leary> The problem with "this case is impossible anyway" is that you can be wrong, or code elsewhere can change that breaks it. When that happens, you will really want to see a runtime error that points precisely to the code that threw it, not a "*** Exception: Maybe.fromJust: Nothing" which could have come from anywhere.
2026-01-03 18:37:02 +0100 <EvanR> and somehow runs the world
2026-01-03 18:36:51 +0100 <EvanR> it sounds scary until you realize every line of dynamically typed code is using this mentality
2026-01-03 18:36:08 +0100 <monochrom> s/consume the chunk/consume the chunks/
2026-01-03 18:36:02 +0100 <Milan_Vanca> monochrom: Yeah agree this is nice solution, but MD5 says there must be padding. As operation is not defined on blocks of different length that 512
2026-01-03 18:36:00 +0100 <EvanR> sometimes the algorithm can be made more efficient at the expense of requiring a meticulous proof that some situations can't happen, not covered by the type system
2026-01-03 18:35:17 +0100 <monochrom> But in your example, I don't even have that dichotomy. Instead of pre-padding then expect well-padded, just go ahead consume the chunk and pad the last chunk when found.
2026-01-03 18:35:07 +0100 <Milan_Vanca> EvanR: Yeah it should be, I try to implement MD5 which pads messages to modulo 512. Then computes whole blocks. So it should not error as it would imply I padded wrong.
2026-01-03 18:35:05 +0100 <EvanR> not a runtime test
2026-01-03 18:34:59 +0100 <EvanR> but it's important to not delude yourself... which is why you need proof
2026-01-03 18:34:39 +0100 <EvanR> sometimes Nothing would be impossible
2026-01-03 18:34:10 +0100 <Milan_Vanca> monochrom: This is great idea! I should ask this question more often when programming.
2026-01-03 18:33:45 +0100 <EvanR> Milan_Vanca, true, it is pointless to use a Maybe, pattern match and then throw an error. Unless you want to change the error message in case the impossible happens. The failure case is impossible right?
2026-01-03 18:32:40 +0100 <monochrom> I work backwards. If the impossible happens, do I have a plan B for the program to continue working (is it even required?), or should it just crash and I just fix the bug and move on?
2026-01-03 18:32:25 +0100merijn(~merijn@62.45.136.136) (Ping timeout: 245 seconds)
2026-01-03 18:31:37 +0100 <Milan_Vanca> Leary: Would you still use total function and pattern match on Nothing and then throw error?
2026-01-03 18:30:47 +0100 <Milan_Vanca> How wouuld you guyz approach this problem. Imagine I have list of elements of arbitrary length. I pad it so it is multiple of 512. Now I try to consume this list by chunks of 512. I am tempted to use partial function for consuming as it should not be possible to have non mod 512 lenght. If padding is correct error can't happen.
2026-01-03 18:27:40 +0100merijn(~merijn@62.45.136.136) merijn
2026-01-03 18:26:28 +0100 <Milan_Vanca> Leary: hmm so no other use of partial? Interesting.
2026-01-03 18:25:44 +0100peterbecich(~Thunderbi@71.84.33.135) peterbecich
2026-01-03 18:25:39 +0100 <Leary> Milan_Vanca: The only partial function I use often is `error`. It's usually worth writing your own error messages, since the generic ones tend not to be very helpful.
2026-01-03 18:22:41 +0100 <Milan_Vanca> So basically when you feel/decide it is not worth it.
2026-01-03 18:21:40 +0100Inline(~User@cgn-195-14-221-74.nc.de) (Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/)
2026-01-03 18:21:30 +0100spew(~spew@user/spew) spew
2026-01-03 18:21:18 +0100 <monochrom> I use partial functions when it becomes over-engineering to make them total.
2026-01-03 18:19:55 +0100Lycurgus(~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org ))
2026-01-03 18:19:51 +0100 <Milan_Vanca> Or is it good practise to always think about all possible branches and explicitly document them? Even when they could not possibly be evaluated at runtime?
2026-01-03 18:18:59 +0100 <Milan_Vanca> Hello :), do you use partial functions? I get that it is unsafe and may lead to runtime errors, but it feels pointles to use function that produces Maybe then pattern match on Nothing and throw my own error.
2026-01-03 18:16:49 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-01-03 18:16:42 +0100Milan_Vanca(~milan@user/Milan-Vanca:32634) Milan_Vanca
2026-01-03 18:14:23 +0100Milan_Vanca(~Milan_Van@user/Milan-Vanca:32634) ()
2026-01-03 18:13:55 +0100Milan_Vanca(~Milan_Van@user/Milan-Vanca:32634) Milan_Vanca
2026-01-03 18:11:47 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-03 18:04:29 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2026-01-03 17:57:47 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-03 17:54:54 +0100Lycurgus(~juan@user/Lycurgus) Lycurgus
2026-01-03 17:54:50 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2026-01-03 17:49:32 +0100vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-01-03 17:49:12 +0100ttybitnik(~ttybitnik@user/wolper) ttybitnik
2026-01-03 17:49:05 +0100machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2026-01-03 17:46:43 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-01-03 17:42:16 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-01-03 17:34:48 +0100Motok(~moto@user/Motok) (Remote host closed the connection)
2026-01-03 17:31:19 +0100merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-01-03 17:31:13 +0100bb010g(~bb010g@wank.party) bb010g