| 2021-11-01 00:01:01 +0100 | <Axman6> | good lord, what happened there? |
| 2021-11-01 00:01:35 +0100 | <Hecate> | I honestly stopped reading |
| 2021-11-01 00:01:39 +0100 | <Hecate> | how are doing Axman6 btw? |
| 2021-11-01 00:02:51 +0100 | <Axman6> | It is a beautiful day, I am doing well |
| 2021-11-01 00:03:53 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-11-01 00:03:58 +0100 | geekosaur | was at one point wondering if what they really wanted was a comonadic structure of some variety |
| 2021-11-01 00:04:07 +0100 | <geekosaur> | but it was so hard to tell… |
| 2021-11-01 00:04:40 +0100 | <Rembane_> | I was hoping that they could implement everything just using plain functions but I didn't understand what they wanted. |
| 2021-11-01 00:04:59 +0100 | awpr | is proud of successfully staying out of it |
| 2021-11-01 00:05:15 +0100 | <hololeap> | it doesn't sound like there was any concrete problem they were trying to solve, just some vague idea that they wanted us to piece together. |
| 2021-11-01 00:05:31 +0100 | <awpr> | also couldn't tell what was going on, too much of a terminology barrier and too unfocused |
| 2021-11-01 00:05:42 +0100 | <hpc> | definitely unfocused |
| 2021-11-01 00:05:47 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 00:05:55 +0100 | <hololeap> | that person has been on here in the past, asking those kinds of super vague super abstract questions, under different names |
| 2021-11-01 00:06:10 +0100 | <monochrom> | software defined {lens, radio, network, socket} |
| 2021-11-01 00:06:22 +0100 | <Axman6> | All I saw was a sea of green from one person and decided I didn't want to read it |
| 2021-11-01 00:06:40 +0100 | <Axman6> | SDS< software defined software |
| 2021-11-01 00:06:43 +0100 | <Axman6> | ,* |
| 2021-11-01 00:06:46 +0100 | <monochrom> | What were some of their previous names? |
| 2021-11-01 00:06:52 +0100 | <hololeap> | fog |
| 2021-11-01 00:06:58 +0100 | <monochrom> | Oh, that. Bannable. |
| 2021-11-01 00:07:00 +0100 | <Axman6> | ah yes |
| 2021-11-01 00:07:05 +0100 | <Axman6> | an apt name |
| 2021-11-01 00:07:06 +0100 | <hololeap> | that's the only one I remember |
| 2021-11-01 00:07:11 +0100 | <awpr> | I had a flashback triggered by the github URL |
| 2021-11-01 00:07:13 +0100 | <hololeap> | lol, yes it is |
| 2021-11-01 00:07:21 +0100 | <Rembane_> | Dang! Was that fog?! |
| 2021-11-01 00:07:26 +0100 | <hpc> | yep |
| 2021-11-01 00:07:33 +0100 | DNH | (~DNH@8.43.122.53) (Quit: Textual IRC Client: www.textualapp.com) |
| 2021-11-01 00:07:36 +0100 | <Rembane_> | I was so easily fooled! |
| 2021-11-01 00:07:53 +0100 | <Axman6> | ah HA,you fool! |
| 2021-11-01 00:09:04 +0100 | <monochrom> | lenses focus, fog unfocuses. That's the definition of unfocused. >:) |
| 2021-11-01 00:11:25 +0100 | <hololeap> | the arrogant attitude was the cherry on top |
| 2021-11-01 00:11:56 +0100 | <Rembane_> | So good |
| 2021-11-01 00:12:05 +0100 | <Rembane_> | Axman6: I am the foolest of fools! |
| 2021-11-01 00:13:19 +0100 | geekosaur | should have kickbanned at [31 21:50:56] <dartford> and then your like "dude, i cant follow, spoonfeed us" |
| 2021-11-01 00:15:02 +0100 | <geekosaur> | but I'd said my piece and was working on dinner and only half following at that point |
| 2021-11-01 00:15:02 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-11-01 00:15:22 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-11-01 00:16:54 +0100 | proboscis | (~proboscis@14.137.28.197) |
| 2021-11-01 00:18:02 +0100 | max22- | (~maxime@2a01cb0883359800143d8394a75c565e.ipv6.abo.wanadoo.fr) (Quit: Leaving) |
| 2021-11-01 00:21:57 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-11-01 00:23:47 +0100 | proboscis | (~proboscis@14.137.28.197) (Ping timeout: 264 seconds) |
| 2021-11-01 00:23:47 +0100 | johnjay | (~pi@192.142.100.50) (Ping timeout: 264 seconds) |
| 2021-11-01 00:25:58 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-11-01 00:25:59 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-11-01 00:25:59 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2021-11-01 00:37:34 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-11-01 00:43:22 +0100 | johnjay | (~pi@192.142.100.50) |
| 2021-11-01 00:48:18 +0100 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 2021-11-01 00:48:43 +0100 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2021-11-01 00:57:14 +0100 | proboscis | (~proboscis@14.137.28.197) |
| 2021-11-01 01:00:02 +0100 | zopsi | (zopsi@2600:3c00::f03c:91ff:fe14:551f) (Quit: Oops) |
| 2021-11-01 01:01:02 +0100 | zopsi | (~zopsi@irc.dir.ac) |
| 2021-11-01 01:03:33 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2021-11-01 01:04:39 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-11-01 01:09:50 +0100 | proboscis | (~proboscis@14.137.28.197) (Ping timeout: 260 seconds) |
| 2021-11-01 01:15:28 +0100 | CannabisIndica | (~herb@user/mesaboogie) (Quit: ZNC - https://znc.in) |
| 2021-11-01 01:15:58 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Remote host closed the connection) |
| 2021-11-01 01:17:08 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-11-01 01:17:10 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:9d95:c71:11e4:3e0f) |
| 2021-11-01 01:18:43 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-11-01 01:20:39 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-11-01 01:21:30 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2021-11-01 01:21:55 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2021-11-01 01:26:10 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 01:30:50 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 260 seconds) |
| 2021-11-01 01:30:59 +0100 | acidjnk | (~acidjnk@p5487d843.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2021-11-01 01:40:34 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2021-11-01 01:42:34 +0100 | <janus> | is it allowed to to make a Haskell Wiki article on fog? or would it worsen the problem? hmmm |
| 2021-11-01 01:45:09 +0100 | <monochrom> | I don't think the readership would be interested in IRC drama :) |
| 2021-11-01 01:46:00 +0100 | <sm> | not a good idea |
| 2021-11-01 01:48:47 +0100 | <janus> | sm: did you upgrade to Monterey? does it work? |
| 2021-11-01 01:49:21 +0100 | <Nachtgespenst> | What was the drama about fog? |
| 2021-11-01 01:49:31 +0100 | <sm> | not yet janus. shapr reports no problems |
| 2021-11-01 01:49:41 +0100 | <sm> | there wasn't any |
| 2021-11-01 01:51:31 +0100 | <shapr> | eh? |
| 2021-11-01 01:51:36 +0100 | <Axman6> | Did Apple manage to make a major release which _didn't_ break GHC? That's impressive! |
| 2021-11-01 01:52:19 +0100 | <shapr> | although today my laptop kernel panicked twice, and I wasn't compiling |
| 2021-11-01 01:53:40 +0100 | CannibisIndica | (~herb@user/mesaboogie) |
| 2021-11-01 01:55:25 +0100 | shailangsa | (~shailangs@host217-39-45-200.range217-39.btcentralplus.com) (Remote host closed the connection) |
| 2021-11-01 01:56:47 +0100 | CannibisIndica | (~herb@user/mesaboogie) (Client Quit) |
| 2021-11-01 01:57:13 +0100 | CannabisIndica | (~herb@user/mesaboogie) |
| 2021-11-01 01:57:26 +0100 | <shapr> | Axman6: I think it broke everything else |
| 2021-11-01 01:57:34 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-11-01 01:57:34 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-11-01 01:57:34 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2021-11-01 02:02:11 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2021-11-01 02:05:01 +0100 | xlei | (znc@pool-68-129-84-118.nycmny.fios.verizon.net) (Quit: ZNC - https://znc.in) |
| 2021-11-01 02:10:35 +0100 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-11-01 02:12:48 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2021-11-01 02:13:16 +0100 | proboscis | (~proboscis@14.137.28.197) |
| 2021-11-01 02:15:41 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) |
| 2021-11-01 02:15:52 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 02:18:54 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2021-11-01 02:20:02 +0100 | Midjak | (~Midjak@82-65-111-221.subs.proxad.net) (Quit: This computer has gone to sleep) |
| 2021-11-01 02:20:18 +0100 | proboscis | (~proboscis@14.137.28.197) (Ping timeout: 260 seconds) |
| 2021-11-01 02:21:42 +0100 | xlei | (znc@pool-68-129-84-118.nycmny.fios.verizon.net) |
| 2021-11-01 02:22:51 +0100 | peterhil | (~peterhil@dsl-hkibng32-54fb56-2.dhcp.inet.fi) (Quit: Must not waste too much time here...) |
| 2021-11-01 02:23:06 +0100 | <Axman6> | Classic. Definitely waiting for the .1 |
| 2021-11-01 02:25:00 +0100 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Quit: WeeChat 3.3) |
| 2021-11-01 02:25:28 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 02:25:50 +0100 | <geekosaur> | this does not exactly make me regret ditching Apple |
| 2021-11-01 02:26:37 +0100 | xlei | (znc@pool-68-129-84-118.nycmny.fios.verizon.net) (Quit: ZNC - https://znc.in) |
| 2021-11-01 02:27:24 +0100 | proboscis | (~proboscis@115-189-129-241.mobile.spark.co.nz) |
| 2021-11-01 02:29:36 +0100 | xlei | (znc@pool-68-129-84-118.nycmny.fios.verizon.net) |
| 2021-11-01 02:29:53 +0100 | tafama | tafa |
| 2021-11-01 02:30:06 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 02:33:10 +0100 | trillp | (~trillp@69.233.98.238) |
| 2021-11-01 02:38:24 +0100 | <dsal> | shapr: compile more! |
| 2021-11-01 02:40:24 +0100 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) (Ping timeout: 276 seconds) |
| 2021-11-01 02:40:36 +0100 | LiaoTao_ | (~LiaoTao@gateway/tor-sasl/liaotao) |
| 2021-11-01 02:41:07 +0100 | <Cajun> | does apple seriously kernel panic that often? if so im shocked |
| 2021-11-01 02:44:06 +0100 | proboscis | (~proboscis@115-189-129-241.mobile.spark.co.nz) (Ping timeout: 260 seconds) |
| 2021-11-01 02:44:53 +0100 | hololeap | (~hololeap@user/hololeap) (Remote host closed the connection) |
| 2021-11-01 02:46:21 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2021-11-01 02:47:06 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2021-11-01 02:49:28 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-11-01 02:50:33 +0100 | <Axman6> | It's been a couple of years since I've had one, but they tend to crop up occasionally with new major OS releases, when they do things like rrqrite their whole graphics framework or security stuff you'd somewhat expect that to happen sometimes |
| 2021-11-01 02:51:00 +0100 | <dsal> | I've had a couple, but I'm running new hardware and all the bleeding edge stuff I can get. |
| 2021-11-01 02:51:12 +0100 | <dsal> | And much of the software I'm running is emulated. |
| 2021-11-01 02:52:35 +0100 | <justsomeguy> | I've had kernel panics on every operating system I've used. (Windows, Linux, FreeBSD, Cisco IOS, Android ...) |
| 2021-11-01 02:53:51 +0100 | mvk | (~mvk@2607:fea8:5cc1:300::d3fb) (Ping timeout: 245 seconds) |
| 2021-11-01 02:55:46 +0100 | <geekosaur> | it's been a decade since I had a linux kernel panic. that said I don't run bleeding edge kernels or weird hardware |
| 2021-11-01 02:56:25 +0100 | catman | (~catman@user/catman) (Read error: Connection reset by peer) |
| 2021-11-01 02:56:39 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Remote host closed the connection) |
| 2021-11-01 02:57:45 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-11-01 02:58:31 +0100 | <justsomeguy> | My laptop has an ACPI implementation bug. |
| 2021-11-01 02:59:39 +0100 | justsomeguy | really should spend some time investigating it, it's been bugging him for six years, now. |
| 2021-11-01 02:59:53 +0100 | proboscis | (~proboscis@115-189-129-110.mobile.spark.co.nz) |
| 2021-11-01 03:02:40 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2021-11-01 03:03:05 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-11-01 03:03:20 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-11-01 03:06:46 +0100 | frobnicator | (~frobnicat@185-227-75-147.dsl.cambrium.nl) (Ping timeout: 245 seconds) |
| 2021-11-01 03:09:06 +0100 | catman | (~catman@user/catman) |
| 2021-11-01 03:10:05 +0100 | <Axman6> | the one that surprises me least is Cisco IOS |
| 2021-11-01 03:10:33 +0100 | n3t | (n3t@user/n3t) (Read error: Connection reset by peer) |
| 2021-11-01 03:12:31 +0100 | m5zs7k | (aquares@web10.mydevil.net) (Quit: m5zs7k) |
| 2021-11-01 03:12:46 +0100 | n3t | (~n3t@s45.mydevil.net) |
| 2021-11-01 03:14:22 +0100 | m5zs7k | (aquares@web10.mydevil.net) |
| 2021-11-01 03:15:06 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 03:18:27 +0100 | nrl^ | (~nrl@wsip-98-188-242-6.mc.at.cox.net) (Remote host closed the connection) |
| 2021-11-01 03:19:30 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 260 seconds) |
| 2021-11-01 03:19:42 +0100 | mvk | (~mvk@2607:fea8:5cc1:300::d3fb) |
| 2021-11-01 03:23:28 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2021-11-01 03:45:05 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2021-11-01 03:47:44 +0100 | mvk | (~mvk@2607:fea8:5cc1:300::d3fb) (Quit: Konversation terminated!) |
| 2021-11-01 03:50:15 +0100 | n3t | (~n3t@s45.mydevil.net) (Changing host) |
| 2021-11-01 03:50:15 +0100 | n3t | (~n3t@user/n3t) |
| 2021-11-01 03:50:47 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:9d95:c71:11e4:3e0f) (Ping timeout: 264 seconds) |
| 2021-11-01 03:51:59 +0100 | xff0x | (~xff0x@2001:1a81:5344:9700:97c:3a82:54b0:a6da) (Ping timeout: 264 seconds) |
| 2021-11-01 03:53:33 +0100 | xff0x | (~xff0x@2001:1a81:537f:9c00:f676:7afa:ede:1e04) |
| 2021-11-01 04:02:11 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Ping timeout: 264 seconds) |
| 2021-11-01 04:05:38 +0100 | fef | (~thedawn@user/thedawn) |
| 2021-11-01 04:05:50 +0100 | lemonsnicks | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-11-01 04:13:03 +0100 | mbuf | (~Shakthi@122.174.251.211) |
| 2021-11-01 04:16:40 +0100 | lemonsnicks | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) |
| 2021-11-01 04:16:41 +0100 | proboscis | (~proboscis@115-189-129-110.mobile.spark.co.nz) (Read error: Connection reset by peer) |
| 2021-11-01 04:17:16 +0100 | proboscis | (~proboscis@115-189-129-110.mobile.spark.co.nz) |
| 2021-11-01 04:24:04 +0100 | desophos | (~desophos@2601:249:1680:a570:b44c:753b:291d:308f) |
| 2021-11-01 04:24:57 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 04:25:08 +0100 | desophos | (~desophos@2601:249:1680:a570:b44c:753b:291d:308f) (Client Quit) |
| 2021-11-01 04:26:27 +0100 | catman | (~catman@user/catman) (Read error: Connection reset by peer) |
| 2021-11-01 04:27:59 +0100 | rtypo | (~alex@user/rtypo) |
| 2021-11-01 04:28:01 +0100 | hololeap | (~hololeap@user/hololeap) (Read error: Connection reset by peer) |
| 2021-11-01 04:29:19 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2021-11-01 04:30:02 +0100 | proboscis | (~proboscis@115-189-129-110.mobile.spark.co.nz) (Ping timeout: 260 seconds) |
| 2021-11-01 04:34:21 +0100 | rtypo | (~alex@user/rtypo) (WeeChat 3.3) |
| 2021-11-01 04:37:10 +0100 | alx741 | (~alx741@181.196.69.253) (Quit: alx741) |
| 2021-11-01 04:40:53 +0100 | boxscape_ | (~boxscape_@mue-88-130-59-084.dsl.tropolys.de) |
| 2021-11-01 04:41:53 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-11-01 04:42:13 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-11-01 04:42:13 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-11-01 04:42:13 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2021-11-01 04:43:07 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-11-01 04:46:21 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 245 seconds) |
| 2021-11-01 04:48:30 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-11-01 04:49:02 +0100 | catman | (~catman@user/catman) |
| 2021-11-01 04:57:33 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 05:00:54 +0100 | yauhsien_ | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 05:00:54 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 2021-11-01 05:03:57 +0100 | darkstarx | (~darkstard@2601:1c2:300:c8a0::6c32) (Quit: Leaving) |
| 2021-11-01 05:05:47 +0100 | yauhsien_ | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 264 seconds) |
| 2021-11-01 05:11:47 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-11-01 05:11:56 +0100 | darkstardevx | (~darkstard@2601:1c2:300:c8a0::6c32) |
| 2021-11-01 05:12:26 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2021-11-01 05:13:11 +0100 | img | (~img@user/img) |
| 2021-11-01 05:13:49 +0100 | darkstardevx | (~darkstard@2601:1c2:300:c8a0::6c32) (Remote host closed the connection) |
| 2021-11-01 05:14:14 +0100 | darkstardevx | (~darkstard@2601:1c2:300:c8a0::6c32) |
| 2021-11-01 05:14:46 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 260 seconds) |
| 2021-11-01 05:16:39 +0100 | trillp | (~trillp@69.233.98.238) (Quit: nyaa~) |
| 2021-11-01 05:22:18 +0100 | boxscape_ | (~boxscape_@mue-88-130-59-084.dsl.tropolys.de) (Ping timeout: 260 seconds) |
| 2021-11-01 05:35:03 +0100 | trillp | (~trillp@69.233.98.238) |
| 2021-11-01 05:37:42 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) |
| 2021-11-01 05:42:20 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 05:53:45 +0100 | sprout_ | (~quassel@2a02:a467:ccd6:1:8872:6fff:30a7:51e0) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-11-01 05:53:50 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-11-01 05:54:03 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:8872:6fff:30a7:51e0) |
| 2021-11-01 06:12:32 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-11-01 06:14:26 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-11-01 06:24:20 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 06:29:11 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-11-01 06:29:46 +0100 | cjb72647 | (~cjbayliss@user/cjb) |
| 2021-11-01 06:30:00 +0100 | quazimodo | (~quazimodo@n1-40-235-47.bla1.nsw.optusnet.com.au) |
| 2021-11-01 06:31:16 +0100 | <quazimodo> | if someone was going to write a function called 'compose' to do right to left composition, as an exercise, what would the type look like? |
| 2021-11-01 06:31:32 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 06:31:55 +0100 | <quazimodo> | in typescript we have to do all sorts of finite function type overloads to handle the case for each size of tuple of lambdas |
| 2021-11-01 06:31:58 +0100 | <dibblego> | @type flip (.) |
| 2021-11-01 06:31:59 +0100 | <lambdabot> | (a -> b) -> (b -> c) -> a -> c |
| 2021-11-01 06:32:04 +0100 | cjb | (~cjbayliss@user/cjb) (Ping timeout: 260 seconds) |
| 2021-11-01 06:32:19 +0100 | <quazimodo> | dibblego: what happens when you have 10 of those lambdas? |
| 2021-11-01 06:32:26 +0100 | <dibblego> | wot now? |
| 2021-11-01 06:33:01 +0100 | <quazimodo> | (a -> b) -> (b -> c) -> (c -> d) ... all the way to -> (j -> k) -> a -> k |
| 2021-11-01 06:33:17 +0100 | <dibblego> | @type flip ((.) . (.)) |
| 2021-11-01 06:33:18 +0100 | <lambdabot> | (a1 -> a2 -> b) -> (b -> c) -> a1 -> a2 -> c |
| 2021-11-01 06:33:22 +0100 | <dibblego> | ? |
| 2021-11-01 06:34:05 +0100 | <quazimodo> | @type flip ((.) . (.) . (.)) |
| 2021-11-01 06:34:14 +0100 | <quazimodo> | :( |
| 2021-11-01 06:34:19 +0100 | <quazimodo> | it hates me |
| 2021-11-01 06:34:21 +0100 | <quazimodo> | @type flip ((.) . (.) . (.)) |
| 2021-11-01 06:34:22 +0100 | <lambdabot> | (a1 -> a2 -> a3 -> b) -> (b -> c) -> a1 -> a2 -> a3 -> c |
| 2021-11-01 06:35:03 +0100 | <dibblego> | brb |
| 2021-11-01 06:35:12 +0100 | cjb72647 | (~cjbayliss@user/cjb) () |
| 2021-11-01 06:37:10 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Remote host closed the connection) |
| 2021-11-01 06:38:37 +0100 | Jing | (~textual@103.121.208.115) |
| 2021-11-01 06:40:44 +0100 | <dibblego> | @type f g h -> h . g . f |
| 2021-11-01 06:40:45 +0100 | <lambdabot> | error: parse error on input ‘->’ |
| 2021-11-01 06:40:47 +0100 | <dibblego> | @type \f g h -> h . g . f |
| 2021-11-01 06:40:48 +0100 | <lambdabot> | (a -> b1) -> (b1 -> b2) -> (b2 -> c) -> a -> c |
| 2021-11-01 06:40:52 +0100 | <dibblego> | maybe you mean that |
| 2021-11-01 06:51:00 +0100 | ghoulguy | glguy |
| 2021-11-01 06:54:12 +0100 | retroid_ | (~retro@2e41e9c8.skybroadband.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | infinity0 | (~infinity0@occupy.ecodis.net) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | Unhammer | (~Unhammer@user/unhammer) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | koz | (~koz@2404:4408:430f:a900:ca69:658c:ba89:aa9f) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | riatre | (~quassel@2001:310:6000:f::5198:1) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | Patternmaster | (~georg@li1192-118.members.linode.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | stilgart | (~Christoph@chezlefab.net) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | Arsen | (~arsen@managarm/dev/Arsen) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | hongminhee | (sid295@tinside.irccloud.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | jackdk | (sid373013@cssa/jackdk) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | pjlsergeant | (sid143467@hampstead.irccloud.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | stevenxl | (sid133530@uxbridge.irccloud.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | rubin55 | (sid175221@hampstead.irccloud.com) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | berberman | (~berberman@user/berberman) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | hexology | (~hexology@user/hexology) (*.net *.split) |
| 2021-11-01 06:54:12 +0100 | thonkpod | (~thonkpod@user/thonkpod) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | vgtw | (~vgtw@c-6a60205c.07-348-756d651.bbcust.telenor.se) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | gawen_ | (~gawen@user/gawen) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | energizer | (~energizer@user/energizer) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | Eoco | (~ian@x-160-94-179-157.acm.umn.edu) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | maerwald | (~maerwald@user/maerwald) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | haskl | (~haskl@user/haskl) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | dfg | (dfg@user/dfg) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | greenbourne277 | (~greenbour@2001:4b98:dc2:45:216:3eff:fe8a:bbf0) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | Athas | (athas@sigkill.dk) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | robertm | (robertm@lattice.rojoma.com) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | flukiluke | (~m-7humut@plum.alephc.xyz) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | canta | (~canta@user/canta) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | royo | (~royo@user/royo) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | incertia | (~incertia@d4-50-26-103.nap.wideopenwest.com) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | exarkun | (~exarkun@user/exarkun) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | caubert | (~caubert@136.244.111.235) (*.net *.split) |
| 2021-11-01 06:54:13 +0100 | root1 | (root@2600:3c02::f03c:92ff:fe1a:c779) (*.net *.split) |
| 2021-11-01 06:54:21 +0100 | riatre | (~quassel@2001:310:6000:f::5198:1) |
| 2021-11-01 06:54:21 +0100 | royo | (~royo@user/royo) |
| 2021-11-01 06:54:22 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:ca09:aa6a:e1e8:dce5) |
| 2021-11-01 06:54:24 +0100 | jackdk | (sid373013@cssa/jackdk) |
| 2021-11-01 06:54:25 +0100 | Patternmaster | (~georg@li1192-118.members.linode.com) |
| 2021-11-01 06:54:26 +0100 | stilgart | (~Christoph@chezlefab.net) |
| 2021-11-01 06:54:27 +0100 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2021-11-01 06:54:30 +0100 | rubin55 | (sid175221@id-175221.hampstead.irccloud.com) |
| 2021-11-01 06:54:32 +0100 | koz | (~koz@2404:4408:430f:a900:ca69:658c:ba89:aa9f) |
| 2021-11-01 06:54:33 +0100 | stevenxl | (sid133530@id-133530.uxbridge.irccloud.com) |
| 2021-11-01 06:54:33 +0100 | root1 | (root@2600:3c02::f03c:92ff:fe1a:c779) |
| 2021-11-01 06:54:34 +0100 | canta | (~canta@cvm0.d5k.one) |
| 2021-11-01 06:54:34 +0100 | caubert | (~caubert@136.244.111.235) |
| 2021-11-01 06:54:35 +0100 | hongminhee | (sid295@id-295.tinside.irccloud.com) |
| 2021-11-01 06:54:35 +0100 | pjlsergeant | (sid143467@id-143467.hampstead.irccloud.com) |
| 2021-11-01 06:54:43 +0100 | greenbourne277 | (~greenbour@2001:4b98:dc2:45:216:3eff:fe8a:bbf0) |
| 2021-11-01 06:54:43 +0100 | Eoco | (~ian@x-160-94-179-157.acm.umn.edu) |
| 2021-11-01 06:54:44 +0100 | robertm | (robertm@lattice.rojoma.com) |
| 2021-11-01 06:54:46 +0100 | canta | (~canta@cvm0.d5k.one) (Changing host) |
| 2021-11-01 06:54:46 +0100 | canta | (~canta@user/canta) |
| 2021-11-01 06:54:52 +0100 | Unhammer | (~Unhammer@2a01:799:60:df00::237) |
| 2021-11-01 06:54:52 +0100 | thonkpod | (~thonkpod@2001:19f0:ac01:b46:5400:1ff:fec7:d73d) |
| 2021-11-01 06:54:58 +0100 | Arsen | (~arsen@managarm/dev/Arsen) |
| 2021-11-01 06:55:05 +0100 | Unhammer | (~Unhammer@2a01:799:60:df00::237) (Changing host) |
| 2021-11-01 06:55:05 +0100 | Unhammer | (~Unhammer@user/unhammer) |
| 2021-11-01 06:55:11 +0100 | exarkun | (~exarkun@user/exarkun) |
| 2021-11-01 06:55:14 +0100 | thonkpod | (~thonkpod@2001:19f0:ac01:b46:5400:1ff:fec7:d73d) (Changing host) |
| 2021-11-01 06:55:14 +0100 | thonkpod | (~thonkpod@user/thonkpod) |
| 2021-11-01 06:55:28 +0100 | dfg | (~dfg@li490-89.members.linode.com) |
| 2021-11-01 06:55:31 +0100 | dfg | (~dfg@li490-89.members.linode.com) (Changing host) |
| 2021-11-01 06:55:31 +0100 | dfg | (~dfg@user/dfg) |
| 2021-11-01 06:55:35 +0100 | maerwald | (~maerwald@mail.hasufell.de) |
| 2021-11-01 06:55:42 +0100 | haskl | (~haskl@user/haskl) |
| 2021-11-01 06:55:50 +0100 | incertia | (~incertia@d4-50-26-103.nap.wideopenwest.com) |
| 2021-11-01 06:55:56 +0100 | berberman | (~berberman@user/berberman) |
| 2021-11-01 06:55:57 +0100 | hexology | (~hexology@user/hexology) |
| 2021-11-01 06:55:57 +0100 | gawen | (~gawen@user/gawen) |
| 2021-11-01 06:56:03 +0100 | vgtw | (~vgtw@c-6a60205c.07-348-756d651.bbcust.telenor.se) |
| 2021-11-01 06:56:19 +0100 | rkrishnan | (~user@223.226.59.167) |
| 2021-11-01 06:56:20 +0100 | infinity0 | (~infinity0@occupy.ecodis.net) |
| 2021-11-01 06:56:30 +0100 | energizer | (~energizer@user/energizer) |
| 2021-11-01 06:58:48 +0100 | retroid_ | (~retro@2e41e9c8.skybroadband.com) |
| 2021-11-01 06:59:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2021-11-01 06:59:29 +0100 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) |
| 2021-11-01 06:59:46 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2021-11-01 07:00:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-11-01 07:00:43 +0100 | <dsal> | :t (&) |
| 2021-11-01 07:00:44 +0100 | <lambdabot> | a -> (a -> b) -> b |
| 2021-11-01 07:01:34 +0100 | <dsal> | I don't know why I was thinking that was similar to flip (.) other than being late. heh |
| 2021-11-01 07:01:37 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 07:01:49 +0100 | <dibblego> | @type flip ($) -- you might be thinking of that |
| 2021-11-01 07:01:50 +0100 | <lambdabot> | a -> (a -> c) -> c |
| 2021-11-01 07:02:20 +0100 | <dsal> | I think it's just how . and $ are sometimes interchangeable. |
| 2021-11-01 07:02:50 +0100 | schuelermine[m] | (~schuelerm@user/schuelermine) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | lisq | (~quassel@lis.moe) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | fakehacker[m] | (~fakehacke@2001:470:69fc:105::b5f0) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | surgeon[m] | (~surge9nma@2001:470:69fc:105::f585) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | Morrow[m] | (~morrowmma@2001:470:69fc:105::1d0) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | the-coot[m] | (~the-cootm@2001:470:69fc:105::95f) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | denbrahe[m] | (~denbrahem@2001:470:69fc:105::19c0) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | psydroid | (~psydroid@user/psydroid) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | hugo | (znc@verdigris.lysator.liu.se) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | ddb | (~ddb@ipv6two.tilde.club) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | tito | (tito@tilde.team) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | phaazon | (~phaazon@2001:41d0:a:fe76::1) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | mht | (~mht@2a03:b0c0:3:e0::1e2:c001) (*.net *.split) |
| 2021-11-01 07:02:50 +0100 | meridion | (~meridion@punt.hetgrotebos.org) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | madnight_ | (~madnight@static.59.103.201.195.clients.your-server.de) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | noddy | (~user@user/noddy) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | acro | (~acro@user/acro) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | Ankhers | (~Ankhers@ec2-54-196-233-138.compute-1.amazonaws.com) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | rookie101 | (~rookie@207.154.204.166) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | dunj3 | (~dunj3@kingdread.de) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | dexterfoo | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | aforemny | (~aforemny@static.248.158.34.188.clients.your-server.de) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | dixie | (~dixie@real.wilbury.sk) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | V | (~v@anomalous.eu) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | tired | (~tired@user/tired) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | TimWolla | (~timwolla@2a01:4f8:150:6153:beef::6667) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | janus | (janus@anubis.0x90.dk) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | relrod | (~relrod@redhat/ansible.staff.relrod) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | tristanC | (~tristanC@user/tristanc) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | dfordvm | (~dfordivam@tk2-219-19469.vs.sakura.ne.jp) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | bcoppens | (~bartcopp@vpn2.bartcoppens.be) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | res0nat0r8 | (~Fletch@dia.whatbox.ca) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) (*.net *.split) |
| 2021-11-01 07:02:51 +0100 | cpape | (~user@2a01:4f9:c010:632d::1) (*.net *.split) |
| 2021-11-01 07:02:57 +0100 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) |
| 2021-11-01 07:02:57 +0100 | meridion | (~meridion@punt.hetgrotebos.org) |
| 2021-11-01 07:02:58 +0100 | TimWolla | (~timwolla@2a01:4f8:150:6153:beef::6667) |
| 2021-11-01 07:02:59 +0100 | bcoppens | (~bartcopp@vpn2.bartcoppens.be) |
| 2021-11-01 07:02:59 +0100 | dunj3 | (~dunj3@kingdread.de) |
| 2021-11-01 07:02:59 +0100 | cpape | (~user@2a01:4f9:c010:632d::1) |
| 2021-11-01 07:03:00 +0100 | dixie | (~dixie@real.wilbury.sk) |
| 2021-11-01 07:03:02 +0100 | res0nat0r8 | (~Fletch@dia.whatbox.ca) |
| 2021-11-01 07:03:02 +0100 | tristanC | (~tristanC@163.172.94.116) |
| 2021-11-01 07:03:03 +0100 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) |
| 2021-11-01 07:03:04 +0100 | lisq | (~quassel@lis.moe) |
| 2021-11-01 07:03:05 +0100 | tito | (tito@tilde.team) |
| 2021-11-01 07:03:06 +0100 | janus | (janus@anubis.0x90.dk) |
| 2021-11-01 07:03:06 +0100 | phaazon | (~phaazon@2001:41d0:a:fe76::1) |
| 2021-11-01 07:03:07 +0100 | relrod | (~relrod@redhat/ansible.staff.relrod) |
| 2021-11-01 07:03:15 +0100 | tristanC | (~tristanC@163.172.94.116) (Changing host) |
| 2021-11-01 07:03:15 +0100 | tristanC | (~tristanC@user/tristanc) |
| 2021-11-01 07:03:17 +0100 | dexterfoo | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) |
| 2021-11-01 07:03:17 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) |
| 2021-11-01 07:03:19 +0100 | V | (~v@anomalous.eu) |
| 2021-11-01 07:03:21 +0100 | bastelfreak | (~bastelfre@basteles-bastelknecht.bastelfreak.org) |
| 2021-11-01 07:03:21 +0100 | mht | (~mht@mht.wtf) |
| 2021-11-01 07:03:26 +0100 | ddb | (~ddb@ipv6two.tilde.club) |
| 2021-11-01 07:03:30 +0100 | madnight | (~madnight@static.59.103.201.195.clients.your-server.de) |
| 2021-11-01 07:03:30 +0100 | tired | (~tired@user/tired) |
| 2021-11-01 07:03:31 +0100 | dfordvm | (~dfordivam@tk2-219-19469.vs.sakura.ne.jp) |
| 2021-11-01 07:03:46 +0100 | Ankhers | (~Ankhers@ec2-54-196-233-138.compute-1.amazonaws.com) |
| 2021-11-01 07:03:58 +0100 | rookie101 | (~rookie@207.154.204.166) |
| 2021-11-01 07:05:02 +0100 | hugo | (znc@verdigris.lysator.liu.se) |
| 2021-11-01 07:05:10 +0100 | surgeon[m] | (~surge9nma@2001:470:69fc:105::f585) |
| 2021-11-01 07:05:43 +0100 | <dibblego> | only syntactically |
| 2021-11-01 07:05:48 +0100 | <dibblego> | f $ g $ h |
| 2021-11-01 07:05:50 +0100 | <dibblego> | f $ (g $ h) |
| 2021-11-01 07:05:53 +0100 | <dibblego> | f . g . h |
| 2021-11-01 07:05:56 +0100 | <dibblego> | oops |
| 2021-11-01 07:06:22 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 260 seconds) |
| 2021-11-01 07:06:36 +0100 | acro | (~acro@user/acro) |
| 2021-11-01 07:06:55 +0100 | the-coot[m] | (~the-cootm@2001:470:69fc:105::95f) |
| 2021-11-01 07:06:55 +0100 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) |
| 2021-11-01 07:07:12 +0100 | fakehacker[m] | (~fakehacke@2001:470:69fc:105::b5f0) |
| 2021-11-01 07:07:22 +0100 | schuelermine[m] | (~schuelerm@user/schuelermine) |
| 2021-11-01 07:08:11 +0100 | aforemny | (~aforemny@static.248.158.34.188.clients.your-server.de) |
| 2021-11-01 07:09:17 +0100 | shailangsa | (~shailangs@host217-39-45-200.range217-39.btcentralplus.com) |
| 2021-11-01 07:09:36 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2021-11-01 07:10:54 +0100 | denbrahe[m] | (~denbrahem@2001:470:69fc:105::19c0) |
| 2021-11-01 07:11:05 +0100 | Morrow[m] | (~morrowmma@2001:470:69fc:105::1d0) |
| 2021-11-01 07:11:06 +0100 | psydroid | (~psydroid@user/psydroid) |
| 2021-11-01 07:11:06 +0100 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) |
| 2021-11-01 07:12:12 +0100 | v01d4lph4 | (~v01d4lph4@223.190.95.48) |
| 2021-11-01 07:12:12 +0100 | v01d4lph4 | (~v01d4lph4@223.190.95.48) (Changing host) |
| 2021-11-01 07:12:12 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 07:17:52 +0100 | <jackdk> | quazimodo: is a tuple the best choice here? Can you compose the functions sooner so you're not carrying wide tuples around everywhere? |
| 2021-11-01 07:18:43 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Ping timeout: 268 seconds) |
| 2021-11-01 07:28:49 +0100 | Guest16 | (~Guest16@103.99.84.6) |
| 2021-11-01 07:29:53 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-11-01 07:30:40 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 07:38:01 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-11-01 07:38:27 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-11-01 07:46:28 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-11-01 07:51:26 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 07:51:26 +0100 | <quazimodo> | jackdk: it's more of a mental exercise, I use typescript a lot in our business and it doesn't compose/curry the same way as haskell |
| 2021-11-01 07:51:55 +0100 | <quazimodo> | i suppose in haskell the compose operation operates on pairs, never a big tuple of functions that are passed into a function |
| 2021-11-01 07:52:26 +0100 | <dibblego> | nah, compose in haskell operates on functions, and all functions in haskell take exactly one argument |
| 2021-11-01 07:53:30 +0100 | <quazimodo> | the people who came up with this stuff are arcane wizards honestly |
| 2021-11-01 07:54:12 +0100 | Lycurgus | (~juan@98.4.112.204) |
| 2021-11-01 07:56:10 +0100 | <jackdk> | I don't think so. It's more that they've started from a different set of baseline assumptions than the ones you're used to, and as you practice more and internalise those assumptions you'll find it easier to think about. |
| 2021-11-01 07:56:14 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 260 seconds) |
| 2021-11-01 07:56:25 +0100 | phma | (~phma@host-67-44-208-63.hnremote.net) (Read error: Connection reset by peer) |
| 2021-11-01 07:57:00 +0100 | <jackdk> | (Although, yes, there are some terrifically smart people around, and it's an absolute privilege to build atop their work.) |
| 2021-11-01 07:57:15 +0100 | phma | (~phma@host-67-44-209-24.hnremote.net) |
| 2021-11-01 07:58:43 +0100 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2021-11-01 08:03:04 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-11-01 08:03:20 +0100 | boxscape_ | (~boxscape_@mue-88-130-59-184.dsl.tropolys.de) |
| 2021-11-01 08:03:30 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 08:07:15 +0100 | cheater | (~Username@user/cheater) |
| 2021-11-01 08:08:25 +0100 | zincy_ | (~zincy@2a00:23c8:970c:4801:e5fe:6e8c:c240:1bb2) |
| 2021-11-01 08:08:51 +0100 | qwedfg | (~qwedfg@user/qwedfg) (Read error: Connection reset by peer) |
| 2021-11-01 08:09:49 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2021-11-01 08:09:57 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-11-01 08:11:23 +0100 | Lycurgus | now that he's used it, thinks of typescript as just a more OO js, not related to FP in the hs sense |
| 2021-11-01 08:12:18 +0100 | qwedfg | (~qwedfg@user/qwedfg) |
| 2021-11-01 08:14:38 +0100 | <quazimodo> | Lycurgus: we try to use it functionally but it's not |
| 2021-11-01 08:15:38 +0100 | <Lycurgus> | no it isn't but a lot pkgs use it, and I find it convenient |
| 2021-11-01 08:16:20 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-11-01 08:16:58 +0100 | <Lycurgus> | xstate is the one I was trynna think of |
| 2021-11-01 08:17:44 +0100 | <Lycurgus> | a lot of react pkgs too |
| 2021-11-01 08:19:20 +0100 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) (Remote host closed the connection) |
| 2021-11-01 08:20:21 +0100 | <quazimodo> | xstate is useful, we use it |
| 2021-11-01 08:20:59 +0100 | zincy_ | (~zincy@2a00:23c8:970c:4801:e5fe:6e8c:c240:1bb2) (Remote host closed the connection) |
| 2021-11-01 08:21:56 +0100 | <Lycurgus> | it's an almost embarrasing but extremely common cognitive error, from "type" to assume FP because hs |
| 2021-11-01 08:25:56 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-11-01 08:30:53 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 265 seconds) |
| 2021-11-01 08:36:49 +0100 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-11-01 08:39:31 +0100 | aegon | (~mike@174.127.249.180) (Quit: leaving) |
| 2021-11-01 08:40:28 +0100 | fendor | (~fendor@77.119.160.25.wireless.dyn.drei.com) |
| 2021-11-01 08:54:10 +0100 | quazimodo | (~quazimodo@n1-40-235-47.bla1.nsw.optusnet.com.au) (Ping timeout: 260 seconds) |
| 2021-11-01 08:55:33 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 268 seconds) |
| 2021-11-01 08:56:20 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:1b26:eada:1c7:e76b) |
| 2021-11-01 08:56:51 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 09:01:45 +0100 | fendor | (~fendor@77.119.160.25.wireless.dyn.drei.com) (Read error: Connection reset by peer) |
| 2021-11-01 09:01:58 +0100 | cheater | (~Username@user/cheater) |
| 2021-11-01 09:02:42 +0100 | fendor | (~fendor@77.119.160.25.wireless.dyn.drei.com) |
| 2021-11-01 09:04:43 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Remote host closed the connection) |
| 2021-11-01 09:05:25 +0100 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) |
| 2021-11-01 09:05:33 +0100 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-11-01 09:09:06 +0100 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-11-01 09:11:00 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-11-01 09:11:21 +0100 | acidjnk | (~acidjnk@p200300d0c74411311cbabef3984b18e3.dip0.t-ipconnect.de) |
| 2021-11-01 09:16:25 +0100 | LiaoTao_ | LiaoTao |
| 2021-11-01 09:17:27 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-11-01 09:17:51 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-11-01 09:17:53 +0100 | max22- | (~maxime@lfbn-ren-1-762-224.w81-53.abo.wanadoo.fr) |
| 2021-11-01 09:18:07 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-11-01 09:18:43 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 09:22:52 +0100 | <kritzefitz> | Does the PVP specify an exception for upper bounds on base? People are asking me to weaken the upper bound for base to `< 5` in one of my libraries. But from what I understand, that wouldn't be compliant with PVP. |
| 2021-11-01 09:23:58 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 09:29:23 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-11-01 09:32:12 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2021-11-01 09:33:29 +0100 | <dminuoso> | kritzefitz: No. |
| 2021-11-01 09:33:59 +0100 | <dminuoso> | kritzefitz: Since base has a history of breaking changes, its simpler to just use set-notation + ^ notation, to quickly add known working base versions |
| 2021-11-01 09:35:22 +0100 | <kritzefitz> | That's the approach I have taken so far. But I guess people are annoyed that they have to poke me for updated bounds on every GHC release. |
| 2021-11-01 09:36:13 +0100 | <dminuoso> | kritzefitz: It's the trade off between honest version bounds, and the risk of breaking builds in the future. |
| 2021-11-01 09:37:11 +0100 | <mc47> | Hello, I'm having a question about GHC, specifically the -Wincomplete-uni-patterns flag. It feels too agressive, since things like `let [i1,i2] = map f [w1,w2]` are also handled as errors |
| 2021-11-01 09:37:34 +0100 | <mc47> | Is this a conscious choice? Isn't it possible to detect that this is safe somehow? |
| 2021-11-01 09:37:56 +0100 | <dminuoso> | Yes and no. |
| 2021-11-01 09:38:43 +0100 | <mc47> | how so? I could think of some abstract interpretation pass that might detect this |
| 2021-11-01 09:39:07 +0100 | <mc47> | (No idea how or where GHC implements these checks) |
| 2021-11-01 09:39:25 +0100 | <dminuoso> | mc47: Im not entirely sure about incomplete-uni-patterns, but the incomplete-patterns is ridiculously complicated to do right. |
| 2021-11-01 09:39:40 +0100 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 09:40:21 +0100 | <dminuoso> | It wasnt until about 2 years ago until someone figured out how to it correctly, there was a WIP branch in ghc to implement it, not sure whether it has been merged already. |
| 2021-11-01 09:41:04 +0100 | <dminuoso> | SPJ once put it this way, there are problems that look simple and are hard to solve, problems that look hard but are hard to solve, and then there's incomplete pattern matches, which looked hard and was hard to solve. |
| 2021-11-01 09:42:12 +0100 | chomwitt | (~chomwitt@2a02:587:dc02:9f00:12c3:7bff:fe6d:d374) |
| 2021-11-01 09:43:13 +0100 | <dminuoso> | mc47: The difficulty really is writing a generic algorithm that works over arbitrary code. In your example, we'd have to leverage either a law (namely that map cant change the length of a list), or do this diagnostic *after* inlining. |
| 2021-11-01 09:43:35 +0100 | <dminuoso> | Without either, you're in incomplete patterns territory |
| 2021-11-01 09:44:24 +0100 | <dminuoso> | GHC right now doesn't really know about such laws, and doing diagnostics after inlining seems quite hard, given that the diagnostic would have to operate on completely transformed core - and then somehow map the results back to the original code (which might not be applicable at all) |
| 2021-11-01 09:44:29 +0100 | <mc47> | Makes sense, but aren't these laws written anywhere? |
| 2021-11-01 09:44:41 +0100 | <mc47> | oh |
| 2021-11-01 09:45:10 +0100 | fef | (~thedawn@user/thedawn) (Quit: Leaving) |
| 2021-11-01 09:45:25 +0100 | <lortabac> | type-class laws are just conventions, nothing prevents you from writing instances that break the laws |
| 2021-11-01 09:45:32 +0100 | <mc47> | It was a breeze proving `length xs = length (map f xs)` with Isabelle |
| 2021-11-01 09:45:34 +0100 | <mc47> | yeah yeah that's true |
| 2021-11-01 09:45:36 +0100 | <dminuoso> | Well in case of `map` you know this law to hold, lortabac. |
| 2021-11-01 09:45:46 +0100 | <dminuoso> | So one could really teach GHC about this. |
| 2021-11-01 09:46:17 +0100 | <lortabac> | ok but that would mean adding special cases to the exaustiveness checker |
| 2021-11-01 09:46:19 +0100 | <dminuoso> | But then you have to wonder, whether special casing for this singular function is going to add much value. |
| 2021-11-01 09:46:20 +0100 | <dminuoso> | Yeah |
| 2021-11-01 09:46:46 +0100 | <mc47> | Do you recommend and reading material or talks about where this is implemented in the GHC pipeline? |
| 2021-11-01 09:46:51 +0100 | <mc47> | true |
| 2021-11-01 09:47:31 +0100 | <mc47> | or any "getting started" guide on GHC? The more theoretical the better :D |
| 2021-11-01 09:47:43 +0100 | <dminuoso> | mc47: https://www.youtube.com/watch?v=SWO5OzSxD6Y |
| 2021-11-01 09:47:45 +0100 | <dminuoso> | Is a good starting point |
| 2021-11-01 09:48:08 +0100 | <dminuoso> | In there SPJ should at some point refer to the paper he helped author that is the basis for this new exhaustiveness checker |
| 2021-11-01 09:48:22 +0100 | <dminuoso> | Note, that this is not what GHC does not right, but will be doing (?) in the near future |
| 2021-11-01 09:48:41 +0100 | <dminuoso> | What GHC does right now in terms of exhausitiveness checking is very complicated and highly error prone |
| 2021-11-01 09:48:58 +0100 | <dminuoso> | Few things have provoked as many error reports as that singular part. :) |
| 2021-11-01 09:49:08 +0100 | <mc47> | thank you |
| 2021-11-01 09:49:10 +0100 | arjun | (~user@user/arjun) |
| 2021-11-01 09:49:44 +0100 | <mc47> | I guess we'll just disable -Wincomplete-uni-patterns for GHC 9.2.1 for the time being, many things just look too ugly |
| 2021-11-01 09:53:23 +0100 | tremon | (~tremon@217-63-61-89.cable.dynamic.v4.ziggo.nl) |
| 2021-11-01 09:56:24 +0100 | fendor_ | (~fendor@77.119.160.25.wireless.dyn.drei.com) |
| 2021-11-01 09:56:24 +0100 | fendor | (~fendor@77.119.160.25.wireless.dyn.drei.com) (Read error: Connection reset by peer) |
| 2021-11-01 09:56:42 +0100 | <tomsmeding> | isn't this the Lower Your Guards paper? https://www.microsoft.com/en-us/research/uploads/prod/2020/03/lower-your-guards-icfp20.pdf |
| 2021-11-01 09:57:17 +0100 | Guest396 | (~Guest39@eth-west-pareq2-46-193-4-100.wb.wifirst.net) |
| 2021-11-01 09:58:39 +0100 | <dminuoso> | tomsmeding: Looks like, yes. Couldn't find it on short notice |
| 2021-11-01 09:59:19 +0100 | <tomsmeding> | I read it a while ago, is quite readable IIRC :) |
| 2021-11-01 10:00:08 +0100 | kar1 | (~kar1@2001:470:69fc:105::c308) (Quit: You have been kicked for being idle) |
| 2021-11-01 10:00:47 +0100 | <mc47> | Awesome! THanks tomsmeding |
| 2021-11-01 10:01:21 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-11-01 10:01:38 +0100 | alzgh | (~alzgh@user/alzgh) |
| 2021-11-01 10:01:55 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 10:01:55 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2021-11-01 10:04:41 +0100 | <alzgh> | Can someone help me understand `>>`? The doc says it chains actions while discarding any value produced by the first action but when I do `putStrLn "hello" >> putStrLn "goodbye"` it outputs both words. Is this because writing "hello" is an effect and not a value produced by `putStrLn`? If so, can you give me an example where the value produced is discarded? Thank you. |
| 2021-11-01 10:05:07 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 10:05:15 +0100 | <tomsmeding> | % return 42 >> putStrLn "goodbye" -- alzgh |
| 2021-11-01 10:05:16 +0100 | <yahb> | tomsmeding: goodbye |
| 2021-11-01 10:05:52 +0100 | <tomsmeding> | the value is the thing of type 'a' in the 'IO a', or more generally the 'm a' where m is a Monad |
| 2021-11-01 10:06:03 +0100 | <tomsmeding> | the effect is all the other stuff that you can do in the monad |
| 2021-11-01 10:06:27 +0100 | <alzgh> | right, thank you tomsmeding |
| 2021-11-01 10:07:44 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2021-11-01 10:07:55 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2021-11-01 10:10:09 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Ping timeout: 268 seconds) |
| 2021-11-01 10:11:10 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-11-01 10:15:06 +0100 | chele | (~chele@user/chele) |
| 2021-11-01 10:15:08 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 10:17:11 +0100 | tafa | (~tafa@2a04:52c0:101:85c::1) (Ping timeout: 245 seconds) |
| 2021-11-01 10:17:21 +0100 | tafa | (~tafa@2a04:52c0:101:85c::1) |
| 2021-11-01 10:21:33 +0100 | <kritzefitz> | Can I force cabal to skip building a specific build-tool-depends and instead use one found one the path or specified via `--with-PROG`? |
| 2021-11-01 10:21:36 +0100 | Jing | (~textual@103.121.208.115) (Remote host closed the connection) |
| 2021-11-01 10:23:26 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2021-11-01 10:28:26 +0100 | <kritzefitz> | More specifically: I installed GHC 9.2.1 via ghcup. Now I can't build packages with hsc2hs, because hsc2hs-0.68.7 doesn't build with base-1.16.0.0 and hsc2-hs0.68.8 is not on hackage. Using a hsc2hs compiled with an older base or using the hsc2hs shipped with ghc-9.2.1 would probably work, but I don't know how to prevent "cabal build" from wanting to build a new hsc2hs. |
| 2021-11-01 10:29:17 +0100 | <arjun> | kritzefitz: maybe try cabal build --alow-newer |
| 2021-11-01 10:29:30 +0100 | <arjun> | not sure if that would work tho |
| 2021-11-01 10:29:47 +0100 | <arjun> | --allow-newer* typo |
| 2021-11-01 10:32:38 +0100 | <kritzefitz> | That seems to work. Or rather it seems to reveal that the ghc-9.2 I installed seems to be completely broken and always fail with a linker error. |
| 2021-11-01 10:33:00 +0100 | <arjun> | yea, 9.2.1 is still new |
| 2021-11-01 10:33:31 +0100 | <arjun> | common thing to do in this case is wait for the libs to catch-up |
| 2021-11-01 10:33:45 +0100 | <fvr> | whats the linker error? |
| 2021-11-01 10:33:51 +0100 | <arjun> | and move to an older, stabler version, like 8.10.7 |
| 2021-11-01 10:35:02 +0100 | <kritzefitz> | “cannot find -lnuma“ and then some missing symbols. I guess I'm just missing some dependency libraries on my system. |
| 2021-11-01 10:35:32 +0100 | <kritzefitz> | Yup, install libnuma-dev helped. |
| 2021-11-01 10:36:16 +0100 | <kritzefitz> | And now hsc2hs also works. Thanks for the help! |
| 2021-11-01 10:36:54 +0100 | oxide | (~lambda@user/oxide) |
| 2021-11-01 10:38:24 +0100 | <arjun> | kritzefitz: np |
| 2021-11-01 10:38:47 +0100 | shriekingnoise | (~shrieking@186.137.144.80) (Quit: Quit) |
| 2021-11-01 10:39:08 +0100 | <kritzefitz> | I usually use more stable versions of GHC for my day-to-day development. But people specifically asked me to upgrade one of my libraries to GHC-9.2. |
| 2021-11-01 10:39:37 +0100 | <arjun> | kritzefitz: it has the native arm codegen, so that might be the reason : P |
| 2021-11-01 10:42:51 +0100 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) (Remote host closed the connection) |
| 2021-11-01 10:43:09 +0100 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) |
| 2021-11-01 10:43:38 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2021-11-01 10:44:26 +0100 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) |
| 2021-11-01 10:44:51 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 10:46:32 +0100 | <timCF> | Hello! Let's say I do have 2 different cabal/stack Haskell packages which do export 2 different modules with the same name Foo. My package is using them both as dependencies. How do I import/use 2 different modules named Foo separately? |
| 2021-11-01 10:48:34 +0100 | <int-e> | there's https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/exts/package_qualified_imports.html |
| 2021-11-01 10:49:22 +0100 | xff0x | (~xff0x@2001:1a81:537f:9c00:f676:7afa:ede:1e04) (Ping timeout: 260 seconds) |
| 2021-11-01 10:49:37 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-11-01 10:52:55 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 10:54:31 +0100 | xff0x | (~xff0x@2001:1a81:537f:9c00:f676:7afa:ede:1e04) |
| 2021-11-01 10:56:24 +0100 | acidjnk | (~acidjnk@p200300d0c74411311cbabef3984b18e3.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2021-11-01 10:57:34 +0100 | tdwamdors^ | (~tdwamdors@wsip-98-188-242-6.mc.at.cox.net) |
| 2021-11-01 10:57:36 +0100 | <merijn> | timCF: The recommended solution is: publically shame the authors to "stop fucking doing that" |
| 2021-11-01 11:03:08 +0100 | acidjnk | (~acidjnk@p200300d0c74411311cbabef3984b18e3.dip0.t-ipconnect.de) |
| 2021-11-01 11:03:42 +0100 | fef | (~thedawn@user/thedawn) |
| 2021-11-01 11:05:41 +0100 | fef | (~thedawn@user/thedawn) (Client Quit) |
| 2021-11-01 11:08:05 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-11-01 11:08:51 +0100 | shidima | (~user@188-206-67-204.mobile.kpn.net) |
| 2021-11-01 11:11:28 +0100 | <shidima> | Can some one tell me what I'm doing wrong here: https://pastebin.com/DeyjxsiC |
| 2021-11-01 11:11:44 +0100 | <shidima> | Am I creating the type wrong? |
| 2021-11-01 11:14:38 +0100 | <Hecate> | shidima: okay so |
| 2021-11-01 11:15:02 +0100 | <Hecate> | shidima: how many arguments does the constructor "Individual" have? |
| 2021-11-01 11:17:18 +0100 | shidima | (~user@188-206-67-204.mobile.kpn.net) (Read error: Connection reset by peer) |
| 2021-11-01 11:19:48 +0100 | Jing | (~textual@103.121.208.52) |
| 2021-11-01 11:19:54 +0100 | fef | (~thedawn@user/thedawn) |
| 2021-11-01 11:21:57 +0100 | <arjun> | . |
| 2021-11-01 11:22:11 +0100 | <arjun> | oh, they left? |
| 2021-11-01 11:22:15 +0100 | <arjun> | nvm |
| 2021-11-01 11:23:22 +0100 | fef | (~thedawn@user/thedawn) () |
| 2021-11-01 11:24:12 +0100 | <Hecate> | yep :') |
| 2021-11-01 11:24:22 +0100 | <arjun> | \o Hecate |
| 2021-11-01 11:27:22 +0100 | <merijn> | As is tradition |
| 2021-11-01 11:30:34 +0100 | Guest|83 | (~Guest|83@101.100.131.49) |
| 2021-11-01 11:30:55 +0100 | Guest|83 | (~Guest|83@101.100.131.49) (Client Quit) |
| 2021-11-01 11:33:32 +0100 | <alzgh> | when I add libraries to the `build-depends` directive in my `.cabal` file, I don't need to separately install those libraries? cabal will download and install them for me automatically? |
| 2021-11-01 11:34:01 +0100 | <Hecate> | alzgh: yes absolutely :) |
| 2021-11-01 11:34:03 +0100 | <Hecate> | arjun: o/ |
| 2021-11-01 11:34:05 +0100 | <Hecate> | merijn: indeed |
| 2021-11-01 11:34:08 +0100 | <arjun> | alzgh: sure |
| 2021-11-01 11:34:44 +0100 | <arjun> | i neat trick i picked up earlier, you may not even mention the bounds initially |
| 2021-11-01 11:35:07 +0100 | <arjun> | you just go build-depends: base,text,time etc |
| 2021-11-01 11:35:16 +0100 | <arjun> | then run cabal gen-bounds |
| 2021-11-01 11:35:55 +0100 | <alzgh> | I'm just a little bit confused about where cabal installs them. Is it per project? So, I don't need to worry about version hell on global level between different projects? Also, what about `cabal install` then? |
| 2021-11-01 11:36:00 +0100 | phma_ | (~phma@host-67-44-209-61.hnremote.net) |
| 2021-11-01 11:36:28 +0100 | <arjun> | alzgh: you don't need to worry about cabal hell anymore with cabal 3.0+ |
| 2021-11-01 11:36:55 +0100 | <arjun> | these are installed in .cabal in home in unix or the relevant counterpart in windows |
| 2021-11-01 11:37:20 +0100 | phma | (~phma@host-67-44-209-24.hnremote.net) (Read error: Connection reset by peer) |
| 2021-11-01 11:37:39 +0100 | <alzgh> | nice, so `cabal install` is not needed anymore? |
| 2021-11-01 11:37:50 +0100 | <arjun> | it is |
| 2021-11-01 11:37:56 +0100 | <merijn> | alzgh: All installed dependencies are tagged with a hash of their (and transitive dependencies) code/config |
| 2021-11-01 11:38:17 +0100 | <merijn> | alzgh: So you can have unlimited number of parallel installs of the same packages with conflicting configuration |
| 2021-11-01 11:38:29 +0100 | <arjun> | well, if you're building a executable and want to install it, else, you can work with cabal run or cabal build |
| 2021-11-01 11:39:03 +0100 | yahb | (xsbot@user/mniip/bot/yahb) (Ping timeout: 268 seconds) |
| 2021-11-01 11:40:46 +0100 | <alzgh> | Thank you, I think I'm starting to understand. So, the selling point of Stack isn't enabling different/parallel versions of the same package (maybe it was before cabal 3.0), but rather guaranteeing that different package work smoothly together like in a stable distro. |
| 2021-11-01 11:41:39 +0100 | <arjun> | totes, it's like a snapshot of package versions that are bound to play nice with each other and will always will, given the same resolver version. |
| 2021-11-01 11:42:21 +0100 | <alzgh> | thank you :D |
| 2021-11-01 11:42:46 +0100 | <geekosaur> | it was before cabal 2.0 |
| 2021-11-01 11:44:38 +0100 | Guest16 | (~Guest16@103.99.84.6) (Quit: Client closed) |
| 2021-11-01 11:44:49 +0100 | mniip | (mniip@libera/staff/mniip) (Ping timeout: 633 seconds) |
| 2021-11-01 11:48:38 +0100 | maerwald | (~maerwald@mail.hasufell.de) (Changing host) |
| 2021-11-01 11:48:38 +0100 | maerwald | (~maerwald@user/maerwald) |
| 2021-11-01 11:49:21 +0100 | <maerwald> | arjun: sup |
| 2021-11-01 11:49:41 +0100 | <arjun> | maerwald: \o |
| 2021-11-01 11:49:48 +0100 | <arjun> | how you been doin mate |
| 2021-11-01 11:50:32 +0100 | <maerwald> | doing haskell on windows mostly |
| 2021-11-01 11:50:38 +0100 | <maerwald> | which gives me odd pleasure |
| 2021-11-01 11:50:51 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 11:50:52 +0100 | <maerwald> | I'm not sure if it's good or bad |
| 2021-11-01 11:51:02 +0100 | Farzad | (~FarzadBek@178.131.25.90) |
| 2021-11-01 11:51:10 +0100 | <arjun> | i tried it sometime back, it surprisingly works well enough, doesn't it |
| 2021-11-01 11:51:15 +0100 | <arjun> | ghcup is champ |
| 2021-11-01 11:51:33 +0100 | yahb | (xsbot@user/mniip/bot/yahb) |
| 2021-11-01 11:51:53 +0100 | mniip | (mniip@libera/staff/mniip) |
| 2021-11-01 11:51:59 +0100 | <maerwald> | mostly due to my abstract-filepath stuff |
| 2021-11-01 11:52:10 +0100 | <maerwald> | trying to migrate my directory package fork to windows |
| 2021-11-01 11:52:46 +0100 | <maerwald> | reading windows API is like looking at a car crash from a distance... it shouldn't be fun, but it is |
| 2021-11-01 11:52:50 +0100 | phma_ | (~phma@host-67-44-209-61.hnremote.net) (Ping timeout: 260 seconds) |
| 2021-11-01 11:53:01 +0100 | <arjun> | lmao |
| 2021-11-01 11:54:17 +0100 | <maerwald> | I still don't really know what junction points are |
| 2021-11-01 11:54:57 +0100 | phma_ | (~phma@host-67-44-209-61.hnremote.net) |
| 2021-11-01 11:55:25 +0100 | phma_ | phma |
| 2021-11-01 11:55:37 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-11-01 11:55:48 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 11:58:00 +0100 | <maerwald> | also, the semantics of what an "executable" is on windows are... well |
| 2021-11-01 11:58:02 +0100 | <maerwald> | complicated |
| 2021-11-01 11:58:25 +0100 | <arjun> | the refactor was great, looks likes a different code-base now but still familiar and sort of cleaner |
| 2021-11-01 11:58:37 +0100 | <maerwald> | directory package uses a hardcoded list https://github.com/haskell/directory/blob/f0da64307959fcd2225c01f97df851ff45285e68/System/Director… |
| 2021-11-01 11:58:43 +0100 | <maerwald> | which seems wrong too |
| 2021-11-01 11:59:21 +0100 | <maerwald> | then there is a PATHEXT variable, but to be really complete you'd also need to look up some random registry entries |
| 2021-11-01 11:59:41 +0100 | <arjun> | are we testing on windows 11? |
| 2021-11-01 11:59:42 +0100 | <maerwald> | and then it's still not clear what "executable" means, because it's not a file attribute |
| 2021-11-01 12:00:03 +0100 | <arjun> | cause that probably might have changed things a bit |
| 2021-11-01 12:00:18 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Ping timeout: 260 seconds) |
| 2021-11-01 12:00:19 +0100 | <maerwald> | not sure |
| 2021-11-01 12:00:40 +0100 | alx741 | (~alx741@181.196.69.253) |
| 2021-11-01 12:03:44 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) (Changing host) |
| 2021-11-01 12:03:44 +0100 | kritzefitz | (~kritzefit@user/kritzefitzm/x-3779698) |
| 2021-11-01 12:04:38 +0100 | kritzefitz | (~kritzefit@user/kritzefitzm/x-3779698) (Changing host) |
| 2021-11-01 12:04:38 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2021-11-01 12:04:40 +0100 | Nachtgespenst | (~user@user/siracusa) (Quit: Bye!) |
| 2021-11-01 12:04:56 +0100 | kritzefitz | kritzefitz[m] |
| 2021-11-01 12:05:12 +0100 | kritzefitz[m] | kritzefitz |
| 2021-11-01 12:05:54 +0100 | __monty__ | (~toonn@user/toonn) |
| 2021-11-01 12:07:00 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 12:07:40 +0100 | Guest396 | (~Guest39@eth-west-pareq2-46-193-4-100.wb.wifirst.net) (Quit: Client closed) |
| 2021-11-01 12:07:43 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 12:08:24 +0100 | kritzefitz[m] | (~kritzefit@fw-front.credativ.com) |
| 2021-11-01 12:08:56 +0100 | kritzefitz[m] | (~kritzefit@fw-front.credativ.com) (Changing host) |
| 2021-11-01 12:08:56 +0100 | kritzefitz[m] | (~kritzefit@debian/kritzefitz) |
| 2021-11-01 12:09:41 +0100 | kritzefitz[m] | (~kritzefit@debian/kritzefitz) (Client Quit) |
| 2021-11-01 12:11:30 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Ping timeout: 260 seconds) |
| 2021-11-01 12:12:42 +0100 | AlexNoo_ | (~AlexNoo@94.233.241.118) |
| 2021-11-01 12:14:55 +0100 | Alex_test | (~al_test@178.34.163.209) (Ping timeout: 260 seconds) |
| 2021-11-01 12:15:30 +0100 | AlexZenon | (~alzenon@178.34.163.209) (Ping timeout: 260 seconds) |
| 2021-11-01 12:16:35 +0100 | AlexNoo | (~AlexNoo@178.34.163.209) (Ping timeout: 264 seconds) |
| 2021-11-01 12:20:15 +0100 | Alex_test | (~al_test@94.233.241.118) |
| 2021-11-01 12:20:57 +0100 | AlexZenon | (~alzenon@94.233.241.118) |
| 2021-11-01 12:24:19 +0100 | arjun | (~user@user/arjun) (ERC (IRC client for Emacs 28.0.50)) |
| 2021-11-01 12:25:16 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 12:28:17 +0100 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) (Ping timeout: 246 seconds) |
| 2021-11-01 12:28:18 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 12:28:41 +0100 | xkuru | (~xkuru@user/xkuru) |
| 2021-11-01 12:29:17 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 12:29:42 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 12:30:12 +0100 | xkuru | (~xkuru@user/xkuru) (Client Quit) |
| 2021-11-01 12:30:55 +0100 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-11-01 12:31:03 +0100 | xkuru | (~xkuru@user/xkuru) |
| 2021-11-01 12:38:51 +0100 | <Hecate> | maerwald: plz don't trainwreck the GHC proposal ticket 😭 |
| 2021-11-01 12:39:08 +0100 | <maerwald> | spj started the discussion |
| 2021-11-01 12:39:12 +0100 | <maerwald> | not me |
| 2021-11-01 12:39:24 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 12:39:31 +0100 | <maerwald> | and it's true, there are only two options: 1. overlays, 2. downstream patches |
| 2021-11-01 12:39:59 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 12:40:30 +0100 | <maerwald> | and this surely touches the core issue: smooth upgrades |
| 2021-11-01 12:45:34 +0100 | chele | (~chele@user/chele) (Ping timeout: 268 seconds) |
| 2021-11-01 12:50:30 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 12:51:06 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 12:54:35 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:bc44:afc4:50a0:6ab8) |
| 2021-11-01 12:55:05 +0100 | Guest10 | (~Guest10@eth-west-pareq2-46-193-4-100.wb.wifirst.net) |
| 2021-11-01 13:03:55 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-11-01 13:06:16 +0100 | AlexNoo_ | AlexNoo |
| 2021-11-01 13:07:17 +0100 | guniberas | (~guniberas@42.191.188.121) |
| 2021-11-01 13:11:53 +0100 | Guest10 | (~Guest10@eth-west-pareq2-46-193-4-100.wb.wifirst.net) (Quit: Client closed) |
| 2021-11-01 13:19:05 +0100 | shriekingnoise | (~shrieking@186.137.144.80) |
| 2021-11-01 13:20:49 +0100 | chexum_ | (~quassel@gateway/tor-sasl/chexum) |
| 2021-11-01 13:21:22 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-11-01 13:22:11 +0100 | <tomjaguarpaw> | There's a third option of trying to instill a pervasive sense of responsibility across the community so that this issue doesn't arise so often |
| 2021-11-01 13:22:18 +0100 | <maerwald> | tomjaguarpaw: :D |
| 2021-11-01 13:22:21 +0100 | <tomjaguarpaw> | Admittedly that is very hand and fraught with many difficulties |
| 2021-11-01 13:22:39 +0100 | <tomjaguarpaw> | *hard |
| 2021-11-01 13:23:06 +0100 | <tomjaguarpaw> | But ultimately I don't think a community can escape its own culture with technical solutions |
| 2021-11-01 13:24:12 +0100 | <maerwald> | I mean... what confuses me is that we're relatively quick with package takeovers, but overly conservative with NMUs. While, in the end: both have the danger of incompetency sneaking in. That's just how it is. |
| 2021-11-01 13:34:05 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-11-01 13:36:47 +0100 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-11-01 13:40:24 +0100 | xff0x | (~xff0x@2001:1a81:537f:9c00:f676:7afa:ede:1e04) (Remote host closed the connection) |
| 2021-11-01 13:40:26 +0100 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 268 seconds) |
| 2021-11-01 13:40:41 +0100 | xff0x | (~xff0x@2001:1a81:537f:9c00:f94d:493e:e9e:5a9) |
| 2021-11-01 13:44:32 +0100 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) |
| 2021-11-01 13:55:34 +0100 | yrlnry | (~mjd@pool-74-109-22-90.phlapa.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2021-11-01 13:56:16 +0100 | dermato | (~dermatobr@cpe-70-114-219-76.austin.res.rr.com) (Ping timeout: 260 seconds) |
| 2021-11-01 13:58:06 +0100 | dermato | (~dermatobr@cpe-70-114-219-76.austin.res.rr.com) |
| 2021-11-01 13:59:23 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) |
| 2021-11-01 14:00:38 +0100 | <dartford> | hi, whats up with the tunes log? |
| 2021-11-01 14:00:48 +0100 | <dartford> | http://tunes.org/~nef/logs/haskell/21.09.14 |
| 2021-11-01 14:01:04 +0100 | <dartford> | i cant find yesterdays conversation |
| 2021-11-01 14:01:18 +0100 | <dartford> | oh ok, i can see it in the header |
| 2021-11-01 14:01:51 +0100 | acowley | (~acowley@c-68-83-22-43.hsd1.nj.comcast.net) (Ping timeout: 260 seconds) |
| 2021-11-01 14:02:05 +0100 | <dartford> | wow, it sure is less organised than when it was grouped by date |
| 2021-11-01 14:02:27 +0100 | <dartford> | i wonder if tomsmeding would consider that option, or linking it back to the old tunes log somehow |
| 2021-11-01 14:03:10 +0100 | <tomsmeding> | dartford: see the "calendar" link at the top of ircbrowse |
| 2021-11-01 14:03:30 +0100 | <dartford> | horay! |
| 2021-11-01 14:03:46 +0100 | <dartford> | how goes it, havent been online in a while |
| 2021-11-01 14:03:50 +0100 | <tomsmeding> | is there anyone who actually uses that browse view with 3000+ pages of content? |
| 2021-11-01 14:04:04 +0100 | <tomsmeding> | like, there's the "recent" view which could be useful, and there's calendar |
| 2021-11-01 14:04:05 +0100 | alzgh | (~alzgh@user/alzgh) (Ping timeout: 256 seconds) |
| 2021-11-01 14:04:10 +0100 | <dartford> | last time we spoke you helped me with a buffer, for which i was most thankful |
| 2021-11-01 14:04:21 +0100 | <dartford> | have you got any cool projects on the go at the moment? |
| 2021-11-01 14:04:32 +0100 | <tomsmeding> | making the browse view efficient has _serious_ implications on the database structure :p |
| 2021-11-01 14:04:35 +0100 | <dartford> | (i was using the handle fog at the time) |
| 2021-11-01 14:04:39 +0100 | <tomsmeding> | ah! |
| 2021-11-01 14:04:45 +0100 | <tomsmeding> | I remember FogBuffer.hs :) |
| 2021-11-01 14:05:02 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-11-01 14:05:12 +0100 | <tomsmeding> | that's... slightly more than a year ago, I think? |
| 2021-11-01 14:05:14 +0100 | <dartford> | im stuck with probabilty monad at the moment, but i tried asking yeasterday and it ended up as gobeldygook |
| 2021-11-01 14:05:31 +0100 | <dartford> | tomsmeding: yeah, i have been basically out of action for about that long |
| 2021-11-01 14:05:32 +0100 | tomsmeding | is currently looking more closely at automatic differentiation |
| 2021-11-01 14:05:49 +0100 | <tomsmeding> | somehow the university decided that it was a good idea to let me do a phd |
| 2021-11-01 14:06:23 +0100 | <dartford> | well if your maintaining the haskell logs id say you probs have the credentials |
| 2021-11-01 14:06:28 +0100 | <tomsmeding> | :D |
| 2021-11-01 14:06:34 +0100 | <dartford> | most of the aplicants are just tramps after a free lunch |
| 2021-11-01 14:06:37 +0100 | <tomsmeding> | "maintaining" |
| 2021-11-01 14:06:47 +0100 | <dartford> | "able to establish" |
| 2021-11-01 14:08:13 +0100 | <tomsmeding> | fun thing is, a while ago I added some route timing statistics to ircbrowse |
| 2021-11-01 14:08:28 +0100 | <dartford> | yes, that does sound fun.... not |
| 2021-11-01 14:08:33 +0100 | <tomsmeding> | apparently I did something wrong regarding memory usage because it went from being ~constant to rising like 500M per day |
| 2021-11-01 14:08:56 +0100 | <tomsmeding> | turned it off after I became tired of 'systemctl restart ircbrowse' |
| 2021-11-01 14:08:59 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 14:09:31 +0100 | <dartford> | basically, the probability monad i envisage is a variant of a state, where instead of just being able to "view" the state, as an input to the update of the carry |
| 2021-11-01 14:09:52 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 14:09:55 +0100 | <dartford> | ie, from within the monad, being able to draw the value using <- from the monadic wrapper |
| 2021-11-01 14:10:08 +0100 | <dartford> | that instead, a "pdf" could be drawn from using the <- |
| 2021-11-01 14:10:26 +0100 | <dartford> | and somehow behind the scenes this would be handling the replacement of the seed for the rng |
| 2021-11-01 14:10:45 +0100 | <tomsmeding> | there is no implementation of a probability monad yet that does what you want?? |
| 2021-11-01 14:10:49 +0100 | <tomsmeding> | s/??/?/ |
| 2021-11-01 14:11:17 +0100 | <dartford> | er, i mean, maybe there is, but maybe not, i think i need to use StateL to preserve an applicative instance |
| 2021-11-01 14:11:43 +0100 | <dartford> | the conclusion of yesterdays garbled discord was that i should use Data.Functo.Compose |
| 2021-11-01 14:11:48 +0100 | <dartford> | instead of pairs |
| 2021-11-01 14:11:53 +0100 | <tomsmeding> | "preserve an applicative instance" -- do you mean 'pure = return ; (<*>) = ap' ? |
| 2021-11-01 14:11:54 +0100 | <dartford> | to build up larger states |
| 2021-11-01 14:12:09 +0100 | <dartford> | hmm, the applicative instance of StateL |
| 2021-11-01 14:12:24 +0100 | <tomsmeding> | hoogle doesn't know what StateL is |
| 2021-11-01 14:12:33 +0100 | <dartford> | which can be located following links in the hadocks starting from the implementation of mapAccumL |
| 2021-11-01 14:13:38 +0100 | fjmorazan_ | (~quassel@user/fjmorazan) (Quit: fjmorazan_) |
| 2021-11-01 14:13:44 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Ping timeout: 268 seconds) |
| 2021-11-01 14:14:02 +0100 | <dartford> | https://hackage.haskell.org/package/base-4.16.0.0/docs/src/Data.Functor.Utils.html#StateL |
| 2021-11-01 14:14:13 +0100 | fjmorazan | (~quassel@user/fjmorazan) |
| 2021-11-01 14:14:29 +0100 | <tomsmeding> | ah I see |
| 2021-11-01 14:14:40 +0100 | <tomsmeding> | so StateL would be the same as State from transformers, right? |
| 2021-11-01 14:14:46 +0100 | <tomsmeding> | and StateR the dual, sortof |
| 2021-11-01 14:14:46 +0100 | <dartford> | i got there by clicking the StateL word here; https://hackage.haskell.org/package/base-4.16.0.0/docs/src/Data.Traversable.html#mapAccumL |
| 2021-11-01 14:14:57 +0100 | <dartford> | yeah |
| 2021-11-01 14:15:11 +0100 | <dartford> | you want to traverse from the left if your given an infinite stream you want to consume lazily |
| 2021-11-01 14:15:15 +0100 | hololeap | (~hololeap@user/hololeap) (Remote host closed the connection) |
| 2021-11-01 14:15:26 +0100 | <tomsmeding> | right |
| 2021-11-01 14:15:35 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Ping timeout: 268 seconds) |
| 2021-11-01 14:15:40 +0100 | <tomsmeding> | so what prevents you from using State from transformers? |
| 2021-11-01 14:15:43 +0100 | <dartford> | hololeap suggested; |
| 2021-11-01 14:15:43 +0100 | <dartford> | % :t \f -> runState . traverse (state . f) |
| 2021-11-01 14:15:43 +0100 | <yahb> | dartford: Traversable t => (a -> s -> (b, s)) -> t a -> s -> (t b, s) |
| 2021-11-01 14:15:52 +0100 | <dartford> | is that the state you mean? |
| 2021-11-01 14:15:55 +0100 | <tomsmeding> | yeah |
| 2021-11-01 14:16:06 +0100 | <dartford> | idk if that has the same applicative instance |
| 2021-11-01 14:16:15 +0100 | <dartford> | that allows it to be lazy when used in traverse |
| 2021-11-01 14:16:32 +0100 | <dartford> | like, how traversing from the right is certainly not going to be lazy |
| 2021-11-01 14:16:43 +0100 | acowley | (~acowley@c-68-83-22-43.hsd1.nj.comcast.net) |
| 2021-11-01 14:16:45 +0100 | <dartford> | lets check |
| 2021-11-01 14:17:28 +0100 | <tomsmeding> | seems to be the same |
| 2021-11-01 14:17:51 +0100 | <tomsmeding> | apart from the pair being swapped of course |
| 2021-11-01 14:17:54 +0100 | <dartford> | https://hackage.haskell.org/package/transformers-0.6.0.2/docs/src/Control.Monad.Trans.State.Lazy.h… |
| 2021-11-01 14:17:56 +0100 | <dartford> | its just below that |
| 2021-11-01 14:19:12 +0100 | <tomsmeding> | yeah |
| 2021-11-01 14:19:25 +0100 | <maerwald> | are there any good automatic ways to observe and benchmark memory fragmentation? |
| 2021-11-01 14:19:30 +0100 | <tomsmeding> | that's the Lazy variant; the Strict variant seems to be the same but missing the lazy tuples |
| 2021-11-01 14:19:30 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2021-11-01 14:19:45 +0100 | <maerwald> | the only post on this topic I can find is https://www.well-typed.com/blog/2020/08/memory-fragmentation which is an odyessey of manual debugging |
| 2021-11-01 14:20:04 +0100 | <dartford> | tomsmeding: lazy tuples!? is that what the ~ i doing there? |
| 2021-11-01 14:20:13 +0100 | <dartford> | s/i/is |
| 2021-11-01 14:20:39 +0100 | alzgh | (~alzgh@user/alzgh) |
| 2021-11-01 14:21:28 +0100 | yrlnry | (~mjd@pool-100-11-2-80.phlapa.fios.verizon.net) |
| 2021-11-01 14:21:31 +0100 | <tomsmeding> | yeah wrong terminology, that's an irrefutable pattern match officially |
| 2021-11-01 14:21:46 +0100 | <tomsmeding> | > case undefined of (a, b) -> () |
| 2021-11-01 14:21:48 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2021-11-01 14:21:54 +0100 | <tomsmeding> | > case undefined of ~(a, b) -> () |
| 2021-11-01 14:21:55 +0100 | <lambdabot> | () |
| 2021-11-01 14:22:03 +0100 | <tomsmeding> | > case undefined of ~(a, b) -> a |
| 2021-11-01 14:22:05 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2021-11-01 14:22:29 +0100 | <tomsmeding> | dartford: the pattern match always succeeds and doesn't force the value being matched, and is thus also lazy |
| 2021-11-01 14:22:41 +0100 | <tomsmeding> | usages effectively become projections |
| 2021-11-01 14:24:00 +0100 | <dartford> | hmm, nice |
| 2021-11-01 14:24:12 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 14:24:31 +0100 | <dartford> | so its use in the StateT Applicative instance reasures us that the traversal should be lazy |
| 2021-11-01 14:24:52 +0100 | <dartford> | ie that we get a rewrite rule for the instance of mapAccumL defined using runState above |
| 2021-11-01 14:25:05 +0100 | <dartford> | that combines to subsequent mapAccumL's into one |
| 2021-11-01 14:25:22 +0100 | <dartford> | as if it were just consuming one element at a time and passing it through to the next scanner |
| 2021-11-01 14:26:13 +0100 | <tomsmeding> | yeah the StateL is also lazy, because let bindings are lazy, so its behaviour would be equivalent to the .Lazy version from transformers, with the ~ matches |
| 2021-11-01 14:26:50 +0100 | <dartford> | wait, iv gotten distracted, i forgot what we were trying to do |
| 2021-11-01 14:27:10 +0100 | <dartford> | good info about how its lazy though |
| 2021-11-01 14:28:56 +0100 | <dartford> | ok, so i want to make something like an existing probability monad |
| 2021-11-01 14:29:06 +0100 | <dartford> | but that uses the Compose idea to build up the state |
| 2021-11-01 14:29:29 +0100 | <dartford> | and then factor away the functionality so that the user doesnt actually see the "top layer" where the seed is |
| 2021-11-01 14:29:31 +0100 | tomsmeding | is not sure what the Compose idea is, but has to go anyway -- meetings meetings |
| 2021-11-01 14:30:23 +0100 | jonathanx | (~jonathan@dyn-8-sc.cdg.chalmers.se) (Ping timeout: 268 seconds) |
| 2021-11-01 14:30:39 +0100 | <dartford> | the idea is that if you use the Applicative instance of Data.Functor.Compose to smash together two StateL's into what should effectively then opperate *lazily* as StateL does, by the Applicative instance offered by Compose |
| 2021-11-01 14:30:48 +0100 | <dartford> | tomsmeding: ok, thanks for your help |
| 2021-11-01 14:31:03 +0100 | <dartford> | ill wait to see if anyone else picks up the convo before continuing |
| 2021-11-01 14:31:37 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2021-11-01 14:31:39 +0100 | hololeap_ | (~hololeap@user/hololeap) |
| 2021-11-01 14:32:09 +0100 | hololeap | (~hololeap@user/hololeap) (Ping timeout: 276 seconds) |
| 2021-11-01 14:32:41 +0100 | <dartford> | i guess in the worst case i would just have to write my own version of compose, posibly that just accepts stateL encoded data, to ensure its applicative instance is lazy as required |
| 2021-11-01 14:32:54 +0100 | <dartford> | not quite sure how that would work, but anyway... |
| 2021-11-01 14:33:11 +0100 | <dartford> | this is turning into a nightmare |
| 2021-11-01 14:33:41 +0100 | <[exa]> | do you have some example of code of how the probability monad should work? |
| 2021-11-01 14:33:46 +0100 | <dartford> | probablistic stream algebras they say, easy they say |
| 2021-11-01 14:34:21 +0100 | <dartford> | [exa]: thats very simple. something like do; x <- gausian1d (0,1) |
| 2021-11-01 14:34:37 +0100 | <[exa]> | what's the type of `x` after that? |
| 2021-11-01 14:34:39 +0100 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-11-01 14:34:42 +0100 | <dartford> | or, gausian1d (0,1) >>= \x -> ... |
| 2021-11-01 14:34:45 +0100 | <[exa]> | "type"....semantics |
| 2021-11-01 14:34:49 +0100 | <dartford> | x :: Double here |
| 2021-11-01 14:34:58 +0100 | <[exa]> | so it draws from the distribution, I see |
| 2021-11-01 14:35:02 +0100 | <dartford> | yeah |
| 2021-11-01 14:35:14 +0100 | <dartford> | and this requires the rng seed is updated behind the scenes |
| 2021-11-01 14:35:17 +0100 | <[exa]> | ok so far that's a monad that just holds a RNG |
| 2021-11-01 14:35:20 +0100 | <dartford> | its in a StateL composition somehow |
| 2021-11-01 14:35:31 +0100 | <dartford> | yeah, its just a fancy version of a pair with an int |
| 2021-11-01 14:35:39 +0100 | <[exa]> | how did you get to StateL? |
| 2021-11-01 14:35:45 +0100 | <dartford> | probably one of these lazy pairs from the StateT applicative instance example |
| 2021-11-01 14:35:58 +0100 | <dartford> | [exa] StateL appears in mapAccumL |
| 2021-11-01 14:36:11 +0100 | <dartford> | this is the basis for the idea of scanners |
| 2021-11-01 14:36:20 +0100 | <[exa]> | trying to hoogle in vain, lemme click backlog |
| 2021-11-01 14:36:30 +0100 | <dartford> | not all applicatives being lazy, scanners being the subset of traversals which use lazy applicatives, basically |
| 2021-11-01 14:37:02 +0100 | <dartford> | [exa] dont worry, we can work even with a custom instance, as long as it has a lazy applicative instance |
| 2021-11-01 14:37:18 +0100 | <[exa]> | oh wow that's the StateLegendary, with the tuple that just™ fmaps™ |
| 2021-11-01 14:37:27 +0100 | <dartford> | ie that when used with traverse that we get a rewrite rule for two subsequent mapAccumL's to compose into one |
| 2021-11-01 14:37:42 +0100 | <dartford> | [exa]: pardon1? |
| 2021-11-01 14:38:08 +0100 | <[exa]> | what would be an example of the 2 mapAccumL's ? |
| 2021-11-01 14:38:15 +0100 | <[exa]> | (that should compose) |
| 2021-11-01 14:38:19 +0100 | <dartford> | let me get the type hang on |
| 2021-11-01 14:38:23 +0100 | <dartford> | :t mapAccumL |
| 2021-11-01 14:38:23 +0100 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2021-11-01 14:38:40 +0100 | <dartford> | so the functions that you want to compose are these ... er wait let me uncurry that |
| 2021-11-01 14:38:46 +0100 | <dartford> | :t uncurry mapAccumL |
| 2021-11-01 14:38:47 +0100 | <lambdabot> | Traversable t => (a -> b -> (a, c), a) -> t b -> (a, t c) |
| 2021-11-01 14:39:00 +0100 | <dartford> | so you would have 2 of that first argument |
| 2021-11-01 14:39:11 +0100 | <dartford> | each needs its own initial state |
| 2021-11-01 14:39:15 +0100 | <dartford> | and state update function |
| 2021-11-01 14:39:24 +0100 | <dartford> | then, the initial states should compose into a pair |
| 2021-11-01 14:39:44 +0100 | <dartford> | and then you would have the `a' appearing in the state update function also ending up as a pair |
| 2021-11-01 14:39:55 +0100 | <dartford> | so it acts to accept and update the tuple of both states |
| 2021-11-01 14:39:57 +0100 | <dartford> | clear? |
| 2021-11-01 14:40:11 +0100 | <[exa]> | not sure what's the point of that |
| 2021-11-01 14:40:20 +0100 | <[exa]> | wait |
| 2021-11-01 14:40:58 +0100 | <dartford> | well, suppose it wasnt lazy, then you couldnt do that |
| 2021-11-01 14:41:00 +0100 | <[exa]> | why'd you want to compose the tuples manually when you'd have a monad below that does it for you? (mapAccumL kinda becomes traverse) |
| 2021-11-01 14:41:12 +0100 | <dartford> | notionally it nyams up one element at a time, and passes it through to the next accumulator |
| 2021-11-01 14:41:22 +0100 | <dartford> | next scanner |
| 2021-11-01 14:41:24 +0100 | <dartford> | whatever |
| 2021-11-01 14:41:46 +0100 | <dartford> | its just the idea that we get an algebra for scanners as a result of the lazyness |
| 2021-11-01 14:41:53 +0100 | <dartford> | it wouldnt *work* if it wasnt lazy |
| 2021-11-01 14:42:02 +0100 | <dartford> | but its difficult to express that |
| 2021-11-01 14:42:15 +0100 | <[exa]> | so you want something like: mapAccumL (...) `magicCompose` mapAccumL (...) ? |
| 2021-11-01 14:42:18 +0100 | <dartford> | because the first thing would hang, you would never be able to realise the composed version |
| 2021-11-01 14:42:32 +0100 | <[exa]> | it's as difficult as writing an example of the cool thing it does at the end |
| 2021-11-01 14:42:38 +0100 | <dartford> | [exa] exactly, it becomes monoidal under `magicCompose' |
| 2021-11-01 14:42:57 +0100 | hendursaga | (~weechat@user/hendursaga) |
| 2021-11-01 14:43:15 +0100 | <dartford> | but only with the lazy applicatives, so instead of bothering with traverse that could break, and supplying StateL's only |
| 2021-11-01 14:43:23 +0100 | <[exa]> | ok and what would be the problem of writing that as `traverse (...) >> traverse (...)` with a custom state inside, as lazy as you want? |
| 2021-11-01 14:43:34 +0100 | <dartford> | just combine them to keep the user from breaking it, and end up with Scanners as an actual thing |
| 2021-11-01 14:44:04 +0100 | <dartford> | kind of as a safety net, and to encapsulate this idea of stream transduction only working with lazy applicatives |
| 2021-11-01 14:44:05 +0100 | <[exa]> | (or *> to keep it applicative) |
| 2021-11-01 14:44:29 +0100 | hololeap_ | hololeap |
| 2021-11-01 14:44:50 +0100 | <dartford> | im not sure i understand |
| 2021-11-01 14:45:11 +0100 | <dartford> | you could certainly write it using traverse |
| 2021-11-01 14:45:24 +0100 | <dartford> | perhaps you dont agree with the notion of scanners as being well motivated |
| 2021-11-01 14:45:24 +0100 | <Tisoxin> | Are GADts a complete replacement for the normal data type declarations? |
| 2021-11-01 14:46:09 +0100 | <dartford> | Tisoxin: no, you do away with user defined records, but gain something in terms of actual type signatures, eg being able to add constraints |
| 2021-11-01 14:46:30 +0100 | <Tisoxin> | hm |
| 2021-11-01 14:46:40 +0100 | <Tisoxin> | I have a problem apart from records |
| 2021-11-01 14:47:06 +0100 | <[exa]> | dartford: re "safety", what would be the unsafe situation there? It starts consuming randomness forever? |
| 2021-11-01 14:47:34 +0100 | <[exa]> | also not sure what "scanners" is, pls elucidate. :] |
| 2021-11-01 14:48:37 +0100 | <dartford> | well suppose one traverse used StateR by mistake |
| 2021-11-01 14:49:02 +0100 | <dartford> | then it would hang, and none of the values would make it through to the next state update function aka scanner |
| 2021-11-01 14:49:20 +0100 | <Tisoxin> | dartford: I need the equivalent of `type Test = (String, Expr)`, where Expr should be a GADT |
| 2021-11-01 14:49:20 +0100 | <dartford> | [exa] scanners is just traversals where the applicative is restricted to StateL |
| 2021-11-01 14:49:37 +0100 | <dartford> | thats easy |
| 2021-11-01 14:49:39 +0100 | <[exa]> | ok good, and why should it hang? |
| 2021-11-01 14:49:46 +0100 | <[exa]> | it doesn't click still |
| 2021-11-01 14:49:55 +0100 | <dartford> | because if it tries to consume the last element first, and the stream is infinite... |
| 2021-11-01 14:49:59 +0100 | <Tisoxin> | `type Test = (Int, Expr (forall p. p))` apparently doesn't work yet (v. 8.10.7 GHC) |
| 2021-11-01 14:50:04 +0100 | <dartford> | you cant traverse streams from the right |
| 2021-11-01 14:50:20 +0100 | <dartford> | streams being strictly infinite lists |
| 2021-11-01 14:50:27 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-11-01 14:50:37 +0100 | chexum_ | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-11-01 14:50:50 +0100 | <dartford> | so, while i can write a Traversable instance, it might break, so i should just be contented with being restricted to using scanners instead |
| 2021-11-01 14:51:07 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-11-01 14:51:07 +0100 | <dartford> | ie, write a Scanner instance, not a Traversable instance, when you have a strictly infinite list |
| 2021-11-01 14:51:15 +0100 | max22- | (~maxime@lfbn-ren-1-762-224.w81-53.abo.wanadoo.fr) (Ping timeout: 260 seconds) |
| 2021-11-01 14:51:17 +0100 | <[exa]> | ah okay, cool, so basically you want a kinda-total subset of all possible operations on streams |
| 2021-11-01 14:51:42 +0100 | <dartford> | the traversables that dont hang |
| 2021-11-01 14:51:46 +0100 | <c_wraith> | lazy state is neither necessary nor sufficient for that |
| 2021-11-01 14:51:48 +0100 | <dartford> | traversals* |
| 2021-11-01 14:52:11 +0100 | <dartford> | c_wraith: there are some subtelties to do with IO we encountered yesterday |
| 2021-11-01 14:52:42 +0100 | <dartford> | basically, you have to have IO in the stack of composed StateL's if its going to be able to do anything |
| 2021-11-01 14:52:45 +0100 | <dartford> | is that what you mean? |
| 2021-11-01 14:52:51 +0100 | <dartford> | what else is wrong with it? |
| 2021-11-01 14:53:14 +0100 | <[exa]> | dartford: where did you get IO in there? |
| 2021-11-01 14:53:20 +0100 | <c_wraith> | using a lazy state type doesn't actually guarantee the operations you do with it are sufficiently non-strict |
| 2021-11-01 14:53:22 +0100 | <[exa]> | I thought it's a RNG monad :] |
| 2021-11-01 14:53:33 +0100 | <dartford> | oh no, even more stacked things |
| 2021-11-01 14:54:11 +0100 | <c_wraith> | and there are a lot of other Applicative instances which can work in certain cases. |
| 2021-11-01 14:54:16 +0100 | <dartford> | c_wraith: are you saying that depending on how the state update function uses the encoutered elements, that somehow they could demand the next element, and break the whole thing!? |
| 2021-11-01 14:54:19 +0100 | <dartford> | that would be terrible! |
| 2021-11-01 14:54:44 +0100 | <[exa]> | dartford: SW eng advice-- make a maximal sample that works for you now, and then show us how you break it, that's going to trigger people into solving it. For me this stuff here is pretty much too abstract. |
| 2021-11-01 14:54:47 +0100 | <dartford> | the IO thing was just because if you want it to return any effect before it reaches the end of the infinite stream |
| 2021-11-01 14:54:51 +0100 | <c_wraith> | yes, you can create unfounded circular data dependencies |
| 2021-11-01 14:55:02 +0100 | <dartford> | well, lets not do that |
| 2021-11-01 14:55:08 +0100 | <dartford> | :-/ |
| 2021-11-01 14:55:13 +0100 | <dartford> | not sure what to say really |
| 2021-11-01 14:55:20 +0100 | <dartford> | scanners recieve pushback |
| 2021-11-01 14:55:29 +0100 | <dartford> | i like the idea anyway |
| 2021-11-01 14:55:39 +0100 | <dartford> | i dont need traverse, just mapAccumL |
| 2021-11-01 14:55:42 +0100 | <dartford> | in some cases |
| 2021-11-01 14:55:43 +0100 | <[exa]> | dartford: to prevent the magic strictness from happening you can make your own "realworld token" and pass it around |
| 2021-11-01 14:55:52 +0100 | <c_wraith> | also, for what it's worth, you really should be modelling traverse_ instead of traverse |
| 2021-11-01 14:56:20 +0100 | <dartford> | [exa] that sounds utterly brutal |
| 2021-11-01 14:56:22 +0100 | <[exa]> | dartford: but at that point you just want to materialize a complete eDSL for it, and avoid reliance on haskell strictness rules |
| 2021-11-01 14:56:24 +0100 | <dartford> | but like it could work! |
| 2021-11-01 14:56:25 +0100 | <[exa]> | yep |
| 2021-11-01 14:56:41 +0100 | <dartford> | whats traverse_ ? |
| 2021-11-01 14:56:56 +0100 | <c_wraith> | part of Foldable |
| 2021-11-01 14:57:07 +0100 | <dartford> | oh, like >> instead of >>= ? to prevent some kind of applicative effect spilling over? |
| 2021-11-01 14:57:19 +0100 | <dartford> | % :t traverse_ |
| 2021-11-01 14:57:20 +0100 | <yahb> | dartford: (Foldable t, Applicative f) => (a -> f b) -> t a -> f () |
| 2021-11-01 14:57:24 +0100 | <[exa]> | yeah, basically `traverse ..thesame... >> return ()` |
| 2021-11-01 14:57:42 +0100 | <dartford> | no, it should update the contents to not be () |
| 2021-11-01 14:57:44 +0100 | <c_wraith> | To prevent memory waste caused by holding on to values that will never get returned |
| 2021-11-01 14:57:49 +0100 | <dartford> | otherwise it cant do mapAccumL |
| 2021-11-01 14:58:07 +0100 | <dartford> | its supposed to update the encountered elements, and change the carried state |
| 2021-11-01 14:58:16 +0100 | <[exa]> | dartford: then you want `($> ())` |
| 2021-11-01 14:58:42 +0100 | <[exa]> | (what's the human name for $> ? fmapconst?) |
| 2021-11-01 14:58:53 +0100 | <dartford> | the values will be returned? or they have to just be producing effects? |
| 2021-11-01 14:59:02 +0100 | <dartford> | er, i mean, no certainly they are returned |
| 2021-11-01 14:59:03 +0100 | <c_wraith> | I get the feeling that what you're really looking for is some kind of streaming abstraction |
| 2021-11-01 14:59:10 +0100 | <dartford> | thats how the next scanner has values to opperate on |
| 2021-11-01 14:59:24 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-11-01 14:59:31 +0100 | <dartford> | only the rewritten version, written into one overall state update function, acting on the full tuples of states |
| 2021-11-01 14:59:35 +0100 | <[exa]> | dartford: btw did you see Selective? I've got a serious feeling you're heading somewhere that way |
| 2021-11-01 14:59:36 +0100 | <dartford> | acts like you say |
| 2021-11-01 15:00:02 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 260 seconds) |
| 2021-11-01 15:00:21 +0100 | <dartford> | [exa] i was under the impression that what i had was very much complete, and superior in many ways to existing approaches of which im aware |
| 2021-11-01 15:00:32 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2021-11-01 15:02:24 +0100 | <[exa]> | dartford: I didn't see much of it yet, sorry :] |
| 2021-11-01 15:02:45 +0100 | <[exa]> | (likely missed a few important pastebins) |
| 2021-11-01 15:04:40 +0100 | <dartford> | is there a paper for selective? it looks like an actual thing |
| 2021-11-01 15:04:56 +0100 | <dminuoso> | Mmm, what kind of paper are you looking for? |
| 2021-11-01 15:04:58 +0100 | <dartford> | [exa] not to worry |
| 2021-11-01 15:05:03 +0100 | <dminuoso> | There's really not much to it |
| 2021-11-01 15:05:15 +0100 | <dartford> | this one i think! |
| 2021-11-01 15:05:15 +0100 | <dartford> | https://www.staff.ncl.ac.uk/andrey.mokhov/selective-functors.pdf |
| 2021-11-01 15:05:21 +0100 | <[exa]> | yep that one |
| 2021-11-01 15:05:28 +0100 | <dminuoso> | Yeah, that's the original paper |
| 2021-11-01 15:05:34 +0100 | <dartford> | dminuoso: whats the idea? |
| 2021-11-01 15:05:54 +0100 | <dminuoso> | dartford: So with selective functors you get something between applicative and monad. |
| 2021-11-01 15:05:55 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-11-01 15:05:55 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-11-01 15:05:55 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2021-11-01 15:06:31 +0100 | <dminuoso> | You have static analyzability, because the *potential* effects are predetermined, and yet you have the power of chosing effects based on previous results. |
| 2021-11-01 15:06:50 +0100 | <dminuoso> | They're kind of like monads but with predetermined possible outcomes |
| 2021-11-01 15:07:57 +0100 | <[exa]> | re static analyzability, I kinda hoped to use that here to get some easy assurances on whether the stuff terminates or explodes |
| 2021-11-01 15:08:02 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) |
| 2021-11-01 15:08:06 +0100 | <dminuoso> | One use case is say `optparse-applicative`, where this static analyzability allows the library to derive a parser and documentation from the specification. If we upgrade its applicative to selective functors, you can do something where say one command flag `-a` decides what further command flags are allowed. |
| 2021-11-01 15:08:32 +0100 | <dminuoso> | Another is if you had parser combinators with selective functors, you can statically analyze and optimize at compile time (say via TH). |
| 2021-11-01 15:09:26 +0100 | <maerwald> | dminuoso: https://imgflip.com/i/5skojf |
| 2021-11-01 15:09:28 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Read error: Connection reset by peer) |
| 2021-11-01 15:11:29 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 15:11:35 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-11-01 15:15:06 +0100 | ubert | (~Thunderbi@p548c9652.dip0.t-ipconnect.de) |
| 2021-11-01 15:17:57 +0100 | max22- | (~maxime@2a01cb088335980078b9d498c24675c0.ipv6.abo.wanadoo.fr) |
| 2021-11-01 15:18:53 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) |
| 2021-11-01 15:18:53 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) (Changing host) |
| 2021-11-01 15:18:53 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2021-11-01 15:19:57 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 260 seconds) |
| 2021-11-01 15:20:30 +0100 | JimL | (~quassel@89-162-2-132.fiber.signal.no) (Ping timeout: 260 seconds) |
| 2021-11-01 15:22:48 +0100 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 268 seconds) |
| 2021-11-01 15:23:20 +0100 | JimL | (~quassel@89-162-2-132.fiber.signal.no) |
| 2021-11-01 15:23:22 +0100 | tput | (~tim@S0106a84e3fe54613.ed.shawcable.net) (Ping timeout: 260 seconds) |
| 2021-11-01 15:25:02 +0100 | cigsender | (~cigsender@74.124.58.162) |
| 2021-11-01 15:28:49 +0100 | <Hecate> | cigsender: hello you :) |
| 2021-11-01 15:28:49 +0100 | img | (~img@user/img) |
| 2021-11-01 15:29:04 +0100 | <cigsender> | salut Hecate :p |
| 2021-11-01 15:29:13 +0100 | <Hecate> | cigsender: how are you doing? |
| 2021-11-01 15:29:47 +0100 | <cigsender> | not bad! pondering the CLC issues that have been sparking discussion |
| 2021-11-01 15:29:52 +0100 | <cigsender> | and you? |
| 2021-11-01 15:32:25 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2021-11-01 15:32:49 +0100 | Jing | (~textual@103.121.208.52) (Quit: Textual IRC Client: www.textualapp.com) |
| 2021-11-01 15:32:56 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2021-11-01 15:34:11 +0100 | <Hecate> | cigsender: pondering if I should pile-up with my own proposal to imitate Rust on having PartialEq/PartialOrd :3 |
| 2021-11-01 15:34:26 +0100 | <Hecate> | but we need the mechanism to change a typeclass's superclass ± seamlessly first |
| 2021-11-01 15:34:40 +0100 | <Hecate> | and I simply do not posess the brainpower to implement that |
| 2021-11-01 15:34:50 +0100 | <Hecate> | hmm |
| 2021-11-01 15:34:57 +0100 | <Hecate> | that being said we could have them separated |
| 2021-11-01 15:35:07 +0100 | <Hecate> | without any superclass dependency |
| 2021-11-01 15:35:38 +0100 | <Hecate> | and say "y'all we give you three years to add PartialEq & PartialOrd to your stuff" |
| 2021-11-01 15:36:01 +0100 | <maerwald> | we'll first have to come up with a new proposal process before we can discuss that |
| 2021-11-01 15:36:17 +0100 | <Hecate> | isn't there already the new proposal process, maerwald ? |
| 2021-11-01 15:36:18 +0100 | <cigsender> | a new proposal process for GHC? |
| 2021-11-01 15:36:28 +0100 | <Hecate> | I'm speaking of base here |
| 2021-11-01 15:36:46 +0100 | <maerwald> | a proposal process for asking questions |
| 2021-11-01 15:36:55 +0100 | <Hecate> | tss |
| 2021-11-01 15:36:59 +0100 | <Hecate> | silly maerwald |
| 2021-11-01 15:37:09 +0100 | <maerwald> | only occasionally |
| 2021-11-01 15:38:05 +0100 | cigsender | sighs in bureaucracy |
| 2021-11-01 15:38:28 +0100 | mjrosenb | (~mjrosenb@pool-108-54-97-96.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2021-11-01 15:38:47 +0100 | <Hecate> | oh btw cigsender, you're not in https://github.com/haskell-core/core-libraries-proposals ? |
| 2021-11-01 15:38:51 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 15:38:51 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 15:38:51 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 15:38:51 +0100 | <Hecate> | in the table of the README |
| 2021-11-01 15:39:16 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Read error: Connection reset by peer) |
| 2021-11-01 15:39:54 +0100 | <cigsender> | oh yeah the new link is https://github.com/haskell/core-libraries-committee |
| 2021-11-01 15:40:01 +0100 | <cigsender> | i'd never heard of that other one |
| 2021-11-01 15:40:06 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2021-11-01 15:40:13 +0100 | <Hecate> | :'') |
| 2021-11-01 15:40:21 +0100 | <Hecate> | I had it in my browser history apparently |
| 2021-11-01 15:40:33 +0100 | <Hecate> | chessai should remove that org |
| 2021-11-01 15:41:00 +0100 | geekosaur | keeps misreading that /nick as "cisgender" and wondering why you'd point that up |
| 2021-11-01 15:41:52 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-11-01 15:42:19 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-11-01 15:42:32 +0100 | alx741 | (~alx741@181.196.69.253) (Ping timeout: 268 seconds) |
| 2021-11-01 15:44:02 +0100 | jespada | (~jespada@190.7.36.46) |
| 2021-11-01 15:44:28 +0100 | Fred9 | (~Fred@78-73-197-175-no2480.tbcn.telia.com) |
| 2021-11-01 15:46:10 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) |
| 2021-11-01 15:46:10 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) (Changing host) |
| 2021-11-01 15:46:10 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2021-11-01 15:46:44 +0100 | <Hecate> | geekosaur: yes, same brainfart here |
| 2021-11-01 15:46:45 +0100 | <Hecate> | :D |
| 2021-11-01 15:46:58 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Read error: Connection reset by peer) |
| 2021-11-01 15:49:21 +0100 | betelgeuse | (~betelgeus@94-225-47-8.access.telenet.be) |
| 2021-11-01 15:49:46 +0100 | <maerwald> | . o O ( maybe a proposal process for all my issue trackers ) |
| 2021-11-01 15:50:37 +0100 | TomWesterhout[m] | (~twesterho@2001:470:69fc:105::1:2918) |
| 2021-11-01 15:52:41 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 15:52:41 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 15:52:41 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 15:53:47 +0100 | drdo6 | (~drdo@roach0.drdo.eu) |
| 2021-11-01 15:55:06 +0100 | johnjay | (~pi@192.142.100.50) (Ping timeout: 260 seconds) |
| 2021-11-01 15:55:34 +0100 | drdo | (~drdo@roach0.drdo.eu) (Ping timeout: 260 seconds) |
| 2021-11-01 15:55:34 +0100 | drdo6 | drdo |
| 2021-11-01 15:56:51 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-11-01 15:56:51 +0100 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-11-01 15:56:51 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2021-11-01 15:57:46 +0100 | johnjay | (~pi@192.142.100.50) |
| 2021-11-01 15:57:51 +0100 | <cigsender> | the trick is: i'm not cisgender :D |
| 2021-11-01 15:58:12 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) (Quit: Connection closed) |
| 2021-11-01 15:58:16 +0100 | <merijn> | I pretty much assumed that was an intentional spoonerism for that reason |
| 2021-11-01 15:59:02 +0100 | <merijn> | I get irrationally annoyed by the name, because my brain wants to parse it as, like, SIGSENDER or some other unix signal >.> |
| 2021-11-01 15:59:21 +0100 | <maerwald> | that's some serious PTSD right there :D |
| 2021-11-01 15:59:31 +0100 | tdwamdors^ | (~tdwamdors@wsip-98-188-242-6.mc.at.cox.net) (Remote host closed the connection) |
| 2021-11-01 15:59:53 +0100 | <merijn> | maerwald: I had to dig through cpython source code with an open APUE to figure out what they broke and how, so yes :p |
| 2021-11-01 16:01:34 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2021-11-01 16:02:50 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-11-01 16:03:26 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 16:04:16 +0100 | <maerwald> | I'll switch gladly with you, then you can try to figure out how blockchains work |
| 2021-11-01 16:04:25 +0100 | <merijn> | Easy |
| 2021-11-01 16:04:33 +0100 | <merijn> | They don't. Next question :) |
| 2021-11-01 16:04:53 +0100 | <maerwald> | next question would be: how did I end up here |
| 2021-11-01 16:04:56 +0100 | maerwald | mumbles |
| 2021-11-01 16:06:21 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:1b26:eada:1c7:e76b) (Quit: WeeChat 2.8) |
| 2021-11-01 16:07:09 +0100 | <merijn> | So, in Dutch (and German, I think?) we have a term for "feeling shame for someone else's behaviour". I wonder if we can invent a similar term for when other people's behaviour traumatises me in their place. Because that'd describe the effect of "everyone else's posix code" on me >.> |
| 2021-11-01 16:07:44 +0100 | <maerwald> | posix has principles at least, even if some are misguided |
| 2021-11-01 16:08:26 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-11-01 16:09:10 +0100 | <maerwald> | also, I've been looking more closely into windows filesystem API |
| 2021-11-01 16:09:17 +0100 | <maerwald> | so if you think you've seen it all... well |
| 2021-11-01 16:09:28 +0100 | <merijn> | maerwald: My complaint isn't with posix |
| 2021-11-01 16:09:43 +0100 | <merijn> | maerwald: My complaint is that people write *terrible* posix code using deprecated and broken interfaces |
| 2021-11-01 16:09:50 +0100 | <maerwald> | well, posix provides difficult APIs |
| 2021-11-01 16:09:59 +0100 | <merijn> | Yes, but people *think* they're easy |
| 2021-11-01 16:10:32 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 16:10:54 +0100 | acidjnk | (~acidjnk@p200300d0c74411311cbabef3984b18e3.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2021-11-01 16:11:14 +0100 | <maerwald> | well, I looked at posix_spawn and the process code that uses it... it's also a family of functions (as always) with initilization and all sorts of stuff you don't care about |
| 2021-11-01 16:11:31 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Ping timeout: 268 seconds) |
| 2021-11-01 16:12:02 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 16:12:02 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 16:12:02 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 16:12:09 +0100 | <maerwald> | it's almost like you need an algorithm to correctly use posix API |
| 2021-11-01 16:13:41 +0100 | <maerwald> | windows API documentation is much nicer... the awful details are usually 5 clicks away and the base page gives you an impression of "wow, this function is surely well-defined" |
| 2021-11-01 16:13:44 +0100 | <maerwald> | until you run it |
| 2021-11-01 16:13:58 +0100 | <shapr> | @quote |
| 2021-11-01 16:13:58 +0100 | <lambdabot> | xentrac says: I [15;2~|" |
| 2021-11-01 16:14:02 +0100 | <shapr> | whoa |
| 2021-11-01 16:15:13 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Ping timeout: 268 seconds) |
| 2021-11-01 16:15:46 +0100 | zys | (~zys@116.21.145.62) |
| 2021-11-01 16:21:42 +0100 | zys | (~zys@116.21.145.62) (Ping timeout: 260 seconds) |
| 2021-11-01 16:23:26 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-11-01 16:24:51 +0100 | mjrosenb | (~mjrosenb@pool-108-54-97-96.nycmny.fios.verizon.net) |
| 2021-11-01 16:25:00 +0100 | cigsender | (~cigsender@74.124.58.162) (Quit: Lost terminal) |
| 2021-11-01 16:26:34 +0100 | alx741 | (~alx741@181.196.69.253) |
| 2021-11-01 16:28:44 +0100 | cigsender | (~cigsender@74.124.58.162) |
| 2021-11-01 16:31:14 +0100 | Farzad | (~FarzadBek@178.131.25.90) (Quit: Leaving) |
| 2021-11-01 16:35:12 +0100 | sy4 | (~sy4@user/sy4) (Quit: WeeChat 1.9.1) |
| 2021-11-01 16:35:34 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2021-11-01 16:35:42 +0100 | jespada | (~jespada@190.7.36.46) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-11-01 16:37:20 +0100 | jespada | (~jespada@190.7.36.46) |
| 2021-11-01 16:37:39 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-11-01 16:38:02 +0100 | jespada | (~jespada@190.7.36.46) (Client Quit) |
| 2021-11-01 16:40:51 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 16:44:15 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 16:44:42 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2021-11-01 16:45:18 +0100 | Fred9 | (~Fred@78-73-197-175-no2480.tbcn.telia.com) (Quit: Connection closed) |
| 2021-11-01 16:48:11 +0100 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-11-01 16:48:59 +0100 | Null_A | (~null_a@2601:645:8700:2290:f456:9370:22df:9c55) |
| 2021-11-01 16:51:01 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 16:52:41 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Quit: Leaving.) |
| 2021-11-01 16:52:57 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 16:52:57 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Client Quit) |
| 2021-11-01 16:53:25 +0100 | fendor__ | (~fendor@77.119.197.65.wireless.dyn.drei.com) |
| 2021-11-01 16:54:41 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2021-11-01 16:55:24 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 16:55:42 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 16:56:33 +0100 | fendor_ | (~fendor@77.119.160.25.wireless.dyn.drei.com) (Ping timeout: 268 seconds) |
| 2021-11-01 16:56:57 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2021-11-01 16:58:45 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Client Quit) |
| 2021-11-01 16:59:25 +0100 | acidsys | (~LSD@2.lsd.systems) (Excess Flood) |
| 2021-11-01 16:59:57 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 17:00:00 +0100 | acidsys | (~LSD@2.lsd.systems) |
| 2021-11-01 17:01:10 +0100 | <[exa]> | ignoring the fact that unbounded dependencies are Just Bad, is there any reason why would cabal choose to install a historical brick-0.26 incompatible with any current base in case I specify unbounded `build-depends: base, brick, vty, vector` ? |
| 2021-11-01 17:01:22 +0100 | <[exa]> | (alternatively, is there any option for tracking the decisions & finding why's ? |
| 2021-11-01 17:01:48 +0100 | myShoggoth | (~myShoggot@97-120-85-195.ptld.qwest.net) |
| 2021-11-01 17:02:12 +0100 | <myShoggoth> | Haskell Foundation Office Hours: https://www.twitch.tv/myshoggoth |
| 2021-11-01 17:02:28 +0100 | <c_wraith> | was there a previous build plan for that project that it might still be getting some version info from? |
| 2021-11-01 17:02:34 +0100 | <maerwald> | [exa]: it has less dependencies... check the diff of them |
| 2021-11-01 17:02:38 +0100 | <maerwald> | one of them must be the reason |
| 2021-11-01 17:03:05 +0100 | <[exa]> | like, if I specify something sane like `brick > 0.60`, the new version (0.64.2 afaik) gets installed without any problems |
| 2021-11-01 17:03:21 +0100 | <[exa]> | so just kinda thinking why cabal decides on the older |
| 2021-11-01 17:03:54 +0100 | <[exa]> | "less dependencies" is a criterion for selection? |
| 2021-11-01 17:04:02 +0100 | <maerwald> | no |
| 2021-11-01 17:04:05 +0100 | <shapr> | myShoggoth: whoa, I'll come to office hours if these happen regularly. |
| 2021-11-01 17:04:07 +0100 | <[exa]> | c_wraith: how do I find that? |
| 2021-11-01 17:04:30 +0100 | <[exa]> | (the project is completely new and fresh) |
| 2021-11-01 17:04:33 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Ping timeout: 268 seconds) |
| 2021-11-01 17:04:38 +0100 | <c_wraith> | then no, there wouldn't be. |
| 2021-11-01 17:04:53 +0100 | <maerwald> | it's possible that it's trying older versions before e.g. checking different flag configuration |
| 2021-11-01 17:05:07 +0100 | <[exa]> | hm that could work with brick+vty |
| 2021-11-01 17:06:49 +0100 | <jlamothe> | Does anyone know if there's an equivalent to bracket that'll work on an arbitrary MonadIO? |
| 2021-11-01 17:07:21 +0100 | <maerwald> | @hoogle bracket |
| 2021-11-01 17:07:22 +0100 | <lambdabot> | Control.Exception bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c |
| 2021-11-01 17:07:22 +0100 | <lambdabot> | Control.Exception.Base bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c |
| 2021-11-01 17:07:22 +0100 | <lambdabot> | GHC.IO bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c |
| 2021-11-01 17:07:53 +0100 | <c_wraith> | jlamothe: that's not possible in general. But there are several packages that provide classes that can work, like MonadCatch |
| 2021-11-01 17:08:04 +0100 | <cigsender> | jlamothe: check in UnliftIO? there's a bunch of MonadIO versions of base functions there |
| 2021-11-01 17:08:21 +0100 | <maerwald> | https://hackage.haskell.org/package/exceptions-0.10.4/docs/Control-Monad-Catch.html#v:bracket |
| 2021-11-01 17:08:24 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 17:08:24 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 17:08:24 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 17:08:28 +0100 | <maerwald> | no need to look in unliftioo |
| 2021-11-01 17:08:53 +0100 | <jlamothe> | That's what I thought. I basically wanted to confirm that I wasn't missing something. |
| 2021-11-01 17:09:14 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Ping timeout: 260 seconds) |
| 2021-11-01 17:10:35 +0100 | <jlamothe> | It's fine. I can work with just a regular IO. I was just trying (unsuccessfully) to be fancy. |
| 2021-11-01 17:10:49 +0100 | <c_wraith> | [exa]: what version of ghc? |
| 2021-11-01 17:11:31 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 17:12:19 +0100 | <jlamothe> | I generally hate exceptions. I much prefer functions whose output types have a way of representing a failure state, then you don't have to worry about forgetting to catch it. |
| 2021-11-01 17:14:05 +0100 | <[exa]> | c_wraith: 9.0.1, fresh from the binary builds, same cabal |
| 2021-11-01 17:14:47 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Remote host closed the connection) |
| 2021-11-01 17:15:45 +0100 | <c_wraith> | [exa]: hmm. testing with ghc 9.2 makes me suspicious... |
| 2021-11-01 17:16:50 +0100 | <c_wraith> | [exa]: yeah, I think I see what's going on. brick 0.26 has a base <5 constraint. starting at 0.26.1, it gets a tighter bound on base |
| 2021-11-01 17:17:15 +0100 | <[exa]> | aaaaaah yes that could make some sense |
| 2021-11-01 17:17:15 +0100 | <c_wraith> | [exa]: I think the solver is preferring wider version bounds |
| 2021-11-01 17:17:49 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 17:18:32 +0100 | <[exa]> | yeah that makes sense because the 0.26 actually fails on Monoid/Semigroup portability bug |
| 2021-11-01 17:19:14 +0100 | <[exa]> | ....someone could really fix that in hackage. :D |
| 2021-11-01 17:19:37 +0100 | <[exa]> | anyway yeah thanks for catching this, sounds plausible to me |
| 2021-11-01 17:21:58 +0100 | <maerwald> | c_wraith: that sounds like a bug :> |
| 2021-11-01 17:22:05 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 17:22:09 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Remote host closed the connection) |
| 2021-11-01 17:22:47 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) |
| 2021-11-01 17:23:40 +0100 | <[exa]> | oioi |
| 2021-11-01 17:24:48 +0100 | <[exa]> | no like, technically there's no problem with picking that version (from cabal side) because it looks plausible and certainly seems to cause less compilation |
| 2021-11-01 17:26:01 +0100 | <c_wraith> | maerwald: doesn't sound like a bug to me. it's a heuristic for finding *some* package set that satisfies the requested constraints. |
| 2021-11-01 17:26:25 +0100 | <c_wraith> | I would say maybe it's not an ideal heuristic. but that's not the same as being just wrong. |
| 2021-11-01 17:26:53 +0100 | <maerwald> | it's picking an older version, while a newer version would satisfy the constraints as well |
| 2021-11-01 17:27:05 +0100 | <maerwald> | that's undesired |
| 2021-11-01 17:27:07 +0100 | <geekosaur> | how's it supposed to know it's wrong? it needs the constraints to make sense |
| 2021-11-01 17:28:24 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-11-01 17:29:36 +0100 | <c_wraith> | isn't there a package manager for another language that, by policy, will always pick the oldest set of packages that satisfy the constraints? |
| 2021-11-01 17:29:48 +0100 | <c_wraith> | people don't always want the newest thing. |
| 2021-11-01 17:30:29 +0100 | <c_wraith> | (I think lock files are a better solution to what that package manager was trying to do, but that's a different issue) |
| 2021-11-01 17:31:57 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-11-01 17:33:34 +0100 | Lycurgus | (~juan@98.4.112.204) |
| 2021-11-01 17:33:52 +0100 | <maerwald> | I think the number of people who expect this behavior is low |
| 2021-11-01 17:34:06 +0100 | ystael | (~ystael@user/ystael) |
| 2021-11-01 17:36:58 +0100 | <c_wraith> | which provides a good argument that the heuristic could be improved. but that's not the same as "this is a bug" |
| 2021-11-01 17:37:40 +0100 | <c_wraith> | a big would imply it wasn't fulfilling its spec. it is here... the spec is very loose. |
| 2021-11-01 17:38:07 +0100 | <c_wraith> | my spelling, on the other hand, might be considered buggy |
| 2021-11-01 17:39:14 +0100 | <[exa]> | maerwald: you might get "recompile everything after each cabal update" if you forced newer versions... but yeah here it could make some sense |
| 2021-11-01 17:39:26 +0100 | <maerwald> | c_wraith: we can debate semantics of the term "bug", sure |
| 2021-11-01 17:39:36 +0100 | <maerwald> | I think breaking users expectations is a bug |
| 2021-11-01 17:39:39 +0100 | <[exa]> | I assume the brick 0.26 version in hackage can't be "fixed" anymore? |
| 2021-11-01 17:39:56 +0100 | <maerwald> | [exa]: I think it can be marked as deprecated |
| 2021-11-01 17:39:59 +0100 | <maerwald> | which affects the solver |
| 2021-11-01 17:40:13 +0100 | <c_wraith> | a metadata revision could also be issued |
| 2021-11-01 17:40:19 +0100 | <[exa]> | where's the button for that? :D |
| 2021-11-01 17:40:32 +0100 | <maerwald> | you need to be a maintainer to do that |
| 2021-11-01 17:40:42 +0100 | <c_wraith> | I'm not sure anyone other than hackage trustees can do that |
| 2021-11-01 17:40:58 +0100 | <geekosaur> | hm. wouldn't you have to deprecate it and all earlier versions, in case it decides to build an even older one? |
| 2021-11-01 17:41:09 +0100 | <[exa]> | likely |
| 2021-11-01 17:41:25 +0100 | <awpr> | I revise my version bounds all the time. it's not limited to Hackage trustees |
| 2021-11-01 17:41:47 +0100 | <c_wraith> | I used to work with the author of brick. but I no longer have a convenient way to yell at him. :P |
| 2021-11-01 17:41:52 +0100 | <[exa]> | so the best way to communicate that would be IMO to open an issue in brick repo? |
| 2021-11-01 17:42:22 +0100 | ByronJohnson | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) (Ping timeout: 260 seconds) |
| 2021-11-01 17:42:30 +0100 | <maerwald> | only time will tell |
| 2021-11-01 17:42:50 +0100 | <[exa]> | I'm going to open it and see |
| 2021-11-01 17:48:02 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-11-01 17:48:03 +0100 | <sm> | cabal's "randomly" picking an ancient version on any given day is if not a functionality bug, certainly a terrible ux fail |
| 2021-11-01 17:48:20 +0100 | <sclv> | it doesn't randomly pick ancient versions on any given day |
| 2021-11-01 17:48:30 +0100 | <sclv> | it has a greedy solver that tries newest first |
| 2021-11-01 17:48:38 +0100 | <sclv> | and is deterministic |
| 2021-11-01 17:48:42 +0100 | <c_wraith> | in some sense, it was trying to maximize for forward compatibility |
| 2021-11-01 17:48:46 +0100 | ByronJohnson | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) |
| 2021-11-01 17:49:08 +0100 | <c_wraith> | sclv: well, as we've discovered, that isn't exactly what it does. |
| 2021-11-01 17:49:14 +0100 | <sclv> | but there's no perfect heuristic and also solving is np complete so moving to a nongreedy algorithm could introduce significant complexity |
| 2021-11-01 17:49:22 +0100 | <geekosaur> | rather than my doing a cabal update and having my whole xmonad+contrib setup getting rebuilt? |
| 2021-11-01 17:49:29 +0100 | <sclv> | c_wraith: i mean, in the code, its literally a greedy algorithm |
| 2021-11-01 17:49:33 +0100 | <sclv> | that tries newest first |
| 2021-11-01 17:49:49 +0100 | <sclv> | if it didn't do that, that's because there's some backtracking issue that drove it away from that goal |
| 2021-11-01 17:49:49 +0100 | <maerwald> | sm: well, what's the alternative: don't solve at all? :D |
| 2021-11-01 17:49:54 +0100 | <c_wraith> | sclv: it appears that it tries the thing with the highest version bound first. |
| 2021-11-01 17:50:12 +0100 | <c_wraith> | sclv: otherwise it wouldn't prefer brick 0.26 |
| 2021-11-01 17:50:18 +0100 | <awpr> | perhaps it chose the newest base and then chose the only brick that worked with that? |
| 2021-11-01 17:50:22 +0100 | <sclv> | hrm, that doesn't sound right -- i would check the code |
| 2021-11-01 17:50:27 +0100 | <sm> | maerwald: that's an alternative yes, hence stack |
| 2021-11-01 17:50:37 +0100 | <maerwald> | sm: and when you NEED a solver, you do what? :) |
| 2021-11-01 17:50:39 +0100 | <sclv> | the solver is big but its factored to be easy to read |
| 2021-11-01 17:50:49 +0100 | <sclv> | also you can look at the -v3 trace of the solver to see why its making choices |
| 2021-11-01 17:50:59 +0100 | Null_A | (~null_a@2601:645:8700:2290:f456:9370:22df:9c55) (Remote host closed the connection) |
| 2021-11-01 17:51:02 +0100 | <sm> | you use it obviously. There's a right time for each approach |
| 2021-11-01 17:51:02 +0100 | <geekosaur> | I don't think it can choose the newest base, base is pinned by the compiler |
| 2021-11-01 17:51:10 +0100 | <maerwald> | sm: except stack doesn't have one |
| 2021-11-01 17:51:23 +0100 | <sm> | I didn't say it did! |
| 2021-11-01 17:51:29 +0100 | <c_wraith> | [exa]: any chance you're actually on GHC 9.2? |
| 2021-11-01 17:51:33 +0100 | <sclv> | like if it tries to pick a newer something else first, and the newer bricks have upper bounds on that thing, then that'll cause an older brick to be picked |
| 2021-11-01 17:51:36 +0100 | <maerwald> | sm: right, but you don't need stack to disable the solver |
| 2021-11-01 17:51:36 +0100 | <sclv> | because it is greedy |
| 2021-11-01 17:51:54 +0100 | <sclv> | instead, if you disallow that, then it is forced to use a newer brick and bactrack on the older choice |
| 2021-11-01 17:52:09 +0100 | <sclv> | greedy algos vary in their result based on the order of goals |
| 2021-11-01 17:52:19 +0100 | <sclv> | there's goal reordering heuristics in cabal, but they're necesarily ad hoc |
| 2021-11-01 17:52:23 +0100 | <c_wraith> | because pure greedy based on version would explain this if you ran it against GHC 9.2 |
| 2021-11-01 17:54:19 +0100 | hololeap | (~hololeap@user/hololeap) (Remote host closed the connection) |
| 2021-11-01 17:54:21 +0100 | <[exa]> | c_wraith: 9.0.1 |
| 2021-11-01 17:54:52 +0100 | thyriaen | (~thyriaen@dynamic-077-011-154-101.77.11.pool.telefonica.de) |
| 2021-11-01 17:55:08 +0100 | johnny_sitar | (~artur@078088015209.bialystok.vectranet.pl) (Ping timeout: 268 seconds) |
| 2021-11-01 17:55:26 +0100 | v01d4lph4 | (~v01d4lph4@106.215.90.6) |
| 2021-11-01 17:55:26 +0100 | v01d4lph4 | (~v01d4lph4@106.215.90.6) (Changing host) |
| 2021-11-01 17:55:26 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 17:55:43 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2021-11-01 17:55:50 +0100 | <maerwald> | windows filetime epoch starts in 1601-01-01 ... that's honestly how this OS feels like |
| 2021-11-01 17:56:06 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Read error: Connection reset by peer) |
| 2021-11-01 17:56:36 +0100 | <[exa]> | re brick version bounds, feel free to discuss here https://github.com/jtdaugherty/brick/issues/341 |
| 2021-11-01 17:56:37 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 17:56:37 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 17:56:37 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 17:57:15 +0100 | <janus> | maerwald: at least it has broken compat with the Antikythera mechanism from 87 BC :P |
| 2021-11-01 17:57:24 +0100 | <[exa]> | awpr: I assume there's no weird trick needed for changing of the dependencies in hackage and it just works? |
| 2021-11-01 17:57:52 +0100 | thyriaen | (~thyriaen@dynamic-077-011-154-101.77.11.pool.telefonica.de) (Client Quit) |
| 2021-11-01 17:58:16 +0100 | <awpr> | right, there's a link on the package page to edit package information, and from there a link to edit each version's cabal file (only maintainers + trustees can access it, though) |
| 2021-11-01 17:58:50 +0100 | v01d4lph_ | (~v01d4lph4@106.215.91.221) |
| 2021-11-01 17:59:39 +0100 | Papa_ | papa |
| 2021-11-01 17:59:48 +0100 | <sm> | my point: a solver as free and powerful as cabal's current default behavior is not ideal for most users - it is too smart for them to predict and on any given day depending on factors they can't see, it can suddenly give new and unexpected results. most of the time it works brilliantly but it can't be completely relied on, without special extra configuration |
| 2021-11-01 17:59:59 +0100 | <sclv> | right. any maintainer can add correct upper bounds to their package, and they can use the matrix for that |
| 2021-11-01 18:00:11 +0100 | <sclv> | to see what works and doesnt |
| 2021-11-01 18:00:34 +0100 | <sclv> | trustees get involved when maintainers are not available or responsive |
| 2021-11-01 18:00:41 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Ping timeout: 268 seconds) |
| 2021-11-01 18:00:57 +0100 | <sclv> | re solvers: there's no such thing as a "dumber" solver. you either solve bounds or you dont |
| 2021-11-01 18:01:23 +0100 | dsrt^ | (~dsrt@wsip-98-188-242-6.mc.at.cox.net) |
| 2021-11-01 18:01:53 +0100 | <sm> | sclv: I can imagine adding some extra constraints and safety belts though |
| 2021-11-01 18:02:14 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Remote host closed the connection) |
| 2021-11-01 18:05:18 +0100 | fendor__ | fendor |
| 2021-11-01 18:07:34 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 18:10:03 +0100 | econo | (uid147250@user/econo) |
| 2021-11-01 18:10:31 +0100 | <[exa]> | sclv: is there any quick way to project the fails from matrix into version bounds? :] (the response was fast, here: https://github.com/jtdaugherty/brick/issues/341#issuecomment-956409689 ) |
| 2021-11-01 18:10:46 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) |
| 2021-11-01 18:12:17 +0100 | <awpr> | +1, I would find that useful too -- I anticipate a lot of my packages will work with 9.2 at all versions, and manually typing in the cabal file changes to each one sounds unpleasant |
| 2021-11-01 18:12:22 +0100 | <sm> | (eg, save the plan on first success and stick to it until told otherwise ?) |
| 2021-11-01 18:13:00 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 18:13:11 +0100 | <awpr> | er, I was responding to the GitHub comment rather than the IRC message -- want a CLI for bumping version bounds, rather than automation of updating bounds according to the matrix |
| 2021-11-01 18:13:24 +0100 | thonkpod | (~thonkpod@user/thonkpod) (Ping timeout: 260 seconds) |
| 2021-11-01 18:14:52 +0100 | <[exa]> | I guess you want a better CLI than a sed exercise right. :] |
| 2021-11-01 18:15:13 +0100 | thonkpod | (~thonkpod@user/thonkpod) |
| 2021-11-01 18:15:16 +0100 | <awpr> | sed would be fine, I suppose, but I don't know of a way to apply it to the metadata on Hackage |
| 2021-11-01 18:15:50 +0100 | <awpr> | I suppose there could be a curl-accessible way of uploading revisions, but I'm not sure I'd trust my own sed script with pushing directly to Hackage |
| 2021-11-01 18:17:22 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) |
| 2021-11-01 18:18:08 +0100 | <[exa]> | maybe something for just downloading all packages/metadata to a git repo and pushing the changed stuff back could make 99% of it |
| 2021-11-01 18:18:18 +0100 | rkrishnan | (~user@223.226.59.167) (Ping timeout: 260 seconds) |
| 2021-11-01 18:24:10 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 18:29:03 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Ping timeout: 268 seconds) |
| 2021-11-01 18:29:11 +0100 | <dartford> | i have to say, i cant understand why selective was proposed for this problem |
| 2021-11-01 18:30:06 +0100 | <dartford> | maybe its because of the carry? |
| 2021-11-01 18:30:10 +0100 | <dartford> | is that a decent use case? |
| 2021-11-01 18:30:28 +0100 | <dartford> | the "accumulater" or state in mapAccumL |
| 2021-11-01 18:30:55 +0100 | <dartford> | the paper mentions about "depending on previous values" - i wonder if selective formalises the notion of an accumlator or carry |
| 2021-11-01 18:31:10 +0100 | <dartford> | but perhaps i dont understand it, can anyone say? |
| 2021-11-01 18:31:31 +0100 | <[exa]> | dartford: not sure if it's the right abstraction but it adds the notion of a "regularly analyzable computation" which you kinda seemed to want |
| 2021-11-01 18:31:46 +0100 | <[exa]> | dartford: I might have missed the point as well |
| 2021-11-01 18:32:34 +0100 | <dartford> | this probably isnt the language i would understand unfortunately |
| 2021-11-01 18:32:54 +0100 | <dartford> | is what i said right? |
| 2021-11-01 18:33:44 +0100 | Guest41 | (~Guest41@eth-west-pareq2-46-193-4-100.wb.wifirst.net) |
| 2021-11-01 18:33:49 +0100 | <dartford> | what makes you think that a "regularly analyzable computation" is what i was after? |
| 2021-11-01 18:34:11 +0100 | <dartford> | seems like a tuatological redefinition, since it isnt itself comprehensible in an obvious way |
| 2021-11-01 18:34:20 +0100 | <dartford> | place is riddled with them |
| 2021-11-01 18:35:43 +0100 | <dartford> | i dont even understand how applicative effects are suposed to be independent |
| 2021-11-01 18:35:55 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-11-01 18:36:03 +0100 | <dartford> | and that monadic effects by contrast are "dependent on previous effects" |
| 2021-11-01 18:36:14 +0100 | <dartford> | and i dont get what it means to "statically declare an effect" |
| 2021-11-01 18:36:24 +0100 | <dartford> | its like gibberish soup at this point |
| 2021-11-01 18:36:49 +0100 | <sclv> | dartford: it sounds to me like you don't have enough background in the basics to be trying to ask the questions you're asking |
| 2021-11-01 18:37:17 +0100 | <sclv> | you can try writing the code you want directly with no typeclasses |
| 2021-11-01 18:37:23 +0100 | <dartford> | [exa] why did you think thats what i need? |
| 2021-11-01 18:37:24 +0100 | <sclv> | or you can buckle up and read some tutorials and ooks |
| 2021-11-01 18:37:28 +0100 | <sclv> | books |
| 2021-11-01 18:37:51 +0100 | <dartford> | thats quite condescending. just an observation |
| 2021-11-01 18:38:25 +0100 | <[exa]> | dartford: it helped me when trying to do a monad that computes weirdly measured dimensions of stuff, this seemed similar :] |
| 2021-11-01 18:38:40 +0100 | <dartford> | what does it mean to "declare" an effect? |
| 2021-11-01 18:38:58 +0100 | <[exa]> | dartford: anyway the truth is that I really don't get your problem completely, more code examples of what you want to achieve would really help |
| 2021-11-01 18:39:01 +0100 | <davean> | declare, definition: formally announce the beginning of (a state or condition). |
| 2021-11-01 18:39:04 +0100 | <sclv> | [exa]: the matrix bounds can turn into base constraints, which can suffice. |
| 2021-11-01 18:39:04 +0100 | <dartford> | [exa] - ah, no wonder that wasnt apparent! |
| 2021-11-01 18:39:09 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-11-01 18:39:16 +0100 | <davean> | reveal one's intentions or identity. |
| 2021-11-01 18:39:48 +0100 | <[exa]> | "write a part of declarative program" |
| 2021-11-01 18:39:50 +0100 | <dartford> | [exa] i was just asking what selective does |
| 2021-11-01 18:40:52 +0100 | <dartford> | or, how applicative is "independent" effects, vs monads as effects which can depend on previous effects |
| 2021-11-01 18:40:58 +0100 | <dartford> | i dont see how that works at all |
| 2021-11-01 18:41:08 +0100 | <dartford> | but have plenty of "background" in both |
| 2021-11-01 18:41:11 +0100 | <davean> | dartford: well, look at the type class |
| 2021-11-01 18:41:18 +0100 | <davean> | No, you clearly lack background |
| 2021-11-01 18:41:25 +0100 | <sclv> | [exa]: there's also https://github.com/phadej/trustee |
| 2021-11-01 18:41:56 +0100 | <davean> | dartford: so with Applicative you get "(<*>) :: f (a -> b) -> f a -> f b" |
| 2021-11-01 18:42:04 +0100 | <davean> | as your (only) way to combine effects |
| 2021-11-01 18:42:08 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 18:42:12 +0100 | <dartford> | davean: right, i dont understand the jargon. but have been using applicative and monad for nearly 15 years now |
| 2021-11-01 18:42:18 +0100 | <[exa]> | dartford: ah there. it's like applicatives, it can do effects that depend on previous effects, but it's highly restricted (unlike in full monads). The restriction could ensure that you almost get monads but don't do the problematic operation you were mentioning there |
| 2021-11-01 18:42:20 +0100 | <sclv> | [exa]: and i know some people have bulk edit scripts but i don't know where. you can just open a ticket at https://github.com/haskell-infra/hackage-trustees/issues to ask for help as well |
| 2021-11-01 18:42:39 +0100 | <davean> | dartford: how could you change one given one you combined before it? You clearly can't |
| 2021-11-01 18:42:50 +0100 | <[exa]> | sclv: ah nice thanks! (cc awpr -- the link some 6 lines above) |
| 2021-11-01 18:43:15 +0100 | <dartford> | which probelamatic opperation!? |
| 2021-11-01 18:43:50 +0100 | <[exa]> | dartford: eating data from an end of an infinite list, iirc |
| 2021-11-01 18:43:51 +0100 | <dartford> | davean: are you saying the order of sequential composition matters? |
| 2021-11-01 18:43:59 +0100 | <davean> | dartford: no, I didn't say that |
| 2021-11-01 18:44:07 +0100 | <sclv> | ?where lyah |
| 2021-11-01 18:44:07 +0100 | <lambdabot> | http://www.learnyouahaskell.com/ |
| 2021-11-01 18:44:11 +0100 | <dartford> | could you explain what you meant? |
| 2021-11-01 18:44:37 +0100 | <dartford> | [exa] oh right, thanks |
| 2021-11-01 18:45:10 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 18:45:30 +0100 | <davean> | dartford: I give you a :: f a and b :: f b, if I combine them - in either order - how can you change what f a or f b is? |
| 2021-11-01 18:45:39 +0100 | <davean> | you very clearly can't |
| 2021-11-01 18:46:07 +0100 | <davean> | Applicatively only gives you the ability to build an f c using the a and bs |
| 2021-11-01 18:47:48 +0100 | <dartford> | i wonder if thats because they sequence together in an order independent way... |
| 2021-11-01 18:48:01 +0100 | <davean> | Really though, you should read a tutorial |
| 2021-11-01 18:49:03 +0100 | <dartford> | i just read some of the comments people were saying about me at the top of this chatlog and im actually on the verge of tears |
| 2021-11-01 18:49:12 +0100 | <dartford> | im going to have to come back to this another time |
| 2021-11-01 18:49:14 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) (Quit: Connection closed) |
| 2021-11-01 18:50:01 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 18:52:54 +0100 | <maerwald> | https://haskellweekly.news/survey/2021.html |
| 2021-11-01 18:56:35 +0100 | mbuf | (~Shakthi@122.174.251.211) (Quit: Leaving) |
| 2021-11-01 18:56:47 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) (Ping timeout: 268 seconds) |
| 2021-11-01 18:56:47 +0100 | guniberas | (~guniberas@42.191.188.121) (Ping timeout: 268 seconds) |
| 2021-11-01 18:57:43 +0100 | cosimone | (~user@93-47-228-135.ip115.fastwebnet.it) |
| 2021-11-01 18:59:25 +0100 | Null_A | (~null_a@2601:645:8700:2290:f456:9370:22df:9c55) |
| 2021-11-01 19:02:43 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 19:05:05 +0100 | <shapr> | yay survey! |
| 2021-11-01 19:05:08 +0100 | emf | (~emf@2620:10d:c090:400::5:f24f) |
| 2021-11-01 19:05:11 +0100 | <davean> | "Do you use Haskell?" Where is the "I neither confirm or deny I engage in this deviant act"? |
| 2021-11-01 19:06:22 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:bc44:afc4:50a0:6ab8) (Ping timeout: 260 seconds) |
| 2021-11-01 19:07:13 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:9dc4:877c:4cec:30b6) |
| 2021-11-01 19:07:18 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Ping timeout: 260 seconds) |
| 2021-11-01 19:07:30 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-11-01 19:08:16 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 19:08:30 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2021-11-01 19:08:46 +0100 | yrlnry | (~mjd@pool-100-11-2-80.phlapa.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2021-11-01 19:10:14 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 19:10:33 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-11-01 19:12:58 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 19:13:34 +0100 | v01d4lph_ | (~v01d4lph4@106.215.91.221) (Remote host closed the connection) |
| 2021-11-01 19:13:39 +0100 | <monochrom> | I think the close-tab/window button is th "I neither confirm nor deny" button :) |
| 2021-11-01 19:14:04 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 19:16:12 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 19:16:22 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) |
| 2021-11-01 19:17:46 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:9dc4:877c:4cec:30b6) (Ping timeout: 268 seconds) |
| 2021-11-01 19:18:37 +0100 | Null_A | (~null_a@2601:645:8700:2290:f456:9370:22df:9c55) (Remote host closed the connection) |
| 2021-11-01 19:23:11 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Remote host closed the connection) |
| 2021-11-01 19:27:52 +0100 | timCF_ | (~timCF@m91-129-101-112.cust.tele2.ee) |
| 2021-11-01 19:32:31 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-11-01 19:35:01 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Ping timeout: 268 seconds) |
| 2021-11-01 19:36:51 +0100 | <timCF_> | Did anybody thought how might be possible to express in Haskell type system some sort of typical school-math compatible computations like `let distance :: Meter = 1; let time :: Second = 2; let speed :: Meter `Per` Second = distance / time`? Ideally in a way where left and right sides of `Per` type constructor will simplify themselves to canonical form and remove redundant type factor (in case something |
| 2021-11-01 19:36:57 +0100 | <timCF_> | is presented in both left and right and might be remove because of redundancy) |
| 2021-11-01 19:37:58 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-11-01 19:38:17 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) |
| 2021-11-01 19:38:17 +0100 | neurocyte0132889 | (~neurocyte@45.10.60.185) (Changing host) |
| 2021-11-01 19:38:17 +0100 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-11-01 19:38:33 +0100 | Vajb | (~Vajb@2001:999:66:281c:27a0:1549:39e5:8b1a) |
| 2021-11-01 19:38:48 +0100 | <davean> | monochrom: ok, perfect. Thank you for your assistance, I've answered thusly |
| 2021-11-01 19:39:08 +0100 | <davean> | timCF_: Thats pretty standard |
| 2021-11-01 19:39:23 +0100 | <davean> | https://hackage.haskell.org/package/dimensional etc |
| 2021-11-01 19:39:26 +0100 | yrlnry | (~mjd@pool-74-109-22-90.phlapa.fios.verizon.net) |
| 2021-11-01 19:39:28 +0100 | <davean> | timCF_: people use that all the time |
| 2021-11-01 19:39:46 +0100 | <davean> | (Theres several other implimentations, that just happens to be the one I've been using when I need it) |
| 2021-11-01 19:41:12 +0100 | chomwitt | (~chomwitt@2a02:587:dc02:9f00:12c3:7bff:fe6d:d374) (Ping timeout: 268 seconds) |
| 2021-11-01 19:41:40 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 19:42:00 +0100 | <timCF_> | davean: cool, thanks! How this kind of stuff is named in general? I just had no idea which keywords to hoogle :) |
| 2021-11-01 19:42:07 +0100 | <tomsmeding> | units? |
| 2021-11-01 19:43:04 +0100 | <tomsmeding> | case in point: https://hackage.haskell.org/package/units (I had no idea this library existed, the name just matches my guess) |
| 2021-11-01 19:45:22 +0100 | <timCF_> | tomsmeding: looks good as well! |
| 2021-11-01 19:46:44 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-11-01 19:47:51 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 19:48:04 +0100 | <davean> | timCF_: uh, its dimensional analysis |
| 2021-11-01 19:48:08 +0100 | <davean> | isthe general term |
| 2021-11-01 19:50:09 +0100 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-11-01 19:51:04 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) (Ping timeout: 268 seconds) |
| 2021-11-01 19:51:20 +0100 | <timCF_> | davean: thanks! |
| 2021-11-01 19:52:34 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 260 seconds) |
| 2021-11-01 19:54:28 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 19:58:26 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) |
| 2021-11-01 20:03:26 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) |
| 2021-11-01 20:04:08 +0100 | nickkkkk_all | (~nick_all@139.102.124.132) (Quit: Leaving) |
| 2021-11-01 20:05:15 +0100 | max22- | (~maxime@2a01cb088335980078b9d498c24675c0.ipv6.abo.wanadoo.fr) (Ping timeout: 268 seconds) |
| 2021-11-01 20:07:11 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:3a97:eaba:c01a:d700) |
| 2021-11-01 20:09:28 +0100 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) |
| 2021-11-01 20:09:28 +0100 | Nachtgespenst | (~user@user/siracusa) |
| 2021-11-01 20:09:33 +0100 | burnsidesLlama | (~burnsides@dhcp168-013.wadham.ox.ac.uk) (Ping timeout: 268 seconds) |
| 2021-11-01 20:12:05 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-11-01 20:12:31 +0100 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-11-01 20:21:54 +0100 | Vajb | (~Vajb@2001:999:66:281c:27a0:1549:39e5:8b1a) (Read error: Connection reset by peer) |
| 2021-11-01 20:22:29 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-11-01 20:23:22 +0100 | cosimone | (~user@93-47-228-135.ip115.fastwebnet.it) (Ping timeout: 260 seconds) |
| 2021-11-01 20:25:23 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 20:31:05 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-11-01 20:35:14 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Read error: Connection reset by peer) |
| 2021-11-01 20:35:27 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) |
| 2021-11-01 20:37:04 +0100 | vicfred | (~vicfred@user/vicfred) |
| 2021-11-01 20:40:34 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) |
| 2021-11-01 20:43:02 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-11-01 20:44:41 +0100 | <[exa]> | awpr: anyway apparently the brick maintainer used this https://github.com/hackage-trustees/hackage-cli to do the edits very quickly, might be useful for the stuff you mentioned |
| 2021-11-01 20:45:04 +0100 | v01d4lph4 | (~v01d4lph4@user/v01d4lph4) (Remote host closed the connection) |
| 2021-11-01 20:45:09 +0100 | <awpr> | oh nice, that looks like exactly what I was looking for |
| 2021-11-01 20:45:28 +0100 | greyrat | (~greyrat@ip202.ip-51-178-215.eu) (Ping timeout: 252 seconds) |
| 2021-11-01 20:45:53 +0100 | greyrat | (~greyrat@ip202.ip-51-178-215.eu) |
| 2021-11-01 20:46:10 +0100 | <sm> | +1 |
| 2021-11-01 20:48:06 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-11-01 20:52:22 +0100 | max22- | (~maxime@2a01cb0883359800a1b4cd1a3eb225c1.ipv6.abo.wanadoo.fr) |
| 2021-11-01 20:53:31 +0100 | Kaiepi | (~Kaiepi@156.34.44.192) (Remote host closed the connection) |
| 2021-11-01 20:53:44 +0100 | tcard_ | (~tcard@p2878075-ipngn18701hodogaya.kanagawa.ocn.ne.jp) (Remote host closed the connection) |
| 2021-11-01 20:53:51 +0100 | Kaiepi | (~Kaiepi@156.34.44.192) |
| 2021-11-01 20:54:00 +0100 | tcard_ | (~tcard@p2878075-ipngn18701hodogaya.kanagawa.ocn.ne.jp) |
| 2021-11-01 20:55:26 +0100 | oxide | (~lambda@user/oxide) (Quit: oxide) |
| 2021-11-01 20:58:05 +0100 | <justsomeguy> | How do I write literal values for Float values like -Infinity and NaN? -Infinity doesn't work in GHCi, but -1/0 does? |
| 2021-11-01 20:58:36 +0100 | <justsomeguy> | Ah, scratch that, I've just found the relevant section in the haskell report. |
| 2021-11-01 20:58:46 +0100 | <monochrom> | :) |
| 2021-11-01 20:59:46 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds) |
| 2021-11-01 21:05:14 +0100 | juhp | (~juhp@128.106.188.220) (Ping timeout: 246 seconds) |
| 2021-11-01 21:07:15 +0100 | juhp | (~juhp@128.106.188.220) |
| 2021-11-01 21:15:28 +0100 | <shapr> | justsomeguy: what's the answer? I don't know! |
| 2021-11-01 21:15:43 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.121) |
| 2021-11-01 21:17:27 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 21:18:29 +0100 | chomwitt | (~chomwitt@ppp-2-85-245-90.home.otenet.gr) |
| 2021-11-01 21:18:42 +0100 | <dsal> | I wanted to ask, but then people would know I was stupid. |
| 2021-11-01 21:19:50 +0100 | <shapr> | dsal: I don't care if people think I ask stupid questions, I want to know the answers more |
| 2021-11-01 21:19:52 +0100 | <dsal> | I avoid floating point so much, I generally try to keep my code as point free as possible just in case one of them decides to start floating away. |
| 2021-11-01 21:21:03 +0100 | <janus> | is there really a literal for this? it seems so odd that i can't find it here https://hackage.haskell.org/package/base-4.16.0.0/docs/src/GHC.Float.html |
| 2021-11-01 21:22:06 +0100 | <janus> | seems roundabout to define isNaN as a foreign function if there were a way to write "== NaN" |
| 2021-11-01 21:22:24 +0100 | <geekosaur> | I don't think two NaNs compare equal? |
| 2021-11-01 21:22:29 +0100 | <dsal> | Isn't == NaN always False? |
| 2021-11-01 21:22:37 +0100 | <geekosaur> | NaN follows some really weird rules |
| 2021-11-01 21:22:46 +0100 | <dolio> | Right. |
| 2021-11-01 21:23:18 +0100 | <dsal> | This is one of the reasons floating point is painful to work in. |
| 2021-11-01 21:23:38 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.121) (Ping timeout: 260 seconds) |
| 2021-11-01 21:23:45 +0100 | <dsal> | You treat them like regular numbers, and then sometimes the answer can't be represented properly and sometimes it's not a number at lal. |
| 2021-11-01 21:24:04 +0100 | <janus> | ok but the comparison with negative zero is a foreign function |
| 2021-11-01 21:24:38 +0100 | <geekosaur> | that's because |
| 2021-11-01 21:24:42 +0100 | <geekosaur> | > -0 == 0 |
| 2021-11-01 21:24:44 +0100 | <lambdabot> | True |
| 2021-11-01 21:25:01 +0100 | <geekosaur> | > -0.0 == 0.0 |
| 2021-11-01 21:25:03 +0100 | <lambdabot> | True |
| 2021-11-01 21:25:15 +0100 | aristid___ | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2021-11-01 21:25:23 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.118) |
| 2021-11-01 21:25:27 +0100 | <janus> | oh ok |
| 2021-11-01 21:25:29 +0100 | <geekosaur> | negative zero is the same as zero for all but a few functions thta care about quadrants |
| 2021-11-01 21:25:39 +0100 | <geekosaur> | (e.g. atan2) |
| 2021-11-01 21:26:09 +0100 | aristid___ | aristid |
| 2021-11-01 21:26:18 +0100 | <geekosaur> | as dsal said, this is why FP is painful |
| 2021-11-01 21:26:30 +0100 | <geekosaur> | (and the same painful in all languages) |
| 2021-11-01 21:26:47 +0100 | <dsal> | The pain was standardized. |
| 2021-11-01 21:26:57 +0100 | <[exa]> | hopefully one day all FP equality comparisons will just return False |
| 2021-11-01 21:27:22 +0100 | <janus> | > atan2 (0) (-1) |
| 2021-11-01 21:27:24 +0100 | <lambdabot> | 3.141592653589793 |
| 2021-11-01 21:27:29 +0100 | <janus> | > atan2 (-0) (-1) |
| 2021-11-01 21:27:31 +0100 | <lambdabot> | -3.141592653589793 |
| 2021-11-01 21:27:36 +0100 | <aristid> | fixed point (or any other alternative to FP) is not exactly a panacea though |
| 2021-11-01 21:28:04 +0100 | <dsal> | Adding negative numbers in general was a bad idea. Zero was already bad enough. |
| 2021-11-01 21:28:10 +0100 | <[exa]> | janus: noooooo |
| 2021-11-01 21:28:29 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 268 seconds) |
| 2021-11-01 21:29:01 +0100 | <janus> | i don't use atan anyway because i don't want untanned people to feel excluded |
| 2021-11-01 21:29:28 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-11-01 21:29:36 +0100 | <dsal> | If I were a geometrist cooped up in my office all day, I could probably use atan. |
| 2021-11-01 21:30:25 +0100 | <aristid> | so i'm the creator of the "aws" hackage package, but i haven't had time to maintain it for a long time (i don't really even use haskell these days) |
| 2021-11-01 21:30:32 +0100 | <aristid> | thoughts on how to find a new maintainer? |
| 2021-11-01 21:30:47 +0100 | fendor | (~fendor@77.119.197.65.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-11-01 21:31:11 +0100 | jespada | (~jespada@190.7.36.46) |
| 2021-11-01 21:31:18 +0100 | <geekosaur> | mail to haskell-cafe? |
| 2021-11-01 21:31:45 +0100 | <geekosaur> | or if you have any outstanding PRs, offer to pass maintainership to whoever submitted them |
| 2021-11-01 21:31:54 +0100 | <sagax> | https://termbin.com/54b5 |
| 2021-11-01 21:31:55 +0100 | <aristid> | i don't want to join any mailing lists :p |
| 2021-11-01 21:31:57 +0100 | <cigsender> | project-matchmaking? |
| 2021-11-01 21:32:04 +0100 | <Hecate> | cigsender: not yet! :< |
| 2021-11-01 21:32:11 +0100 | <cigsender> | :( |
| 2021-11-01 21:33:46 +0100 | <geekosaur> | sagax: you don't. printf is a fragile hack in Haskell |
| 2021-11-01 21:33:48 +0100 | <Hecate> | aristid: hi! the haskell-cafe mailing-list is your best bet to reach out for new maintainers. I would also advise that you use social media platforms like Twitter (with the #haskell hashtag) because lots of professionals are also monitoring and interacting on those platforms |
| 2021-11-01 21:34:09 +0100 | <aristid> | looks like joeyh_ has an outstanding PR to aws :D |
| 2021-11-01 21:34:26 +0100 | <maerwald> | "advise that you use social media" <-- uhm... |
| 2021-11-01 21:34:41 +0100 | max22- | (~maxime@2a01cb0883359800a1b4cd1a3eb225c1.ipv6.abo.wanadoo.fr) (Remote host closed the connection) |
| 2021-11-01 21:34:46 +0100 | <janus> | is irc social media? |
| 2021-11-01 21:34:51 +0100 | <aristid> | yeah i guess i can tweet something |
| 2021-11-01 21:34:54 +0100 | fendor | (~fendor@77.119.197.65.wireless.dyn.drei.com) |
| 2021-11-01 21:34:56 +0100 | <geekosaur> | possibly antisocial media |
| 2021-11-01 21:35:21 +0100 | <geekosaur> | (then again that's also how I feel about twitter most of the time) |
| 2021-11-01 21:35:52 +0100 | <aristid> | Hecate: is there a way to interact haskell-cafe without adding any more emails to my email? i am too close to email bankruptcy already.. :D |
| 2021-11-01 21:35:55 +0100 | <maerwald> | janus: no, because here you get banned if you post your bikini pics |
| 2021-11-01 21:36:09 +0100 | <sagax> | geekosaur: what better then `printf`? |
| 2021-11-01 21:36:44 +0100 | <janus> | maerwald: i have a collection of ansi porn that i can show you if connect to my server |
| 2021-11-01 21:36:46 +0100 | <sagax> | for output with formatting |
| 2021-11-01 21:36:58 +0100 | <maerwald> | janus: you seems like a trustworthy person, why not |
| 2021-11-01 21:37:06 +0100 | <geekosaur> | sagax, printf (badly) wraps the numeric formatting functions in https://downloads.haskell.org/ghc/latest/docs/html/libraries/base-4.15.0.0/Numeric.html |
| 2021-11-01 21:37:10 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2021-11-01 21:37:15 +0100 | <Hecate> | aristid: I can cross-post to it if you need to avoid new MLs :P But I'd advise you to post on the Haskell Discourse then :) |
| 2021-11-01 21:37:37 +0100 | max22- | (~maxime@lfbn-ren-1-762-224.w81-53.abo.wanadoo.fr) |
| 2021-11-01 21:39:03 +0100 | jespada | (~jespada@190.7.36.46) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-11-01 21:39:36 +0100 | <aristid> | Hecate: https://twitter.com/aristidb/status/1455273103278346244?s=21 - retweet would be appreciated :) |
| 2021-11-01 21:40:13 +0100 | <Hecate> | aristid: 👍 |
| 2021-11-01 21:43:11 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-11-01 21:50:42 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.118) (Ping timeout: 268 seconds) |
| 2021-11-01 21:50:59 +0100 | zero | yin |
| 2021-11-01 21:52:03 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.115) |
| 2021-11-01 21:53:09 +0100 | mikoto-chan | (~mikoto-ch@185.237.102.115) (Client Quit) |
| 2021-11-01 21:53:33 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) |
| 2021-11-01 21:54:33 +0100 | <dartford> | ok - i want to give this another try, but im going to try and take it slow. im recovering from blast trauma and i hope the other users can be considerate of this |
| 2021-11-01 21:54:43 +0100 | <dartford> | im sorry im not totally with it, but im trying my best |
| 2021-11-01 21:56:13 +0100 | <Hecate> | salut dartford |
| 2021-11-01 21:56:22 +0100 | <dartford> | hi |
| 2021-11-01 21:58:06 +0100 | <dartford> | i dont understand the termanology used in the paper "Selective Applicative Functors" |
| 2021-11-01 21:58:21 +0100 | <dartford> | eg when describing the type of bind |
| 2021-11-01 21:58:24 +0100 | <dartford> | :t (>>=) |
| 2021-11-01 21:58:25 +0100 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2021-11-01 21:58:35 +0100 | <sclv> | [exa]: btw also there's hackage-cli for bulk editing bounds https://github.com/hackage-trustees/hackage-cli |
| 2021-11-01 21:58:46 +0100 | <dartford> | it says; |
| 2021-11-01 21:58:47 +0100 | <dartford> | The operator takes two arguments: an effectful computation f a, which yields a value of type a |
| 2021-11-01 21:58:47 +0100 | <dartford> | when executed |
| 2021-11-01 21:59:20 +0100 | <janus> | sclv: 20:44 <..... [exa]> awpr: anyway apparently the brick maintainer used this https://github.com/hackage-trustees/hackage-cli to do the edits very quickly, might be useful for the stuff you mentioned |
| 2021-11-01 21:59:25 +0100 | <dartford> | i have never heard of a monad f, applied to the type `a' being called "an effectful computation" |
| 2021-11-01 21:59:30 +0100 | <sclv> | oh nice :-) |
| 2021-11-01 21:59:42 +0100 | <Hecate> | dartford: Monads are here to provide the means to have effectful computations in Haskell |
| 2021-11-01 21:59:44 +0100 | <dartford> | eg, the list monad, i normally just think of as a kind of container |
| 2021-11-01 21:59:47 +0100 | <Hecate> | that's literally their whole purpose |
| 2021-11-01 21:59:52 +0100 | <Hecate> | in Haskell |
| 2021-11-01 22:00:05 +0100 | <sclv> | you can also think of the list monad as encompasing the "nondterminism effect" |
| 2021-11-01 22:00:09 +0100 | <dartford> | er, well yeah i guess IO was crucial in the dev of haskell |
| 2021-11-01 22:00:24 +0100 | <sclv> | where instead of one value, you have a nondeterministic collection of values |
| 2021-11-01 22:00:26 +0100 | <Hecate> | dartford: https://wiki.haskell.org/Monads_as_computation |
| 2021-11-01 22:00:37 +0100 | <dartford> | but monads in general also include flattenable containers like list |
| 2021-11-01 22:00:43 +0100 | <sclv> | monads were introduced for effects in general -- not just IO, but state, nondeterminism, etc |
| 2021-11-01 22:00:51 +0100 | <dartford> | which is the kind of bind instance im more used to dealing with |
| 2021-11-01 22:00:56 +0100 | <janus> | but shouldn't it be a set instead of a list if it were really about nondeterminism |
| 2021-11-01 22:01:05 +0100 | <dartford> | its not |
| 2021-11-01 22:01:09 +0100 | <Hecate> | I think the Monad instance for List was also here to provide support for list comprehension operational semantics? |
| 2021-11-01 22:01:23 +0100 | <sclv> | the monad instance for list was for nondeterminism |
| 2021-11-01 22:01:27 +0100 | <Hecate> | as ok :) |
| 2021-11-01 22:01:35 +0100 | <sclv> | https://www.cs.cmu.edu/~crary/819-f09/Moggi91.pdf |
| 2021-11-01 22:01:44 +0100 | <Hecate> | I have to admit I'm never doing (consciously) non-determinism by hand |
| 2021-11-01 22:01:59 +0100 | <sclv> | but this is all historical. you don't have to _agree_ that this is the fundamental way to think about them. you just have to understand that people _do_ think about them that way |
| 2021-11-01 22:02:01 +0100 | <dartford> | its flattenable |
| 2021-11-01 22:02:05 +0100 | <sclv> | so you can read the papers |
| 2021-11-01 22:02:06 +0100 | <dartford> | thats its monadic behaviour |
| 2021-11-01 22:02:19 +0100 | <monochrom> | janus: All of {list, tree, multiset/bag, set} can be used for non-determinism, you have a lot of choice about how much intermediate information to throw away. |
| 2021-11-01 22:02:36 +0100 | <sclv> | the monadic behavior is just that it obeys the laws. its pure calculation. anything else is just a more intuitive way we have of talking about some aspect of the thing |
| 2021-11-01 22:02:48 +0100 | <dartford> | sclv: good call, id rather not speak of nondetermanism at all if thats ok |
| 2021-11-01 22:02:56 +0100 | <monochrom> | For example, if you choose set, you throw away multiplicity. |
| 2021-11-01 22:03:04 +0100 | <sclv> | well you _have_ to understand the effect standpoint if you want to read papers that take it |
| 2021-11-01 22:03:07 +0100 | <dartford> | i get that its important to the discussion of pure vs escaping effects though |
| 2021-11-01 22:03:11 +0100 | <sclv> | so i don't want to convince you that this is the right standpoint |
| 2021-11-01 22:03:18 +0100 | <dartford> | fair |
| 2021-11-01 22:03:18 +0100 | <sclv> | i just want to help you read the paper by answering your question |
| 2021-11-01 22:03:24 +0100 | <monochrom> | But nothing says that the only correct thing to do is to throw away multiplicity. |
| 2021-11-01 22:03:58 +0100 | Midjak | (~Midjak@82-65-111-221.subs.proxad.net) |
| 2021-11-01 22:04:10 +0100 | <dartford> | ok, so if we are talking about "effects" this is something to do with the "impure" contents? |
| 2021-11-01 22:04:20 +0100 | <monochrom> | In the case of fitting monads to the Monad type class, you also can't add the Eq constraint to say you want sets. |
| 2021-11-01 22:05:03 +0100 | <dartford> | i think the point is that we want something like IO effects but in a pure setting, right? |
| 2021-11-01 22:06:07 +0100 | <dartford> | the idea just being to understand how `Monad f => f a' expresses "an effectful computation" |
| 2021-11-01 22:06:10 +0100 | <sclv> | you can be simpler. "Maybe" is the nontermination effect |
| 2021-11-01 22:06:38 +0100 | <dartford> | ok, so if i have Just 1 |
| 2021-11-01 22:06:42 +0100 | <janus> | i feel like i am not understanding what people mean when they say non-determinism here. because it doesn't involve randomness. wikipedia says "even for the same input, can exhibit different behaviors on different runs" |
| 2021-11-01 22:06:46 +0100 | <dartford> | hows that "an effectful computation" ? |
| 2021-11-01 22:06:57 +0100 | <janus> | but what is the definition that people use when they associate lists with nondeterminism? |
| 2021-11-01 22:07:02 +0100 | <dartford> | seems more like a container with a value in |
| 2021-11-01 22:07:19 +0100 | <sclv> | its the computation that terminates and yields 1 |
| 2021-11-01 22:07:22 +0100 | <dartford> | but where we wouldnt know that it actually has a value just from the type |
| 2021-11-01 22:07:27 +0100 | <sclv> | as opposed to Nothing, which is the computation that does not terminate |
| 2021-11-01 22:07:32 +0100 | <aristid> | i think the point is just that you can build functions that rely on nothing but the monad laws, and they will work for all instances of monad - any intuition to explain monads may be helpful but is never the whole picture |
| 2021-11-01 22:07:37 +0100 | <dartford> | sclv: ok, right, that sounds like we are getting somewhere |
| 2021-11-01 22:07:43 +0100 | <sclv> | the Moggi paper I linked above is the origin of all this |
| 2021-11-01 22:07:44 +0100 | <monochrom> | I simply take it as "4 has two square roots, 2 and -2, how do I express multi-valued functions?" |
| 2021-11-01 22:07:47 +0100 | <sclv> | before haskell even had monads |
| 2021-11-01 22:08:11 +0100 | <dartford> | aristid: the problem is the whole paper is written in this language of effects |
| 2021-11-01 22:08:28 +0100 | <monochrom> | In fact one of the Moggi papers had monad transformers too heh. |
| 2021-11-01 22:08:37 +0100 | <sclv> | `Either String` is error because `Right 1` is the computation which yields 1 and `Left "hello"` is the computation that errors with "hello" |
| 2021-11-01 22:09:09 +0100 | <dolio> | Non-determinism doesn't involve randomness in general. |
| 2021-11-01 22:09:11 +0100 | <dartford> | hows it "effectful" though? |
| 2021-11-01 22:09:11 +0100 | <sm> | janus: my limited understanding: it's not saying random, but "multiple answers", ie no one definite answer |
| 2021-11-01 22:09:12 +0100 | <sclv> | janus: lists are nondeterminism because they encompass computaions that can have multiple outcomes |
| 2021-11-01 22:09:30 +0100 | <sclv> | so like "all possible paths through a tree" |
| 2021-11-01 22:09:34 +0100 | <dartford> | dolio: right, a "pottentially" hanging computation is nondetermanistic, right? |
| 2021-11-01 22:09:47 +0100 | <dartford> | idk if it will return or not |
| 2021-11-01 22:09:48 +0100 | <dolio> | Non-deterministic Turing machines don't do random branches. They either do every branch, or they magically pick the right branch every time, depending on how you want to think about it. |
| 2021-11-01 22:10:00 +0100 | <sm> | so really it's deterministic, just multiple. Confusing term. |
| 2021-11-01 22:10:03 +0100 | <aristid> | lol i haven't hung out in this channel for many years, and still i recognize a few of the people |
| 2021-11-01 22:10:43 +0100 | unit73e | (~emanuel@2001:818:e8dd:7c00:32b5:c2ff:fe6b:5291) (Remote host closed the connection) |
| 2021-11-01 22:10:46 +0100 | <dartford> | the kind of people that start and end a sentence with "right", right? |
| 2021-11-01 22:10:53 +0100 | <janus> | but it requires you to choose an order for them, and you can even choose to have infinite answers.. that just seems like two major differences to how non-deterministic turing machines work |
| 2021-11-01 22:11:02 +0100 | <monochrom> | Well, S->(S,a) is also both "mutable state" and "but it's a stateless function from S to (S,a)". |
| 2021-11-01 22:11:17 +0100 | <sclv> | some papers use "bags" or "unsorted multisets" for true nondeterminism |
| 2021-11-01 22:11:25 +0100 | <sclv> | but we just use list historically because its easier to write :-) |
| 2021-11-01 22:11:26 +0100 | <dartford> | is it nesacary to understand nondetermanism to understand effectful computations? |
| 2021-11-01 22:11:30 +0100 | <dartford> | why are we talking about it? |
| 2021-11-01 22:11:35 +0100 | <dolio> | dartford: Yeah, no answers is encompassed by non-determinism, too. |
| 2021-11-01 22:11:40 +0100 | <sclv> | its necessary to understand why people call list the "nondeterminism effect" |
| 2021-11-01 22:11:44 +0100 | <monochrom> | You will always have this double-speak tension when using math functions to model non-math things. |
| 2021-11-01 22:11:48 +0100 | <dartford> | i mean, as an example other than that uses randomness |
| 2021-11-01 22:12:03 +0100 | <sclv> | if you want to forget about lists and only thing about other monads, like state, or writer, or maybe for effects |
| 2021-11-01 22:12:07 +0100 | <sclv> | then we can ignore nondeterminism for now |
| 2021-11-01 22:12:11 +0100 | <dartford> | thanks |
| 2021-11-01 22:12:19 +0100 | Null_A | (~null_a@2601:645:8700:2290:7887:7a6d:751e:a369) |
| 2021-11-01 22:12:26 +0100 | <janus> | hmmm all right, i suppose it is correct that programming rarely matches programming 100% |
| 2021-11-01 22:12:35 +0100 | <dartford> | ok, so, forgetting about how containers are used to model nondetermanism, as in, options |
| 2021-11-01 22:12:53 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 268 seconds) |
| 2021-11-01 22:13:02 +0100 | <dartford> | [1..], it contains all the numbers, idk which one to select, or something like that |
| 2021-11-01 22:13:12 +0100 | <monochrom> | "I have a partial function X -> Y, oh let's express it by X -> Maybe Y, oh wait now I have a total function again..." same deal. |
| 2021-11-01 22:13:24 +0100 | <dartford> | "could be any of them if i draw a number from it", or something like that, idk |
| 2021-11-01 22:13:32 +0100 | <monochrom> | You have to know you are talking 2 levels at the same time. |
| 2021-11-01 22:14:11 +0100 | <sclv> | how you select a value from a list is known as an _algebra_ for a monad |
| 2021-11-01 22:14:11 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-11-01 22:14:21 +0100 | <dartford> | so, if we just talk about embedding "effects" in monads, are we just talking about being able to change the contents? |
| 2021-11-01 22:14:35 +0100 | <sclv> | no, we say that monads model effects |
| 2021-11-01 22:14:37 +0100 | <dartford> | some older notion akin to saying "weer going to lens into part of it" |
| 2021-11-01 22:14:46 +0100 | <sclv> | it has nothing to do with lenses |
| 2021-11-01 22:14:54 +0100 | <dartford> | sclv: thats the termanology i dont understand |
| 2021-11-01 22:15:12 +0100 | <dartford> | i mean, if i have writer, then the effect is changing part of it right? |
| 2021-11-01 22:15:23 +0100 | <cigsender> | monads "are" the effects. a `Maybe a` is an `a` with the effect of being possibly-empty |
| 2021-11-01 22:15:27 +0100 | <sclv> | we mean that if `m` is a monad, the difference between `a -> b` and `a -> m b` is that the latter can be thought of as "the former, but with some effect" |
| 2021-11-01 22:15:31 +0100 | <dartford> | or a state rather, if i want to read the value it contains in order to be able to update it |
| 2021-11-01 22:15:45 +0100 | <dartford> | basically, i was working with the state monad almost exclusivly for this |
| 2021-11-01 22:15:47 +0100 | <sclv> | a problem is you're thinking only of containers |
| 2021-11-01 22:15:52 +0100 | <sclv> | monads aren't always containers |
| 2021-11-01 22:15:54 +0100 | <dartford> | so changing the contents becomes the thing |
| 2021-11-01 22:16:01 +0100 | <sclv> | for example, the continuation monad is not a container |
| 2021-11-01 22:16:13 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-11-01 22:16:20 +0100 | <dartford> | so how is that an efectful computation? |
| 2021-11-01 22:16:29 +0100 | <janus> | why is it not a container? just because it can contain a function? :P |
| 2021-11-01 22:16:30 +0100 | <dartford> | if the effect is other than changing the value it contanes |
| 2021-11-01 22:16:50 +0100 | <sclv> | because call/CC is an effect |
| 2021-11-01 22:16:55 +0100 | <dartford> | weer talking about ((a->b) -> b) right? |
| 2021-11-01 22:16:57 +0100 | <sclv> | a control flow effect |
| 2021-11-01 22:17:03 +0100 | <dartford> | seems to contain a value of type `a' to me |
| 2021-11-01 22:17:03 +0100 | <maerwald> | sclv: it just moves you to another container |
| 2021-11-01 22:17:10 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) (Remote host closed the connection) |
| 2021-11-01 22:17:18 +0100 | <dartford> | % :t callCC |
| 2021-11-01 22:17:18 +0100 | <yahb> | dartford: MonadCont m => ((a -> m b) -> m a) -> m a |
| 2021-11-01 22:17:27 +0100 | <janus> | sclv: but i can use Cont just fine without call/cc? i don't understand how the existence of call/cc changes whether it is a container or not? |
| 2021-11-01 22:17:47 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-11-01 22:17:50 +0100 | <dartford> | so it contains a `a -> m b' ? |
| 2021-11-01 22:18:01 +0100 | <dolio> | What's your definition of, "container"? |
| 2021-11-01 22:18:10 +0100 | <dartford> | i can retrive the value |
| 2021-11-01 22:18:13 +0100 | <dartford> | or change it |
| 2021-11-01 22:18:19 +0100 | <dartford> | depends what instances it satisfies |
| 2021-11-01 22:18:24 +0100 | <dartford> | but there are some values |
| 2021-11-01 22:18:40 +0100 | <dartford> | and they appear in a way decorated by the nature of the container |
| 2021-11-01 22:18:44 +0100 | <monochrom> | janus: Try to wing "(a -> S -> (R, S)) -> S -> (R, S)" as a container? >:) (That's "ContT R (State S) a") |
| 2021-11-01 22:19:00 +0100 | <dartford> | eg a functor is a container in an obvious way because of how fmap can change the values |
| 2021-11-01 22:19:21 +0100 | <sclv> | a functor is not a container |
| 2021-11-01 22:19:23 +0100 | <monochrom> | I'm OK with not talking about callCC. Although, callCC still exists. |
| 2021-11-01 22:19:28 +0100 | <dartford> | ie, because functor is a superclass of monad, so then, there must be values that i can at least fmap over |
| 2021-11-01 22:19:34 +0100 | <cigsender> | dartford: given a type `a`, the type `Maybe a` may or may not hold a value of `a`. But `Maybe a` is not a monad, it is a type. `Maybe` is teh monad |
| 2021-11-01 22:20:05 +0100 | <sclv> | its a fine intuition at first, but it doesn't hold for more complex types very easily |
| 2021-11-01 22:20:31 +0100 | <dartford> | but if you can opperate on the values, they must be there, inside it |
| 2021-11-01 22:20:37 +0100 | <dartford> | so it contains them |
| 2021-11-01 22:20:44 +0100 | <dartford> | :t fmap |
| 2021-11-01 22:20:45 +0100 | <lambdabot> | Functor f => (a -> b) -> f a -> f b |
| 2021-11-01 22:20:59 +0100 | <sclv> | `data Phantom a = Phantom` |
| 2021-11-01 22:21:03 +0100 | <dartford> | values of type `a' are having a function applied to them |
| 2021-11-01 22:21:05 +0100 | <davean> | dartford: absotely not |
| 2021-11-01 22:21:13 +0100 | <sclv> | its a "container of zero as" but how is that useful |
| 2021-11-01 22:21:16 +0100 | <dartford> | sclv: seems like the always empty container... |
| 2021-11-01 22:21:21 +0100 | <maerwald> | I think most haskellers think of "collections" or something similar when you say "container" |
| 2021-11-01 22:21:23 +0100 | <dartford> | its a wierd edge case sure |
| 2021-11-01 22:21:33 +0100 | <maerwald> | I have no problem with "container" as a more abstract term |
| 2021-11-01 22:21:35 +0100 | <sclv> | there's also a formal theory of containers from ghani et al. |
| 2021-11-01 22:21:40 +0100 | <davean> | dartford: what about (data Function b = F Int -> b) |
| 2021-11-01 22:21:44 +0100 | unit73e | (~emanuel@2001:818:e8dd:7c00:32b5:c2ff:fe6b:5291) |
| 2021-11-01 22:21:45 +0100 | <dsal> | It seems weird to refer to a function as "containing" a thing. |
| 2021-11-01 22:21:45 +0100 | <davean> | wheres the b inside that? |
| 2021-11-01 22:21:58 +0100 | <dartford> | anyway, even if you only had a getter, id still call it a container, since it can have the values retrived |
| 2021-11-01 22:22:16 +0100 | <janus> | i guess i don't have a definition of container. is Maybe a container according to anyone? |
| 2021-11-01 22:22:20 +0100 | <sclv> | but things with getters are not necessarily functors, and some functors, like phantom, have no getters |
| 2021-11-01 22:22:34 +0100 | <monochrom> | I accept that Maybe is a container. |
| 2021-11-01 22:22:43 +0100 | <dartford> | davean: thats a much better idea, that doesnt seem to be a container of values of type b |
| 2021-11-01 22:22:45 +0100 | <dsal> | I think of Maybe as a container. |
| 2021-11-01 22:22:46 +0100 | <monochrom> | I don't have a definition either. I don't think we need one. |
| 2021-11-01 22:22:50 +0100 | <sclv> | maybe also fits the formal definition: https://www.sciencedirect.com/science/article/pii/S0304397505003373 |
| 2021-11-01 22:22:57 +0100 | <davean> | dartford: its also clearly a functor |
| 2021-11-01 22:23:03 +0100 | <davean> | via compose. |
| 2021-11-01 22:23:06 +0100 | <janus> | but Cont has a Susp constructor which is just like Just. so it seems weird that Maybe is a container but Cont wouldn't be |
| 2021-11-01 22:23:24 +0100 | <monochrom> | What I don't accept is the stance "Maybe is only a container". |
| 2021-11-01 22:23:42 +0100 | <janus> | you could choose a polymorphic type parameter for Cont which would make the input type Void and have it be 'isomorphic' to Maybe, no |
| 2021-11-01 22:24:10 +0100 | <davean> | dartford: infact, its also a common monad - reader |
| 2021-11-01 22:24:19 +0100 | <dartford> | there are no values inside the reader monad |
| 2021-11-01 22:24:30 +0100 | <dartford> | so its not a container |
| 2021-11-01 22:24:32 +0100 | <dartford> | ok, done |
| 2021-11-01 22:24:36 +0100 | <dartford> | so, back to effects |
| 2021-11-01 22:24:53 +0100 | <monochrom> | I treat "container" on the same level as "compiler", "interpreter", "programming". I expect grey areas. I expect disagreements. |
| 2021-11-01 22:24:57 +0100 | <janus> | oh no, i meant the "Done" constructor for Cont. Not Susp, which is the one that would be 'disabled' with Void |
| 2021-11-01 22:24:59 +0100 | <dartford> | (we conclude that "not all monads can be thought of as containers, even though they are functors) |
| 2021-11-01 22:25:10 +0100 | <davean> | monochrom: A box is a container, a Box is not. |
| 2021-11-01 22:25:16 +0100 | <janus> | right ok, i accept it is a grey area |
| 2021-11-01 22:25:18 +0100 | <monochrom> | haha |
| 2021-11-01 22:25:39 +0100 | <dartford> | ie, being able to fmap over values of the type parameter, does not mean the Functor contains values of that type that can be "got" |
| 2021-11-01 22:25:49 +0100 | <monochrom> | Is YAML a programming language? >:) |
| 2021-11-01 22:26:01 +0100 | <dartford> | erp |
| 2021-11-01 22:26:02 +0100 | <monochrom> | ("No! It's a container language!") |
| 2021-11-01 22:26:06 +0100 | <janus> | haha :P |
| 2021-11-01 22:26:09 +0100 | <davean> | monochrom: yes, and you made me think about it, so thats a crime against humanity and I want you prosecuted |
| 2021-11-01 22:26:18 +0100 | <monochrom> | haha |
| 2021-11-01 22:26:26 +0100 | <dartford> | shots fired |
| 2021-11-01 22:26:28 +0100 | cigsender | (~cigsender@74.124.58.162) (Quit: leaving) |
| 2021-11-01 22:26:31 +0100 | <monochrom> | Belated Halloween activities. |
| 2021-11-01 22:26:43 +0100 | <dartford> | soooo, effects? |
| 2021-11-01 22:27:02 +0100 | <sclv> | like you've gotten three answers on effects and a link to one or two papers |
| 2021-11-01 22:27:17 +0100 | acidjnk | (~acidjnk@p200300d0c7441145a0f2d1eed66e92ec.dip0.t-ipconnect.de) |
| 2021-11-01 22:27:19 +0100 | <dartford> | if we refuse to consider containers, are we left with things more obviously embodying the notion of "effectful computations" ? |
| 2021-11-01 22:27:20 +0100 | <sclv> | do you have a specific question |
| 2021-11-01 22:27:23 +0100 | <dsal> | If covariant functors are boxes, are contravariant functors conveyor belts? |
| 2021-11-01 22:27:33 +0100 | <sclv> | no, we should _also_ consider things you personally think of as containers |
| 2021-11-01 22:27:35 +0100 | <sclv> | like maybe |
| 2021-11-01 22:27:42 +0100 | <dartford> | ah ok |
| 2021-11-01 22:27:43 +0100 | <dartford> | thanks |
| 2021-11-01 22:27:51 +0100 | <dartford> | i wasnt sure what was being suggested |
| 2021-11-01 22:28:01 +0100 | <sclv> | the potential nontermination effect is a very nice simple one |
| 2021-11-01 22:28:08 +0100 | <sclv> | as is reader, and state |
| 2021-11-01 22:28:22 +0100 | <dartford> | so what was the "effect" of Maybe? |
| 2021-11-01 22:28:33 +0100 | <sclv> | potential nontermination |
| 2021-11-01 22:28:43 +0100 | <davean> | dsal: a falsehood implies anything you want it to, so maybe? |
| 2021-11-01 22:29:18 +0100 | <dartford> | ok, so, because Nothing certainly returns, but Just nastyLoopingThing wont... |
| 2021-11-01 22:29:37 +0100 | <sclv> | pretend we're in a language without loops |
| 2021-11-01 22:29:41 +0100 | <dartford> | i suppose i might be thinking of effects as basically being IO |
| 2021-11-01 22:29:43 +0100 | <sclv> | or without infinite recursion |
| 2021-11-01 22:29:46 +0100 | <dartford> | i guess thats whats wrong |
| 2021-11-01 22:30:03 +0100 | <dartford> | Just doInfiniteWorkForever |
| 2021-11-01 22:30:24 +0100 | <dartford> | sclv: ok, i dont know how to make that not terminate without loops or recursion... |
| 2021-11-01 22:30:33 +0100 | <dartford> | i cant unfold infinite containers? |
| 2021-11-01 22:30:41 +0100 | <sclv> | you can also simulate IO with appropriate monads. https://hackage.haskell.org/package/IOSpec-0.3.1.1 |
| 2021-11-01 22:30:56 +0100 | <dartford> | im just not sure thats whats *meant* by effec |
| 2021-11-01 22:30:59 +0100 | <dartford> | effect* |
| 2021-11-01 22:31:08 +0100 | <sclv> | dartford: i'm saying, to think of Maybe as nontermination as an effect, it helps to think of yourself in a language that has no unlimited recursion |
| 2021-11-01 22:31:14 +0100 | <dartford> | since pottential nontermination is supposed to be thought of as an effect apparently |
| 2021-11-01 22:31:22 +0100 | <sclv> | and Maybe is the effect of halting |
| 2021-11-01 22:31:35 +0100 | <sclv> | or rather of not terminating |
| 2021-11-01 22:31:41 +0100 | <sclv> | not by infinite loop, but by getting "stuck" |
| 2021-11-01 22:31:46 +0100 | <dartford> | huh? you mean, Just? or Nothing? |
| 2021-11-01 22:31:53 +0100 | <sclv> | Maybe itsel |
| 2021-11-01 22:31:55 +0100 | <monochrom> | I think "no answer / failure" is much better than "non-termination". |
| 2021-11-01 22:31:58 +0100 | <sclv> | sure |
| 2021-11-01 22:32:05 +0100 | <sclv> | i'm using the old terminology |
| 2021-11-01 22:32:11 +0100 | <dartford> | oooh right, just "this might return" |
| 2021-11-01 22:32:13 +0100 | <dartford> | fine |
| 2021-11-01 22:32:15 +0100 | <sclv> | you can think of it as "null pointer semantics" |
| 2021-11-01 22:32:15 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-11-01 22:32:22 +0100 | <dartford> | so Nothing, is it hanging |
| 2021-11-01 22:32:26 +0100 | <dartford> | notionally |
| 2021-11-01 22:32:44 +0100 | <sclv> | sure |
| 2021-11-01 22:32:55 +0100 | <dartford> | monochrom: right, or you would need some way to make a hanging computation, which would require loops |
| 2021-11-01 22:33:06 +0100 | <dartford> | idk why it was "helpful" to consider a language without loops... |
| 2021-11-01 22:33:25 +0100 | <dartford> | so just to be sure, this is an "effect" why? |
| 2021-11-01 22:33:26 +0100 | <sclv> | because loops are complicated to model as an effect and are beyond the scope of what we're talking about here |
| 2021-11-01 22:33:34 +0100 | <dartford> | because its impure? |
| 2021-11-01 22:33:40 +0100 | <sclv> | there's a richer monad that introduces a "real" notion of loops as an effect |
| 2021-11-01 22:34:10 +0100 | <sclv> | not because its impure, but because you can't rule them out with types and then introduce models of them without a richer type system |
| 2021-11-01 22:34:13 +0100 | <sclv> | its... complicated |
| 2021-11-01 22:34:24 +0100 | <sclv> | because of the halting problem, basically |
| 2021-11-01 22:34:29 +0100 | <dartford> | argh |
| 2021-11-01 22:34:35 +0100 | <dartford> | thwarted once more |
| 2021-11-01 22:34:37 +0100 | <sclv> | so i'm advising ignoring it |
| 2021-11-01 22:35:02 +0100 | <dartford> | yeah, im never going to be able to read this stupidly written paper in the absurd incomprehensible jargon |
| 2021-11-01 22:35:10 +0100 | <sclv> | don't be mean to the paper |
| 2021-11-01 22:35:16 +0100 | <sclv> | its a great paper by very talented people |
| 2021-11-01 22:35:16 +0100 | <dartford> | sorry paper |
| 2021-11-01 22:35:31 +0100 | <dartford> | yeah, that have grapled with the incomprehensible far too much |
| 2021-11-01 22:35:32 +0100 | <sclv> | and i'm sorry you can't read it, but its written in a way very comrehensible compared to most |
| 2021-11-01 22:35:41 +0100 | <dartford> | all their girfriends are already divorced them |
| 2021-11-01 22:35:49 +0100 | <sclv> | ok seriously stop it |
| 2021-11-01 22:35:56 +0100 | <maerwald> | :D |
| 2021-11-01 22:35:57 +0100 | <dartford> | make it simple yo |
| 2021-11-01 22:36:09 +0100 | <sclv> | these are lovely people and you making personal attacks on them is winning you no friends |
| 2021-11-01 22:36:15 +0100 | <sclv> | i'm sorry you're having a hard time with the paper |
| 2021-11-01 22:36:15 +0100 | mmhat | (~mmh@55d4a9b2.access.ecotel.net) |
| 2021-11-01 22:36:21 +0100 | <sclv> | there is NO EXCUSE for that sort of rudeness |
| 2021-11-01 22:36:26 +0100 | <sclv> | to our friends and community members |
| 2021-11-01 22:36:35 +0100 | <maerwald> | what's the paper in question even |
| 2021-11-01 22:36:36 +0100 | <dartford> | i meant that their girlfriends would be angry at people wasting their time, not that they were unlovable |
| 2021-11-01 22:36:48 +0100 | <monochrom> | The "selective" paper. |
| 2021-11-01 22:36:48 +0100 | <dartford> | you misunderstood |
| 2021-11-01 22:36:57 +0100 | <dartford> | i did not mean any form of rudeness |
| 2021-11-01 22:37:03 +0100 | <sclv> | maerwald: the selective functors paper by mokhov, simon marlow et al |
| 2021-11-01 22:37:11 +0100 | <dartford> | other than to the forces of constant derailment that beset our beloveds |
| 2021-11-01 22:37:20 +0100 | <sclv> | seriously i'm going to ask the ops to kick you |
| 2021-11-01 22:37:35 +0100 | <dartford> | why? |
| 2021-11-01 22:37:43 +0100 | <maerwald> | I like selective |
| 2021-11-01 22:37:44 +0100 | <dartford> | because you thought i was being rude when i didnt mean to be |
| 2021-11-01 22:37:46 +0100 | <sclv> | for the continued trolling you're doing right now |
| 2021-11-01 22:37:47 +0100 | <dartford> | i appolgise |
| 2021-11-01 22:37:54 +0100 | <dartford> | im trying to molify you |
| 2021-11-01 22:37:58 +0100 | <dartford> | im sorry! |
| 2021-11-01 22:38:09 +0100 | <sclv> | ok just stop it, and ask questions if you have them |
| 2021-11-01 22:38:11 +0100 | <dartford> | im not trying to troll, i dont know how to get you to not be mad at me |
| 2021-11-01 22:38:18 +0100 | <sclv> | simply don't insult people |
| 2021-11-01 22:38:34 +0100 | <dartford> | i honestly dindt mean to |
| 2021-11-01 22:38:40 +0100 | <monochrom> | Yes I basically ban all sour-grape attitudes. |
| 2021-11-01 22:38:47 +0100 | <monochrom> | and entitlement attitudes. |
| 2021-11-01 22:39:06 +0100 | <geekosaur> | surprised you haven't already |
| 2021-11-01 22:39:10 +0100 | <dartford> | i feel like im being misconstrued, i meant no offence |
| 2021-11-01 22:39:14 +0100 | <janus> | but fog keeps coming back even though he is 'bannable'? |
| 2021-11-01 22:39:23 +0100 | <dartford> | please stop! |
| 2021-11-01 22:39:34 +0100 | <dartford> | i cant deal with this |
| 2021-11-01 22:39:36 +0100 | dartford | (~dartford@176-157-77-163.abo.bbox.fr) (Quit: Connection closed) |
| 2021-11-01 22:39:44 +0100 | <janus> | i don't understand it. it is entitled if you fill multiple screens and refuse to read, but it happens again and again |
| 2021-11-01 22:39:46 +0100 | <davean> | janus: who claimed monochrom was good at banning people? |
| 2021-11-01 22:39:48 +0100 | <sclv> | oh dartford is fog? |
| 2021-11-01 22:40:01 +0100 | <sclv> | jesus i had no idea, wouldn't have engaged |
| 2021-11-01 22:40:07 +0100 | <monochrom> | I did, heh. |
| 2021-11-01 22:40:13 +0100 | <sclv> | sigh |
| 2021-11-01 22:40:17 +0100 | ChanServ | +o geekosaur |
| 2021-11-01 22:40:47 +0100 | <davean> | Is there some origin story to fog? |
| 2021-11-01 22:40:49 +0100 | geekosaur | +b *!*@176-157-77-163.abo.bbox.fr |
| 2021-11-01 22:40:57 +0100 | geekosaur | -o geekosaur |
| 2021-11-01 22:41:03 +0100 | <geekosaur> | enough with that |
| 2021-11-01 22:41:10 +0100 | <dolio> | janus: Here's something to think about. I can write `Cont r (Either (b -> r) b)`. Does it contain an `Either (b -> r) b`? |
| 2021-11-01 22:41:19 +0100 | <dibblego> | the story is: long-term repetition of the above and I recommend: ban |
| 2021-11-01 22:41:38 +0100 | <davean> | dibblego: oh I know that, I'm just curious if theres an actual story or thats just who they are |
| 2021-11-01 22:41:44 +0100 | <maerwald> | I don't know. I always found it entertaining and only mildly disruptive |
| 2021-11-01 22:41:47 +0100 | <davean> | I certainly don't think its to anyone's benefit for them to be back |
| 2021-11-01 22:41:56 +0100 | <dolio> | If so, which one? |
| 2021-11-01 22:44:54 +0100 | <dolio> | Importantly, I can write a single value that works for all `r` and `b`. No need for particular choices. |
| 2021-11-01 22:48:36 +0100 | nickkkkk_all | (~nick_all@2603-6011-f940-1d00-0000-0000-0000-0002.res6.spectrum.com) |
| 2021-11-01 22:50:31 +0100 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 268 seconds) |
| 2021-11-01 22:51:02 +0100 | <nickkkkk_all> | hi guys. i'm reading the cabal docs and i'm a little confused. i ran cabal init thinking it would be interactive like the docs said. when i ran it, it gave me a Changelog.md app/Main.hs and a .cabal file (where I need to add some libraries that aren't exposed yet which I'm trying to learn how to do). but the hs source code has "module Main where" at the top so it doesn't look like it will build an |
| 2021-11-01 22:51:02 +0100 | <nickkkkk_all> | executable. could someone clarify? sorry for the noob question |
| 2021-11-01 22:51:49 +0100 | <sclv> | its fine, they switched the interactive and the not interactive flags and the docs are out of date |
| 2021-11-01 22:52:01 +0100 | <sclv> | but they will be correct again next release (where they switched the flags back) |
| 2021-11-01 22:52:06 +0100 | <monochrom> | cabal init -i, then it still asks you one last time and you have to say "I really want interactive" (I forgot whether that's a "yes" or "no") |
| 2021-11-01 22:52:20 +0100 | <nickkkkk_all> | oh ok. thanks |
| 2021-11-01 22:52:35 +0100 | <monochrom> | You can also edit your .cabal/config |
| 2021-11-01 22:53:09 +0100 | <nickkkkk_all> | yea i just didn't want to do that manually yet since i don't really know what i'm doing, but i'll search the docs |
| 2021-11-01 22:53:16 +0100 | <monochrom> | But sadly it will still ask you "are you really sure you want interactive? I really want to sell you the non-interactive version" |
| 2021-11-01 22:53:28 +0100 | <janus> | dolio: it must contain an "Either (b -> r) b" because you could choose r to be "Either (b -> r) b" and the "a -> r" function to be 'id'. is the problem here that it recursive? |
| 2021-11-01 22:53:35 +0100 | <davean> | The non-interactive version sucks |
| 2021-11-01 22:53:54 +0100 | <dolio> | janus: It's not recursive. |
| 2021-11-01 22:53:55 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-11-01 22:54:16 +0100 | <maerwald> | cabal should get some inspiration from summoner |
| 2021-11-01 22:54:20 +0100 | <janus> | what do you mean by "Importantly, i can write a single value". important for which goal? sorry i am dense |
| 2021-11-01 22:54:23 +0100 | <sclv> | nickkkkk_all: just rerun it with the `-i` flag after clearning out what it generated. interactive is the better default and its coming back. switching the behavior was a misfeature |
| 2021-11-01 22:54:33 +0100 | <maerwald> | https://asciinema.org/a/314375 like that |
| 2021-11-01 22:54:37 +0100 | <nickkkkk_all> | i don't need the module syntax right? i'm not going to be using this code as an external module. i'm following along with a course |
| 2021-11-01 22:54:41 +0100 | Null_A | (~null_a@2601:645:8700:2290:7887:7a6d:751e:a369) (Remote host closed the connection) |
| 2021-11-01 22:54:44 +0100 | <nickkkkk_all> | sclv: thanks |
| 2021-11-01 22:54:56 +0100 | <monochrom> | janus, I don't know the answer either (oh wait what I have done? >:) ), but I very much worry about the same r being used in both "Cont r" and "b->r". |
| 2021-11-01 22:55:02 +0100 | <dolio> | janus: It's important because there is no value of `Either (b -> r) b` in general. :) |
| 2021-11-01 22:55:16 +0100 | Null_A | (~null_a@2601:645:8700:2290:7887:7a6d:751e:a369) |
| 2021-11-01 22:55:25 +0100 | <sclv> | nickkkkk_all: you always want `module Main where` to start your main app file if you're building an executable |
| 2021-11-01 22:55:57 +0100 | <sclv> | every haskell file has `module Something where` near the top -- Main is just the name that the main module of an executable has |
| 2021-11-01 22:55:57 +0100 | <dolio> | No way to write a well defined one for all `r` and `b`, at least. |
| 2021-11-01 22:56:14 +0100 | <geekosaur> | "module Main where" will be the default for an executable, but there's no harm in saying it explicitly |
| 2021-11-01 22:56:19 +0100 | <monochrom> | Normally if I'm looking at "Cont r (Either x y)" I am OK with "yes it contains an Either x y value", but that's when x and y are independent of r. |
| 2021-11-01 22:56:49 +0100 | <monochrom> | And actually it's more like "module Main(main)" |
| 2021-11-01 22:56:54 +0100 | <janus> | dolio: but isn't this similar to saying "Maybe a" is not a container because i can choose Void and then it can't actually store anything? |
| 2021-11-01 22:57:38 +0100 | <janus> | dolio: why should we be able to choose a value for a generic type for it to be a container? |
| 2021-11-01 22:57:38 +0100 | <maerwald> | containers are more like possibilities... so actually non-determinism :D |
| 2021-11-01 22:58:28 +0100 | Guest41 | (~Guest41@eth-west-pareq2-46-193-4-100.wb.wifirst.net) (Ping timeout: 256 seconds) |
| 2021-11-01 22:59:45 +0100 | Null_A | (~null_a@2601:645:8700:2290:7887:7a6d:751e:a369) (Ping timeout: 268 seconds) |
| 2021-11-01 22:59:48 +0100 | <nickkkkk_all> | ok that makes sense. the only haskell i've ever written was for xmonad.hs which i guess technically isn't an executable |
| 2021-11-01 23:00:17 +0100 | <dolio> | Is my value of `Cont r (Either (b -> r) b)` just empty, like the Maybe value? |
| 2021-11-01 23:00:22 +0100 | <nickkkkk_all> | the interactive init process was much better |
| 2021-11-01 23:00:32 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:54f0:825c:9f33:c349) |
| 2021-11-01 23:02:06 +0100 | <dsal> | I'm annoyed at how my coverage test marks things as yellow when they weren't touched even though there's not much room for them to be wrong. |
| 2021-11-01 23:02:11 +0100 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) (Quit: Leaving) |
| 2021-11-01 23:05:58 +0100 | <dolio> | For instance, there's no well-defined value `Cont r r` for arbitrary `r`. |
| 2021-11-01 23:06:44 +0100 | ubert | (~Thunderbi@p548c9652.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2021-11-01 23:06:57 +0100 | chomwitt | (~chomwitt@ppp-2-85-245-90.home.otenet.gr) (Remote host closed the connection) |
| 2021-11-01 23:08:36 +0100 | <nickkkkk_all> | ok is this what I should do? build-depends: codeworld-api, ... |
| 2021-11-01 23:08:37 +0100 | <janus> | dolio: right, but regarding polymorphic types i regard it is possibly containing information (optimistic?). i don't see why there needs to be a value for an arbitrary instantiation |
| 2021-11-01 23:09:00 +0100 | <janus> | dolio: i see it as consistent with "Maybe" being a container |
| 2021-11-01 23:09:35 +0100 | <nickkkkk_all> | when i ran "cabal install codeworld-api" it said that the libraries weren't exposed because i didn't use the --lib flag so i think this is what i'm supposed to do but i'm not sure |
| 2021-11-01 23:09:39 +0100 | <janus> | and i'd even argue that Solo/Identity are containers even though there is no value to construct for an arbitrary instantiation |
| 2021-11-01 23:09:55 +0100 | <janus> | maybe i am not understanding the point about your Either containing a function... |
| 2021-11-01 23:10:13 +0100 | <monochrom> | build-depends is preferred. |
| 2021-11-01 23:10:36 +0100 | <monochrom> | But --lib is OK if you still want "I just run ghci and I have the library available" |
| 2021-11-01 23:10:45 +0100 | <janus> | but i guess i have made the term so permissive that it becomes meaningless :P |
| 2021-11-01 23:11:13 +0100 | <dolio> | I don't know what Solo is. Identity is arguably a container of exactly one thing. |
| 2021-11-01 23:11:48 +0100 | <nickkkkk_all> | i don't really want that. i'm only working with codeworld api in a project so i can follow along with this course. i don't think the api is used after lecture 4 and i'll move on to "real" code bases |
| 2021-11-01 23:11:54 +0100 | <janus> | dolio: i just learnt about this, it is some new one-tuple in ghc 9.2: https://www.reddit.com/r/haskell/comments/qjgg60/fyi_we_have_1tuple_in_base_since_ghc_92/hiurwzr/?… |
| 2021-11-01 23:11:55 +0100 | <dolio> | The point of `Cont r r` was that a `Cont r` can't just be an empty container. |
| 2021-11-01 23:12:49 +0100 | <janus> | ooh ok, so it should be able to be empty to be a container? that makes sense, i guess |
| 2021-11-01 23:13:11 +0100 | <dolio> | So, `Cont r a` can't just be empty, and no values of `Either (b -> r) b` can be demonstrated, but we can demonstrate `Cont r (Either (b -> r) b)`. |
| 2021-11-01 23:13:52 +0100 | <sclv> | nickkkkk_all: if you're using a recent cabal you don't need to install the deps explicitly |
| 2021-11-01 23:14:12 +0100 | <sclv> | as long as you use cabal commands `cabal build` `cabal repl` etc it'll install and mange em for you |
| 2021-11-01 23:14:21 +0100 | <sclv> | based on your .cabal file |
| 2021-11-01 23:14:25 +0100 | <dolio> | It's fine to consider containers that can't be empty. But how can you have a container that can't be empty but also not be able to have anything to put in it? |
| 2021-11-01 23:14:57 +0100 | <nickkkkk_all> | sclv: oh nice |
| 2021-11-01 23:15:13 +0100 | <nickkkkk_all> | on another note: dist-newstyle/build/x86_64-linux/ghc-8.10.7/haskell-fun-0.1.0.0/x/haskell-fun/build/haskell-fun/ why????????????/ |
| 2021-11-01 23:15:24 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-11-01 23:17:04 +0100 | <monochrom> | You can use "cabal install --install-method=copy --overwrite-policy=always --installdir=<???>" |
| 2021-11-01 23:17:45 +0100 | <sclv> | the length paths are because we can have crosscomp and share between multiple compilers and also have different subcomponents |
| 2021-11-01 23:18:06 +0100 | <nickkkkk_all> | ok that's better. so far the cabal defaults are very annoying... |
| 2021-11-01 23:18:08 +0100 | <sclv> | its pretty hard to cut them down without accidentally creating the possibility of incompatible build products being shared |
| 2021-11-01 23:18:34 +0100 | <nickkkkk_all> | sclv: that makes sense. so the default path is good for a real project i assume? |
| 2021-11-01 23:18:50 +0100 | <sclv> | well its unavoidable, it seems |
| 2021-11-01 23:18:59 +0100 | <sclv> | unfortunate though |
| 2021-11-01 23:19:15 +0100 | <sclv> | `cabal run` will run an executable too, so... eh |
| 2021-11-01 23:19:20 +0100 | <dsal> | Is there a place where HPC bugs are filed? It seems particularly strange that RecordWildCards doesn't show up as record field accesses. |
| 2021-11-01 23:19:30 +0100 | <dsal> | I'm sure that's a really slimy bag of worms. |
| 2021-11-01 23:20:03 +0100 | <nickkkkk_all> | this is a huge learning curve :) |
| 2021-11-01 23:20:24 +0100 | <monochrom> | "cabal run" oversteps its place regarding what should go to stdout. |
| 2021-11-01 23:20:43 +0100 | <nickkkkk_all> | monochrom: what does that mean |
| 2021-11-01 23:21:10 +0100 | <monochrom> | You get an extra "Up to date" line for example. |
| 2021-11-01 23:21:13 +0100 | <sclv> | dsal: those go in the general ghc bug tracker. i think there's a tag or category that would class em as hpc |
| 2021-11-01 23:22:06 +0100 | <dsal> | https://gitlab.haskell.org/ghc/ghc/-/issues/17834 |
| 2021-11-01 23:22:08 +0100 | <monochrom> | So suppose your program is meant to output valid json to stdout. Well now your stdout is polluted. |
| 2021-11-01 23:22:10 +0100 | <dsal> | Looks like someone's already found it. |
| 2021-11-01 23:23:54 +0100 | <sclv> | monochrom: do you think the correct solution is to add a flag for quiet mode or "no junk" or the like? if so and if you can think of the right flag name, please open a ticket |
| 2021-11-01 23:24:26 +0100 | fendor | (~fendor@77.119.197.65.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 2021-11-01 23:24:27 +0100 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-11-01 23:24:28 +0100 | <geekosaur> | sclv, seems to me that should go to stderr |
| 2021-11-01 23:24:39 +0100 | <sclv> | oh fair point |
| 2021-11-01 23:24:39 +0100 | <geekosaur> | (and yes, that's annoyed me as well) |
| 2021-11-01 23:24:52 +0100 | <monochrom> | To be honest, I simply don't use cabal run. |
| 2021-11-01 23:24:52 +0100 | <nickkkkk_all> | yea that sounds like a reasonable thing. in my case i don't care. my code isn't even working for some reason anyway |
| 2021-11-01 23:25:10 +0100 | <monochrom> | And there are multiple reasons, not just this one. |
| 2021-11-01 23:25:19 +0100 | <monochrom> | There is no use case at all. |
| 2021-11-01 23:26:13 +0100 | <nickkkkk_all> | it says "Open me on http://127.0.0.1:3000/" but firefox is saying unable to connect |
| 2021-11-01 23:26:21 +0100 | <monochrom> | If I want to use an exe regularly, "cabal install" is the right thing to do, and with --installdir=<something actually on PATH>. Why would I cd into some development directory to "cabal run" for a program I use regulary? |
| 2021-11-01 23:26:42 +0100 | <geekosaur> | nickkkkk_all, what kind of system are you on? could it have a firewall preventing such connections? |
| 2021-11-01 23:26:43 +0100 | <monochrom> | If I want to test, "cabal repl" and "cabal test" have got that covered. |
| 2021-11-01 23:26:51 +0100 | <monochrom> | So, when do I need "cabal run" again? |
| 2021-11-01 23:27:04 +0100 | <dsal> | Yeah, the other hpc case that bugged me was about derived instances. Technically, I haven't tested all aspects of various derived junk. But also, I feel like that's not my job. |
| 2021-11-01 23:27:08 +0100 | <nickkkkk_all> | i don't have any firewalls |
| 2021-11-01 23:27:40 +0100 | <geekosaur> | monochrom, I use iit for programs where the executable would be ephemeral anyway — I'm constantly rejiggering various things inside the program |
| 2021-11-01 23:28:13 +0100 | <nickkkkk_all> | that's the case i'm using it for right now. a dumb program that i'm just writing for learning purposes |
| 2021-11-01 23:28:24 +0100 | <geekosaur> | so "cabal run" keeps track for me of when a rebuild is needed, and I don't have an executable in $PATH that'll just have to be overwritten in a few hours anyway |
| 2021-11-01 23:28:38 +0100 | <monochrom> | Yeah there are a few rare moments when I make peace with dist-newstyle/xxx/yyy/zzz/x/xxx |
| 2021-11-01 23:28:38 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2021-11-01 23:28:45 +0100 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) (Ping timeout: 268 seconds) |
| 2021-11-01 23:28:59 +0100 | <sclv> | filed a ticket for cabal run, but honestly its probably a bit of a PITA to fix since that shares output with all the other cabal commands |
| 2021-11-01 23:30:22 +0100 | <nickkkkk_all> | geekosaur: it also tells me i need to recompile with the -threaded flag. could that be it? |
| 2021-11-01 23:30:39 +0100 | <geekosaur> | (also I only use it when working on a particular project so I don't really want it on $PATH anyway) |
| 2021-11-01 23:31:08 +0100 | <geekosaur> | nickkkkk_all, that should not prevent connections, I think |
| 2021-11-01 23:31:24 +0100 | <geekosaur> | although if it's demanding -threaded you probably should enable it |
| 2021-11-01 23:31:51 +0100 | <sclv> | you can add -threaded to the ghc options in the cabal file |
| 2021-11-01 23:32:57 +0100 | quazimodo | (~quazimodo@n1-40-235-47.bla1.nsw.optusnet.com.au) |
| 2021-11-01 23:34:16 +0100 | G_w | (~Gw@197.3.191.56) |
| 2021-11-01 23:34:32 +0100 | <nickkkkk_all> | there isn't a section for that so i guess i'll have to make one |
| 2021-11-01 23:34:42 +0100 | <nickkkkk_all> | just ghc-options:? |
| 2021-11-01 23:35:02 +0100 | <monochrom> | ghc-options: in the same section as the exe's section |
| 2021-11-01 23:36:12 +0100 | hololeap | (~hololeap@user/hololeap) (Ping timeout: 276 seconds) |
| 2021-11-01 23:36:30 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2021-11-01 23:36:35 +0100 | <nickkkkk_all> | that fixed my issue. thanks for the help guys. hopefully before long i won't be asking so many questions |
| 2021-11-01 23:36:40 +0100 | <nickkkkk_all> | i'm gonna get to coding |
| 2021-11-01 23:40:48 +0100 | <hpc> | hopefully you keep asking questions forever, they just get increasingly complicated and obscure :D |
| 2021-11-01 23:46:36 +0100 | <nickkkkk_all> | that's definitely the plan |
| 2021-11-01 23:47:20 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-11-01 23:49:35 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) |
| 2021-11-01 23:54:39 +0100 | yauhsien | (~yauhsien@61-231-61-245.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-11-01 23:55:02 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-11-01 23:56:50 +0100 | thblt | (~thblt@user/thblt) |
| 2021-11-01 23:59:31 +0100 | Axman6 | (~Axman6@user/axman6) |