IRCBrowse

2023/05/30

2023-05-30 00:00:47 +0200acidjnk(~acidjnk@p200300d6e7072f02f87078db41c940f7.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-05-30 00:01:35 +0200gurkenglas(~user@dynamic-046-114-182-030.46.114.pool.telefonica.de) (Ping timeout: 250 seconds)
2023-05-30 00:12:25 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 240 seconds)
2023-05-30 00:25:35 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-05-30 00:28:26 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-05-30 00:33:31 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-30 00:33:59 +0200oo_miguel(~Thunderbi@77.252.47.84) (Ping timeout: 240 seconds)
2023-05-30 00:36:38 +0200nate2(~nate@98.45.169.16)
2023-05-30 00:38:20 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-05-30 00:41:27 +0200nate2(~nate@98.45.169.16) (Ping timeout: 250 seconds)
2023-05-30 00:49:55 +0200nick___(~nick@2600:8807:9086:5b00:5c2d:3478:2903:1245)
2023-05-30 00:50:08 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds)
2023-05-30 00:57:25 +0200nick___(~nick@2600:8807:9086:5b00:5c2d:3478:2903:1245) (Ping timeout: 265 seconds)
2023-05-30 01:00:12 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 01:00:17 +0200 <EvanR> cheater, so like dependently typed hoogle
2023-05-30 01:00:29 +0200 <cheater> i don't know
2023-05-30 01:01:21 +0200 <EvanR> I wonder if chat-gpt could be used for this unironically
2023-05-30 01:13:36 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds)
2023-05-30 01:16:45 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 240 seconds)
2023-05-30 01:19:34 +0200mauke_(~mauke@user/mauke)
2023-05-30 01:20:47 +0200mauke(~mauke@user/mauke) (Ping timeout: 240 seconds)
2023-05-30 01:20:47 +0200mauke_mauke
2023-05-30 01:26:05 +0200thegeekinside(~thegeekin@189.180.18.187) (Ping timeout: 250 seconds)
2023-05-30 01:26:49 +0200 <cheater> ewwww
2023-05-30 01:28:16 +0200thegeekinside(~thegeekin@189.180.19.71)
2023-05-30 01:28:17 +0200mechap(~mechap@user/mechap) (Quit: WeeChat 3.8)
2023-05-30 01:31:18 +0200cheater_(~Username@user/cheater)
2023-05-30 01:33:10 +0200_xor(~xor@nw-esr1-72-49-97-201.fuse.net)
2023-05-30 01:33:53 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-30 01:34:03 +0200cheater_cheater
2023-05-30 01:42:18 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-05-30 01:42:18 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-05-30 01:42:18 +0200wroathe(~wroathe@user/wroathe)
2023-05-30 01:43:31 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-30 01:44:01 +0200mei(~mei@user/mei) (Ping timeout: 240 seconds)
2023-05-30 01:50:13 +0200cheater_(~Username@user/cheater)
2023-05-30 01:50:24 +0200Xe(~cadey@tailscale/xe) (Quit: WeeChat 3.8)
2023-05-30 01:52:00 +0200cheater(~Username@user/cheater) (Ping timeout: 248 seconds)
2023-05-30 01:52:03 +0200machinedgod(~machinedg@93-136-113-216.adsl.net.t-com.hr)
2023-05-30 01:52:08 +0200cheater_cheater
2023-05-30 02:07:59 +0200machinedgod(~machinedg@93-136-113-216.adsl.net.t-com.hr) (Ping timeout: 240 seconds)
2023-05-30 02:08:03 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-30 02:12:27 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 250 seconds)
2023-05-30 02:16:43 +0200ryanbooker(uid4340@id-4340.hampstead.irccloud.com)
2023-05-30 02:20:07 +0200machinedgod(~machinedg@93-136-113-216.adsl.net.t-com.hr)
2023-05-30 02:20:49 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-05-30 02:25:02 +0200EllenorAmyMalik
2023-05-30 02:29:12 +0200Guest13(~Guest13@250.79-105-213.static.virginmediabusiness.co.uk)
2023-05-30 02:29:21 +0200 <Guest13> hi, i managed to construct a code example of the problem i was asking before
2023-05-30 02:29:36 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:6c9c:9af5:8708:5fc6)
2023-05-30 02:29:56 +0200 <Guest13> i was wondering if anyone could tell if it works by looking, since i dont really want to have to profile it to see if the bang pattern is doing what i think it should
2023-05-30 02:30:19 +0200 <Guest13> https://paste.tomsmeding.com/qnT5pH7j
2023-05-30 02:31:05 +0200machinedgod(~machinedg@93-136-113-216.adsl.net.t-com.hr) (Ping timeout: 250 seconds)
2023-05-30 02:33:32 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:6c9c:9af5:8708:5fc6) (Remote host closed the connection)
2023-05-30 02:34:09 +0200 <Guest13> fr is used twice, but the hope is that the internal randoms are only computed once
2023-05-30 02:35:38 +0200 <Guest13> and if this approach seems well structured, in order to avoid the recomputation
2023-05-30 02:36:18 +0200 <Guest13> (opted for a continuation in the end, rather than Reader monad which seems no better than this kind of encapsulated version in the way monochrom advised)
2023-05-30 02:37:13 +0200 <Guest13> i actually quite like the way a bang pattern in a continuation seems like it manages to achieve this
2023-05-30 02:37:24 +0200 <Guest13> but i cant actually tell if does! can anyone take a look for me?
2023-05-30 02:40:04 +0200 <[Leary]> Guest13: So you just want `rs` to be shared? I don't think the bang pattern will do anything, but you can just change the definition to `withRandoms (chunkLength, nLayers) = \f -> f rs`.
2023-05-30 02:40:50 +0200 <[Leary]> I don't see any good reason for the continuation there, however; you may as well just return `rs` directly.
2023-05-30 02:40:55 +0200 <Guest13> ... basically rs should only be computed once
2023-05-30 02:41:21 +0200 <Guest13> i dont want to reexplain the motivation which we covered yesterday
2023-05-30 02:41:57 +0200 <Guest13> the idea is basically that the continuation and this withRandoms function offers the user a way to encapsulate the strictly evaluated value
2023-05-30 02:42:23 +0200 <Guest13> something like a "global environment" which Reader monad is used for
2023-05-30 02:42:42 +0200 <Guest13> but i find the continuation paradigm easier to work with and rationalise
2023-05-30 02:43:05 +0200 <Guest13> why do you think the bang pattern would fail?
2023-05-30 02:43:40 +0200 <Guest13> an "immutable global environment"
2023-05-30 02:44:10 +0200 <Guest13> since all Reader was doing was hiding a partial application, the continuation way seems to do the same but clearer
2023-05-30 02:44:18 +0200 <int-e> Guest13: that bang pattern has no effect
2023-05-30 02:44:34 +0200 <Guest13> so fr will recalculate the randoms each time it is called?
2023-05-30 02:45:25 +0200nate2(~nate@98.45.169.16)
2023-05-30 02:45:29 +0200 <int-e> You're at the compiler's mercy here to realize that it's computing the exact same thing twice, namely `fr randomSupport`.
2023-05-30 02:45:29 +0200 <Guest13> or would it somehow manage to do what its supposed to even without the !
2023-05-30 02:46:00 +0200 <int-e> As [Leary] said, the CPS is not doing anything useful here.
2023-05-30 02:46:21 +0200 <Guest13> int-e: i could have given it randomSupport' for the second call, fr should still store !rs
2023-05-30 02:46:50 +0200 <Guest13> regardless of what fr is applied to, i want it to somehow store the computed rs
2023-05-30 02:47:32 +0200 <Guest13> int-e: monochrom was saying Reader achieves dependency injection in the same way as partial application
2023-05-30 02:47:54 +0200 <Guest13> so im just partially applying the first argument, which gives a continuation
2023-05-30 02:48:24 +0200 <Guest13> its just a form to work with that is comprehensible, i dont expect it to force the evaluation like the ! should or anything special
2023-05-30 02:49:37 +0200 <Guest13> i guess its the partial application itself that i expect to somehow be able to make strict in its applied argument
2023-05-30 02:50:50 +0200 <Guest13> so maybe it should just work without the bang pattern as i expect it should
2023-05-30 02:50:52 +0200 <int-e> Well, apparently GHC's optimizations are smart enough to figure this out in this case. It's not at all obvious from reading the code that this will happen.
2023-05-30 02:51:01 +0200dcleonarski(~user@2804:d51:4793:c800:b0e2:a2e8:89a0:4c46) (Remote host closed the connection)
2023-05-30 02:51:03 +0200 <Guest13> damn
2023-05-30 02:51:08 +0200 <Guest13> thanks tho
2023-05-30 02:51:35 +0200 <[Leary]> Skimming the backlog, what was wrong with MonadRandom? Isn't it exactly what you want?
2023-05-30 02:51:41 +0200 <Guest13> not at all
2023-05-30 02:52:01 +0200 <Guest13> iiuc thats for handling the seed behind the scenes
2023-05-30 02:52:09 +0200 <Guest13> while this stores all the randoms behind the scenes
2023-05-30 02:52:27 +0200 <Guest13> and while the seed changes, like State. these randoms are fixed, like Reader
2023-05-30 02:53:13 +0200 <int-e> If, on the other hand, you had `withRandoms :: (Int,Int) -> Randoms` then the compiler would not have to be clever. Or, if the goal were to actually recompute the `rs` twice, {-# NOINLINE withRandoms #-} seems to accomplish that.
2023-05-30 02:53:30 +0200 <int-e> Sorry, I meant to name that first function `makeRandoms`
2023-05-30 02:53:48 +0200chanceyan(~chanceyan@user/chanceyan)
2023-05-30 02:53:54 +0200 <[Leary]> In Haskell's lazy/streaming context, there's no real difference between unfolding with a seed and reading from a list unfolded from a seed.
2023-05-30 02:53:56 +0200 <int-e> And I can't count either. (compute twice, recompute nonce)
2023-05-30 02:54:00 +0200 <int-e> *once
2023-05-30 02:54:10 +0200 <Guest13> so id have to tell it explicitly *to* recompute it, rather than the other way round
2023-05-30 02:54:36 +0200chanceyan(~chanceyan@user/chanceyan) (Client Quit)
2023-05-30 02:54:56 +0200 <int-e> Guest13: how did I figure this out? I used `rs = trace "Foo" $ Randoms chunkLength nLayers (createRandomSupport chunkLength nLayers)` where `trace` comes from Debug.Trace
2023-05-30 02:55:32 +0200 <Guest13> can you paste the code?
2023-05-30 02:55:56 +0200 <int-e> no, I deleted it already
2023-05-30 02:56:21 +0200 <Guest13> ok, ill try to recreate from your snippet
2023-05-30 02:56:45 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 240 seconds)
2023-05-30 02:57:49 +0200 <Guest13> hmm, if i just put the trace "Foo" in the computation of rs, it only prints Foo at the start, so it must be doing it correctly
2023-05-30 02:58:14 +0200 <Guest13> even with the bang pattern removed like you suggested
2023-05-30 02:58:25 +0200 <int-e> Guest13: but only if you use -O
2023-05-30 02:58:47 +0200 <Guest13> im just using cabal v2-run without -O
2023-05-30 02:58:59 +0200 <Guest13> wow its faster with -O
2023-05-30 02:59:16 +0200 <int-e> while with `makeRandoms` you wouldn't have to rely on the compiler for this
2023-05-30 03:00:23 +0200 <Guest13> hmm, strange
2023-05-30 03:04:49 +0200 <Guest13> https://paste.tomsmeding.com/vPefbu5f
2023-05-30 03:05:06 +0200 <Guest13> i guess its slightly less strange looking without the CPS
2023-05-30 03:05:10 +0200 <Guest13> thanks
2023-05-30 03:05:45 +0200 <[Leary]> By they way, you might actually /want/ to be recomputing these randoms. Generating them is definitely cheap, but storing them might not be.
2023-05-30 03:06:51 +0200 <Guest13> !!!
2023-05-30 03:06:56 +0200 <Guest13> thats the worst news ever!
2023-05-30 03:07:16 +0200 <Guest13> as if its cheaper to recalculate than store
2023-05-30 03:07:24 +0200 <Guest13> i guess i should get criterion on this...
2023-05-30 03:09:48 +0200 <Guest13> even with the chunking?
2023-05-30 03:10:13 +0200 <Guest13> i guess if i did that on the fly it would be faster...
2023-05-30 03:10:27 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-30 03:11:18 +0200 <Guest13> isnt the point that storing them is 0 cheap or am i just a fool...
2023-05-30 03:11:35 +0200 <Guest13> like, it would have to opperate on a stored version anyway
2023-05-30 03:11:43 +0200 <Guest13> you just save regenerating that stored version
2023-05-30 03:12:22 +0200 <int-e> it's not simply stored; GC will move the data around, and even without GC you'd be putting extra burden on the caches
2023-05-30 03:12:26 +0200 <[Leary]> Storing something that's expensive to compute, but small enough to fit in cache is a big win. Storing something that's cheap to compute but big enough to need RAM access often isn't.
2023-05-30 03:13:11 +0200 <Guest13> i get what your saying, but, what i was saying is that it would have to go into ram if it was that big anyway
2023-05-30 03:13:24 +0200 <Guest13> its not like im doing anything where build fold fusion would kick in
2023-05-30 03:13:47 +0200 <Guest13> like if i was consumeing the values as they were produced, but it doesnt, it has to have the whole object before it can overlap all the chunks
2023-05-30 03:14:03 +0200 <int-e> fusion is excellent, but the power of laziness is that you can consume data as it's produced even without fusion
2023-05-30 03:14:18 +0200 <int-e> not for free either
2023-05-30 03:14:36 +0200 <int-e> profiling is really the only way to figure these trade-offs out
2023-05-30 03:14:42 +0200phma(phma@2001:5b0:2172:dd28:7911:911:8af7:7b23) (Read error: Connection reset by peer)
2023-05-30 03:14:47 +0200 <Guest13> criterion is still building
2023-05-30 03:14:50 +0200 <Guest13> ...
2023-05-30 03:15:08 +0200phma(phma@2001:5b0:2172:dd28:3b22:598:a9f4:e4a5)
2023-05-30 03:15:31 +0200 <Guest13> right, but im consuming the end of the long list with the earlier elements
2023-05-30 03:15:57 +0200 <Guest13> i guess if i changed the order so it folded up lists, like transposing the chunks...
2023-05-30 03:16:10 +0200 <Guest13> but then it would have to make loads of copies of the coeffecients
2023-05-30 03:16:20 +0200zaquest(~notzaques@5.130.79.72)
2023-05-30 03:16:35 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-30 03:16:49 +0200 <Guest13> map (zipWith (*) coeffecients) . transpose . chunks
2023-05-30 03:16:55 +0200lav(~pi@wikipedia/maddy-from-celeste) (Ping timeout: 260 seconds)
2023-05-30 03:17:24 +0200 <Guest13> but like, obviously if you want to use the lazy or fusion thing you dont implement the transposed chunks like that
2023-05-30 03:18:01 +0200 <Guest13> probably this also depends on the length of the supported vector, and the number of random support vectors used
2023-05-30 03:18:07 +0200 <int-e> also if you figure that you want to store the values, consider using a vector instead of a list... that'll give you better memory efficiency and random access
2023-05-30 03:18:11 +0200Xe(~cadey@tailscale/xe)
2023-05-30 03:18:27 +0200 <int-e> (O(1) random access that is)
2023-05-30 03:18:30 +0200 <Guest13> yeah, your right, if this is supposed to be the fast version
2023-05-30 03:18:40 +0200 <Guest13> would you be able to help me write that?
2023-05-30 03:19:05 +0200 <Guest13> i hate using vectors...
2023-05-30 03:19:39 +0200 <Guest13> my code production rate is so low nowerdays i cant really afford to clunk up the code
2023-05-30 03:20:24 +0200 <Guest13> i used to be able to write for like 3 days without sleep but since i started working out, i can hardly type a sentence without getting exhausted
2023-05-30 03:21:07 +0200 <Guest13> (a tall order)
2023-05-30 03:23:05 +0200 <Guest13> i might just do it in the slowest way possible instead!
2023-05-30 03:23:10 +0200 <Guest13> so lazy..
2023-05-30 03:23:39 +0200 <int-e> but then why do you worry about sharing :P
2023-05-30 03:23:53 +0200lav(~pi@wikipedia/maddy-from-celeste)
2023-05-30 03:24:24 +0200 <Guest13> i thought that was the only optimization i needed
2023-05-30 03:24:30 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:6c9c:9af5:8708:5fc6)
2023-05-30 03:24:34 +0200 <Guest13> im not sure Vectors would help even
2023-05-30 03:24:39 +0200 <Guest13> since all the values are consumed
2023-05-30 03:24:54 +0200 <Guest13> and there is a way of producing them where they would be consumed in the order they were produced
2023-05-30 03:25:24 +0200 <Guest13> like, i assume zipWith for the coefficients is basically a parallel fold
2023-05-30 03:25:42 +0200 <Guest13> not sure where random access would enter the picture
2023-05-30 03:26:11 +0200 <Guest13> its not faster than a list in that case is it?
2023-05-30 03:26:35 +0200 <int-e> If you consume as you produce then vectors won't pay off indeed.
2023-05-30 03:26:46 +0200thegeekinside(~thegeekin@189.180.19.71) (Ping timeout: 265 seconds)
2023-05-30 03:26:55 +0200 <Guest13> ok great, thats some overhead i can avoid
2023-05-30 03:26:58 +0200 <int-e> But then you probably also should not be sharing that big list of lists of pseudorandom numbers.
2023-05-30 03:27:17 +0200 <Guest13> yeah, thats the thing thats worth profiling to discover
2023-05-30 03:28:06 +0200thegeekinside(~thegeekin@189.180.43.189)
2023-05-30 03:28:08 +0200 <Guest13> oh, that and the transpose thing.
2023-05-30 03:28:23 +0200 <Guest13> im going to take a rest and see if i can conquer this
2023-05-30 03:28:57 +0200 <int-e> the transpose is why I thought of random access
2023-05-30 03:29:55 +0200 <int-e> but if you can reorder the pseudo-random numbers, you could also work directly with m chunks of length n instead of n chunks of length m
2023-05-30 03:30:23 +0200 <Guest13> oh i see what you meant now
2023-05-30 03:30:39 +0200 <int-e> > (chunksOf 2 [1..12], chunksOf 5 [1..12])
2023-05-30 03:30:41 +0200 <lambdabot> ([[1,2],[3,4],[5,6],[7,8],[9,10],[11,12]],[[1,2,3,4,5],[6,7,8,9,10],[11,12]])
2023-05-30 03:30:53 +0200vandita(~vandit@94-21-131-99.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-30 03:30:58 +0200 <int-e> oops, that 5 was meant to be a 6
2023-05-30 03:31:18 +0200 <Guest13> > (chunksOf 2 [1..12], chunksOf 6 [1..12])
2023-05-30 03:31:19 +0200 <lambdabot> ([[1,2],[3,4],[5,6],[7,8],[9,10],[11,12]],[[1,2,3,4,5,6],[7,8,9,10,11,12]])
2023-05-30 03:31:45 +0200 <int-e> if you only consider the shape, the second looks like a transposition of the first result
2023-05-30 03:32:04 +0200 <Guest13> yeah, and given they are random numbers anyway it shouldnt matter
2023-05-30 03:32:06 +0200 <int-e> but you get the 12 numbers in a different order
2023-05-30 03:32:30 +0200 <int-e> and only you know whether that matters
2023-05-30 03:32:33 +0200vandita(~vandit@213-197-76-99.pool.digikabel.hu)
2023-05-30 03:32:51 +0200 <Guest13> well as long as its the same each time then it should work as a support
2023-05-30 03:33:19 +0200 <Guest13> its interesting how this came about
2023-05-30 03:33:31 +0200 <Guest13> basically i had a mixture of matrix model
2023-05-30 03:33:45 +0200 <Guest13> where the outputs were combined with coeffecients
2023-05-30 03:33:52 +0200 <Guest13> and since matricies are linear opperators
2023-05-30 03:34:09 +0200 <Guest13> this is the same as combining the matricies with these coefficients
2023-05-30 03:34:40 +0200 <Guest13> and then, i think its redundant to sum the randomly supported matricies
2023-05-30 03:34:59 +0200 <Guest13> unless the two orthogonal coefficients is better for learning....
2023-05-30 03:35:23 +0200 <Guest13> like, the coefs for the random supports of each matrix, and the coefs for combining these together
2023-05-30 03:35:39 +0200 <Guest13> i guess there is an n-ary version of this
2023-05-30 03:35:53 +0200 <Guest13> which if it does indeed help during learning, could be really powerful
2023-05-30 03:36:01 +0200 <Guest13> does that make sense?
2023-05-30 03:36:30 +0200 <Guest13> i wish i could get someone to help me write this code, i feel like i forgot how to type
2023-05-30 03:38:27 +0200 <Guest13> i think im gona call it a night tbh
2023-05-30 03:38:32 +0200 <Guest13> thanks for the help
2023-05-30 03:39:25 +0200thegeekinside(~thegeekin@189.180.43.189) (Ping timeout: 240 seconds)
2023-05-30 03:40:57 +0200thegeekinside(~thegeekin@189.180.105.132)
2023-05-30 03:43:01 +0200Guest13(~Guest13@250.79-105-213.static.virginmediabusiness.co.uk) (Quit: Connection closed)
2023-05-30 03:47:35 +0200thegeekinside(~thegeekin@189.180.105.132) (Ping timeout: 240 seconds)
2023-05-30 03:47:53 +0200thegeekinside(~thegeekin@189.180.41.85)
2023-05-30 03:47:53 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection)
2023-05-30 03:48:48 +0200nate2(~nate@98.45.169.16) (Ping timeout: 248 seconds)
2023-05-30 03:50:55 +0200thegeekinside(~thegeekin@189.180.41.85) (Remote host closed the connection)
2023-05-30 03:51:18 +0200thegeekinside(~thegeekin@189.180.41.85)
2023-05-30 03:53:59 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 03:57:52 +0200thegeekinside(~thegeekin@189.180.41.85) (Ping timeout: 248 seconds)
2023-05-30 03:58:15 +0200TonyStone(~TonyStone@cpe-74-76-57-186.nycap.res.rr.com)
2023-05-30 03:58:30 +0200thegeekinside(~thegeekin@189.180.42.214)
2023-05-30 04:01:36 +0200xff0x(~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 248 seconds)
2023-05-30 04:08:21 +0200monochrom(trebla@216.138.220.146) (Ping timeout: 256 seconds)
2023-05-30 04:10:35 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection)
2023-05-30 04:10:58 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 04:17:54 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-30 04:25:03 +0200scrungus(~scrungus@bras-base-aurron9127w-grc-63-70-24-87-21.dsl.bell.ca)
2023-05-30 04:33:15 +0200scrungus(~scrungus@bras-base-aurron9127w-grc-63-70-24-87-21.dsl.bell.ca) (Quit: WeeChat 3.8)
2023-05-30 04:40:21 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection)
2023-05-30 04:40:45 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 04:42:52 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-05-30 04:44:26 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-05-30 04:44:52 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-05-30 04:45:33 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-05-30 04:45:33 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-05-30 04:45:33 +0200finn_elijaFinnElija
2023-05-30 04:46:02 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-05-30 04:59:31 +0200td_(~td@i53870935.versanet.de) (Ping timeout: 240 seconds)
2023-05-30 05:01:22 +0200td_(~td@i53870907.versanet.de)
2023-05-30 05:15:06 +0200trev(~trev@user/trev)
2023-05-30 05:18:46 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-30 05:18:54 +0200falafel(~falafel@2603-8000-d700-115c-baeb-e94d-8eca-e244.res6.spectrum.com)
2023-05-30 05:18:59 +0200gry(quasselcor@botters/gry) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-05-30 05:19:01 +0200falafel(~falafel@2603-8000-d700-115c-baeb-e94d-8eca-e244.res6.spectrum.com) (Remote host closed the connection)
2023-05-30 05:20:30 +0200gry(quasselcor@2400:c400:1002:11:5054:ff:fe78:ebe6)
2023-05-30 05:23:44 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 265 seconds)
2023-05-30 05:27:07 +0200Sciencentistguy5(~sciencent@hacksoc/ordinary-member)
2023-05-30 05:29:11 +0200Sciencentistguy(~sciencent@hacksoc/ordinary-member) (Ping timeout: 240 seconds)
2023-05-30 05:29:11 +0200Sciencentistguy5Sciencentistguy
2023-05-30 05:30:35 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:6c9c:9af5:8708:5fc6) (Remote host closed the connection)
2023-05-30 05:33:29 +0200gry(quasselcor@2400:c400:1002:11:5054:ff:fe78:ebe6) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-05-30 05:35:42 +0200gry(quasselcor@botters/gry)
2023-05-30 05:40:54 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 250 seconds)
2023-05-30 05:42:11 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 250 seconds)
2023-05-30 05:44:23 +0200danso_odanso
2023-05-30 05:45:39 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 05:47:25 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 265 seconds)
2023-05-30 06:06:31 +0200ryanbooker(uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
2023-05-30 06:08:04 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-30 06:08:30 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2023-05-30 06:11:39 +0200zaquest(~notzaques@5.130.79.72) (Ping timeout: 250 seconds)
2023-05-30 06:12:25 +0200ystael(~ystael@user/ystael) (Ping timeout: 240 seconds)
2023-05-30 06:24:31 +0200zaquest(~notzaques@5.130.79.72)
2023-05-30 06:36:05 +0200notzmv(~zmv@user/notzmv)
2023-05-30 06:38:39 +0200vandita(~vandit@213-197-76-99.pool.digikabel.hu) (Ping timeout: 265 seconds)
2023-05-30 06:40:02 +0200vandita(~vandit@84-236-1-110.pool.digikabel.hu)
2023-05-30 06:46:05 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 246 seconds)
2023-05-30 06:47:48 +0200shapr(~user@2600:1700:c640:3100:6ac8:cf17:6356:ff5f) (Ping timeout: 240 seconds)
2023-05-30 06:51:46 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 06:53:13 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-05-30 07:02:36 +0200monochrom(trebla@216.138.220.146)
2023-05-30 07:08:11 +0200monochrom(trebla@216.138.220.146) (Quit: NO CARRIER)
2023-05-30 07:10:05 +0200_xor(~xor@nw-esr1-72-49-97-201.fuse.net) (Quit: brb/bbiab)
2023-05-30 07:16:08 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 07:19:22 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-05-30 07:28:06 +0200monochrom(trebla@216.138.220.146)
2023-05-30 07:31:11 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-05-30 07:34:31 +0200redmp(~redmp@mobile-166-171-249-80.mycingular.net)
2023-05-30 07:35:09 +0200 <redmp> hi, I'm using "-threaded" and make calls to "threadDelay", but I'm on an exotic machine and these calls fail with an error I've not seen before. I'll paste it.
2023-05-30 07:36:07 +0200 <redmp> it's only one line: "main: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:216:3-10)"
2023-05-30 07:36:30 +0200 <redmp> This seems to indicate a problem in https://hackage.haskell.org/package/base-4.15.1.0/docs/src/GHC-Event-Thread.html (I'm using GHC 9.0.2)
2023-05-30 07:36:58 +0200 <redmp> I looked at the line, and indeed, it's doing "Just mgr <- readIORef timerManager"
2023-05-30 07:37:46 +0200 <redmp> Googling around indicated that this might be due to forgetting the "-threaded" option so I double checked by running my executable with "+RTS -info" and its "way" is indeed rts_thr
2023-05-30 07:38:24 +0200 <redmp> Short of debugging Thread.hs, I'm not sure what to try next
2023-05-30 07:47:12 +0200d34df00d(~d34df00d@2600:1702:4f1b:7c10::f) (Ping timeout: 248 seconds)
2023-05-30 08:17:04 +0200shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 248 seconds)
2023-05-30 08:17:49 +0200emmanuelux_(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-05-30 08:34:39 +0200cfricke(~cfricke@user/cfricke)
2023-05-30 08:41:08 +0200acidjnk(~acidjnk@p200300d6e7072f08c511281507bd955a.dip0.t-ipconnect.de)
2023-05-30 08:42:53 +0200vandita(~vandit@84-236-1-110.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-30 08:44:26 +0200vandita(~vandit@84-236-21-17.pool.digikabel.hu)
2023-05-30 08:53:20 +0200ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-05-30 09:00:58 +0200ec(~ec@gateway/tor-sasl/ec)
2023-05-30 09:04:12 +0200 <Axman6> redmp: that might be an appropriate question for #ghc. what exotic machine are you running on?
2023-05-30 09:05:01 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:bd3c:70d:4e85:6e2b)
2023-05-30 09:10:05 +0200Guest70(~Guest75@176.122.87.241)
2023-05-30 09:10:17 +0200 <Guest70> hello
2023-05-30 09:11:02 +0200 <Axman6> o/
2023-05-30 09:12:45 +0200 <Guest70> i have ng network
2023-05-30 09:12:47 +0200 <Guest70> https://pastecode.io/s/um3dwcay
2023-05-30 09:13:11 +0200 <Guest70> i have jail with vnet on ngeth0
2023-05-30 09:14:54 +0200 <Guest70> after enabling ipfw on the host i automatically get the rule in jail "65535 deny ip from any to any"
2023-05-30 09:15:11 +0200 <Axman6> does this have anything to do with Haskell?
2023-05-30 09:15:23 +0200 <Guest70> sorry!
2023-05-30 09:15:41 +0200 <Guest70> my mistake
2023-05-30 09:15:49 +0200 <Axman6> All good, good luck!
2023-05-30 09:15:56 +0200 <Guest70> not that channel
2023-05-30 09:16:18 +0200Guest70(~Guest75@176.122.87.241) (Quit: Client closed)
2023-05-30 09:16:43 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-05-30 09:16:48 +0200 <probie> I wonder if there's any haskell library to manage pf rules
2023-05-30 09:17:26 +0200 <Axman6> I hope so, I always find them somewhat painful to write, needs moar types
2023-05-30 09:25:57 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-30 09:26:57 +0200titibandit(~titibandi@user/titibandit)
2023-05-30 09:36:53 +0200Guest49(~Guest75@176.122.87.241)
2023-05-30 09:37:56 +0200Guest49(~Guest75@176.122.87.241) (Client Quit)
2023-05-30 09:42:44 +0200hisa382(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net)
2023-05-30 09:44:44 +0200hisa38(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 265 seconds)
2023-05-30 09:44:44 +0200hisa382hisa38
2023-05-30 09:50:56 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds)
2023-05-30 09:51:24 +0200chomwitt(~chomwitt@2a02:587:7a16:6700:1ac0:4dff:fedb:a3f1)
2023-05-30 09:52:18 +0200 <Hecate> pf <3
2023-05-30 09:53:14 +0200gurkenglas(~user@dynamic-046-114-181-050.46.114.pool.telefonica.de)
2023-05-30 09:55:42 +0200Guest39(~Guest75@176.122.87.241)
2023-05-30 09:57:27 +0200Guest39cr4zsci
2023-05-30 10:07:17 +0200oneeyedalien(~oneeyedal@125-63-26-100.ip4.superloop.au)
2023-05-30 10:07:40 +0200oneeyedalien(~oneeyedal@125-63-26-100.ip4.superloop.au) (Remote host closed the connection)
2023-05-30 10:10:57 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-05-30 10:11:35 +0200gurkenglas(~user@dynamic-046-114-181-050.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-30 10:17:55 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-30 10:21:40 +0200gurkenglas(~user@dynamic-046-114-181-050.46.114.pool.telefonica.de)
2023-05-30 10:26:04 +0200shane(~shane@ana.rch.ist)
2023-05-30 10:26:19 +0200titibandit(~titibandi@user/titibandit)
2023-05-30 10:27:51 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2023-05-30 10:28:09 +0200 <shane> Is `(# #) -> Int#` similar to a boxed `Int`? Does it end up just being a pointer to an `Int#` or is it an actual function call?
2023-05-30 10:41:43 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-05-30 10:42:55 +0200ubert(~Thunderbi@p548c91e0.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
2023-05-30 10:43:20 +0200ubert(~Thunderbi@p200300ecdf0002063c1d2db889bb964c.dip0.t-ipconnect.de)
2023-05-30 10:46:04 +0200_xor(~xor@nw-esr1-72-49-97-201.fuse.net)
2023-05-30 10:46:26 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Remote host closed the connection)
2023-05-30 10:53:40 +0200thegeekinside(~thegeekin@189.180.42.214) (Remote host closed the connection)
2023-05-30 10:55:49 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-05-30 10:55:49 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-05-30 10:56:23 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
2023-05-30 10:56:55 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:89bf:2c1e:724:8d14)
2023-05-30 10:57:10 +0200Lord_of_Life_Lord_of_Life
2023-05-30 10:58:22 +0200ubert1(~Thunderbi@2a02:8109:abc0:6434:e3:e79d:949c:d6b)
2023-05-30 11:00:01 +0200vladan[m](~vladanmat@2001:470:69fc:105::2:24df) (Remote host closed the connection)
2023-05-30 11:02:43 +0200cr4zsci(~Guest75@176.122.87.241) (Ping timeout: 245 seconds)
2023-05-30 11:02:59 +0200 <probie> shane: https://godbolt.org/z/Wdrxh7qM6 it looks like an actual function call to me
2023-05-30 11:06:50 +0200xameer(~xameer@144.48.224.57)
2023-05-30 11:08:31 +0200mncheck(~mncheck@193.224.205.254)
2023-05-30 11:10:12 +0200xameer(~xameer@144.48.224.57) (Client Quit)
2023-05-30 11:12:40 +0200 <shane> probie: Thanks for that!
2023-05-30 11:15:30 +0200Guest9(~Guest75@176.122.87.241)
2023-05-30 11:16:11 +0200 <shane> That's a nice tool, I hadn't come across it before
2023-05-30 11:16:24 +0200Guest9cr4zsci
2023-05-30 11:31:09 +0200thegeekinside(~thegeekin@189.180.42.214)
2023-05-30 11:35:02 +0200 <tomsmeding> shane, probie: shameless plug for an alternative tool :) https://play.haskell.org/saved/4nYlce4v
2023-05-30 11:35:29 +0200 <tomsmeding> doesn't have highlighting that relates source and asm yet, though
2023-05-30 11:36:05 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-05-30 11:37:03 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-05-30 11:37:54 +0200 <redmp> Axman6: it's a machine with 256 1.5GHz cores, according to /proc/cpuinfo, but the university website say it's a GPU machine w/4000 cores.. anyway, thanks, i'll ask in #ghc tomorrow
2023-05-30 11:38:24 +0200 <merijn> redmp: gpu cores aren't reported in cpuinfo, though?
2023-05-30 11:38:33 +0200 <merijn> redmp: What was the original question?
2023-05-30 11:39:17 +0200 <geekosaur> [30 05:36:07] <redmp> it's only one line: "main: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:216:3-10)"
2023-05-30 11:39:21 +0200 <probie> merijn: > hi, I'm using "-threaded" and make calls to "threadDelay", but I'm on an exotic machine and these calls fail with an error I've not seen before. I'll paste it. it's only one line: "main: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:216:3-10)"
2023-05-30 11:39:40 +0200 <merijn> heh
2023-05-30 11:40:19 +0200 <probie> (They're on ghc 9.0.2)
2023-05-30 11:42:17 +0200redmp(~redmp@mobile-166-171-249-80.mycingular.net) (Ping timeout: 250 seconds)
2023-05-30 11:42:31 +0200 <merijn> redmp: are you, perchance, using rtsopts and specifying -N?
2023-05-30 11:46:51 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 11:46:59 +0200 <merijn> It seems like it's either 1) number of capabilities exceeding the max number of event managers, or 2) some kinda memory ordering issue accessing one before they're initialised
2023-05-30 11:47:30 +0200 <merijn> Also, isn't 9.0 kinda busted to begin with?
2023-05-30 11:48:32 +0200chele(~chele@user/chele)
2023-05-30 11:51:17 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Ping timeout: 246 seconds)
2023-05-30 11:51:23 +0200chomwitt(~chomwitt@2a02:587:7a16:6700:1ac0:4dff:fedb:a3f1) (Ping timeout: 250 seconds)
2023-05-30 11:58:47 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:89bf:2c1e:724:8d14) (Remote host closed the connection)
2023-05-30 11:59:07 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:89bf:2c1e:724:8d14)
2023-05-30 12:03:27 +0200red-snail1(~snail@static.151.210.203.116.clients.your-server.de) (Quit: ZNC 1.8.2 - https://znc.in)
2023-05-30 12:03:44 +0200red-snail1(~snail@static.151.210.203.116.clients.your-server.de)
2023-05-30 12:04:05 +0200madnight(~madnight@static.59.103.201.195.clients.your-server.de) (Quit: ZNC 1.8.2 - https://znc.in)
2023-05-30 12:04:20 +0200madnight(~madnight@static.59.103.201.195.clients.your-server.de)
2023-05-30 12:04:33 +0200thegeekinside(~thegeekin@189.180.42.214) (Remote host closed the connection)
2023-05-30 12:05:42 +0200barcisz(~barcisz@83.6.194.51.ipv4.supernova.orange.pl)
2023-05-30 12:05:59 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 246 seconds)
2023-05-30 12:24:56 +0200CiaoSen(~Jura@145.224.73.17)
2023-05-30 12:29:32 +0200reverse(~inversed@bcdcac82.skybroadband.com) (Ping timeout: 250 seconds)
2023-05-30 12:32:05 +0200troydm(~troydm@user/troydm) (Ping timeout: 240 seconds)
2023-05-30 12:41:23 +0200pyook(~puke@user/puke) (Remote host closed the connection)
2023-05-30 12:41:41 +0200pyook(~puke@user/puke)
2023-05-30 12:43:20 +0200reverse(~inversed@bcdcac82.skybroadband.com)
2023-05-30 12:44:32 +0200CiaoSen(~Jura@145.224.73.17) (Ping timeout: 265 seconds)
2023-05-30 12:46:25 +0200CiaoSen(~Jura@145.224.73.17)
2023-05-30 12:50:50 +0200tackleton(~tackleton@user/tackleton)
2023-05-30 12:53:49 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving)
2023-05-30 12:54:00 +0200tackleton(~tackleton@user/tackleton) (Since you gotta go you better go now)
2023-05-30 12:59:27 +0200xff0x(~xff0x@2405:6580:b080:900:2331:d5b8:4a67:9709)
2023-05-30 13:11:01 +0200oo_miguel(~Thunderbi@77.252.47.84) (Quit: oo_miguel)
2023-05-30 13:15:39 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 13:22:08 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds)
2023-05-30 13:30:41 +0200cr4zsci(~Guest75@176.122.87.241) (Quit: Client closed)
2023-05-30 13:30:48 +0200xff0x(~xff0x@2405:6580:b080:900:2331:d5b8:4a67:9709) (Remote host closed the connection)
2023-05-30 13:31:06 +0200xff0x(~xff0x@2405:6580:b080:900:bf5:d0f1:bef5:d272)
2023-05-30 13:32:50 +0200 <zero> https://github.com/ghc-proposals/ghc-proposals/issues/587 <- please don't do this
2023-05-30 13:33:35 +0200 <yushyin> yet another or-pattern proposal?
2023-05-30 13:34:19 +0200 <zero> i don't get it
2023-05-30 13:34:37 +0200 <yushyin> Oh, one was actually accepted, I didn't know that yet
2023-05-30 13:34:46 +0200 <zero> https://github.com/ghc-proposals/ghc-proposals/pull/522 <- the example given here is an argument against wildcards, not for or patterns
2023-05-30 13:34:55 +0200 <zero> just don't use wildcards then
2023-05-30 13:35:02 +0200 <zero> am i missing something?
2023-05-30 13:36:25 +0200CiaoSen(~Jura@145.224.73.17) (Ping timeout: 240 seconds)
2023-05-30 13:36:26 +0200 <zero> piling on layers of redundant sugar is a good way to kill a language
2023-05-30 13:36:30 +0200 <zero> imo
2023-05-30 13:37:28 +0200 <zero> just make wildcards throw a warning by default
2023-05-30 13:37:51 +0200 <zero> it's bad practice anyway
2023-05-30 13:40:14 +0200 <probie> If wildcards are "bad practice", why not just remove them?
2023-05-30 13:42:32 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-05-30 13:45:13 +0200vandita(~vandit@84-236-21-17.pool.digikabel.hu) (Ping timeout: 256 seconds)
2023-05-30 13:46:45 +0200vandita(~vandit@92-249-185-171.pool.digikabel.hu)
2023-05-30 13:57:34 +0200machinedgod(~machinedg@93-138-3-195.adsl.net.t-com.hr)
2023-05-30 14:11:48 +0200xff0x(~xff0x@2405:6580:b080:900:bf5:d0f1:bef5:d272) (Ping timeout: 240 seconds)
2023-05-30 14:13:55 +0200xff0x(~xff0x@ai098135.d.east.v6connect.net)
2023-05-30 14:14:43 +0200 <merijn> I don't agree they're bad practice to begin with
2023-05-30 14:15:33 +0200 <merijn> I severely dislike the accepted or-proposal anyway, since it doesn't actually implement the *one* actual use case I can imagine for it
2023-05-30 14:16:01 +0200 <merijn> zero: Well, tell the people who keep insisting on making trivial syntax change proposals :\
2023-05-30 14:16:37 +0200 <geekosaur> I don't think they're bad practice either
2023-05-30 14:16:38 +0200 <merijn> I mostly agree, there's lots of syntax I would change IFF we were doing Haskell from scratch (like imports), but these post-hoc minor tweaks just create a freaking mess of a language
2023-05-30 14:17:07 +0200 <merijn> The record dot proposal is also brain-damaged for that reason, imo
2023-05-30 14:19:50 +0200 <merijn> I can think of like 5-10 minor changes that woulda make things much more pleasant, but the gain in pleasantness doesn't outweigh the potential breakage and long-term splintering, I think
2023-05-30 14:23:14 +0200mei(~mei@user/mei)
2023-05-30 14:23:36 +0200Las[m]1(~lasmatrix@2001:470:69fc:105::74e)
2023-05-30 14:24:34 +0200 <Las[m]1> Does anyone know the reasoning for why top-level definitions must be lifted?
2023-05-30 14:25:28 +0200 <jade[m]> what do you mean by lifted?
2023-05-30 14:25:49 +0200 <merijn> jade[m]: That they have a Lifted TypeRep, presumably
2023-05-30 14:26:15 +0200 <merijn> Las[m]1: Probably because else you could export them from the module, which sounds like a nightmare to implement
2023-05-30 14:26:25 +0200 <merijn> Las[m]1: Since then you can't just resolve them to a simple symbol
2023-05-30 14:26:46 +0200 <Las[m]1> Type rather than TYPE anything
2023-05-30 14:27:09 +0200 <geekosaur> there's also questions like whether it's a computation as opposed to a constant value, in which case when is it performed?
2023-05-30 14:27:47 +0200 <geekosaur> (C++ has this problem and solves it with file level constructors/destructors, which are indeed a nightmare)
2023-05-30 14:28:04 +0200 <geekosaur> especially if it's dynamically loaded
2023-05-30 14:28:08 +0200 <merijn> Las[m]1: essentially, it sounds like a design headache to implement and of limited use
2023-05-30 14:28:38 +0200 <merijn> Which seems a reasonable enough reason to say "sod this" :p
2023-05-30 14:29:03 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-05-30 14:32:47 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 14:39:29 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection)
2023-05-30 14:39:42 +0200 <dminuoso> Las[m]1: Is lifted an actual requirement?
2023-05-30 14:39:52 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 14:40:07 +0200 <dminuoso> Naively I would expect any BoxedRep to be enough
2023-05-30 14:40:16 +0200 <dminuoso> i.e. boxed/unlifted
2023-05-30 14:40:32 +0200machinedgod(~machinedg@93-138-3-195.adsl.net.t-com.hr) (Ping timeout: 265 seconds)
2023-05-30 14:43:40 +0200 <geekosaur> You cannot bind a variable with an unboxed type in a top-level binding.
2023-05-30 14:43:56 +0200 <geekosaur> (https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/primitives.html#unboxed-type-ki…)
2023-05-30 14:44:33 +0200 <geekosaur> (9.0.1 there is more or less accident; that's the last version I needed to check the release notes for 🙂 )
2023-05-30 14:45:19 +0200 <dminuoso> geekosaur: Right. Im just saying it sufficient but not necessary to be lifted.
2023-05-30 14:45:31 +0200 <dminuoso> Since you can also have boxed unlifted things
2023-05-30 14:48:32 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 248 seconds)
2023-05-30 14:49:40 +0200 <Axman6> zero: two things, it will be behind a language extension, so if you don't likeit, you don't have to use it; and this isn't the place to complain, you've literally linked to where you should be raising this if you care so deeply
2023-05-30 14:50:55 +0200 <Axman6> it also seems like you missed the point of or-patterns, they aren't really related twildcards at all (though the example could lead you to believe that)
2023-05-30 14:51:07 +0200 <Axman6> to *
2023-05-30 14:53:17 +0200 <dminuoso> Well there is some relationship in that some uses of wildcards lead to brittle code.
2023-05-30 14:53:35 +0200 <dminuoso> But the use of one-of covers not only that but goes further.
2023-05-30 14:55:29 +0200 <Axman6> I want to be able to say case one of (Foo a _); (Bar a _) -> ... ; one of (Baz x y); (Quux y x) -> ... and the compiler just needs to check those bindings are for values of the same type
2023-05-30 14:56:01 +0200 <merijn> Axman6: or-patterns don't let you do that :\
2023-05-30 14:56:02 +0200 <jackdk> just bodge prisms together
2023-05-30 14:56:19 +0200 <Axman6> that to me is the main use case for or-patterns, not to get exhaustive pattern matches without using wildcards
2023-05-30 14:56:21 +0200 <merijn> Axman6: The accepted proposals doesn't allow bindings shared between the patterns
2023-05-30 14:56:31 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 14:56:35 +0200 <Axman6> merijn: well shit (: guess it's not very useful then
2023-05-30 14:56:36 +0200 <merijn> Axman6: so you can only use or patterns when you bind nothing
2023-05-30 14:56:53 +0200 <merijn> Axman6: yeah, that's my main complaint, that's the one usecase I could see and they ruined it
2023-05-30 14:57:14 +0200 <merijn> Axman6: Because they can't comprehensively support GADTs and whatever DependentHaskell nonsense with it
2023-05-30 14:57:18 +0200 <Axman6> what was the reasoning for not doing that?
2023-05-30 14:57:27 +0200 <Axman6> -_-
2023-05-30 14:57:27 +0200 <merijn> like...screw those things, just check if the two unify
2023-05-30 14:57:38 +0200 <Axman6> yeah
2023-05-30 14:58:00 +0200 <merijn> as-is it's an extension neutered to the point of uselessness so it's just adding syntactic noise and doesn't even address the one usecase they're good for
2023-05-30 14:58:03 +0200 <Axman6> "Error: or-patterns are not supported for GADTs" problem solved
2023-05-30 14:58:35 +0200 <Axman6> imagine if we had Erlang's pattern matching
2023-05-30 14:59:00 +0200 <Axman6> IIRC you can basically do e == e = True; _ == _ = False
2023-05-30 14:59:20 +0200 <Axman6> I guess they don't have infinite data
2023-05-30 15:08:10 +0200MajorBiscuit(~MajorBisc@c-001-021-017.client.tudelft.eduvpn.nl)
2023-05-30 15:12:28 +0200 <dminuoso> But I agree, that without variable bindings, the value of or-patterns will largely be limited to sum types of nullary data types.
2023-05-30 15:14:23 +0200__monty__(~toonn@user/toonn)
2023-05-30 15:22:56 +0200barcisz(~barcisz@83.6.194.51.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-05-30 15:34:32 +0200ystael(~ystael@user/ystael)
2023-05-30 15:34:38 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-05-30 15:34:38 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-05-30 15:34:38 +0200wroathe(~wroathe@user/wroathe)
2023-05-30 15:35:09 +0200td_(~td@i53870907.versanet.de) (Quit: waking up from the american dream ...)
2023-05-30 15:46:47 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 15:47:14 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 268 seconds)
2023-05-30 15:48:38 +0200td_(~td@i53870907.versanet.de)
2023-05-30 15:50:41 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 246 seconds)
2023-05-30 15:51:01 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-05-30 15:52:22 +0200gensyst(~gensyst@user/gensyst)
2023-05-30 15:52:45 +0200 <gensyst> During putMVar (when waiting for it to become empty), does GHC call the garbage collector at all?
2023-05-30 15:52:55 +0200 <gensyst> (because something in the GC could empty the mvar?)
2023-05-30 15:53:36 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-30 15:54:08 +0200titibandit(~titibandi@user/titibandit)
2023-05-30 15:54:35 +0200 <Axman6> why would the GC empty an MVar?
2023-05-30 15:54:49 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-05-30 15:55:00 +0200 <Axman6> they can only be emptied by a call to takeMVar (or equivalent)
2023-05-30 15:55:05 +0200ystael(~ystael@user/ystael) (Quit: Lost terminal)
2023-05-30 15:56:36 +0200 <Axman6> IIRC, the way that poutMVar works is: optimistically try to write to it, if it';s full, the thread adds itself to a queue of threads waiting to write and that thread is not runable until it reaches the head of the queue
2023-05-30 15:57:06 +0200 <Axman6> Parallel and Concurrent Programming in Haskell will have more details
2023-05-30 15:57:10 +0200 <Axman6> @where pcph
2023-05-30 15:57:10 +0200 <lambdabot> "Parallel and Concurrent Programming in Haskell" by Simon Marlow in 2013 at <http://community.haskell.org/~simonmar/pcph/>,<http://chimera.labs.oreilly.com/books/1230000000929/>,<https://web.archive.
2023-05-30 15:57:10 +0200 <lambdabot> org/web/20180117194842/http://chimera.labs.oreilly.com/books/1230000000929>,<https://www.oreilly.com/library/view/parallel-and-concurrent/9781449335939/>
2023-05-30 15:57:14 +0200barcisz(~barcisz@83.6.194.51.ipv4.supernova.orange.pl)
2023-05-30 15:57:33 +0200ystael(~ystael@user/ystael)
2023-05-30 15:58:49 +0200 <merijn> gensyst: MVars are GC roots, so GC can never empty them
2023-05-30 15:58:56 +0200 <merijn> Axman6: correct
2023-05-30 16:02:43 +0200 <gensyst> Axman6, merijn thanks!
2023-05-30 16:02:56 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-05-30 16:03:46 +0200 <merijn> I guess that *theoretically* some atrocious abomination of weak pointers and finalizer could conceivably indirectly cause GC to run a finalizer that empties an MVar, but that seems sufficiently farfetched it's not what you mean :p
2023-05-30 16:04:09 +0200 <merijn> Also, if you do that, you deserve any misery you get :p
2023-05-30 16:04:18 +0200 <gensyst> Axman6, merijn so code that empties an mvar (with takeMVar) on GC (through e.g. weakIORRef is invalid code?
2023-05-30 16:04:28 +0200 <gensyst> merijn, lol that's the route i was barking on :(
2023-05-30 16:04:30 +0200 <gensyst> fuuuuuuuuu
2023-05-30 16:05:11 +0200 <merijn> gensyst: I mean, the interactions there are complicated enough I'm not willing to make any statement on their correctness or sanity :p
2023-05-30 16:05:38 +0200 <merijn> That's "better stare at GHC's implementation to make sure this makes sense" levels of complexity
2023-05-30 16:06:15 +0200ddellacosta(~ddellacos@143.244.47.100)
2023-05-30 16:08:08 +0200 <gensyst> merijn, are literally all mvars gc roots? why?
2023-05-30 16:08:29 +0200 <merijn> gensyst: I'm not sure how you can imagine them not being GC roots?
2023-05-30 16:08:49 +0200 <merijn> I can't really conceive what that'd mean
2023-05-30 16:08:50 +0200 <dminuoso> They are global mutable state.
2023-05-30 16:10:58 +0200 <geekosaur> a value in an `MVar` is "unowned" until `takeMVar`ed, so the `MVar` itself has to keep it alive, hence must be a GC root
2023-05-30 16:11:44 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds)
2023-05-30 16:11:49 +0200ubert1(~Thunderbi@2a02:8109:abc0:6434:e3:e79d:949c:d6b) (Ping timeout: 250 seconds)
2023-05-30 16:13:49 +0200ddellacosta(~ddellacos@143.244.47.100) (Ping timeout: 265 seconds)
2023-05-30 16:13:53 +0200Sgeo(~Sgeo@user/sgeo)
2023-05-30 16:15:35 +0200ddellacosta(~ddellacos@146.70.168.170)
2023-05-30 16:18:23 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-30 16:19:17 +0200 <gensyst> I still don't see why some weakioref code (my own code) can't contain takeMVar. What's so special about takeMVar? i'm just doing stuff, like i do any other stuff. After that code is run, things are what they are in the end.
2023-05-30 16:19:20 +0200 <gensyst> so what's the big deal?
2023-05-30 16:19:42 +0200 <gensyst> the only difference is that GC eventually runs that code
2023-05-30 16:19:43 +0200 <merijn> gensyst: It can, it just makes it a nightmare to reason about
2023-05-30 16:21:48 +0200 <merijn> I didn't say it was invalid code. I said people who value their sanity avoid writing code like that :p
2023-05-30 16:22:13 +0200captnemo(~captnemo@193.32.127.232)
2023-05-30 16:25:12 +0200cheater(~Username@user/cheater)
2023-05-30 16:28:06 +0200stackdroid18(14094@de1.hashbang.sh)
2023-05-30 16:28:42 +0200captnemo(~captnemo@193.32.127.232) (Quit: WeeChat 3.8)
2023-05-30 16:31:16 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-05-30 16:32:42 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2023-05-30 16:40:59 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-30 16:44:01 +0200zerozzz
2023-05-30 16:45:05 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-05-30 16:45:42 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:bd3c:70d:4e85:6e2b) (Quit: WeeChat 2.8)
2023-05-30 16:45:53 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.8)
2023-05-30 16:47:53 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-30 16:50:49 +0200ddellacosta(~ddellacos@146.70.168.170) (Ping timeout: 250 seconds)
2023-05-30 16:51:16 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 16:52:55 +0200ddellacosta(~ddellacos@143.244.47.74)
2023-05-30 16:55:28 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Ping timeout: 248 seconds)
2023-05-30 17:00:47 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-05-30 17:01:34 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 17:12:47 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-05-30 17:16:32 +0200 <jade[m]> would it make sense to have
2023-05-30 17:16:32 +0200 <jade[m]> ```
2023-05-30 17:16:32 +0200 <jade[m]> pass :: Applicative f => f ()
2023-05-30 17:16:32 +0200 <jade[m]> ...(truncated)
2023-05-30 17:16:45 +0200 <jade[m]> s/use/export
2023-05-30 17:20:33 +0200 <dminuoso> jade[m]: The answer to that question is the same as for whether anything is sensible to export.
2023-05-30 17:21:12 +0200 <dminuoso> It's a convenince bit I generally dont use because I just write: () <$ foo
2023-05-30 17:21:14 +0200 <geekosaur> "pass" feels like a Pythonism
2023-05-30 17:21:19 +0200cheater_(~Username@user/cheater)
2023-05-30 17:21:48 +0200 <dminuoso> As much as `return` feels like a Fortranism.
2023-05-30 17:21:58 +0200 <geekosaur> was just thinking that, yes
2023-05-30 17:22:26 +0200 <ncf> jade[m]: we can't see your entire message because the matrix bridge truncates it; please use an IRC client
2023-05-30 17:22:44 +0200 <geekosaur> yeh, I had to switch to matrix to see it
2023-05-30 17:22:47 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-30 17:22:54 +0200cheater_cheater
2023-05-30 17:23:05 +0200 <geekosaur> annoyingly, the bridge only *sometimes* truncates; other times it at least pastebins the whole message
2023-05-30 17:23:43 +0200 <ncf> matrix bridges are a disaster and we should just stop it
2023-05-30 17:24:10 +0200 <dminuoso> ncf: Federation of federated chat networks!
2023-05-30 17:24:31 +0200ubert(~Thunderbi@p200300ecdf0002063c1d2db889bb964c.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2023-05-30 17:24:38 +0200 <dminuoso> It's like running bitcoin in a smart contract on cardano.
2023-05-30 17:28:56 +0200ubert(~Thunderbi@p200300ecdf0002068202f1bd1e34972c.dip0.t-ipconnect.de)
2023-05-30 17:29:18 +0200cheater_(~Username@user/cheater)
2023-05-30 17:30:38 +0200cheater__(~Username@user/cheater)
2023-05-30 17:31:33 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-30 17:31:43 +0200cheater__cheater
2023-05-30 17:34:10 +0200cheater_(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-30 17:35:38 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-05-30 17:37:04 +0200kritzefitz(~kritzefit@debian/kritzefitz) (Ping timeout: 248 seconds)
2023-05-30 17:37:27 +0200kritzefitz(~kritzefit@debian/kritzefitz)
2023-05-30 17:41:59 +0200kritzefitz(~kritzefit@debian/kritzefitz) (Ping timeout: 240 seconds)
2023-05-30 17:42:15 +0200cheater_(~Username@user/cheater)
2023-05-30 17:42:18 +0200kritzefitz(~kritzefit@debian/kritzefitz)
2023-05-30 17:43:31 +0200cheater__(~Username@user/cheater)
2023-05-30 17:45:00 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-30 17:45:06 +0200cheater__cheater
2023-05-30 17:45:20 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Remote host closed the connection)
2023-05-30 17:46:47 +0200cheater_(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-30 17:47:33 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 17:47:39 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 17:47:52 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Quit: WeeChat 3.8)
2023-05-30 17:52:03 +0200cheater__(~Username@user/cheater)
2023-05-30 17:52:12 +0200kritzefitz_(~kritzefit@debian/kritzefitz)
2023-05-30 17:52:28 +0200kritzefitz(~kritzefit@debian/kritzefitz) (Ping timeout: 240 seconds)
2023-05-30 17:53:34 +0200 <gensyst> Is there a reliable way to convert ThreadId to Int?
2023-05-30 17:54:06 +0200 <gensyst> wondering if i really have to do mkWeakThreadId (to point to it weakly) instead of just storing the Int (which I really need in the end)
2023-05-30 17:54:11 +0200cheater___(~Username@user/cheater)
2023-05-30 17:54:57 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-30 17:55:05 +0200cheater___cheater
2023-05-30 17:55:34 +0200 <Hecate> gensyst: heavens why do you need it to be an Int?
2023-05-30 17:55:45 +0200 <EvanR> there might be a proof that ThreadId can't logically be converted to an Int
2023-05-30 17:55:56 +0200 <EvanR> puts euclid's hat on
2023-05-30 17:56:09 +0200esph(~weechat@user/esph)
2023-05-30 17:56:57 +0200 <EvanR> 1. different threads have different ThreadIds. 2. for any function f :: ThreadId -> Int, and and two different ThreadId x /= y, f x /= f y
2023-05-30 17:57:04 +0200kritzefitz_kritzefitz
2023-05-30 17:57:12 +0200 <EvanR> but as time goes on you can have more threads in the history of the program than Int
2023-05-30 17:57:28 +0200 <EvanR> so by pigeonhole principle you would have f x == f y for some pair of ThreadIds
2023-05-30 17:57:38 +0200 <EvanR> causing a contradiction
2023-05-30 17:57:44 +0200cheater__(~Username@user/cheater) (Ping timeout: 265 seconds)
2023-05-30 17:57:53 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2023-05-30 17:58:09 +0200 <c_wraith> gensyst: https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-Conc-Sync.html#t:ThreadId this exposes the constructor
2023-05-30 17:58:13 +0200 <geekosaur> well, the key point is as long as you hold a ThreadId you prevent it from being reused, this is not true if you make it an Int (or make it weak for that matter)
2023-05-30 17:58:35 +0200 <geekosaur> \but at least you get a finalizer call in the latter case
2023-05-30 17:58:46 +0200 <gensyst> well, all I wanted to do is at some point in the program, check if the Int I stored is the same int as the currently running thread.
2023-05-30 17:58:46 +0200chomwitt(~chomwitt@ppp-94-67-203-168.home.otenet.gr)
2023-05-30 17:59:27 +0200 <geekosaur> do you accept false positives?
2023-05-30 17:59:29 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds)
2023-05-30 17:59:50 +0200 <ncf> EvanR: you're assuming that f is injective! const 0 :: ThreadId -> Int
2023-05-30 18:00:01 +0200 <c_wraith> Hmm. I guess the constructor isn't that helpful
2023-05-30 18:00:12 +0200 <gensyst> EvanR's point stands that yeah, I guess at some point i might exhaust maxBound :: Int
2023-05-30 18:00:14 +0200kluk(~arrowhead@cpe-74-66-76-151.nyc.res.rr.com)
2023-05-30 18:00:27 +0200 <c_wraith> On a 64-bit system?
2023-05-30 18:00:29 +0200 <gensyst> if the program runs long enough :S
2023-05-30 18:00:34 +0200 <gensyst> unlikely
2023-05-30 18:00:45 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Remote host closed the connection)
2023-05-30 18:00:55 +0200 <gensyst> unlikely on 64-bit sys
2023-05-30 18:01:01 +0200 <geekosaur> (I note that it's currently a pointer per the documentation, which reduces the space because threads might be pooled and reused)
2023-05-30 18:01:03 +0200 <gensyst> unlikely that this happens on a 64-bit sys
2023-05-30 18:01:48 +0200 <ncf> apparently it fits in a CULLong https://hackage.haskell.org/package/base-4.18.0.0/docs/src/GHC.Conc.Sync.html#getThreadId
2023-05-30 18:02:47 +0200 <EvanR> Int (on 64-bit) is approximately infinite
2023-05-30 18:03:03 +0200 <EvanR> lol
2023-05-30 18:03:33 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-05-30 18:03:59 +0200 <EvanR> damn good job obliterating my proof, const 0 indeed
2023-05-30 18:10:28 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 18:10:30 +0200n0den1te(~~.~@157.119.87.13)
2023-05-30 18:11:41 +0200 <c_wraith> As a very silly alternative, you could hold ThreadIds and periodically check that the ThreadStatus is still in one of the active states, and discard the ThreadId if it needs to be cleaned up.
2023-05-30 18:12:08 +0200 <c_wraith> I can't offhand think of when that's better than using a finalizer, but it's an option of sorts
2023-05-30 18:14:33 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 18:17:36 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-30 18:18:23 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection)
2023-05-30 18:18:46 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 18:21:14 +0200econo(uid147250@user/econo)
2023-05-30 18:21:22 +0200nick___(~nick@wsip-174-78-110-18.pn.at.cox.net)
2023-05-30 18:22:05 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-05-30 18:22:28 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-30 18:22:31 +0200mikail(~mikail@2a02:c7c:60bc:7b00:436c:7fb5:a1d2:3a5e)
2023-05-30 18:25:43 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 256 seconds)
2023-05-30 18:26:12 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-05-30 18:26:43 +0200zero(~z@user/zero)
2023-05-30 18:27:38 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 18:27:42 +0200MajorBiscuit(~MajorBisc@c-001-021-017.client.tudelft.eduvpn.nl) (Ping timeout: 265 seconds)
2023-05-30 18:28:32 +0200 <eldritchcookie[m> we have a FFI for c, what would it take exactly to make one for another compiled language?
2023-05-30 18:29:02 +0200 <geekosaur> a fixed, standardized ABI for that language
2023-05-30 18:29:28 +0200 <geekosaur> as yet only C has such and even it has limitations (for example, passing/returning `struct`s by value is not part of the standard)
2023-05-30 18:29:43 +0200MajorBiscuit(~MajorBisc@128-227-168.netrun.cytanet.com.cy)
2023-05-30 18:30:10 +0200 <geekosaur> Raku tried to do one for C++ only to discover it wasn't portable; C++ makes no promises as to ABI
2023-05-30 18:30:15 +0200zzz(~z@user/zero) (Ping timeout: 256 seconds)
2023-05-30 18:30:50 +0200 <geekosaur> so pretty much all FFI passes through the subset of C that has a fixed ABI
2023-05-30 18:32:40 +0200 <EvanR> how about pascal ffi for haskell, which would have a side benefit of confusing everyone who thought those were the same language
2023-05-30 18:33:05 +0200 <geekosaur> first, find one
2023-05-30 18:33:46 +0200 <geekosaur> (ironically, it used to exist after a fashion: older macos and older windows both used a pascal-based ABI)
2023-05-30 18:34:32 +0200 <EvanR> that's what I was thinking of, wow this is older and more obsolete than I thought
2023-05-30 18:35:15 +0200 <EvanR> a 16 bit ThreadId would really ruin gensyst's day
2023-05-30 18:44:29 +0200EvanR(~EvanR@user/evanr) (Remote host closed the connection)
2023-05-30 18:44:49 +0200EvanR(~EvanR@user/evanr)
2023-05-30 18:49:50 +0200mikail(~mikail@2a02:c7c:60bc:7b00:436c:7fb5:a1d2:3a5e) (Quit: Leaving)
2023-05-30 18:51:59 +0200turlando(~turlando@user/turlando) (Ping timeout: 240 seconds)
2023-05-30 18:55:37 +0200vandita(~vandit@92-249-185-171.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-30 18:55:52 +0200nick___(~nick@wsip-174-78-110-18.pn.at.cox.net) (Quit: WeeChat 3.8)
2023-05-30 18:57:13 +0200vandita(~vandit@92-249-182-8.pool.digikabel.hu)
2023-05-30 18:59:28 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds)
2023-05-30 19:00:44 +0200n0den1te(~~.~@157.119.87.13) (Quit: Leaving.)
2023-05-30 19:01:15 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 19:01:40 +0200__monty__(~toonn@user/toonn)
2023-05-30 19:03:10 +0200turlando(~turlando@user/turlando)
2023-05-30 19:05:31 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Ping timeout: 240 seconds)
2023-05-30 19:07:44 +0200barcisz(~barcisz@83.6.194.51.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-05-30 19:07:59 +0200ub(~Thunderbi@p548c91e0.dip0.t-ipconnect.de)
2023-05-30 19:08:05 +0200ubert(~Thunderbi@p200300ecdf0002068202f1bd1e34972c.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-05-30 19:08:06 +0200ububert
2023-05-30 19:11:30 +0200oo_miguel(~Thunderbi@77.252.47.84) (Quit: oo_miguel)
2023-05-30 19:12:02 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-05-30 19:13:15 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-05-30 19:13:45 +0200 <merijn> eldritchcookie[m: The main thing it'd take to make another FFI is "a lot of elbow grease"
2023-05-30 19:15:28 +0200 <Las[m]1> eldritch cookie: you typically use that C FFI for all other languages
2023-05-30 19:15:29 +0200 <Las[m]1> so e.g. you'd bind to it from Rust, Python, Go, because C is universally supporoted
2023-05-30 19:15:45 +0200Midjak(~Midjak@82.66.147.146)
2023-05-30 19:15:53 +0200 <Las[m]1> if you want to have more in-depth support (e.g. translate type classes), that depends on the language and can be very complex.
2023-05-30 19:17:09 +0200 <eldritchcookie[m> yeah was looking at it unfortunately not worth it, time used on the javascript backend would be way more efficient to do what i want
2023-05-30 19:17:43 +0200MajorBiscuit(~MajorBisc@128-227-168.netrun.cytanet.com.cy) (Ping timeout: 250 seconds)
2023-05-30 19:20:35 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc)
2023-05-30 19:22:45 +0200 <dminuoso> `geekosaur | as yet only C has such [...]`
2023-05-30 19:22:55 +0200 <dminuoso> Even thats a mild lie at best.
2023-05-30 19:22:55 +0200Midjak(~Midjak@82.66.147.146) (Quit: Leaving)
2023-05-30 19:24:25 +0200 <dminuoso> The gigantic clustermess of different ABIs, incoherent clusterscrew of header macros being interpreted differently depending on what compiler you use or what platform you have, completely broken dances across static storage state in glibc (Im looking at you NSS)
2023-05-30 19:25:11 +0200 <dminuoso> It's not really standardized either, at best there's a bunch of conventions that - as long as you obey by using a stack of ancient convoluted autotools - might work togehter.
2023-05-30 19:25:14 +0200 <dminuoso> Or might not.
2023-05-30 19:26:33 +0200 <dminuoso> .NET and JRE are examples of how standardized FFI can work.
2023-05-30 19:26:49 +0200 <dminuoso> C is the epitome of "but it works for me"
2023-05-30 19:26:55 +0200 <merijn> eldritchcookie[m: a javascript FFI is the one thing I can see getting added at some point
2023-05-30 19:27:05 +0200 <merijn> Now that wasm is in mainline ghc
2023-05-30 19:30:56 +0200quarkyalice(~alice@92.sub-75-198-181.myvzw.com)
2023-05-30 19:30:56 +0200quarkyalice(~alice@92.sub-75-198-181.myvzw.com) (Changing host)
2023-05-30 19:30:56 +0200quarkyalice(~alice@user/quarkyalice)
2023-05-30 19:42:22 +0200gensyst(~gensyst@user/gensyst) (Quit: Leaving)
2023-05-30 19:43:48 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 19:48:58 +0200TMA(tma@twin.jikos.cz) (Ping timeout: 268 seconds)
2023-05-30 19:49:55 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 19:57:48 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 20:02:03 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-05-30 20:08:56 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-05-30 20:10:52 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 20:12:30 +0200scrungus(~scrungus@bras-base-aurron9127w-grc-63-70-24-87-21.dsl.bell.ca)
2023-05-30 20:17:05 +0200vandita(~vandit@92-249-182-8.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-30 20:18:04 +0200 <tomsmeding> dminuoso: that's the glibc ABI
2023-05-30 20:18:37 +0200 <tomsmeding> granted, that's relevant when talking about C at large, but when talking about FFI'ing with another C library, what glibc does matters less
2023-05-30 20:18:55 +0200vandita(~vandit@94-21-82-214.pool.digikabel.hu)
2023-05-30 20:19:26 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-05-30 20:19:38 +0200 <tomsmeding> though even the bare-bones C ABI for calling functions differs by architecture and platform :)
2023-05-30 20:19:56 +0200tomsmedingis thinking about fastcall/ccall/whatever windows does again
2023-05-30 20:20:44 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Remote host closed the connection)
2023-05-30 20:21:06 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 20:23:01 +0200 <EvanR> pascall
2023-05-30 20:31:54 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-05-30 20:38:34 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-30 20:40:18 +0200gmg(~user@user/gehmehgeh)
2023-05-30 20:47:28 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 248 seconds)
2023-05-30 20:52:13 +0200pavonia(~user@user/siracusa)
2023-05-30 21:01:41 +0200Feuermagier(~Feuermagi@user/feuermagier)
2023-05-30 21:05:12 +0200stackdroid18(14094@de1.hashbang.sh) (Quit: hasta la vista... tchau!)
2023-05-30 21:07:09 +0200mechap(~mechap@user/mechap)
2023-05-30 21:07:17 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 21:14:19 +0200robobub(uid248673@2a03:5180:f:5::3:cb61) (Quit: Connection closed for inactivity)
2023-05-30 21:14:56 +0200taupiqueur(~taupiqueu@2a02-842a-8180-4601-655d-eb2e-b97d-d4ca.rev.sfr.net) (Quit: WeeChat 3.8)
2023-05-30 21:16:23 +0200vandita(~vandit@94-21-82-214.pool.digikabel.hu) (Ping timeout: 240 seconds)
2023-05-30 21:18:16 +0200vandita(~vandit@80-95-69-242.pool.digikabel.hu)
2023-05-30 21:19:53 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-05-30 21:21:12 +0200Lycurgus(~juan@user/Lycurgus)
2023-05-30 21:21:31 +0200ub(~Thunderbi@p200300ecdf0002068202f1bd1e34972c.dip0.t-ipconnect.de)
2023-05-30 21:21:45 +0200ubert(~Thunderbi@p548c91e0.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-05-30 21:21:46 +0200ububert
2023-05-30 21:25:03 +0200Lycurgus(~juan@user/Lycurgus) (Client Quit)
2023-05-30 21:27:28 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 240 seconds)
2023-05-30 21:31:25 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 21:32:13 +0200wrengr(~wrengr@201.59.83.34.bc.googleusercontent.com)
2023-05-30 21:32:43 +0200phma(phma@2001:5b0:2172:dd28:3b22:598:a9f4:e4a5) (Read error: Connection reset by peer)
2023-05-30 21:33:35 +0200simendsjo(~user@84.211.91.241)
2023-05-30 21:33:36 +0200phma(phma@2001:5b0:211c:ea78:b455:bfa2:d6ff:5b73)
2023-05-30 21:35:46 +0200ub(~Thunderbi@p548c91e0.dip0.t-ipconnect.de)
2023-05-30 21:35:55 +0200ubert(~Thunderbi@p200300ecdf0002068202f1bd1e34972c.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-05-30 21:35:56 +0200ububert
2023-05-30 21:38:34 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b) (Ping timeout: 250 seconds)
2023-05-30 21:41:57 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-05-30 21:42:14 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-05-30 21:42:24 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 248 seconds)
2023-05-30 21:47:23 +0200machinedgod(~machinedg@93-138-3-195.adsl.net.t-com.hr)
2023-05-30 21:49:42 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-05-30 21:50:01 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net)
2023-05-30 21:50:15 +0200vandita(~vandit@80-95-69-242.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-30 21:51:29 +0200redmp(~redmp@mobile-166-137-179-122.mycingular.net)
2023-05-30 21:52:10 +0200vandita(~vandit@193-110-63-63.cable-modem.hdsnet.hu)
2023-05-30 21:53:29 +0200reach(~reach@2607:fea8:4c0:990:f891:b512:3659:bf1b)
2023-05-30 21:55:03 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 265 seconds)
2023-05-30 21:59:21 +0200gurkenglas(~user@dynamic-046-114-181-050.46.114.pool.telefonica.de) (Ping timeout: 250 seconds)
2023-05-30 22:01:30 +0200 <dminuoso> tomsmeding: Fair enough. But the issues surrounding autotools, compiler specialties (fixincludes comes to mind), or just different macro substitution...
2023-05-30 22:02:04 +0200 <dminuoso> I mean if you give me a library and a header, in general I cant even guarantee proper linkage. Will my `struct foo` have the same layout as your `struct foo`?
2023-05-30 22:02:40 +0200 <dminuoso> As soon as CPP enters the scene, all bets are off.
2023-05-30 22:03:41 +0200 <dminuoso> And even without CPP, it depends on all the extensions and compiler flags that are used.,
2023-05-30 22:04:07 +0200 <dminuoso> And while yes, those are non-standard C, standard C is just a myth that language lawyers in ##c on freenode or libera spread.
2023-05-30 22:04:46 +0200trev(~trev@user/trev) (Quit: trev)
2023-05-30 22:04:50 +0200gurkenglas(~user@dynamic-046-114-181-050.46.114.pool.telefonica.de)
2023-05-30 22:05:29 +0200 <geekosaur> sounds like my attitude toward posix, except mine includes that it's not even a tech standard
2023-05-30 22:08:35 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de)
2023-05-30 22:10:14 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:3dda:98a9:2443:29bc) (Remote host closed the connection)
2023-05-30 22:10:50 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-05-30 22:15:21 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds)
2023-05-30 22:18:50 +0200darchitect1(~darchitec@2a00:23c6:3584:df01:25bf:d476:680b:8299)
2023-05-30 22:19:21 +0200 <darchitect1> hey guys, has anyone seen Robert Harper's Practical Foundations for Programming Languages in lectures ?
2023-05-30 22:23:00 +0200 <darchitect1> there he mentions the fact that Haskell has `undefined` and is lazy by default makes it unable to have inductive types, but I didn't quite get why he reached this conclusion...
2023-05-30 22:23:52 +0200 <darchitect1> any clarification or rebutal would be welcome :)
2023-05-30 22:25:39 +0200 <merijn> darchitect1: Harper is a very smart and knowledgeable person, hampered by his personal grudge/vendetta against haskell, because he's mad (S)ML lost the popularity contest :p
2023-05-30 22:26:15 +0200 <merijn> darchitect1: So he makes a big deal of several haskell flaws/problems that are "technically correct, but practically irrelevant"
2023-05-30 22:26:53 +0200jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Read error: Connection reset by peer)
2023-05-30 22:27:27 +0200jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-05-30 22:27:31 +0200 <merijn> darchitect1: The problem is that laziness + undefined combined means that, for example, you can never prove a list is finite (the inductive definition of a list would be, by definition)
2023-05-30 22:28:22 +0200 <merijn> darchitect1: in essence, all Haskell datatypes are codata (i.e. possibly infinite in size)
2023-05-30 22:28:34 +0200 <darchitect1> does this matter when proving software to be correct though ?
2023-05-30 22:28:56 +0200 <merijn> darchitect1: Yes, because reasoning about codata is harder than inductive datatypes
2023-05-30 22:29:00 +0200 <geekosaur> yes, if that's what you are doing. if you are solving problems with it, no
2023-05-30 22:29:01 +0200 <darchitect1> as in - does that make Haskell more "unsafe" than OCaml in practice when it comes to software verification
2023-05-30 22:29:23 +0200 <merijn> darchitect1: Not (necessarily) more unsafe, but certainly harder to prove the same things
2023-05-30 22:29:47 +0200 <darchitect1> alright I think I'm getting the gist of it
2023-05-30 22:29:49 +0200 <darchitect1> one more q
2023-05-30 22:30:06 +0200 <darchitect1> (again I'm pretty no to PL so bare with me if it's a stupid one)
2023-05-30 22:30:09 +0200phma(phma@2001:5b0:211c:ea78:b455:bfa2:d6ff:5b73) (Read error: Connection reset by peer)
2023-05-30 22:30:10 +0200 <darchitect1> new *
2023-05-30 22:30:18 +0200 <geekosaur> flip side, purity makes it easier to prove some things you can't prove in OCaml or SML because it's impure and might do IO anywhere
2023-05-30 22:30:29 +0200 <geekosaur> so it's a tradeoff
2023-05-30 22:30:41 +0200 <merijn> geekosaur: Sure, but that goes against Harper's haskell-grudge, so he's not gonna call that out ;)
2023-05-30 22:30:49 +0200 <geekosaur> exactly
2023-05-30 22:31:07 +0200 <geekosaur> remember I was in the building next to his for ~15 years 🙂
2023-05-30 22:31:21 +0200 <geekosaur> hobnobbing with his students
2023-05-30 22:31:38 +0200 <darchitect1> geekosaur: nice
2023-05-30 22:31:47 +0200 <EvanR> an angry mob appears, blames undefined, and removes it from the language. Meanwhile we have unsafePerformIO and unsafeCoerce
2023-05-30 22:32:11 +0200 <darchitect1> what about DSLs written in Haskell
2023-05-30 22:32:12 +0200 <EvanR> sorry for using "whataboutism"
2023-05-30 22:32:24 +0200Feuermagier_(~Feuermagi@user/feuermagier)
2023-05-30 22:32:51 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-05-30 22:32:58 +0200 <darchitect1> say I have a less expressive DSL in Haskell, does the fact that we have undefined and lazy by default mean it will be hard to prove things about the DSL because it's implemented in Haskell ?
2023-05-30 22:33:00 +0200 <geekosaur> you can choose not to import those, you can't choose not to import nontermination
2023-05-30 22:33:13 +0200 <ncf> it's not like ML-style language are total anyway
2023-05-30 22:33:17 +0200 <geekosaur> then again you can't in SML anyuway
2023-05-30 22:33:18 +0200 <ncf> languages*
2023-05-30 22:33:20 +0200 <merijn> darchitect1: Nope, it does mean it'll be trickier to prove your DSL implementation conforms to your spec
2023-05-30 22:33:20 +0200 <geekosaur> either
2023-05-30 22:34:14 +0200 <merijn> darchitect1: there's 2 different meta levels: proving something about a formal system (i.e., your DSL) and proving that some artifact actually *implements* a formal system as specified
2023-05-30 22:34:20 +0200 <darchitect1> would it be any easier in OCaml?
2023-05-30 22:34:44 +0200 <merijn> darchitect1: The former depends solely on your formal system (DSL), the latter would also depend on your implementation language (i.e. Haskell)
2023-05-30 22:34:56 +0200Feuermagier(~Feuermagi@user/feuermagier) (Ping timeout: 246 seconds)
2023-05-30 22:34:56 +0200 <EvanR> if someone is saying haskell can't properly do inductive types, they are probably alluding to languages like Coq which is dependently typed and designed to prove things
2023-05-30 22:35:15 +0200 <EvanR> not ocaml
2023-05-30 22:35:36 +0200 <merijn> darchitect1: Incidentally, if your studying formal proofs, etc. let me also highly recommend the insightful paper "Fast and Loose Reasoning is Morally Correct"
2023-05-30 22:35:42 +0200 <ncf> or agda, to stay within haskell territory
2023-05-30 22:36:05 +0200 <darchitect1> merijn: will do! thanks
2023-05-30 22:36:15 +0200Pickchea(~private@user/pickchea)
2023-05-30 22:36:42 +0200 <merijn> darchitect1: Which (partially) justifies reasoning/pretending Haskell is total, despite it obviously not being total
2023-05-30 22:37:08 +0200 <EvanR> you can and should write total functions in any language!
2023-05-30 22:37:24 +0200 <EvanR> unless it's elixir because let it crash
2023-05-30 22:37:34 +0200 <merijn> EvanR: I'm trying, but TIS-100 is very hard ;_;
2023-05-30 22:37:40 +0200 <EvanR> lol
2023-05-30 22:37:46 +0200 <darchitect1> I was only wondering because I like both OCaml (modules and great imperative support) and Haskell (beauty :D ) and wanted to know if both languages are in the sweet spot of productivity + math rigor or there are clear benefits to using one over the other for general use cases where correctness is critical without sacrificing performance or clarity
2023-05-30 22:38:20 +0200 <merijn> darchitect1: They're about the same, tbh
2023-05-30 22:38:22 +0200 <EvanR> in haskell you control how lazy and how total your code is
2023-05-30 22:38:41 +0200 <EvanR> as long as you don't download anyone's code
2023-05-30 22:38:51 +0200 <merijn> darchitect1: FYI, haskell has great imperative support to :p
2023-05-30 22:38:52 +0200 <darchitect1> EvanR: what exactly does total mean ? no libs ?
2023-05-30 22:39:05 +0200 <EvanR> a total function is defined for all its inputs
2023-05-30 22:39:09 +0200 <merijn> darchitect1: And STM! And purity by default is smart
2023-05-30 22:39:34 +0200 <EvanR> practically, it returns an answer in finite time
2023-05-30 22:39:41 +0200 <merijn> darchitect1: I'd say overall Haskell is slightly nicer and more practical
2023-05-30 22:39:45 +0200 <darchitect1> merijn: yeah, I like the monadic way and do notation, but maybe I'm just too used to fors and whiles
2023-05-30 22:39:47 +0200 <darchitect1> :D
2023-05-30 22:39:59 +0200 <darchitect1> + refs and pointers
2023-05-30 22:40:01 +0200 <merijn> @hackage monad-loops
2023-05-30 22:40:01 +0200 <lambdabot> https://hackage.haskell.org/package/monad-loops
2023-05-30 22:40:15 +0200 <merijn> darchitect1: But you get refs and pointers in Haskell too :p
2023-05-30 22:40:23 +0200 <merijn> darchitect1: Like 8 different flavours even
2023-05-30 22:40:23 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 240 seconds)
2023-05-30 22:43:30 +0200 <darchitect1> will have a look at that
2023-05-30 22:43:52 +0200 <darchitect1> thanks a lot !
2023-05-30 22:52:02 +0200chomwitt(~chomwitt@ppp-94-67-203-168.home.otenet.gr) (Remote host closed the connection)
2023-05-30 22:52:39 +0200darchitect1(~darchitec@2a00:23c6:3584:df01:25bf:d476:680b:8299) (Ping timeout: 250 seconds)
2023-05-30 22:56:59 +0200redmp(~redmp@mobile-166-137-179-122.mycingular.net) (Quit: leaving)
2023-05-30 23:00:45 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-05-30 23:05:57 +0200statusbot9(~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com)
2023-05-30 23:06:09 +0200AlexNoo_(~AlexNoo@178.34.163.104)
2023-05-30 23:06:49 +0200pavonia_(~user@user/siracusa)
2023-05-30 23:06:56 +0200hgolden_(~hgolden@cpe-172-251-233-141.socal.res.rr.com)
2023-05-30 23:07:10 +0200hometown(~blurb@96.45.2.121)
2023-05-30 23:07:14 +0200bollu0(~bollu@159.65.151.13)
2023-05-30 23:07:21 +0200bramhaag4(~bramhaag@134.195.121.39)
2023-05-30 23:07:33 +0200russruss5(~russruss@my.russellmcc.com)
2023-05-30 23:07:36 +0200kimiamania6(~65804703@user/kimiamania)
2023-05-30 23:07:37 +0200oo_miguel1(~Thunderbi@77.252.47.84)
2023-05-30 23:07:38 +0200finnekit2(~finnekit@fsf/member/finnekit)
2023-05-30 23:07:42 +0200EsoAlgo81(~EsoAlgo@129.146.136.145)
2023-05-30 23:07:51 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-05-30 23:07:55 +0200elkcl_(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru)
2023-05-30 23:07:57 +0200malte_(~malte@mal.tc)
2023-05-30 23:07:58 +0200remexre_(~remexre@mail.sift.net)
2023-05-30 23:08:01 +0200eL_Bart0-(eL_Bart0@dietunichtguten.org)
2023-05-30 23:08:22 +0200jbalint_(~jbalint@2600:6c44:117f:e98a:816a:9488:fb1:7b7)
2023-05-30 23:08:31 +0200bgamari(~bgamari@64.223.233.113)
2023-05-30 23:08:37 +0200kaskal(~kaskal@2001:4bb8:2dd:a79d:1a7:8529:b79b:cfa)
2023-05-30 23:08:38 +0200B-J(~BenziJuni@88-149-64-165.du.xdsl.is)
2023-05-30 23:08:52 +0200kadobanana(~mud@user/kadoban)
2023-05-30 23:08:55 +0200phma(~phma@2001:5b0:2143:ed58:27b1:77ae:44a6:25c1)
2023-05-30 23:08:58 +0200urdh_(~urdh@user/urdh)
2023-05-30 23:09:12 +0200swistak-(~swistak@185.21.216.141)
2023-05-30 23:10:01 +0200telser_(~quassel@user/telser)
2023-05-30 23:11:00 +0200_koolazer(~koo@user/koolazer)
2023-05-30 23:11:01 +0200finstern1s(~X@23.226.237.192)
2023-05-30 23:11:06 +0200ystael_(~ystael@user/ystael)
2023-05-30 23:11:06 +0200hpc_(~juzz@ip98-169-35-163.dc.dc.cox.net)
2023-05-30 23:11:15 +0200aweinsto1k(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com)
2023-05-30 23:11:38 +0200Gremlin8583(~Gremlin84@c-73-243-250-212.hsd1.co.comcast.net)
2023-05-30 23:12:13 +0200Alex_test_(~al_test@178.34.163.104)
2023-05-30 23:14:37 +0200noteness-(~noteness@user/noteness)
2023-05-30 23:16:03 +0200pavonia(~user@user/siracusa) (*.net *.split)
2023-05-30 23:16:03 +0200oo_miguel(~Thunderbi@77.252.47.84) (*.net *.split)
2023-05-30 23:16:03 +0200kluk(~arrowhead@cpe-74-66-76-151.nyc.res.rr.com) (*.net *.split)
2023-05-30 23:16:03 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (*.net *.split)
2023-05-30 23:16:03 +0200ystael(~ystael@user/ystael) (*.net *.split)
2023-05-30 23:16:03 +0200pyook(~puke@user/puke) (*.net *.split)
2023-05-30 23:16:03 +0200davean(~davean@davean.sciesnet.net) (*.net *.split)
2023-05-30 23:16:03 +0200Benzi-Junior(~BenziJuni@88-149-64-165.du.xdsl.is) (*.net *.split)
2023-05-30 23:16:03 +0200telser(~quassel@user/telser) (*.net *.split)
2023-05-30 23:16:03 +0200Alex_test(~al_test@178.34.163.104) (*.net *.split)
2023-05-30 23:16:03 +0200offtherock(~blurb@96.45.2.121) (*.net *.split)
2023-05-30 23:16:03 +0200dsrt^(~dsrt@c-71-204-38-59.hsd1.ga.comcast.net) (*.net *.split)
2023-05-30 23:16:03 +0200son0p(~ff@181.136.122.143) (*.net *.split)
2023-05-30 23:16:03 +0200hgolden(~hgolden@cpe-172-251-233-141.socal.res.rr.com) (*.net *.split)
2023-05-30 23:16:03 +0200russruss(~russruss@my.russellmcc.com) (*.net *.split)
2023-05-30 23:16:03 +0200bgamari_(~bgamari@64.223.233.113) (*.net *.split)
2023-05-30 23:16:03 +0200hpc(~juzz@ip98-169-35-163.dc.dc.cox.net) (*.net *.split)
2023-05-30 23:16:03 +0200finnekit(~finnekit@fsf/member/finnekit) (*.net *.split)
2023-05-30 23:16:03 +0200statusbot(~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (*.net *.split)
2023-05-30 23:16:03 +0200jbalint(~jbalint@071-090-119-177.res.spectrum.com) (*.net *.split)
2023-05-30 23:16:03 +0200EsoAlgo8(~EsoAlgo@129.146.136.145) (*.net *.split)
2023-05-30 23:16:03 +0200mud(~mud@user/kadoban) (*.net *.split)
2023-05-30 23:16:03 +0200eL_Bart0(eL_Bart0@dietunichtguten.org) (*.net *.split)
2023-05-30 23:16:03 +0200kaskal-(~kaskal@213-147-167-98.nat.highway.webapn.at) (*.net *.split)
2023-05-30 23:16:03 +0200elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (*.net *.split)
2023-05-30 23:16:03 +0200Putonlalla(~Putonlall@it-cyan.it.jyu.fi) (*.net *.split)
2023-05-30 23:16:03 +0200koolazer(~koo@user/koolazer) (*.net *.split)
2023-05-30 23:16:03 +0200bramhaag(~bramhaag@134.195.121.39) (*.net *.split)
2023-05-30 23:16:03 +0200shailangsa(~shailangs@host86-186-133-102.range86-186.btcentralplus.com) (*.net *.split)
2023-05-30 23:16:03 +0200kimiamania(~65804703@user/kimiamania) (*.net *.split)
2023-05-30 23:16:03 +0200aweinstock(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (*.net *.split)
2023-05-30 23:16:03 +0200AlexNoo(~AlexNoo@178.34.163.104) (*.net *.split)
2023-05-30 23:16:03 +0200remexre(~remexre@user/remexre) (*.net *.split)
2023-05-30 23:16:04 +0200finsternis(~X@23.226.237.192) (*.net *.split)
2023-05-30 23:16:04 +0200Gremlin8483(~Gremlin84@c-73-243-250-212.hsd1.co.comcast.net) (*.net *.split)
2023-05-30 23:16:04 +0200urdh(~urdh@user/urdh) (*.net *.split)
2023-05-30 23:16:04 +0200swistak(~swistak@185.21.216.141) (*.net *.split)
2023-05-30 23:16:04 +0200malte(~malte@mal.tc) (*.net *.split)
2023-05-30 23:16:04 +0200Typedfern(~Typedfern@60.red-83-37-32.dynamicip.rima-tde.net) (*.net *.split)
2023-05-30 23:16:04 +0200noteness_(~noteness@user/noteness) (*.net *.split)
2023-05-30 23:16:04 +0200bollu(~bollu@159.65.151.13) (*.net *.split)
2023-05-30 23:16:05 +0200bramhaag4bramhaag
2023-05-30 23:16:05 +0200russruss5russruss
2023-05-30 23:16:06 +0200oo_miguel1oo_miguel
2023-05-30 23:16:06 +0200urdh_urdh
2023-05-30 23:16:06 +0200remexre_remexre
2023-05-30 23:16:06 +0200EsoAlgo81EsoAlgo8
2023-05-30 23:16:06 +0200finnekit2finnekit
2023-05-30 23:16:06 +0200elkcl_elkcl
2023-05-30 23:16:06 +0200kimiamania6kimiamania
2023-05-30 23:16:07 +0200malte_malte
2023-05-30 23:16:07 +0200bollu0bollu
2023-05-30 23:16:07 +0200finstern1sfinsternis
2023-05-30 23:17:12 +0200dsrt^(~dsrt@c-71-204-38-59.hsd1.ga.comcast.net)
2023-05-30 23:18:56 +0200Ranhir(~Ranhir@157.97.53.139)
2023-05-30 23:19:47 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2023-05-30 23:21:00 +0200MQ-17J(~MQ-17J@104.28.248.166)
2023-05-30 23:21:06 +0200MQ-17J(~MQ-17J@104.28.248.166) (Client Quit)
2023-05-30 23:21:53 +0200Typedfern(~Typedfern@60.red-83-37-32.dynamicip.rima-tde.net)
2023-05-30 23:22:59 +0200davean(~davean@davean.sciesnet.net)
2023-05-30 23:23:01 +0200Putonlalla(~Putonlall@it-cyan.it.jyu.fi)
2023-05-30 23:23:37 +0200myxos_(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-05-30 23:24:14 +0200myxos_(~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit)
2023-05-30 23:26:36 +0200myxokephale(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-05-30 23:26:52 +0200myxokephale(~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit)
2023-05-30 23:27:02 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Quit: myxos)
2023-05-30 23:27:16 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-05-30 23:27:46 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Client Quit)
2023-05-30 23:28:29 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-05-30 23:28:40 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-05-30 23:29:59 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-05-30 23:31:21 +0200Headlights(~Headlight@37.182.188.207)
2023-05-30 23:32:23 +0200mei(~mei@user/mei)
2023-05-30 23:38:45 +0200michalz(~michalz@185.246.204.93) (Ping timeout: 240 seconds)
2023-05-30 23:39:27 +0200Headlights(~Headlight@37.182.188.207) (Leaving)
2023-05-30 23:43:48 +0200ubert(~Thunderbi@p548c91e0.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
2023-05-30 23:43:52 +0200ub(~Thunderbi@p200300ecdf00029cf94c40b268cbf3ca.dip0.t-ipconnect.de)
2023-05-30 23:46:10 +0200ububert
2023-05-30 23:50:08 +0200shailangsa_(~shailangs@host86-186-133-102.range86-186.btcentralplus.com)
2023-05-30 23:50:27 +0200hpc_hpc
2023-05-30 23:59:56 +0200TMA(tma@twin.jikos.cz)