2022/10/29

2022-10-29 00:00:13 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-10-29 00:00:13 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-10-29 00:00:13 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 00:03:44 +0200michalz(~michalz@185.246.207.200) (Remote host closed the connection)
2022-10-29 00:03:48 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 00:04:24 +0200fjmorazan(~quassel@user/fjmorazan) ()
2022-10-29 00:05:08 +0200fjmorazan(~quassel@user/fjmorazan)
2022-10-29 00:06:25 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 246 seconds)
2022-10-29 00:06:26 +0200talismanick(~talismani@76.133.152.122)
2022-10-29 00:07:30 +0200axeman(~quassel@ip-037-201-153-145.um10.pools.vodafone-ip.de)
2022-10-29 00:08:24 +0200acidjnk_new3(~acidjnk@p200300d6e7137a26d59898e5c9870d6b.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
2022-10-29 00:09:44 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2022-10-29 00:11:20 +0200pavonia(~user@user/siracusa)
2022-10-29 00:11:39 +0200polo(~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2022-10-29 00:12:07 +0200polo(~polo@user/polo)
2022-10-29 00:13:15 +0200 <cpli> is there some `TChan A -> TChan A -> TChan A` which fuses two channels?
2022-10-29 00:13:28 +0200 <cpli> i.e. for writing purposes only
2022-10-29 00:14:16 +0200 <cpli> dup and clone exist, would fusing require doing so on a seperate thread?
2022-10-29 00:14:33 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:41f8:4e00:54f7:b844)
2022-10-29 00:15:41 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 00:15:42 +0200 <EvanR> what does fusing for writing purpose mean
2022-10-29 00:15:53 +0200 <dminuoso> Or for reading purposes.
2022-10-29 00:16:06 +0200 <EvanR> or append purpose
2022-10-29 00:16:10 +0200 <dminuoso> That is, if both channels have multiple things, in what order should they read?
2022-10-29 00:16:40 +0200 <dminuoso> Looking at the internals, I think you can construct an interleaving TChan without a thread
2022-10-29 00:16:54 +0200 <DigitalKiwi> no append only prepend
2022-10-29 00:17:08 +0200 <EvanR> this is haskell we can only prepend
2022-10-29 00:17:17 +0200 <DigitalKiwi> :D
2022-10-29 00:17:58 +0200 <EvanR> haskellOS
2022-10-29 00:18:09 +0200 <EvanR> all the files are stored backwards
2022-10-29 00:18:35 +0200 <dminuoso> Well anyway, an interleaving TChan could be constructed if the internals were exposed in Control.Concurrent.STM.TChan
2022-10-29 00:18:44 +0200 <dminuoso> But they are not, so I guess you're out of luck either way
2022-10-29 00:18:53 +0200 <dminuoso> I dont see a way without a separate thread doing what you want
2022-10-29 00:19:08 +0200 <DigitalKiwi> https://mostlyabsurd.com/files/2022-10-28-171849_964x357_scrot.png
2022-10-29 00:19:08 +0200polo(~polo@user/polo) (Ping timeout: 276 seconds)
2022-10-29 00:20:16 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 00:20:53 +0200 <cpli> re:dminuoso "..., in what order should they read?"; in order they were written
2022-10-29 00:21:07 +0200 <dminuoso> cpli: What does that even mean in STM?
2022-10-29 00:22:27 +0200 <cpli> i have a `[Backend]` where `data Backend = B1 B1State | B2 B2State | B3...`
2022-10-29 00:22:50 +0200 <cpli> each `Backend` broadcasts its event to all other backends
2022-10-29 00:23:16 +0200 <dsal> "order" over distinct things (e.g., two threads with two channels) is a coincidence when you observe it.
2022-10-29 00:23:22 +0200 <cpli> in some wrapper `data Event = E1 FromB1 | E2 FromB2`
2022-10-29 00:23:48 +0200 <cpli> all backends are concurrently executed
2022-10-29 00:23:59 +0200 <dminuoso> cpli: STM works differently
2022-10-29 00:24:07 +0200 <dminuoso> It's not just barriers.
2022-10-29 00:25:01 +0200 <cpli> is there any <10min read on how to impl async broadcasting?
2022-10-29 00:25:51 +0200 <dsal> The stm docs are pretty clear. You just dup a chan and write to it.
2022-10-29 00:26:05 +0200 <monochrom> There is no need to "merge" two TChans. Instead, to read from both TChans with "whichever one has a message first, read it", use atomically (fmap Left readTChan c1 <|> fmap Right readTChan c2) or equivalent.
2022-10-29 00:26:08 +0200 <int-e> DigitalKiwi: 4 centuries earlier: REPENT! REPENT!
2022-10-29 00:26:11 +0200 <cpli> if i write to a chan and immediately read, do i read my own message?
2022-10-29 00:26:26 +0200 <dsal> https://hackage.haskell.org/package/stm-2.5.1.0/docs/Control-Concurrent-STM-TChan.html#v:dupTChan
2022-10-29 00:26:45 +0200 <dminuoso> monochrom: Im not sure "first" really applies.
2022-10-29 00:26:49 +0200 <DigitalKiwi> https://twitter.com/ArchKiwi/status/1586120762544398336
2022-10-29 00:27:05 +0200 <monochrom> Sure, s/first/"first"
2022-10-29 00:27:14 +0200 <dminuoso> monochrom: Consider the case where first `c2` has a message, the stm transaction proceeds, but gets retried.
2022-10-29 00:27:43 +0200 <dminuoso> Is there any guarantee c2 will be picked again, even if after retrying c1 has a message?
2022-10-29 00:28:00 +0200 <dsal> cpli: maybe? You've not shown enough code to say for sure.
2022-10-29 00:28:56 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Remote host closed the connection)
2022-10-29 00:29:29 +0200 <dsal> dminuoso: I'm pretty sure that code won't read from c2 until c1 is empty. To make that fairer, you could put the channels in a queue of some sort and make sure each time a channel is read from it goes to the end of the list.
2022-10-29 00:29:41 +0200 <dsal> Doing the go thing of "randomly pick a ready channel" might be a little harder.
2022-10-29 00:29:52 +0200 <dminuoso> dsal: well, if c1 is empty at the time the transaction is started
2022-10-29 00:30:00 +0200 <dminuoso> but has data when its retried.
2022-10-29 00:30:23 +0200 <dminuoso> The only way I can see fairness is if you put them into a single list with a tag
2022-10-29 00:30:28 +0200 <dminuoso> Then you can preserve the original order.
2022-10-29 00:30:50 +0200 <monochrom> Oh the beauty is that every observation can be explained away by a fictional sequence, and you have no way to refute it, right?
2022-10-29 00:31:00 +0200 <monochrom> or fictional history.
2022-10-29 00:32:48 +0200thyriaen_(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-10-29 00:32:49 +0200buffet(~buffet@buffet.sh)
2022-10-29 00:32:52 +0200 <dminuoso> cpli: So yeah I guess thats the real answer. Keep a single TChan and have all write into that, and then each backend would have a dupTChan'ed or newBroadcastTChan'ed reader.
2022-10-29 00:33:00 +0200 <dsal> I've never had to care about a particular ordering of channel ops, so I've not thought too much about avoiding having one get behind. One approach might be to atomically read from multiple and make a decision as to which one you want based on data inside.
2022-10-29 00:33:23 +0200 <dminuoso> cpli: (so the merging happens by fact of just writing into a single TChan)
2022-10-29 00:33:37 +0200 <dsal> Yeah, that's a lot easier. :)
2022-10-29 00:33:41 +0200 <monochrom> Right? "Is c2 really ready earlier?" is just philosophy. The computer science question is "if empirically you get Right, can we restrospectively make up a story that says c2 is ready earlier?" and the answer is yes.
2022-10-29 00:33:57 +0200polo(~polo@user/polo)
2022-10-29 00:34:42 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 00:34:52 +0200 <dsal> I've got into a lot of arguments with people who just want to overwrite the state with "whatever happened last" and it's really hard to explain to people how that doesn't work.
2022-10-29 00:34:59 +0200 <dminuoso> cpli: more to the point, set up that `TChan Event` with newBroadcastTChan (instead of newTChan) and then dupChan it for every backend. :)
2022-10-29 00:35:25 +0200 <dminuoso> dsal: You can just fling an IORef around!
2022-10-29 00:35:53 +0200 <dminuoso> And to silence any arguments, unsafeIOtoSTM all evil operations and do this in STM for maximum confusion.
2022-10-29 00:36:01 +0200 <dsal> A guy on my team once made a model of our system that let someone single step through every decision with business folks nodding that it was doing what they want and then get to the last bit and it all falls apart and they just assume it's a bug that needs to be fixed.
2022-10-29 00:37:01 +0200 <dsal> You could always have a PNRG in your STM state and change the ordering along the way.
2022-10-29 00:37:24 +0200pyrex(~pyrex@user/pyrex)
2022-10-29 00:39:17 +0200 <dminuoso> Why settle for a PRNG?
2022-10-29 00:39:31 +0200 <dminuoso> unsafeIOtoSTM that quantum RNG :)
2022-10-29 00:39:38 +0200 <monochrom> Haha
2022-10-29 00:39:48 +0200 <cpli> dsal: not enough code
2022-10-29 00:39:49 +0200 <cpli> run :: [Backend] → IO ()
2022-10-29 00:39:50 +0200 <cpli> run bs = let
2022-10-29 00:39:50 +0200 <cpli> withChannel :: [(Chan Event, Backend)]
2022-10-29 00:39:50 +0200 <cpli> withChannel = (newChan,) <$> bs
2022-10-29 00:39:50 +0200 <cpli> -- what would i do here, such that
2022-10-29 00:39:50 +0200 <cpli> -- bn <- bm where N /= M
2022-10-29 00:39:50 +0200 <cpli> in mapConcurrently_ (uncurry runBackend) withChannel
2022-10-29 00:39:51 +0200 <cpli> runBackend :: Chan Event → Backend → IO ()
2022-10-29 00:39:51 +0200 <cpli> runBackend ch (B1 b) = runB1 ch b
2022-10-29 00:39:52 +0200 <cpli> runBackend ch (B2 b) = runB2 ch b
2022-10-29 00:39:52 +0200 <cpli> -- ...
2022-10-29 00:40:48 +0200 <cpli> dminuoso: if i simply `dupChan` then every backend needs to take `N-1` reading channels from all the other backends
2022-10-29 00:41:00 +0200 <dminuoso> cpli: No, you seem to misunderstand.
2022-10-29 00:41:01 +0200 <monochrom> That may break the Copenhagen interpretation >:)
2022-10-29 00:41:04 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com)
2022-10-29 00:41:33 +0200 <dminuoso> cpli: First you start with one writer TChan, set it up with newBroadcastTChan (this is important!), this will get passed along to every backend.
2022-10-29 00:41:47 +0200 <cpli> understood.
2022-10-29 00:41:54 +0200 <dminuoso> cpli: Then, for every backend, you provide a dupTChan of that original chan, which will - for each backend - be a reader.
2022-10-29 00:42:23 +0200 <dminuoso> s/for each backend/for each respective backend/
2022-10-29 00:43:04 +0200 <dminuoso> So if you want to broadcast, you write to that first writer tchan, and to listen to events you just read from that local reader tchan
2022-10-29 00:43:52 +0200 <dminuoso> so each backend has exactly one writer and one reader channel
2022-10-29 00:48:35 +0200 <cpli> and if i `runBackend1 :: Chan Event → Backend1 → IO ()
2022-10-29 00:48:35 +0200 <cpli> runBackend1 ch b = race (async (readChan ch)) awaitBackendEvent
2022-10-29 00:48:49 +0200 <cpli> sorry for formatting
2022-10-29 00:49:07 +0200 <cpli> that code isn't really done
2022-10-29 00:49:23 +0200 <cpli> the idea is that events from the backend are then written into the channel again
2022-10-29 00:50:27 +0200 <cpli> more akin to:
2022-10-29 00:50:27 +0200 <cpli> runBackend1 :: Chan Event → Backend1 → IO ()
2022-10-29 00:50:27 +0200 <cpli> runBackend1 ch b = forever $ race (readChan ch)
2022-10-29 00:50:27 +0200 <cpli> (writeChan ch =<< awaitBackendEvent)
2022-10-29 00:51:31 +0200 <cpli> or in your case dminuoso:
2022-10-29 00:51:33 +0200 <cpli> runBackend1 :: Chan Event → Chan Event → Backend1 → IO ()
2022-10-29 00:51:33 +0200 <cpli> runBackend1 wch rch b = forever $ race (readChan rch)
2022-10-29 00:51:33 +0200 <cpli> (writeChan wch =<< awaitBackendEvent)
2022-10-29 00:52:04 +0200 <dminuoso> That looks a bit strange
2022-10-29 00:52:17 +0200 <dminuoso> Is the `rch` another channel?
2022-10-29 00:52:21 +0200 <cpli> don't `Event`s from `wch` don't simply end up back in `rch`?
2022-10-29 00:52:35 +0200 <dminuoso> Sure, you need to filter them out.
2022-10-29 00:52:42 +0200 <cpli> and `unGet` them?
2022-10-29 00:53:19 +0200 <dminuoso> No, you just read them again.
2022-10-29 00:53:36 +0200 <cpli> oh true
2022-10-29 00:53:41 +0200 <cpli> sure
2022-10-29 00:53:55 +0200 <cpli> kind of a hassle to have to
2022-10-29 00:54:17 +0200 <cpli> but the events are sure to arrive at the other threads nonetheless
2022-10-29 00:54:31 +0200 <dminuoso> Of course, that's what dupTChan is for
2022-10-29 00:54:43 +0200 <dminuoso> It lets you set up broadcast semantics exactly like that
2022-10-29 00:54:53 +0200polo(~polo@user/polo) (Ping timeout: 276 seconds)
2022-10-29 00:56:32 +0200 <cpli> the entire idea with "fuse" would've been to do what you meant, i.e. to `newBroadcastTChan` then `dupTChan` until you'd have a list of "RChan"s from all *other backends* and fuse those together to create a `Chan` for `bn` which would only recieve all events from `bm` where `n /= m`
2022-10-29 00:56:54 +0200 <cpli> but i guess just filtering out your own events is simpler
2022-10-29 00:57:12 +0200 <dminuoso> Yup, it doesnt need a n helper threads to set up
2022-10-29 00:57:36 +0200 <dminuoso> or I guess just a singular dispatcher thread
2022-10-29 00:57:38 +0200 <cpli> probably possible to solve in data, no?
2022-10-29 00:58:15 +0200 <dminuoso> I would only pursue the dispatcher model if you had more unicast semantics
2022-10-29 00:58:20 +0200 <dminuoso> but if everything is broadcast, this is the simpler way
2022-10-29 00:58:37 +0200 <dminuoso> cpli: Also, this model preserves event order properly
2022-10-29 00:58:47 +0200 <dminuoso> your other approach does not
2022-10-29 00:59:03 +0200 <cpli> *would* not, since it doesn't seem to exist
2022-10-29 00:59:14 +0200 <dminuoso> of course it does.
2022-10-29 00:59:24 +0200nek0(~nek0@2a01:4f8:222:2b41::12)
2022-10-29 00:59:25 +0200 <dminuoso> its preserved in the order of which elements are read out
2022-10-29 01:00:05 +0200 <dminuoso> I mean yeah, ultimately you could still have write problems if there's any coordination/communication between the backends with retries going on
2022-10-29 01:00:11 +0200 <cpli> would an optimization be to include the read in the write case? i.e. immediately read after writing to the `Chan- i don't have guarantees about my event being next ever..
2022-10-29 01:00:30 +0200 <dminuoso> What do you mean "to include the read in the write case"?
2022-10-29 01:00:46 +0200 <dsal> No, if you want to ignore particular messages, you have to ignore the particular messages. You can't rely on timing.
2022-10-29 01:01:34 +0200 <dminuoso> Oh you mean as a means to consume the element you have just written?
2022-10-29 01:02:37 +0200 <cpli> `bn` writes to `wch` and read from `rch`, `bm` will recieve the event, but `bn` also *will* recieve its own message, `bn` wouldn't need to read its message in its "read thread" if it could immediately could remove the message from `rch`
2022-10-29 01:02:42 +0200 <cpli> but there's no guarantee
2022-10-29 01:03:00 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:f81b:3b92:bbe7:93b6) (Remote host closed the connection)
2022-10-29 01:03:33 +0200 <cpli> also `rch` could be clogged up anyway, with 15 events "in queue" in which case the event pushed to `wch` wouldn't be the next in line anyways
2022-10-29 01:03:41 +0200 <dminuoso> cpli: https://gist.github.com/dminuoso/f42f92a27457088ce0d927175d7a21fc
2022-10-29 01:03:43 +0200 <dminuoso> Something along these lines
2022-10-29 01:03:55 +0200danza(~francesco@151.68.150.173) (Ping timeout: 272 seconds)
2022-10-29 01:04:34 +0200 <dminuoso> cpli: oh hold on by the way, we dont even need two separate TChans!
2022-10-29 01:04:43 +0200 <dminuoso> Just the dupTChan'ed channel will serve both!
2022-10-29 01:04:48 +0200 <dminuoso> simplifying things even further.
2022-10-29 01:05:50 +0200 <cpli> `atomically` such that no events may be written to the channels whilst initializing them?
2022-10-29 01:06:58 +0200 <dminuoso> cpli: No, its just that newBroadcastTChan must occur inside STM.
2022-10-29 01:07:00 +0200 <dminuoso> And dupTChan
2022-10-29 01:07:38 +0200 <cpli> what stops this from being non-STM, multithreading?
2022-10-29 01:08:02 +0200 <dminuoso> cpli: Ive updated the gist, feel free to reload
2022-10-29 01:08:35 +0200 <dminuoso> cpli: TChan is an STM data structure.
2022-10-29 01:08:56 +0200 <dminuoso> You dont have to use STM everywhere, just in the few parts where you interact with it.
2022-10-29 01:08:59 +0200redmp(~redmp@eduroam-169-233-187-108.ucsc.edu) (Ping timeout: 272 seconds)
2022-10-29 01:10:33 +0200j4cc3b(~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net)
2022-10-29 01:10:49 +0200 <cpli> "TChan", "STM.TChan". yes, and multithreading requires STM, I assume
2022-10-29 01:11:00 +0200 <dminuoso> No, we have threads without STM just fine.
2022-10-29 01:11:11 +0200 <dminuoso> STM is just the basis for most our synchronization tools.
2022-10-29 01:11:23 +0200 <dminuoso> Think of STM as setting up transactions around critical sections.
2022-10-29 01:11:55 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-10-29 01:12:00 +0200 <dminuoso> or well, avoiding the need for critical sections, even.
2022-10-29 01:12:32 +0200 <dminuoso> cpli: Basically we have two things at our disposal: We have MVar and STM
2022-10-29 01:12:34 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-10-29 01:13:46 +0200 <dminuoso> Both can help with synchronizing multiple threads. MVar is a really low level primitive that you can build higher primitives around (say like a semaphore), whereas STM is a potent high level framework (its not based on MVar, though)
2022-10-29 01:13:54 +0200 <cpli> oh this is actually way cooler than i expected
2022-10-29 01:14:18 +0200 <cpli> i require awaitEvent :: _ -> IO Event
2022-10-29 01:14:29 +0200 <cpli> actually no
2022-10-29 01:14:49 +0200 <dminuoso> Sure, just wrap the body in `atomically` then you can make it `IO Event`
2022-10-29 01:14:57 +0200 <cpli> this may await an event from `b1` indefinitely
2022-10-29 01:15:12 +0200 <dminuoso> Either would
2022-10-29 01:15:12 +0200 <cpli> whilst `b2` is broadcasting
2022-10-29 01:15:33 +0200 <dminuoso> Why would it?>
2022-10-29 01:16:10 +0200 <cpli> if `b1` recieves an event `FromB1` it creates another `B1Event`
2022-10-29 01:16:36 +0200 <cpli> otherwise `awaitEvent` return the event from `bn`
2022-10-29 01:16:41 +0200Sgeo_(~Sgeo@user/sgeo)
2022-10-29 01:16:41 +0200 <dminuoso> Well, each backend will likely have to run two separate threads, yes.
2022-10-29 01:16:42 +0200danza(~francesco@151.35.98.197)
2022-10-29 01:16:58 +0200 <cpli> and `race` with Control.Concurrent
2022-10-29 01:17:03 +0200 <dminuoso> Or you have some kind of event loop and use tryReadTChan instead
2022-10-29 01:17:49 +0200 <cpli> i think for each backend to either be:
2022-10-29 01:17:55 +0200 <cpli> 1. broadcasting its own event
2022-10-29 01:18:07 +0200 <cpli> 2. processing an event it recieved
2022-10-29 01:18:11 +0200 <cpli> is relatively elgant
2022-10-29 01:18:39 +0200cplithinks their typos probably aren't exactly elegant
2022-10-29 01:19:27 +0200jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2022-10-29 01:19:53 +0200 <dminuoso> cpli: Updated gist
2022-10-29 01:20:04 +0200Sgeo(~Sgeo@user/sgeo) (Ping timeout: 250 seconds)
2022-10-29 01:20:34 +0200 <dminuoso> Whether a simple `runBackend b = forever $ do r <- tryAwaitEvent ...` or STM variant instead makes more sense, depends on what you want to do exactly
2022-10-29 01:20:49 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03)
2022-10-29 01:21:09 +0200 <dminuoso> Also think ahead about things like termination
2022-10-29 01:21:19 +0200 <dminuoso> Might want to include some kind of signaling layer in the event stream
2022-10-29 01:21:38 +0200 <dminuoso> Such that the worker can just stop gracefully, perhaps release resources
2022-10-29 01:21:59 +0200 <cpli> doesn't `TMChan` solve such a scenario?
2022-10-29 01:22:35 +0200 <dminuoso> Sure, if you fancy that.
2022-10-29 01:22:39 +0200 <dminuoso> I would probably just roll my own
2022-10-29 01:23:01 +0200 <cpli> i have to admit i don't know why you're checking if eventTag e == backendTag (bwcBackend b)
2022-10-29 01:23:11 +0200 <dminuoso> Writing such thing on the spot takes little effort and it helps keep dependency footprints small. And it lets you model your combinators the way you need to.
2022-10-29 01:23:24 +0200 <cpli> if it recieves a message from itself it tries agai-
2022-10-29 01:23:27 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 01:23:28 +0200 <cpli> makes sense.
2022-10-29 01:24:29 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds)
2022-10-29 01:24:43 +0200 <dminuoso> cpli: For elaborate things, you may have to spawn two thread for each backend, potentially with TQueues or things between them for coordinations.
2022-10-29 01:25:00 +0200 <dminuoso> This is all just different options, without knowing what these backends really do its hard to tell
2022-10-29 01:25:01 +0200 <cpli> dminuoso the backends both come from relatively large dependencies, i've come this far only by scouting stackage for package versions that don't clash on their version of `ByteString` and downgrading from ghc 9.4.2 to 9.0.2
2022-10-29 01:25:15 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds)
2022-10-29 01:25:42 +0200 <cpli> they're xmpp and irc
2022-10-29 01:25:47 +0200 <cpli> i'm writing a bridge.
2022-10-29 01:25:53 +0200 <cpli> cat's out the bag
2022-10-29 01:26:04 +0200 <dminuoso> So there's just two backends then?
2022-10-29 01:26:11 +0200 <cpli> well, extensibility
2022-10-29 01:26:21 +0200 <dminuoso> As a kind of star bridge?
2022-10-29 01:26:36 +0200 <cpli> currently my dhall config only lets you specify bots for either backend, but yes, a star bridge
2022-10-29 01:26:44 +0200 <cpli> plans for discord etc
2022-10-29 01:27:11 +0200 <cpli> the thing i want to implement really is proper puppeteering for irc
2022-10-29 01:27:13 +0200 <dminuoso> cpli: I think I would just spawn two threads for each backend.
2022-10-29 01:27:20 +0200 <cpli> exaclty
2022-10-29 01:27:27 +0200 <cpli> s/cl/lc/
2022-10-29 01:27:28 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-10-29 01:27:38 +0200 <dminuoso> Haskell threads are really cheap, so go wild with them.
2022-10-29 01:27:45 +0200 <cpli> they are?
2022-10-29 01:27:53 +0200 <dminuoso> Yes, they are green threads.
2022-10-29 01:28:32 +0200 <cpli> haskell knew of that color before go's implementation?
2022-10-29 01:28:37 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds)
2022-10-29 01:29:01 +0200 <dminuoso> Honestly I dont know of the ethymology. :)
2022-10-29 01:29:18 +0200 <dminuoso> Sorry I should refine. *GHC threads cheap
2022-10-29 01:29:46 +0200 <cpli> it has something to do with async, where threads are coloured red or blue, and state needs to stay in one color
2022-10-29 01:29:55 +0200 <cpli> but green sits on top ignoring all of that
2022-10-29 01:30:07 +0200 <dminuoso> Im almost confident that the name is older than go.
2022-10-29 01:30:46 +0200 <cpli> yup 1997: "Green threads refers to the name of the original thread library for the programming language Java (that was released in version 1.1 and then Green threads were abandoned in version 1.3 to native threads). It was designed by The Green Team at Sun Microsystems."
2022-10-29 01:30:56 +0200 <cpli> from wikipedia the *free* encyclopedia
2022-10-29 01:31:00 +0200 <dminuoso> https://web.archive.org/web/20080530073139/http://java.sun.com/features/1998/05/birthday.html
2022-10-29 01:31:06 +0200 <dminuoso> Well I prefer citing the primary source. :)
2022-10-29 01:31:20 +0200mvk(~mvk@2607:fea8:5ce3:8500::f30b) (Ping timeout: 250 seconds)
2022-10-29 01:31:48 +0200 <cpli> find on page: "green threads" 0/0 results
2022-10-29 01:31:52 +0200 <dminuoso> Heh its funny, isnt it.
2022-10-29 01:32:01 +0200 <dminuoso> Quality control at its finest
2022-10-29 01:32:37 +0200 <dminuoso> cpli: the cool thing about the way things are implemented in haskell, is that you get the best of all worlds combined.
2022-10-29 01:32:59 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-10-29 01:32:59 +0200thyriaen_(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-10-29 01:33:29 +0200 <dminuoso> You can just use blocking IO in threads, and the RTS will be aware of that, use non-blockin IO behind the scenes, schedule threads when data is available again
2022-10-29 01:33:44 +0200 <dminuoso> And you still get parallelism since GHC can use multiple capabilities
2022-10-29 01:33:53 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 276 seconds)
2022-10-29 01:33:55 +0200 <jbggs[m]> I thought red/blue functions was a different thing from green threads
2022-10-29 01:34:16 +0200 <dminuoso> And when I say Haskell, I really mean GHC Haskell.
2022-10-29 01:34:34 +0200 <cpli> systemFω here to save the day
2022-10-29 01:35:03 +0200 <jbggs[m]> i.e. red functions are async functions, which in many languages are run on green threads
2022-10-29 01:35:21 +0200 <cpli> jbggs[m]: i apologise, i relay uncited information.
2022-10-29 01:35:35 +0200 <jbggs[m]> or at least can be
2022-10-29 01:35:59 +0200 <monochrom> amd functions, intel functions, and nvidia threads? >:)
2022-10-29 01:36:04 +0200 <cpli> dminuoso: this is the haskell irc, before i denounce things without thought
2022-10-29 01:36:13 +0200 <cpli> do people here use compilers other than ghc?
2022-10-29 01:36:21 +0200 <dminuoso> monochrom: If you want crazy terminology, look at ARINC 653.
2022-10-29 01:36:55 +0200 <jbggs[m]> I think it's interesting that people are prone to thinking of these things with colors
2022-10-29 01:36:56 +0200 <jbggs[m]> cpli: no harm no foul :D
2022-10-29 01:37:11 +0200 <dminuoso> They contort established terminology to the point where they will sell you a "list" as an "OS process" (slightly exaggerating, but not by much)
2022-10-29 01:37:25 +0200 <monochrom> Oh there are people who listen to music and see colours, too.
2022-10-29 01:37:26 +0200mixfix41(~sdeny9ee@user/mixfix41) (Ping timeout: 260 seconds)
2022-10-29 01:37:40 +0200 <jbggs[m]> I mean they're both functors right :V
2022-10-29 01:37:50 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 01:38:08 +0200 <jbggs[m]> lists and OS processes i mean
2022-10-29 01:38:12 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2022-10-29 01:38:18 +0200 <cpli> jbggs[m]: smells like 2-cats
2022-10-29 01:38:45 +0200 <cpli> sorry, i meant 2d operads
2022-10-29 01:38:49 +0200 <jbggs[m]> 2-cats?
2022-10-29 01:39:11 +0200 <EvanR> cpli, within the atomically, it's like there are no other threads or they don't do anything that matters. So you read what you just wrote. If anything would have happened to change that, the atomically doesn't happen (retry)
2022-10-29 01:39:54 +0200 <dminuoso> *semantically
2022-10-29 01:39:56 +0200 <jbggs[m]> That's a new word for me, operad
2022-10-29 01:39:58 +0200 <cpli> EvanR, if i remember anything correctly STM basically locks for any other thread trying to access the same memory region
2022-10-29 01:40:05 +0200 <dminuoso> cpli: No.
2022-10-29 01:40:08 +0200 <cpli> q-q
2022-10-29 01:40:08 +0200 <dminuoso> cpli: its lock-free.
2022-10-29 01:40:11 +0200 <cpli> q-q
2022-10-29 01:40:16 +0200cpliin awe
2022-10-29 01:40:26 +0200 <EvanR> locking sounds like an implementation thing, which it doesn't use but really shouldn't matter to this story
2022-10-29 01:40:29 +0200 <cpli> wait-free too?
2022-10-29 01:40:38 +0200 <monochrom> Well, I'm fine with a suitable definition of "basically".
2022-10-29 01:41:21 +0200 <EvanR> one slow implementation strategy is to run all STM actions sequentially, perhaps using a shared global lock
2022-10-29 01:42:03 +0200 <monochrom> Basically, if you only notice final answers and don't notice speed, STM gives the same answer as locking.
2022-10-29 01:42:18 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-29 01:42:28 +0200perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2022-10-29 01:42:39 +0200 <monochrom> If you pay attention to speed, STM is sometimes faster than locking, sometimes slower.
2022-10-29 01:42:42 +0200 <cpli> jbggs[m]: "cats" or categories, 2-cats are cats with 0-cells (your normal objects) 1-cells (arrows between your objects) and arrows between your objects etc. operads are a way to represent cells, which is another matter
2022-10-29 01:43:22 +0200 <EvanR> do operads have anything to do with monads
2022-10-29 01:43:38 +0200 <monochrom> Although, the sad thing is that the very word "transactional" in the very name has already told you how it does it, but people have never learned transactions, they have only learned locking.
2022-10-29 01:43:53 +0200 <cpli> not necessarily, but also yes, unless they don't EvanR
2022-10-29 01:44:18 +0200 <EvanR> that's the worst bit of category theory ever
2022-10-29 01:45:16 +0200 <cpli> operads are just shapes that give you some way of "glueing" them together to get new shapes
2022-10-29 01:45:31 +0200 <cpli> i.e. composition if you think of the edges of your shapes as arrows
2022-10-29 01:45:52 +0200 <cpli> i.e. glueing from topology if you get really weird
2022-10-29 01:46:00 +0200polo(~polo@user/polo)
2022-10-29 01:46:06 +0200 <cpli> i.e. homotopies if you haven't slept for 2 weeks
2022-10-29 01:46:45 +0200 <talismanick> monochrom: "If you want to write CS research today, look at what the database people were doing 2 decades ago"
2022-10-29 01:46:56 +0200 <cpli> monochrom, what does transactional entail?
2022-10-29 01:47:00 +0200 <talismanick> I forget who said that, but the more I read, the more it rings true...
2022-10-29 01:47:12 +0200 <EvanR> what database people other than mysql was doing 2 decades ago
2022-10-29 01:47:13 +0200 <cpli> i.e. "ownership" in rust terms is always handed along?
2022-10-29 01:47:22 +0200 <talismanick> cpli: ACIDity
2022-10-29 01:47:41 +0200 <EvanR> the I in ACID corresponds to transactional
2022-10-29 01:47:50 +0200 <cpli> of course it does
2022-10-29 01:47:56 +0200 <monochrom> Learn "database transactions". If you don't see "roll back" you aren't learning transactions.
2022-10-29 01:48:01 +0200polo(~polo@user/polo) (Client Quit)
2022-10-29 01:48:02 +0200Tuplanolla(~Tuplanoll@91-159-69-11.elisa-laajakaista.fi) (Quit: Leaving.)
2022-10-29 01:48:16 +0200 <dminuoso> Gosh, did Microsoft really remove SPJs papers website? :(
2022-10-29 01:48:18 +0200 <talismanick> Or, at least, the A and I parts - C is up to the programmer, and D is outside the scope of STM
2022-10-29 01:48:28 +0200 <dminuoso> I wish hyperlinks would just stay alive...
2022-10-29 01:48:38 +0200 <EvanR> i was downloading spj papers from microsoft a couple weeks ago
2022-10-29 01:48:56 +0200 <cpli> oh
2022-10-29 01:49:22 +0200 <monochrom> I think https://simon.peytonjones.org/publications/ helps.
2022-10-29 01:49:41 +0200 <cpli> start doing x, do x in y, if x fails, restore y
2022-10-29 01:50:02 +0200 <EvanR> begin transaction; do whatever, do whatever, do whatever, commit
2022-10-29 01:50:31 +0200 <cpli> or record y, do f, if f fails, restore y and override g's operation on y
2022-10-29 01:50:32 +0200 <EvanR> let the database figure out how to interleave it all
2022-10-29 01:50:55 +0200 <EvanR> while maintaining the invariants
2022-10-29 01:51:24 +0200 <cpli> i guess `I` ruins my joke
2022-10-29 01:51:44 +0200 <dminuoso> cpli: Anyway, the way GHC implements STM, is by just running the transactional code without any lock, along the way it records a transaction log of what it has does, and if at the end the log is consistent it will commit that to memory.
2022-10-29 01:51:49 +0200 <cpli> how do you guarantee `I` on non-hardware-atomics?
2022-10-29 01:51:55 +0200 <cpli> i.e. entire memory regions?
2022-10-29 01:52:30 +0200 <dminuoso> And if it doesnt, it can retry that block. Given that it has a transactional log, it can then block until it *knows* that a dependent variable has changed (no need to retry if none of the read variables havent changed)
2022-10-29 01:53:03 +0200 <cpli> dminuoso, oh, it's the weird "transform any algorithm into a wait-free algorithm vm"
2022-10-29 01:53:21 +0200 <dminuoso> I do not know that transformation
2022-10-29 01:53:30 +0200 <cpli> no?
2022-10-29 01:53:34 +0200 <cpli> one-moment
2022-10-29 01:53:48 +0200 <EvanR> what would wait free mean in this context
2022-10-29 01:54:06 +0200 <monochrom> I know lock-free, I don't know wait-free.
2022-10-29 01:54:08 +0200 <cpli> http://cs.technion.ac.il/~erez/Papers/wf-simulation-full.pdf
2022-10-29 01:54:16 +0200 <cpli> wait, this turns lock-free into wait-free
2022-10-29 01:54:22 +0200 <cpli> dammit
2022-10-29 01:54:25 +0200 <monochrom> Wouldn't it be nice if vaccination clinics were wait-free >:)
2022-10-29 01:54:41 +0200chomwitt(~chomwitt@2a02:587:dc10:8200:1ac0:4dff:fedb:a3f1) (Ping timeout: 276 seconds)
2022-10-29 01:55:14 +0200 <dminuoso> monochrom: They can be, just start coughing enough and ask loudly-but-not-too-loudly for the vaccination against your hot COVID infection.
2022-10-29 01:55:22 +0200 <talismanick> cpli: so, wait-free means no live locks... ?
2022-10-29 01:56:15 +0200 <cpli> wait-free is pseudo termination-guarantees
2022-10-29 01:56:32 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-10-29 01:56:32 +0200 <monochrom> I think they would immediately send you home instead. But hey, "abort early, abort often" is more wait-free than "wait then abort anyway".
2022-10-29 01:56:32 +0200 <dminuoso> cpli: Im not sure this really compares. One of the crucial things is that if the view of memory is not consistent (which it might be), it will retry.
2022-10-29 01:57:09 +0200 <cpli> talismanick: `push` **will succeed** in n cpu-cycles
2022-10-29 01:57:50 +0200 <cpli> dminuoso: how do you ensure termination? i.e. stop the vm from retrying indefinitely?
2022-10-29 01:58:05 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 01:58:29 +0200 <dminuoso> cpli: two things: a) since a transaction log is kept, you can only retry when there's a possibility of obtaining a different result
2022-10-29 01:58:42 +0200 <monochrom> In usage of STM we just ask for fairness, I think.
2022-10-29 01:58:50 +0200 <cpli> dminuoso: interesting.
2022-10-29 01:58:52 +0200 <dminuoso> b) just some optimism that concurrency is not crazy wild I suppose?
2022-10-29 01:59:00 +0200euandreh(~euandreh@179.214.113.107)
2022-10-29 01:59:05 +0200 <cpli> B)
2022-10-29 01:59:13 +0200 <talismanick> aaaaah, so it's the opposite of what I said - no deadlocks , but can have livelocks (each part succeeds in allotted time without being starved externally, but end up ping-pong'ing each other and cause the system to make no progress)
2022-10-29 01:59:13 +0200 <dminuoso> I mean yeah, if you keep extremely large transactions, retrying will get more expensive
2022-10-29 01:59:22 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds)
2022-10-29 01:59:46 +0200 <talismanick> interesting
2022-10-29 02:00:27 +0200 <cpli> talismanick, the guarantee applies to entire algorithms, i.e. only using wait-free makes you wait-free
2022-10-29 02:00:37 +0200 <EvanR> cpli, nothing stops you from writing STM code that retries forever. Actually that's a handy way to get a dummy thread that does nothing
2022-10-29 02:00:43 +0200 <EvanR> without busy looping
2022-10-29 02:01:09 +0200 <cpli> EvanR do you have a simple example? that does sound fun
2022-10-29 02:01:11 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-29 02:01:18 +0200 <EvanR> forever retry
2022-10-29 02:01:24 +0200 <dminuoso> And unlike the naïve MVar variant, GHC wont "help you catch a bug" :p
2022-10-29 02:01:29 +0200 <cpli> (mainly because a thread doing nothing is kind of useful in places-
2022-10-29 02:01:40 +0200califax(~califax@user/califx) (Remote host closed the connection)
2022-10-29 02:01:41 +0200 <cpli> EvanR i.e. a haskell example
2022-10-29 02:01:46 +0200 <EvanR> that's... haskell xD
2022-10-29 02:01:49 +0200 <cpli> oh
2022-10-29 02:01:50 +0200 <dminuoso> cpli: that was a haskell example. :)
2022-10-29 02:01:57 +0200 <talismanick> EvanR: That reminds me a bit of a technique in a paper on OOP (the Actor Model back then, really) in Concurrent Prolog
2022-10-29 02:02:06 +0200 <cpli> Control.Concurrent.retry?
2022-10-29 02:02:09 +0200 <dminuoso> Isnt it lovely, how you can express a thought so vividly like `forever retry`
2022-10-29 02:02:12 +0200 <EvanR> :t retry
2022-10-29 02:02:14 +0200 <lambdabot> error: Variable not in scope: retry
2022-10-29 02:02:23 +0200 <geekosaur> % :t retry
2022-10-29 02:02:23 +0200 <yahb2> <interactive>:1:1: error: Variable not in scope: retry
2022-10-29 02:02:24 +0200 <dminuoso> % import Control.Monad
2022-10-29 02:02:24 +0200 <yahb2> <no output>
2022-10-29 02:02:29 +0200 <dminuoso> % import GHC.Conc
2022-10-29 02:02:30 +0200 <yahb2> <no output>
2022-10-29 02:02:32 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 02:02:35 +0200 <dminuoso> % :t forever retry
2022-10-29 02:02:35 +0200 <yahb2> forever retry :: STM b
2022-10-29 02:02:51 +0200 <cpli> beautiful
2022-10-29 02:02:58 +0200 <dminuoso> Is the `forever` even needed?
2022-10-29 02:03:16 +0200ubert1(~Thunderbi@91.141.46.203.wireless.dyn.drei.com)
2022-10-29 02:03:17 +0200 <talismanick> https://dl.acm.org/doi/10.1007/BF03037020
2022-10-29 02:03:19 +0200 <monochrom> Only one way to find out. Try. :)
2022-10-29 02:03:21 +0200 <cpli> talismanick: concurrent prolog sounds wild.
2022-10-29 02:03:22 +0200 <dminuoso> % print =<< (atomically retry :: STM ())
2022-10-29 02:03:23 +0200 <yahb2> <interactive>:20:12: error: ; • Couldn't match expected type: STM () ; with actual type: IO a0 ; • In the second argument of ‘(=<<)’, namely ; ‘(atomically retry :...
2022-10-29 02:03:28 +0200 <dminuoso> % print =<< atomically (retry :: STM ())
2022-10-29 02:03:30 +0200 <yahb2> <interactive>:4:32: error: ; Not in scope: type constructor or class ‘STM’
2022-10-29 02:03:41 +0200 <dminuoso> % print =<< atomically retry
2022-10-29 02:03:42 +0200 <yahb2> <interactive>:6:11: error: ; Variable not in scope: atomically :: t0 -> IO a0 ; ; <interactive>:6:22: error: Variable not in scope: retry
2022-10-29 02:03:52 +0200 <dminuoso> % :t retry
2022-10-29 02:03:53 +0200 <yahb2> <interactive>:1:1: error: Variable not in scope: retry
2022-10-29 02:03:57 +0200ubert(~Thunderbi@178.165.186.249.wireless.dyn.drei.com) (Ping timeout: 240 seconds)
2022-10-29 02:03:57 +0200ubert1ubert
2022-10-29 02:03:58 +0200 <dminuoso> % import Control.Monad
2022-10-29 02:03:58 +0200 <yahb2> <no output>
2022-10-29 02:04:00 +0200 <dminuoso> % import GHC.COnc
2022-10-29 02:04:00 +0200 <yahb2> <no location info>: error: ; Could not find module ‘GHC.COnc’ ; Perhaps you meant GHC.Conc (from base-4.16.3.0)
2022-10-29 02:04:02 +0200 <dminuoso> % import GHC.Conc
2022-10-29 02:04:03 +0200 <yahb2> <no output>
2022-10-29 02:04:16 +0200crns(~netcrns@user/crns) (Ping timeout: 250 seconds)
2022-10-29 02:04:17 +0200 <dminuoso> % print =<< atomically (retry :: STM ())
2022-10-29 02:04:19 +0200 <yahb2> <interactive>:4:32: error: ; Not in scope: type constructor or class ‘STM’
2022-10-29 02:04:28 +0200 <dminuoso> I do not know whats going on here.
2022-10-29 02:04:29 +0200califax(~califax@user/califx)
2022-10-29 02:04:49 +0200 <jbggs[m]> Is this conversational AI
2022-10-29 02:04:50 +0200 <dminuoso> *** Exception: thread blocked indefinitely in an STM transaction
2022-10-29 02:04:59 +0200 <monochrom> Retry with Control.Concurrent.STM? :)
2022-10-29 02:04:59 +0200 <dminuoso> EvanR: So I do not think this will actually work.
2022-10-29 02:05:28 +0200dolio(~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-29 02:05:30 +0200 <dminuoso> A similar detection as with MVar seems to be existing here, except I do not think you can work around this.
2022-10-29 02:05:37 +0200 <[Leary]> There's no memory it depends on, so the retry will never happen.
2022-10-29 02:05:58 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 02:06:12 +0200 <EvanR> looks like STM is too smart for me
2022-10-29 02:06:34 +0200 <[Leary]> So the way to make it go forever is to have it read something but ignore it, while another thread can potentially change that thing?
2022-10-29 02:06:37 +0200 <EvanR> forever retry generated some good puns though
2022-10-29 02:06:43 +0200 <cpli> i'll be back in a bit, this was fun, i'll implement my star breech when i'm back
2022-10-29 02:07:03 +0200dolio(~dolio@130.44.134.54)
2022-10-29 02:07:05 +0200 <dminuoso> EvanR: Know what you can do, however?
2022-10-29 02:07:11 +0200 <dminuoso> % import Control.Monad
2022-10-29 02:07:11 +0200 <yahb2> <no output>
2022-10-29 02:07:13 +0200 <dminuoso> % import Data.Function
2022-10-29 02:07:14 +0200 <yahb2> <no output>
2022-10-29 02:07:16 +0200 <dminuoso> % forever fix error
2022-10-29 02:07:19 +0200 <yahb2> <interactive>:4:1: error: ; Variable not in scope: forever :: t0 -> ([Char] -> a0) -> t ; ; <interactive>:4:9: error: Variable not in scope: fix
2022-10-29 02:07:22 +0200dolio(~dolio@130.44.134.54) (Client Quit)
2022-10-29 02:07:33 +0200 <monochrom> Yeah, one transaction reads a TVar then goes "if it's 0, retry". Another thread runs "write 0 to that TVar" every once in a while.
2022-10-29 02:07:36 +0200 <dminuoso> Okay, this would normally loop. Something is up with yahb here
2022-10-29 02:08:22 +0200dolio(~dolio@130.44.134.54)
2022-10-29 02:08:28 +0200 <dminuoso> monochrom: I think doing the inverse is better. If its 0, retry, and have a signal handler write 1 to that tvar on sigterm.
2022-10-29 02:08:35 +0200 <monochrom> Well, import Control.Monad and then can't find forever, that's an issue, yeah.
2022-10-29 02:09:07 +0200 <dminuoso> monochrom: the delay suggests to me there's something killing the yahb instance (due to timeout, presumably), and perhaps re-inputing the last command.
2022-10-29 02:09:17 +0200 <monochrom> I'm going to issue % :quit to see if it helps to, "have you turned it off and on again?"
2022-10-29 02:09:21 +0200 <monochrom> % :quit
2022-10-29 02:09:21 +0200 <yahb2> <no output>
2022-10-29 02:09:33 +0200 <EvanR> % 1 `div` 0
2022-10-29 02:09:33 +0200 <yahb2> *** Exception: divide by zero
2022-10-29 02:09:47 +0200 <dminuoso> Hold on.
2022-10-29 02:09:51 +0200 <dminuoso> I thought you couldnt divide by zero?
2022-10-29 02:09:53 +0200 <EvanR> yahb is more resilient than the idris bot
2022-10-29 02:10:02 +0200 <dminuoso> I finally have the answer. Haskell shows me you can!
2022-10-29 02:10:20 +0200 <EvanR> you can divide by zero on graphical linear algebra .net blog xD
2022-10-29 02:10:48 +0200 <monochrom> I can divide by zero in Double. In fact I can do it two ways. :)
2022-10-29 02:10:51 +0200 <dminuoso> If you divide by negative zero, do you get a negative bottom?
2022-10-29 02:11:09 +0200crns(~netcrns@p4ff5e2ab.dip0.t-ipconnect.de)
2022-10-29 02:11:09 +0200crns(~netcrns@p4ff5e2ab.dip0.t-ipconnect.de) (Changing host)
2022-10-29 02:11:09 +0200crns(~netcrns@user/crns)
2022-10-29 02:11:14 +0200 <dminuoso> (and does a negative bottom converge?)
2022-10-29 02:11:28 +0200 <EvanR> % 1 `div` (negate 0) < 0
2022-10-29 02:11:29 +0200 <yahb2> *** Exception: divide by zero
2022-10-29 02:12:04 +0200 <EvanR> % 1 `div` negate 0 < 0
2022-10-29 02:12:05 +0200 <yahb2> *** Exception: divide by zero
2022-10-29 02:12:44 +0200 <EvanR> not lazy enough
2022-10-29 02:12:47 +0200 <monochrom> > sqrt (-0)
2022-10-29 02:12:48 +0200 <lambdabot> -0.0
2022-10-29 02:12:49 +0200 <dminuoso> EvanR: So here comes the difficult thing. We may not see the real negative bottom. Imprecise exceptions means we can never know whether the error came from your division or not!
2022-10-29 02:12:50 +0200 <monochrom> \∩/
2022-10-29 02:13:53 +0200 <monochrom> Blame theory says that it always came from someone else's division!
2022-10-29 02:14:45 +0200 <dminuoso> Does that mean if my Haskell program bottoms out, I can never be liable for damages or injuries?
2022-10-29 02:14:57 +0200 <dminuoso> (Provably)
2022-10-29 02:15:35 +0200 <geekosaur> only if the bottom's exceptional
2022-10-29 02:15:58 +0200 <monochrom> That's under the jurisdiction of legal theory, not blame theory. :)
2022-10-29 02:17:26 +0200 <EvanR> there better not be any bottoms in the avionics software on my plane
2022-10-29 02:17:32 +0200 <EvanR> of course, there probably are
2022-10-29 02:18:25 +0200 <EvanR> dminuoso, aiui imprecise exceptions means when evaluating something that could bottom in several ways
2022-10-29 02:19:12 +0200 <EvanR> one way is selected and that's what you get. But you might be able to know which is which
2022-10-29 02:19:25 +0200 <monochrom> It's an abstraction. If an expression have several sources of exceptions, imprecise exception says one of them is nondeterministically chosen.
2022-10-29 02:19:53 +0200 <monochrom> But clearly it is not very nondeterministic. If you find out the evaluation order, that settles it.
2022-10-29 02:20:22 +0200 <EvanR> I mean you might get one of several different error messages (if any)
2022-10-29 02:20:34 +0200 <monochrom> This is an abstraction façade to entitle the optimizer to do reordering.
2022-10-29 02:20:59 +0200 <dminuoso> monochrom: It'll be easy to argue "this is an implementation detail", "lets just worry about language semantics"
2022-10-29 02:21:00 +0200 <EvanR> it says it's non deterministic?
2022-10-29 02:21:13 +0200 <EvanR> in some fancy technical sense?
2022-10-29 02:21:14 +0200 <dminuoso> Otherwise I will just shift the blame (and damages) to the GHC team as being responsible for the implementation.
2022-10-29 02:21:19 +0200 <monochrom> The same way we say "the OS nondeterministically chooses the next thread to run" but clearly it's deterministic once you know the actual scheduler and all the other 1 million factors.
2022-10-29 02:21:22 +0200 <dminuoso> I will win this argument in court.
2022-10-29 02:21:50 +0200 <dminuoso> monochrom: Okay, that means I must really buy a quantum RNG PCI card.
2022-10-29 02:22:06 +0200 <monochrom> Oh, hiding an implementation detail is a case of abstraction, too.
2022-10-29 02:22:06 +0200 <dminuoso> If evaluation order is chosen truly randomly, I have a way out.
2022-10-29 02:24:21 +0200 <monochrom> Yes, to date, short of quantum computing, nondeterminism has always been a hide-implementation-details abstraction, in the very same sense as throwing a die is regarded nondeterministic just because no one bothers measuring all factors involved.
2022-10-29 02:24:29 +0200 <alexfmpe[m]> as long as any evaluation order results in damages, you're liable according to a non-deterministic finite judge machine
2022-10-29 02:25:51 +0200boxscape_(~boxscape@81.191.27.107) (Remote host closed the connection)
2022-10-29 02:26:24 +0200 <monochrom> Although, beautifully, this abstraction inspires the beautiful theory of nondeterminisitc computing, which is pivotal in helping us frame very important questions on complexity.
2022-10-29 02:29:05 +0200 <monochrom> It is also possible that the multiple-world interpretation of quantum computing still makes your quantum nondeterminism a hide-details abstraction, i.e., you are just ignorant of all the entanglements out there that affect you.
2022-10-29 02:29:22 +0200 <dolio> That's not the only one.
2022-10-29 02:29:55 +0200j4cc3b(~j4cc3b@pool-74-105-2-138.nwrknj.fios.verizon.net) (Quit: Client closed)
2022-10-29 02:36:05 +0200nate3(~nate@98.45.169.16)
2022-10-29 02:36:08 +0200slack1256(~slack1256@181.42.52.169)
2022-10-29 02:40:29 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-10-29 02:40:29 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-10-29 02:40:29 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 02:40:58 +0200nate3(~nate@98.45.169.16) (Ping timeout: 255 seconds)
2022-10-29 02:48:09 +0200Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 255 seconds)
2022-10-29 02:52:57 +0200beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 240 seconds)
2022-10-29 03:03:11 +0200redmp(~redmp@mobile-166-170-43-64.mycingular.net)
2022-10-29 03:04:38 +0200nate3(~nate@98.45.169.16)
2022-10-29 03:06:14 +0200xff0x(~xff0x@2405:6580:b080:900:2e5f:ef77:7c98:ca52) (Ping timeout: 250 seconds)
2022-10-29 03:08:47 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 276 seconds)
2022-10-29 03:09:29 +0200money(sid532813@user/polo) ()
2022-10-29 03:09:57 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 272 seconds)
2022-10-29 03:10:39 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-10-29 03:16:45 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-10-29 03:18:54 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 03:18:54 +0200xff0x(~xff0x@2405:6580:b080:900:2e5f:ef77:7c98:ca52)
2022-10-29 03:23:34 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 03:24:03 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 03:24:28 +0200money(sid532813@user/polo)
2022-10-29 03:25:42 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 03:33:23 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-10-29 03:33:44 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-10-29 03:42:09 +0200hgolden(~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection)
2022-10-29 03:42:43 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds)
2022-10-29 03:43:50 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2022-10-29 03:45:25 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 272 seconds)
2022-10-29 03:53:02 +0200axeman(~quassel@ip-037-201-153-145.um10.pools.vodafone-ip.de) (Ping timeout: 250 seconds)
2022-10-29 03:58:05 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds)
2022-10-29 04:03:52 +0200nate3(~nate@98.45.169.16) (Ping timeout: 250 seconds)
2022-10-29 04:07:26 +0200moneypolo
2022-10-29 04:08:22 +0200td_(~td@83.135.9.42) (Ping timeout: 252 seconds)
2022-10-29 04:10:05 +0200td_(~td@83.135.9.7)
2022-10-29 04:10:26 +0200causal(~user@50.35.83.177) (Quit: WeeChat 3.6)
2022-10-29 04:12:39 +0200slack1256(~slack1256@181.42.52.169) (Ping timeout: 272 seconds)
2022-10-29 04:17:43 +0200crns(~netcrns@user/crns) (Ping timeout: 272 seconds)
2022-10-29 04:19:23 +0200crns(~netcrns@p5dc33ed0.dip0.t-ipconnect.de)
2022-10-29 04:19:23 +0200crns(~netcrns@p5dc33ed0.dip0.t-ipconnect.de) (Changing host)
2022-10-29 04:19:23 +0200crns(~netcrns@user/crns)
2022-10-29 04:22:56 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 04:26:37 +0200frost75(~frost@user/frost)
2022-10-29 04:30:02 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 04:32:17 +0200Kaiepi(~Kaiepi@108.175.84.104)
2022-10-29 04:34:38 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 04:37:18 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 04:43:24 +0200terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat)
2022-10-29 04:44:44 +0200terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1)
2022-10-29 04:45:14 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2022-10-29 04:45:14 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-29 04:57:21 +0200constxd(~brad@47.55.121.233) (Quit: WeeChat 2.8)
2022-10-29 05:01:09 +0200danza(~francesco@151.35.98.197) (Read error: Connection reset by peer)
2022-10-29 05:03:25 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-10-29 05:05:45 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-29 05:06:16 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 250 seconds)
2022-10-29 05:16:11 +0200tiziodcaio(~tiziodcai@2001:470:69fc:105::1:2bf8)
2022-10-29 05:16:12 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-10-29 05:16:41 +0200danza(~francesco@bo-18-136-28.service.infuturo.it)
2022-10-29 05:17:59 +0200king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-10-29 05:18:10 +0200jargon(~jargon@184.101.90.242)
2022-10-29 05:21:01 +0200bilegeek(~bilegeek@2600:1008:b027:7f32:a99b:c297:feda:8531) (Quit: Leaving)
2022-10-29 05:30:31 +0200td_(~td@83.135.9.7) (Ping timeout: 246 seconds)
2022-10-29 05:32:33 +0200td_(~td@83.135.9.8)
2022-10-29 05:36:10 +0200Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 250 seconds)
2022-10-29 05:45:16 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 250 seconds)
2022-10-29 05:46:32 +0200johnw(~johnw@2600:1700:cf00:db0:24dd:7cba:243c:c819) (Quit: ZNC - http://znc.in)
2022-10-29 05:46:34 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2022-10-29 05:46:34 +0200litharge(litharge@libera/bot/litharge) (*.net *.split)
2022-10-29 05:52:34 +0200litharge(litharge@libera/bot/litharge)
2022-10-29 05:54:24 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 05:55:37 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2022-10-29 05:55:37 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2022-10-29 05:55:37 +0200finn_elijaFinnElija
2022-10-29 05:58:26 +0200king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 276 seconds)
2022-10-29 06:05:56 +0200frost75(~frost@user/frost) (Quit: Client closed)
2022-10-29 06:10:46 +0200king_gs(~Thunderbi@187.201.83.115)
2022-10-29 06:12:38 +0200flukiluke(~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) (Remote host closed the connection)
2022-10-29 06:12:59 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 272 seconds)
2022-10-29 06:13:41 +0200flukiluke(~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962)
2022-10-29 06:14:08 +0200whatsupdoc(uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-29 06:17:25 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 272 seconds)
2022-10-29 06:28:36 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 250 seconds)
2022-10-29 06:30:01 +0200Vajb(~Vajb@85-76-71-213-nat.elisa-mobile.fi) (Read error: Connection reset by peer)
2022-10-29 06:30:14 +0200Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi)
2022-10-29 06:35:03 +0200Kaiepi(~Kaiepi@108.175.84.104)
2022-10-29 06:51:27 +0200src36(~src@176.53.146.40)
2022-10-29 06:52:27 +0200src36(~src@176.53.146.40) (Client Quit)
2022-10-29 06:58:00 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2022-10-29 07:08:39 +0200 <dsal> I'm using sqlite-simple in an app and would really like to add postgres support. All the options seem pretty invasive. What do people like these days?
2022-10-29 07:09:21 +0200redmp(~redmp@mobile-166-170-43-64.mycingular.net) (Ping timeout: 272 seconds)
2022-10-29 07:12:01 +0200Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer)
2022-10-29 07:12:12 +0200Vajb(~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57)
2022-10-29 07:15:51 +0200monochrom(trebla@216.138.220.146) (Quit: NO CARRIER)
2022-10-29 07:23:50 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2022-10-29 07:24:49 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds)
2022-10-29 07:24:49 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-29 07:24:54 +0200 <kronicmage> @pf \(a, b) (c, d) -> (a+c, b+d)
2022-10-29 07:24:54 +0200 <lambdabot> Maybe you meant: pl bf
2022-10-29 07:25:00 +0200 <kronicmage> @pl \(a, b) (c, d) -> (a+c, b+d)
2022-10-29 07:25:01 +0200 <lambdabot> uncurry (flip flip snd . (ap .) . flip flip fst . ((.) .) . (. (+)) . flip . (((.) . (,)) .) . (+))
2022-10-29 07:25:16 +0200 <kronicmage> ouch
2022-10-29 07:28:04 +0200monochrom(trebla@216.138.220.146)
2022-10-29 07:28:16 +0200 <dsal> :t bimap (+) (+)
2022-10-29 07:28:18 +0200 <lambdabot> (Bifunctor p, Num a1, Num a2) => p a1 a2 -> p (a1 -> a1) (a2 -> a2)
2022-10-29 07:39:14 +0200jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-29 07:52:45 +0200nate3(~nate@98.45.169.16)
2022-10-29 08:03:09 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2022-10-29 08:04:49 +0200king_gs(~Thunderbi@187.201.83.115) (Read error: Connection reset by peer)
2022-10-29 08:05:28 +0200king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-10-29 08:15:57 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-29 08:25:07 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 08:30:25 +0200nate3(~nate@98.45.169.16) (Ping timeout: 272 seconds)
2022-10-29 08:35:49 +0200birdgoose(~jesse@2406:e003:1d87:6601:e725:b6b4:ace8:4ebe) (Quit: Konversation terminated!)
2022-10-29 08:36:07 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds)
2022-10-29 08:38:01 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-29 08:57:35 +0200king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Quit: king_gs)
2022-10-29 08:58:30 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 255 seconds)
2022-10-29 08:59:22 +0200rembo10(~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-29 09:01:55 +0200rembo10(~rembo10@main.remulis.com)
2022-10-29 09:03:44 +0200danza(~francesco@bo-18-136-28.service.infuturo.it) (Ping timeout: 250 seconds)
2022-10-29 09:05:00 +0200gmg(~user@user/gehmehgeh)
2022-10-29 09:09:03 +0200Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 272 seconds)
2022-10-29 09:16:59 +0200danza(~francesco@151.57.22.153)
2022-10-29 09:19:31 +0200jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net)
2022-10-29 09:20:42 +0200Kaiepi(~Kaiepi@108.175.84.104)
2022-10-29 09:21:43 +0200danza(~francesco@151.57.22.153) (Read error: Connection reset by peer)
2022-10-29 09:31:47 +0200mixfix41(~sdeny9ee@user/mixfix41)
2022-10-29 09:37:23 +0200acidjnk_new3(~acidjnk@p200300d6e7137a26b5cba7005e8744f0.dip0.t-ipconnect.de)
2022-10-29 09:38:38 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2022-10-29 09:39:57 +0200zaquest(~notzaques@5.130.79.72)
2022-10-29 09:42:57 +0200jargon(~jargon@184.101.90.242) (Remote host closed the connection)
2022-10-29 09:43:11 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-10-29 09:49:12 +0200whatsupdoc(uid509081@id-509081.hampstead.irccloud.com)
2022-10-29 10:02:01 +0200acidjnk_new3(~acidjnk@p200300d6e7137a26b5cba7005e8744f0.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-10-29 10:08:24 +0200vglfr(~vglfr@145.224.100.22)
2022-10-29 10:09:10 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de)
2022-10-29 10:09:28 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2022-10-29 10:11:50 +0200poloGambino
2022-10-29 10:15:14 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2022-10-29 10:19:51 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Remote host closed the connection)
2022-10-29 10:21:52 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 10:34:03 +0200Sgeo_(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-10-29 10:36:13 +0200Tuplanolla(~Tuplanoll@91-159-69-11.elisa-laajakaista.fi)
2022-10-29 10:43:24 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2022-10-29 10:54:31 +0200Unhammer(~Unhammer@user/unhammer) (Ping timeout: 260 seconds)
2022-10-29 10:55:20 +0200Batzy(~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-29 10:55:43 +0200Batzy(~quassel@user/batzy)
2022-10-29 10:57:17 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-10-29 10:57:18 +0200Batzy(~quassel@user/batzy) (Client Quit)
2022-10-29 10:57:43 +0200Batzy(~quassel@user/batzy)
2022-10-29 10:59:11 +0200vglfr(~vglfr@145.224.100.22) (Remote host closed the connection)
2022-10-29 10:59:46 +0200vglfr(~vglfr@145.224.100.22)
2022-10-29 11:04:54 +0200freeside(~mengwong@122.11.214.174)
2022-10-29 11:08:29 +0200Unhammer(~Unhammer@user/unhammer)
2022-10-29 11:09:08 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2022-10-29 11:11:44 +0200tcard_(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Read error: Connection reset by peer)
2022-10-29 11:11:44 +0200tcard__(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9)
2022-10-29 11:15:27 +0200AkechiShiro(~licht@user/akechishiro)
2022-10-29 11:17:32 +0200zeenk(~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494)
2022-10-29 11:18:13 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-10-29 11:20:19 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03)
2022-10-29 11:24:15 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Quit: Leaving)
2022-10-29 11:24:42 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Ping timeout: 252 seconds)
2022-10-29 11:25:46 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds)
2022-10-29 11:26:00 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de) (Remote host closed the connection)
2022-10-29 11:27:00 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-10-29 11:27:12 +0200CiaoSen(~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-10-29 11:27:17 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de)
2022-10-29 11:28:44 +0200jakalx(~jakalx@base.jakalx.net) ()
2022-10-29 11:30:10 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-10-29 11:31:15 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-10-29 11:44:11 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de) (Quit: Leaving.)
2022-10-29 11:45:58 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-10-29 11:46:16 +0200 <dminuoso> dsal: You can also just additionally load hasql, implement queries for both backends, and just keep a database independent layer in between.
2022-10-29 11:46:32 +0200 <dminuoso> Just dont succumb to postgresql-simple.
2022-10-29 11:46:41 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-10-29 11:48:49 +0200 <dminuoso> With a bit of discipline you can probably reuse most queries across them
2022-10-29 11:49:10 +0200biberu(~biberu@user/biberu) (Read error: Connection reset by peer)
2022-10-29 11:49:55 +0200 <dminuoso> Otherwise hdbc is a thing, its not overly terrible
2022-10-29 11:50:33 +0200jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 272 seconds)
2022-10-29 11:57:02 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de)
2022-10-29 11:59:30 +0200jakalx(~jakalx@base.jakalx.net)
2022-10-29 12:02:05 +0200biberu(~biberu@user/biberu)
2022-10-29 12:02:57 +0200ubert(~Thunderbi@91.141.46.203.wireless.dyn.drei.com) (Ping timeout: 240 seconds)
2022-10-29 12:05:02 +0200 <fendor[m]> Can I have something akin to rewrite rules for type family application? E.g., I have type level functions Append and RemoveLast, and I want `forall p . RemoveLast (Append p 'Z) ~ p` to hold
2022-10-29 12:05:46 +0200 <fendor[m]> or do I need a type-plugin that fixes that adds this simplification for me?
2022-10-29 12:07:39 +0200freeside(~mengwong@122.11.214.174) (Ping timeout: 272 seconds)
2022-10-29 12:14:01 +0200 <[Leary]> fendor[m]: I'm not sure if there are better ways, but if you use defunctionalised type families you can write these rules into the definitions of `RemoveLast` and `Append`.
2022-10-29 12:14:43 +0200 <probie> As a hack, I've often added those sort of things as assertions at the use site (I remember at one point needing `Reverse (Reverse xs) ~ xs`), which works well enough if their use is internal and not exposed to a user of one's library
2022-10-29 12:15:41 +0200 <fendor[m]> [Leary]: Any resources on how to defunctionalise type families?
2022-10-29 12:15:53 +0200 <fendor[m]> probie: that sounds curious, I am fine with terrible UX for now
2022-10-29 12:16:16 +0200zer0bitz(~zer0bitz@2001:2003:f748:2000:99dc:7f1f:c53d:641d) (Read error: Connection reset by peer)
2022-10-29 12:18:35 +0200 <[Leary]> fendor[m]: It's been a while since I read about it, I forget where. But this looks alright: https://free.cofree.io/2019/01/08/defunctionalization/
2022-10-29 12:18:51 +0200 <fendor[m]> thank you!
2022-10-29 12:19:14 +0200zer0bitz(~zer0bitz@2001:2003:f748:2000:5894:8e10:5893:ce6f)
2022-10-29 12:20:48 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds)
2022-10-29 12:29:12 +0200burakcankGuest283
2022-10-29 12:30:35 +0200frost14(~frost@user/frost)
2022-10-29 12:31:35 +0200tcard__(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Quit: Leaving)
2022-10-29 12:32:32 +0200CiaoSen(~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-10-29 12:32:36 +0200beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt)
2022-10-29 12:36:32 +0200tcard(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9)
2022-10-29 12:39:29 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-10-29 12:40:04 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-10-29 12:40:04 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Remote host closed the connection)
2022-10-29 12:41:28 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 12:45:54 +0200jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net)
2022-10-29 12:46:11 +0200__monty__(~toonn@user/toonn)
2022-10-29 12:53:21 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-29 13:09:00 +0200danza(~francesco@151.35.235.74)
2022-10-29 13:12:43 +0200janlely(~janlely@122.231.201.44)
2022-10-29 13:16:00 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 264 seconds)
2022-10-29 13:16:48 +0200beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 250 seconds)
2022-10-29 13:17:55 +0200beteigeuze(~Thunderbi@89.187.168.47)
2022-10-29 13:21:09 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2022-10-29 13:25:50 +0200acidjnk(~acidjnk@p200300d6e7137a2658873e742925ddf0.dip0.t-ipconnect.de)
2022-10-29 13:36:10 +0200mrmonday(~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: .)
2022-10-29 13:37:55 +0200mrmonday(~robert@what.i.hope.is.not.a.tabernaevagant.es)
2022-10-29 13:43:15 +0200 <dminuoso> fendor[m]: The only equivalent of rewrite rules I know of is typechecker plugins.
2022-10-29 13:44:58 +0200CiaoSen(~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-10-29 13:49:37 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2022-10-29 13:57:52 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de) (Quit: Leaving.)
2022-10-29 13:59:16 +0200 <fendor[m]> typechecker plugin it is!
2022-10-29 13:59:16 +0200 <fendor[m]> will make it actually easier
2022-10-29 13:59:17 +0200infinity0(~infinity0@pwned.gg) (Ping timeout: 240 seconds)
2022-10-29 14:05:42 +0200frost14(~frost@user/frost) (Ping timeout: 244 seconds)
2022-10-29 14:05:59 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 14:11:08 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds)
2022-10-29 14:19:09 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-10-29 14:19:09 +0200califax(~califax@user/califx) (Remote host closed the connection)
2022-10-29 14:20:39 +0200vglfr(~vglfr@145.224.100.22) (Ping timeout: 272 seconds)
2022-10-29 14:21:37 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 240 seconds)
2022-10-29 14:22:19 +0200gmg(~user@user/gehmehgeh)
2022-10-29 14:22:38 +0200califax(~califax@user/califx)
2022-10-29 14:24:10 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de)
2022-10-29 14:26:41 +0200cyphase(~cyphase@user/cyphase)
2022-10-29 14:30:02 +0200jlgw(~jw@83-233-104-81.cust.bredband2.com)
2022-10-29 14:37:44 +0200 <jlgw> Hi, I'm trying to remap ctrl-j in ghci, but any time I enter a remap of ctrl-j (e.g. adding `bind: ctrl-j down` in ~/.haskeline) the return key is also remapped. I don't get this issue for other remaps (e.g. `bind: ctrl-k up`) and it's not an issue I've encountered in GNU readline. I've skimmed through the haskeline docs and the open issues but I haven't found anything relevant. Any tips on a solution or further reading?
2022-10-29 14:39:11 +0200vglfr(~vglfr@145.224.100.22)
2022-10-29 14:42:27 +0200 <fendor[m]> huh, the defunctionatalisation approach looks very promising, too
2022-10-29 14:45:49 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-10-29 14:56:03 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Quit: Stop)
2022-10-29 14:57:46 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2022-10-29 15:02:23 +0200shapr(~user@144.163.4.141)
2022-10-29 15:03:17 +0200 <MangoIV[m]> <fendor[m]> "Any resources on how to defuncti..." <- there's a library, `first-class-families`, you can have a look at. It's probably faster than reading 10 blogposts.
2022-10-29 15:03:20 +0200 <MangoIV[m]> * there's a (imho really good) library, `first-class-families`,
2022-10-29 15:03:38 +0200 <fendor[m]> ooh, nice!
2022-10-29 15:03:39 +0200 <MangoIV[m]> https://flora.pm/packages/@hackage/first-class-families
2022-10-29 15:03:50 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 250 seconds)
2022-10-29 15:03:52 +0200 <fendor[m]> haha, nice, flora 🙂
2022-10-29 15:04:12 +0200 <MangoIV[m]> yes, I am a flora power user.
2022-10-29 15:05:01 +0200fendor[m]uploaded an image: (174KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/IpizUwRetSGlZXTMURjQtqkm/image.png >
2022-10-29 15:05:01 +0200 <fendor[m]> I remember reading that on discord 😄 I am immediately filing a layout bug report
2022-10-29 15:05:48 +0200MangoIV[m]uploaded an image: (427KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/hEogonwbNYLOUdvCDHRzMPwW/image.png >
2022-10-29 15:05:48 +0200 <MangoIV[m]> might as well just ping Hecate, they will probably be able to help you, for me it doesn't look like that:
2022-10-29 15:06:27 +0200 <fendor[m]> will do, thank you very much!
2022-10-29 15:06:47 +0200 <MangoIV[m]> you're very welcome :)
2022-10-29 15:07:33 +0200phma(~phma@2001:5b0:212a:cc58:94b0:45f6:bc48:ff7d) (Read error: Connection reset by peer)
2022-10-29 15:08:08 +0200phma(~phma@host-67-44-208-99.hnremote.net)
2022-10-29 15:15:22 +0200acidjnk(~acidjnk@p200300d6e7137a2658873e742925ddf0.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2022-10-29 15:16:56 +0200infinity0(~infinity0@pwned.gg)
2022-10-29 15:23:52 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 15:31:33 +0200phma_(~phma@2001:5b0:211f:2dc8:ca7e:3ef3:1458:a7b3)
2022-10-29 15:36:01 +0200phma(~phma@host-67-44-208-99.hnremote.net) (Ping timeout: 272 seconds)
2022-10-29 15:36:23 +0200zeenk(~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494) (Quit: Konversation terminated!)
2022-10-29 15:50:29 +0200causal(~user@50.35.83.177)
2022-10-29 15:54:18 +0200Natch(~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Remote host closed the connection)
2022-10-29 15:58:52 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-10-29 15:59:26 +0200jonathanx(~jonathan@host-78-78-169-236.mobileonline.telia.com)
2022-10-29 16:07:21 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 16:10:10 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-29 16:15:20 +0200jonathanx(~jonathan@host-78-78-169-236.mobileonline.telia.com) (Ping timeout: 250 seconds)
2022-10-29 16:22:51 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2022-10-29 16:24:46 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03)
2022-10-29 16:29:21 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03) (Ping timeout: 260 seconds)
2022-10-29 16:32:13 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-10-29 16:40:54 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 250 seconds)
2022-10-29 16:41:01 +0200beteigeuze1(~Thunderbi@89.187.168.50)
2022-10-29 16:43:47 +0200beteigeuze(~Thunderbi@89.187.168.47) (Ping timeout: 272 seconds)
2022-10-29 16:44:32 +0200titibandit(~titibandi@xdsl-87-79-250-160.nc.de) (Remote host closed the connection)
2022-10-29 16:45:40 +0200beteigeuze1(~Thunderbi@89.187.168.50) (Ping timeout: 250 seconds)
2022-10-29 16:50:39 +0200tiziodcaio(~tiziodcai@2001:470:69fc:105::1:2bf8) (Quit: Reconnecting)
2022-10-29 16:51:09 +0200gqplox(~textual@2a02:c7c:941d:fd00:40a0:1c9d:7a12:f334)
2022-10-29 16:59:02 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2022-10-29 17:00:02 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-10-29 17:00:36 +0200danza(~francesco@151.35.235.74) (Read error: Connection reset by peer)
2022-10-29 17:06:24 +0200Natch(~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se)
2022-10-29 17:06:49 +0200 <zzz> weird. it looks fine to me on linux firefox but not on chromium
2022-10-29 17:06:51 +0200tiziodcaio(~tiziodcai@2001:470:69fc:105::1:2bf8)
2022-10-29 17:08:53 +0200 <zzz> Hecate: there's also an extra space at the beginning of each code block: https://shot.jrvieira.com/1667056109.png
2022-10-29 17:11:45 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-29 17:16:41 +0200danza(~francesco@151.68.163.113)
2022-10-29 17:17:40 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-10-29 17:28:20 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-10-29 17:30:57 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-29 17:31:44 +0200mvk(~mvk@2607:fea8:5ce3:8500::f30b)
2022-10-29 17:32:10 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-29 17:32:36 +0200img(~img@user/img)
2022-10-29 17:33:30 +0200beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt)
2022-10-29 17:34:58 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2022-10-29 17:38:20 +0200CiaoSen(~Jura@p200300c95724d3002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-10-29 17:39:06 +0200zebrag(~chris@user/zebrag)
2022-10-29 17:43:15 +0200azimut_(~azimut@gateway/tor-sasl/azimut)
2022-10-29 17:43:21 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 17:44:17 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds)
2022-10-29 17:56:10 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-10-29 17:57:10 +0200acidjnk(~acidjnk@p200300d6e7137a24c5c90248eaa00c2d.dip0.t-ipconnect.de)
2022-10-29 17:57:11 +0200danza(~francesco@151.68.163.113) (Read error: Connection reset by peer)
2022-10-29 17:59:20 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 250 seconds)
2022-10-29 18:00:06 +0200Las[m](~lasmatrix@2001:470:69fc:105::74e)
2022-10-29 18:03:00 +0200califax(~califax@user/califx) (Remote host closed the connection)
2022-10-29 18:03:44 +0200califax(~califax@user/califx)
2022-10-29 18:04:36 +0200michalz(~michalz@185.246.207.221)
2022-10-29 18:11:09 +0200chomwitt(~chomwitt@athe730-c-multi-217.home.otenet.gr)
2022-10-29 18:11:57 +0200acidjnk(~acidjnk@p200300d6e7137a24c5c90248eaa00c2d.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2022-10-29 18:18:08 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds)
2022-10-29 18:19:24 +0200econo(uid147250@user/econo)
2022-10-29 18:29:26 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-10-29 18:29:26 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-10-29 18:29:26 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 18:32:42 +0200shapr(~user@144.163.4.141) (Ping timeout: 250 seconds)
2022-10-29 18:47:54 +0200danza(~francesco@151.68.168.242)
2022-10-29 18:55:20 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:5147:575b:dd93:ff03)
2022-10-29 18:57:50 +0200mixfix41(~sdeny9ee@user/mixfix41) (Ping timeout: 250 seconds)
2022-10-29 19:00:49 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-10-29 19:02:11 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 19:02:15 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-29 19:03:56 +0200glguy(~glguy@libera/staff-emeritus/glguy) (Ping timeout: 260 seconds)
2022-10-29 19:06:55 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds)
2022-10-29 19:09:26 +0200nate3(~nate@98.45.169.16)
2022-10-29 19:10:08 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 276 seconds)
2022-10-29 19:11:03 +0200glguy(~glguy@libera/staff-emeritus/glguy)
2022-10-29 19:15:11 +0200Sgeo(~Sgeo@user/sgeo)
2022-10-29 19:17:46 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 250 seconds)
2022-10-29 19:18:30 +0200Buliarous(~gypsydang@46.232.210.139)
2022-10-29 19:20:51 +0200glguy(~glguy@libera/staff-emeritus/glguy) (Ping timeout: 260 seconds)
2022-10-29 19:20:58 +0200Buliarous(~gypsydang@46.232.210.139) (Client Quit)
2022-10-29 19:21:41 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-10-29 19:21:41 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-10-29 19:21:41 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 19:23:16 +0200dimsuz(~dima@185.17.131.16)
2022-10-29 19:24:11 +0200 <EvanR> dminuoso, whats wrong with postgresql-simple
2022-10-29 19:24:53 +0200glguy(~glguy@libera/staff-emeritus/glguy)
2022-10-29 19:25:58 +0200 <dimsuz> hi! learing to parse with megaparsec. Struggling to turn this: ""@@header@@\nline\nline\line\n@@header@@\nline\nline"" into [Hunk{header,[lines]}]. I have working parser for "header" and then I'm trying to sepBy header, but also need to not consume it while sepBy-ing... Need advice/direction.
2022-10-29 19:27:07 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2022-10-29 19:30:40 +0200 <EvanR> hmm I would not start with sepBy for that
2022-10-29 19:31:11 +0200 <EvanR> if you have a parser for header body optional newlines/whitespace, then you can use many on that to get a list
2022-10-29 19:33:44 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-10-29 19:33:45 +0200 <dimsuz> oh, that gives me an idea that I should write a separate parser for body. not sure though if I should make it know that it should stop if it sees 'header'. megaparsec has "notFollowedBy", maybe I should use it
2022-10-29 19:34:36 +0200danza(~francesco@151.68.168.242) (Ping timeout: 264 seconds)
2022-10-29 19:34:46 +0200 <EvanR> if it that lines can't start with @@? or @@header@@
2022-10-29 19:34:50 +0200 <EvanR> or something else
2022-10-29 19:36:15 +0200ec(~ec@gateway/tor-sasl/ec)
2022-10-29 19:36:36 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 260 seconds)
2022-10-29 19:36:50 +0200 <EvanR> you could make a line parser that fails if the first two characters is @@
2022-10-29 19:38:17 +0200moonsheep(~user@user/moonsheep)
2022-10-29 19:39:10 +0200 <dimsuz> yes, it's a diff hunk parser, so headers are stuff like "@@ +3,44 -8,55 @@", then go the lines separated by '\n', then goes another hunk (header+lines)
2022-10-29 19:39:12 +0200 <EvanR> thunk hunk parser would be, header followed by many lines
2022-10-29 19:39:24 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-10-29 19:39:32 +0200 <EvanR> then hunk parser would be, header followed by many lines
2022-10-29 19:39:45 +0200 <EvanR> the word hunk is throwing me off heavily
2022-10-29 19:39:52 +0200 <dimsuz> oh, and line parser failing wouldn't fail whole parsing?
2022-10-29 19:39:59 +0200 <moonsheep> for some procedure that may fail (i.e. a protocol of some sort) what is the best way to back out in case of an unrecoverable failure? there seems to be so many options and I never know which to pick: Alternative, MonadFail, MonadError, etc.
2022-10-29 19:40:19 +0200 <dimsuz> "hunk" is diff speak :) not sure why they're called taht
2022-10-29 19:40:21 +0200 <EvanR> that's how many works, it tries the parser repeatedly until it fails
2022-10-29 19:40:27 +0200acidjnk(~acidjnk@p200300d6e7137a24f4d49bb670ebec41.dip0.t-ipconnect.de)
2022-10-29 19:40:40 +0200 <dimsuz> EvanR: thanks, going off to try this
2022-10-29 19:40:45 +0200 <EvanR> when you use the basic combinator p1 <|> p2, p1 is tried, if it fails p2 is tried, if that fails p1 <|> p2 fails
2022-10-29 19:41:05 +0200 <EvanR> something like that is going on within many
2022-10-29 19:41:09 +0200 <dimsuz> yep, I understand it for <|> but somehow didn't intuitively undrstood it for many
2022-10-29 19:41:18 +0200 <moonsheep> on a related note, that seems like the main advantage of Alternative, but I'm not sure if it plays nice with IO
2022-10-29 19:41:47 +0200 <EvanR> moonsheep, if you're in IO, you could throw an IO exception xD
2022-10-29 19:42:08 +0200 <EvanR> if you're in pure code, something like Except or ExceptT
2022-10-29 19:42:15 +0200 <moonsheep> I am in a MonadUnliftIO
2022-10-29 19:42:22 +0200 <EvanR> if you're in a sophisticated monad transformer...
2022-10-29 19:42:30 +0200 <moonsheep> pretty much
2022-10-29 19:42:45 +0200 <EvanR> consult your sophisticated monad transformer manual / service representative
2022-10-29 19:42:52 +0200 <moonsheep> hmm right
2022-10-29 19:43:15 +0200 <moonsheep> well, MonadError "feels" like it was built exactly for this kind of scenario
2022-10-29 19:43:20 +0200 <int-e> don't get yourself into a bind
2022-10-29 19:45:02 +0200 <[Leary]> moonsheep: The unliftio paradigm already has its own opinions about how exceptions should be produced and recovered from, as I recall. If you're in that world already, it's probably worth heeding.
2022-10-29 19:45:16 +0200 <moonsheep> so I should use IO exceptions?
2022-10-29 19:46:07 +0200 <moonsheep> I have some finallys that always have to fire at the end of all things, no matter what, and I was scared that they would interact weirdly with other things
2022-10-29 19:46:14 +0200 <EvanR> wait that's not what we were saying at all
2022-10-29 19:46:35 +0200 <moonsheep> well what are those "opinions on how exceptions should be produced"?
2022-10-29 19:46:37 +0200 <EvanR> I haven't used MonadUnliftIO but there's probably some more appropriate exception mechanism
2022-10-29 19:46:46 +0200 <EvanR> for that
2022-10-29 19:47:33 +0200ddellacosta(~ddellacos@89.45.224.247)
2022-10-29 19:47:37 +0200 <moonsheep> unliftio does have a handy "throwString", should I just use that for one-off errors?
2022-10-29 19:49:45 +0200 <EvanR> it looks like throwIO is recommended if you have your own exception type, else if you can't be arsed use throwString
2022-10-29 19:50:13 +0200 <moonsheep> right
2022-10-29 19:50:21 +0200 <moonsheep> sounds like a decent plan
2022-10-29 19:50:29 +0200 <EvanR> has the same effect as fromEither if you are converting an Either into an exception
2022-10-29 19:52:54 +0200ddellacosta(~ddellacos@89.45.224.247) (Ping timeout: 252 seconds)
2022-10-29 19:54:23 +0200 <EvanR> looks like they reference and depend on the package safe-exceptions
2022-10-29 19:56:24 +0200 <EvanR> which claims that by default exception handling is scary
2022-10-29 19:57:10 +0200 <EvanR> which kind of sounds like bootstrapping its own purpose
2022-10-29 19:58:46 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Remote host closed the connection)
2022-10-29 20:00:33 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com)
2022-10-29 20:00:49 +0200 <geekosaur> exception handling by default is scary
2022-10-29 20:00:50 +0200 <moonsheep> yeah that's kind of the point of unliftioo
2022-10-29 20:01:23 +0200 <geekosaur> and bracket, which issupposed to hide some of that scariness, propitiates it instead
2022-10-29 20:02:10 +0200 <sm> g'day all
2022-10-29 20:02:26 +0200wroathe(~wroathe@50.205.197.50)
2022-10-29 20:02:26 +0200wroathe(~wroathe@50.205.197.50) (Changing host)
2022-10-29 20:02:26 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 20:03:11 +0200 <sm> is there an easy way to get a human-friendly hash of a haskell value, eg of a Data instance ?
2022-10-29 20:04:25 +0200 <moonsheep> does it have to be cryptographically secure?
2022-10-29 20:04:38 +0200 <sm> not really
2022-10-29 20:04:39 +0200 <sm> no, not at all
2022-10-29 20:04:45 +0200 <moonsheep> what about Hashable then?
2022-10-29 20:04:49 +0200talismanick(~talismani@76.133.152.122) (Ping timeout: 246 seconds)
2022-10-29 20:04:57 +0200 <sm> it's more important that it be fairly reliably unique
2022-10-29 20:05:27 +0200 <sm> I found that, but I think it produces an integer ? I'm wanting something more alphanumeric
2022-10-29 20:05:36 +0200 <moonsheep> well Hashable doesn't do any guarantees on the algorithm used
2022-10-29 20:05:53 +0200 <EvanR> render the Integer in hex xD
2022-10-29 20:06:17 +0200 <EvanR> I guess that doesn't guarantee there will be letters
2022-10-29 20:06:32 +0200 <moonsheep> I mean, the representation you use is largely irrelevant
2022-10-29 20:06:48 +0200 <moonsheep> if your issue is that integers are too small you could use a bytestring I guess
2022-10-29 20:07:36 +0200 <sm> this is something users will see, I want it to look like familiar, like an md5 hash
2022-10-29 20:08:13 +0200 <sm> would md5 be wrong for this ?
2022-10-29 20:08:25 +0200 <moonsheep> so then are you asking for a way to represent integers as strings in some base (like base16)?
2022-10-29 20:08:42 +0200 <moonsheep> sm: md5 is vulnerable to collision attacks, but if those aren't a problem then it's fine
2022-10-29 20:08:50 +0200 <sm> concretely, people want to see a unique content-based hash for each of their hledger transactions
2022-10-29 20:08:50 +0200 <[Leary]> I would just render the integer in base64.
2022-10-29 20:09:31 +0200 <moonsheep> yeah base64 is pretty nice
2022-10-29 20:09:33 +0200 <sm> hashable + base64, that sounds like an option
2022-10-29 20:09:38 +0200 <moonsheep> I wonder why hashes aren't more often represented like that
2022-10-29 20:09:53 +0200 <moonsheep> it's always base16 for some reason
2022-10-29 20:10:38 +0200 <moonsheep> well I guess padding =s sure
2022-10-29 20:11:30 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-10-29 20:12:49 +0200 <sm> https://hackage.haskell.org/package/pureMD5 might be plan B
2022-10-29 20:13:12 +0200 <sm> (with custom haskell value -> hash generator, which I expect I'll need anyway)
2022-10-29 20:13:16 +0200 <sm> thanks all
2022-10-29 20:13:26 +0200 <darkling> If we're generating IDs that are going to be turned into base64 strings for human consumption, we always make sure they're a multiple of 3 bytes, so there's no trailing = symbols.
2022-10-29 20:15:16 +0200 <EvanR> moonsheep, bespoke ways to display hashes or IDs abound in web land, perhaps you would be interested in applying for a job at amazon to learn more. Don't think call now
2022-10-29 20:16:24 +0200 <moonsheep> darkling: if you know the length in advance you don't really need the trailing =
2022-10-29 20:17:18 +0200 <moonsheep> EvanR: one day
2022-10-29 20:18:29 +0200nate3(~nate@98.45.169.16) (Ping timeout: 272 seconds)
2022-10-29 20:18:50 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-10-29 20:25:30 +0200AlexNoo_(~AlexNoo@178.34.163.109)
2022-10-29 20:27:11 +0200Alex_test(~al_test@178.34.162.124) (Ping timeout: 244 seconds)
2022-10-29 20:27:44 +0200danza(~francesco@151.68.168.242)
2022-10-29 20:28:48 +0200AlexNoo(~AlexNoo@178.34.162.124) (Ping timeout: 255 seconds)
2022-10-29 20:28:58 +0200AlexZenon(~alzenon@178.34.162.124) (Ping timeout: 246 seconds)
2022-10-29 20:30:45 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-10-29 20:31:33 +0200Alex_test(~al_test@178.34.163.109)
2022-10-29 20:32:26 +0200cowboy8625(~cowboy@rrcs-173-198-134-163.west.biz.rr.com)
2022-10-29 20:36:47 +0200AlexZenon(~alzenon@178.34.163.109)
2022-10-29 20:38:09 +0200 <dimsuz> EvanR: thanks for the help with parser combinators, it all worked out beautifully. Feeling good, going for a walk. Cheers!
2022-10-29 20:38:34 +0200dimsuz(~dima@185.17.131.16) (Quit: leaving)
2022-10-29 20:41:45 +0200son0p(~ff@181.136.122.143) (Remote host closed the connection)
2022-10-29 20:44:23 +0200mvk(~mvk@2607:fea8:5ce3:8500::f30b) (Ping timeout: 276 seconds)
2022-10-29 20:45:34 +0200nate3(~nate@98.45.169.16)
2022-10-29 20:47:25 +0200danza(~francesco@151.68.168.242) (Read error: Connection reset by peer)
2022-10-29 20:54:08 +0200acidjnk(~acidjnk@p200300d6e7137a24f4d49bb670ebec41.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-10-29 20:54:35 +0200nate3(~nate@98.45.169.16) (Ping timeout: 272 seconds)
2022-10-29 20:55:35 +0200AlexNoo_AlexNoo
2022-10-29 20:56:14 +0200 <APic> Guad Nocht!
2022-10-29 21:03:05 +0200 <EvanR> sometimes you see proposals to add something like monads, do notation, or something like just State monad to language X. If they could only steal one thing I would settle for Functor
2022-10-29 21:03:37 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds)
2022-10-29 21:03:48 +0200 <EvanR> spread the news about Functor please because it's large scale missing too
2022-10-29 21:03:52 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-10-29 21:04:12 +0200 <EvanR> and much more widely applicable
2022-10-29 21:04:40 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-10-29 21:06:33 +0200 <EvanR> geekosaur, what's wrong with bracket?
2022-10-29 21:06:48 +0200moonsheep(~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2))
2022-10-29 21:07:13 +0200moonsheep(~user@185.154.9.186)
2022-10-29 21:07:26 +0200moonsheep(~user@185.154.9.186) ()
2022-10-29 21:07:34 +0200 <geekosaur> IIRC a missing `mask` in the recovery/after-close part means an exception there can leak resources
2022-10-29 21:08:00 +0200 <geekosaur> and it won't be fixed because "someone might be relying on it running without `mask`"
2022-10-29 21:08:43 +0200 <EvanR> that does sound a bit dubious
2022-10-29 21:08:53 +0200 <c_wraith> I think you have to mask the whole bracket and strategically unmask to make it work right, too
2022-10-29 21:09:09 +0200 <c_wraith> Like, you can't just mask in the release action, because that still leaves a gap
2022-10-29 21:09:19 +0200 <geekosaur> https://stackoverflow.com/questions/64468126/how-to-make-bracket-safe-from-async-exception
2022-10-29 21:09:25 +0200 <geekosaur> yeh
2022-10-29 21:09:31 +0200 <EvanR> it is specific to async exceptions
2022-10-29 21:09:32 +0200 <geekosaur> this is more or less why unliftio
2022-10-29 21:09:51 +0200 <c_wraith> well yes. async exceptions are the only thing mask stops
2022-10-29 21:10:46 +0200 <geekosaur> but async exceptions are also essentially the only thing that can lead to resource leaks (unless you're really careless)
2022-10-29 21:10:47 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-10-29 21:11:04 +0200 <c_wraith> Oh, I've seen some careless code. :P
2022-10-29 21:11:13 +0200 <geekosaur> so have I
2022-10-29 21:11:35 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-10-29 21:11:36 +0200 <geekosaur> but more often in C or etc.; Haskell programmers usually make some attempt at safety
2022-10-29 21:11:57 +0200 <EvanR> strive to write carelessness safe code
2022-10-29 21:12:19 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 272 seconds)
2022-10-29 21:12:36 +0200 <Franciman> geekosaur: laziness can also lead to strange behaviour making your machine fail
2022-10-29 21:12:41 +0200 <Franciman> because it goes out of RAM
2022-10-29 21:12:51 +0200 <Franciman> well, not laziness per se, while careless usage of laziness
2022-10-29 21:13:14 +0200 <EvanR> careless evaluation
2022-10-29 21:13:19 +0200 <geekosaur> Franciman, given that you hate Haskell so much,m could you please go peddle your wares elsewhere?
2022-10-29 21:13:36 +0200cowboy8625(~cowboy@rrcs-173-198-134-163.west.biz.rr.com) (Quit: WeeChat 3.5)
2022-10-29 21:14:05 +0200 <Franciman> wtf
2022-10-29 21:14:11 +0200 <Franciman> ok
2022-10-29 21:14:15 +0200 <DigitalKiwi> what's funny is the majority of programs that make my machine run out of ram are not haskell
2022-10-29 21:14:34 +0200 <c_wraith> are they electron?
2022-10-29 21:14:55 +0200acidjnk(~acidjnk@p200300d6e7137a24f17133d2359444b2.dip0.t-ipconnect.de)
2022-10-29 21:15:04 +0200 <DigitalKiwi> there are a few of those yeah lol
2022-10-29 21:15:20 +0200wroathe(~wroathe@50.205.197.50)
2022-10-29 21:15:20 +0200wroathe(~wroathe@50.205.197.50) (Changing host)
2022-10-29 21:15:20 +0200wroathe(~wroathe@user/wroathe)
2022-10-29 21:15:40 +0200 <DigitalKiwi> i'm actually really shocked that signal-desktop works as well as it does heh
2022-10-29 21:15:41 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-10-29 21:15:56 +0200 <DigitalKiwi> but slack and discord == OOM
2022-10-29 21:16:10 +0200 <EvanR> wasteful usage of ram grows to meet memory upgrades?
2022-10-29 21:16:25 +0200 <DigitalKiwi> ram soldered in capped at 16GB :(
2022-10-29 21:16:26 +0200 <EvanR> it's even built into haskell
2022-10-29 21:16:33 +0200 <geekosaur> here you're pissing on laziness. last time it was "in ocaml. way better". in fact I'm hard put to see much positive in your contributions here, according to my logs
2022-10-29 21:17:07 +0200 <Franciman> ...
2022-10-29 21:17:10 +0200 <Franciman> are you serious?
2022-10-29 21:17:16 +0200 <Franciman> it was a joke...
2022-10-29 21:17:17 +0200 <EvanR> how's the laziness situation on ocaml
2022-10-29 21:17:28 +0200 <DigitalKiwi> i'm too lazy to learn it
2022-10-29 21:17:45 +0200 <DigitalKiwi> so it's going great i guess?
2022-10-29 21:17:48 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 21:17:49 +0200son0p(~ff@181.136.122.143)
2022-10-29 21:17:56 +0200 <EvanR> 🥁
2022-10-29 21:18:00 +0200 <Franciman> let's put it clear geekosaur
2022-10-29 21:18:14 +0200 <Franciman> i have no interest in showing things
2022-10-29 21:18:34 +0200 <Franciman> i wanted to participate in the conversation without saying haskell sucks
2022-10-29 21:18:40 +0200 <Franciman> i even said «careless usage of laziness»
2022-10-29 21:18:56 +0200 <Franciman> what's edgy about it?
2022-10-29 21:19:34 +0200 <EvanR> SPJ: Haskell is useless. Franciman: Haskell sucks
2022-10-29 21:19:44 +0200 <Franciman> i don't care whether haskell sucks or not
2022-10-29 21:19:47 +0200 <Franciman> i was wrong in the past
2022-10-29 21:20:09 +0200 <Franciman> i've done my share of errors
2022-10-29 21:20:38 +0200 <EvanR> cunningham & cunningham: everything sucks
2022-10-29 21:21:47 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-10-29 21:24:47 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-10-29 21:26:06 +0200 <geekosaur> sysadmin: all hardware sucks, all software sucks
2022-10-29 21:26:44 +0200 <Franciman> bye bye
2022-10-29 21:26:48 +0200Franciman(~Franciman@mx1.fracta.dev) (WeeChat 3.0)
2022-10-29 21:29:33 +0200SnoopDoll(~SnoopDoll@host-95-251-162-186.retail.telecomitalia.it)
2022-10-29 21:29:48 +0200buffet(~buffet@buffet.sh) (WeeChat 3.5)
2022-10-29 21:30:16 +0200SnoopDoll(~SnoopDoll@host-95-251-162-186.retail.telecomitalia.it) ()
2022-10-29 21:31:09 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal)
2022-10-29 21:44:56 +0200 <dsal> dminuoso: I've not looked at hasql. But what's wrong with postgresql-simple?
2022-10-29 21:46:47 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-10-29 21:46:54 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:41f8:4e00:54f7:b844) (Quit: caryhartline)
2022-10-29 21:49:40 +0200son0p(~ff@181.136.122.143) (Remote host closed the connection)
2022-10-29 21:55:55 +0200polo(~polo@user/polo)
2022-10-29 22:00:47 +0200Cale_(~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com)
2022-10-29 22:01:52 +0200Cale(~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds)
2022-10-29 22:01:58 +0200nate3(~nate@98.45.169.16)
2022-10-29 22:05:02 +0200Cale_(~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com) (Client Quit)
2022-10-29 22:05:10 +0200Cale(~cale@cpef48e38ee8583-cm30b7d4b3fc20.cpe.net.cable.rogers.com)
2022-10-29 22:08:05 +0200Guest|57(~Guest|57@128.172.245.79)
2022-10-29 22:15:23 +0200polo(~polo@user/polo) (Ping timeout: 276 seconds)
2022-10-29 22:20:25 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 255 seconds)
2022-10-29 22:24:05 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-10-29 22:25:58 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2022-10-29 22:26:41 +0200qhong(~qhong@rescomp-21-400677.stanford.edu) (Remote host closed the connection)
2022-10-29 22:26:50 +0200cyphase(~cyphase@user/cyphase)
2022-10-29 22:29:57 +0200nate3(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2022-10-29 22:29:58 +0200mrianbloom(uid350277@id-350277.ilkley.irccloud.com)
2022-10-29 22:30:54 +0200 <mrianbloom> Can you specify that you want some example code to be compiled in a package even if it is not an executable and has no main function?
2022-10-29 22:31:34 +0200 <mrianbloom> Currently using stack but I guess this also applies to cabal.
2022-10-29 22:37:26 +0200RevoGen(~RevoGen@136.167.84.221)
2022-10-29 22:40:34 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-10-29 22:42:34 +0200 <sclv> mrianbloom: if you have a library stanza, all modules in the library will be compiled
2022-10-29 22:42:46 +0200buffet(~buffet@buffet.sh)
2022-10-29 22:42:54 +0200buffet(~buffet@buffet.sh) (WeeChat 3.5)
2022-10-29 22:43:11 +0200 <mrianbloom> I see.
2022-10-29 22:44:01 +0200 <mrianbloom> Seems like I'm suggesting it can be used by library users.
2022-10-29 22:44:56 +0200seriley(~seriley@75.164.74.1)
2022-10-29 22:45:17 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 22:45:31 +0200lechner-(~lechner@2601:641:400:1e5::d35)
2022-10-29 22:46:17 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 240 seconds)
2022-10-29 22:47:06 +0200zebrag(~chris@user/zebrag) (Quit: Konversation terminated!)
2022-10-29 22:48:00 +0200 <seriley> When I do :info Enum in ghci, the first line gives me "type Enum :: * -> Constraint. What does that mean?
2022-10-29 22:49:30 +0200 <geekosaur> Enum takes a Type and produces a Constraint. so something like `Enum Int` is legal as long as it occurs to the left of a `=>`
2022-10-29 22:49:38 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 252 seconds)
2022-10-29 22:49:47 +0200 <[Leary]> mrianbloom: If you don't want it to be exposed for use like a regular library module, you can keep it internal by putting it in `other modules`. Though in that case, I'm not certain it will be compiled without being a dependency; you may need to do an `import MyLibrary.Example()` somewhere.
2022-10-29 22:49:51 +0200 <geekosaur> but `Enum Monad` would be ill-typed as its kind is not `*` but `* -> *`
2022-10-29 22:50:16 +0200 <seriley> thanks
2022-10-29 22:50:27 +0200 <mrianbloom> I see, thank you.
2022-10-29 22:50:35 +0200 <geekosaur> nor can you say `foo :: Enum Int` because it's a Constraint instead of a Type
2022-10-29 22:51:29 +0200 <seriley> ok. That makes sense
2022-10-29 22:52:50 +0200 <seriley> Constraints only work on the left of => in a type declaration?
2022-10-29 22:53:17 +0200RevoGen(~RevoGen@136.167.84.221) (Remote host closed the connection)
2022-10-29 22:54:36 +0200 <geekosaur> yes
2022-10-29 22:54:45 +0200 <monochrom> For beginners it is simpler to ignore "type Enum :: * -> Constraint" and focus on "class Enum a where ..." and some of the instances.
2022-10-29 22:54:50 +0200 <geekosaur> ^
2022-10-29 22:55:11 +0200 <geekosaur> that teells you what it can do., the rest is more or less typechecker gobbledygook
2022-10-29 22:55:50 +0200 <seriley> I see. thanks again
2022-10-29 22:55:55 +0200 <monochrom> Hell, in general, beginners better focus on Haskell 2010; hell, sometimes even that is too big.
2022-10-29 22:57:47 +0200 <monochrom> After you understand the concept of type classes, then this Constraint business is a powerful generalization. But walk before run, low tech before high tech.
2022-10-29 22:59:50 +0200 <[Leary]> Haskell is just big full-stop. If I were teaching it, I would start with plain LC and introduce one Haskell feature at a time.
2022-10-29 23:01:20 +0200ddellacosta(~ddellacos@143.244.47.100)
2022-10-29 23:01:33 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-29 23:03:05 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-10-29 23:07:26 +0200thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Ping timeout: 250 seconds)
2022-10-29 23:10:07 +0200Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 272 seconds)
2022-10-29 23:10:40 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com)
2022-10-29 23:12:55 +0200freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-10-29 23:13:47 +0200nate3(~nate@98.45.169.16)
2022-10-29 23:13:54 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2022-10-29 23:14:09 +0200Lycurgus(~juan@user/Lycurgus)
2022-10-29 23:19:26 +0200Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org)
2022-10-29 23:19:37 +0200nate3(~nate@98.45.169.16) (Ping timeout: 272 seconds)
2022-10-29 23:22:01 +0200polo(~polo@user/polo)
2022-10-29 23:24:46 +0200Clint(~Clint@user/clint) (Quit: restarting)
2022-10-29 23:30:11 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2022-10-29 23:30:28 +0200nate3(~nate@98.45.169.16)
2022-10-29 23:33:46 +0200polo(~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2022-10-29 23:34:05 +0200zzzyin
2022-10-29 23:34:41 +0200polo(~polo@user/polo)
2022-10-29 23:34:44 +0200 <yin> hi. i'm trying out hls with CoC on nvim. where can i get a list of all the commands i can use?
2022-10-29 23:35:08 +0200 <yin> been searching the docs for about 15 mins and am lost
2022-10-29 23:37:59 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 272 seconds)
2022-10-29 23:38:42 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-10-29 23:42:55 +0200michalz(~michalz@185.246.207.221) (Remote host closed the connection)
2022-10-29 23:44:48 +0200Clint(~Clint@user/clint)
2022-10-29 23:48:17 +0200acidjnk(~acidjnk@p200300d6e7137a24f17133d2359444b2.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2022-10-29 23:53:25 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-10-29 23:53:48 +0200jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 264 seconds)
2022-10-29 23:56:15 +0200mmhat(~mmh@p200300f1c7307602ee086bfffe095315.dip0.t-ipconnect.de)
2022-10-29 23:57:56 +0200polo(~polo@user/polo) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2022-10-29 23:59:52 +0200zebrag(~chris@user/zebrag)