| 2021-09-22 00:00:04 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.2.1) |
| 2021-09-22 00:00:51 +0200 | max22- | (~maxime@2a01cb08833598000f1fa44417d80ccf.ipv6.abo.wanadoo.fr) (Quit: Leaving) |
| 2021-09-22 00:02:54 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-22 00:03:37 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-22 00:05:30 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 00:06:37 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-09-22 00:10:52 +0200 | son0p | (~ff@181.136.122.143) |
| 2021-09-22 00:12:37 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 00:15:37 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-09-22 00:16:48 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2021-09-22 00:18:17 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-09-22 00:26:26 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-09-22 00:28:14 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 00:29:15 +0200 | <cdsmith> | glguy: Getting all arguments was actually perfect for my use. https://github.com/haskell/haskell-language-server/pull/2228 |
| 2021-09-22 00:31:02 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-09-22 00:33:21 +0200 | <glguy> | It seems like you'd want the arguments to not be interpreted by the wrapper and *only* passed through |
| 2021-09-22 00:34:35 +0200 | <glguy> | passing through the ones handled by the wrapper itself means that, for example, things that write to files (like -t) will cause two different runtimes to write to that file |
| 2021-09-22 00:40:55 +0200 | wroathe | (~wroathe@96-88-30-181-static.hfc.comcastbusiness.net) |
| 2021-09-22 00:40:55 +0200 | wroathe | (~wroathe@96-88-30-181-static.hfc.comcastbusiness.net) (Changing host) |
| 2021-09-22 00:40:55 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 00:48:06 +0200 | <monochrom> | w00t new ghcup |
| 2021-09-22 00:50:21 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 00:54:05 +0200 | nfd | (~nfd@user/nfd) (Ping timeout: 264 seconds) |
| 2021-09-22 00:54:40 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-09-22 00:55:13 +0200 | MQ-17J | (~MQ-17J@8.21.10.6) (Ping timeout: 265 seconds) |
| 2021-09-22 00:55:46 +0200 | maroloccio | (~marolocci@93-142-92-177.adsl.net.t-com.hr) (Quit: WeeChat 3.0) |
| 2021-09-22 00:56:57 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 00:58:37 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 01:12:55 +0200 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-09-22 01:18:22 +0200 | <geekosaur> | wee, big upgrade completed and xmonad now happily runniung based on 8.10.7 instead of 8.10.4 |
| 2021-09-22 01:18:42 +0200 | <geekosaur> | other utils can wait, they'll rebuild as needed anyway |
| 2021-09-22 01:19:17 +0200 | <geekosaur> | cabal++ |
| 2021-09-22 01:20:25 +0200 | <hpc> | cabal# .net |
| 2021-09-22 01:24:59 +0200 | kimjetwav | (~user@2607:fea8:235f:9730:158b:8b68:ef55:bdbf) |
| 2021-09-22 01:27:17 +0200 | <shapr> | yay xmonad! |
| 2021-09-22 01:28:01 +0200 | hiruji` | (~hiruji@72.74.190.75) |
| 2021-09-22 01:28:17 +0200 | acidjnk | (~acidjnk@p200300d0c703cb44319f4c33bc64626e.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2021-09-22 01:28:17 +0200 | hiruji | (~hiruji@user/hiruji) (Ping timeout: 264 seconds) |
| 2021-09-22 01:33:26 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-09-22 01:33:35 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-09-22 01:35:12 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 01:36:11 +0200 | TranquilEcho | (~grom@user/tranquilecho) (Quit: WeeChat 2.8) |
| 2021-09-22 01:37:58 +0200 | hiruji` | (~hiruji@72.74.190.75) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-09-22 01:38:16 +0200 | hiruji | (~hiruji@user/hiruji) |
| 2021-09-22 01:41:29 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-09-22 01:42:08 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2021-09-22 01:42:10 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 01:42:19 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-22 01:42:39 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 01:42:48 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-22 01:43:08 +0200 | hiruji | (~hiruji@user/hiruji) (Client Quit) |
| 2021-09-22 01:43:09 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 01:49:25 +0200 | asivitz | (uid178348@id-178348.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-22 01:51:06 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.3) |
| 2021-09-22 01:57:03 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 01:57:03 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 01:57:03 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 02:00:03 +0200 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) |
| 2021-09-22 02:00:28 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 02:00:43 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-22 02:02:32 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-22 02:02:45 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 02:04:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Quit: Lost terminal) |
| 2021-09-22 02:04:53 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-09-22 02:06:24 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 02:09:58 +0200 | andreabedini[m] | (~andreabed@2001:470:69fc:105::c821) |
| 2021-09-22 02:10:29 +0200 | jespada | (~jespada@2803:9800:9842:7a62:4d47:2975:7b31:a447) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-09-22 02:11:47 +0200 | remexre | (~nathan@user/remexre) (Read error: Connection reset by peer) |
| 2021-09-22 02:13:21 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 02:21:42 +0200 | <lbseale> | I see that `sum` is dangerous because it has a lazy accumulator, what should I use instead? |
| 2021-09-22 02:22:35 +0200 | <geekosaur> | write it yourself using foldl', I think |
| 2021-09-22 02:23:16 +0200 | <geekosaur> | (also iirc there's already a proposal to change that) |
| 2021-09-22 02:23:44 +0200 | <Axman6> | foldl' (+) 0 |
| 2021-09-22 02:24:12 +0200 | <lbseale> | ok |
| 2021-09-22 02:25:36 +0200 | <Axman6> | I think generally GHC is good enough at inlining and doing strictness analysis on sum though |
| 2021-09-22 02:25:40 +0200 | <dsal> | You can also just use sum. |
| 2021-09-22 02:27:50 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) (Ping timeout: 252 seconds) |
| 2021-09-22 02:28:10 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) |
| 2021-09-22 02:36:57 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-22 02:43:36 +0200 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) (Read error: Connection reset by peer) |
| 2021-09-22 02:44:17 +0200 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) |
| 2021-09-22 02:44:36 +0200 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) (Quit: Leaving) |
| 2021-09-22 02:48:20 +0200 | <dsal> | The problem with "X being dangerous" is that it's easier to fix things than to have people forget that the easy obvious thing is no longer dangerous. I've seen a lot of dumb bad bugs in code because people tried to do a workaround for something "bad" that got fixed and they got the workaround wrong. |
| 2021-09-22 02:50:43 +0200 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) |
| 2021-09-22 02:52:32 +0200 | jacks | (~bc8165b6@217.29.117.252) |
| 2021-09-22 02:53:00 +0200 | <jacks> | lbseale, I think ghc is smart enough to optimize that away, at least with -O2 (and maybe even without) |
| 2021-09-22 02:53:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 02:58:21 +0200 | matijja | (~matijja@193.77.181.201) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-09-22 02:58:47 +0200 | matijja | (~matijja@193.77.181.201) |
| 2021-09-22 02:59:41 +0200 | alzgh | (~alzgh@user/alzgh) (Remote host closed the connection) |
| 2021-09-22 03:02:14 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-09-22 03:03:45 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-09-22 03:04:14 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 03:10:17 +0200 | xff0x | (~xff0x@2001:1a81:53a2:cb00:fe64:bcbc:d8a9:c1f9) (Ping timeout: 264 seconds) |
| 2021-09-22 03:11:52 +0200 | xff0x | (~xff0x@2001:1a81:53e4:c100:5359:f89f:44a7:385e) |
| 2021-09-22 03:17:10 +0200 | remexre | (~nathan@user/remexre) |
| 2021-09-22 03:25:42 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 03:25:45 +0200 | neurocyte0136 | (~neurocyte@185.238.252.138) |
| 2021-09-22 03:25:45 +0200 | neurocyte0136 | (~neurocyte@185.238.252.138) (Changing host) |
| 2021-09-22 03:25:45 +0200 | neurocyte0136 | (~neurocyte@user/neurocyte) |
| 2021-09-22 03:26:18 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 03:27:35 +0200 | andreabedini[m] | (~andreabed@2001:470:69fc:105::c821) () |
| 2021-09-22 03:27:40 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) (Ping timeout: 252 seconds) |
| 2021-09-22 03:27:40 +0200 | neurocyte0136 | neurocyte013 |
| 2021-09-22 03:30:44 +0200 | matijja | (~matijja@193.77.181.201) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-09-22 03:31:48 +0200 | andreabedini | (~andreabed@8s8kj6nmjrp47ztpwbd7.ip6.superloop.com) |
| 2021-09-22 03:32:35 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 03:32:59 +0200 | matijja | (~matijja@193.77.181.201) |
| 2021-09-22 03:35:09 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-22 03:36:08 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 03:41:00 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 265 seconds) |
| 2021-09-22 03:44:33 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-22 03:50:20 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-09-22 03:53:53 +0200 | iqubic | (~user@2601:602:9502:c70:f7dd:50c9:a1b6:901a) |
| 2021-09-22 03:55:47 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-22 03:56:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 03:59:28 +0200 | a6a45081-2b83 | (~aditya@2601:249:4300:1296:88ec:cc73:84d4:1507) |
| 2021-09-22 03:59:29 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) (Ping timeout: 264 seconds) |
| 2021-09-22 03:59:52 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 04:00:10 +0200 | <a6a45081-2b83> | so I'm trying to debug a big program, I add trace statements like `traceShowM ("foo", foo, "bar", bar...)` and then compile it and run it to check what variable values are |
| 2021-09-22 04:00:19 +0200 | <a6a45081-2b83> | is there an easier way like adding breakpoints and stuff? |
| 2021-09-22 04:00:42 +0200 | <a6a45081-2b83> | and also compiling everytime and running in itself takes most of the time |
| 2021-09-22 04:02:23 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:705e:acf0:71e7:8a79) (Quit: Leaving) |
| 2021-09-22 04:03:40 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 04:09:37 +0200 | Melvar | (~melvar@dslb-178-001-195-022.178.001.pools.vodafone-ip.de) (Quit: WeeChat 3.2) |
| 2021-09-22 04:10:20 +0200 | <dsal> | Make small programs and verify they work correctly, and then combine them into larger programs. |
| 2021-09-22 04:11:05 +0200 | <Axman6> | also using GHCi means you don't need to wait as long to compile. GHCi has a debugger built in too |
| 2021-09-22 04:11:45 +0200 | <a6a45081-2b83> | yeah, I'm trying to use `stack ghci` but idk why it is giving me an error which `stack build` is not ... hmm .. |
| 2021-09-22 04:12:33 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) |
| 2021-09-22 04:12:49 +0200 | dolio | (~dolio@130.44.130.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-09-22 04:13:58 +0200 | <Axman6> | well, we have no idea either if you don't share the error... |
| 2021-09-22 04:15:05 +0200 | td_ | (~td@muedsl-82-207-238-060.citykom.de) (Ping timeout: 252 seconds) |
| 2021-09-22 04:16:57 +0200 | <a6a45081-2b83> | this -> https://hastebin.com/kugixifonu.properties |
| 2021-09-22 04:17:02 +0200 | td_ | (~td@94.134.91.222) |
| 2021-09-22 04:17:10 +0200 | tommd | (~tommd@75-164-130-101.ptld.qwest.net) (Ping timeout: 252 seconds) |
| 2021-09-22 04:18:13 +0200 | <dsal> | The type of extend is being inferred incorrectly. You'll need to specify the type you mean it to have. |
| 2021-09-22 04:18:21 +0200 | <Axman6> | any reason you're using foldrM when you don't use the monad at all? |
| 2021-09-22 04:18:56 +0200 | <dsal> | (I can't even tell what's meant from this context) |
| 2021-09-22 04:19:29 +0200 | <a6a45081-2b83> | idk why it is not treating extend as a polymorphic function and binding it's first argument to [Mode] instead of [as] |
| 2021-09-22 04:19:46 +0200 | dolio | (~dolio@130.44.130.54) |
| 2021-09-22 04:20:20 +0200 | <dsal> | Well, if you want it to have a particular type, you can say that. It'll make reading easier as well. |
| 2021-09-22 04:20:28 +0200 | <a6a45081-2b83> | i remember it works fine when I add the type definition for extend |
| 2021-09-22 04:20:47 +0200 | <a6a45081-2b83> | I wonder why stack build doesn't complain about this ... hmm ... |
| 2021-09-22 04:20:58 +0200 | <awpr> | https://wiki.haskell.org/Monomorphism_restriction |
| 2021-09-22 04:21:13 +0200 | <awpr> | could be some extension that implies NoMonomorphismRestriction is enabled in one or the other |
| 2021-09-22 04:21:27 +0200 | <a6a45081-2b83> | yeah very likely |
| 2021-09-22 04:23:53 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 252 seconds) |
| 2021-09-22 04:24:01 +0200 | <a6a45081-2b83> | found something: https://gitlab.haskell.org/ghc/ghc/-/issues/3202 |
| 2021-09-22 04:25:18 +0200 | <awpr> | I don't /think/ that should affect .hs files being loaded by ghci |
| 2021-09-22 04:25:19 +0200 | andreabedini | (~andreabed@8s8kj6nmjrp47ztpwbd7.ip6.superloop.com) (Quit: WeeChat 3.0.1) |
| 2021-09-22 04:25:30 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 04:27:27 +0200 | <a6a45081-2b83> | yeah adding an explicit type seems to have fixed it and is easier, seems like stack ghci is not picking up flags from my .cabal file ... |
| 2021-09-22 04:28:51 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-22 04:29:08 +0200 | <awpr> | hmm, I think it should respect those. how are you using stack ghci? |
| 2021-09-22 04:29:26 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2021-09-22 04:31:35 +0200 | <a6a45081-2b83> | this is the stack.yaml file: https://github.com/iu-parfunc/gibbon/blob/master/gibbon-compiler/stack.yaml |
| 2021-09-22 04:32:14 +0200 | <a6a45081-2b83> | but I guess it's not in sync with <project_name>.cabal: https://github.com/iu-parfunc/gibbon/blob/master/gibbon-compiler/gibbon.cabal |
| 2021-09-22 04:32:37 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 04:33:57 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-22 04:34:48 +0200 | <awpr> | my hunch is if you're specifying the filename on the command line, Stack might not understand it's part of the package, and just try to load it as a standalone Haskell file |
| 2021-09-22 04:43:07 +0200 | hololeap | (~hololeap@user/hololeap) |
| 2021-09-22 04:44:29 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 264 seconds) |
| 2021-09-22 04:46:16 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-09-22 04:48:06 +0200 | andreabedini | (~andreabed@8s8kj6nmjrp47ztpwbd7.ip6.superloop.com) |
| 2021-09-22 04:51:56 +0200 | andreabedini | (~andreabed@8s8kj6nmjrp47ztpwbd7.ip6.superloop.com) (Client Quit) |
| 2021-09-22 04:52:03 +0200 | waleee | (~waleee@h-98-128-228-119.NA.cust.bahnhof.se) (Ping timeout: 265 seconds) |
| 2021-09-22 04:53:40 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-22 04:56:42 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 04:59:40 +0200 | nfd | (~nfd@user/nfd) |
| 2021-09-22 04:59:57 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-22 05:03:22 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-22 05:06:33 +0200 | hpc | (~juzz@ip98-169-35-13.dc.dc.cox.net) (Ping timeout: 265 seconds) |
| 2021-09-22 05:06:55 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 05:07:50 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-22 05:08:13 +0200 | hpc | (~juzz@ip98-169-35-13.dc.dc.cox.net) |
| 2021-09-22 05:12:50 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) (Ping timeout: 252 seconds) |
| 2021-09-22 05:17:02 +0200 | zebrag | (~chris@user/zebrag) (Remote host closed the connection) |
| 2021-09-22 05:18:14 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 05:22:13 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-09-22 05:25:25 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-09-22 05:27:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 05:31:10 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) |
| 2021-09-22 05:31:19 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) |
| 2021-09-22 05:35:08 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-22 05:38:28 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 05:38:29 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-09-22 05:38:58 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-22 05:39:34 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 05:40:15 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Ping timeout: 276 seconds) |
| 2021-09-22 05:40:50 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2021-09-22 05:46:36 +0200 | thyriaen | (~thyriaen@dynamic-078-054-003-131.78.54.pool.telefonica.de) |
| 2021-09-22 05:55:19 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 05:55:20 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 05:55:20 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 05:59:45 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 06:00:12 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2021-09-22 06:00:50 +0200 | yauhsien_ | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 06:01:02 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 2021-09-22 06:01:14 +0200 | nfd | (~nfd@user/nfd) (Ping timeout: 252 seconds) |
| 2021-09-22 06:05:23 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-09-22 06:06:54 +0200 | img | (~img@user/img) |
| 2021-09-22 06:10:08 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 06:10:52 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-09-22 06:11:17 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 06:12:25 +0200 | kid-icarus | (~kid-icaru@c-24-5-41-43.hsd1.ca.comcast.net) |
| 2021-09-22 06:13:48 +0200 | zebrag | (~chris@user/zebrag) (Remote host closed the connection) |
| 2021-09-22 06:15:46 +0200 | yauhsien_ | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-22 06:16:23 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 06:21:05 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-09-22 06:28:22 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) |
| 2021-09-22 06:35:40 +0200 | kid-icarus | (~kid-icaru@c-24-5-41-43.hsd1.ca.comcast.net) (Quit: Client closed) |
| 2021-09-22 06:41:17 +0200 | <jle`> | haskell is pretty neat |
| 2021-09-22 06:45:07 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2021-09-22 06:45:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 06:47:27 +0200 | thyriaen | (~thyriaen@dynamic-078-054-003-131.78.54.pool.telefonica.de) (Quit: Leaving) |
| 2021-09-22 06:48:41 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 06:48:41 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 06:48:41 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 06:50:42 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-22 06:52:45 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) |
| 2021-09-22 06:54:21 +0200 | a6a45081-2b83 | (~aditya@2601:249:4300:1296:88ec:cc73:84d4:1507) (Remote host closed the connection) |
| 2021-09-22 06:56:07 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 06:58:26 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-22 07:02:42 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 07:07:17 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-22 07:10:42 +0200 | statusbot1 | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2021-09-22 07:10:57 +0200 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
| 2021-09-22 07:11:21 +0200 | lbseale_ | (~lbseale@user/ep1ctetus) |
| 2021-09-22 07:11:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 07:13:32 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 07:14:23 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Ping timeout: 252 seconds) |
| 2021-09-22 07:14:23 +0200 | Nahra` | (~user@static.161.95.99.88.clients.your-server.de) (Ping timeout: 252 seconds) |
| 2021-09-22 07:14:37 +0200 | Nahra`` | (~user@static.161.95.99.88.clients.your-server.de) |
| 2021-09-22 07:14:52 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 07:14:52 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 07:14:52 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 07:17:29 +0200 | juhp | (~juhp@128.106.188.220) (Ping timeout: 264 seconds) |
| 2021-09-22 07:17:41 +0200 | hexology | (~hexology@user/hexology) (Ping timeout: 252 seconds) |
| 2021-09-22 07:18:19 +0200 | hexology | (~hexology@user/hexology) |
| 2021-09-22 07:19:53 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-09-22 07:21:11 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-09-22 07:21:17 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 246 seconds) |
| 2021-09-22 07:24:34 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-09-22 07:24:34 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 07:24:37 +0200 | allbery_b | geekosaur |
| 2021-09-22 07:27:10 +0200 | chomwitt | (~chomwitt@ppp-94-67-1-143.home.otenet.gr) |
| 2021-09-22 07:32:03 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 07:41:16 +0200 | Izem | (~Izem@bras-base-london1483w-grc-31-74-12-158-179.dsl.bell.ca) (Good Bye) |
| 2021-09-22 07:42:47 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 07:43:47 +0200 | nfd | (~nfd@user/nfd) |
| 2021-09-22 07:49:36 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2021-09-22 07:52:37 +0200 | superbil | (~superbil@1-34-176-171.HINET-IP.hinet.net) (Quit: WeeChat 3.2) |
| 2021-09-22 07:52:58 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2021-09-22 07:53:02 +0200 | jacks | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/ (Session timeout)) |
| 2021-09-22 08:01:31 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-09-22 08:03:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 08:06:13 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-09-22 08:07:36 +0200 | shriekingnoise | (~shrieking@186.137.144.80) (Quit: Quit) |
| 2021-09-22 08:08:05 +0200 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) (Remote host closed the connection) |
| 2021-09-22 08:16:03 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) |
| 2021-09-22 08:20:46 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 08:24:10 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2021-09-22 08:26:06 +0200 | ubert | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) |
| 2021-09-22 08:27:41 +0200 | arjun | (~Srain@user/arjun) |
| 2021-09-22 08:33:00 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-09-22 08:33:16 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-09-22 08:34:27 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2021-09-22 08:35:20 +0200 | kenran | (~kenran@b2b-37-24-119-190.unitymedia.biz) |
| 2021-09-22 08:35:45 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-09-22 08:44:42 +0200 | Lycurgus | (~juan@98.4.112.204) |
| 2021-09-22 08:46:27 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-09-22 08:50:20 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 08:50:46 +0200 | ub | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) |
| 2021-09-22 08:51:32 +0200 | seeg | (~thelounge@static.89.161.217.95.clients.your-server.de) (Quit: The Lounge - https://thelounge.chat) |
| 2021-09-22 08:52:06 +0200 | seeg | (~thelounge@static.89.161.217.95.clients.your-server.de) |
| 2021-09-22 08:52:35 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 08:54:02 +0200 | fresheyeball | (~fresheyeb@c-76-25-93-164.hsd1.co.comcast.net) (Ping timeout: 246 seconds) |
| 2021-09-22 08:55:02 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-09-22 08:56:03 +0200 | fresheyeball | (~fresheyeb@c-76-25-93-164.hsd1.co.comcast.net) |
| 2021-09-22 08:56:04 +0200 | michalz | (~michalz@185.246.204.62) |
| 2021-09-22 08:58:38 +0200 | phma | (~phma@host-67-44-208-5.hnremote.net) (Read error: Connection reset by peer) |
| 2021-09-22 08:59:03 +0200 | ub | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) (Quit: ub) |
| 2021-09-22 08:59:22 +0200 | ub | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) |
| 2021-09-22 08:59:42 +0200 | phma | (~phma@host-67-44-209-62.hnremote.net) |
| 2021-09-22 09:03:50 +0200 | ub | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-22 09:06:18 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2021-09-22 09:08:40 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-09-22 09:08:42 +0200 | Nosrep | (~archbox@user/nosrep) (Ping timeout: 265 seconds) |
| 2021-09-22 09:09:45 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) |
| 2021-09-22 09:12:42 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Quit: WeeChat 3.1) |
| 2021-09-22 09:13:26 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-09-22 09:14:06 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-09-22 09:16:29 +0200 | fendor | (~fendor@77.119.193.149.wireless.dyn.drei.com) |
| 2021-09-22 09:17:42 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 09:18:45 +0200 | wonko | (~wjc@62.115.229.50) |
| 2021-09-22 09:19:51 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 09:23:02 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:2e6e:d4a5:1c64:daa) |
| 2021-09-22 09:24:29 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-09-22 09:26:25 +0200 | hexfive | (~eric@50.35.83.177) |
| 2021-09-22 09:27:28 +0200 | mastarija | (~mastarija@31.217.13.108) |
| 2021-09-22 09:29:57 +0200 | hexfive | (~eric@50.35.83.177) (Client Quit) |
| 2021-09-22 09:30:50 +0200 | Guest73 | (~Guest73@wificampus-022110.grenet.fr) |
| 2021-09-22 09:32:17 +0200 | <Guest73> | hello. I've stumbled upon this type definition: `data Compose f g a = Compose { getCompose :: f (g a) } -- haskell book` |
| 2021-09-22 09:33:23 +0200 | <Guest73> | I assumed it would be used like so `Compose Node Maybe 1` |
| 2021-09-22 09:33:35 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 246 seconds) |
| 2021-09-22 09:33:52 +0200 | chele | (~chele@user/chele) |
| 2021-09-22 09:33:57 +0200 | acidjnk | (~acidjnk@p200300d0c703cb65087a628f3300f5c4.dip0.t-ipconnect.de) |
| 2021-09-22 09:33:59 +0200 | <opqdonut> | more like Compose Node Maybe Int |
| 2021-09-22 09:34:18 +0200 | <Guest73> | But the compiler yelled at me, I'm not sure I understand the constructor there |
| 2021-09-22 09:34:27 +0200 | <opqdonut> | Compose (Just [True]) :: Compose Maybe [] Bool |
| 2021-09-22 09:34:44 +0200 | <opqdonut> | you might have an easier time grokking this if you rename the value constructor to something like MkCompose |
| 2021-09-22 09:34:51 +0200 | <opqdonut> | then it's harder to mix up the types and values |
| 2021-09-22 09:35:03 +0200 | <opqdonut> | so: MkCompose (Just [True]) :: Compose Maybe [] Bool |
| 2021-09-22 09:35:46 +0200 | <Guest73> | so the inputs to the constructor have to also be in the form f (g a) ? I thought that was just what getCompose returned |
| 2021-09-22 09:36:05 +0200 | <opqdonut> | that's how named field work |
| 2021-09-22 09:36:16 +0200 | <opqdonut> | they give the type of the field, but also name the accessor function |
| 2021-09-22 09:36:35 +0200 | <Guest73> | thank you very much |
| 2021-09-22 09:36:54 +0200 | <opqdonut> | if you have something like `data Example = MkExample {getValue :: Int}` , you construct a value with `MkExample 1` |
| 2021-09-22 09:36:59 +0200 | <opqdonut> | same thing here, except more complex types |
| 2021-09-22 09:38:07 +0200 | <Guest73> | makes sense now, I should be more careful with notations from now on |
| 2021-09-22 09:39:10 +0200 | Cajun | (~Cajun@user/cajun) (Quit: Client closed) |
| 2021-09-22 09:40:03 +0200 | Guest73 | (~Guest73@wificampus-022110.grenet.fr) (Quit: Client closed) |
| 2021-09-22 09:43:56 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-22 09:49:17 +0200 | lbseale_ | (~lbseale@user/ep1ctetus) (Ping timeout: 264 seconds) |
| 2021-09-22 09:52:42 +0200 | Nahra`` | (~user@static.161.95.99.88.clients.your-server.de) (Remote host closed the connection) |
| 2021-09-22 09:55:07 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2021-09-22 09:56:55 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-22 09:56:59 +0200 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-09-22 09:58:38 +0200 | max22- | (~maxime@2a01cb088335980068341cc0d04f7803.ipv6.abo.wanadoo.fr) |
| 2021-09-22 10:00:58 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2021-09-22 10:03:09 +0200 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) |
| 2021-09-22 10:05:37 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-09-22 10:05:57 +0200 | arjun | (~Srain@user/arjun) (Remote host closed the connection) |
| 2021-09-22 10:07:44 +0200 | michalz | (~michalz@185.246.204.62) (Remote host closed the connection) |
| 2021-09-22 10:08:42 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-09-22 10:11:02 +0200 | xff0x | (~xff0x@2001:1a81:53e4:c100:5359:f89f:44a7:385e) (Ping timeout: 246 seconds) |
| 2021-09-22 10:12:03 +0200 | xff0x | (~xff0x@2001:1a81:53e4:c100:b3ec:1b10:ec18:8c2) |
| 2021-09-22 10:15:12 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-09-22 10:15:42 +0200 | qbt | (~edun@user/edun) |
| 2021-09-22 10:16:43 +0200 | mastarija | (~mastarija@31.217.13.108) (Quit: Leaving) |
| 2021-09-22 10:16:51 +0200 | michalz | (~michalz@185.246.204.61) |
| 2021-09-22 10:17:40 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-09-22 10:17:40 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 10:17:43 +0200 | allbery_b | geekosaur |
| 2021-09-22 10:21:55 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-22 10:21:59 +0200 | chris | Guest3894 |
| 2021-09-22 10:22:16 +0200 | <sshine> | 'ghcup tui' is really kinda neat. |
| 2021-09-22 10:22:44 +0200 | <maerwald[m]> | 💯 |
| 2021-09-22 10:24:04 +0200 | <sshine> | if I hadn't read a comment on this channel about HLS, I probably wouldn't have guessed that if I upgrade HLS to 1.4.0, the labels next to GHC 8.10.7 would update to 'hls-powered' from not having it |
| 2021-09-22 10:25:12 +0200 | <maerwald[m]> | There's also `ghcup compile hls` now |
| 2021-09-22 10:25:19 +0200 | <maerwald[m]> | But it needs a bit fiddling for 9.0.1 |
| 2021-09-22 10:34:53 +0200 | Morrow | (~MorrowM_@147.161.14.83) |
| 2021-09-22 10:36:04 +0200 | haykam2 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-09-22 10:36:14 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) (Read error: Connection reset by peer) |
| 2021-09-22 10:36:16 +0200 | mikoto-chan | (~mikoto-ch@84.199.144.235) |
| 2021-09-22 10:36:18 +0200 | MorrowM | (~MorrowM_@147.161.14.83) |
| 2021-09-22 10:36:24 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) |
| 2021-09-22 10:36:38 +0200 | pfurla_ | (~pfurla@ool-182ed2e2.dyn.optonline.net) |
| 2021-09-22 10:36:45 +0200 | chele_ | (~chele@user/chele) |
| 2021-09-22 10:36:56 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) (Read error: Connection reset by peer) |
| 2021-09-22 10:37:15 +0200 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2021-09-22 10:37:15 +0200 | abraham | (~abraham@143.244.185.86) (Quit: Ping timeout (120 seconds)) |
| 2021-09-22 10:37:37 +0200 | abraham | (~abraham@143.244.185.86) |
| 2021-09-22 10:37:38 +0200 | adamCS | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) (Ping timeout: 265 seconds) |
| 2021-09-22 10:38:02 +0200 | chele | (~chele@user/chele) (Read error: Connection reset by peer) |
| 2021-09-22 10:38:03 +0200 | nitrix | (~nitrix@user/nitrix) (Quit: Genius is one percent inspiration and ninety-nine percent perspiration) |
| 2021-09-22 10:38:05 +0200 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-57-65-92-163-194.dsl.bell.ca) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-09-22 10:38:23 +0200 | pieguy128 | (~pieguy128@bas1-montreal02-65-92-163-194.dsl.bell.ca) |
| 2021-09-22 10:38:39 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 10:38:42 +0200 | nitrix | (~nitrix@ns569831.ip-51-79-81.net) |
| 2021-09-22 10:38:42 +0200 | nitrix | (~nitrix@ns569831.ip-51-79-81.net) (Changing host) |
| 2021-09-22 10:38:42 +0200 | nitrix | (~nitrix@user/nitrix) |
| 2021-09-22 10:39:34 +0200 | Morrow | (~MorrowM_@147.161.14.83) (Ping timeout: 265 seconds) |
| 2021-09-22 10:39:34 +0200 | pfurla | (~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2021-09-22 10:39:35 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) (Ping timeout: 265 seconds) |
| 2021-09-22 10:39:54 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-22 10:40:07 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-09-22 10:40:46 +0200 | adamCS | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) |
| 2021-09-22 10:41:26 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-22 10:42:35 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-09-22 10:45:28 +0200 | ubert | (~Thunderbi@77.119.172.39.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-22 10:45:42 +0200 | sheddow | (~sheddow@2001:4652:3064:0:855:8e28:191f:6ce6) |
| 2021-09-22 10:47:50 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-22 10:48:20 +0200 | MorrowM | (~MorrowM_@147.161.14.83) (Ping timeout: 252 seconds) |
| 2021-09-22 10:50:12 +0200 | mikoto-chan | (~mikoto-ch@84.199.144.235) (Quit: mikoto-chan) |
| 2021-09-22 10:51:05 +0200 | qbt | (~edun@user/edun) (Ping timeout: 252 seconds) |
| 2021-09-22 10:57:09 +0200 | jinsun | (~quassel@user/jinsun) (Ping timeout: 268 seconds) |
| 2021-09-22 10:57:20 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 11:01:42 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 260 seconds) |
| 2021-09-22 11:10:58 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 11:13:26 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) (Remote host closed the connection) |
| 2021-09-22 11:13:55 +0200 | <jchia[m]> | Is there a simple way (e.g. some haddock library) to take a random subset of size k from a list of n items, k <= n? I can almost use `sampleSubset` from https://hackage.haskell.org/package/monte-carlo-0.2/docs/Control-Monad-MC-Class.html but I don't care about order of the result, so I'd still have to sort the result from `sampleSubset`. I believe there's a rather standard algorithm for this but I prefer not to reinvent the wheel. |
| 2021-09-22 11:15:05 +0200 | vemek | (~vemek@2a03:b0c0:2:d0::d98:1) (Quit: WeeChat 2.8) |
| 2021-09-22 11:15:30 +0200 | <merijn> | jchia[m]: Yes, but I forgot the name |
| 2021-09-22 11:15:40 +0200 | <merijn> | jchia[m]: I use it to sample from a stream of millions |
| 2021-09-22 11:16:22 +0200 | <merijn> | jchia[m]: basically, for every element generate a random number with range 0-N (where N is remaining elements) |
| 2021-09-22 11:16:51 +0200 | <merijn> | Then, if the generated number is smaller than K (remaining number of sample elements) keep the element and decrement K |
| 2021-09-22 11:17:24 +0200 | <[exa]> | merijn jchia[m]: it might be a Knuth shuffle, except just for the first K elems |
| 2021-09-22 11:17:41 +0200 | Guest8973 | (~neo3@cpe-292712.ip.primehome.com) |
| 2021-09-22 11:17:46 +0200 | Guest8973 | neo1 |
| 2021-09-22 11:17:53 +0200 | <merijn> | [exa]: What I describe is effectively a variation of Fisher-Yates shuffle, yeah |
| 2021-09-22 11:18:12 +0200 | <jchia[m]> | merijn: Was there an actual haddock library that you used to do this? |
| 2021-09-22 11:18:34 +0200 | <merijn> | jchia[m]: No, because I do it in C inside an SQLite query :p |
| 2021-09-22 11:19:36 +0200 | <[exa]> | jchia[m]: what do you mean by "I'd have to sort the result" ? |
| 2021-09-22 11:20:09 +0200 | <[exa]> | you need the same order of the subset as in the original data? |
| 2021-09-22 11:20:28 +0200 | <jchia[m]> | exa: sampleSubset produces a sequence of random elements, but I don't want a sequence; I want a subset and don't care about the order. |
| 2021-09-22 11:20:34 +0200 | <merijn> | jchia[m]: https://github.com/merijn/Belewitte/blob/master/benchmark-analysis/cbits/random_sample.c#L12-L22 |
| 2021-09-22 11:20:53 +0200 | <merijn> | jchia[m]: That's trivially solved by converting the sequence to a Set? |
| 2021-09-22 11:20:56 +0200 | <jchia[m]> | i want the elements in the subset to be in the same order as the original set/list. |
| 2021-09-22 11:21:02 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-22 11:21:08 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 265 seconds) |
| 2021-09-22 11:21:08 +0200 | <[exa]> | jchia[m]: the order is "random generator order", there's always going to be an order with random numbers |
| 2021-09-22 11:21:19 +0200 | <merijn> | jchia[m]: Right, then you want my suggestion |
| 2021-09-22 11:21:20 +0200 | <[exa]> | ah so |
| 2021-09-22 11:21:39 +0200 | <merijn> | Which lets you uniform randomly drop (or keep, depending on your point of view) elements from an existing sequence |
| 2021-09-22 11:21:41 +0200 | <jchia[m]> | but i reckon i don't have more than a few million items in the original set, so it's no big deal to use sampleIntSubset and sort the resulting indexes |
| 2021-09-22 11:22:04 +0200 | <[exa]> | what's your `k`, roughly? |
| 2021-09-22 11:22:23 +0200 | <[exa]> | if it's like 10, just take 10 random integers and retry if some of them are same. :D |
| 2021-09-22 11:22:45 +0200 | <jchia[m]> | The conversion to set or sorting is just additional work that can be avoided if using a more precise algorithm, but I think I can live with the inefficiency. |
| 2021-09-22 11:22:54 +0200 | <jchia[m]> | around 10 million, probably |
| 2021-09-22 11:22:58 +0200 | <jchia[m]> | so, it's no big deal to do the sorting |
| 2021-09-22 11:23:32 +0200 | wonko | (~wjc@62.115.229.50) (Ping timeout: 252 seconds) |
| 2021-09-22 11:24:24 +0200 | <jchia[m]> | In C++, this type of sorting probably takes just a few seconds. My entire program takes hours typically and this sampling happens once per run. |
| 2021-09-22 11:26:15 +0200 | <merijn> | jchia[m]: I mean, my solution is simple, runs in linear time and (if input is a stream) storage linear in number of kept elements |
| 2021-09-22 11:26:33 +0200 | <merijn> | All you need is a decent uniform int generator |
| 2021-09-22 11:27:09 +0200 | <jchia[m]> | merijn: Doesn't conversion to Set take O(k log k)? |
| 2021-09-22 11:27:12 +0200 | <merijn> | Trivial to implement as a foldr too |
| 2021-09-22 11:27:41 +0200 | <merijn> | jchia[m]: Not that one, that was just an alternative when using sampleSubset |
| 2021-09-22 11:28:01 +0200 | <merijn> | I meant the C code I linked/described |
| 2021-09-22 11:28:03 +0200 | <[exa]> | there's some constructor that can build a Set from pre-ordered stuff right? |
| 2021-09-22 11:28:38 +0200 | <merijn> | [exa]: There are functions that create set assuming ordering, yes |
| 2021-09-22 11:28:42 +0200 | <[exa]> | yap https://hackage.haskell.org/package/containers-0.6.5.1/docs/Data-Set.html#v:fromAscList |
| 2021-09-22 11:28:52 +0200 | jinsun | (~quassel@user/jinsun) |
| 2021-09-22 11:29:17 +0200 | <jchia[m]> | merijn: OK, I think you mean the algorithm itself. The efficiency is not super-important. I'll start with the simple solution using sampleIntSubset first and if that's not fast enough, implement the algorithm in Haskell. |
| 2021-09-22 11:33:26 +0200 | mixfix41 | (~homefame@user/mixfix41) (Ping timeout: 260 seconds) |
| 2021-09-22 11:34:56 +0200 | juhp | (~juhp@bb42-60-204-249.singnet.com.sg) |
| 2021-09-22 11:37:59 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-09-22 11:41:39 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2021-09-22 11:42:47 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-09-22 11:48:20 +0200 | chomwitt | (~chomwitt@ppp-94-67-1-143.home.otenet.gr) (Ping timeout: 246 seconds) |
| 2021-09-22 11:55:25 +0200 | alzgh | (~alzgh@user/alzgh) |
| 2021-09-22 11:55:26 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 11:58:21 +0200 | hgolden | (~hgolden2@cpe-172-114-84-61.socal.res.rr.com) (Ping timeout: 265 seconds) |
| 2021-09-22 11:59:09 +0200 | kenran | (~kenran@b2b-37-24-119-190.unitymedia.biz) (Quit: WeeChat info:version) |
| 2021-09-22 12:05:46 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 12:07:56 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 12:08:42 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 12:09:53 +0200 | qbt | (~edun@user/edun) |
| 2021-09-22 12:10:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:13:53 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-22 12:15:14 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 12:15:30 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:16:58 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-09-22 12:20:32 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 12:21:09 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:26:08 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 12:26:44 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:29:12 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 12:32:11 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-09-22 12:32:33 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:32:38 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 12:34:53 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 12:37:25 +0200 | Guest3894 | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-09-22 12:40:58 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 12:42:20 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-09-22 12:43:34 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:48:47 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 12:49:10 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:51:13 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-09-22 12:51:44 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 12:54:50 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 12:55:16 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 12:56:21 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 265 seconds) |
| 2021-09-22 12:58:11 +0200 | Morrow | (~MorrowM_@147.161.14.83) |
| 2021-09-22 12:59:15 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 12:59:25 +0200 | oxide | (~lambda@user/oxide) |
| 2021-09-22 13:00:20 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 13:00:58 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 13:03:20 +0200 | nitrix | (~nitrix@user/nitrix) (Remote host closed the connection) |
| 2021-09-22 13:03:41 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 264 seconds) |
| 2021-09-22 13:04:11 +0200 | jespada | (~jespada@2803:9800:9842:7a62:4d47:2975:7b31:a447) |
| 2021-09-22 13:05:16 +0200 | nitrix | (~nitrix@ns569831.ip-51-79-81.net) |
| 2021-09-22 13:05:32 +0200 | nitrix | (~nitrix@ns569831.ip-51-79-81.net) (Changing host) |
| 2021-09-22 13:05:32 +0200 | nitrix | (~nitrix@user/nitrix) |
| 2021-09-22 13:06:28 +0200 | michalz | (~michalz@185.246.204.61) (Remote host closed the connection) |
| 2021-09-22 13:07:05 +0200 | michalz | (~michalz@185.246.204.33) |
| 2021-09-22 13:08:34 +0200 | Cajun | (~Cajun@user/cajun) |
| 2021-09-22 13:09:07 +0200 | max22- | (~maxime@2a01cb088335980068341cc0d04f7803.ipv6.abo.wanadoo.fr) (Ping timeout: 268 seconds) |
| 2021-09-22 13:09:41 +0200 | ubert | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) |
| 2021-09-22 13:12:48 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 13:13:16 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) |
| 2021-09-22 13:14:14 +0200 | pooryorick | (~pooryoric@87-119-174-173.tll.elisa.ee) (Ping timeout: 265 seconds) |
| 2021-09-22 13:16:12 +0200 | azeem | (~azeem@2a00:801:3c7:f4f5:1ae6:c0ab:f962:792a) (Read error: Connection reset by peer) |
| 2021-09-22 13:16:37 +0200 | chomwitt | (~chomwitt@ppp-94-67-1-143.home.otenet.gr) |
| 2021-09-22 13:17:12 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 13:20:36 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-09-22 13:20:40 +0200 | betelgeuse | (~betelgeus@94-225-47-8.access.telenet.be) (Ping timeout: 260 seconds) |
| 2021-09-22 13:21:14 +0200 | betelgeuse | (~betelgeus@94-225-47-8.access.telenet.be) |
| 2021-09-22 13:24:35 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) |
| 2021-09-22 13:26:31 +0200 | Guest68 | (~Guest68@212.8.115.226) |
| 2021-09-22 13:29:00 +0200 | Guest68 | (~Guest68@212.8.115.226) (Client Quit) |
| 2021-09-22 13:32:29 +0200 | Guest07 | (~Guest07@eth-west-pareq2-46-193-4-100.wb.wifirst.net) |
| 2021-09-22 13:33:41 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2021-09-22 13:34:59 +0200 | <Guest07> | Hello, I just installed stack and started a new project. But it locked base at >= 4.7 and < 5 |
| 2021-09-22 13:35:04 +0200 | <Guest07> | Is this normal? |
| 2021-09-22 13:35:40 +0200 | <dminuoso> | Guest07: stack resolves packages using its resolvers, so everything is tied to whats in them anyway |
| 2021-09-22 13:35:48 +0200 | <dminuoso> | by default, anyhow |
| 2021-09-22 13:36:30 +0200 | <merijn> | Guest07: It's locked at *one* specific version of base |
| 2021-09-22 13:36:50 +0200 | <merijn> | Guest07: Base is hard-wired into GHC and any resolver only includes one GHC version anyway |
| 2021-09-22 13:37:10 +0200 | <merijn> | tbh, if it's generating ">= 4.7 && < 5" constraints on base that's bogus anyway |
| 2021-09-22 13:38:06 +0200 | <Guest07> | yes the base constraints are in my package.yaml. But stack.yaml references an lts resolver |
| 2021-09-22 13:38:29 +0200 | <Guest07> | specifically: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/18/10.yaml |
| 2021-09-22 13:39:14 +0200 | <Guest07> | merijn: so the contraints are redundant? Or are they there for when I upgrade the resolver? |
| 2021-09-22 13:39:50 +0200 | <merijn> | Guest07: Well, if you want anyone who doesn't use stack to have any hope of compiling/using your code, they're not redundant |
| 2021-09-22 13:40:42 +0200 | <merijn> | Guest07: My objection is that, unless you've tested code with other versions/ranges, your range should be "the PVP compatible range of what you're using *now*", so if stack is inserting wider ranges (like "4.7 >= && <5") that's just bogus |
| 2021-09-22 13:43:05 +0200 | <Guest07> | maybe there is something game breaking about base = 5, this is the latest lts afterall |
| 2021-09-22 13:44:15 +0200 | <merijn> | base 5 doesn't exist |
| 2021-09-22 13:44:36 +0200 | <merijn> | It's claiming the code works with "all future versions of base until version 5" |
| 2021-09-22 13:44:49 +0200 | <Guest07> | that can't be very sensible |
| 2021-09-22 13:44:49 +0200 | <merijn> | Which is obviously nonsense, since you dunno what will change in future versions of base |
| 2021-09-22 13:45:01 +0200 | <merijn> | It isn't |
| 2021-09-22 13:45:32 +0200 | <merijn> | Guest07: Incidentally, related to discussion of bounds: https://pvp.haskell.org/ |
| 2021-09-22 13:45:33 +0200 | <Guest07> | merijn: thanks for the explanations |
| 2021-09-22 13:46:37 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Ping timeout: 265 seconds) |
| 2021-09-22 13:48:05 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 13:50:23 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 13:50:27 +0200 | Guest07 | (~Guest07@eth-west-pareq2-46-193-4-100.wb.wifirst.net) (Ping timeout: 256 seconds) |
| 2021-09-22 13:50:31 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) |
| 2021-09-22 13:53:37 +0200 | <merijn> | Also, you should commit the generated cabal file from your package into the repository (and, personal opinion incoming: probably ditch package.yaml entirely and just use the cabal file directly) |
| 2021-09-22 13:55:35 +0200 | <maerwald> | burn package.yaml |
| 2021-09-22 13:55:45 +0200 | <maerwald> | the pain it has caused us |
| 2021-09-22 14:01:35 +0200 | michalz | (~michalz@185.246.204.33) (Remote host closed the connection) |
| 2021-09-22 14:02:19 +0200 | michalz | (~michalz@185.246.204.62) |
| 2021-09-22 14:03:47 +0200 | michalz | (~michalz@185.246.204.62) (Remote host closed the connection) |
| 2021-09-22 14:04:27 +0200 | michalz | (~michalz@185.246.204.61) |
| 2021-09-22 14:08:09 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 14:09:55 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-09-22 14:14:32 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-09-22 14:20:35 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-22 14:20:59 +0200 | pooryorick | (~pooryoric@87-119-174-173.tll.elisa.ee) |
| 2021-09-22 14:21:06 +0200 | [exa] | hands over a box of matches |
| 2021-09-22 14:22:18 +0200 | xiongxin | (~quassel@119.123.102.205) |
| 2021-09-22 14:22:54 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-22 14:23:34 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 14:23:45 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-09-22 14:28:17 +0200 | dextaa | (~DV@user/dextaa) (Ping timeout: 264 seconds) |
| 2021-09-22 14:29:19 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-09-22 14:32:09 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-09-22 14:32:33 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-22 14:33:26 +0200 | tj_allemaal | (~tj_allema@17-14-122.cgnat.fonira.net) |
| 2021-09-22 14:34:55 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-09-22 14:35:16 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-09-22 14:35:21 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-09-22 14:36:54 +0200 | <Morrow> | I think I've heard that stack includes the bogus bounds on base because Hackage requires it. |
| 2021-09-22 14:37:10 +0200 | <maerwald> | Morrow: I use base <100000 |
| 2021-09-22 14:37:12 +0200 | <maerwald> | xD |
| 2021-09-22 14:37:25 +0200 | <Morrow> | lol |
| 2021-09-22 14:37:27 +0200 | <merijn> | Morrow: But why bogus bounds instead of just *actual* bounds |
| 2021-09-22 14:37:57 +0200 | <Morrow> | Because this is stack-land, where version bounds don't exist! |
| 2021-09-22 14:37:59 +0200 | <merijn> | i.e. "base ^>= 4.x" where x = base of the GHC in the resolver |
| 2021-09-22 14:38:12 +0200 | <merijn> | That's accepted by hackage and actually reasonable |
| 2021-09-22 14:38:17 +0200 | <maerwald> | merijn: meh, most packages work with more than one x |
| 2021-09-22 14:38:37 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 14:38:39 +0200 | <merijn> | maerwald: Sure, but if people don't *test* that they shouldn't *specify* it |
| 2021-09-22 14:38:57 +0200 | <maerwald> | PVP failed |
| 2021-09-22 14:39:22 +0200 | <merijn> | And that's a solid argument for "failing even more stuff"? |
| 2021-09-22 14:39:48 +0200 | <int-e> | applying PVP to base is not worth the hassle |
| 2021-09-22 14:40:50 +0200 | <merijn> | int-e: And yet shit breaks every GHC release |
| 2021-09-22 14:41:01 +0200 | <merijn> | There are at most 2 GHC releases a year |
| 2021-09-22 14:41:07 +0200 | <int-e> | A lot of stuff just keeps working. |
| 2021-09-22 14:41:16 +0200 | <merijn> | Which means worst case scenario, relax your base constraint twice a year |
| 2021-09-22 14:41:29 +0200 | <merijn> | (you need to update your CI for the new GHC anyway...) |
| 2021-09-22 14:41:33 +0200 | <merijn> | "oh god, the horror" |
| 2021-09-22 14:41:51 +0200 | <merijn> | int-e: If it keeps working you just edit one number twice a year :O |
| 2021-09-22 14:42:11 +0200 | <merijn> | ez pz |
| 2021-09-22 14:42:55 +0200 | <maerwald> | merijn: lol |
| 2021-09-22 14:43:03 +0200 | <maerwald> | right... file an NMU that takes half a year to process |
| 2021-09-22 14:43:23 +0200 | <merijn> | maerwald: That says something about "unmaintained packages" not "how constraints are too hard" |
| 2021-09-22 14:43:37 +0200 | <maerwald> | idc what it says, it's annoying |
| 2021-09-22 14:44:11 +0200 | <int-e> | merijn: So I'd have 3 times the number of releases for this silly little thing: https://hackage.haskell.org/package/ivar-simple |
| 2021-09-22 14:44:25 +0200 | <int-e> | (package size and stability is clearly a factor) |
| 2021-09-22 14:44:38 +0200 | <merijn> | int-e: You don't even have to make a new release |
| 2021-09-22 14:44:45 +0200 | <merijn> | You can revise the bound |
| 2021-09-22 14:45:02 +0200 | <int-e> | I can also do that when things break |
| 2021-09-22 14:45:04 +0200 | int-e | shrugs |
| 2021-09-22 14:46:38 +0200 | <maerwald> | int-e: exactly |
| 2021-09-22 14:46:49 +0200 | <int-e> | Personally I hate people having strict upper bounds on base because it makes it harder to try out a new version of ghc |
| 2021-09-22 14:46:57 +0200 | <int-e> | --allow-newer=base is too crude |
| 2021-09-22 14:47:29 +0200 | <merijn> | int-e: That's what ^>= is for? Then you can just relax all those bounds at once |
| 2021-09-22 14:47:40 +0200 | fendor_ | (~fendor@91.141.44.67.wireless.dyn.drei.com) |
| 2021-09-22 14:47:48 +0200 | <maerwald> | merijn: ^>= isn't enough |
| 2021-09-22 14:47:51 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Quit: WeeChat 3.2.1) |
| 2021-09-22 14:48:44 +0200 | <maerwald> | it's bad syntax... I want to express a) 4.7-4.9 is tested, below 4.7 is broken shite, above 4.9 may work |
| 2021-09-22 14:49:56 +0200 | <merijn> | ^>= {4.7, 4.8, 4.9} |
| 2021-09-22 14:50:01 +0200 | <maerwald> | yeah, ugh |
| 2021-09-22 14:50:05 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-09-22 14:50:20 +0200 | fendor | (~fendor@77.119.193.149.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-22 14:50:29 +0200 | <maerwald> | get someone to use this |
| 2021-09-22 14:50:37 +0200 | pbrisbin | (~patrick@pool-173-49-147-250.phlapa.fios.verizon.net) |
| 2021-09-22 14:50:45 +0200 | <merijn> | maerwald: Do you have better syntax? |
| 2021-09-22 14:50:57 +0200 | <maerwald> | probably if I thought hard enough |
| 2021-09-22 14:51:10 +0200 | <maerwald> | the point is... this is bolted on stuff that most ppl don't even know |
| 2021-09-22 14:51:15 +0200 | <maerwald> | and came too late |
| 2021-09-22 14:51:47 +0200 | <merijn> | So instead of "better late than never and educating people" you're solution is "fuck it, let's throw in the towel and give up" |
| 2021-09-22 14:51:49 +0200 | <maerwald> | damage is done, we're going to add stackage resolvers to cabal and then move on |
| 2021-09-22 14:52:05 +0200 | <maerwald> | (well, more complex contraints, but ...) |
| 2021-09-22 14:52:24 +0200 | <maerwald> | so no one is gonna rely heavily on PVP anymore anyway |
| 2021-09-22 14:52:57 +0200 | <maerwald> | and have you ever seen a haskell maintainner backport bugfixes to a previous major version? |
| 2021-09-22 14:53:23 +0200 | <maerwald> | so to get the bugfix you gotta upgrade to new API anyway |
| 2021-09-22 14:53:33 +0200 | <maerwald> | what's the point of PVP here |
| 2021-09-22 14:56:52 +0200 | <int-e> | ^>= {4.7, 4.8, 4.9} still doesn't allow people to *try* 4.10 without relaxing bounds. |
| 2021-09-22 14:57:25 +0200 | <merijn> | int-e: Except you can relax ^>= without relaxing regular bounds |
| 2021-09-22 14:57:52 +0200 | dextaa | (~DV@user/dextaa) |
| 2021-09-22 14:57:53 +0200 | <merijn> | int-e: The distinction is ^>= "not known to work with newer" whereas "<" says "known to not work with newer" |
| 2021-09-22 14:58:27 +0200 | <merijn> | int-e: The main problem with allow-newer was the inability to relax unknown bounds without immediately *also* breaking bounds known to not work |
| 2021-09-22 14:59:24 +0200 | <int-e> | So, the documentation is lying about ^>= being equivalent to >= ... <? |
| 2021-09-22 14:59:47 +0200 | <merijn> | int-e: It's equivalent in what it *does*, it's not equivalent in *meaning* |
| 2021-09-22 14:59:57 +0200 | <merijn> | int-e: i.e. it's equivalent in terms of what the solver will do |
| 2021-09-22 15:00:12 +0200 | <merijn> | It's not equivalent in terms of "supported operations on the commandline" |
| 2021-09-22 15:00:51 +0200 | <merijn> | int-e: You will get the same buildplans with ">= ... <" and "^>=", but you can choose to *only* relax ^>= bounds without touching < bounds on the cabal-install commandline |
| 2021-09-22 15:01:08 +0200 | dextaa | (~DV@user/dextaa) (Read error: Connection reset by peer) |
| 2021-09-22 15:01:18 +0200 | <merijn> | Else there'd be no point to having ^>= |
| 2021-09-22 15:01:20 +0200 | dextaa | (~DV@user/dextaa) |
| 2021-09-22 15:01:33 +0200 | <maerwald> | no, how many people know this? :) |
| 2021-09-22 15:01:36 +0200 | <maerwald> | s/no/now/ |
| 2021-09-22 15:01:55 +0200 | <maerwald> | version policies only work if people understand them |
| 2021-09-22 15:02:05 +0200 | <int-e> | Also, the documentation of that feature sucks. I looked around for a long time and finally found it described for cabal.project files. |
| 2021-09-22 15:02:12 +0200 | <maerwald> | yeah |
| 2021-09-22 15:02:16 +0200 | <int-e> | I didn't know. |
| 2021-09-22 15:02:45 +0200 | <maerwald> | bad syntax, bad documentation and too late... I think this feature isn't going to save us |
| 2021-09-22 15:02:54 +0200 | <merijn> | int-e: Maybe, but it was implemented during the time that all development and maintenance was basically just hvr and Oleg |
| 2021-09-22 15:03:47 +0200 | <merijn> | int-e: Lots of experienced Haskellers like to complain about the inadequacy of tool documentation, but not many step up and help... |
| 2021-09-22 15:04:13 +0200 | <maerwald> | I already have enough stuff to document :> |
| 2021-09-22 15:04:28 +0200 | <merijn> | So does everyone |
| 2021-09-22 15:04:37 +0200 | zardoz | (~bc8165b6@217.29.117.252) |
| 2021-09-22 15:04:54 +0200 | <maerwald> | if you want me to redo cabal docs, I'm afraid that will be a paid job |
| 2021-09-22 15:05:06 +0200 | <merijn> | I just get tired of people "just pointing out problems". Everyone already knows they're problems |
| 2021-09-22 15:05:20 +0200 | <merijn> | Either you help address them, or stop complaining |
| 2021-09-22 15:05:44 +0200 | <int-e> | I know. I also know that documenting stuff is hard, because documentation often needs to be redundant to be useful, but it's hard to think of all the perspectives, and it's also hard to overcome the instinct of not repeating oneself. |
| 2021-09-22 15:05:49 +0200 | <zardoz> | hi. what are your thoughts of using Show/Read instance for config files? I have something like this: data Action = MoveWindow Int Int | ResizeWindow Int Int | MinimizeWindow | MaximizeWindow deriving (Show, Read) |
| 2021-09-22 15:05:55 +0200 | <maerwald> | I don't think anyone is complaining. I'm merely stating my opinion that a) upper bounds are horrid and b) Caret operator isn't gonna solve it |
| 2021-09-22 15:05:58 +0200 | <merijn> | zardoz: Terrible |
| 2021-09-22 15:06:00 +0200 | <dminuoso> | zardoz: No. |
| 2021-09-22 15:06:04 +0200 | <zardoz> | why? |
| 2021-09-22 15:06:10 +0200 | <dminuoso> | So many reasons. |
| 2021-09-22 15:06:15 +0200 | <merijn> | zardoz: I only read the first sentence and I already know whatever else comes next is terrible |
| 2021-09-22 15:06:17 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2021-09-22 15:06:19 +0200 | <maerwald> | zardoz: use ini |
| 2021-09-22 15:06:21 +0200 | <zardoz> | I'm listening :P |
| 2021-09-22 15:06:27 +0200 | <dminuoso> | There's essentially non-existent useful errors for Read |
| 2021-09-22 15:06:30 +0200 | <maerwald> | https://hackage.haskell.org/package/ini |
| 2021-09-22 15:06:31 +0200 | <int-e> | merijn: It's not so much a complaint as an explanation why this feature is probably hardly known at all. |
| 2021-09-22 15:06:34 +0200 | <dminuoso> | The format is horrid and hard to explain for non-haskellers |
| 2021-09-22 15:06:36 +0200 | <zardoz> | maerwald, I am actually using ini. this is "action" property of an ini file |
| 2021-09-22 15:06:41 +0200 | <dminuoso> | Show also risks leaking secrets in the wrong places |
| 2021-09-22 15:06:42 +0200 | <merijn> | Read has no errors, Read is slow, Read is implementation specific |
| 2021-09-22 15:06:51 +0200 | <maerwald> | ini is great |
| 2021-09-22 15:06:53 +0200 | <merijn> | Show is implementation specific too |
| 2021-09-22 15:07:22 +0200 | <merijn> | zardoz: Many people think "I know, I'll just tie my external format directly to my internal datatypes. It'll be easy" |
| 2021-09-22 15:07:31 +0200 | <dminuoso> | zardoz: Personally Im quite fond of config-schema |
| 2021-09-22 15:07:33 +0200 | <int-e> | > read ('"' : repeat ' ') :: Int |
| 2021-09-22 15:07:36 +0200 | <merijn> | These same people are in for lots of lots of pain in the medium to long future |
| 2021-09-22 15:07:39 +0200 | <lambdabot> | mueval-core: Time limit exceeded |
| 2021-09-22 15:08:09 +0200 | <dminuoso> | It has a nice config format with an automatically derivable parser, good error diagnostics, and built-in documentation generation of expected format. |
| 2021-09-22 15:08:17 +0200 | <dminuoso> | With a mild dependency overhead. |
| 2021-09-22 15:08:40 +0200 | <dminuoso> | ini is also fine, but potentially too limiting depending on your needs |
| 2021-09-22 15:08:41 +0200 | <zardoz> | parsing this myself isn't too hard, but seems like a a double effort. and I like the syntax Show/Read gives me. though I didn't know Read is implementation specific (not that it matters at this point, but still) |
| 2021-09-22 15:08:42 +0200 | tj_allemaal | (~tj_allema@17-14-122.cgnat.fonira.net) () |
| 2021-09-22 15:08:45 +0200 | <merijn> | zardoz: The number of times I've added an explicit conversion/parsing step between "external data format" and "internal data types" and regretted it, is zero. The number of times I *didn't* do that and regretted it is: literally every time |
| 2021-09-22 15:09:05 +0200 | <dminuoso> | zardoz: you have *no* useful error other than "Nope!" if there's any syntax error. |
| 2021-09-22 15:09:18 +0200 | <dminuoso> | take the extra time and set up proper parsing |
| 2021-09-22 15:09:23 +0200 | <zardoz> | dminuoso, error is easy to add. wrong action in section X at property Y |
| 2021-09-22 15:09:28 +0200 | <dminuoso> | nope, its not |
| 2021-09-22 15:09:30 +0200 | <zardoz> | wrong action syntax* |
| 2021-09-22 15:09:39 +0200 | <dminuoso> | `readMaybe` gives you Nothing. |
| 2021-09-22 15:09:40 +0200 | <zardoz> | well I did it :P |
| 2021-09-22 15:09:40 +0200 | <dminuoso> | That's it. |
| 2021-09-22 15:09:47 +0200 | <zardoz> | right. that's enough for error above |
| 2021-09-22 15:10:06 +0200 | <dminuoso> | "invalid config" is quite useless if you dont even know what's wrong. |
| 2021-09-22 15:10:19 +0200 | <dminuoso> | you dont have "wrong action in section X at property Y" with read. |
| 2021-09-22 15:10:25 +0200 | <dminuoso> | It's simply " |
| 2021-09-22 15:10:27 +0200 | <dminuoso> | "nope" |
| 2021-09-22 15:10:36 +0200 | <zardoz> | I am parsing ini file manually. read is just used to parse a single line of a single property in an ini file |
| 2021-09-22 15:11:01 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-22 15:11:31 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) |
| 2021-09-22 15:12:04 +0200 | <zardoz> | (well, one line per property, and there's one action property in every ini section) |
| 2021-09-22 15:13:16 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-09-22 15:13:53 +0200 | <zardoz> | example of test ini file: https://pastebin.com/gegbbiP7 |
| 2021-09-22 15:13:59 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Ping timeout: 252 seconds) |
| 2021-09-22 15:14:38 +0200 | cheater | (~Username@user/cheater) |
| 2021-09-22 15:14:40 +0200 | <zardoz> | so I have to parse the ini file, get all the sections, get target/action properties, and then I send those lines to readMaybe. so I know exactly what failed |
| 2021-09-22 15:14:48 +0200 | <zardoz> | so error messages are not an issue. other things might be though |
| 2021-09-22 15:17:50 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 15:18:17 +0200 | MQ-17J | (~MQ-17J@2607:fb90:885d:dc4:b0b2:2c03:76da:1640) |
| 2021-09-22 15:20:24 +0200 | qbt | (~edun@user/edun) (Ping timeout: 265 seconds) |
| 2021-09-22 15:20:42 +0200 | dextaa | (~DV@user/dextaa) (Ping timeout: 260 seconds) |
| 2021-09-22 15:20:53 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-22 15:21:06 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 15:21:06 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 15:21:06 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 15:21:50 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) (Quit: leaving) |
| 2021-09-22 15:22:02 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-09-22 15:22:15 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-09-22 15:22:40 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-22 15:22:53 +0200 | acidjnk | (~acidjnk@p200300d0c703cb65087a628f3300f5c4.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2021-09-22 15:24:37 +0200 | thyriaen | (~thyriaen@dynamic-078-054-003-131.78.54.pool.telefonica.de) |
| 2021-09-22 15:25:38 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Quit: WeeChat 3.3) |
| 2021-09-22 15:25:53 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-09-22 15:34:04 +0200 | max22- | (~maxime@2a01cb08833598009945523f8c6be6aa.ipv6.abo.wanadoo.fr) |
| 2021-09-22 15:35:47 +0200 | dextaa | (~DV@user/dextaa) |
| 2021-09-22 15:36:40 +0200 | hrnz | (~ulli@vegan.im.it) (Ping timeout: 240 seconds) |
| 2021-09-22 15:37:10 +0200 | noddy | (~user@user/noddy) (Ping timeout: 240 seconds) |
| 2021-09-22 15:37:34 +0200 | dyniec | (~dyniec@mail.dybiec.info) (Ping timeout: 252 seconds) |
| 2021-09-22 15:38:05 +0200 | dyniec | (~dyniec@mail.dybiec.info) |
| 2021-09-22 15:38:08 +0200 | noddy | (~user@user/noddy) |
| 2021-09-22 15:38:41 +0200 | sheddow | (~sheddow@2001:4652:3064:0:855:8e28:191f:6ce6) (Ping timeout: 256 seconds) |
| 2021-09-22 15:38:55 +0200 | robbert-vdh | (~robbert@robbertvanderhelm.nl) |
| 2021-09-22 15:42:01 +0200 | hrnz | (~ulli@vegan.im.it) |
| 2021-09-22 15:42:48 +0200 | <ldlework> | "An astute reader might have noticed that the mapping from integers to adders follows from the second interpretation of the type signature of mappend as m->(m->m). It tells us that mappend maps an element of a monoid set to a function acting on that set." |
| 2021-09-22 15:42:50 +0200 | <ldlework> | huh |
| 2021-09-22 15:44:06 +0200 | <robbert-vdh> | Anyone know of some kind of trick to get some sort of default value with the ImplicitParameters extension? Basically, I have a function that evaluates a form with an implicit parameter set, and I'd like it to not do that when the parameter is already set. (kind of like how withFrozenCallStack doesn't do anything when the call stack is already frozen) |
| 2021-09-22 15:44:34 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-09-22 15:44:34 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 15:44:37 +0200 | allbery_b | geekosaur |
| 2021-09-22 15:45:19 +0200 | <lortabac> | robbert-vdh: maybe you can use a Maybe? |
| 2021-09-22 15:45:19 +0200 | <robbert-vdh> | I was hoping that using an overlapping type class with the parameter as a constraint would do the trick, but the type checker obviously doesn't like that :) |
| 2021-09-22 15:46:27 +0200 | <robbert-vdh> | lortabac: Is there some implementation detail that lets `(?foo :: Maybe Bar)` default to Nothing? (I'd also not want this all the time, I just need this fallback behaviour in a single function) |
| 2021-09-22 15:49:31 +0200 | Brumaire | (~quassel@37.164.75.100) |
| 2021-09-22 15:49:48 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-09-22 15:49:59 +0200 | viluon | (uid453725@id-453725.helmsley.irccloud.com) |
| 2021-09-22 15:50:39 +0200 | <robbert-vdh> | Basically, as an XY problem, if something along the lines of this would work (so, kinda like C++'s SFINAE) then that would be great https://hastebin.com/wobuvukubi.hs |
| 2021-09-22 15:50:50 +0200 | Morrow | (~MorrowM_@147.161.14.83) (Ping timeout: 252 seconds) |
| 2021-09-22 15:51:23 +0200 | phma | (~phma@host-67-44-209-62.hnremote.net) (Read error: Connection reset by peer) |
| 2021-09-22 15:52:26 +0200 | <lortabac> | robbert-vdh: I would use a Reader and start the whole thing with runReader ... Nothing |
| 2021-09-22 15:52:40 +0200 | <lortabac> | then you can override the value with local |
| 2021-09-22 15:54:31 +0200 | phma | (~phma@host-67-44-209-25.hnremote.net) |
| 2021-09-22 15:54:38 +0200 | <lortabac> | what you want to achieve is probably doable but I wouldn't rely on such tricks |
| 2021-09-22 15:55:44 +0200 | MQ-17J | (~MQ-17J@2607:fb90:885d:dc4:b0b2:2c03:76da:1640) (Read error: Connection reset by peer) |
| 2021-09-22 15:56:01 +0200 | <dminuoso> | ldlework: So this is the observation that functions take only a single argument. |
| 2021-09-22 15:56:09 +0200 | <dminuoso> | lortabac: mappend takes a single argument and returns a function. |
| 2021-09-22 15:56:13 +0200 | MQ-17J | (~MQ-17J@35.50.35.3) |
| 2021-09-22 15:56:14 +0200 | <dminuoso> | Woah. This is confusing. |
| 2021-09-22 15:56:17 +0200 | <dminuoso> | % :t mappend |
| 2021-09-22 15:56:17 +0200 | <yahb> | dminuoso: Monoid a => a -> a -> a |
| 2021-09-22 15:56:29 +0200 | <dminuoso> | lortabac: ^- This parses as `Monoid a => a -> (a -> a)` |
| 2021-09-22 15:56:48 +0200 | <dminuoso> | And again. sorry. ldlework - somehow I expected weechat to do tabcompletion a particular way. |
| 2021-09-22 15:56:49 +0200 | shriekingnoise | (~shrieking@186.137.144.80) |
| 2021-09-22 15:57:28 +0200 | <ldlework> | dminuoso: Sure, but I already knew that. It's the realization in that doing so there is a CT arrow in play. |
| 2021-09-22 15:57:38 +0200 | <dminuoso> | A CT arrow? |
| 2021-09-22 15:58:05 +0200 | Brumaire | (~quassel@37.164.75.100) (Ping timeout: 265 seconds) |
| 2021-09-22 15:58:14 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-22 15:58:19 +0200 | <ldlework> | category theory arrow |
| 2021-09-22 15:58:44 +0200 | <[exa]> | I'm not sure if this arrow is that much abstract |
| 2021-09-22 15:58:49 +0200 | <ldlework> | I'm reading Milewski |
| 2021-09-22 15:59:43 +0200 | <dminuoso> | Good to see that beginners are still misdirected into the category theory trap. |
| 2021-09-22 15:59:45 +0200 | <robbert-vdh> | lortabac: It would need to be an implicit parameter, so that's not really an option. (without refactoring ~30k LoC to operate within a monad) We're currently hijacking HasCallStack and that works, but it would be much nicer to have a separate implicit parameter. |
| 2021-09-22 16:00:08 +0200 | <dminuoso> | Haskell has been losing its reputation as "being hard and requiring category theory" lately |
| 2021-09-22 16:00:35 +0200 | <ldlework> | dminuoso: HFFP very much gave me that exact impression. It is simply the fact that at this point I am merely curious now. |
| 2021-09-22 16:00:55 +0200 | <lortabac> | honestly I don't get why so many beginners want to learn Haskell and category theory at the same time |
| 2021-09-22 16:01:02 +0200 | <lortabac> | it makes their lives much harder |
| 2021-09-22 16:01:20 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 16:01:30 +0200 | <dminuoso> | With what I know of category theory now, I wouldn't reapproach it unless I happened to pick up some random fields of mathematics, just so category theory would make more sense.. |
| 2021-09-22 16:01:33 +0200 | <[exa]> | ldlework: [*imperator voice:*] good, gooood. |
| 2021-09-22 16:01:37 +0200 | <ldlework> | I have been coding for a long time. It took about 6 days to consume Haskell as a normal ML and start writing graphical and network applications of it |
| 2021-09-22 16:02:01 +0200 | <dminuoso> | Merely learning CT for Haskell is as useful as learning group theory for adding numbers.. |
| 2021-09-22 16:02:13 +0200 | <ldlework> | I have simply been hooked by learning about the abstract side of things. I come from a philosophy background so I'm interested in this more general structure. |
| 2021-09-22 16:02:18 +0200 | <dminuoso> | At least that's how I feel about it |
| 2021-09-22 16:03:20 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 16:03:24 +0200 | <ldlework> | An aquaintance of mine tried to get me into Haskell for years, and simply could not help himself from presenting it in the verbiage of category theory which consistently put me off. I refused to believe I needed to know all this crap just to write programs. |
| 2021-09-22 16:04:08 +0200 | <ldlework> | But now that I've got the uptake of Haskell as just a programming language, I guess I'm finally at a place where I'm curious to find out about this other stuff for its own right. |
| 2021-09-22 16:04:10 +0200 | <ldlework> | Something like that |
| 2021-09-22 16:05:01 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-09-22 16:05:20 +0200 | <[exa]> | CT is sometimes great for discovering structures&relations that are not obvious at all, and haskell programming kinda encourages that |
| 2021-09-22 16:05:41 +0200 | <lortabac> | robbert-vdh: I think the sane way of doing it is to set the implicit parameter to Nothing before the whole computation starts |
| 2021-09-22 16:05:58 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Ping timeout: 260 seconds) |
| 2021-09-22 16:06:17 +0200 | <lortabac> | robbert-vdh: you probably need to add the constraint to a couple of signatures, but that's better than refactoring 30k lines |
| 2021-09-22 16:06:47 +0200 | <[exa]> | ldlework: as with the monoids, it might be useful to see they're isomorphic to functions tat paste tiny amount of stuff to the other stuff, sometimes later enjoying this fact by pasting the functions together with <> or mconcat without much extra thinking |
| 2021-09-22 16:07:30 +0200 | <[exa]> | but like, don't overdo it |
| 2021-09-22 16:07:37 +0200 | <ldlework> | [exa]: I do suspect that my struggle will being able to keep these generalizations in mind while actually writing code |
| 2021-09-22 16:07:50 +0200 | <robbert-vdh> | lortabac: That's sadly also not possible here. Or at least, not without refactoring thousands of functions. This is a library, so you'd need to set that default value at the start of every exposed library function, but the libraries functions tend to also call other library functions. So then you'd either need to do that refactor, or be left with the same problem. |
| 2021-09-22 16:07:51 +0200 | <ldlework> | And that I'll forget them and just code how I usually do |
| 2021-09-22 16:08:02 +0200 | <[exa]> | ldlework: yeah well, think about people who will read the code after you |
| 2021-09-22 16:08:23 +0200 | <[exa]> | anyway most of it becomes pretty intuitive after you actually use the concepts for a few times |
| 2021-09-22 16:08:47 +0200 | <robbert-vdh> | (so the actual end goal is to save call stack information in an implicit parameter so it can be accessed deep inside of some function calling chain) |
| 2021-09-22 16:09:15 +0200 | <lortabac> | robbert-vdh: https://blog.csongor.co.uk/global-implicit-parameters/ |
| 2021-09-22 16:09:30 +0200 | <lortabac> | you can try this ↑ |
| 2021-09-22 16:11:50 +0200 | <lortabac> | however I don't know what the rules are when overriding implicit parameters, and whether those rules are reliable |
| 2021-09-22 16:11:55 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-09-22 16:12:08 +0200 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) |
| 2021-09-22 16:12:23 +0200 | <lortabac> | as I said, Reader is a better option for this kind of stuff |
| 2021-09-22 16:12:39 +0200 | haritz | (~hrtz@62.3.70.206) |
| 2021-09-22 16:12:40 +0200 | haritz | (~hrtz@62.3.70.206) (Changing host) |
| 2021-09-22 16:12:40 +0200 | haritz | (~hrtz@user/haritz) |
| 2021-09-22 16:12:45 +0200 | Everything | (~Everythin@37.115.210.35) |
| 2021-09-22 16:12:54 +0200 | haritz | (~hrtz@user/haritz) (Remote host closed the connection) |
| 2021-09-22 16:13:54 +0200 | haritz | (~hrtz@62.3.70.206) |
| 2021-09-22 16:13:54 +0200 | haritz | (~hrtz@62.3.70.206) (Changing host) |
| 2021-09-22 16:13:54 +0200 | haritz | (~hrtz@user/haritz) |
| 2021-09-22 16:14:06 +0200 | <dminuoso> | CT is something that's nice to sprinkle ontop *after* you've become a seasoned haskeller - but only if you enjoy CT. |
| 2021-09-22 16:14:06 +0200 | <robbert-vdh> | lortabac: Yeah I also found that one! But the issue there is that you'll end up with basically the same situation as with HasCallStack, while relying on even more GHC implementation details. The main benefit I envisioned when using some custom implicit parameter instead of HasCallStack would be that you'd get a type checker error if you forgot to either define or propagate it. |
| 2021-09-22 16:14:20 +0200 | <dminuoso> | Learning CT *before* or *while* learning Haskell is likely not going to be helpful and just confusing. |
| 2021-09-22 16:14:22 +0200 | <robbert-vdh> | Reader would be the better option, but that's just not going to be feasible |
| 2021-09-22 16:14:22 +0200 | <dminuoso> | I made that mistake. |
| 2021-09-22 16:14:37 +0200 | <dminuoso> | Wish I hadnt, it delayed my basic haskell competencies by nearly half a year. |
| 2021-09-22 16:15:25 +0200 | <dminuoso> | ldlework: Im not trying to dissuade you from learning CT, but when you're also new to Haskell, Im confident it's going to be more time efficient to look at CT after you've become acquianted with haskell |
| 2021-09-22 16:20:27 +0200 | <jneira[m]> | <maerwald> "if you want me to redo cabal..." <- https://github.com/haskell/cabal-userguide |
| 2021-09-22 16:21:16 +0200 | <ldlework> | I become confused when I read: |
| 2021-09-22 16:21:18 +0200 | <ldlework> | "Now I want you to forget that you are dealing with the set of natural numbers and just think of it as a single object, a blob with a bunch of morphisms — the adders. A monoid is a single object category. In fact the name monoid comes from Greek mono, which means single. Every monoid can be described as a single object category with a set of morphisms that follow appropriate rules of |
| 2021-09-22 16:21:20 +0200 | <ldlework> | composition. |
| 2021-09-22 16:21:53 +0200 | <ldlework> | Are the set of natural numbers, the single object? Or is the blob of morphisms, the adders, the functions, the object? |
| 2021-09-22 16:22:12 +0200 | <ldlework> | by "single object category" do they mean "a category with a single object"? |
| 2021-09-22 16:22:21 +0200 | <ldlework> | I have a hard time understanding what that single object is. |
| 2021-09-22 16:24:53 +0200 | <ldlework> | When I think morphism I think of transformation, and are the morphisms things that work on the "single object" or are morphisms things that work on the numbers, which are in the set of natural numbers, which is the single object in the category/monoid? |
| 2021-09-22 16:26:40 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2021-09-22 16:27:17 +0200 | flouflou | (~flouflou@modemcable032.110-177-173.mc.videotron.ca) |
| 2021-09-22 16:29:29 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 264 seconds) |
| 2021-09-22 16:34:42 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-09-22 16:35:25 +0200 | qbt | (~edun@user/edun) |
| 2021-09-22 16:36:21 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) |
| 2021-09-22 16:38:47 +0200 | <geekosaur> | as I (possibly incorrectly) understand it, all the numbers in the category behave the same way because otherwise it wouldn't be a category, so you only need one of them |
| 2021-09-22 16:39:10 +0200 | pooryorick | (~pooryoric@87-119-174-173.tll.elisa.ee) (Ping timeout: 265 seconds) |
| 2021-09-22 16:39:26 +0200 | <geekosaur> | the other possibility being that we're operating at a level above the numbers themselves |
| 2021-09-22 16:40:43 +0200 | <ldlework> | Right, I had the intuition that the morphisms maybe work upon the "single object", the "set of natural numbers" like it works upon the set itself. But the "adders" here are like partially-applied addition functions. |
| 2021-09-22 16:40:44 +0200 | pooryorick | (~pooryoric@87-119-174-173.tll.elisa.ee) |
| 2021-09-22 16:40:50 +0200 | <ldlework> | One for each number in the natural set. |
| 2021-09-22 16:41:46 +0200 | azeem | (~azeem@emp-91-123.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-09-22 16:42:03 +0200 | <dminuoso> | ldlework: Consider a subcategory of Set. A single object might be the set of all natural numberrs. |
| 2021-09-22 16:42:09 +0200 | azeem | (~azeem@2a00:801:2d6:ba33:1dbc:2215:71a9:ffcb) |
| 2021-09-22 16:43:26 +0200 | <dminuoso> | Morphisms are functions from set to set, but we consider not all such functions, but perhaps one that adds nothing, and one that adds one, one - both `f : Nat -> Nat`, `g : Nat -> Nat` |
| 2021-09-22 16:43:34 +0200 | <dminuoso> | That's it. |
| 2021-09-22 16:44:10 +0200 | <dminuoso> | These morphisms are valid, as they respect composition laws |
| 2021-09-22 16:44:43 +0200 | <ldlework> | But what is the single object that milewski refers to in the case at hand |
| 2021-09-22 16:45:04 +0200 | <dminuoso> | In my example, the set of natural numbers. |
| 2021-09-22 16:45:25 +0200 | <Morrow[m]> | It doesn't matter, any single-object category will do. |
| 2021-09-22 16:45:41 +0200 | <dminuoso> | The really magical part of category theory is that you no longer *care* about the internals of those objects. |
| 2021-09-22 16:45:51 +0200 | <dminuoso> | It's all about the morphisms. :) |
| 2021-09-22 16:46:26 +0200 | ubert | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) (Ping timeout: 265 seconds) |
| 2021-09-22 16:46:52 +0200 | <dminuoso> | The term `monoid` in category theory is terribly confusing since there's multiple (related) notions |
| 2021-09-22 16:47:27 +0200 | <Morrow[m]> | The power we get, is that since we don't examine the internals of objects, the theorems apply very generally, to a wide range of topics. |
| 2021-09-22 16:47:39 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) |
| 2021-09-22 16:48:42 +0200 | <Morrow[m]> | So anything we prove about categorical monoids will apply to the natural numbers with id and (+1). |
| 2021-09-22 16:49:31 +0200 | <dminuoso> | Morrow[m]: Sure you meant categorical monoids here? |
| 2021-09-22 16:49:41 +0200 | <dminuoso> | That seems orthogonal |
| 2021-09-22 16:50:23 +0200 | <Morrow[m]> | I meant "monoids in CT" by that, sorry. |
| 2021-09-22 16:59:28 +0200 | ubert | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) |
| 2021-09-22 17:03:20 +0200 | MQ-17J | (~MQ-17J@35.50.35.3) (Ping timeout: 265 seconds) |
| 2021-09-22 17:03:31 +0200 | MQ-17J | (~MQ-17J@2607:fb90:885d:dc4:b0b2:2c03:76da:1640) |
| 2021-09-22 17:04:02 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2021-09-22 17:04:41 +0200 | <monochrom> | You can compose two morphisms. This can model adding two numbers. Note that both are associative, both have identities, this is a decent match. |
| 2021-09-22 17:05:27 +0200 | max22- | (~maxime@2a01cb08833598009945523f8c6be6aa.ipv6.abo.wanadoo.fr) (Quit: Leaving) |
| 2021-09-22 17:06:01 +0200 | <monochrom> | If you use two objects for two numbers, what can you do to two objects? You can't even compose them. Your model of addition will be some kind of add-on that doesn't play to the strength of categories. |
| 2021-09-22 17:07:15 +0200 | dut | (~dut@user/dut) |
| 2021-09-22 17:09:49 +0200 | jcob | (~jcob@216-165-95-181.natpool.nyu.edu) |
| 2021-09-22 17:09:55 +0200 | <monochrom> | And then you will want to use "f . f . f . f" to model "x + x + x + x". If you have so much as "f . f", type inference forces f to be an endomorphism. The eureka is then all numbers are endomorphisms and they all have the same domain. You need only one object to hang them on. |
| 2021-09-22 17:10:05 +0200 | <jcob> | Hi everyone! Here for a recc. Anybody know good communities for parsing and compiler construction? |
| 2021-09-22 17:10:18 +0200 | <jcob> | I have some questions on course material and I'm interested in the field as well. |
| 2021-09-22 17:11:52 +0200 | max22- | (~maxime@2a01cb0883359800d93abb16064ffecc.ipv6.abo.wanadoo.fr) |
| 2021-09-22 17:12:29 +0200 | <dolio> | You could have objects be numbers, and + be tensor product. Then you can do something else with arrows. |
| 2021-09-22 17:13:52 +0200 | <dolio> | Arrows could be ordering. Then `3 ≤ 4` and `10 ≤ 15` gives rise to `3+10 ≤ 4+15`. |
| 2021-09-22 17:14:28 +0200 | <monochrom> | Yeah there will be times when you model something else, where using objects for numbers is advantageous. |
| 2021-09-22 17:14:38 +0200 | <ldlework> | I appreciate the answers. dminuoso, so if the object is the set of natural numbers, then the morphisms in a category must be things that work upon items within the set. Like adding 1 to a number in the set of all natural numbers. So I can get away from the idea that morphisms work upon categories. But rather, for a given category, it's specific morphisms work upon items inside the objects (sets?) |
| 2021-09-22 17:14:39 +0200 | <ldlework> | of the category. I'm anticipating eventually that there will be categories who's objects (sets) are comprised of items which are themselves categories, in which case the morphisms would be operating on categories. |
| 2021-09-22 17:14:42 +0200 | <ldlework> | Did I get any of that right? |
| 2021-09-22 17:15:34 +0200 | dut | (~dut@user/dut) (Quit: Leaving) |
| 2021-09-22 17:15:48 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 17:15:56 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 246 seconds) |
| 2021-09-22 17:16:35 +0200 | <dolio> | The object doesn't have to be the set of natural numbers. It doesn't really matter what the object is, there's just one of them. |
| 2021-09-22 17:17:00 +0200 | <monochrom> | Yeah in this model the homset is the set of numbers. |
| 2021-09-22 17:17:14 +0200 | <monochrom> | galaxy brain? |
| 2021-09-22 17:17:39 +0200 | <monochrom> | Note how I keep using the word "model" to prime a subtext. |
| 2021-09-22 17:18:35 +0200 | <dolio> | In cases like the category of sets, it's useful to say that the objects are sets, because you need one object for each possible set, so what else are you going to use. But for monoids-as-categories it doesn't really matter as much. |
| 2021-09-22 17:20:02 +0200 | <monochrom> | You are applying a piece of math. The measure of how right you are is based on what benefit you get out of it, whether it solves your problem (so it depends on your problem). Not on whose authority it is. |
| 2021-09-22 17:21:47 +0200 | ub | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) |
| 2021-09-22 17:24:20 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-22 17:26:12 +0200 | nschoe | (~quassel@178.251.84.79) |
| 2021-09-22 17:26:20 +0200 | asthasr | (~asthasr@162.210.28.151) |
| 2021-09-22 17:28:42 +0200 | <monochrom> | Perhaps the problem of learning here is once again hoping that the object and the endomorphisms are defined in terms of things you already know, as opposed to simply axiomatizing that you have an object (no further definition), you have these endomorphisms that satisfy certain expectations (no further definition). |
| 2021-09-22 17:28:42 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 17:28:44 +0200 | ub | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-22 17:32:26 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) |
| 2021-09-22 17:32:31 +0200 | jcob | (~jcob@216-165-95-181.natpool.nyu.edu) (Quit: Client closed) |
| 2021-09-22 17:34:26 +0200 | <ldlework> | "In cases like the category of sets, it's useful to say that objects are sets, because you need one object for each possible set." So when we are talking about the set of natural numbers, is the category we're talking about "Natural Numbers" or "Monoids"? If it's the former, wouldnt' what you said imply that each natural number would be an object? If it's the latter, I suppose that means that |
| 2021-09-22 17:34:27 +0200 | <ldlework> | there's one object in the Category of Monoids, and that single object is a generic representation of anything that has an associative operator with identity where the set of natural numbers is merely an example of such an object? |
| 2021-09-22 17:34:36 +0200 | <ldlework> | (thank you all so much for your replied, srsly) |
| 2021-09-22 17:34:40 +0200 | <ldlework> | replies too |
| 2021-09-22 17:35:23 +0200 | <timCF> | Hello! Could anybody help me a bit with `Fixed a` type? A want a type signature `a :: Fixed 8` but for some reason GHC is saying "Expected a type, but 8 has kind Nat". At the same time `a :: Fixed E9` works fine. |
| 2021-09-22 17:35:24 +0200 | <monochrom> | Neither. Here we use one category to model one monoid. |
| 2021-09-22 17:35:27 +0200 | <c_wraith> | I'm not sure what a "Category of Monoids" is. |
| 2021-09-22 17:35:37 +0200 | <ldlework> | c_wraith: me either clearly :P |
| 2021-09-22 17:35:42 +0200 | <c_wraith> | It doesn't make much sense. I'm not sure how to connect arrows. |
| 2021-09-22 17:35:53 +0200 | <dolio> | 'Category of monoids' would presumably have monoids as objects and monoid homomorphisms as arrows. |
| 2021-09-22 17:35:54 +0200 | <ldlework> | Well what category are we talking about, when talking about the natural numbers and monoids? |
| 2021-09-22 17:36:24 +0200 | <c_wraith> | I think as monochrom points out, you're looking for a slightly different idea - the fact that all monoids are the same thing as a single-object category |
| 2021-09-22 17:36:29 +0200 | <geekosaur> | timCF, the possible values for Fixed are defined in Data.Fixed |
| 2021-09-22 17:36:32 +0200 | <monochrom> | or one category to model all of the natural numbers, or rather, natural number addition. |
| 2021-09-22 17:36:39 +0200 | <geekosaur> | you probably want something like Fixed E8 |
| 2021-09-22 17:37:13 +0200 | <ldlework> | OK so "there is a category of natural number addition and it is true of the monoid laws" |
| 2021-09-22 17:37:15 +0200 | <ldlework> | something like that? |
| 2021-09-22 17:37:16 +0200 | <geekosaur> | although I'm not sure that's predefined. there are some things for building your own iirc |
| 2021-09-22 17:37:20 +0200 | Null_A | (~null_a@2601:645:8700:2290:887d:3c4c:6983:4192) |
| 2021-09-22 17:38:16 +0200 | <ldlework> | I'll just keep reading :P |
| 2021-09-22 17:38:20 +0200 | <monochrom> | Don't worry, there are also times when we need multiple objects and they carry information, and the morphisms are boring. For example when modeling natural number order, like dolio's example but suppose I omit addition. |
| 2021-09-22 17:39:19 +0200 | <ldlework> | A difficulty with category theory I've always had is that I cannot help but to understand a category in the philosophical sense, of a set of objects who are true for a set of properties. |
| 2021-09-22 17:39:24 +0200 | <timCF> | geekosaur: seems like `E8` is not exported, but I do see that there is one instance (first which is supposed to give me any custom precision I want), but I don't have an idea how to use it https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Fixed.html#t:HasResolution |
| 2021-09-22 17:39:35 +0200 | <ldlework> | But my old acquaintance would always badger me that that is completely wrong. |
| 2021-09-22 17:39:47 +0200 | <monochrom> | Generally we can use one category to model one partial order. An object is an element. Each morphism X->Y is trivial, but it exists iff X<=Y. |
| 2021-09-22 17:40:00 +0200 | <Cale> | ldlework: One thing you might be a little confused about, I can't tell... there is a category of monoids, where the objects are monoids, and the arrows are monoid homomorphisms between them. But then you can also take any one monoid and turn it into a category having a single object, and where the arrows are the elements of that monoid, and composing arrows multiplies the elements according to that monoid's |
| 2021-09-22 17:40:00 +0200 | <Cale> | multiplication. |
| 2021-09-22 17:40:04 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-09-22 17:40:23 +0200 | <c_wraith> | call it a mathegory in your head, if you need to distinguish the ideas. :P |
| 2021-09-22 17:40:32 +0200 | <Cale> | ldlework: A category in this setting has a particular technical definition which you ought to learn first :) |
| 2021-09-22 17:40:53 +0200 | <monochrom> | Ugh category theory is totally not about a collection of objects who are true for a collection of properties. |
| 2021-09-22 17:41:05 +0200 | MQ-17J | (~MQ-17J@2607:fb90:885d:dc4:b0b2:2c03:76da:1640) (Read error: Connection reset by peer) |
| 2021-09-22 17:41:13 +0200 | <monochrom> | If anything the properties are for morphisms not objects. |
| 2021-09-22 17:41:52 +0200 | <ldlework> | Yeah I suspect this will be a hurdle for me. |
| 2021-09-22 17:41:52 +0200 | <geekosaur> | hm, the docs I'm looking at suggest that shoulkd work, but the docs are for ghc 9.0 |
| 2021-09-22 17:41:54 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 17:41:58 +0200 | <geekosaur> | may not work in 8.10 |
| 2021-09-22 17:42:11 +0200 | <monochrom> | If you don't secretly realize that each category is defined by its morphisms, that the objects are only there for type checking, you are doing it wrong. |
| 2021-09-22 17:42:12 +0200 | <Cale> | It's not just a collection of things having a common property, it's a particular sort of structure consisting of a collection of "objects" and a collection of "arrows" which are arranged in a particular way between the objects, and a definition for how to "compose" the arrows |
| 2021-09-22 17:42:19 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 17:42:49 +0200 | <ldlework> | Cale: right so it seems to be a super-notion of the philosophical "category" |
| 2021-09-22 17:42:53 +0200 | <Cale> | (but you'll be better served by reading Wikipedia's definition) https://en.wikipedia.org/wiki/Category_(mathematics)#Definition |
| 2021-09-22 17:43:05 +0200 | <c_wraith> | it's just totally independent |
| 2021-09-22 17:43:06 +0200 | <ldlework> | because, there is still notion of objects that are in the category, and objects that are not |
| 2021-09-22 17:43:06 +0200 | <sclv> | what you're calling a philosophical "category" is just like... a "set" |
| 2021-09-22 17:43:09 +0200 | <geekosaur> | looks like data E8; instance HasResolution E8 where resolution _ = 8 |
| 2021-09-22 17:43:09 +0200 | <c_wraith> | forget philosophy |
| 2021-09-22 17:43:21 +0200 | <sclv> | a category is a set _and_ structure about morphisms |
| 2021-09-22 17:43:29 +0200 | <ldlework> | sclv: right, it's hard for me not to see a category as a set with lawful constraints or something like that |
| 2021-09-22 17:43:42 +0200 | <Cale> | ldlework: Or a sub-notion, but only insofar as you have a collection of objects |
| 2021-09-22 17:44:04 +0200 | <timCF> | geekosaur: oh, so I just define my own resolution type locally? I'll try, thanks! |
| 2021-09-22 17:44:13 +0200 | <geekosaur> | seems like it |
| 2021-09-22 17:44:30 +0200 | <monochrom> | If you mix up the philosophy community and the math community, your next point of confusion is that they also use the same word "monad" for two unrelated definitions. |
| 2021-09-22 17:44:42 +0200 | <ldlework> | Cale: I guess a sub-notion because there's more baggage, and so more restrictive in definition. I was thinking in the sense that since all Javascript is valid Typescript but not the otherway around, Typescript is a superset of Javascript. But I think I see what you mean. |
| 2021-09-22 17:44:43 +0200 | xiongxin | (~quassel@119.123.102.205) (Remote host closed the connection) |
| 2021-09-22 17:44:54 +0200 | <geekosaur> | sadly the KnownNat entry for Fixed has no "Since:" |
| 2021-09-22 17:44:55 +0200 | <sclv> | think of a set as a "bag of marbles". there's no real difference between the set of five marbles and the set {a,b,c,d,e} and the set {1,2,3,4,5} because you can get between them by renaming |
| 2021-09-22 17:45:01 +0200 | <Cale> | But also those objects really needn't have anything to do with one another apart from being part of the category. What the objects "are" is almost entirely irrelevant to us, they mostly serve as labels to make sure we don't compose arrows that we shouldn't. |
| 2021-09-22 17:45:08 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.2.1) |
| 2021-09-22 17:45:10 +0200 | <sclv> | but you can have different categories each of which have five objects, but have totally different morphism structures |
| 2021-09-22 17:45:14 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 17:45:35 +0200 | <sclv> | a good example is you can look at categories _only_ with one element, and they _still_ have a rich morphism structure |
| 2021-09-22 17:45:37 +0200 | <ldlework> | morphism sturctures "sounds like" a very abstracted notion of qualitative restrictions on membership |
| 2021-09-22 17:45:58 +0200 | xiongxin | (~quassel@119.123.102.205) |
| 2021-09-22 17:46:00 +0200 | dut | (~dut@user/dut) |
| 2021-09-22 17:46:03 +0200 | <ldlework> | IE a list of predicates that must be all true of an object for it to be in that set or category |
| 2021-09-22 17:46:20 +0200 | <timCF> | geekosaur: it worked, thanks! |
| 2021-09-22 17:46:26 +0200 | <sclv> | i.e. i pick the category with the object *, the identity arrow on * (which must exist) and also with morphisms generated by a single self map `i : * -> *` -- what is this category? |
| 2021-09-22 17:46:35 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 17:47:00 +0200 | <monochrom> | Yeah sets are a very poor way to explain categories to yourself. |
| 2021-09-22 17:47:05 +0200 | <dolio> | monochrom: But the next step is to realize that the objects do matter, and the arrows may not actually all matter. :) |
| 2021-09-22 17:47:29 +0200 | <ldlework> | monochrom: I'm only describing my current pathology not advocating for it :P |
| 2021-09-22 17:47:32 +0200 | <sclv> | my example above gives the category of natural numbers under addition |
| 2021-09-22 17:47:34 +0200 | <monochrom> | categories have so much more structure than sets. You are only doing a forgetful thing. |
| 2021-09-22 17:47:55 +0200 | <ldlework> | sclv: I got lost at "and also with morphisms generated by a single self map `i : * -> *` |
| 2021-09-22 17:48:08 +0200 | <monochrom> | or rather s/structure/information/ |
| 2021-09-22 17:48:22 +0200 | <sclv> | its a category that looks like one dot, the identity arrow that points to itself, and also an arrow from that dot to itself that is _not_ the identity |
| 2021-09-22 17:48:39 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) (Quit: leaving) |
| 2021-09-22 17:48:39 +0200 | <Cale> | ldlework: Basically, we run out of words in mathematics for "collection of some sort with additional structure", and so there are dozens of special words that sound roughly like some sort of collection, but actually have a detailed technical meaning and lots of additional structure. |
| 2021-09-22 17:48:45 +0200 | <ldlework> | monochrom: in philosophy ontological categories are not just mathematical sets, they have qualitative constraints on them |
| 2021-09-22 17:48:46 +0200 | Cajun | (~Cajun@user/cajun) (Quit: Client closed) |
| 2021-09-22 17:48:46 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Ping timeout: 265 seconds) |
| 2021-09-22 17:48:49 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-09-22 17:49:00 +0200 | <ldlework> | and i was saying it sounds like the morphisms of a category are a way of very abstractly encoding those qualitative constraints |
| 2021-09-22 17:49:05 +0200 | <ldlework> | formalizing them |
| 2021-09-22 17:49:14 +0200 | <sclv> | but of course, you also get generated by that the composition of that arrow `i . i` and `i . i . i` etc. (you can also throw in identities into the composition, but the laws say they don't do anything, so you can ignore them |
| 2021-09-22 17:49:22 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-22 17:49:24 +0200 | <sclv> | ) |
| 2021-09-22 17:49:30 +0200 | <ldlework> | it mean in philosophy this is all rooted in predicate and propositional logics and certainly in some grander sense category theory is going to link up |
| 2021-09-22 17:49:42 +0200 | <sclv> | not in any useful sense for you, though, just ignore that |
| 2021-09-22 17:49:58 +0200 | <ldlework> | Cale: yeah that makes sense |
| 2021-09-22 17:50:08 +0200 | <sclv> | again, put a dot on a piece of paper, and draw an arrow that's a loop going from that dot to itself, and think about it |
| 2021-09-22 17:50:12 +0200 | <sclv> | now draw two loops and think about that |
| 2021-09-22 17:50:21 +0200 | <sclv> | now draw one loop, but have it be invertible, and think about that |
| 2021-09-22 17:50:35 +0200 | <sclv> | these are all categories with one object, but representing very different mathematical strutures |
| 2021-09-22 17:50:42 +0200 | <ldlework> | sclv: i get the notion of identity |
| 2021-09-22 17:50:44 +0200 | <ldlework> | but like |
| 2021-09-22 17:50:51 +0200 | <ldlework> | you can a notion of identity for transofrmation on specific numbers |
| 2021-09-22 17:50:54 +0200 | <ldlework> | like (+0) |
| 2021-09-22 17:50:56 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 17:50:56 +0200 | <ldlework> | or |
| 2021-09-22 17:51:08 +0200 | <ldlework> | you could have identity on some more general object like the set of all natural numbers |
| 2021-09-22 17:51:10 +0200 | <ldlework> | pointing back to itself |
| 2021-09-22 17:51:17 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 17:51:21 +0200 | <sclv> | not in this setup. there's plenty of categories you can generate using numbers that have totally different morphism structures. there's not "one category of natural numbers" |
| 2021-09-22 17:51:23 +0200 | xiongxin | (~quassel@119.123.102.205) (Quit: No Ping reply in 180 seconds.) |
| 2021-09-22 17:51:24 +0200 | <ldlework> | where there could be "morphisms" from the set of natural numbers, to some other kind of objects |
| 2021-09-22 17:51:34 +0200 | <monochrom> | I have friends who are very fluent in C++. Do they know functors? Yes and no. |
| 2021-09-22 17:51:36 +0200 | <ldlework> | it's hard to understand at which level of abstraction we're really working |
| 2021-09-22 17:51:36 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 17:52:04 +0200 | <ldlework> | Like I can imagine 1 with a self loop, and a loop to 2, which also has a self loop, etc |
| 2021-09-22 17:52:04 +0200 | <monochrom> | They know C++'s functors. They don't know Haskell's or math's functor. Oh btw there is a 3rd functor, from SML. |
| 2021-09-22 17:52:22 +0200 | <ldlework> | but I can also imagine a graph where the first node is "the set of all natural numbers" with a self loop, and an arrow pointing to some other object |
| 2021-09-22 17:52:29 +0200 | <ldlework> | representing the set of all even natural numbers |
| 2021-09-22 17:52:31 +0200 | <ldlework> | or something like that |
| 2021-09-22 17:52:38 +0200 | <sclv> | sure. these are all possible categories |
| 2021-09-22 17:52:38 +0200 | xiongxin | (~quassel@119.123.100.167) |
| 2021-09-22 17:52:47 +0200 | <ldlework> | sclv: even the first example? |
| 2021-09-22 17:52:54 +0200 | <ldlework> | where the number 1 has a self loop? |
| 2021-09-22 17:53:12 +0200 | <ldlework> | and another arrow which points to the number 2, etc? |
| 2021-09-22 17:53:16 +0200 | _bin | (~bin@user/bin/x-1583188) (Quit: ZNC - https://znc.in) |
| 2021-09-22 17:53:17 +0200 | <ldlework> | is that a category? |
| 2021-09-22 17:53:36 +0200 | <sclv> | well it depends what you mean. you can create a discrete category where every natural corresponds to a different object. then _every_ object has an identity loop, by definition |
| 2021-09-22 17:53:52 +0200 | <ldlework> | that's what i'm imagining right now |
| 2021-09-22 17:53:56 +0200 | <sclv> | but also you can draw whatever other arrows you want. and then you get "for free" the compositions. |
| 2021-09-22 17:53:57 +0200 | <dsal> | I knew functors from O'Caml, which made Haskell functors confusing. |
| 2021-09-22 17:54:09 +0200 | <sclv> | this is known as the "free category generated by a graph" and any graph you can draw generates a category |
| 2021-09-22 17:54:30 +0200 | <ldlework> | sclv: right since we have the arrow that goes from 1 to 2 |
| 2021-09-22 17:54:36 +0200 | <ldlework> | that means there will be an arrow going from 2 to 3 |
| 2021-09-22 17:54:38 +0200 | _bin | (~bin@user/bin/x-1583188) |
| 2021-09-22 17:54:38 +0200 | <sclv> | it just so happens that categories may have _more rules for composition_ than those that come for free, so graphs don't capture that |
| 2021-09-22 17:54:40 +0200 | <ldlework> | so we can compose from 1 to 3 |
| 2021-09-22 17:54:43 +0200 | <ldlework> | and everything else? |
| 2021-09-22 17:54:57 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) |
| 2021-09-22 17:54:58 +0200 | <sclv> | no, if you have an arrow from 1 to 2, there's no reason you'd have an arrow from 2 to 3 if they're all distinct objects |
| 2021-09-22 17:55:19 +0200 | <sclv> | if you have 1 -> 2, and _also_ 2 -> 3 then you get the composition 1 -> 3 automatically |
| 2021-09-22 17:55:20 +0200 | wonko | (~wjc@62.115.229.50) |
| 2021-09-22 17:55:28 +0200 | <ldlework> | Right that's what I meant I think |
| 2021-09-22 17:55:34 +0200 | <ldlework> | But you're saying |
| 2021-09-22 17:55:39 +0200 | <ldlework> | If we're taking seriously that 1 is different than 2 |
| 2021-09-22 17:55:41 +0200 | <sclv> | but you may have _another_ arrow 1 -> 3 not generated by that composition, and that's not equal to the composition |
| 2021-09-22 17:55:47 +0200 | <ldlework> | than we can't assume they have the same arrows or whatever |
| 2021-09-22 17:55:51 +0200 | <ldlework> | because they are truly distinct |
| 2021-09-22 17:55:56 +0200 | <sclv> | right -- they're different objects in that setup, yet |
| 2021-09-22 17:55:58 +0200 | <sclv> | yes |
| 2021-09-22 17:56:03 +0200 | <ldlework> | ok so |
| 2021-09-22 17:56:16 +0200 | <ldlework> | if we presumed that for every object in this category we're talking about where the objects are naturals |
| 2021-09-22 17:56:24 +0200 | <ldlework> | there was such an arrow between each of them, with the identity |
| 2021-09-22 17:56:27 +0200 | <sclv> | the best place to start with categories is not sets imho. instead start with partial orders, and then consider when more arrows may exist |
| 2021-09-22 17:56:39 +0200 | <ldlework> | is that just an arbitrary category we made up that has no generally known name? |
| 2021-09-22 17:56:40 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 17:56:58 +0200 | <sclv> | so all objects have an arrow to every other object? |
| 2021-09-22 17:57:03 +0200 | xiongxin | (~quassel@119.123.100.167) (Client Quit) |
| 2021-09-22 17:57:04 +0200 | <ldlework> | to their subsequent |
| 2021-09-22 17:57:10 +0200 | <ldlework> | i forget what math calls that |
| 2021-09-22 17:57:13 +0200 | <ldlework> | the next natural |
| 2021-09-22 17:57:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 17:57:23 +0200 | <ldlework> | like when you define them in peano arithmetic |
| 2021-09-22 17:57:31 +0200 | <ldlework> | ancestor... no |
| 2021-09-22 17:57:38 +0200 | <ldlework> | i forget, but hopefully you get what i mean |
| 2021-09-22 17:57:42 +0200 | <sclv> | that's often what people will call "the naturals as a preorder category" |
| 2021-09-22 17:57:48 +0200 | <ldlework> | each object has a self-arrow, and an arrow pointing to it's +1 |
| 2021-09-22 17:57:50 +0200 | <ldlework> | I see |
| 2021-09-22 17:57:56 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-09-22 17:57:58 +0200 | <ldlework> | OK |
| 2021-09-22 17:58:02 +0200 | <ldlework> | So how does this differentiate |
| 2021-09-22 17:58:03 +0200 | <sclv> | the relationship shouldn't be thought of as addition, it should be thought of as <= |
| 2021-09-22 17:58:15 +0200 | <ldlework> | When the first object in our new graph is "the set of natural numbers" |
| 2021-09-22 17:58:18 +0200 | xiongxin | (~quassel@113.116.33.208) |
| 2021-09-22 17:58:19 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-09-22 17:58:21 +0200 | <sclv> | as in "every object has a unique morphism to every other object it is less than or equal to" |
| 2021-09-22 17:58:21 +0200 | dut | (~dut@user/dut) (Quit: Leaving) |
| 2021-09-22 17:58:27 +0200 | <monochrom> | sclv, that's how I started, and therefore I ended with being stuck at Galois connection for 20 years without wanting/needing/being capable of stepping up to adjunctions. >:) |
| 2021-09-22 17:58:35 +0200 | <zardoz> | I'm kind of shocked that this works flawlessly in windows.. cool library! https://hackage.haskell.org/package/concurrent-output |
| 2021-09-22 17:58:59 +0200 | <sclv> | monochrom: yeah i actually find order theory very powerful on its own -- especially when one considers richer lattices, etc |
| 2021-09-22 18:00:21 +0200 | <timCF> | I have one more question. Is there some standard class which I can use in type signature to declare that type `a` can be coerced to type `b` using `coerce` function? This might be useful for functions like `apply0 :: Coerce a b => (b -> b) -> a -> a` where `apply0 f = coerce . f . coerce`. |
| 2021-09-22 18:00:25 +0200 | akegalj | (~akegalj@93-138-133-62.adsl.net.t-com.hr) |
| 2021-09-22 18:02:34 +0200 | <sclv> | ?ty coerce |
| 2021-09-22 18:02:35 +0200 | <lambdabot> | error: |
| 2021-09-22 18:02:35 +0200 | <lambdabot> | • Variable not in scope: coerce |
| 2021-09-22 18:02:35 +0200 | <lambdabot> | • Perhaps you meant ‘coerced’ (imported from Control.Lens) |
| 2021-09-22 18:02:43 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:02:45 +0200 | <sclv> | ah well: `coerce :: Coercible a b => a -> b ` |
| 2021-09-22 18:02:52 +0200 | <sclv> | so that would be the type class? |
| 2021-09-22 18:03:24 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:04:01 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-09-22 18:04:08 +0200 | <timCF> | sclv: Interesting! I have used `coerce` many times, but never dealed with actual `Coercible` class instances, I'll try it, thanks! |
| 2021-09-22 18:04:28 +0200 | <timCF> | have never seen it be derived also |
| 2021-09-22 18:04:43 +0200 | xiongxin | (~quassel@113.116.33.208) (Quit: No Ping reply in 180 seconds.) |
| 2021-09-22 18:04:46 +0200 | <monochrom> | The :type command is underappreciated :) |
| 2021-09-22 18:04:51 +0200 | <sclv> | you can't derive it -- see the docs |
| 2021-09-22 18:04:51 +0200 | <sclv> | https://hackage.haskell.org/package/ghc-prim-0.7.0/docs/GHC-Types.html#t:Coercible |
| 2021-09-22 18:05:50 +0200 | <timCF> | Interesting :) |
| 2021-09-22 18:05:58 +0200 | xiongxin | (~quassel@113.116.33.208) |
| 2021-09-22 18:06:29 +0200 | <akegalj> | Hey. I was watching last years talk from skillsmatter by "Winter is comming even faster" by Joachim Breitner (https://skillsmatter.com/skillscasts/14903-winter-is-coming-even-faster) where at 11:18 he explains optimization technique/trick (Avoid the quadratic (++)). The trick/transformation explanation is about a minute long but I just can't seem to get it :/ If anyone is interested to have a look and |
| 2021-09-22 18:06:35 +0200 | <akegalj> | give me some tips that would be great <3 |
| 2021-09-22 18:07:59 +0200 | <monochrom> | Is it when you replace x++y++z by (x++) . (y++) . (z++) ? |
| 2021-09-22 18:08:08 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2021-09-22 18:08:36 +0200 | xiongxin | (~quassel@113.116.33.208) (Client Quit) |
| 2021-09-22 18:08:46 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:08:46 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:08:59 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:09:26 +0200 | <akegalj> | monochrom: it might be. He is replacing ++ with . , but there are some transformations that I don't get... |
| 2021-09-22 18:10:25 +0200 | <akegalj> | monochrom: [t] replaced with [t] -> [t], [] with id, [x] with (x:), xs++ys with xs . ys |
| 2021-09-22 18:11:00 +0200 | <akegalj> | monochrom: do you think thats the same? |
| 2021-09-22 18:12:28 +0200 | <sclv> | consider what all the transformations he gives look like when applied to the one element list |
| 2021-09-22 18:12:31 +0200 | <sclv> | er to the empty list |
| 2021-09-22 18:12:43 +0200 | <c_wraith> | there was a good blog post about that trick a while back |
| 2021-09-22 18:12:52 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Remote host closed the connection) |
| 2021-09-22 18:13:15 +0200 | <sclv> | https://en.wikipedia.org/wiki/Difference_list |
| 2021-09-22 18:13:17 +0200 | <c_wraith> | something about how it implicitly rewrites everything into a right-associated form |
| 2021-09-22 18:14:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:14:41 +0200 | <akegalj> | sclv: I think that's it, thanks! |
| 2021-09-22 18:14:50 +0200 | <akegalj> | c_wraith: monochrom: thanks both! |
| 2021-09-22 18:14:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:18:06 +0200 | <kuribas> | akegalj: https://hackage.haskell.org/package/dlist |
| 2021-09-22 18:18:06 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) |
| 2021-09-22 18:19:13 +0200 | <akegalj> | kuribas: thanks, there is also link from wiki to haskell wiki explanation https://wiki.haskell.org/Difference_list |
| 2021-09-22 18:19:59 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 18:20:53 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:21:14 +0200 | zachjs | (~zachjs@pool-96-224-239-180.nycmny.fios.verizon.net) |
| 2021-09-22 18:22:15 +0200 | maroloccio | (~marolocci@93-136-18-134.adsl.net.t-com.hr) |
| 2021-09-22 18:23:29 +0200 | yauhsien | (~yauhsien@118-167-47-202.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-09-22 18:23:40 +0200 | Null_A | (~null_a@2601:645:8700:2290:887d:3c4c:6983:4192) (Ping timeout: 252 seconds) |
| 2021-09-22 18:23:49 +0200 | Null_A | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) |
| 2021-09-22 18:26:45 +0200 | Null_A_ | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) |
| 2021-09-22 18:28:04 +0200 | Null_A__ | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) |
| 2021-09-22 18:28:57 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2021-09-22 18:29:05 +0200 | alzgh | (~alzgh@user/alzgh) (Remote host closed the connection) |
| 2021-09-22 18:29:14 +0200 | Null_A | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) (Ping timeout: 260 seconds) |
| 2021-09-22 18:29:25 +0200 | alzgh | (~alzgh@user/alzgh) |
| 2021-09-22 18:29:58 +0200 | timCF | (~timCF@m91-129-108-244.cust.tele2.ee) (Quit: leaving) |
| 2021-09-22 18:30:10 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:2e6e:d4a5:1c64:daa) (Quit: WeeChat 2.8) |
| 2021-09-22 18:30:18 +0200 | Null_A | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) |
| 2021-09-22 18:31:06 +0200 | Null_A_ | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) (Ping timeout: 260 seconds) |
| 2021-09-22 18:31:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-22 18:32:17 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:33:26 +0200 | Null_A__ | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) (Ping timeout: 260 seconds) |
| 2021-09-22 18:33:46 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-22 18:35:19 +0200 | <c_wraith> | huh. do TH typed splices participate in bidirectional inference? |
| 2021-09-22 18:36:42 +0200 | Null_A | (~null_a@2601:645:8700:2290:25aa:2fd7:a477:7781) (Ping timeout: 260 seconds) |
| 2021-09-22 18:37:29 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:37:37 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Read error: No route to host) |
| 2021-09-22 18:38:04 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:39:51 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-22 18:40:28 +0200 | <c_wraith> | looks like it does. you can generate a (TExp a) value by selecting an instance based on a |
| 2021-09-22 18:40:51 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-09-22 18:40:56 +0200 | <c_wraith> | that's probably a large part of why TExp was added. |
| 2021-09-22 18:41:06 +0200 | Null_A | (~null_a@2600:1010:b0d9:2882:48a4:bec2:eba0:2e41) |
| 2021-09-22 18:41:07 +0200 | <c_wraith> | but I hadn't thought about it. |
| 2021-09-22 18:43:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-09-22 18:44:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:44:29 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Ping timeout: 246 seconds) |
| 2021-09-22 18:46:10 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-22 18:49:23 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-09-22 18:49:41 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:50:09 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) (Ping timeout: 265 seconds) |
| 2021-09-22 18:50:30 +0200 | ub | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) |
| 2021-09-22 18:51:38 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 260 seconds) |
| 2021-09-22 18:51:41 +0200 | fefufo[m] | fcortesi |
| 2021-09-22 18:51:42 +0200 | cheater1__ | (~Username@user/cheater) |
| 2021-09-22 18:51:45 +0200 | cheater1__ | cheater |
| 2021-09-22 18:52:26 +0200 | fcortesi | (~fefufomat@2001:470:69fc:105::f3a9) (Quit: Reconnecting) |
| 2021-09-22 18:52:40 +0200 | fcortesi | (~fefufomat@2001:470:69fc:105::f3a9) |
| 2021-09-22 18:53:03 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Quit: ran away) |
| 2021-09-22 18:53:30 +0200 | fcortesi | (~fefufomat@2001:470:69fc:105::f3a9) (Client Quit) |
| 2021-09-22 18:53:44 +0200 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) |
| 2021-09-22 18:54:25 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-09-22 18:54:42 +0200 | Yotta | (~Yotta@195.1.199.74) |
| 2021-09-22 18:55:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-09-22 18:55:06 +0200 | <Yotta> | Howdy |
| 2021-09-22 18:55:27 +0200 | zaquest | (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-09-22 18:55:29 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 18:55:34 +0200 | <glguy> | hi |
| 2021-09-22 18:55:52 +0200 | zachjs | (~zachjs@pool-96-224-239-180.nycmny.fios.verizon.net) (Quit: zachjs) |
| 2021-09-22 18:55:54 +0200 | Null_A_ | (~null_a@2600:1010:b0d9:2882:943f:60e0:140f:bb0f) |
| 2021-09-22 18:57:43 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 252 seconds) |
| 2021-09-22 18:58:08 +0200 | Null_A | (~null_a@2600:1010:b0d9:2882:48a4:bec2:eba0:2e41) (Ping timeout: 246 seconds) |
| 2021-09-22 18:59:15 +0200 | max22- | (~maxime@2a01cb0883359800d93abb16064ffecc.ipv6.abo.wanadoo.fr) (Remote host closed the connection) |
| 2021-09-22 18:59:38 +0200 | <Yotta> | I'm struggling with a university task, anyone keen to lend a hand? |
| 2021-09-22 19:00:56 +0200 | zaquest | (~notzaques@5.128.210.178) |
| 2021-09-22 19:01:22 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) |
| 2021-09-22 19:03:12 +0200 | <dminuoso> | Hi, good to let us know this is a homework assignment. Let us know how we can help |
| 2021-09-22 19:03:43 +0200 | mixfix41 | (~homefame@user/mixfix41) |
| 2021-09-22 19:03:45 +0200 | <Yotta> | Of course. So I created this function to check if a is a prefix of b |
| 2021-09-22 19:03:53 +0200 | waleee | (~waleee@student-223-182.eduroam.uu.se) |
| 2021-09-22 19:03:58 +0200 | <Yotta> | isPrefix :: String -> String -> Bool |
| 2021-09-22 19:03:58 +0200 | <Yotta> | isPrefix [] _ = True |
| 2021-09-22 19:03:59 +0200 | <Yotta> | isPrefix _ [] = False |
| 2021-09-22 19:03:59 +0200 | <Yotta> | isPrefix (x:xs) (y:ys) = x == y && isPrefix xs ys |
| 2021-09-22 19:04:14 +0200 | Null_A_ | (~null_a@2600:1010:b0d9:2882:943f:60e0:140f:bb0f) (Ping timeout: 260 seconds) |
| 2021-09-22 19:04:46 +0200 | dut | (~dut@user/dut) |
| 2021-09-22 19:04:52 +0200 | <Yotta> | Now I'm trying create a function `locate` which should check if a exists in b, and output the index of the location (so not just prefix) |
| 2021-09-22 19:05:11 +0200 | awpr | wonders if everyone asking very similar questions here and on the FP Discord is from the same course |
| 2021-09-22 19:05:25 +0200 | <Yotta> | locate :: String -> String -> [(Int, Int)] |
| 2021-09-22 19:05:25 +0200 | <Yotta> | locate [] _ = [] |
| 2021-09-22 19:05:26 +0200 | <Yotta> | locate _ [] = [] |
| 2021-09-22 19:05:26 +0200 | <Yotta> | locate (x:xs) (y:ys) = ( |
| 2021-09-22 19:05:30 +0200 | <Yotta> | Haha probably awpr |
| 2021-09-22 19:05:45 +0200 | <dsal> | Pasting lots of lines of code here is a bad idea. Try this: Paste code/errors: https://paste.tomsmeding.com |
| 2021-09-22 19:06:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-09-22 19:06:23 +0200 | <Yotta> | Okay cool |
| 2021-09-22 19:06:24 +0200 | <Yotta> | https://paste.tomsmeding.com/rsYIHdcz |
| 2021-09-22 19:06:34 +0200 | <awpr> | (no implied judgment there, just interesting that there's been a flurry of like 3-4 people struggling with nearly the same thing) |
| 2021-09-22 19:06:48 +0200 | max22- | (~maxime@2a01cb0883359800388d3ba1f1b932ab.ipv6.abo.wanadoo.fr) |
| 2021-09-22 19:06:48 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 19:07:04 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 19:07:35 +0200 | <Yotta> | Yeah sorry I'm sure, I just entered here |
| 2021-09-22 19:08:07 +0200 | <dminuoso> | No worries, cant expect newcomers to me familiar with the finer details of IRC. |
| 2021-09-22 19:08:20 +0200 | qbt | (~edun@user/edun) (Remote host closed the connection) |
| 2021-09-22 19:08:36 +0200 | <Yotta> | Haven't used IRC in 10+ years haha |
| 2021-09-22 19:10:12 +0200 | <monochrom> | Is it OK for locate to call isPrefix? |
| 2021-09-22 19:10:28 +0200 | <dminuoso> | Yotta: What is your question? |
| 2021-09-22 19:10:33 +0200 | <dminuoso> | Or are you still working on that? |
| 2021-09-22 19:11:07 +0200 | <Yotta> | So I'm thinking when a == b, add the position of b to the first index, and as the second index i just do ` b + length of a` |
| 2021-09-22 19:11:15 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-09-22 19:11:39 +0200 | <Yotta> | But I can't figure out how to write that in haskell |
| 2021-09-22 19:11:55 +0200 | <awpr> | so the expected result is pairs of (start index, end index)? |
| 2021-09-22 19:12:27 +0200 | <awpr> | by which I mean after-the-end |
| 2021-09-22 19:12:32 +0200 | <monochrom> | "a == b" is not a good special case to split on. |
| 2021-09-22 19:12:45 +0200 | <Yotta> | I phrased the question a bit poorly, the function should behave like this: `locate “oo” “foobarbarfoo” = [(1,3), (10,12)]` `locate “oo” “barbarbar” = [] ` |
| 2021-09-22 19:13:04 +0200 | chele_ | (~chele@user/chele) (Remote host closed the connection) |
| 2021-09-22 19:14:34 +0200 | <Yotta> | So input a should be split into (x:xs), right? And if it doesn't match with y, then the function should recursively run `function xs` ? |
| 2021-09-22 19:14:42 +0200 | <awpr> | yep, that clears it up. so, you made a point to mention you've written `isPrefix`. does that mean you have an approach in mind to use it as part of `locate`? |
| 2021-09-22 19:14:48 +0200 | nschoe | (~quassel@178.251.84.79) (Ping timeout: 265 seconds) |
| 2021-09-22 19:15:06 +0200 | <awpr> | "yep" was re: the example inputs/outputs |
| 2021-09-22 19:15:08 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) |
| 2021-09-22 19:15:11 +0200 | <Yotta> | I understand |
| 2021-09-22 19:15:45 +0200 | <Yotta> | Well `isPrefix` was the previous task, idk if it's easier to use it in my next task here |
| 2021-09-22 19:15:58 +0200 | <monochrom> | Yes very much easier. |
| 2021-09-22 19:15:59 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 246 seconds) |
| 2021-09-22 19:16:22 +0200 | <monochrom> | "oo" occurs in "food" because "oo" is a prefix of "ood". |
| 2021-09-22 19:16:31 +0200 | <monochrom> | Not only that. |
| 2021-09-22 19:16:44 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-09-22 19:16:48 +0200 | <awpr> | have you internalized that String is the same as [Char], and what that means for what sub-structures exist in "foobarbarfoo"? |
| 2021-09-22 19:17:05 +0200 | <monochrom> | "oo" in "food" has index 1 because "oo" in "ood" has index 0, and the 'f' bumps that to 1. |
| 2021-09-22 19:17:05 +0200 | TDANG_ | (~TDANG@cpe-107-15-144-45.nc.res.rr.com) (Ping timeout: 252 seconds) |
| 2021-09-22 19:18:05 +0200 | ksqsf | (~user@2001:da8:d800:611:9de8:5c9:5157:fa51) |
| 2021-09-22 19:18:16 +0200 | <Yotta> | I understand String is a list of char's |
| 2021-09-22 19:18:26 +0200 | <Yotta> | Yeah got it monochrom |
| 2021-09-22 19:18:41 +0200 | TDANG_ | (~TDANG@cpe-107-15-144-45.nc.res.rr.com) |
| 2021-09-22 19:19:22 +0200 | <Yotta> | So I guess I should loop `locate` until `isPrefix` returns True, then add the current position to a list of Int's? |
| 2021-09-22 19:19:25 +0200 | <monochrom> | I should steal this assignment question :) |
| 2021-09-22 19:19:35 +0200 | <Yotta> | Haha, you a teacher? |
| 2021-09-22 19:19:41 +0200 | <monochrom> | Yes. |
| 2021-09-22 19:19:45 +0200 | <Yotta> | cool |
| 2021-09-22 19:20:12 +0200 | <dminuoso> | Who knows, perhaps monochrom is your professor even. |
| 2021-09-22 19:20:20 +0200 | <dminuoso> | :) |
| 2021-09-22 19:20:21 +0200 | <Yotta> | tell your students it's Prelude only |
| 2021-09-22 19:20:33 +0200 | <monochrom> | Nah I didn't know of this question. |
| 2021-09-22 19:20:40 +0200 | <Yotta> | if so, you gave us way too little time on this assigment monochrom! |
| 2021-09-22 19:21:50 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-09-22 19:23:40 +0200 | <awpr> | I wonder if anyone will implement Knuth-Morris-Pratt for this |
| 2021-09-22 19:24:32 +0200 | <monochrom> | Fat chance. There are two barriers. |
| 2021-09-22 19:24:40 +0200 | <monochrom> | First is to learn KMP in the first place. |
| 2021-09-22 19:24:47 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2021-09-22 19:24:58 +0200 | <monochrom> | Second is to re-express the imperative KMP you have learned in FP terms. |
| 2021-09-22 19:25:41 +0200 | <c_wraith> | Holy crap, template haskell changed completely in ghc 9 |
| 2021-09-22 19:25:52 +0200 | <awpr> | yeah fair enough, probably not gonna happen unless someone already knew a lot of Haskell going into the course |
| 2021-09-22 19:25:59 +0200 | <monochrom> | A student in this course, by definition, has already great trouble re-expressing any easy imperative algorithm in FP terms. |
| 2021-09-22 19:26:54 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-22 19:27:37 +0200 | <Yotta> | word |
| 2021-09-22 19:29:00 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) |
| 2021-09-22 19:29:12 +0200 | <c_wraith> | ok, so. typed applications aren't bidirectionally inferred. I tried to do that and got a ghc panic |
| 2021-09-22 19:29:36 +0200 | <c_wraith> | err. typed splices |
| 2021-09-22 19:29:45 +0200 | <monochrom> | Yikes. panic is not good. :) |
| 2021-09-22 19:30:21 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-09-22 19:31:14 +0200 | TDANG_ | (~TDANG@cpe-107-15-144-45.nc.res.rr.com) (Ping timeout: 265 seconds) |
| 2021-09-22 19:31:56 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-09-22 19:33:11 +0200 | <c_wraith> | ok, that's not a problem with bidirectional inference in general, just with partial type signatures |
| 2021-09-22 19:33:58 +0200 | <c_wraith> | that makes me think I should test in a newer ghc than 9.0.1 |
| 2021-09-22 19:35:27 +0200 | alzgh | (~alzgh@user/alzgh) (Remote host closed the connection) |
| 2021-09-22 19:35:47 +0200 | alzgh | (~alzgh@user/alzgh) |
| 2021-09-22 19:36:45 +0200 | python476 | (~user@88.160.31.174) |
| 2021-09-22 19:37:09 +0200 | <c_wraith> | yeah, it's fixed in newer (pre-release) versions |
| 2021-09-22 19:37:18 +0200 | <monochrom> | nice |
| 2021-09-22 19:38:21 +0200 | <c_wraith> | it does give me the partial type signature warning *twice* for some reason, but whatever. |
| 2021-09-22 19:38:45 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-09-22 19:39:03 +0200 | glguy | (x@libera/staff/glguy) (Quit: Quit) |
| 2021-09-22 19:40:08 +0200 | glguy | (x@libera/staff/glguy) |
| 2021-09-22 19:42:20 +0200 | <c_wraith> | is there a writeup on the new template-haskell somewhere? |
| 2021-09-22 19:47:58 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-22 19:48:02 +0200 | fendor_ | fendor |
| 2021-09-22 19:48:58 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 19:50:38 +0200 | neo1 | (~neo3@cpe-292712.ip.primehome.com) (Ping timeout: 246 seconds) |
| 2021-09-22 19:54:41 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2021-09-22 19:56:27 +0200 | <Yotta> | https://paste.tomsmeding.com/kOJ2Hec7 |
| 2021-09-22 19:56:37 +0200 | <Yotta> | Does this make sense at all (obviously it's not finished) ? |
| 2021-09-22 19:56:56 +0200 | akegalj | (~akegalj@93-138-133-62.adsl.net.t-com.hr) (Quit: leaving) |
| 2021-09-22 19:57:01 +0200 | <monochrom> | Yes. |
| 2021-09-22 19:57:36 +0200 | <tomsmeding> | locate [] _ = [] feels fishy to me |
| 2021-09-22 19:57:41 +0200 | waleee | (~waleee@student-223-182.eduroam.uu.se) (Ping timeout: 264 seconds) |
| 2021-09-22 19:57:52 +0200 | <tomsmeding> | clearly, the empty list appears in any list at position 0, doesn't it? :p |
| 2021-09-22 19:57:54 +0200 | <Yotta> | May I ask how I can add the indexes/position to become the return value? |
| 2021-09-22 19:57:54 +0200 | fendor | (~fendor@91.141.44.67.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-09-22 19:58:00 +0200 | <monochrom> | Right, I need second thoughts on that. |
| 2021-09-22 19:58:10 +0200 | <Yotta> | Aha |
| 2021-09-22 19:58:50 +0200 | <awpr> | but also if you're using isPrefix, you won't be tearing down the search term to the point of reaching an empty list |
| 2021-09-22 19:58:51 +0200 | <monochrom> | I think I would first and foremost test for prefixness first. |
| 2021-09-22 19:59:00 +0200 | <tomsmeding> | 'isPrefix = (all (uncurry (==)) .) . zip' but please don't do that |
| 2021-09-22 19:59:09 +0200 | <monochrom> | Only when x is not a prefix of y do I care "OK is y empty then?" |
| 2021-09-22 20:00:38 +0200 | <Yotta> | tbh I don't understand what you mean |
| 2021-09-22 20:01:02 +0200 | <Yotta> | tomsmeding |
| 2021-09-22 20:01:09 +0200 | <tomsmeding> | don't try :p |
| 2021-09-22 20:01:40 +0200 | <Yotta> | haha ok |
| 2021-09-22 20:01:46 +0200 | <tomsmeding> | that uncurry thing is a deliberately complicated way to write a simple thing |
| 2021-09-22 20:02:12 +0200 | <awpr> | haskellers sometimes like to code-golf while avoiding naming any function arguments for fun. an equivalent definition that might be more understandable is `isPrefix x = and . zipWith (==) x` |
| 2021-09-22 20:02:34 +0200 | tomsmeding | always forgets the existence of 'and' |
| 2021-09-22 20:02:51 +0200 | fendor | (~fendor@91.141.44.67.wireless.dyn.drei.com) |
| 2021-09-22 20:03:03 +0200 | <monochrom> | > ((all (uncurry (==)) .) . zip) "fooood" "foo" |
| 2021-09-22 20:03:05 +0200 | <lambdabot> | True |
| 2021-09-22 20:03:13 +0200 | <monochrom> | That's your bug there. |
| 2021-09-22 20:03:16 +0200 | <tomsmeding> | ow |
| 2021-09-22 20:03:17 +0200 | <awpr> | oops |
| 2021-09-22 20:03:24 +0200 | <tomsmeding> | here, it's even wrong ;) |
| 2021-09-22 20:03:51 +0200 | <monochrom> | The difficult is that "isPrefix [] _" and "isPrefix _ []" are not both True. You lost a symmetry there. |
| 2021-09-22 20:04:08 +0200 | <tomsmeding> | yeah, I don't do non-symmetric problems |
| 2021-09-22 20:05:25 +0200 | <dsal> | It's unfair to ask if a long string is a prefix of a shorter string. |
| 2021-09-22 20:05:50 +0200 | <monochrom> | All assymetries are unfair. :) |
| 2021-09-22 20:06:11 +0200 | <c_wraith> | let's redefine "prefix" so that both inputs must be the same length. |
| 2021-09-22 20:06:22 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-22 20:06:33 +0200 | <dsal> | isPrefix works in the zipWith case, it's just not picky about which is a prefix of which. |
| 2021-09-22 20:06:52 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:8c9e:15bc:1174:e66f) |
| 2021-09-22 20:07:17 +0200 | <monochrom> | I have a less radical redefinition. Redefine "prefix" to be bidirectional. x is a prefix of y or y is a prefix of x. |
| 2021-09-22 20:07:25 +0200 | <monochrom> | Yeah that. |
| 2021-09-22 20:07:40 +0200 | <Yotta> | how the hell do i do that |
| 2021-09-22 20:08:29 +0200 | <awpr> | step one: look up prefix on etymonline.com; step two: go back in time to that date and convince the originator of the word to choose a different definition |
| 2021-09-22 20:08:43 +0200 | <Yotta> | haha |
| 2021-09-22 20:08:53 +0200 | nvmd | (~nvmd@user/nvmd) (Quit: Later, nerds.) |
| 2021-09-22 20:09:01 +0200 | <Yotta> | or accept the bug... |
| 2021-09-22 20:09:14 +0200 | <monochrom> | The Teen Titans can help. |
| 2021-09-22 20:09:34 +0200 | <c_wraith> | I still don't understand why typed template haskell changed to introduce the Code type. Anyone have any link to a discussion of this change? |
| 2021-09-22 20:10:27 +0200 | <janus> | is there a good overview of haskell linting tools? or should i just read through the hlint docs ? |
| 2021-09-22 20:10:35 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 20:10:37 +0200 | <Yotta> | may i ask what to put in `then() ` and `else` in order to output index of position? |
| 2021-09-22 20:11:20 +0200 | <c_wraith> | I suppose it gives a top-level constructor for things that would otherwise by polymorphic over a type variable. If you want to create instances, that's a good thing. Hmm. |
| 2021-09-22 20:11:22 +0200 | <monochrom> | the else branch is easier. |
| 2021-09-22 20:11:50 +0200 | <c_wraith> | polymorphic over their top-level type constructor, specifically |
| 2021-09-22 20:11:52 +0200 | <monochrom> | "oo" is not a prefix of "food". What should you do next? |
| 2021-09-22 20:11:53 +0200 | <awpr> | do you have the present index in scope? if not, I'd start with keeping track of that (or the else branch) |
| 2021-09-22 20:12:00 +0200 | <glguy> | Here's a contribution to the unrequested golfing: (. tails) . findIndices . isPrefixOf |
| 2021-09-22 20:12:01 +0200 | Guest47 | (~Guest47@rrcs-98-6-18-130.sw.biz.rr.com) |
| 2021-09-22 20:12:15 +0200 | ksqsf | (~user@2001:da8:d800:611:9de8:5c9:5157:fa51) (ERC (IRC client for Emacs 27.2)) |
| 2021-09-22 20:12:53 +0200 | yauhsien | (~yauhsien@61-231-35-247.dynamic-ip.hinet.net) |
| 2021-09-22 20:13:12 +0200 | <Yotta> | monochrom run the same function with `x tail(y) `? |
| 2021-09-22 20:13:41 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Read error: No route to host) |
| 2021-09-22 20:14:20 +0200 | <dminuoso> | Yotta: What is `x tail(y)` supposed to denote? |
| 2021-09-22 20:14:27 +0200 | <Guest47> | on a new install of OSX big sur running `stack install text-show` fails with > ghc: couldn't find archive in `/usr/bin/iconv'at offset 16384; ghc: panic! (the 'impossible' happened); loadArchive "/usr/bin/iconv": failed . Any ideas? |
| 2021-09-22 20:14:31 +0200 | <Yotta> | Or wait, does that happen automatically? since i'm sending `x y` to `isPrefix ` |
| 2021-09-22 20:14:39 +0200 | <monochrom> | awpr, at this point I think I am a fan of post-processing, i.e., OK so locate "oo" "ood" returns [(0,1)], but the answer I need for locate "oo" "food" is [(1,2)], how do I do some post-processing to fix up that difference? |
| 2021-09-22 20:15:06 +0200 | <dminuoso> | Guest47: Check the GHC bug tracker |
| 2021-09-22 20:15:15 +0200 | <awpr> | yeah, good point |
| 2021-09-22 20:15:32 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-09-22 20:15:42 +0200 | <Yotta> | dminuoso I'm thinking that if the inputs are "oo" and "foobar", then it's False, but if the next loop then is "oo" and "oobar", then we found position of the "prefix" ? so |
| 2021-09-22 20:15:52 +0200 | nvmd | (~nvmd@user/nvmd) |
| 2021-09-22 20:15:59 +0200 | <Yotta> | if y = "foobar", then tail(y) = "oobar" no? |
| 2021-09-22 20:16:00 +0200 | <dminuoso> | Yotta: No I meant, syntactically, what is that supposed to even mean? |
| 2021-09-22 20:16:14 +0200 | <dminuoso> | Function application has no parens in Haskell |
| 2021-09-22 20:16:16 +0200 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.2) |
| 2021-09-22 20:16:34 +0200 | <Yotta> | Oh right |
| 2021-09-22 20:17:24 +0200 | <dminuoso> | Guest47: Mmm, actually nothing up yet. Irrespective of what the solution is, please file a bug report. A panic is always a bug. |
| 2021-09-22 20:17:49 +0200 | <dminuoso> | That error looks almost like GHC could fail more graciously |
| 2021-09-22 20:17:56 +0200 | <Guest47> | dminuoso thanks dont see anything specifically |
| 2021-09-22 20:18:05 +0200 | yauhsien | (~yauhsien@61-231-35-247.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-09-22 20:18:36 +0200 | <Guest47> | it almost seems like I am missing some dep in OSX but `/usr/bin/iconv` exists and is the same version as my other mac which works fine |
| 2021-09-22 20:18:43 +0200 | <monochrom> | Does tail y always exist? |
| 2021-09-22 20:19:24 +0200 | <geekosaur> | Guest47, it's not an archive though. in fact I'm kinda bewildered by it using loadArchive on it |
| 2021-09-22 20:19:32 +0200 | <geekosaur> | this does smell like a bug |
| 2021-09-22 20:19:51 +0200 | <Yotta> | https://paste.tomsmeding.com/k73xO9F0 |
| 2021-09-22 20:20:03 +0200 | <Guest47> | your right - its just the binary |
| 2021-09-22 20:20:17 +0200 | Yotta | (~Yotta@195.1.199.74) (Quit: Client closed) |
| 2021-09-22 20:20:18 +0200 | <dminuoso> | geekosaur: Do you know what GHC even means by "archive"? |
| 2021-09-22 20:20:27 +0200 | Yotta | (~Yotta@195.1.199.74) |
| 2021-09-22 20:20:31 +0200 | <Guest47> | I assume .a or dylib? |
| 2021-09-22 20:20:36 +0200 | <dminuoso> | Im staring at C code of this, and I cant quite make sense of it |
| 2021-09-22 20:20:50 +0200 | <geekosaur> | I'd expect "archive" to mena a .a |
| 2021-09-22 20:21:03 +0200 | <Guest47> | I can install libiconv with brew and it changes the path of iconv in the error but nothing much else |
| 2021-09-22 20:21:35 +0200 | <dminuoso> | geekosaur: ah indeed! |
| 2021-09-22 20:21:48 +0200 | <dminuoso> | Turns out .a archives start with the "!<arch>" magic header, which is what the C code probes for. |
| 2021-09-22 20:22:11 +0200 | <dminuoso> | Guest47: File a bug report. It's likely the GHC team might have some workaround |
| 2021-09-22 20:22:23 +0200 | <dminuoso> | But this looks really strange |
| 2021-09-22 20:22:24 +0200 | <glguy> | Guest47: What version of GHC? What version of stack? |
| 2021-09-22 20:22:39 +0200 | <Guest47> | (.venv) ❱ stack --version |
| 2021-09-22 20:22:39 +0200 | <Guest47> | Version 2.7.3, Git revision 7927a3aec32e2b2e5e4fb5be76d0d50eddcc197f x86_64 hpack-0.34.4 |
| 2021-09-22 20:22:43 +0200 | <awpr> | Yotta: GHC thinks you want to apply `[]` to that if-expression, because it's just stuck next to the list. you've written the body of another clause without writing the function name and argument patterns |
| 2021-09-22 20:22:54 +0200 | <janus> | dminuoso: haha i thought <arch> was supposed be the actual architecture, but it is that literal string. weird |
| 2021-09-22 20:23:06 +0200 | <glguy> | Guest47: and is it an x86_64 or arm mac? |
| 2021-09-22 20:23:16 +0200 | <monochrom> | "Agh" :) |
| 2021-09-22 20:23:24 +0200 | <Guest47> | x86_64 |
| 2021-09-22 20:23:24 +0200 | <monochrom> | or even, "Argh" |
| 2021-09-22 20:23:47 +0200 | <geekosaur> | nope, short for "archive" |
| 2021-09-22 20:24:07 +0200 | <Guest47> | so far it happens with every version of stack resolvers including nightly |
| 2021-09-22 20:24:12 +0200 | <geekosaur> | while making a 8-byte / 64-bit magic number |
| 2021-09-22 20:24:24 +0200 | <janus> | % file /usr/lib/libdb-4.8.a |
| 2021-09-22 20:24:24 +0200 | <yahb> | janus: ; <interactive>:66:1: error: Variable not in scope: file :: a -> c; <interactive>:66:7: error:; * Variable not in scope: usr :: a -> c; * Perhaps you meant `use' (imported from Control.Lens); <interactive>:66:11: error: Variable not in scope: lib :: a -> c; <interactive>:66:15: error: Variable not in scope: libdb :: a -> c; <interactive>:66:25: error: Variable not in scope: a :: a -> b0 |
| 2021-09-22 20:24:24 +0200 | <janus> | /usr/lib/libdb-4.8.a: current ar archive |
| 2021-09-22 20:24:31 +0200 | <janus> | i wonder what "current" means |
| 2021-09-22 20:24:58 +0200 | <tomsmeding> | janus: you thoroughly confused ghci right there |
| 2021-09-22 20:26:10 +0200 | <janus> | yeah maybe i shouldn't use % in my PS1... i dunno, i just picked my favorite zsh preset.. why didn't they stick with $? |
| 2021-09-22 20:26:20 +0200 | <geekosaur> | janus, archives have had a number of different magic numbers over the years |
| 2021-09-22 20:26:56 +0200 | nvmd | (~nvmd@user/nvmd) (Quit: Later, nerds.) |
| 2021-09-22 20:26:57 +0200 | <geekosaur> | binary codes, then #!ar, then #!<arch> |
| 2021-09-22 20:27:15 +0200 | econo | (uid147250@user/econo) |
| 2021-09-22 20:27:27 +0200 | <janus> | hmm when it was #!ar was it something like a linker script then? |
| 2021-09-22 20:27:36 +0200 | <janus> | never fiddled with linker scripts, don't know if i want to :P |
| 2021-09-22 20:27:54 +0200 | <geekosaur> | I don't thinl the concept of linker scripts existed at that time |
| 2021-09-22 20:28:07 +0200 | <geekosaur> | but linkers were just starting to become more complex |
| 2021-09-22 20:28:23 +0200 | <dminuoso> | geekosaur: Judging from the source code of `fil` "a number" means 2 total. |
| 2021-09-22 20:28:29 +0200 | <geekosaur> | and archoves were starting to change to "nobody uses them for anything but object files" |
| 2021-09-22 20:28:36 +0200 | <dminuoso> | There is `System V Release 1 ar archive` and `current ar archive` |
| 2021-09-22 20:28:42 +0200 | <tomsmeding> | what if we get a new .a file format that supersedes the current one? "new ar archive", and have "current" refer to the old one? :p |
| 2021-09-22 20:29:05 +0200 | <awpr> | `postmodern ar archive` |
| 2021-09-22 20:29:07 +0200 | SawyerBergeron[m | (~sawyerber@2001:470:69fc:105::3036) |
| 2021-09-22 20:29:09 +0200 | <dminuoso> | postcurrent. |
| 2021-09-22 20:29:15 +0200 | <geekosaur> | dminuoso, the binary ones were from V7 unix, I assume file just doesn't care about those |
| 2021-09-22 20:29:23 +0200 | <dminuoso> | Possibly, yeah |
| 2021-09-22 20:29:31 +0200 | <tomsmeding> | blackcurrant ar archive |
| 2021-09-22 20:29:44 +0200 | <awpr> | to catch up with anthropology, it needs to reach the point where "postcurrent" is a few generations back |
| 2021-09-22 20:30:29 +0200 | <tomsmeding> | there _should_ have been a better name than "current" to give to that file format |
| 2021-09-22 20:30:30 +0200 | <dminuoso> | A century from now, the term "current" will mean "back around 2000" |
| 2021-09-22 20:30:31 +0200 | <Guest47> | opened https://gitlab.haskell.org/ghc/ghc/-/issues/20407 |
| 2021-09-22 20:34:59 +0200 | <dminuoso> | Mmm, this probably happens right in template haskell |
| 2021-09-22 20:35:31 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) |
| 2021-09-22 20:35:40 +0200 | koolazer | (~koo@user/koolazer) (Ping timeout: 252 seconds) |
| 2021-09-22 20:36:23 +0200 | <dminuoso> | The number of strange linker bugs Ive had over the years in TH.. |
| 2021-09-22 20:37:53 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 264 seconds) |
| 2021-09-22 20:39:21 +0200 | <janus> | dminuoso: haha kinda like 'modern' in architecture means 1910s and after :P ? |
| 2021-09-22 20:39:49 +0200 | <monochrom> | I thought that was "decca". |
| 2021-09-22 20:40:24 +0200 | <monochrom> | I have a decca style Monopoly set. :) |
| 2021-09-22 20:41:37 +0200 | <janus> | monochrom: i never heard that term, google doesn't seem to helpful. is it an architecture term? or something else? |
| 2021-09-22 20:41:56 +0200 | <shapr> | art deco? |
| 2021-09-22 20:42:14 +0200 | <shapr> | https://en.wikipedia.org/wiki/Art_Deco ? |
| 2021-09-22 20:46:52 +0200 | oxide | (~lambda@user/oxide) (Quit: oxide) |
| 2021-09-22 20:49:23 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-22 20:50:38 +0200 | <monochrom> | Err yeah, deco |
| 2021-09-22 20:51:23 +0200 | <monochrom> | Decca is a music record label. I have had too much classical musical recordings from Decca. :) |
| 2021-09-22 20:52:10 +0200 | <Yotta> | awpr i don't quite understand - i have written `if isPrefix x y == True then `, which part is incorrect? |
| 2021-09-22 20:52:36 +0200 | <awpr> | no part of that is incorrect, it's just in an incorrect contex |
| 2021-09-22 20:52:40 +0200 | <awpr> | context |
| 2021-09-22 20:52:49 +0200 | <Yotta> | aha |
| 2021-09-22 20:52:59 +0200 | <Yotta> | thanks so far btw |
| 2021-09-22 20:53:24 +0200 | <Yotta> | what would be the correct context? |
| 2021-09-22 20:53:27 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-09-22 20:53:46 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-09-22 20:53:48 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 20:53:51 +0200 | allbery_b | geekosaur |
| 2021-09-22 20:54:19 +0200 | <awpr> | it currently looks like either not part of any function definition, or smashed into the previous clause for empty lists |
| 2021-09-22 20:56:06 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-09-22 20:56:09 +0200 | <geekosaur> | also `== True` is completely redundant |
| 2021-09-22 20:56:33 +0200 | <Yotta> | right |
| 2021-09-22 20:56:36 +0200 | <Yotta> | ty |
| 2021-09-22 20:57:27 +0200 | <Yotta> | awpr so i need another line starting with `locate` and then something before if? |
| 2021-09-22 20:58:03 +0200 | kenran | (~kenran@200116b82b5cf400e8fdcfa3687d60f9.dip.versatel-1u1.de) |
| 2021-09-22 20:59:03 +0200 | <awpr> | yep, something to bind/match the parameters |
| 2021-09-22 21:01:48 +0200 | shailangsa | (~shailangs@host86-186-132-44.range86-186.btcentralplus.com) () |
| 2021-09-22 21:02:48 +0200 | kuribas | (~user@188.189.40.222) |
| 2021-09-22 21:03:28 +0200 | <Yotta> | https://paste.tomsmeding.com/t9eSHvZo |
| 2021-09-22 21:03:31 +0200 | <Yotta> | am i getting there? |
| 2021-09-22 21:03:38 +0200 | <Yotta> | or closer at least haha |
| 2021-09-22 21:03:49 +0200 | <Yotta> | (1,2) just placeholders |
| 2021-09-22 21:04:06 +0200 | <awpr> | yeah, that's a step in the right direction |
| 2021-09-22 21:05:29 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 265 seconds) |
| 2021-09-22 21:08:40 +0200 | ub1 | (~Thunderbi@178.115.76.102.wireless.dyn.drei.com) |
| 2021-09-22 21:09:05 +0200 | <Yotta> | Thanks, I fixed the last line to `else locate x(tail y) |
| 2021-09-22 21:09:21 +0200 | ubert | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) (Ping timeout: 265 seconds) |
| 2021-09-22 21:09:22 +0200 | ub1 | ubert |
| 2021-09-22 21:09:46 +0200 | ubert1 | (~Thunderbi@178.115.76.102.wireless.dyn.drei.com) |
| 2021-09-22 21:10:53 +0200 | ub | (~Thunderbi@178.115.37.114.wireless.dyn.drei.com) (Ping timeout: 264 seconds) |
| 2021-09-22 21:12:01 +0200 | sneq | (~user@88.160.31.174) |
| 2021-09-22 21:12:42 +0200 | sneq | (~user@88.160.31.174) () |
| 2021-09-22 21:13:02 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-09-22 21:13:27 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-09-22 21:14:55 +0200 | viluon | (uid453725@id-453725.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-09-22 21:16:05 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 21:16:09 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) |
| 2021-09-22 21:17:15 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:8c9e:15bc:1174:e66f) (Read error: Connection reset by peer) |
| 2021-09-22 21:17:32 +0200 | yinghua | (~yinghua@2800:2121:1400:1db:28cd:b538:6ec9:eacd) |
| 2021-09-22 21:18:49 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-22 21:19:38 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-09-22 21:20:43 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-09-22 21:23:10 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-09-22 21:23:35 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 252 seconds) |
| 2021-09-22 21:25:42 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-09-22 21:25:46 +0200 | nvmd | (~nvmd@user/nvmd) |
| 2021-09-22 21:30:37 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-09-22 21:33:48 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-09-22 21:34:23 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 21:35:06 +0200 | <TDANG> | Hi. From haskell package: https://hackage.haskell.org/package/base-4.15.0.0/docs/src/GHC-List.html#filter |
| 2021-09-22 21:35:17 +0200 | <TDANG> | I found this: |
| 2021-09-22 21:35:28 +0200 | <TDANG> | filter :: (a -> Bool) -> [a] -> [a] |
| 2021-09-22 21:35:30 +0200 | <TDANG> | filter _pred [] = [] |
| 2021-09-22 21:35:31 +0200 | <TDANG> | filter pred (x:xs) |
| 2021-09-22 21:35:33 +0200 | <TDANG> | | pred x = x : filter pred xs |
| 2021-09-22 21:35:34 +0200 | <TDANG> | | otherwise = filter pred xs |
| 2021-09-22 21:36:43 +0200 | <[exa]> | TDANG: hi! please use pastebin to paste more than 1 or 2 lines of code. It's okay now I guess but people get frowny when there's traffic and people start pasting around |
| 2021-09-22 21:37:05 +0200 | <[exa]> | anyways yeah that's the standard `filter` |
| 2021-09-22 21:37:26 +0200 | <TDANG> | I don't know if this is Guards or not. |
| 2021-09-22 21:37:36 +0200 | <monochrom> | It is. |
| 2021-09-22 21:37:50 +0200 | <[exa]> | yep |
| 2021-09-22 21:38:03 +0200 | <TDANG> | As far as I know, Guards should come with condition |
| 2021-09-22 21:38:32 +0200 | <monochrom> | "pred x" is a condition. "otherwise" is a condition. |
| 2021-09-22 21:38:35 +0200 | <[exa]> | it's kinda combined, you've got 2 definitions of `filter` that are distinguished by pattern matching, and the second one has 2 guards, first condition is `pred x`, the second one is `otherwise` |
| 2021-09-22 21:39:12 +0200 | <awpr> | > otherwise |
| 2021-09-22 21:39:13 +0200 | <lambdabot> | True |
| 2021-09-22 21:39:29 +0200 | <[exa]> | `pred x` returns Bool so it's technically a condition, and you see the `otherwise` there ^ :] |
| 2021-09-22 21:40:36 +0200 | <monochrom> | This is a nitpick but I don't see what could possibly be a line between "a condition" and "technically a condition but morally not". |
| 2021-09-22 21:41:14 +0200 | <monochrom> | If the line is "if I see < or >= then it's morally a condition else morally not" that's dumb. |
| 2021-09-22 21:41:25 +0200 | TDANG__ | (~TDANG@inet-177-7.ets.org) |
| 2021-09-22 21:41:54 +0200 | <monochrom> | Even if C you would write "if (func(x,y)) { ..." all the time. |
| 2021-09-22 21:41:55 +0200 | <TDANG__> | Does first condition mean : If "pred x" is True |
| 2021-09-22 21:42:02 +0200 | <monochrom> | Yes. |
| 2021-09-22 21:42:17 +0200 | <TDANG__> | Oh, I got you. Cool. Thanks a lot |
| 2021-09-22 21:42:39 +0200 | zardoz | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/) |
| 2021-09-22 21:42:50 +0200 | <[exa]> | :] |
| 2021-09-22 21:43:11 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) (Ping timeout: 265 seconds) |
| 2021-09-22 21:43:31 +0200 | <TDANG__> | So, I can rewrite 1st condition like this |
| 2021-09-22 21:43:47 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-09-22 21:43:57 +0200 | <TDANG__> | | pred x == True = x : filter pred xs |
| 2021-09-22 21:44:02 +0200 | <[exa]> | yes, precisely |
| 2021-09-22 21:44:24 +0200 | <monochrom> | Sure, but I don't understand the obsession with "== True". |
| 2021-09-22 21:44:26 +0200 | <TDANG__> | thanks |
| 2021-09-22 21:44:41 +0200 | <monochrom> | Do you write "if (func(x,y) == true)" in C? |
| 2021-09-22 21:44:42 +0200 | <awpr> | could also rewrite it like `| (pred x == True) == (not (not (True == True)))` |
| 2021-09-22 21:45:17 +0200 | <TDANG__> | because, condition mean evaludate expression with True |
| 2021-09-22 21:45:23 +0200 | <monochrom> | Do you say "if my computer works tomorrow is true, I can email you tomorrow is true" to people? |
| 2021-09-22 21:45:53 +0200 | <[exa]> | TDANG__: yep, you may imagine the language does the "==True" thing internally already, so writing it again doesn't make much sense |
| 2021-09-22 21:46:18 +0200 | <awpr> | the guard syntax already (colloquially) means "if <the expression> evaluates to True, pick this clause" |
| 2021-09-22 21:46:20 +0200 | <TDANG__> | ya, just to better understand |
| 2021-09-22 21:46:33 +0200 | <TDANG__> | ya, I see. Thanks |
| 2021-09-22 21:46:52 +0200 | <monochrom> | So this goes back to "I insist to see a comparison operator in the middle". |
| 2021-09-22 21:47:19 +0200 | <[exa]> | there's a strong push to avoid comparison and various other operations on Bools, preferably not even storing them, due to various logical problems that often arise from that |
| 2021-09-22 21:48:43 +0200 | <awpr> | this actually tripped me up in the opposite direction trying to write some bash: `if [[ $? ]]` does not do what I wanted |
| 2021-09-22 21:49:05 +0200 | <[exa]> | which is only topped by the effort of #haskell to eliminate all redundat code. |
| 2021-09-22 21:49:46 +0200 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) (Quit: benchmarking) |
| 2021-09-22 21:50:05 +0200 | <[exa]> | awpr: `test -z $?` ? |
| 2021-09-22 21:50:11 +0200 | <monochrom> | I don't so much worry about longer, more redundant code. |
| 2021-09-22 21:50:47 +0200 | <monochrom> | But liberating yourself from "a boolean must compare two things" makes you a better, more sophisticated thinker. |
| 2021-09-22 21:50:55 +0200 | <[exa]> | true ^ |
| 2021-09-22 21:51:13 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 21:51:15 +0200 | <monochrom> | Is 'x' a letter? Just yes or no. Nothing to compare. |
| 2021-09-22 21:51:23 +0200 | <janus> | [exa]: what would Bool-averse haskeller use instead of the 'filter' function? or are bools only bad if they get names? |
| 2021-09-22 21:51:31 +0200 | ubert1 | (~Thunderbi@178.115.76.102.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-09-22 21:52:22 +0200 | ubert | (~Thunderbi@178.115.76.102.wireless.dyn.drei.com) (Ping timeout: 265 seconds) |
| 2021-09-22 21:52:55 +0200 | <janus> | i dunno, i understand that haskellers tend towards "correct by construction" and somehow Bools are too general purpose to be used in that spirit, is that true? |
| 2021-09-22 21:53:04 +0200 | <monochrom> | I don't think Haskellers are bool-averse. |
| 2021-09-22 21:53:19 +0200 | <monochrom> | I think they are bool-overuse-averse instead. |
| 2021-09-22 21:53:43 +0200 | <janus> | ok, but it is only overuse because it is so easy to make sum types and derive Eq for them, right? |
| 2021-09-22 21:53:43 +0200 | <[exa]> | janus: not necessarily, if you are talking about e.g. raw propositional logic values. Otherwise the bools have semantics that doesn't really match True/False naming very well, such as "Matches/Fails" or "Found/NotFound" etc, and usually there's a lot of other information you'd put into the type |
| 2021-09-22 21:53:47 +0200 | <monochrom> | For example "filter xs = if null xs then ... else ... head ... tail..." would be the one Haskellers object to. |
| 2021-09-22 21:53:56 +0200 | <[exa]> | and there's the nice boolean blindness post |
| 2021-09-22 21:54:19 +0200 | <monochrom> | But "filter (x:xs) = if pred x then ... else ..." is cool. |
| 2021-09-22 21:54:47 +0200 | <[exa]> | kinda wondering why it's implemented with guards in Base then |
| 2021-09-22 21:54:55 +0200 | <monochrom> | Give booleans what belongs to booleans, give patterns what belongs to patterns. |
| 2021-09-22 21:55:01 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 21:55:01 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 21:55:01 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 21:55:08 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-09-22 21:55:19 +0200 | <janus> | right, i know booleans are the most problematic. but it just seems a bit arbitrary to draw the line at bools. if nats were easier to use in haskell, would people have the same aversion toward Ints? |
| 2021-09-22 21:55:23 +0200 | <TDANG__> | ;-) |
| 2021-09-22 21:55:39 +0200 | <geekosaur> | janus, some people do |
| 2021-09-22 21:55:55 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-09-22 21:55:59 +0200 | <geekosaur> | and regularly complain about e.g. length producing Int |
| 2021-09-22 21:56:17 +0200 | <monochrom> | We are also string-overuse-averse. We just don't have a chance to talk about it. No beginner comes from tcl backgrounds. |
| 2021-09-22 21:56:50 +0200 | <[exa]> | eyebrow raised |
| 2021-09-22 21:57:16 +0200 | <geekosaur> | there does seem to be a certain amount of overlap with Perlers though |
| 2021-09-22 21:57:28 +0200 | <monochrom> | And by string I don't just mean [Char], it could be Text too. |
| 2021-09-22 21:58:32 +0200 | <janus> | sure, tcl probably doesn't have a linked list for its strings since they are everywhere there |
| 2021-09-22 21:58:37 +0200 | <monochrom> | Right? We have PHP friends who convert our 'data X = A | B | C' to 3 strings, "A", "B", "C". |
| 2021-09-22 21:59:02 +0200 | <janus> | right right, i sympathize, and it is great that people pick battles they can win |
| 2021-09-22 21:59:13 +0200 | <janus> | would be depressing to see the same amount of Nat-zealotry ;) |
| 2021-09-22 21:59:33 +0200 | kenran | (~kenran@200116b82b5cf400e8fdcfa3687d60f9.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2021-09-22 22:01:11 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Quit: m5zs7k) |
| 2021-09-22 22:01:37 +0200 | favonia | (~favonia@user/favonia) |
| 2021-09-22 22:01:41 +0200 | deejaytee | (~deejaytee@vpn-fn-228.net.ed.ac.uk) |
| 2021-09-22 22:01:54 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) (Remote host closed the connection) |
| 2021-09-22 22:02:38 +0200 | kuribas | (~user@188.189.40.222) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-09-22 22:03:11 +0200 | n3t | (n3t@s45.mydevil.net) (Ping timeout: 252 seconds) |
| 2021-09-22 22:06:34 +0200 | <monochrom> | Our integer-overuse-averseness is already shown in "compare x y" giving you LT, GT, EQ, not "an integer that could be 0, positive, negative". |
| 2021-09-22 22:07:14 +0200 | <monochrom> | There are already Scalaers who criticize Scala for that. "We were in a position to fix this! But we didn't!" |
| 2021-09-22 22:08:45 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) |
| 2021-09-22 22:09:56 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2021-09-22 22:10:59 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-09-22 22:10:59 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-09-22 22:10:59 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2021-09-22 22:14:37 +0200 | <deejaytee> | Does anyone know of a library that derives an "index datatype" for any simple container datatype? e.g. if I were to write `data XYZ a = X Int | Y a a | Z a` it could derive `data XYZIdx = XIdx Void | YIdx Bool | ZIdx`, and a corresponding `lookup :: XYZ a -> XYZIdx -> Maybe a`, and ideally maybe even `attachIndices :: XYZ a -> XYZ (XYZIdx, a)`. |
| 2021-09-22 22:14:43 +0200 | <deejaytee> | I've seen `keys` and `Representable`, but both get hung up on sum types when all I need is straightforward "failing lookup" |
| 2021-09-22 22:15:01 +0200 | yauhsien | (~yauhsien@61-231-35-247.dynamic-ip.hinet.net) |
| 2021-09-22 22:15:17 +0200 | mikoto-chan | (~mikoto-ch@ip-83-134-2-136.dsl.scarlet.be) (Ping timeout: 252 seconds) |
| 2021-09-22 22:16:19 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) |
| 2021-09-22 22:16:35 +0200 | nfd | (~nfd@user/nfd) (Ping timeout: 246 seconds) |
| 2021-09-22 22:17:14 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-09-22 22:17:23 +0200 | neurocyte013 | (~neurocyte@user/neurocyte) (Quit: The Lounge - https://thelounge.chat) |
| 2021-09-22 22:17:39 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-09-22 22:17:42 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-09-22 22:17:57 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-09-22 22:17:58 +0200 | TDANG__ | (~TDANG@inet-177-7.ets.org) (Ping timeout: 252 seconds) |
| 2021-09-22 22:18:39 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) (Remote host closed the connection) |
| 2021-09-22 22:18:59 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2021-09-22 22:19:34 +0200 | yauhsien | (~yauhsien@61-231-35-247.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-09-22 22:20:03 +0200 | n3t | (n3t@s45.mydevil.net) |
| 2021-09-22 22:20:56 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) (Remote host closed the connection) |
| 2021-09-22 22:22:11 +0200 | chomwitt | (~chomwitt@ppp-94-67-1-143.home.otenet.gr) (Ping timeout: 246 seconds) |
| 2021-09-22 22:22:35 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) |
| 2021-09-22 22:23:35 +0200 | shailangsa | (~shailangs@host86-186-132-44.range86-186.btcentralplus.com) |
| 2021-09-22 22:31:53 +0200 | jstolarek | (~jstolarek@erx128.neoplus.adsl.tpnet.pl) (Ping timeout: 264 seconds) |
| 2021-09-22 22:32:29 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) (Remote host closed the connection) |
| 2021-09-22 22:34:11 +0200 | Cajun | (~Cajun@user/cajun) |
| 2021-09-22 22:35:29 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-09-22 22:38:45 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) |
| 2021-09-22 22:38:56 +0200 | ulvarrefr | (~user@185.24.53.152) (Remote host closed the connection) |
| 2021-09-22 22:39:34 +0200 | tfeb | (~tfb@88.98.95.237) |
| 2021-09-22 22:40:24 +0200 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-09-22 22:40:28 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) (Ping timeout: 252 seconds) |
| 2021-09-22 22:43:17 +0200 | deejaytee | (~deejaytee@vpn-fn-228.net.ed.ac.uk) (Ping timeout: 264 seconds) |
| 2021-09-22 22:46:17 +0200 | Null_A | (~null_a@2601:645:8700:2290:2108:e73c:fa5c:78e) (Ping timeout: 264 seconds) |
| 2021-09-22 22:47:01 +0200 | <jle`> | deejaytee: that sounds a lot like what the lens deriving mechanisms give you, just without a concrete data type |
| 2021-09-22 22:47:12 +0200 | <jle`> | aw they left :( |
| 2021-09-22 22:47:29 +0200 | <jle`> | hm, actually it doesn't give you that attachIndices |
| 2021-09-22 22:48:13 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-09-22 22:48:31 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-09-22 22:51:28 +0200 | TDANG | (~TDANG@inet-177-7.ets.org) (Ping timeout: 252 seconds) |
| 2021-09-22 22:51:54 +0200 | TDANG_ | (~TDANG@inet-177-7.ets.org) |
| 2021-09-22 22:52:36 +0200 | ulvarrefr | (~user@185.24.53.152) |
| 2021-09-22 22:53:29 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-09-22 22:53:55 +0200 | Null_A_ | (~null_a@2601:645:8700:2290:a969:7066:ab00:d0f1) |
| 2021-09-22 22:55:20 +0200 | <jle`> | would be neat tho |
| 2021-09-22 22:56:03 +0200 | dut | (~dut@user/dut) (Quit: Leaving) |
| 2021-09-22 22:56:10 +0200 | <jle`> | you could probably do something using generics-sop or generic-lens-core |
| 2021-09-22 22:56:11 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-09-22 22:56:55 +0200 | tfeb | (~tfb@88.98.95.237) (Quit: died) |
| 2021-09-22 22:59:59 +0200 | Null_A_ | (~null_a@2601:645:8700:2290:a969:7066:ab00:d0f1) (Ping timeout: 246 seconds) |
| 2021-09-22 23:00:43 +0200 | terrorjack | (~terrorjac@ec2-54-95-39-30.ap-northeast-1.compute.amazonaws.com) (Remote host closed the connection) |
| 2021-09-22 23:01:40 +0200 | terrorjack | (~terrorjac@ec2-54-95-39-30.ap-northeast-1.compute.amazonaws.com) |
| 2021-09-22 23:03:03 +0200 | Guest47 | (~Guest47@rrcs-98-6-18-130.sw.biz.rr.com) (Quit: Client closed) |
| 2021-09-22 23:04:50 +0200 | Yotta | (~Yotta@195.1.199.74) (Quit: Client closed) |
| 2021-09-22 23:05:11 +0200 | fendor | (~fendor@91.141.44.67.wireless.dyn.drei.com) (Quit: Leaving) |
| 2021-09-22 23:07:49 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-09-22 23:07:52 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1c28:7782:3d08:8ee5) |
| 2021-09-22 23:08:55 +0200 | chris | (~chris@81.96.113.213) |
| 2021-09-22 23:08:59 +0200 | chris | Guest8325 |
| 2021-09-22 23:09:05 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2021-09-22 23:09:52 +0200 | raoul | (~raoul@95.179.203.88) (Quit: The Lounge - https://thelounge.chat) |
| 2021-09-22 23:10:28 +0200 | raoul | (~raoul@95.179.203.88) |
| 2021-09-22 23:10:35 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2021-09-22 23:12:47 +0200 | nandomartinez | (~nandomart@125.red-79-152-207.dynamicip.rima-tde.net) |
| 2021-09-22 23:12:48 +0200 | Null_A | (~null_a@2601:645:8700:2290:2cad:b1e0:101a:8137) |
| 2021-09-22 23:12:54 +0200 | <nandomartinez> | hi |
| 2021-09-22 23:13:06 +0200 | <nandomartinez> | does anyone know how to install haskell? |
| 2021-09-22 23:13:16 +0200 | <maerwald> | nandomartinez: https://www.haskell.org/ghcup/ |
| 2021-09-22 23:13:44 +0200 | <nandomartinez> | i put the link on the terminal and the software got intsalled but now i dont know what to do |
| 2021-09-22 23:14:21 +0200 | <nandomartinez> | on mac os i mean |
| 2021-09-22 23:14:31 +0200 | <maerwald> | did you do what it says at then end? |
| 2021-09-22 23:14:44 +0200 | <nandomartinez> | it didnt say anything |
| 2021-09-22 23:14:48 +0200 | <nandomartinez> | it just said |
| 2021-09-22 23:14:56 +0200 | <nandomartinez> | the software is installed |
| 2021-09-22 23:15:05 +0200 | <maerwald> | no, it says more than that |
| 2021-09-22 23:15:19 +0200 | <nandomartinez> | i didnt see it :( |
| 2021-09-22 23:15:26 +0200 | <nandomartinez> | what does it say? |
| 2021-09-22 23:15:38 +0200 | pavonia | (~user@user/siracusa) |
| 2021-09-22 23:15:47 +0200 | <nandomartinez> | and thank you btw |
| 2021-09-22 23:15:59 +0200 | <maerwald> | https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/scripts/bootstrap/bootstrap-haskell#L407 |
| 2021-09-22 23:16:18 +0200 | <maerwald> | source ~/.ghcup/env |
| 2021-09-22 23:16:47 +0200 | <nandomartinez> | thank you so muchj |
| 2021-09-22 23:16:49 +0200 | <nandomartinez> | much |
| 2021-09-22 23:17:37 +0200 | Brumaire | (~quassel@81-64-14-121.rev.numericable.fr) |
| 2021-09-22 23:19:22 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 265 seconds) |
| 2021-09-22 23:19:47 +0200 | acidjnk | (~acidjnk@p200300d0c703cb65087a628f3300f5c4.dip0.t-ipconnect.de) |
| 2021-09-22 23:19:56 +0200 | Null_A | (~null_a@2601:645:8700:2290:2cad:b1e0:101a:8137) (Remote host closed the connection) |
| 2021-09-22 23:20:10 +0200 | Null_A | (~null_a@2601:645:8700:2290:2cad:b1e0:101a:8137) |
| 2021-09-22 23:21:07 +0200 | nandomartinez | (~nandomart@125.red-79-152-207.dynamicip.rima-tde.net) (Quit: Connection closed) |
| 2021-09-22 23:22:16 +0200 | wonko | (~wjc@62.115.229.50) (Ping timeout: 252 seconds) |
| 2021-09-22 23:24:41 +0200 | flouflou | (~flouflou@modemcable032.110-177-173.mc.videotron.ca) (Quit: WeeChat 3.2) |
| 2021-09-22 23:24:42 +0200 | khanred | (~khanred@user/khanred) |
| 2021-09-22 23:25:04 +0200 | nfd | (~nfd@user/nfd) |
| 2021-09-22 23:26:56 +0200 | Null_A | (~null_a@2601:645:8700:2290:2cad:b1e0:101a:8137) (Ping timeout: 246 seconds) |
| 2021-09-22 23:28:41 +0200 | Null_A | (~null_a@2601:645:8700:2290:dc8f:40ba:7f6f:b65c) |
| 2021-09-22 23:31:55 +0200 | deejaytee | (~deejaytee@vpn-fn-228.net.ed.ac.uk) |
| 2021-09-22 23:37:32 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Read error: Connection reset by peer) |
| 2021-09-22 23:39:17 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-09-22 23:45:07 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-09-22 23:51:48 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-09-22 23:52:52 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-09-22 23:54:22 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-09-22 23:58:14 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |