| 2021-07-09 00:02:03 +0200 | jespada | (~jespada@90.254.247.46) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-09 00:02:17 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 00:02:44 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-09 00:02:57 +0200 | <koz> | If I want to test whether something _compiles_ (say, if I'm trying to TH stuff up) in an automated way, what's a good thing to use? |
| 2021-07-09 00:02:57 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2021-07-09 00:03:03 +0200 | jespada | (~jespada@90.254.247.46) |
| 2021-07-09 00:03:18 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) (Quit: Client closed) |
| 2021-07-09 00:03:28 +0200 | <geekosaur> | ghc -fno-code ? |
| 2021-07-09 00:03:41 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) |
| 2021-07-09 00:03:43 +0200 | <koz> | I mean, something similar to unit tests. |
| 2021-07-09 00:03:57 +0200 | <koz> | So I can like, run it as part of a test suite and have it fail if compilation fails. |
| 2021-07-09 00:05:40 +0200 | dminuoso | would also add -O0 to geekosaur's suggestion |
| 2021-07-09 00:05:44 +0200 | neceve | (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) (Ping timeout: 252 seconds) |
| 2021-07-09 00:05:52 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-09 00:06:34 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 00:07:26 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2021-07-09 00:10:59 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Ping timeout: 255 seconds) |
| 2021-07-09 00:13:53 +0200 | argento | (~argent0@168-227-97-34.ptr.westnet.com.ar) |
| 2021-07-09 00:14:36 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2021-07-09 00:17:21 +0200 | argento | (~argent0@168-227-97-34.ptr.westnet.com.ar) (Client Quit) |
| 2021-07-09 00:20:22 +0200 | mikail | (~mikail@2a02:c7f:bd83:fd00:55cf:122f:957a:f66f) |
| 2021-07-09 00:21:40 +0200 | trattue | (~trattue@152.70.182.158) (Quit: bye) |
| 2021-07-09 00:21:47 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-09 00:22:11 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-09 00:29:22 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 240 seconds) |
| 2021-07-09 00:29:36 +0200 | aerona | (~aerona@2600:6c54:4600:f300:c99c:8727:19f:ba14) |
| 2021-07-09 00:29:56 +0200 | acidjnk | (~acidjnk@p200300d0c72b956384793fd2325b5113.dip0.t-ipconnect.de) |
| 2021-07-09 00:30:09 +0200 | slep | (~slep@cpc150002-brnt4-2-0-cust437.4-2.cable.virginm.net) (Quit: No Ping reply in 180 seconds.) |
| 2021-07-09 00:30:13 +0200 | mikail | (~mikail@2a02:c7f:bd83:fd00:55cf:122f:957a:f66f) (Ping timeout: 246 seconds) |
| 2021-07-09 00:30:13 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 246 seconds) |
| 2021-07-09 00:30:22 +0200 | slep | (~slep@cpc150002-brnt4-2-0-cust437.4-2.cable.virginm.net) |
| 2021-07-09 00:30:43 +0200 | fendor | (~fendor@91.141.49.3.wireless.dyn.drei.com) (Read error: Connection reset by peer) |
| 2021-07-09 00:33:01 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 00:33:43 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 00:37:59 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Ping timeout: 255 seconds) |
| 2021-07-09 00:38:53 +0200 | chomwitt | (~Pitsikoko@athedsl-16082.home.otenet.gr) (Ping timeout: 255 seconds) |
| 2021-07-09 00:42:29 +0200 | acowley | (~acowley@c-68-83-22-43.hsd1.nj.comcast.net) (Read error: Connection reset by peer) |
| 2021-07-09 00:50:13 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 00:51:10 +0200 | acowley | (~acowley@c-68-83-22-43.hsd1.nj.comcast.net) |
| 2021-07-09 00:52:11 +0200 | kilolympus | (~kilolympu@cpc92710-cmbg20-2-0-cust265.5-4.cable.virginm.net) (Read error: Connection reset by peer) |
| 2021-07-09 00:53:53 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-09 00:53:53 +0200 | Kaipi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Ping timeout: 265 seconds) |
| 2021-07-09 00:58:07 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-07-09 00:59:19 +0200 | Atum_ | (~IRC@user/atum/x-2392232) |
| 2021-07-09 01:03:10 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 01:06:00 +0200 | ptr_frac7al | (~longlong@user/ptr-frac7al/x-0038398) |
| 2021-07-09 01:07:45 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-09 01:07:52 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 01:08:10 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 272 seconds) |
| 2021-07-09 01:12:33 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 258 seconds) |
| 2021-07-09 01:12:53 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 01:13:55 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 01:19:40 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-07-09 01:24:20 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-09 01:25:41 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-07-09 01:25:44 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 244 seconds) |
| 2021-07-09 01:34:14 +0200 | alx741 | (~alx741@181.196.68.47) (Ping timeout: 255 seconds) |
| 2021-07-09 01:38:56 +0200 | <oak-> | I've been doing my first project where I'm writing Haskell code into production system and being paid doing the work, and I must say that I'm amazed how quick I can advance on the project even though I think I'm still quite beginner with Haskell |
| 2021-07-09 01:39:12 +0200 | <oak-> | The client said I can use any programming language I want, so I naturally chose Haskell :D |
| 2021-07-09 01:39:23 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b95631d5780c7e55edf21.dip0.t-ipconnect.de) |
| 2021-07-09 01:40:03 +0200 | acidjnk_new3 | (~acidjnk@p200300d0c72b9563e5efeb4dbf0edadc.dip0.t-ipconnect.de) |
| 2021-07-09 01:40:45 +0200 | <oak-> | The solution is already working quite well, but I think I should probably learn either MTL or Tagless Final to make the code cleaner and more readable |
| 2021-07-09 01:40:45 +0200 | <orzo> | sounds nice |
| 2021-07-09 01:41:00 +0200 | jol | (~jol@jol.dev) |
| 2021-07-09 01:43:08 +0200 | <oak-> | The downside is there won't be not so many hours to bill :D |
| 2021-07-09 01:43:12 +0200 | acidjnk | (~acidjnk@p200300d0c72b956384793fd2325b5113.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2021-07-09 01:43:43 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-07-09 01:44:04 +0200 | <orzo> | last time i used haskell in production, i was bitten by the poor cross support |
| 2021-07-09 01:44:11 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b95631d5780c7e55edf21.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2021-07-09 01:44:16 +0200 | <orzo> | it was a long time ago |
| 2021-07-09 01:44:35 +0200 | <orzo> | but ghc still isn't well known for being a great cross compiler |
| 2021-07-09 01:45:42 +0200 | <orzo> | it's surely better now than then though |
| 2021-07-09 01:46:02 +0200 | <orzo> | still, i wished it "just worked" |
| 2021-07-09 01:46:05 +0200 | <oak-> | I'm doing development on Mac and then using virtual machine with Ubuntu (because the target system is using Ubuntu) to build the code and package it to .deb package, and then just deploy the .deb package to target system |
| 2021-07-09 01:46:05 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds) |
| 2021-07-09 01:46:21 +0200 | <oak-> | At least on Mac Os and Linux it runs, I haven't tried Windows :P |
| 2021-07-09 01:46:37 +0200 | <orzo> | i was on mac too |
| 2021-07-09 01:46:44 +0200 | <orzo> | years ago |
| 2021-07-09 01:46:47 +0200 | <orzo> | say 2008 |
| 2021-07-09 01:46:50 +0200 | justache | (~justache@user/justache) (Read error: Connection reset by peer) |
| 2021-07-09 01:47:10 +0200 | <orzo> | it sounds like you got a nice dev enviro setup |
| 2021-07-09 01:47:44 +0200 | justache | (~justache@user/justache) |
| 2021-07-09 01:47:50 +0200 | <orzo> | it's annoying how everything takes tons of resources to build nowadays |
| 2021-07-09 01:48:01 +0200 | <orzo> | i'm using an old laptop as my main computer |
| 2021-07-09 01:48:09 +0200 | <orzo> | that i do all my dev on |
| 2021-07-09 01:48:31 +0200 | <orzo> | there's no reason why projects can't build on this machine |
| 2021-07-09 01:48:49 +0200 | <orzo> | i'm particularly annoyed with the latest android tools |
| 2021-07-09 01:48:52 +0200 | <orzo> | not haskell related |
| 2021-07-09 01:49:19 +0200 | <oak-> | I have also done Android development in the past in various companies |
| 2021-07-09 01:49:29 +0200 | <orzo> | i wish i could write android in haskell and use only ghc to make an apk file |
| 2021-07-09 01:49:39 +0200 | <oak-> | Like at the operating system level, built the whole Android image from the source |
| 2021-07-09 01:49:49 +0200 | <orzo> | oh right |
| 2021-07-09 01:49:53 +0200 | <orzo> | that's what i wish i could avoid |
| 2021-07-09 01:50:12 +0200 | <orzo> | but just using the sdk/studio seems to be almost as much resources as the whole os |
| 2021-07-09 01:50:15 +0200 | <oak-> | Even with the latest hardware the clean build seems to take ~1 hour |
| 2021-07-09 01:50:44 +0200 | <oak-> | Last Android I was building was the 8.1 or something, I haven't tried to build the latest 11 version |
| 2021-07-09 01:51:47 +0200 | <oak-> | There's just massive amounts of Java code on the Android operating system, especially in the frameworks/base |
| 2021-07-09 01:51:59 +0200 | <oak-> | Yeah, isn't the Android Studio based on IntelliJ IDEA or something |
| 2021-07-09 01:52:19 +0200 | <orzo> | i'd like a way to just build apk files from java source and resources using gnu make or something |
| 2021-07-09 01:52:22 +0200 | <koz> | oak-: Yep, I believe so. |
| 2021-07-09 01:52:38 +0200 | <orzo> | we shouldn't need a huge sdk |
| 2021-07-09 01:52:46 +0200 | <orzo> | android is just a linux distro ultimately |
| 2021-07-09 01:54:33 +0200 | <oak-> | Last time I did Android App development I just used NeoVim from the shell and built with Gradle from the shell |
| 2021-07-09 01:54:39 +0200 | <oak-> | It still uses quite much resources though |
| 2021-07-09 01:55:47 +0200 | <orzo> | is there some reason why community people cant maintain an alternate build system for android? |
| 2021-07-09 01:56:10 +0200 | <orzo> | it seems simple in principle, just pack .dex files and .res files into an .apk zip |
| 2021-07-09 01:56:37 +0200 | <orzo> | gradle would be an improvement over the studio maybe, but i'm currently annoyed with it too |
| 2021-07-09 01:57:18 +0200 | <orzo> | i think letting google maintain all the dev tools for android is not working out |
| 2021-07-09 01:57:21 +0200 | <oak-> | Doesn't Studio use Gradle in the background? |
| 2021-07-09 01:57:24 +0200 | <orzo> | yes |
| 2021-07-09 01:57:31 +0200 | <orzo> | but i don't know how to use gradle |
| 2021-07-09 01:57:41 +0200 | <orzo> | i'm coming back to android after a long hiatus |
| 2021-07-09 01:57:41 +0200 | cjb | (~cjb@user/cjb) |
| 2021-07-09 01:57:48 +0200 | <orzo> | back in my day it was eclipse and ant |
| 2021-07-09 01:58:41 +0200 | <oak-> | Gradle seems fine as long at it works :D |
| 2021-07-09 01:58:46 +0200 | <orzo> | i have good makefile skills, so its a little annoying to have to work with these super ambitious build systems that ultimately just disable incremental builds |
| 2021-07-09 01:59:47 +0200 | <oak-> | I tried Eta (compiler which compiles Haskell to Java bytecode) a year ago, and it was pain to work around all the tooling |
| 2021-07-09 02:00:07 +0200 | <orzo> | i trie dto build that recently with a ghc 7.10.3 binary i downloaded |
| 2021-07-09 02:00:14 +0200 | <orzo> | it fails with a lot of link issues |
| 2021-07-09 02:01:13 +0200 | <orzo> | one thing i really like about ghc is that you don't even need cabal if you are compiling a single file haskell program |
| 2021-07-09 02:01:23 +0200 | <orzo> | you just pass it to the compiler and it makes a binary |
| 2021-07-09 02:01:24 +0200 | <orzo> | very simple |
| 2021-07-09 02:01:32 +0200 | <orzo> | i want that for android |
| 2021-07-09 02:01:44 +0200 | <orzo> | hello world android shouldn't even need a build system |
| 2021-07-09 02:01:48 +0200 | <oak-> | I've been looking forward to try to use Reflex to build native Android apps, that should use regular GHC to build native code |
| 2021-07-09 02:02:01 +0200 | <orzo> | i'm not familiar with Reflex |
| 2021-07-09 02:02:03 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 02:02:35 +0200 | <oak-> | That is a set of libraries for Haskell to implement the functional reactive programming paradigm |
| 2021-07-09 02:02:39 +0200 | <orzo> | even deb files can be packed manulally from components |
| 2021-07-09 02:03:04 +0200 | <orzo> | is that how you pack your debs on your haskell-mac-to-ubuntu system? |
| 2021-07-09 02:03:31 +0200 | <oak-> | I think it needs to be packaged because of the Java's class system |
| 2021-07-09 02:04:30 +0200 | <oak-> | I'm just building the binary with stack, and then generating the .deb package with fpm |
| 2021-07-09 02:05:20 +0200 | <orzo> | i wonder if fpm can be made to support android |
| 2021-07-09 02:05:43 +0200 | <oak-> | fpm makes it much easier to generate simple .deb packages (and also simple .rpm packages) |
| 2021-07-09 02:05:44 +0200 | DNH | (~DNH@2a02:8108:1100:16d8:99cf:ff96:88:4a77) (Ping timeout: 255 seconds) |
| 2021-07-09 02:06:00 +0200 | <orzo> | i'm pretty familiar with dpkg-deb and what not |
| 2021-07-09 02:06:12 +0200 | <orzo> | i make a lot of casual deb packaging for my own purposes |
| 2021-07-09 02:06:36 +0200 | <oak-> | Yeah it's just more complicated, you need to write like 5 files to control what kind of .deb package is created :D |
| 2021-07-09 02:06:37 +0200 | <orzo> | i use debian |
| 2021-07-09 02:06:49 +0200 | <orzo> | hm |
| 2021-07-09 02:06:49 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 246 seconds) |
| 2021-07-09 02:06:59 +0200 | Deide | (~Deide@user/deide) (Quit: Seeee yaaaa) |
| 2021-07-09 02:07:35 +0200 | <orzo> | fpm doesn't seem to be in th edebian archives |
| 2021-07-09 02:08:22 +0200 | <orzo> | if it was, i'd install it and maybe try it out |
| 2021-07-09 02:08:32 +0200 | <orzo> | but i cant be bothered to clone it and install from source |
| 2021-07-09 02:08:59 +0200 | <oak-> | It can be installed from rubygems |
| 2021-07-09 02:11:02 +0200 | acidjnk_new3 | (~acidjnk@p200300d0c72b9563e5efeb4dbf0edadc.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2021-07-09 02:11:27 +0200 | <orzo> | i have an old android app that i screwed up the gradle files for |
| 2021-07-09 02:11:33 +0200 | <orzo> | i don't know how to get it to build |
| 2021-07-09 02:11:49 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 02:12:00 +0200 | <orzo> | i recently got a fresh wizard-created app to build and run from the studio |
| 2021-07-09 02:12:20 +0200 | <orzo> | but my old eclipse/ant app is borked |
| 2021-07-09 02:15:59 +0200 | <orzo> | every binary in the sdk seems to consist of a bash script with over 80 lines of code to set up the enviro |
| 2021-07-09 02:16:01 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 02:16:46 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Read error: Connection reset by peer) |
| 2021-07-09 02:16:48 +0200 | <oak-> | It shouldn't be that hard but you probably need to match the SDK version you initially used to build the app |
| 2021-07-09 02:19:08 +0200 | <oak-> | Also It starts to be a bit offtopic if we start to debug your Android app building in the #haskell channel :P |
| 2021-07-09 02:20:04 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2021-07-09 02:21:18 +0200 | <orzo> | yeah sorry |
| 2021-07-09 02:30:21 +0200 | P1RATEZ | (piratez@user/p1ratez) |
| 2021-07-09 02:33:25 +0200 | dajoer | (~david@user/gvx) |
| 2021-07-09 02:36:29 +0200 | Atum_ | (~IRC@user/atum/x-2392232) (Quit: Atum_) |
| 2021-07-09 02:36:38 +0200 | <ephemient> | Bazel and Buck both seem to have teams maintaining their android app building capabilities |
| 2021-07-09 02:37:19 +0200 | <ephemient> | probably not gonna be any lighter on orzo's computer than Gradle, though |
| 2021-07-09 02:40:55 +0200 | hmmmas | (~fidnc@183.217.200.144) |
| 2021-07-09 02:43:17 +0200 | <orzo> | everyone makes huge hungry build enviros these days |
| 2021-07-09 02:44:29 +0200 | <orzo> | there should be an effort to make building accessible to cheap low power devices |
| 2021-07-09 02:44:51 +0200 | <orzo> | i'm on an i5 anyway with 8gig ram, it should be sufficient |
| 2021-07-09 02:45:18 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-09 02:45:51 +0200 | <orzo> | one might suspect they don't want people to build their own binaries |
| 2021-07-09 02:46:03 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-09 02:53:40 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 02:53:51 +0200 | cjb | (~cjb@user/cjb) (Ping timeout: 246 seconds) |
| 2021-07-09 02:57:39 +0200 | epolanski | (uid312403@id-312403.brockwell.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-09 02:58:14 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Remote host closed the connection) |
| 2021-07-09 02:59:51 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Remote host closed the connection) |
| 2021-07-09 03:04:51 +0200 | <exarkun> | what force is there exerting pressure on the software development process not increase its resource usage, apart from the absolute limit on what resources are actually available? |
| 2021-07-09 03:05:18 +0200 | <exarkun> | and lacking such a force, why would resource usage not continuously expand to that limit? |
| 2021-07-09 03:08:28 +0200 | <davean> | exarkun: I find making it complex harder, and I don't need to show I'm making a tangled mess to keep my job, so I can do it simply? |
| 2021-07-09 03:09:09 +0200 | <orzo> | the force is randos like me longing for simpler tools |
| 2021-07-09 03:10:56 +0200 | sheepduck | (~sheepduck@user/sheepduck) (Remote host closed the connection) |
| 2021-07-09 03:12:05 +0200 | <exarkun> | davean: Is _making_ it complex harder? Or is it harder to deal with once it's been made complex? |
| 2021-07-09 03:12:23 +0200 | <exarkun> | And then once it's hard to deal with, what's the easiest thing to do? Well, add some more complexity of course... |
| 2021-07-09 03:13:39 +0200 | <exarkun> | Just pull in another library, adopt a fancier build system, set up CI, set up CD, use tools to automate the development workflow, pull in linters, and formatters, and ... |
| 2021-07-09 03:14:22 +0200 | <dsal> | Extra points if the additional layer has "simple" in the name. |
| 2021-07-09 03:14:25 +0200 | <exarkun> | orzo: Yea, not enough of a force I guess. 1000x people who can't even recognize simple for every one of you randos. |
| 2021-07-09 03:15:32 +0200 | <DigitalKiwi> | orzo++ |
| 2021-07-09 03:15:36 +0200 | <exarkun> | Even if you _want_ things to be simpler, you also want to get things done sometimes |
| 2021-07-09 03:16:05 +0200 | <exarkun> | How often do you fully anticipate _all_ of the consequences of introducing a new piece of software into your system? |
| 2021-07-09 03:16:45 +0200 | <DigitalKiwi> | https://source.android.com/setup/build/requirements#hardware-requirements |
| 2021-07-09 03:16:47 +0200 | <exarkun> | There's extreme bias in the direction of more complexity, not less |
| 2021-07-09 03:16:52 +0200 | hegstal | (~hegstal@2a02:c7f:7604:8a00:5056:66c0:d6e:186f) (Remote host closed the connection) |
| 2021-07-09 03:17:34 +0200 | <DigitalKiwi> | my computer only has 16GB of ram ;_; |
| 2021-07-09 03:17:45 +0200 | <exarkun> | I sure don't like stripe-core's 20 minute build time, but what am I gonna do, write my own stripe client library? |
| 2021-07-09 03:18:04 +0200 | <DigitalKiwi> | and it only had 500GB ssd |
| 2021-07-09 03:18:44 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Remote host closed the connection) |
| 2021-07-09 03:19:46 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2021-07-09 03:19:59 +0200 | <DigitalKiwi> | which i finally upgraded but due to the infinite wisdom of apple this $3,500+ macbook pro has the ram soldered on so that one's out... |
| 2021-07-09 03:20:13 +0200 | <DigitalKiwi> | 3 |
| 2021-07-09 03:20:50 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 03:20:57 +0200 | <dsal> | You don't have a heat gun? |
| 2021-07-09 03:21:57 +0200 | wei2912 | (~wei2912@112.199.250.21) |
| 2021-07-09 03:22:02 +0200 | <dsal> | All of my computers have 4GB of RAM or less. cachix+github actions makes things actually work at least for me. |
| 2021-07-09 03:22:12 +0200 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 252 seconds) |
| 2021-07-09 03:22:31 +0200 | maf654321 | (~maf654321@user/maf654321) |
| 2021-07-09 03:23:43 +0200 | <DigitalKiwi> | i have several heat guns but i don't think it would help ;p |
| 2021-07-09 03:23:55 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-09 03:24:07 +0200 | <monochrom> | "developers" are spoiled. |
| 2021-07-09 03:24:31 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) |
| 2021-07-09 03:24:46 +0200 | <monochrom> | But what do you use a heat gun for? To fry the over-speced computers of the spoiled developers? >:) |
| 2021-07-09 03:24:53 +0200 | <exarkun> | monochrom: "users" are undiscerning? |
| 2021-07-09 03:25:15 +0200 | <monochrom> | Well, I'll complain about users some other day. |
| 2021-07-09 03:25:40 +0200 | <DigitalKiwi> | when your users are developers what now |
| 2021-07-09 03:25:49 +0200 | <exarkun> | or maybe both are true and irrelevant and fitness is maximized by the easy production and use of bloated software |
| 2021-07-09 03:26:22 +0200 | <exarkun> | The heat gun is for desoldering the tiny DIMMs before replacing them |
| 2021-07-09 03:26:39 +0200 | <monochrom> | cool |
| 2021-07-09 03:26:52 +0200 | <DigitalKiwi> | should i just ignore exarkun before i go off at them |
| 2021-07-09 03:27:51 +0200 | <exarkun> | DigitalKiwi: let me save you the trouble, I'm going to bed now |
| 2021-07-09 03:27:55 +0200 | <DigitalKiwi> | g'night |
| 2021-07-09 03:28:07 +0200 | <DigitalKiwi> | As of June 2021, Google is using 72-core machines with 64 GB of RAM internally, which take about 40 minutes for a full build (and just a few minutes for incremental builds, depending on exactly which files were modified). By contrast, a 6-core machine with a similar amount of RAM takes 3 hours. |
| 2021-07-09 03:28:07 +0200 | <DigitalKiwi> | lolol |
| 2021-07-09 03:28:55 +0200 | monochrom | intentional misreads that as "takes such and such time to build the machine" |
| 2021-07-09 03:29:26 +0200 | <monochrom> | "I would think that fewer cores takes less time to build" :) |
| 2021-07-09 03:30:24 +0200 | <DigitalKiwi> | well you see the 6-core machines have bigger cores so it takes longer to move them |
| 2021-07-09 03:31:40 +0200 | <monochrom> | I wonder if https://xkcd.com/303/ is the true incentive for longer build times. |
| 2021-07-09 03:32:53 +0200 | <oak-> | On one of my past workplaces they actually had the boffer swords in the office |
| 2021-07-09 03:33:17 +0200 | <monochrom> | nice |
| 2021-07-09 03:34:10 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 03:34:18 +0200 | xff0x | (~xff0x@2001:1a81:53dc:b800:d9eb:91ca:317b:6253) (Ping timeout: 252 seconds) |
| 2021-07-09 03:36:05 +0200 | xff0x | (~xff0x@2001:1a81:521d:ec00:3970:2542:2f1d:feb7) |
| 2021-07-09 03:38:26 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Ping timeout: 255 seconds) |
| 2021-07-09 03:42:57 +0200 | neurocyte404 | (~neurocyte@46.243.81.30) |
| 2021-07-09 03:42:57 +0200 | neurocyte404 | (~neurocyte@46.243.81.30) (Changing host) |
| 2021-07-09 03:42:57 +0200 | neurocyte404 | (~neurocyte@user/neurocyte) |
| 2021-07-09 03:46:34 +0200 | neurocyte40 | (~neurocyte@user/neurocyte) (Ping timeout: 240 seconds) |
| 2021-07-09 03:46:34 +0200 | neurocyte404 | neurocyte40 |
| 2021-07-09 03:47:00 +0200 | shredder | (~user@user/shredder) (Quit: quitting) |
| 2021-07-09 03:48:20 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 255 seconds) |
| 2021-07-09 03:49:20 +0200 | shredder | (~user@user/shredder) |
| 2021-07-09 03:51:24 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) (Remote host closed the connection) |
| 2021-07-09 03:51:56 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) |
| 2021-07-09 03:55:05 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-09 03:56:55 +0200 | falafel | (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Read error: Connection reset by peer) |
| 2021-07-09 04:00:17 +0200 | <davean> | exarkun: making it complex takes more work |
| 2021-07-09 04:00:24 +0200 | <davean> | exarkun: its easier to make it simple |
| 2021-07-09 04:00:35 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2021-07-09 04:01:57 +0200 | <davean> | exarkun: pretty sure a lot of complexity comes from people trying to look busy, important, and valuable. |
| 2021-07-09 04:02:55 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-09 04:08:16 +0200 | maf654321 | (~maf654321@user/maf654321) (Quit: Textual IRC Client: www.textualapp.com) |
| 2021-07-09 04:08:23 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2021-07-09 04:09:48 +0200 | mafdz | (~maf654321@user/maf654321) |
| 2021-07-09 04:11:04 +0200 | mafdz | maf654321 |
| 2021-07-09 04:17:46 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2021-07-09 04:18:57 +0200 | maf654321 | (~maf654321@user/maf654321) (Quit: ZNC 1.7.4 - https://znc.in) |
| 2021-07-09 04:20:32 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-07-09 04:21:07 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) (Remote host closed the connection) |
| 2021-07-09 04:23:19 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-07-09 04:23:19 +0200 | FinnElija | Guest181 |
| 2021-07-09 04:23:19 +0200 | Guest181 | (~finn_elij@user/finn-elija/x-0085643) (Killed (mercury.libera.chat (Nickname regained by services))) |
| 2021-07-09 04:23:19 +0200 | finn_elija | FinnElija |
| 2021-07-09 04:23:27 +0200 | td_ | (~td@94.134.91.165) (Ping timeout: 258 seconds) |
| 2021-07-09 04:24:01 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 246 seconds) |
| 2021-07-09 04:24:30 +0200 | aerona | (~aerona@2600:6c54:4600:f300:c99c:8727:19f:ba14) (Quit: Leaving) |
| 2021-07-09 04:25:08 +0200 | td_ | (~td@muedsl-82-207-238-014.citykom.de) |
| 2021-07-09 04:25:40 +0200 | polykernel[m] | (~polykerne@2001:470:69fc:105::ba04) |
| 2021-07-09 04:27:52 +0200 | hexreel | (~hr@69.233.98.238) |
| 2021-07-09 04:33:37 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) |
| 2021-07-09 04:34:36 +0200 | safinaskar | (~user@109-252-90-89.nat.spd-mgts.ru) |
| 2021-07-09 04:34:39 +0200 | <safinaskar> | hi |
| 2021-07-09 04:34:50 +0200 | <safinaskar> | i just published my second hackage package! |
| 2021-07-09 04:35:18 +0200 | <safinaskar> | see ann: https://mail.haskell.org/pipermail/haskell-cafe/2021-July/134205.html |
| 2021-07-09 04:35:24 +0200 | <safinaskar> | it is parsing lib |
| 2021-07-09 04:35:27 +0200 | <safinaskar> | arrow parsing |
| 2021-07-09 04:37:16 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) (Remote host closed the connection) |
| 2021-07-09 04:37:52 +0200 | <Axman6> | That's the longest email subject I've seen in my life, haha |
| 2021-07-09 04:38:03 +0200 | <Axman6> | and longest package name too |
| 2021-07-09 04:39:06 +0200 | <safinaskar> | :) |
| 2021-07-09 04:39:13 +0200 | <safinaskar> | and longest package description? |
| 2021-07-09 04:39:25 +0200 | hmmmas1 | (~fidnc@183.217.200.144) |
| 2021-07-09 04:40:20 +0200 | <pavonia> | "the best parsing library" The code harder to read than e.g. MegaParsec code |
| 2021-07-09 04:41:16 +0200 | hmmmas1 | (~fidnc@183.217.200.144) (Client Quit) |
| 2021-07-09 04:41:38 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) |
| 2021-07-09 04:41:50 +0200 | hmmmas | (~fidnc@183.217.200.144) (Ping timeout: 252 seconds) |
| 2021-07-09 04:42:31 +0200 | hmmmas | (~fidnc@183.217.200.144) |
| 2021-07-09 04:42:48 +0200 | <safinaskar> | pavonia: yes. but megaparsec doesn't support unbiased choice |
| 2021-07-09 04:43:30 +0200 | <glguy> | safinaskar: happy has no trouble being used with tokens that have line and also column information |
| 2021-07-09 04:44:35 +0200 | dragestil | (~quassel@user/dragestil) (Ping timeout: 252 seconds) |
| 2021-07-09 04:45:28 +0200 | <glguy> | There's an example here where *parsing* fails because a name wasn't declared, but it think it's a lot nicer for the user if things like that don't break parsing. Once you've parsed the syntax you can then find all the problems at once and things like scope and typing, etc, don't have to be passing to know that the syntax is OK |
| 2021-07-09 04:46:04 +0200 | dragestil | (~quassel@user/dragestil) |
| 2021-07-09 04:46:24 +0200 | <pavonia> | safinaskar: Why is unbiased choice better than biased choice? |
| 2021-07-09 04:46:45 +0200 | <Axman6> | yeah I would have thought that often you know which bias you want |
| 2021-07-09 04:47:12 +0200 | <c_wraith> | Nah, biased choice without backtracking is terrible. You constantly have to refactor your grammar around the parser limitations |
| 2021-07-09 04:47:42 +0200 | <glguy> | I generally find it's a liability when you start computing inside your parser, which is a problem with most examples of parser-combinators uses |
| 2021-07-09 04:47:58 +0200 | <glguy> | the grammar gets lost in the midst of the computation |
| 2021-07-09 04:48:04 +0200 | <Axman6> | safinaskar: Good news, the haddocks have appeared on hackage :) |
| 2021-07-09 04:49:13 +0200 | <glguy> | Unbiased choice parsing was handy on this year's Advent of Code; it saved me from having to think too hard when going for quick completion |
| 2021-07-09 04:54:14 +0200 | <qrpnxz> | > • Could not deduce: ((n1 + m) + 1) ~ (n + m) |
| 2021-07-09 04:54:14 +0200 | <qrpnxz> | > from the context: n ~ (n1 + 1) |
| 2021-07-09 04:54:15 +0200 | <qrpnxz> | rip |
| 2021-07-09 04:54:15 +0200 | <lambdabot> | <hint>:1:1: error: parse error on input ‘•’ |
| 2021-07-09 04:54:15 +0200 | <lambdabot> | error: |
| 2021-07-09 04:54:15 +0200 | <lambdabot> | Pattern syntax in expression context: ~(n1 + 1) |
| 2021-07-09 04:55:11 +0200 | bitmapper | (uid464869@id-464869.tooting.irccloud.com) |
| 2021-07-09 04:55:40 +0200 | <Axman6> | yeah you need to be quite careful about how you structure types with nats, sometimes just changing the order of the arguments can help. I think there are also GHC plugins which can resolve things which are obviously true |
| 2021-07-09 04:56:07 +0200 | cmburnett | (~cmburnett@c-73-37-184-238.hsd1.mn.comcast.net) |
| 2021-07-09 04:56:49 +0200 | cmburnett | (~cmburnett@c-73-37-184-238.hsd1.mn.comcast.net) () |
| 2021-07-09 04:57:20 +0200 | <safinaskar> | glguy: "happy has no trouble being used with tokens that have line and also column information" - yes, but then you have to manually combine this location information. For example, using (<-->) from srcloc. And you should do this in every happy production. My library does this automatically |
| 2021-07-09 04:58:47 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 05:00:03 +0200 | <safinaskar> | glguy: "but it think it's a lot nicer for the user if things like that don't break parsing" - fully agree. My library (thanks to power of arrows) allow you to check you for parsing errors and then (if there is no parsing errors) check semantic errors. In other words parsing code is mixed/ |
| 2021-07-09 05:00:54 +0200 | <safinaskar> | glguy: in other words, parsing code is mixed/interleaved, but thanks to arrow power, when you actually run parser (in "main") you check for parsing errors and then other errors!!! |
| 2021-07-09 05:01:58 +0200 | <Axman6> | trifecta adds location information by default right? |
| 2021-07-09 05:03:29 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 255 seconds) |
| 2021-07-09 05:05:25 +0200 | andreabedini | (~andreabed@8s8kj6nl13s474s8p7bh.ip6.superloop.com) |
| 2021-07-09 05:06:11 +0200 | <glguy> | putting code into the parser isn't great, but that's nice that it helps with locations |
| 2021-07-09 05:08:15 +0200 | <safinaskar> | pavonia: "Why is unbiased choice better than biased choice?" - because unbiased choice captures my parsing intuition. And I think it captures parsing intuition of everybody else. I once had one tragedy: I created grammar for my language. In my head this grammar used unbiased choice, i. e. in my mental map the choice was unbiased. Then I converted this my mental map to code. To parsec code. Which uses |
| 2021-07-09 05:08:21 +0200 | <safinaskar> | biased choice. The code worked. I wrote lot of code in this my new language. But then I discovered that original grammar (with unbiased choice) was ambiguous! But when I converted it to parsec code, the ambiguity vanished! So, the actual parser simply stick to particular choices, and I don't know to which! So all code in this my new language was possibly ambiguous! |
| 2021-07-09 05:08:21 +0200 | mei | (~mei@user/mei) (Ping timeout: 252 seconds) |
| 2021-07-09 05:09:51 +0200 | <safinaskar> | pavonia: well, again: i think biased is counter-intuitive. Also, definitions of many languages use unbiased choice |
| 2021-07-09 05:10:09 +0200 | dragestil | (~quassel@user/dragestil) (Read error: Connection reset by peer) |
| 2021-07-09 05:11:09 +0200 | mei | (~mei@user/mei) |
| 2021-07-09 05:15:09 +0200 | P1RATEZ | (piratez@user/p1ratez) (Remote host closed the connection) |
| 2021-07-09 05:18:23 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 05:32:53 +0200 | <qrpnxz> | i found out how to do existential with data by the way :) |
| 2021-07-09 05:34:33 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 05:34:51 +0200 | <qrpnxz> | this is epic |
| 2021-07-09 05:35:40 +0200 | <lechner> | Hi, are emails for hackage account registration sent with a delay? |
| 2021-07-09 05:36:02 +0200 | <Axman6> | I believe they have to be actioned by a human |
| 2021-07-09 05:36:05 +0200 | <safinaskar> | qrpnxz: how? |
| 2021-07-09 05:36:22 +0200 | <lechner> | Axman6: ah, no rush. thanks! |
| 2021-07-09 05:36:33 +0200 | luna_ | (~luna@124.205.197.98) |
| 2021-07-09 05:37:43 +0200 | <qrpnxz> | you can make something like `data SomeFoldable = forall a. Foldable f => SomeFoldable (f a)`, then you can do `deriving instance Foldable SomeFoldable`, and whatever you wrap will act like a dynamic interface type |
| 2021-07-09 05:37:45 +0200 | <qrpnxz> | it's pretty nice |
| 2021-07-09 05:39:02 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Ping timeout: 252 seconds) |
| 2021-07-09 05:39:12 +0200 | <glguy> | Do you mean: data SomeFoldable a = ... ? |
| 2021-07-09 05:39:19 +0200 | <qrpnxz> | yeah oops |
| 2021-07-09 05:41:08 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 272 seconds) |
| 2021-07-09 05:41:37 +0200 | <qrpnxz> | for that you need DeriveFoldable, StandaloneDeriving, and ExistentialQuantification by the way |
| 2021-07-09 05:43:49 +0200 | <qrpnxz> | i wish it would just do all that for you, but oh well |
| 2021-07-09 05:44:57 +0200 | <glguy> | What're you doing that you needed that? |
| 2021-07-09 05:46:07 +0200 | <qrpnxz> | you can use this to return an interface on a function |
| 2021-07-09 05:48:07 +0200 | <monochrom> | I'm pretty sure even "data SomeFoldable a = forall a. Foldable f => SomeFoldable (f a)" is not the real code. |
| 2021-07-09 05:48:19 +0200 | <qrpnxz> | it is, it compiles |
| 2021-07-09 05:48:19 +0200 | <monochrom> | For starters, free variable f. |
| 2021-07-09 05:48:27 +0200 | <qrpnxz> | oh, i meant forall f |
| 2021-07-09 05:48:28 +0200 | <qrpnxz> | ofc |
| 2021-07-09 05:50:54 +0200 | <c_wraith> | I thought you were concerned with preventing fusion |
| 2021-07-09 05:51:31 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 05:52:27 +0200 | bontaq | (~user@ool-18e47f8d.dyn.optonline.net) |
| 2021-07-09 05:52:30 +0200 | <qrpnxz> | I'm just saying I found how to do it |
| 2021-07-09 05:53:20 +0200 | <qrpnxz> | thx for bringing that up though, would be good to bench it |
| 2021-07-09 05:58:00 +0200 | <safinaskar> | qrpnxz: please write correct code. "f" is free |
| 2021-07-09 05:58:13 +0200 | oxide | (~lambda@user/oxide) |
| 2021-07-09 05:58:34 +0200 | <qrpnxz> | already brought up, here is the corrected version `data SomeFoldable a = forall f. Foldable f => SomeFoldable (f a)` |
| 2021-07-09 06:00:01 +0200 | <safinaskar> | qrpnxz: thanks |
| 2021-07-09 06:01:00 +0200 | <safinaskar> | qrpnxz: so, SomeFoldable itself can be passed as "f", right? is this intentional? |
| 2021-07-09 06:01:18 +0200 | <qrpnxz> | idk what you mean by passed as f |
| 2021-07-09 06:02:42 +0200 | <qrpnxz> | c_wraith, seems to fuse fine. I think where you get in trouble is if you accept SomeFoldable for your function, but if you just return, the real type should always be known, and ghc can optimize for that. (And accepting SomeFoldable should never happen; should be using constraint there). |
| 2021-07-09 06:05:52 +0200 | <safinaskar> | qrpnxz: i mean that SomeFoldable can be f. i. e. you can substitute SomeFoldable as f |
| 2021-07-09 06:06:33 +0200 | <qrpnxz> | Eh, yes. |
| 2021-07-09 06:06:57 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-07-09 06:07:16 +0200 | <safinaskar> | qrpnxz: is this intentional? i. e. i need this fact to understand this code? |
| 2021-07-09 06:07:25 +0200 | <Axman6> | feels related to Yoneda |
| 2021-07-09 06:08:52 +0200 | <qrpnxz> | safinaskar: It is intentional that SomeFoldable is a foldable if that's what you're asking. |
| 2021-07-09 06:09:27 +0200 | <c_wraith> | Axman6: it's just the existential typeclass antipattern |
| 2021-07-09 06:10:16 +0200 | <Axman6> | @hoogle Yoneda |
| 2021-07-09 06:10:16 +0200 | <lambdabot> | module Data.Profunctor.Yoneda |
| 2021-07-09 06:10:16 +0200 | <lambdabot> | Data.Profunctor.Yoneda newtype Yoneda p a b |
| 2021-07-09 06:10:16 +0200 | <lambdabot> | Data.Profunctor.Yoneda Yoneda :: (forall x y . (x -> a) -> (b -> y) -> p x y) -> Yoneda p a b |
| 2021-07-09 06:11:41 +0200 | <Axman6> | that was not useful |
| 2021-07-09 06:12:51 +0200 | Megant | (megant@user/megant) (Read error: Connection reset by peer) |
| 2021-07-09 06:13:32 +0200 | <c_wraith> | Yoneda does something different - it captures the functionality of a class, but it doesn't wrap an unknown instance |
| 2021-07-09 06:13:45 +0200 | <c_wraith> | wait, no, I'm thinking Coyoneda |
| 2021-07-09 06:14:39 +0200 | Axman6 | muses that we need a Yoyoneda, which caputres the idea of traversing down into a structure and back up, and down again... |
| 2021-07-09 06:16:43 +0200 | luna_ | (~luna@124.205.197.98) (Remote host closed the connection) |
| 2021-07-09 06:18:27 +0200 | <qrpnxz> | c_wraith, Why do you say it is an antipattern |
| 2021-07-09 06:18:49 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-07-09 06:19:47 +0200 | <c_wraith> | because hiding types like that basically always gets in the way of good code in Haskell |
| 2021-07-09 06:20:34 +0200 | <qrpnxz> | ok how |
| 2021-07-09 06:21:47 +0200 | hexfive | (~eric@50.35.83.177) |
| 2021-07-09 06:25:00 +0200 | safinaskar | (~user@109-252-90-89.nat.spd-mgts.ru) () |
| 2021-07-09 06:25:31 +0200 | <qrpnxz> | i could instead return like `(a -> b -> b) -> b -> b` which would be a completely explicit type, yet reveal no new information. Because functions are abstractions, and this is also an abstraction, except it's much nicer to use imo |
| 2021-07-09 06:25:50 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-09 06:29:28 +0200 | hexfive | (~eric@50.35.83.177) (Quit: WeeChat 3.0) |
| 2021-07-09 06:32:19 +0200 | luna_ | (~luna2021@124.205.197.98) |
| 2021-07-09 06:32:42 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-09 06:35:46 +0200 | derelict | (~derelict@user/derelict) (Ping timeout: 240 seconds) |
| 2021-07-09 06:38:25 +0200 | <nshepperd> | you could also just return whatever the underlying foldable is, instead of being paternalistic toward your user |
| 2021-07-09 06:38:49 +0200 | <c_wraith> | basically, users always want to do things you haven't imagined |
| 2021-07-09 06:38:58 +0200 | <qrpnxz> | but then changing it is a breaking change, it has nothing to do with paternalism |
| 2021-07-09 06:39:09 +0200 | <c_wraith> | breaking changes are fine, as long as they break compilation |
| 2021-07-09 06:41:14 +0200 | <qrpnxz> | well not really, because that change might've "taken away" features, features that i never intended to guarantee. It would not be an easy fix for you if my overkill type that i used is suddenly a very dumb type |
| 2021-07-09 06:42:08 +0200 | <c_wraith> | you keep imagining that you know every valid use case |
| 2021-07-09 06:42:24 +0200 | <c_wraith> | I assure you, users have weird ideas. :) |
| 2021-07-09 06:42:32 +0200 | luna_ | (~luna2021@124.205.197.98) (Remote host closed the connection) |
| 2021-07-09 06:42:38 +0200 | <nshepperd> | if you never intended to guarantee it but it's useful then that's good, value was created |
| 2021-07-09 06:43:00 +0200 | dragestil | (~quassel@user/dragestil) |
| 2021-07-09 06:43:19 +0200 | dragestil | (~quassel@user/dragestil) (Client Quit) |
| 2021-07-09 06:43:54 +0200 | dragestil | (~quassel@user/dragestil) |
| 2021-07-09 06:44:34 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 240 seconds) |
| 2021-07-09 06:49:32 +0200 | luna_ | (~luna2021@124.205.197.98) |
| 2021-07-09 06:50:45 +0200 | <nshepperd> | you can just document what you guarantee in your haddock comments. this makes any usage outside that guarantee the user's responsibility, and freedom |
| 2021-07-09 06:51:01 +0200 | <qrpnxz> | More is not always good. Encapsulation is good. It would also allow one to return a different foldable based on the inputs. |
| 2021-07-09 06:51:38 +0200 | <c_wraith> | That sounds like a terrible thing to do |
| 2021-07-09 06:52:01 +0200 | Megant | (~kaitsu@user/megant) |
| 2021-07-09 06:53:00 +0200 | <nshepperd> | The paternalism is that you are trying to protect the user from this responsibility |
| 2021-07-09 06:53:30 +0200 | <sm> | sounds like php/perl/lisp-type coding. I will admit, those rich do-everything functions can seem handy at times. |
| 2021-07-09 06:53:41 +0200 | <sm> | in those languages |
| 2021-07-09 06:54:16 +0200 | <sm> | nothing illegal about it in haskell either, if it's documented with types.. |
| 2021-07-09 06:54:23 +0200 | luna_ | (~luna2021@124.205.197.98) (Ping timeout: 252 seconds) |
| 2021-07-09 06:54:26 +0200 | <qrpnxz> | like in some function I could do if you gave me a set maybe i use that directly and then return a set too, otherwise i do an ordered list. |
| 2021-07-09 06:55:24 +0200 | hexreel | (~hr@69.233.98.238) (WeeChat 3.2) |
| 2021-07-09 07:01:58 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 07:03:03 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 07:03:14 +0200 | <qrpnxz> | i agree with my arguments, and yet i would like to return a concrete type too. At least for this function I'm currently writing, but I still think this is a legitimate feature. |
| 2021-07-09 07:04:39 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 07:09:09 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-09 07:09:26 +0200 | edwtjo | (~edwtjo@user/edwtjo) (Ping timeout: 258 seconds) |
| 2021-07-09 07:17:33 +0200 | <sm> | are we talking about a Monoid a => m a -> m a function ? |
| 2021-07-09 07:18:37 +0200 | <qrpnxz> | eh, no. idk where you got that |
| 2021-07-09 07:19:03 +0200 | <sm> | "some function I could do if you gave me a set maybe i use that directly and then return a set too, otherwise i do an ordered list" |
| 2021-07-09 07:19:29 +0200 | <sm> | I may not have understood you, no worries |
| 2021-07-09 07:20:05 +0200 | <qrpnxz> | well we were using foldable as an example, idk if set has monoid ig it does. |
| 2021-07-09 07:20:23 +0200 | <qrpnxz> | but sure you could say something similar but with monoid instead |
| 2021-07-09 07:20:41 +0200 | <sm> | I was just trying to think what's the haskell way of saying "some collection of things" |
| 2021-07-09 07:21:10 +0200 | <sm> | it sounded like you wanted to make a function polymorphic in the collection type. But I've just jumped in at the end of your discussion. |
| 2021-07-09 07:22:30 +0200 | <sm> | (afk) |
| 2021-07-09 07:22:45 +0200 | <qrpnxz> | ah well we are talking about function that returns an interface rather than a concrete type. For accepting any foldable, you use forall, but to return any generic (specific) foldable, you use existential. |
| 2021-07-09 07:23:54 +0200 | edwtjo | (~edwtjo@h-109-228-137-133.A213.priv.bahnhof.se) |
| 2021-07-09 07:23:54 +0200 | edwtjo | (~edwtjo@h-109-228-137-133.A213.priv.bahnhof.se) (Changing host) |
| 2021-07-09 07:23:54 +0200 | edwtjo | (~edwtjo@user/edwtjo) |
| 2021-07-09 07:24:00 +0200 | <qrpnxz> | ok i have to go to bed now gn |
| 2021-07-09 07:24:20 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) |
| 2021-07-09 07:29:21 +0200 | luna_ | (~luna2021@124.205.197.98) |
| 2021-07-09 07:29:21 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Quit: Leaving) |
| 2021-07-09 07:29:21 +0200 | oxide | (~lambda@user/oxide) (Ping timeout: 272 seconds) |
| 2021-07-09 07:29:22 +0200 | tabemann_ | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) |
| 2021-07-09 07:30:41 +0200 | oxide | (~lambda@user/oxide) |
| 2021-07-09 07:31:01 +0200 | scrazen | (~scrazen@user/scrazen) (Remote host closed the connection) |
| 2021-07-09 07:31:20 +0200 | tabemann | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2021-07-09 07:31:20 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 272 seconds) |
| 2021-07-09 07:31:29 +0200 | scrazen | (~scrazen@user/scrazen) |
| 2021-07-09 07:31:57 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2021-07-09 07:41:30 +0200 | ptr_frac7al | (~longlong@user/ptr-frac7al/x-0038398) (Quit: ptr_frac7al) |
| 2021-07-09 07:44:59 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-07-09 07:49:56 +0200 | Megant | (~kaitsu@user/megant) (Ping timeout: 252 seconds) |
| 2021-07-09 07:50:44 +0200 | gioyik | (~gioyik@gateway/tor-sasl/gioyik) (Quit: WeeChat 3.1) |
| 2021-07-09 07:51:21 +0200 | ishutin | (~ishutin@79.120.162.129) |
| 2021-07-09 08:05:46 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds) |
| 2021-07-09 08:11:23 +0200 | tabemann_ | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) (Remote host closed the connection) |
| 2021-07-09 08:11:29 +0200 | tabemann_ | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) |
| 2021-07-09 08:12:14 +0200 | artagnon | (sid7560@id-7560.tooting.irccloud.com) |
| 2021-07-09 08:12:34 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2021-07-09 08:14:13 +0200 | Cale | (~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com) (Ping timeout: 258 seconds) |
| 2021-07-09 08:14:48 +0200 | Cale | (~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com) |
| 2021-07-09 08:15:49 +0200 | chele | (~chele@user/chele) |
| 2021-07-09 08:18:51 +0200 | jneira | (~jneira@212.8.115.226) |
| 2021-07-09 08:18:53 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-09 08:20:09 +0200 | turlando | (~turlando@user/turlando) |
| 2021-07-09 08:22:00 +0200 | jespada | (~jespada@90.254.247.46) (Ping timeout: 268 seconds) |
| 2021-07-09 08:22:03 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 08:22:33 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 08:25:04 +0200 | xerxes | (~xerxes@117.222.64.149) |
| 2021-07-09 08:25:07 +0200 | jespada | (~jespada@90.254.247.46) |
| 2021-07-09 08:27:47 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 255 seconds) |
| 2021-07-09 08:28:31 +0200 | Megant | (megant@user/megant) |
| 2021-07-09 08:28:34 +0200 | kenran | (~kenran@b2b-37-24-119-190.unitymedia.biz) |
| 2021-07-09 08:29:05 +0200 | acidjnk | (~acidjnk@p200300d0c72b9563509afe7c5cdd8ef5.dip0.t-ipconnect.de) |
| 2021-07-09 08:29:15 +0200 | awth13 | (~user@user/awth13) (Remote host closed the connection) |
| 2021-07-09 08:29:36 +0200 | awth13 | (~user@user/awth13) |
| 2021-07-09 08:34:51 +0200 | neurocyte40 | (~neurocyte@user/neurocyte) (Quit: The Lounge - https://thelounge.chat) |
| 2021-07-09 08:39:38 +0200 | neurocyte404 | (~neurocyte@46.243.81.30) |
| 2021-07-09 08:39:38 +0200 | neurocyte404 | (~neurocyte@46.243.81.30) (Changing host) |
| 2021-07-09 08:39:38 +0200 | neurocyte404 | (~neurocyte@user/neurocyte) |
| 2021-07-09 08:44:30 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) |
| 2021-07-09 08:45:40 +0200 | bOy_isOg | (~bOy_isOg@119.93.22.3) |
| 2021-07-09 08:46:30 +0200 | bOy_isOg | (~bOy_isOg@119.93.22.3) () |
| 2021-07-09 08:49:34 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-09 08:51:06 +0200 | polux | (~polux@51.15.169.172) (Quit: The Lounge - https://thelounge.github.io) |
| 2021-07-09 08:51:23 +0200 | polux | (~polux@51.15.169.172) |
| 2021-07-09 08:52:44 +0200 | fendor | (~fendor@77.119.197.100.wireless.dyn.drei.com) |
| 2021-07-09 08:52:51 +0200 | anandprabhu | (~anandprab@94.202.243.198) |
| 2021-07-09 08:54:20 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 08:55:01 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 08:55:58 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds) |
| 2021-07-09 08:56:55 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-07-09 08:58:58 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Ping timeout: 240 seconds) |
| 2021-07-09 09:00:11 +0200 | flipchan | (~yumman@user/flipchan) (Ping timeout: 255 seconds) |
| 2021-07-09 09:00:33 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 09:05:08 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 255 seconds) |
| 2021-07-09 09:10:23 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) |
| 2021-07-09 09:18:56 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) |
| 2021-07-09 09:22:55 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2021-07-09 09:23:29 +0200 | nerdypepper | (~nerdypepp@user/nerdypepper) (Remote host closed the connection) |
| 2021-07-09 09:24:00 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-07-09 09:24:58 +0200 | thiross | (~thiross@39.170.37.82) |
| 2021-07-09 09:25:51 +0200 | thiross | (~thiross@39.170.37.82) (Remote host closed the connection) |
| 2021-07-09 09:26:42 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:156a:d066:25bb:13b1) |
| 2021-07-09 09:27:38 +0200 | rhett | (Username@174-126-122-77.cpe.sparklight.net) |
| 2021-07-09 09:27:53 +0200 | rhett | (Username@174-126-122-77.cpe.sparklight.net) (Excess Flood) |
| 2021-07-09 09:28:10 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-09 09:31:05 +0200 | zaquest | (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-07-09 09:32:15 +0200 | zaquest | (~notzaques@5.128.210.178) |
| 2021-07-09 09:33:38 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-09 09:34:20 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-07-09 09:35:49 +0200 | nerdypepper | (~nerdypepp@user/nerdypepper) |
| 2021-07-09 09:36:09 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 09:39:43 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) (Ping timeout: 246 seconds) |
| 2021-07-09 09:40:41 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Ping timeout: 255 seconds) |
| 2021-07-09 09:41:20 +0200 | azeem | (~azeem@176.201.41.131) |
| 2021-07-09 09:43:50 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-09 09:45:59 +0200 | azeem | (~azeem@176.201.41.131) (Ping timeout: 252 seconds) |
| 2021-07-09 09:46:54 +0200 | azeem | (~azeem@176.201.41.131) |
| 2021-07-09 09:49:41 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2021-07-09 09:51:08 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) |
| 2021-07-09 09:51:50 +0200 | opqdonut_ | (opqdonut@pseudo.fixme.fi) (Ping timeout: 265 seconds) |
| 2021-07-09 09:52:14 +0200 | opqdonut | (opqdonut@pseudo.fixme.fi) |
| 2021-07-09 09:54:10 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 09:58:56 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-09 10:00:47 +0200 | thiross | (~thiross@39.170.37.82) |
| 2021-07-09 10:01:03 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2021-07-09 10:02:02 +0200 | thiross | (~thiross@39.170.37.82) (Client Quit) |
| 2021-07-09 10:06:33 +0200 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-07-09 10:07:00 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Ping timeout: 252 seconds) |
| 2021-07-09 10:09:38 +0200 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 244 seconds) |
| 2021-07-09 10:12:08 +0200 | zeenk | (~zeenk@2a02:2f04:a106:9600:82fb:aed9:ca9:38d3) |
| 2021-07-09 10:17:22 +0200 | azeem | (~azeem@176.201.41.131) (Ping timeout: 240 seconds) |
| 2021-07-09 10:17:55 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2021-07-09 10:17:57 +0200 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2021-07-09 10:18:10 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-07-09 10:18:13 +0200 | azeem | (~azeem@176.201.41.131) |
| 2021-07-09 10:19:22 +0200 | ray | (~ray@user/re) (Ping timeout: 240 seconds) |
| 2021-07-09 10:19:33 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2021-07-09 10:22:04 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-07-09 10:22:58 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2021-07-09 10:23:17 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2021-07-09 10:23:45 +0200 | xerxes | (~xerxes@117.222.64.149) (Quit: leaving) |
| 2021-07-09 10:29:10 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-09 10:33:06 +0200 | turlando | (~turlando@user/turlando) (Ping timeout: 272 seconds) |
| 2021-07-09 10:33:22 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2021-07-09 10:38:07 +0200 | jay-invariant | (~jay@c-24-4-6-169.hsd1.ca.comcast.net) (Remote host closed the connection) |
| 2021-07-09 10:38:07 +0200 | Gurkenglas_ | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-07-09 10:38:07 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) |
| 2021-07-09 10:38:07 +0200 | jay-invariant | (~jay@c-24-4-6-169.hsd1.ca.comcast.net) |
| 2021-07-09 10:39:57 +0200 | gehmehgeh_ | (~user@user/gehmehgeh) |
| 2021-07-09 10:40:04 +0200 | Gurkenglas | (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) (Ping timeout: 272 seconds) |
| 2021-07-09 10:41:09 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 244 seconds) |
| 2021-07-09 10:43:41 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-09 10:48:28 +0200 | azeem | (~azeem@176.201.41.131) (Read error: Connection reset by peer) |
| 2021-07-09 10:50:03 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) |
| 2021-07-09 10:51:24 +0200 | michalz | (~michalz@185.246.204.61) |
| 2021-07-09 10:55:42 +0200 | viluon | (uid453725@id-453725.brockwell.irccloud.com) |
| 2021-07-09 10:56:16 +0200 | nsilv | (~nsilv@212.103.198.210) |
| 2021-07-09 10:59:51 +0200 | Teacup_ | (~teacup@user/teacup) |
| 2021-07-09 11:00:29 +0200 | Teacup | (~teacup@user/teacup) (Ping timeout: 268 seconds) |
| 2021-07-09 11:02:35 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 255 seconds) |
| 2021-07-09 11:03:46 +0200 | pjb | (~pjb@user/pjb) (Read error: Connection reset by peer) |
| 2021-07-09 11:08:15 +0200 | <tomsmeding> | Does anyone happen to know a class of numerical two-argument functions that 1. are associative, and 2. can be randomly generated? |
| 2021-07-09 11:09:06 +0200 | trattue | (~trattue@152.70.182.158) |
| 2021-07-09 11:09:08 +0200 | <tomsmeding> | I want to quickcheck a thing that requires a (numerically) differentiable function (a -> a -> a) that is also associative (f(f(x,y),z) == f(x,f(y,z))) |
| 2021-07-09 11:09:27 +0200 | ray | (~ray@user/re) |
| 2021-07-09 11:09:53 +0200 | <tomsmeding> | '\x y -> b*x*y + u*x + v*y' is associative for all b and with u in {0,1}, but is there perhaps a larger set? |
| 2021-07-09 11:10:06 +0200 | <tomsmeding> | (correction, u and v in {0,1}) |
| 2021-07-09 11:12:45 +0200 | <tomsmeding> | (correction, u=v=0 or u=v=1 :p) |
| 2021-07-09 11:13:11 +0200 | haykam2 | (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-09 11:13:24 +0200 | haykam3 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-09 11:14:54 +0200 | acid | (~acid@user/acid) (Ping timeout: 272 seconds) |
| 2021-07-09 11:16:56 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-09 11:17:00 +0200 | acid | (~acid@user/acid) |
| 2021-07-09 11:17:30 +0200 | MoC | (~moc@user/moc) |
| 2021-07-09 11:19:56 +0200 | <viluon> | surely `\x y -> 3` is also associative? |
| 2021-07-09 11:21:13 +0200 | <tomsmeding> | ah, true! |
| 2021-07-09 11:21:48 +0200 | <tomsmeding> | maybe this class of things, together with matrix multiplication, is already diverse enough to get some confidence that my function is correct :p |
| 2021-07-09 11:21:56 +0200 | <viluon> | could you perhaps arrive at the entire set compositionally? |
| 2021-07-09 11:22:14 +0200 | <tomsmeding> | that's what I would be interested in |
| 2021-07-09 11:23:38 +0200 | <viluon> | all constant functions are differentiable & associative (so they're in let's say S), multiplications of an f ∈ S by a scalar (αf) are also in S, their additions are also in S, as are their multiplications, where you define + and * on these functions as f + g = \x y -> f x y + g x y (analogically for *) |
| 2021-07-09 11:23:57 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Remote host closed the connection) |
| 2021-07-09 11:24:30 +0200 | <viluon> | I mean, hopefully right? make sure such + and * makes sense esp. w.r.t. differentiation |
| 2021-07-09 11:24:49 +0200 | <tomsmeding> | yeah don't worry about the differentiation :p |
| 2021-07-09 11:25:31 +0200 | <viluon> | but that's still all just constant functions if you look closely |
| 2021-07-09 11:25:46 +0200 | <tomsmeding> | yeah |
| 2021-07-09 11:25:47 +0200 | <viluon> | there's no use of the arguments in the leaves of functions defined as such |
| 2021-07-09 11:26:03 +0200 | <tomsmeding> | \x y -> x + y ought to be in S, but \x y -> (x + y) * (x + y) is definitely not in S |
| 2021-07-09 11:26:18 +0200 | <viluon> | it'd be great if there were an identity function, but I'm not sure how to do that with two arguments |
| 2021-07-09 11:26:34 +0200 | <tomsmeding> | well \x _ -> x and \_ y -> y are also in S |
| 2021-07-09 11:27:10 +0200 | <viluon> | yeah true that, you have the projections |
| 2021-07-09 11:28:01 +0200 | <viluon> | it's really the set of ℝ × ℝ → ℝ, for some definition of ℝ, I don't think you get much from partial application here |
| 2021-07-09 11:28:19 +0200 | <viluon> | (the subset of*) |
| 2021-07-09 11:28:27 +0200 | <viluon> | (a subset of*) |
| 2021-07-09 11:28:38 +0200 | <tomsmeding> | problem is that S is not at all closed under + or * |
| 2021-07-09 11:29:01 +0200 | <viluon> | hmm |
| 2021-07-09 11:30:43 +0200 | kenran | (~kenran@b2b-37-24-119-190.unitymedia.biz) (Quit: WeeChat info:version) |
| 2021-07-09 11:42:10 +0200 | neceve | (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) |
| 2021-07-09 11:44:07 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-99a5-f36d-ee14-d92.fixed6.kpn.net) |
| 2021-07-09 11:44:36 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) |
| 2021-07-09 11:48:29 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) (Ping timeout: 255 seconds) |
| 2021-07-09 11:49:42 +0200 | trattue | (~trattue@152.70.182.158) (Remote host closed the connection) |
| 2021-07-09 11:51:18 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-07-09 11:51:30 +0200 | Trattue | (~Trattue@152.70.182.158) |
| 2021-07-09 11:59:07 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-07-09 11:59:37 +0200 | <viluon> | what are the desired properties for + and * on functions? |
| 2021-07-09 12:00:13 +0200 | <tomsmeding> | I'm not even sure I need the set to be closed under particular operations specifically |
| 2021-07-09 12:00:35 +0200 | <tomsmeding> | I just want a large set of functions, parametrised in some way that I can randomly generate them, that are all associative |
| 2021-07-09 12:01:21 +0200 | <viluon> | btw here's a notion of function composition that works, but isn't very revealing `f . g = \ x y -> let z = g x y in f z z` |
| 2021-07-09 12:01:23 +0200 | <tomsmeding> | but (\x y -> f x y) + (\a b -> g a b) can only really mean \x y -> f x y + g x y |
| 2021-07-09 12:01:46 +0200 | <viluon> | I'm struggling to find the "point" at which the associativity is lost |
| 2021-07-09 12:01:54 +0200 | <tomsmeding> | :D |
| 2021-07-09 12:02:18 +0200 | <tomsmeding> | that function composition also doesn't preserve associativity I believe |
| 2021-07-09 12:02:19 +0200 | fef | (~thedawn@user/thedawn) |
| 2021-07-09 12:05:15 +0200 | Trattue | (~Trattue@152.70.182.158) (Quit: bye) |
| 2021-07-09 12:05:30 +0200 | Trattue | (~Trattue@152.70.182.158) |
| 2021-07-09 12:08:07 +0200 | <viluon> | ah, you may be right! |
| 2021-07-09 12:08:21 +0200 | <viluon> | it's associative if `g (let q = g x y in f q q) z ≟ g x (let q = g y z in f q q)` |
| 2021-07-09 12:10:30 +0200 | <tomsmeding> | not associative for f = g = (+) :p |
| 2021-07-09 12:10:40 +0200 | <tomsmeding> | because \x y -> 2 * x * y is not associative |
| 2021-07-09 12:10:54 +0200 | <tomsmeding> | uh correction, \x y -> 2 * (x + y) |
| 2021-07-09 12:11:13 +0200 | wqsz7xn | (~wqsz7xn@202.36.244.28) |
| 2021-07-09 12:11:42 +0200 | <tomsmeding> | I feel like the only things that really compose here are \x _ -> x and \_ y -> y |
| 2021-07-09 12:13:24 +0200 | <viluon> | associativity is way more elusive than I thought |
| 2021-07-09 12:14:18 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-07-09 12:14:29 +0200 | <viluon> | hmm, *just* multiplication or *just* addition would work though, wouldn't it? |
| 2021-07-09 12:14:36 +0200 | <viluon> | that'd give you a group, right? |
| 2021-07-09 12:14:38 +0200 | <tomsmeding> | yes, also c*x*y |
| 2021-07-09 12:14:47 +0200 | <tomsmeding> | would it? |
| 2021-07-09 12:14:59 +0200 | <viluon> | oh, group has inverses |
| 2021-07-09 12:15:09 +0200 | <tomsmeding> | monoid rather |
| 2021-07-09 12:15:20 +0200 | <viluon> | semigroup? |
| 2021-07-09 12:15:28 +0200 | <viluon> | associative binary operation |
| 2021-07-09 12:15:53 +0200 | <viluon> | oh monoid is a semigroup plus identity, fair enough |
| 2021-07-09 12:17:12 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) (Quit: Client closed) |
| 2021-07-09 12:17:29 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) |
| 2021-07-09 12:18:32 +0200 | <viluon> | so it's the interactions between + and * that screw it up |
| 2021-07-09 12:18:46 +0200 | <tomsmeding> | yeah |
| 2021-07-09 12:24:26 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) |
| 2021-07-09 12:26:28 +0200 | <viluon> | tomsmeding: I think you can get quite far with just the two separate monoids, plus multiplication by a scalar on each (although that has to be on the "top-level" I believe, without further composition via + or *). There may be functions that mix + and * in other ways that this doesn't cover, but I don't know how to find them :/ |
| 2021-07-09 12:28:54 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Ping timeout: 252 seconds) |
| 2021-07-09 12:29:22 +0200 | nsilv | (~nsilv@212.103.198.210) (Quit: WeeChat 3.0.1) |
| 2021-07-09 12:34:56 +0200 | luna_ | (~luna2021@124.205.197.98) (Remote host closed the connection) |
| 2021-07-09 12:39:08 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-07-09 12:39:47 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Ping timeout: 252 seconds) |
| 2021-07-09 12:45:02 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-09 12:54:23 +0200 | luna_ | (~luna2021@124.205.197.98) |
| 2021-07-09 12:54:50 +0200 | zcombinator | (~zcombinat@host-87-7-58-35.retail.telecomitalia.it) |
| 2021-07-09 12:56:21 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 12:56:53 +0200 | andreabedini | (~andreabed@8s8kj6nl13s474s8p7bh.ip6.superloop.com) (Ping timeout: 255 seconds) |
| 2021-07-09 12:57:11 +0200 | ray | (~ray@user/re) (Quit: WeeChat 3.2) |
| 2021-07-09 12:58:02 +0200 | s__ | (~s@50.34.81.185) |
| 2021-07-09 12:58:16 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) (Ping timeout: 258 seconds) |
| 2021-07-09 12:59:03 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) (Quit: Client closed) |
| 2021-07-09 12:59:14 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 12:59:15 +0200 | s_ | (~s@50.34.81.185) (Read error: Connection reset by peer) |
| 2021-07-09 12:59:21 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) |
| 2021-07-09 13:00:34 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 2021-07-09 13:02:19 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 13:03:00 +0200 | vpan | (~vilius@212.117.1.172) |
| 2021-07-09 13:03:34 +0200 | luna__ | (~luna2021@124.205.197.98) |
| 2021-07-09 13:06:18 +0200 | luna_ | (~luna2021@124.205.197.98) (Ping timeout: 252 seconds) |
| 2021-07-09 13:06:44 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-09 13:08:41 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-09 13:08:53 +0200 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2021-07-09 13:11:34 +0200 | luna__ | (~luna2021@124.205.197.98) () |
| 2021-07-09 13:12:46 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-99a5-f36d-ee14-d92.fixed6.kpn.net) (Remote host closed the connection) |
| 2021-07-09 13:13:02 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-e2b1-5b1f-ad9a-57c9.fixed6.kpn.net) |
| 2021-07-09 13:16:27 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-09 13:18:14 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) |
| 2021-07-09 13:22:09 +0200 | andreabedini | (~andreabed@8s8kj6n9tyzc511tnjb7.ip6.superloop.com) |
| 2021-07-09 13:22:10 +0200 | <dminuoso> | 11:08:15 tomsmeding | Does anyone happen to know a class of numerical two-argument functions that 1. are associative, and 2. can be randomly generated? |
| 2021-07-09 13:23:11 +0200 | <dminuoso> | Elliptic curves come to mind |
| 2021-07-09 13:23:43 +0200 | <dminuoso> | (e.g. elliptic curves over Galois fields) |
| 2021-07-09 13:23:58 +0200 | <dminuoso> | Or.. is that even associative I wonder? |
| 2021-07-09 13:25:38 +0200 | <tomsmeding> | "An elliptic curve is an abelian variety – that is, it has a group law defined algebraically, with respect to which it is an abelian group – and O99,99 serves as the identity element." |
| 2021-07-09 13:25:52 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) |
| 2021-07-09 13:26:04 +0200 | <tomsmeding> | dminuoso: sounds like it should be associative; but it's also commutative, right? |
| 2021-07-09 13:26:18 +0200 | <tomsmeding> | Suboptimal but quite interesting example |
| 2021-07-09 13:26:47 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Quit: FinnElija) |
| 2021-07-09 13:28:16 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 246 seconds) |
| 2021-07-09 13:28:30 +0200 | <tomsmeding> | Looks like you really need more than one-dimensional arguments to get interesting behaviour |
| 2021-07-09 13:28:51 +0200 | ishutin_ | (~ishutin@87-97-88-250.pool.digikabel.hu) |
| 2021-07-09 13:30:28 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-07-09 13:30:30 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Ping timeout: 252 seconds) |
| 2021-07-09 13:32:20 +0200 | ishutin | (~ishutin@79.120.162.129) (Ping timeout: 272 seconds) |
| 2021-07-09 13:33:08 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-09 13:34:52 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 2021-07-09 13:35:08 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.2) |
| 2021-07-09 13:35:19 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-07-09 13:37:34 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 13:40:03 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 13:42:03 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Ping timeout: 252 seconds) |
| 2021-07-09 13:45:38 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-09 13:46:35 +0200 | epolanski | (uid312403@id-312403.brockwell.irccloud.com) |
| 2021-07-09 13:58:05 +0200 | jippiedoe | (~david@2a02-a44c-e14e-1-e2b1-5b1f-ad9a-57c9.fixed6.kpn.net) (Ping timeout: 255 seconds) |
| 2021-07-09 13:59:04 +0200 | dunj3 | (~dunj3@2001:16b8:30aa:f100:5749:57d0:4660:97ec) |
| 2021-07-09 13:59:57 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b9550509afe7c5cdd8ef5.dip0.t-ipconnect.de) |
| 2021-07-09 14:00:23 +0200 | <AWizzArd> | dminuoso: have you implemented Single Sign-On? |
| 2021-07-09 14:01:30 +0200 | <dminuoso> | No. |
| 2021-07-09 14:03:02 +0200 | acidjnk | (~acidjnk@p200300d0c72b9563509afe7c5cdd8ef5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2021-07-09 14:03:23 +0200 | coeus | (~coeus@b2b-92-50-96-34.unitymedia.biz) |
| 2021-07-09 14:05:42 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 14:06:50 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 14:07:33 +0200 | <viluon> | hello, I have a question about generics-sop again. In pretty-sop's function `prettyValFor`, in the second equation, there's an auxiliary map for infix constructors (https://github.com/well-typed/pretty-sop/blob/master/src/Generics/SOP/PrettyVal.hs#L42-L45). It has the type `forall x y. NP (K Value) '[x, y] -> Value`, but is seemingly applied in a context where it is not known that `xs ~ '[x, y]`. How come this typechecks? |
| 2021-07-09 14:08:05 +0200 | phma | (phma@2001:5b0:211c:858:db7c:9aeb:2bd8:1b08) (Read error: Connection reset by peer) |
| 2021-07-09 14:08:25 +0200 | <viluon> | I thought the `xs ~ '[x, y]` equivalence came as a consequence of pattern-matching on the `Infix` constructor of `ConstructorInfo`, but `ConstructorInfo` is not a GADT |
| 2021-07-09 14:11:55 +0200 | fluffyballoon | (~fluffybal@199.204.58.62) (Ping timeout: 246 seconds) |
| 2021-07-09 14:12:51 +0200 | Pickchea | (~private@user/pickchea) |
| 2021-07-09 14:15:00 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2021-07-09 14:15:21 +0200 | anandprabhu | (~anandprab@94.202.243.198) (Quit: Leaving) |
| 2021-07-09 14:17:59 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) |
| 2021-07-09 14:23:11 +0200 | lortabac | (~lortabac@95.138.56.124) |
| 2021-07-09 14:24:45 +0200 | phma | (phma@2001:5b0:212a:c338:e904:270b:aa2b:a4ce) |
| 2021-07-09 14:31:03 +0200 | <kosmikus> | viluon: `ConstructorInfo` *is* a GADT. |
| 2021-07-09 14:31:18 +0200 | <kosmikus> | viluon: what makes you think otherwise? |
| 2021-07-09 14:31:40 +0200 | <viluon> | oh, am I confused? I'm probably confused https://hackage.haskell.org/package/generics-sop-0.5.1.1/docs/src/Generics.SOP.Type.Metadata.html#… |
| 2021-07-09 14:31:55 +0200 | <kosmikus> | ah |
| 2021-07-09 14:32:17 +0200 | <kosmikus> | that explains your confusion indeed |
| 2021-07-09 14:32:23 +0200 | <kosmikus> | the right definition is here: https://hackage.haskell.org/package/generics-sop-0.5.1.1/docs/src/Generics.SOP.Metadata.html#Const… |
| 2021-07-09 14:32:44 +0200 | <kosmikus> | generics-sop has two methods of providing metadata |
| 2021-07-09 14:32:53 +0200 | <kosmikus> | one is that metadata is a term-level structure |
| 2021-07-09 14:33:07 +0200 | <kosmikus> | the datatypes for this are defined in `Generics.SOP.Metadata` |
| 2021-07-09 14:33:15 +0200 | <kosmikus> | (and have the GADT) |
| 2021-07-09 14:33:24 +0200 | <viluon> | haha, that's mightily confusing. Thanks for clearing it up! |
| 2021-07-09 14:33:25 +0200 | <kosmikus> | this is what's being used by `pretty-sop`. |
| 2021-07-09 14:33:38 +0200 | <kosmikus> | the other is that the entire metadata can be lifted to the type-level. |
| 2021-07-09 14:33:48 +0200 | <kosmikus> | and that uses "simple" datatypes. |
| 2021-07-09 14:33:59 +0200 | <kosmikus> | primarily because there was a time when GADTs could not be promoted. |
| 2021-07-09 14:34:20 +0200 | <kosmikus> | this is no longer the case. it might be worth exploring whether the two could be unified better. |
| 2021-07-09 14:35:15 +0200 | <kosmikus> | but then again, even though GADTs can be lifted now, the type-level programming world is still different from the term-level programming world, so promoted GADTs don't quite behave as one might expect of GADTs. |
| 2021-07-09 14:35:35 +0200 | <Gurkenglas_> | Is there a language that compiles to python, has IDE support, and is more like Haskell? |
| 2021-07-09 14:35:39 +0200 | Gurkenglas_ | Gurkenglas |
| 2021-07-09 14:36:18 +0200 | <viluon> | Gurkenglas haven't tried, but I heard of https://github.com/evhub/coconut |
| 2021-07-09 14:36:30 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 14:36:36 +0200 | <darklambda> | how's coconut these days? |
| 2021-07-09 14:36:38 +0200 | <kosmikus> | Idris typically has backends for everything, but not necessarily backends of a very robust quality. |
| 2021-07-09 14:37:14 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 14:38:10 +0200 | <viluon> | if I had a nickel every time I'm confused about something that would be cleared up by jump-to-definition, I would have at least one nickel today |
| 2021-07-09 14:38:33 +0200 | <viluon> | HLS is wonderful but I wish it could jump to hackage sources as well |
| 2021-07-09 14:39:07 +0200 | <kosmikus> | perhaps that will be possible some day. |
| 2021-07-09 14:39:26 +0200 | <kosmikus> | HLS is evolving so quickly, it's amazing. |
| 2021-07-09 14:39:50 +0200 | <Gurkenglas> | could you download acme-everything and just goto definition? |
| 2021-07-09 14:40:13 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 14:40:14 +0200 | <dminuoso> | acme-everything sadly doesn't build, and quchen is too lazy to fix it. |
| 2021-07-09 14:40:27 +0200 | <dminuoso> | We ought to start a petition. |
| 2021-07-09 14:40:48 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 14:41:20 +0200 | pbrisbin | (~patrick@pool-173-49-147-28.phlapa.fios.verizon.net) |
| 2021-07-09 14:42:10 +0200 | <Gurkenglas> | the problem is that when you import lens and build your package goto definition doesnt work on lens, right? shouldnt it be possible to tell cabal/stack to put all the source in the local folder before building it? |
| 2021-07-09 14:42:13 +0200 | pbrisbin | (~patrick@pool-173-49-147-28.phlapa.fios.verizon.net) (Client Quit) |
| 2021-07-09 14:44:45 +0200 | pbrisbin | (~patrick@pool-173-49-147-28.phlapa.fios.verizon.net) |
| 2021-07-09 14:47:27 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-09 14:48:26 +0200 | <fendor> | iirc, with a bit of hacking, you can goto hackage libs with hls |
| 2021-07-09 14:48:33 +0200 | rostero | (uid236576@id-236576.tooting.irccloud.com) |
| 2021-07-09 14:48:51 +0200 | <fendor> | it's not stable yet, though |
| 2021-07-09 14:49:43 +0200 | jneira | (~jneira@212.8.115.226) (Quit: Client closed) |
| 2021-07-09 14:51:20 +0200 | <Gurkenglas> | you mean, the required hacking is likely to change in the future so it's not worth adding it as a command to stack and hls? |
| 2021-07-09 14:51:54 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 14:52:12 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 14:53:34 +0200 | <fendor> | yep |
| 2021-07-09 14:53:40 +0200 | <fendor> | based on hie files, iirc |
| 2021-07-09 14:54:08 +0200 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2021-07-09 15:01:03 +0200 | fluffyballoon | (~fluffybal@pat-verona-i.epic.com) |
| 2021-07-09 15:01:15 +0200 | alx741 | (~alx741@186.178.108.75) |
| 2021-07-09 15:03:48 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-09 15:06:17 +0200 | zebrag | (~chris@user/zebrag) |
| 2021-07-09 15:15:46 +0200 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-07-09 15:16:47 +0200 | hendursaga | (~weechat@user/hendursaga) |
| 2021-07-09 15:19:35 +0200 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-09 15:21:52 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2021-07-09 15:22:11 +0200 | biberu | (~biberu@user/biberu) |
| 2021-07-09 15:22:14 +0200 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2021-07-09 15:22:29 +0200 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
| 2021-07-09 15:24:25 +0200 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-57-65-92-163-194.dsl.bell.ca) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-09 15:24:43 +0200 | pieguy128 | (~pieguy128@bras-base-mtrlpq5031w-grc-57-65-92-163-194.dsl.bell.ca) |
| 2021-07-09 15:24:54 +0200 | viluon | (uid453725@id-453725.brockwell.irccloud.com) (Ping timeout: 252 seconds) |
| 2021-07-09 15:25:27 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 252 seconds) |
| 2021-07-09 15:25:32 +0200 | viluon | (uid453725@id-453725.brockwell.irccloud.com) |
| 2021-07-09 15:26:00 +0200 | ishutin_ | (~ishutin@87-97-88-250.pool.digikabel.hu) (Ping timeout: 252 seconds) |
| 2021-07-09 15:26:24 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-07-09 15:26:45 +0200 | ishutin | (~ishutin@87-97-88-250.pool.digikabel.hu) |
| 2021-07-09 15:27:18 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) |
| 2021-07-09 15:28:00 +0200 | Katarushisu | (~Katarushi@cpc152083-finc20-2-0-cust170.4-2.cable.virginm.net) (Quit: Ping timeout (120 seconds)) |
| 2021-07-09 15:28:18 +0200 | Katarushisu | (~Katarushi@cpc152083-finc20-2-0-cust170.4-2.cable.virginm.net) |
| 2021-07-09 15:29:36 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2021-07-09 15:30:02 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) |
| 2021-07-09 15:30:24 +0200 | typedfern_ | (~Typedfern@185.red-83-57-142.dynamicip.rima-tde.net) (Ping timeout: 252 seconds) |
| 2021-07-09 15:31:38 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 15:31:41 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Ping timeout: 255 seconds) |
| 2021-07-09 15:32:26 +0200 | turlando | (~turlando@user/turlando) |
| 2021-07-09 15:34:48 +0200 | funsafe | (~funsafe@2601:1c1:4200:938f:32aa:eb39:2110:e2ea) (Ping timeout: 252 seconds) |
| 2021-07-09 15:35:36 +0200 | funsafe | (~funsafe@2601:1c1:4200:938f:32aa:eb39:2110:e2ea) |
| 2021-07-09 15:36:37 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 15:37:43 +0200 | vpan | (~vilius@212.117.1.172) (Quit: Leaving.) |
| 2021-07-09 15:38:02 +0200 | egoist | (~egoist@186.235.80.249) |
| 2021-07-09 15:38:07 +0200 | <Martinsos> | Hi! I am trying to decide between tml and transformers package, is there a general consensus one which one is better? It is a pretty common use case, writing a Parser monad that needs to combine state and exceptions, will probably be writing some Reader Env transformers in the future and similar. |
| 2021-07-09 15:38:17 +0200 | <Martinsos> | mtl, not tml |
| 2021-07-09 15:39:02 +0200 | <nshepperd2> | they work together |
| 2021-07-09 15:39:13 +0200 | <nshepperd2> | mtl has the typeclasses, transformer has the types |
| 2021-07-09 15:39:33 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2021-07-09 15:39:49 +0200 | <nshepperd2> | it's not a thing where you need to only use one |
| 2021-07-09 15:39:52 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) |
| 2021-07-09 15:39:55 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 15:41:22 +0200 | <Hecate> | Martinsos: they work hand in hand |
| 2021-07-09 15:43:01 +0200 | typedfern_ | (~Typedfern@185.red-83-57-142.dynamicip.rima-tde.net) |
| 2021-07-09 15:43:07 +0200 | <Hecate> | hey typedfern_ :) |
| 2021-07-09 15:44:55 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-09 15:45:22 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2021-07-09 15:45:34 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) |
| 2021-07-09 15:45:38 +0200 | chomwitt | (~Pitsikoko@2a02:587:dc04:e00:d8f7:cdfe:4658:bec4) |
| 2021-07-09 15:48:15 +0200 | MorrowM | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-09 15:48:51 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Remote host closed the connection) |
| 2021-07-09 15:48:58 +0200 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 246 seconds) |
| 2021-07-09 15:49:04 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 15:49:51 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-09 15:51:21 +0200 | derelict | (~derelict@user/derelict) |
| 2021-07-09 15:51:56 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-09 15:53:05 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Read error: Connection reset by peer) |
| 2021-07-09 15:53:29 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-09 15:53:45 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 15:55:07 +0200 | comerijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 15:55:07 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-09 15:55:37 +0200 | mastarija | (~mastarija@31.217.22.8) |
| 2021-07-09 15:55:54 +0200 | mastarija | (~mastarija@31.217.22.8) (Client Quit) |
| 2021-07-09 15:57:21 +0200 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2021-07-09 15:57:40 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 258 seconds) |
| 2021-07-09 16:02:37 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 16:02:55 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 16:03:46 +0200 | azeem | (~azeem@dynamic-adsl-84-220-226-129.clienti.tiscali.it) |
| 2021-07-09 16:03:57 +0200 | comerijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-09 16:06:31 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2021-07-09 16:06:50 +0200 | nick8325 | (~nick@2001:9b1:26f9:3e00:b7ea:ac95:e18:4c1d) |
| 2021-07-09 16:07:41 +0200 | dunj3 | (~dunj3@2001:16b8:30aa:f100:5749:57d0:4660:97ec) (Remote host closed the connection) |
| 2021-07-09 16:07:43 +0200 | allbery_b | geekosaur |
| 2021-07-09 16:09:34 +0200 | <qrpnxz> | I'm kind of surprised that associativity et al. or not yet things you can declare now that i think about it. |
| 2021-07-09 16:10:33 +0200 | <qrpnxz> | *are |
| 2021-07-09 16:12:48 +0200 | <Martinsos> | Thanks pplz! Ok, so I should use mtl and transformers with it. I shouldn't use just transfomers, although I could, because I am loosing on goodies that mtl brings, right? |
| 2021-07-09 16:16:41 +0200 | nick8325 | (~nick@2001:9b1:26f9:3e00:b7ea:ac95:e18:4c1d) (Quit: Leaving.) |
| 2021-07-09 16:17:32 +0200 | nick8325 | (~nick8325@2001:9b1:26f9:3e00:b7ea:ac95:e18:4c1d) |
| 2021-07-09 16:17:40 +0200 | safinaskar | (~user@109.252.90.89) |
| 2021-07-09 16:18:11 +0200 | nick8325 | (~nick8325@2001:9b1:26f9:3e00:b7ea:ac95:e18:4c1d) (Client Quit) |
| 2021-07-09 16:18:36 +0200 | <safinaskar> | i just published my second hackage package! read ann: https://mail.haskell.org/pipermail/haskell-cafe/2021-July/134205.html |
| 2021-07-09 16:18:47 +0200 | <safinaskar> | parsing lib, arrow parsing |
| 2021-07-09 16:20:21 +0200 | sergal | (~ezra@user/ezra) |
| 2021-07-09 16:22:12 +0200 | nick8325 | (~nick8325@2001:9b1:26f9:3e00:b7ea:ac95:e18:4c1d) |
| 2021-07-09 16:22:39 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-07-09 16:24:38 +0200 | <yushyin> | what is this way to long subject, /me closes tab |
| 2021-07-09 16:27:17 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 16:27:34 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 16:28:11 +0200 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-07-09 16:29:08 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) |
| 2021-07-09 16:31:10 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 16:33:35 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 16:33:52 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 16:33:55 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2021-07-09 16:36:38 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-07-09 16:37:25 +0200 | Vajb | (~Vajb@n2hz3gq4auh6ltn9l-2.v6.elisa-mobile.fi) |
| 2021-07-09 16:37:50 +0200 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 255 seconds) |
| 2021-07-09 16:39:53 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 16:40:10 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 16:40:58 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 240 seconds) |
| 2021-07-09 16:41:21 +0200 | MorrowM | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 252 seconds) |
| 2021-07-09 16:41:54 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) |
| 2021-07-09 16:42:07 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 16:48:36 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) (Quit: WeeChat 2.8) |
| 2021-07-09 16:48:43 +0200 | sedeki | (~textual@user/sedeki) |
| 2021-07-09 16:50:16 +0200 | zcombinator | (~zcombinat@host-87-7-58-35.retail.telecomitalia.it) (Quit: WeeChat 3.2) |
| 2021-07-09 16:50:26 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-09 16:50:54 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-09 16:51:08 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 252 seconds) |
| 2021-07-09 16:51:17 +0200 | tomku | (~tomku@user/tomku) |
| 2021-07-09 16:54:27 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Remote host closed the connection) |
| 2021-07-09 16:56:09 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2021-07-09 16:56:44 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-09 16:56:55 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 16:58:01 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-09 16:58:37 +0200 | son0p | (~ff@181.136.122.143) |
| 2021-07-09 16:59:02 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 16:59:53 +0200 | Vajb | (~Vajb@n2hz3gq4auh6ltn9l-2.v6.elisa-mobile.fi) (Ping timeout: 255 seconds) |
| 2021-07-09 17:00:06 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2021-07-09 17:02:59 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 17:03:18 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 17:03:28 +0200 | MorrowM | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-09 17:05:08 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 17:05:22 +0200 | chomwitt | (~Pitsikoko@2a02:587:dc04:e00:d8f7:cdfe:4658:bec4) (Ping timeout: 240 seconds) |
| 2021-07-09 17:05:25 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 17:06:13 +0200 | sedeki | (~textual@user/sedeki) (Quit: Textual IRC Client: www.textualapp.com) |
| 2021-07-09 17:06:22 +0200 | hmmmas | (~fidnc@183.217.200.144) (Quit: Leaving.) |
| 2021-07-09 17:07:17 +0200 | wei2912 | (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-07-09 17:09:06 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 17:09:47 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 17:11:39 +0200 | chris-th_ | (~chris@81.96.113.213) |
| 2021-07-09 17:11:39 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Read error: Connection reset by peer) |
| 2021-07-09 17:13:15 +0200 | <qrpnxz> | interesting, i will check it out today |
| 2021-07-09 17:13:15 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-09 17:14:54 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 252 seconds) |
| 2021-07-09 17:15:01 +0200 | tomku | (~tomku@user/tomku) |
| 2021-07-09 17:17:20 +0200 | <safinaskar> | thanks! :) |
| 2021-07-09 17:19:15 +0200 | leeb | (~leeb@KD111239157039.au-net.ne.jp) |
| 2021-07-09 17:20:48 +0200 | <azeem> | tomsmeding: You can get a lot of examples by consider matrices with coefficients in some ring and I think even a semiring. You can consider the ring of Integers modulo n and even of polynomials in some number of variables. |
| 2021-07-09 17:21:20 +0200 | <azeem> | They will be non-commutative but associative. |
| 2021-07-09 17:26:05 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 17:26:22 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 17:28:32 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 17:28:49 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) |
| 2021-07-09 17:30:13 +0200 | Morrow | (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Quit: Leaving) |
| 2021-07-09 17:31:31 +0200 | MorrowM | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-09 17:31:54 +0200 | Morrow | (~Morrow@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-09 17:35:10 +0200 | lbseale | (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-07-09 17:37:00 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) |
| 2021-07-09 17:38:04 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-07-09 17:38:54 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-09 17:42:38 +0200 | ubert | (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) (Ping timeout: 255 seconds) |
| 2021-07-09 17:43:46 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 246 seconds) |
| 2021-07-09 17:44:27 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-09 17:46:36 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) |
| 2021-07-09 17:47:21 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 17:48:23 +0200 | sqrt2 | (~ben@80-108-18-7.cable.dynamic.surfer.at) (Quit: ZNC - http://znc.in) |
| 2021-07-09 17:48:42 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 17:50:30 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) |
| 2021-07-09 17:51:32 +0200 | <Martinsos> | I published my very first package on Hackage -> strongly typed paths, similar like 'path' which was big inspiration but I try to take it one level further: https://hackage.haskell.org/package/strong-path . Any comments on code / API are very welcome, as I still consider myself to be intermediate in Haskell! |
| 2021-07-09 17:51:41 +0200 | sqrt2 | (~ben@tunnel330957-pt.tunnel.tserv6.fra1.ipv6.he.net) |
| 2021-07-09 17:52:14 +0200 | <maerwald> | Martinsos: I posted my comment on reddig already :p |
| 2021-07-09 17:52:17 +0200 | <maerwald> | *reddit |
| 2021-07-09 17:52:50 +0200 | <Martinsos> | maerwald ah that is you thanks for that :D! I thought it might be worth putting it here also, I don't know how much people from IRC are also on reddit |
| 2021-07-09 17:53:10 +0200 | <maerwald> | Also, if you're using FilePath under the hood, then that would be my other critique |
| 2021-07-09 17:53:17 +0200 | <jle`> | nice Martinsos ! |
| 2021-07-09 17:53:26 +0200 | lortabac | (~lortabac@95.138.56.124) (Quit: WeeChat 2.8) |
| 2021-07-09 17:54:06 +0200 | egoist | (~egoist@186.235.80.249) (Quit: WeeChat 3.2) |
| 2021-07-09 17:54:31 +0200 | Kofid | (~Kofid@2601:404:d300:5a0:fcbf:c290:5998:a5c6) |
| 2021-07-09 17:55:43 +0200 | <Martinsos> | I am using Path under the hood actually, which uses FilePath :). Makes sense, but we can change that implementation in the future with no / little effect on the API I believe. |
| 2021-07-09 17:55:57 +0200 | <maerwald> | if I ever get AFPP done, yeah |
| 2021-07-09 17:56:22 +0200 | <maerwald> | Martinsos: https://github.com/hasufell/abstract-filepath |
| 2021-07-09 17:56:27 +0200 | <Martinsos> | Just read about AFPP, that would be cool! |
| 2021-07-09 17:57:11 +0200 | <maerwald> | I have green light from the CLC to attempt a user space implementation and start writing patches for e.g. filpath/unix/Win32, but it's gonna be a lot of wor |
| 2021-07-09 17:57:26 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 246 seconds) |
| 2021-07-09 17:58:19 +0200 | neurocyte4048 | (~neurocyte@46.243.81.30) |
| 2021-07-09 17:58:19 +0200 | neurocyte4048 | (~neurocyte@46.243.81.30) (Changing host) |
| 2021-07-09 17:58:19 +0200 | neurocyte4048 | (~neurocyte@user/neurocyte) |
| 2021-07-09 17:58:30 +0200 | neurocyte404 | (~neurocyte@user/neurocyte) (Read error: Connection reset by peer) |
| 2021-07-09 17:58:30 +0200 | neurocyte4048 | neurocyte404 |
| 2021-07-09 17:58:51 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 17:59:47 +0200 | <Martinsos> | It does look like a lot of work. I never got much into the lower-level details regarding the representation of path, normalization and similar, I leveraged Path for that, but I do hope to get some more time in the future to investigate that and to follow projects like AFPP |
| 2021-07-09 18:00:30 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 18:02:01 +0200 | <Martinsos> | Maybe stupid question but I see that you have AbstractFilePath and WindowsFilePath exported from the top module, however there is no PosixFilePath -> how is that? You do have PosixString though hm |
| 2021-07-09 18:03:24 +0200 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-07-09 18:05:13 +0200 | <maerwald> | those are the same |
| 2021-07-09 18:05:18 +0200 | <maerwald> | https://github.com/hasufell/abstract-filepath/blob/master/lib/AbstractFilePath/Internal/Types.hs#L37 |
| 2021-07-09 18:05:37 +0200 | <maerwald> | the String vs FilePath was a major question that made me stop working |
| 2021-07-09 18:05:56 +0200 | <maerwald> | rust also makes that distinction |
| 2021-07-09 18:06:05 +0200 | <maerwald> | although those are the same representation afair |
| 2021-07-09 18:07:42 +0200 | rednaZ[m] | (~r3dnazmat@2001:470:69fc:105::ba70) |
| 2021-07-09 18:08:53 +0200 | <maerwald> | Martinsos: https://paste.tomsmeding.com/1nCW1bVt |
| 2021-07-09 18:09:00 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 18:09:29 +0200 | <albet70> | does typeclass could be a type of another typeclass? |
| 2021-07-09 18:09:38 +0200 | <albet70> | I don't know how to describe |
| 2021-07-09 18:10:02 +0200 | <albet70> | typeclass has types, could typeclass has typeclass? |
| 2021-07-09 18:10:59 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b9550509afe7c5cdd8ef5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2021-07-09 18:10:59 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:156a:d066:25bb:13b1) (Ping timeout: 255 seconds) |
| 2021-07-09 18:11:03 +0200 | <albet70> | in Java, abstract class could extend interface, could typeclass extend typeclass? |
| 2021-07-09 18:14:07 +0200 | <boxscape> | albet70: we do have a thing called "super class", you can put constraints in the definition of a type class, e.g. `class Eq a => Ord a where ...` |
| 2021-07-09 18:14:10 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2021-07-09 18:14:44 +0200 | <boxscape> | not sure how close that comes to what you're thinking of |
| 2021-07-09 18:14:58 +0200 | <Martinsos> | maerwald: ahh that is tricky, haven't considered that. Somehow thought that filepath functions should work only with filepaths :D! The problem is that for this proposal to make sense you need to support everything that was supported so far? I don't have complete understanding of the problem, but the approach where there is a more general concept then, OSString (or maybe it is just Path? Is that also too specific?), and then there is |
| 2021-07-09 18:15:10 +0200 | <Martinsos> | Upff just lost second part of the message |
| 2021-07-09 18:16:07 +0200 | <Martinsos> | Anyway FilePath being newtype for OsString, like Rust does, makes some sense. Although I don't at first undresatnd fromt he name what OSString stands for. I would that this more general than FilePath is just Path. OSString is even more general? What could that be? |
| 2021-07-09 18:16:25 +0200 | safinaskar | (~user@109.252.90.89) () |
| 2021-07-09 18:16:49 +0200 | <maerwald> | Martinsos: it's very simple... it's the encoding that the syscalls expect |
| 2021-07-09 18:16:53 +0200 | <maerwald> | in a way |
| 2021-07-09 18:17:09 +0200 | <maerwald> | so on windows it's UTF-16 (at least for Win32) and on unix it's just char[] |
| 2021-07-09 18:17:17 +0200 | <Martinsos> | aha, so this is all about the encoding. |
| 2021-07-09 18:17:21 +0200 | <maerwald> | yes |
| 2021-07-09 18:17:29 +0200 | <maerwald> | rust uses WTF-8 though on windows, a custom encoding |
| 2021-07-09 18:17:36 +0200 | econo | (uid147250@user/econo) |
| 2021-07-09 18:17:48 +0200 | <maerwald> | internally |
| 2021-07-09 18:17:55 +0200 | <maerwald> | but once passed to syscalls it's UTF-16 |
| 2021-07-09 18:18:24 +0200 | <albet70> | boxscape how you describe the relation between typeclass and type |
| 2021-07-09 18:18:50 +0200 | <Martinsos> | Got it. Wish I could comment something more useful right now, but from my limited knowledge of the domain: sounds tricky all together :D / I am always in for keeping the types true to their name / approach 2 sounds reasonable |
| 2021-07-09 18:18:55 +0200 | <maerwald> | but it's not only filepaths that are UTF-16 |
| 2021-07-09 18:19:15 +0200 | <boxscape> | albet70: which typeclass and which type? |
| 2021-07-09 18:19:35 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) |
| 2021-07-09 18:20:10 +0200 | <Martinsos> | approach #3 surely not |
| 2021-07-09 18:20:15 +0200 | <albet70> | Semigroup and Monad |
| 2021-07-09 18:20:50 +0200 | <albet70> | Maybe and Monad |
| 2021-07-09 18:20:50 +0200 | <boxscape> | albet70: if you mean Semigroup and Monoid, Semigroup is a superclass of Monoid |
| 2021-07-09 18:21:00 +0200 | <boxscape> | Maybe is an instance of Monad |
| 2021-07-09 18:21:07 +0200 | <albet70> | yes |
| 2021-07-09 18:21:17 +0200 | <boxscape> | (Semigroup and Monad (as opposed to Monoid) are unrelated) |
| 2021-07-09 18:21:27 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2021-07-09 18:22:14 +0200 | <albet70> | if a type would be an instance of Monad, it could not be an instance of Semigroup? |
| 2021-07-09 18:22:48 +0200 | <davean> | No, it could be |
| 2021-07-09 18:22:56 +0200 | <davean> | well, sorta |
| 2021-07-09 18:23:21 +0200 | <davean> | Depends on what you mean by "it" |
| 2021-07-09 18:23:25 +0200 | kuribas | (~user@ptr-25vy0i8xkirhfn6k3n1.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-07-09 18:23:41 +0200 | <davean> | albet70: https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-List-NonEmpty.html#t:NonEmpty |
| 2021-07-09 18:24:04 +0200 | <davean> | Note Monad NonEmpty and Semigroup (NonEmpty a) |
| 2021-07-09 18:24:08 +0200 | <drdo> | How would I enable optimization for all packages (including external deps) in cabal.project? |
| 2021-07-09 18:24:24 +0200 | <davean> | SLIGHTLY different membership, but probably what you mean by being both |
| 2021-07-09 18:24:28 +0200 | <boxscape> | % :k Monad |
| 2021-07-09 18:24:29 +0200 | <yahb> | boxscape: (* -> *) -> Constraint |
| 2021-07-09 18:24:44 +0200 | Martinsos | (~Martinsos@cpe-188-129-56-84.dynamic.amis.hr) (Remote host closed the connection) |
| 2021-07-09 18:24:48 +0200 | <boxscape> | % :k Semigroup |
| 2021-07-09 18:24:48 +0200 | <yahb> | boxscape: * -> Constraint |
| 2021-07-09 18:25:04 +0200 | sergal | (~ezra@user/ezra) (Changing host) |
| 2021-07-09 18:25:04 +0200 | sergal | (~ezra@fsf/member/ezra) |
| 2021-07-09 18:30:02 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Remote host closed the connection) |
| 2021-07-09 18:31:14 +0200 | <albet70> | Functor, Applicative, Monad |
| 2021-07-09 18:31:30 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 256 seconds) |
| 2021-07-09 18:31:58 +0200 | <albet70> | an instance of Monad, so it must be an instance of Functor and Applicative, right? |
| 2021-07-09 18:32:19 +0200 | <[exa]> | true |
| 2021-07-09 18:34:06 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-09 18:34:25 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-09 18:34:31 +0200 | darklambda | cs |
| 2021-07-09 18:34:39 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-09 18:34:42 +0200 | cs | cpp |
| 2021-07-09 18:35:46 +0200 | cpp | darklambda |
| 2021-07-09 18:37:16 +0200 | hnOsmium0001 | (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-07-09 18:41:00 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) |
| 2021-07-09 18:41:15 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 252 seconds) |
| 2021-07-09 18:44:26 +0200 | shutdown_-h_now | (~arjan@82-75-187-100.cable.dynamic.v4.ziggo.nl) (Ping timeout: 252 seconds) |
| 2021-07-09 18:45:50 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2021-07-09 18:46:08 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-09 18:48:38 +0200 | <zzz> | if we have ´T a = T Wtv a` and i want to have `tmap :: (a -> b) -> T a -> Tb ; tmap f (T wtv a) = T wtv (f a)` how d we avoid the infinite type error? |
| 2021-07-09 18:50:01 +0200 | <dminuoso> | zzz: Can you present your real code? |
| 2021-07-09 18:50:25 +0200 | shutdown_-h_now | (~arjan@82-75-187-100.cable.dynamic.v4.ziggo.nl) |
| 2021-07-09 18:50:25 +0200 | <dminuoso> | It should exactly like that |
| 2021-07-09 18:50:46 +0200 | kaizen | (sid501599@id-501599.brockwell.irccloud.com) (Ping timeout: 246 seconds) |
| 2021-07-09 18:51:02 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) |
| 2021-07-09 18:51:07 +0200 | hendi | (sid489601@id-489601.tooting.irccloud.com) (Ping timeout: 246 seconds) |
| 2021-07-09 18:51:32 +0200 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds) |
| 2021-07-09 18:51:42 +0200 | hendi | (sid489601@id-489601.tooting.irccloud.com) |
| 2021-07-09 18:51:44 +0200 | kaizen | (sid501599@id-501599.brockwell.irccloud.com) |
| 2021-07-09 18:52:59 +0200 | <zzz> | oops, my bad |
| 2021-07-09 18:53:31 +0200 | hegstal | (~hegstal@2a02:c7f:7604:8a00:7018:37c7:e025:203e) |
| 2021-07-09 18:54:03 +0200 | <zzz> | i had `T = T Wtv (U a)` |
| 2021-07-09 18:54:14 +0200 | <zzz> | i mean `T a = T Wtv (U a)` |
| 2021-07-09 18:54:21 +0200 | <zzz> | time for a break |
| 2021-07-09 18:59:02 +0200 | <dminuoso> | What do you expect this to do, with that type signature? |
| 2021-07-09 18:59:48 +0200 | dajoer | (~david@user/gvx) (Quit: leaving) |
| 2021-07-09 19:02:54 +0200 | Obo | (~roberto@70.pool90-171-81.dynamic.orange.es) (Quit: WeeChat 2.8) |
| 2021-07-09 19:04:11 +0200 | phma | (phma@2001:5b0:212a:c338:e904:270b:aa2b:a4ce) (Read error: Connection reset by peer) |
| 2021-07-09 19:07:34 +0200 | michalz | (~michalz@185.246.204.61) (Remote host closed the connection) |
| 2021-07-09 19:10:16 +0200 | <yin[m]> | hi. I'm trying to make a short-circuiting fold, something like a foldl (||) False $ cycle [False, True] that doesn't hang. what's an idiomatic way of achieving this? |
| 2021-07-09 19:10:46 +0200 | <yin[m]> | i want it to work on maps, not just lists |
| 2021-07-09 19:11:10 +0200 | <monochrom> | foldr, despite wrong intuition |
| 2021-07-09 19:11:22 +0200 | <yin[m]> | can you explain? |
| 2021-07-09 19:11:24 +0200 | <monochrom> | > foldr (||) undefined (cycle [False, True]) |
| 2021-07-09 19:11:26 +0200 | <lambdabot> | True |
| 2021-07-09 19:11:56 +0200 | <yin[m]> | let me think about that |
| 2021-07-09 19:12:03 +0200 | <monochrom> | Perform lazy evaluation steps by hand to see why. |
| 2021-07-09 19:12:27 +0200 | <monochrom> | The popular science story of "foldr starts from the right" is wrong. Has always been wrong. |
| 2021-07-09 19:13:23 +0200 | <yin[m]> | of course. why did my intuition mislead me? |
| 2021-07-09 19:14:16 +0200 | roconnor_ | (~roconnor@host-104-157-226-103.dyn.295.ca) |
| 2021-07-09 19:15:14 +0200 | roconnor | (~roconnor@host-45-78-208-216.dyn.295.ca) (Ping timeout: 252 seconds) |
| 2021-07-09 19:15:30 +0200 | <maerwald> | compare foldl and foldr when using (-) |
| 2021-07-09 19:15:45 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 19:15:46 +0200 | <maerwald> | then check how laziness works for || |
| 2021-07-09 19:16:18 +0200 | <yin[m]> | foldl actually starts _evaluating_ from the right |
| 2021-07-09 19:16:34 +0200 | <yin[m]> | right? |
| 2021-07-09 19:16:44 +0200 | <monochrom> | No. |
| 2021-07-09 19:16:57 +0200 | <monochrom> | err, yes. |
| 2021-07-09 19:17:07 +0200 | <maerwald> | you build all the thunks through the list before you apply the first function |
| 2021-07-09 19:17:38 +0200 | Atum_ | (~IRC@user/atum/x-2392232) |
| 2021-07-09 19:18:09 +0200 | roconnor | (~roconnor@host-45-58-230-126.dyn.295.ca) |
| 2021-07-09 19:19:06 +0200 | <maerwald> | and at that time your `cycle` has already killed the cat |
| 2021-07-09 19:19:31 +0200 | <monochrom> | cycle killed the cat. foldr brought it back! |
| 2021-07-09 19:19:32 +0200 | roconnor_ | (~roconnor@host-104-157-226-103.dyn.295.ca) (Ping timeout: 252 seconds) |
| 2021-07-09 19:19:38 +0200 | <maerwald> | :> |
| 2021-07-09 19:20:50 +0200 | phma | (phma@2001:0:c38c:c38c:207c:8189:bcd3:2f32) |
| 2021-07-09 19:23:23 +0200 | MoC | (~moc@user/moc) (Quit: Konversation terminated!) |
| 2021-07-09 19:24:52 +0200 | viluon | (uid453725@id-453725.brockwell.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-09 19:25:13 +0200 | phma_ | (phma@2001:5b0:211b:d008:d38:3ff9:8a1d:e053) |
| 2021-07-09 19:25:14 +0200 | phma | (phma@2001:0:c38c:c38c:207c:8189:bcd3:2f32) (Ping timeout: 255 seconds) |
| 2021-07-09 19:28:34 +0200 | <zzz> | :) |
| 2021-07-09 19:31:50 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) (Ping timeout: 265 seconds) |
| 2021-07-09 19:34:34 +0200 | chris-th_ | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 19:37:14 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:44e3:e9f0:ea4d:f039) (Remote host closed the connection) |
| 2021-07-09 19:37:19 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 19:37:20 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Read error: Connection reset by peer) |
| 2021-07-09 19:37:32 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 19:37:58 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 19:42:38 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) |
| 2021-07-09 19:43:07 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 19:44:47 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-09 19:45:15 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-09 19:45:19 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 19:45:55 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) (Remote host closed the connection) |
| 2021-07-09 19:47:05 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 19:47:31 +0200 | mikail | (~mikail@2a02:c7f:bd83:fd00:55cf:122f:957a:f66f) |
| 2021-07-09 19:47:44 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 19:49:25 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 246 seconds) |
| 2021-07-09 19:49:59 +0200 | chris-the-slurpa | (~chris@81.96.113.213) (Ping timeout: 255 seconds) |
| 2021-07-09 19:50:04 +0200 | Reyu[M] | (~reyureyuz@matrix.reyuzenfold.com) |
| 2021-07-09 19:50:54 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 19:52:10 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2021-07-09 19:52:45 +0200 | derelict | (~derelict@user/derelict) (Ping timeout: 252 seconds) |
| 2021-07-09 19:52:57 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Ping timeout: 244 seconds) |
| 2021-07-09 19:53:45 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) |
| 2021-07-09 19:59:25 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 19:59:34 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 246 seconds) |
| 2021-07-09 20:00:16 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 2021-07-09 20:00:54 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 20:04:38 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2021-07-09 20:05:34 +0200 | chris-the-slurpa | (~chris@81.96.113.213) |
| 2021-07-09 20:06:46 +0200 | roconnor_ | (~roconnor@host-104-157-231-207.dyn.295.ca) |
| 2021-07-09 20:06:49 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) (Remote host closed the connection) |
| 2021-07-09 20:07:24 +0200 | roconnor_ | (~roconnor@host-104-157-231-207.dyn.295.ca) (Client Quit) |
| 2021-07-09 20:08:35 +0200 | roconnor | (~roconnor@host-45-58-230-126.dyn.295.ca) (Ping timeout: 252 seconds) |
| 2021-07-09 20:10:22 +0200 | chisui | (~chisui@200116b866eaab00b869ec172918c6ce.dip.versatel-1u1.de) |
| 2021-07-09 20:10:51 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) |
| 2021-07-09 20:10:58 +0200 | <chisui> | Hey, is there a way to resolve this issue without the need of an additional type variable? `Could not deduce: n1 ~ (n - 1) from the context: n ~ (n1 + 1)` |
| 2021-07-09 20:11:30 +0200 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2021-07-09 20:11:43 +0200 | lavaman | (~lavaman@98.38.249.169) |
| 2021-07-09 20:14:45 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 20:15:53 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 20:19:34 +0200 | pavonia | (~user@user/siracusa) |
| 2021-07-09 20:19:50 +0200 | pgib | (~textual@173.38.117.69) |
| 2021-07-09 20:20:14 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 20:21:01 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 20:22:42 +0200 | ukari | (~ukari@user/ukari) (Remote host closed the connection) |
| 2021-07-09 20:23:09 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 20:23:46 +0200 | ukari | (~ukari@user/ukari) |
| 2021-07-09 20:30:02 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-09 20:31:45 +0200 | <Hecate> | would I sound absolutely demented if I suggested to examine which GHC language extensions can be moved to a compiler plugin? |
| 2021-07-09 20:32:06 +0200 | <Hecate> | or have they all encroached in its architecture now? |
| 2021-07-09 20:32:33 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 20:33:27 +0200 | <Hecate> | or maybe we have some work to make compiler plugins' ergonomics better so that it doesn't slow adoption? |
| 2021-07-09 20:33:30 +0200 | <peutri> | bonus points for extracting ApplicativeDo |
| 2021-07-09 20:33:33 +0200 | <Hecate> | bgamari: what do you think? |
| 2021-07-09 20:34:03 +0200 | <Hecate> | peutri: yeah I was thinking of this, because people are talking about SelectiveDo on the subreddit and it might start as a compiler plugin |
| 2021-07-09 20:34:36 +0200 | <davean> | Hecate: what would be the proposed benefit? |
| 2021-07-09 20:35:01 +0200 | <bgamari> | yeah, I'll admit that I'm not entirely clear on what we would gain by doing so |
| 2021-07-09 20:35:23 +0200 | <bgamari> | all I see are costs |
| 2021-07-09 20:35:40 +0200 | <Hecate> | davean: the things that don't have to live in-tree can be put elsewhere, we can reduce the size of the GHC codebase… |
| 2021-07-09 20:35:45 +0200 | <Hecate> | bgamari: I'm interested to know why! |
| 2021-07-09 20:35:49 +0200 | <Hecate> | we're not modular enough? |
| 2021-07-09 20:36:11 +0200 | <davean> | Hecate: So, more cost of maintainership for ... a larger overall code base? I'm confused, I see no benefits here |
| 2021-07-09 20:36:43 +0200 | <monochrom> | I think the hope is that when a thing is called a "plugin", you can enable 3 plugins and expect no surprising interference, just because they are called "plugin"s. The word suggests so much modularity, no? |
| 2021-07-09 20:36:58 +0200 | <Hecate> | davean: why more cost of maintenership? |
| 2021-07-09 20:37:07 +0200 | <bgamari> | Hecate, well, many, if not most, extensions do require some extra syntax |
| 2021-07-09 20:37:13 +0200 | <peutri> | wouldn't the point be to have a smaller, lighter ghc? |
| 2021-07-09 20:37:14 +0200 | <davean> | Hecate: because you have to deal with GHC version still |
| 2021-07-09 20:37:19 +0200 | <monochrom> | And I think the reality is that they will still have the same ugly surprising interference as when we did things the old "monolithic" way. |
| 2021-07-09 20:37:22 +0200 | <bgamari> | and we currently have no means for plugins to extend the grammar |
| 2021-07-09 20:37:29 +0200 | <davean> | monochrom: but thats clearly silly |
| 2021-07-09 20:37:32 +0200 | <Hecate> | bgamari: ok, I wasn't quite aware of that. :) |
| 2021-07-09 20:37:40 +0200 | <bgamari> | even for those cases that don't require new syntax |
| 2021-07-09 20:37:43 +0200 | <davean> | but even if there was, theres only cost here |
| 2021-07-09 20:38:09 +0200 | <bgamari> | you still have the usual composability problems that plugins introduce |
| 2021-07-09 20:38:13 +0200 | <bgamari> | as monochrom suggested |
| 2021-07-09 20:38:17 +0200 | <Hecate> | I see the errors of my ways. Let's first create a beautiful monolith before thinking about splitting and modularity |
| 2021-07-09 20:38:34 +0200 | <bgamari> | then there are also the purely practical considerations |
| 2021-07-09 20:38:47 +0200 | <bgamari> | e.g. presumably we would want to continue to evolve the plugin alongside GHC |
| 2021-07-09 20:38:58 +0200 | <Hecate> | which is certainly reasonable :P |
| 2021-07-09 20:39:03 +0200 | <davean> | Hecate: no, I don't think you EVER split this |
| 2021-07-09 20:39:08 +0200 | <bgamari> | which means we would have to advance multiple projects in lockstep |
| 2021-07-09 20:39:09 +0200 | <davean> | Hecate: because they're inhernetly tied |
| 2021-07-09 20:39:18 +0200 | <Hecate> | bgamari: ok, got it! |
| 2021-07-09 20:39:21 +0200 | <Hecate> | davean: 👍 |
| 2021-07-09 20:39:23 +0200 | <bgamari> | potentially introducing another haddock scenario |
| 2021-07-09 20:39:35 +0200 | <bgamari> | it's an interesting idea though |
| 2021-07-09 20:39:40 +0200 | motherfs1 | (~motherfsc@user/motherfsck) |
| 2021-07-09 20:40:40 +0200 | <davean> | The only "benefit" to plugins I see here is supporting new things on older GHCs, but thats combinatorically more work, and its a bad idea - upgrade GHC, you need to anyway |
| 2021-07-09 20:41:10 +0200 | <monochrom> | The monad transformer saga was a wake-up call. |
| 2021-07-09 20:41:20 +0200 | <Hecate> | monochrom: tell me more :) |
| 2021-07-09 20:41:34 +0200 | <davean> | monochrom: ? |
| 2021-07-09 20:42:15 +0200 | <monochrom> | Early adoptors used to think that the monad transformer way was "modular", "plugin", "component", "mix and match", all those nice utopian->dystopian wordings. |
| 2021-07-09 20:42:41 +0200 | <monochrom> | Just because each monad transformer has standalone definition, "no dependency". |
| 2021-07-09 20:43:00 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 272 seconds) |
| 2021-07-09 20:43:04 +0200 | <monochrom> | We now understand that you combine your monad transformers to build a monolith. |
| 2021-07-09 20:43:05 +0200 | mikail | (~mikail@2a02:c7f:bd83:fd00:55cf:122f:957a:f66f) (Ping timeout: 255 seconds) |
| 2021-07-09 20:43:45 +0200 | <sclv> | i think plugins for things like selective-do (or preprocessors) are good as proofs of concept |
| 2021-07-09 20:43:54 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-09 20:44:14 +0200 | <sclv> | you can develop them independently, let a few brave people try them out and get a feel for it |
| 2021-07-09 20:44:26 +0200 | <sclv> | but long term you have to fold it in to the main codebase or it usually dies |
| 2021-07-09 20:45:12 +0200 | <sclv> | in the case of selective-do its the preprocessor approach rather than plugin imho, since its a syntactic transform |
| 2021-07-09 20:45:13 +0200 | <bgamari> | right |
| 2021-07-09 20:45:16 +0200 | <bgamari> | I agree with that |
| 2021-07-09 20:45:23 +0200 | <sclv> | recall that's how arrows were first done too -- a long tradition! |
| 2021-07-09 20:45:26 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 20:45:30 +0200 | <bgamari> | plugins are really best used for a prototyping |
| 2021-07-09 20:45:35 +0200 | <Hecate> | oki doki |
| 2021-07-09 20:45:58 +0200 | <bgamari> | IIRC scala used to make quite a bit of use of compiler plugins |
| 2021-07-09 20:46:14 +0200 | <bgamari> | and the effect was that projects became very tied to particular compiler versions |
| 2021-07-09 20:46:53 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 20:47:40 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) (Remote host closed the connection) |
| 2021-07-09 20:48:18 +0200 | motherfs1 | (~motherfsc@user/motherfsck) (Ping timeout: 252 seconds) |
| 2021-07-09 20:49:43 +0200 | <lechner> | Hi, what are the "row types" mentioned here, and why are they scary, please? Thanks! https://chrisdone.com/posts/clientside-programming-haskell/ |
| 2021-07-09 20:49:46 +0200 | <sclv> | also these days for syntactic prototyping one can do it directly with quasiquotes, which is pretty nice and stable |
| 2021-07-09 20:49:53 +0200 | <davean> | I've seen plugins used for library support too |
| 2021-07-09 20:49:55 +0200 | <sclv> | but again unpleasant compared to doing it directly |
| 2021-07-09 20:50:06 +0200 | <davean> | where its not a language thing, but a specific library needs a macro-ish transform to work |
| 2021-07-09 20:50:13 +0200 | <davean> | like for tracing |
| 2021-07-09 20:50:23 +0200 | <davean> | Thats where a plugin always fits I think |
| 2021-07-09 20:51:30 +0200 | amahl | (~amahl@dsl-jklbng12-54fbca-64.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-09 20:52:14 +0200 | <Hecate> | davean: Polysemy needs a plugin to avoid terrible performance |
| 2021-07-09 20:52:20 +0200 | <sclv> | lechner: they're just anonymous records, also known as heterogenous lists, hlists, or "extensible tuples" among other things |
| 2021-07-09 20:52:25 +0200 | <Hecate> | (but delcont primop should fix this) |
| 2021-07-09 20:52:36 +0200 | <sclv> | there's plenty of packages for doing them in haskell -- hlist, row-types, etc... |
| 2021-07-09 20:52:53 +0200 | <sclv> | they were scary in the context of ur because it was written by a type theorist so they looked scary |
| 2021-07-09 20:52:59 +0200 | <sclv> | in the docs :-) |
| 2021-07-09 20:53:03 +0200 | <Hecate> | lechner: https://hgiasac.github.io/posts/2018-11-18-Record-Row-Type-and-Row-Polymorphism.html |
| 2021-07-09 20:53:39 +0200 | <sclv> | ml also had them for years, where they were considered Not Scary |
| 2021-07-09 20:54:12 +0200 | <davean> | sclv: I don't know, I thought they were scary because they type system implimentations tend to work poorly and have bad comprimises :) |
| 2021-07-09 20:54:20 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-07-09 20:54:31 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2021-07-09 20:54:35 +0200 | <sclv> | there's a lot of systems that do them pretty well in the literature, not least ml |
| 2021-07-09 20:54:36 +0200 | <Hecate> | I know error reporting in PureScript is at times painful |
| 2021-07-09 20:54:45 +0200 | <monochrom> | "The row types documentation frankly scares me away." is very different from "the row types scares me away". |
| 2021-07-09 20:55:21 +0200 | <sclv> | having them in the presence of a ton of other things including type classes and higher order polymorphism etc can be a bit much |
| 2021-07-09 20:55:22 +0200 | Vajb | (~Vajb@2001:999:62:1d53:26b1:6c9b:c1ed:9c01) (Read error: Connection reset by peer) |
| 2021-07-09 20:55:30 +0200 | <monochrom> | As usual, Chris Done doesn't write ridiculous things. |
| 2021-07-09 20:55:38 +0200 | <sclv> | well... |
| 2021-07-09 20:55:41 +0200 | <Hecate> | monochrom: since the documentation is the gateway to the concept, they mean the same thing |
| 2021-07-09 20:55:55 +0200 | <davean> | Hecate: absolutely not! |
| 2021-07-09 20:56:05 +0200 | <monochrom> | No. I know how to write scary documentation for Int. |
| 2021-07-09 20:56:14 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-09 20:56:18 +0200 | <lechner> | Is this still true? (from Hecate) "you can't define Person { name :: String } and Cat { name :: String } in same module. Function name will be duplicated" |
| 2021-07-09 20:56:32 +0200 | <monochrom> | For Bool. For (). |
| 2021-07-09 20:56:42 +0200 | <davean> | lechner: somewhat |
| 2021-07-09 20:56:52 +0200 | <davean> | lechner: Thats never a problem though |
| 2021-07-09 20:57:03 +0200 | <davean> | (Its a problem if you can!) |
| 2021-07-09 20:57:07 +0200 | <Hecate> | monochrom: I swear to god I've had terrifying introductions in maths class for concepts that scared me years after until someone introduced me to them again |
| 2021-07-09 20:57:21 +0200 | <sclv> | we have an extension that removes that limitation iirc -- a whole universe of extensions for working with that sort of stuff now in fact (and i'm not up to speed because i haven't bothered to use em in practice yet) |
| 2021-07-09 20:57:24 +0200 | <davean> | Hecate: right, so don't do the documentation, just do the concepts |
| 2021-07-09 20:57:38 +0200 | <davean> | sclv: well thats not Haskell persay |
| 2021-07-09 20:57:38 +0200 | <Hecate> | davean: the concepts don't appear from nowhere in your head :) |
| 2021-07-09 20:58:00 +0200 | <davean> | Hecate: No, they appear from the direct specification |
| 2021-07-09 20:58:01 +0200 | <monochrom> | I know how to write scary documentation for javascript. Hell, I learned from Guy Steele, he did that. |
| 2021-07-09 20:58:09 +0200 | <davean> | Usually the construction |
| 2021-07-09 20:58:18 +0200 | <Hecate> | davean: specification isn't documentation? |
| 2021-07-09 20:58:33 +0200 | <davean> | Hecate: absolutely not, it exactly the thing |
| 2021-07-09 20:58:42 +0200 | <davean> | Its definitional |
| 2021-07-09 20:58:44 +0200 | <lechner> | I plan to use Generic instances for FromJSON for parsing, but the files are complicated and may share field names across levels. Will that be a problem? |
| 2021-07-09 20:59:03 +0200 | <Hecate> | davean: is a reference documentation for you? |
| 2021-07-09 20:59:11 +0200 | <davean> | Hecate: Yes |
| 2021-07-09 20:59:13 +0200 | <sclv> | lechner: that shouldn't be a problem, no. just make sure that the datatypes with overlapping field names are each defined in different modules. |
| 2021-07-09 20:59:29 +0200 | <davean> | Hecate: I do not mean "specification" like "someone describing it" I mean specification as in "this specifies it" |
| 2021-07-09 20:59:34 +0200 | <lechner> | ok, thanks! |
| 2021-07-09 20:59:44 +0200 | xff0x | (~xff0x@2001:1a81:521d:ec00:3970:2542:2f1d:feb7) (Ping timeout: 255 seconds) |
| 2021-07-09 20:59:46 +0200 | <Hecate> | davean: then you're the first person I've met who doesn't believe that specification is documentation |
| 2021-07-09 20:59:56 +0200 | <Hecate> | Personally I follow this quadrant: https://documentation.divio.com/_images/overview.png |
| 2021-07-09 21:00:02 +0200 | <sclv> | also cf https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/duplicate_record_fields.html |
| 2021-07-09 21:00:17 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 21:00:19 +0200 | <davean> | Hecate: I think this is an issue with there being multiple meanings of the word specification, which I tried to clarify |
| 2021-07-09 21:00:22 +0200 | <dsal> | ghc: panic! (the 'impossible' happened) -- well, I guess it's lunch time. |
| 2021-07-09 21:00:29 +0200 | <Hecate> | dsal: happy meal |
| 2021-07-09 21:00:36 +0200 | motherfs1 | (~motherfsc@user/motherfsck) |
| 2021-07-09 21:01:03 +0200 | <Hecate> | davean: I don't understand the difference between "something describing it" and "something specifying it"? |
| 2021-07-09 21:01:05 +0200 | <monochrom> | No one is interested in my scary take on Bool and ()? >:) |
| 2021-07-09 21:01:20 +0200 | <davean> | Hecate: the later is the actual thing, the former is a description of a thing |
| 2021-07-09 21:01:21 +0200 | <Hecate> | monochrom: I implemented 'Num ()', nothing scares me :P |
| 2021-07-09 21:01:28 +0200 | xff0x | (~xff0x@185.65.135.235) |
| 2021-07-09 21:01:32 +0200 | <Hecate> | davean: but the actual thing… isn't it the implementation? |
| 2021-07-09 21:01:38 +0200 | <davean> | Hecate: yes, exactly |
| 2021-07-09 21:01:39 +0200 | <Hecate> | does it exist on paper? |
| 2021-07-09 21:01:43 +0200 | <sclv> | we need an RFC on the meaning of specification and reference. a specification MAY be documentation. a reference MUST be documentation. |
| 2021-07-09 21:01:50 +0200 | <davean> | Hecate: Maybe? |
| 2021-07-09 21:01:53 +0200 | <monochrom> | That doesn't mean I can't tell a scary story logically equivalent to a normal explanation of (). |
| 2021-07-09 21:01:55 +0200 | <sclv> | everything can exist on paper, if you have enough pages |
| 2021-07-09 21:01:59 +0200 | <davean> | sclv: yes |
| 2021-07-09 21:02:04 +0200 | <Hecate> | davean: don't you need then to reverse-engineer the implementation to extract a set of observable behaviours? |
| 2021-07-09 21:02:25 +0200 | <sclv> | the implementation contains the observable behaviors within it directly |
| 2021-07-09 21:02:38 +0200 | <davean> | Hecate: no, thats rediculous, it does the tihng it does |
| 2021-07-09 21:02:41 +0200 | <Hecate> | so you presume an implementation that follows the spec? |
| 2021-07-09 21:02:47 +0200 | <davean> | Hecate: no! |
| 2021-07-09 21:02:49 +0200 | <davean> | never! |
| 2021-07-09 21:02:51 +0200 | <davean> | Thats horrid |
| 2021-07-09 21:02:52 +0200 | <sclv> | a "reference implementation" MAY be a specification |
| 2021-07-09 21:03:02 +0200 | <davean> | sclv: yes |
| 2021-07-09 21:03:14 +0200 | <Hecate> | ok for context I have very, very little experience in program or static analysis |
| 2021-07-09 21:03:46 +0200 | <sclv> | i don't think this is directly related to that. basically a specification is a socially agreed on thing that can take any number of forms but which has some method of validating conformance |
| 2021-07-09 21:03:50 +0200 | <davean> | Hecate: data Z = S Z | N |
| 2021-07-09 21:03:51 +0200 | <monochrom> | I even know many long and contrived ways to say "true". |
| 2021-07-09 21:03:53 +0200 | <davean> | thats a specification |
| 2021-07-09 21:04:14 +0200 | <davean> | I can start adding other facts |
| 2021-07-09 21:04:21 +0200 | <Hecate> | monochrom: ok spill the beans already :P |
| 2021-07-09 21:04:28 +0200 | <Hecate> | davean: oh, okay |
| 2021-07-09 21:04:38 +0200 | <davean> | You start talking about it, and you're not longer a specification |
| 2021-07-09 21:04:40 +0200 | <sclv> | > fix ("true && " ++) |
| 2021-07-09 21:04:41 +0200 | <monochrom> | "The books I read are the books read by all those who read all books I read" is a long way to say "true", since it is a tautology. |
| 2021-07-09 21:04:42 +0200 | <lambdabot> | "true && true && true && true && true && true && true && true && true && tru... |
| 2021-07-09 21:05:21 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-09 21:05:43 +0200 | <monochrom> | "the stone topology of two points" is a trolling way to say "Bool", since every stone topology is a boolean algebra. |
| 2021-07-09 21:05:55 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 21:06:11 +0200 | <Hecate> | damn I forgot what were talking about in the beginning |
| 2021-07-09 21:06:38 +0200 | <Hecate> | ah yes, terrifying introductions that can bar access to simple concepts |
| 2021-07-09 21:06:50 +0200 | <monochrom> | There are multiple ways to document/specify/define/characterize/whateveryoucallit a thing in a scary or trolling or highbrow way. All it takes is creativity and knowledge. Doesn't mean the thing itself is not simple. |
| 2021-07-09 21:06:52 +0200 | <davean> | Hecate: the very nature of debuging is understanding something via specification instead of documentation! |
| 2021-07-09 21:07:18 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) |
| 2021-07-09 21:07:22 +0200 | <davean> | Thats a reasonable working definition of debugging in many ways |
| 2021-07-09 21:07:25 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 21:07:30 +0200 | <Hecate> | hm okay |
| 2021-07-09 21:07:50 +0200 | <sclv> | well i mean specification, implementation and documentation all may vary |
| 2021-07-09 21:08:10 +0200 | <davean> | sclv: depending on which definition of specification you're using |
| 2021-07-09 21:08:25 +0200 | <Hecate> | a function specification document I guess? |
| 2021-07-09 21:08:36 +0200 | <sclv> | specification is a socially agreed on thing that can be validated against |
| 2021-07-09 21:08:43 +0200 | <davean> | well I'd say implimentation is how you write down the specification, the specification is the actual behaviors |
| 2021-07-09 21:08:58 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2021-07-09 21:09:07 +0200 | <sclv> | implementation is a thing you validate against the specification, unless its a reference implementation taken to be the specification |
| 2021-07-09 21:09:44 +0200 | <davean> | Hecate: do you get what I'm saying about about debugging though? |
| 2021-07-09 21:09:52 +0200 | <Hecate> | that's the moment where I realise I missed a bunch of things by not studying onthology of programs lol |
| 2021-07-09 21:10:01 +0200 | Deide | (~Deide@217.155.19.23) |
| 2021-07-09 21:10:02 +0200 | Deide | (~Deide@217.155.19.23) (Changing host) |
| 2021-07-09 21:10:02 +0200 | Deide | (~Deide@user/deide) |
| 2021-07-09 21:10:08 +0200 | <sclv> | specifications MAY have undefined behaviors. implementations definitionally CANNOT |
| 2021-07-09 21:10:11 +0200 | <Hecate> | davean: yes, debugging is acting against the observable behaviour |
| 2021-07-09 21:10:21 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-09 21:10:27 +0200 | <davean> | or derivable, sorta the same thing? |
| 2021-07-09 21:10:31 +0200 | <davean> | but yah |
| 2021-07-09 21:11:08 +0200 | <davean> | The main documentation I want is an ordering of how I should read an implimentation |
| 2021-07-09 21:11:25 +0200 | <Hecate> | like Jonesforth? |
| 2021-07-09 21:11:39 +0200 | <monochrom> | oh, internal vs external documentation... |
| 2021-07-09 21:11:55 +0200 | __monty__ | (~toonn@user/toonn) |
| 2021-07-09 21:11:57 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) (Ping timeout: 252 seconds) |
| 2021-07-09 21:12:29 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2021-07-09 21:13:27 +0200 | xff0x | (~xff0x@185.65.135.235) (Ping timeout: 268 seconds) |
| 2021-07-09 21:14:17 +0200 | <davean> | Hecate: I'm not sure what that is, but a search seems to show a fuckton of problematic words instead of an actual order I should read an implimentation in |
| 2021-07-09 21:14:39 +0200 | xff0x | (~xff0x@2001:1a81:521d:ec00:3970:2542:2f1d:feb7) |
| 2021-07-09 21:15:08 +0200 | <Hecate> | https://github.com/nornagon/jonesforth/blob/master/jonesforth.S |
| 2021-07-09 21:15:13 +0200 | <Hecate> | It's literate programming |
| 2021-07-09 21:15:21 +0200 | <Hecate> | you read it from top to bottom |
| 2021-07-09 21:15:33 +0200 | <davean> | Great, see all thsoe words? Remove them |
| 2021-07-09 21:15:38 +0200 | <davean> | DO NOT WANT |
| 2021-07-09 21:16:07 +0200 | <Hecate> | not gonna lie when you don't know shit to Forth or Asm, it's darn useful :P |
| 2021-07-09 21:16:21 +0200 | <Hecate> | but I acknowledge that we have different needs |
| 2021-07-09 21:16:31 +0200 | <davean> | This is someone's attempt to explain sometihng with code |
| 2021-07-09 21:16:35 +0200 | <davean> | it is NOT specificaiton |
| 2021-07-09 21:16:51 +0200 | <davean> | I do not get truth from this |
| 2021-07-09 21:17:01 +0200 | <Hecate> | (technically yes, because each Forth is different) |
| 2021-07-09 21:17:11 +0200 | <Hecate> | you get the truth about this program's behaviour |
| 2021-07-09 21:17:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2021-07-09 21:17:20 +0200 | <davean> | Not from the words |
| 2021-07-09 21:17:31 +0200 | <Hecate> | you mean the prose? |
| 2021-07-09 21:17:34 +0200 | <davean> | yes |
| 2021-07-09 21:17:41 +0200 | <Hecate> | what is truth for you? |
| 2021-07-09 21:17:55 +0200 | <davean> | Now, take time to write the implimentation carefully so its assembled in a convinient form to think about |
| 2021-07-09 21:17:57 +0200 | <davean> | THATS helpful |
| 2021-07-09 21:18:28 +0200 | <davean> | Pick useful base pieces, build your implimentation from those |
| 2021-07-09 21:18:47 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) |
| 2021-07-09 21:19:10 +0200 | <davean> | Good factoring is sorta like documentation |
| 2021-07-09 21:19:15 +0200 | <Hecate> | it only works when you use an implementation mechanism that can be perfectly understood, where you presume your reader to be ridden of all biases or unable to mis-understand your code |
| 2021-07-09 21:19:35 +0200 | <davean> | No, it doesn't have to be perfectly understood - it can't be |
| 2021-07-09 21:19:38 +0200 | <monochrom> | This being asm, I do expect a mess, code that misses the forest for the trees, and clever tricks that need back-stories. |
| 2021-07-09 21:19:41 +0200 | <davean> | but you can reach truths from it |
| 2021-07-09 21:20:11 +0200 | <davean> | Hecate: and no, theres no room for biases when you actually face truth |
| 2021-07-09 21:20:18 +0200 | <davean> | prose is what allows biases, etc |
| 2021-07-09 21:20:22 +0200 | <davean> | because theres room for interpritation |
| 2021-07-09 21:20:34 +0200 | <Hecate> | davean: what do you call "truth"? For me it's the relationship between your perception of fact, and facts |
| 2021-07-09 21:20:57 +0200 | <Hecate> | when they become aligned in their complexity, then you reach truth |
| 2021-07-09 21:20:59 +0200 | <davean> | Truth is exactly what is |
| 2021-07-09 21:21:18 +0200 | <davean> | Your understanding is beside the point |
| 2021-07-09 21:21:52 +0200 | <Hecate> | your understanding is what allows you to act on truth, that's why many people with diverging conclusions are convinced to posess truth |
| 2021-07-09 21:21:57 +0200 | <Hecate> | despite facing the same facts |
| 2021-07-09 21:22:37 +0200 | <davean> | act sure - perhaps. Though I'd say one can act correctly without understanding. I've verified many things and used them without gaining understanding. |
| 2021-07-09 21:28:35 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) |
| 2021-07-09 21:29:30 +0200 | haykam3 | (~haykam@static.100.2.21.65.clients.your-server.de) (Remote host closed the connection) |
| 2021-07-09 21:29:42 +0200 | haykam1 | (~haykam@static.100.2.21.65.clients.your-server.de) |
| 2021-07-09 21:30:01 +0200 | Ariakenom | (~Ariakenom@c83-255-154-140.bredband.tele2.se) |
| 2021-07-09 21:30:35 +0200 | wallymathieu | (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-07-09 21:34:03 +0200 | cuz | (~user@38.140.58.234) |
| 2021-07-09 21:34:51 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 255 seconds) |
| 2021-07-09 21:35:11 +0200 | cheater | (~Username@user/cheater) |
| 2021-07-09 21:36:48 +0200 | Guest62 | (~Guest62@187.83.249.216.dyn.smithville.net) |
| 2021-07-09 21:37:35 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) (Ping timeout: 246 seconds) |
| 2021-07-09 21:39:32 +0200 | <Guest62> | so i'm suddenly having issues installing a package with stack on arch. used to work fine, but now when i do `stack install vulkan` in a directory without a project, it takes a few minutes, seems to work and exits gracefully after "Registering library for vulkan-3.6.2..". But import Vulkan.Core10 is always "could not find module" and stack exec |
| 2021-07-09 21:39:32 +0200 | <Guest62> | ghc-pkg -- list doesn't have vulkan anywhere |
| 2021-07-09 21:39:38 +0200 | <Guest62> | any ideas for what i might be doing wrong? |
| 2021-07-09 21:40:59 +0200 | isekaijin | (~pyon@user/pyon) (Ping timeout: 252 seconds) |
| 2021-07-09 21:41:42 +0200 | isekaijin | (~pyon@user/pyon) |
| 2021-07-09 21:43:55 +0200 | <boxscape> | Why do I get this error when trying to derive Generic? I feel like I may be missing something obvious... https://paste.tomsmeding.com/6EopZUJE |
| 2021-07-09 21:44:17 +0200 | <boxscape> | hm am I importing the wrong module |
| 2021-07-09 21:44:36 +0200 | <boxscape> | yes |
| 2021-07-09 21:44:38 +0200 | <boxscape> | it's GHC.Generics |
| 2021-07-09 21:44:39 +0200 | <boxscape> | thanks |
| 2021-07-09 21:44:44 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-09 21:44:55 +0200 | <lechner> | yeah, that's what i use |
| 2021-07-09 21:46:16 +0200 | coeus | (~coeus@b2b-92-50-96-34.unitymedia.biz) (Killed (NickServ (GHOST command used by _coeus!~coeus@250.sub-174-205-176.myvzw.com))) |
| 2021-07-09 21:46:39 +0200 | coeus | (~coeus@b2b-92-50-96-34.unitymedia.biz) |
| 2021-07-09 21:47:08 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 21:47:38 +0200 | <sm> | Guest62 are you sure you're not in a project ? Eg a parent directory ? Try to reproduce in $HOME |
| 2021-07-09 21:48:06 +0200 | coeus | (~coeus@b2b-92-50-96-34.unitymedia.biz) (Killed (NickServ (GHOST command used by _coeus!~coeus@250.sub-174-205-176.myvzw.com))) |
| 2021-07-09 21:48:29 +0200 | coeus_ | (~coeus@b2b-92-50-96-34.unitymedia.biz) |
| 2021-07-09 21:49:21 +0200 | <Guest62> | yeah, same thing. `stack exec ghc` returns 'could not find module', and `stack exec ghc-pkg -- list` still doesn't list vulkan even in ~ |
| 2021-07-09 21:49:37 +0200 | epolanski | (uid312403@id-312403.brockwell.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-07-09 21:50:17 +0200 | drd | (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-09 21:50:23 +0200 | <sm> | Odd, any funny haskell related env vars ? |
| 2021-07-09 21:51:03 +0200 | <sm> | Try the install again with increased --verbosity ? |
| 2021-07-09 21:58:46 +0200 | wqsz7xn | (~wqsz7xn@202.36.244.28) (Quit: Leaving) |
| 2021-07-09 21:59:02 +0200 | <Guest62> | tried reinstalling but it looks like it's just finding the package that was installed and just linking that |
| 2021-07-09 21:59:06 +0200 | <Boarders> | this is really an algorithms question but someone here might know. If I have a set of integers and I want to choose a subset that is closest to summing to a target value, is there a nice algorithm to do that? |
| 2021-07-09 21:59:13 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:af88:6c9:cc87:d82a) |
| 2021-07-09 21:59:21 +0200 | <Guest62> | i wonder if i might've set some default options somewhere for stack |
| 2021-07-09 21:59:48 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 22:00:22 +0200 | chisui | (~chisui@200116b866eaab00b869ec172918c6ce.dip.versatel-1u1.de) (Quit: Client closed) |
| 2021-07-09 22:00:31 +0200 | <Guest62> | ls |
| 2021-07-09 22:01:07 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 22:01:43 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-09 22:01:56 +0200 | <sm> | Guest62: that would be in ~/.stack/global-project |
| 2021-07-09 22:02:12 +0200 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-09 22:02:29 +0200 | <sm> | reinstalling with --verbosity=debug should show some kind of path info, if not then probably --force-reinstall or something will help |
| 2021-07-09 22:02:33 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 252 seconds) |
| 2021-07-09 22:03:05 +0200 | smtnet3 | (~asdfasdfa@202.36.244.28) |
| 2021-07-09 22:04:59 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) (Remote host closed the connection) |
| 2021-07-09 22:05:15 +0200 | juhp | (~juhp@128.106.188.66) (Ping timeout: 268 seconds) |
| 2021-07-09 22:07:31 +0200 | juhp | (~juhp@128.106.188.66) |
| 2021-07-09 22:08:11 +0200 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-07-09 22:08:55 +0200 | ghais | (~ghais@c-76-97-106-226.hsd1.ga.comcast.net) |
| 2021-07-09 22:09:36 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 22:12:11 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2021-07-09 22:12:21 +0200 | phma_ | phma |
| 2021-07-09 22:12:25 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-09 22:13:59 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 255 seconds) |
| 2021-07-09 22:16:11 +0200 | <ghais> | Hi all. I have a package https://github.com/ghais/HQu which depends on hmatrix-gsl which in turn depends on gsl (Gnu Scientific Library). I cannot seem to get hackage servers to build this library correctly. However other libraries that depend on gsl seem to build fine on hackage build servers. Does anyone know if i have an issue in my cabal file |
| 2021-07-09 22:16:12 +0200 | <ghais> | (https://github.com/ghais/HQu/blob/main/HQu.cabal)? |
| 2021-07-09 22:16:23 +0200 | <ghais> | I would appreciate any help, i tried everything i can think about |
| 2021-07-09 22:16:59 +0200 | <ghais> | Sorry second link is messed up: https://github.com/ghais/HQu/blob/main/HQu.cabal |
| 2021-07-09 22:18:11 +0200 | <ghais> | alternatively are there any documentations about the hackage build servers where i can define my system dependencies? |
| 2021-07-09 22:18:16 +0200 | <ghais> | pkgconfig-depends: gsl |
| 2021-07-09 22:18:39 +0200 | <ghais> | doesn't seem to do the trick on the server, since i get a message saying it cannot be satisfied |
| 2021-07-09 22:20:07 +0200 | waleee | (~waleee@h-98-128-228-119.NA.cust.bahnhof.se) |
| 2021-07-09 22:20:34 +0200 | <ghais> | hackage build report is here: https://hackage.haskell.org/package/HQu-0.0.0.4/reports/2 |
| 2021-07-09 22:20:44 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 255 seconds) |
| 2021-07-09 22:21:48 +0200 | chomwitt | (~Pitsikoko@ppp-94-67-202-202.home.otenet.gr) |
| 2021-07-09 22:22:19 +0200 | zes | (~zes@p2003000631de7b35c9a03d4c214f06a5.dip0.t-ipconnect.de) |
| 2021-07-09 22:23:04 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 22:23:09 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-09 22:24:32 +0200 | bontaq | (~user@ool-18e47f8d.dyn.optonline.net) (Remote host closed the connection) |
| 2021-07-09 22:26:32 +0200 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 252 seconds) |
| 2021-07-09 22:27:12 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2021-07-09 22:28:01 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-09 22:28:04 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) |
| 2021-07-09 22:30:03 +0200 | Hanicef | (~gustaf@81-229-9-108-no92.tbcn.telia.com) |
| 2021-07-09 22:30:31 +0200 | <sclv> | ghais: please stop uploading to hackage to make your package build! |
| 2021-07-09 22:30:40 +0200 | <sclv> | it has been abusive to the servers |
| 2021-07-09 22:30:49 +0200 | <ghais> | sclv: My bad |
| 2021-07-09 22:30:53 +0200 | <ghais> | I will stop |
| 2021-07-09 22:30:55 +0200 | ubert | (~Thunderbi@p2e5a50e5.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2021-07-09 22:31:09 +0200 | <sclv> | the buildbox lacks many libs, its fine if it doesn’t build |
| 2021-07-09 22:31:28 +0200 | <sclv> | uploading the docs manually as you have done is fine |
| 2021-07-09 22:31:53 +0200 | <ghais> | I understand that, however if i want to add it to stackage, it seems that there is a requirement that it builds on hackage first |
| 2021-07-09 22:31:54 +0200 | <sclv> | the backstory is we moved servers at some point and the old one had more libs |
| 2021-07-09 22:32:08 +0200 | <sclv> | that shouldn’t be a stackage requirement? |
| 2021-07-09 22:32:33 +0200 | <ghais> | https://github.com/commercialhaskell/stackage/blob/master/MAINTAINERS.md#adding-a-package |
| 2021-07-09 22:32:38 +0200 | <sclv> | i did notice you repeatedly attempting to upload and installed the libgsl stuff on the buildbox |
| 2021-07-09 22:32:38 +0200 | turlando | (~turlando@user/turlando) (Read error: Connection reset by peer) |
| 2021-07-09 22:33:27 +0200 | <ghais> | again, i apologize. Maybe i misread the requirements from stackage |
| 2021-07-09 22:33:39 +0200 | <sclv> | if you want libs installed there’s a hackage ticket you can comment on in the future as well, and also you can edit metadata and force rebuilds from the maintainer corner without a new upload |
| 2021-07-09 22:33:54 +0200 | <sclv> | no big deal, just glad i could communicate to you about this! :-) |
| 2021-07-09 22:34:16 +0200 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2021-07-09 22:34:17 +0200 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2021-07-09 22:34:17 +0200 | turlando | (~turlando@user/turlando) |
| 2021-07-09 22:34:25 +0200 | <sclv> | If it does turn out its a stackage req, do let me know. Id be surprised |
| 2021-07-09 22:34:56 +0200 | <sclv> | I suspect they mean it needs to be on hackage and needs to be buildable, not that hackage itself needs to be able to build it :-) |
| 2021-07-09 22:35:00 +0200 | <ghais> | I might be misunderstanding this statement from their documentation: The package is buildable and testable from Hackage |
| 2021-07-09 22:35:12 +0200 | <ghais> | I understood this to mean that it must build successfully on hackage |
| 2021-07-09 22:35:22 +0200 | <ghais> | Yeah, good point |
| 2021-07-09 22:35:42 +0200 | <sclv> | the “from” means just that its on there i think.. |
| 2021-07-09 22:36:27 +0200 | <ghais> | thanks. I will just upload the documentation manually then |
| 2021-07-09 22:38:31 +0200 | jumper149 | (~jumper149@80.240.31.34) |
| 2021-07-09 22:38:59 +0200 | oxide | (~lambda@user/oxide) (Quit: oxide) |
| 2021-07-09 22:39:02 +0200 | <sclv> | releases are permanent so ideally should not be too frequent |
| 2021-07-09 22:42:51 +0200 | TheRAt | (~TheRAt@user/therat) (Ping timeout: 258 seconds) |
| 2021-07-09 22:44:32 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.0.1) |
| 2021-07-09 22:45:08 +0200 | TheRAt | (~TheRAt@user/therat) |
| 2021-07-09 22:45:30 +0200 | <ghais> | That part i understood, but i couldn't connect the dots to why other libraries with similar dependency successfully, and i assumed it was my issue. As a new comer to Haskell some of this knowledge is not easy to glue together, and documentation around the interaction between stack/cabal/build servers/hackage/stackage has been particular difficult |
| 2021-07-09 22:45:30 +0200 | <ghais> | to glue together |
| 2021-07-09 22:46:00 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 22:46:10 +0200 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:39f3:da:7ab8:bc1e) |
| 2021-07-09 22:47:53 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 22:48:06 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-07-09 22:49:10 +0200 | <sclv> | sure, understood. any specific suggestions of how to improve docs welcome! |
| 2021-07-09 22:50:32 +0200 | warnz | (~warnz@2600:1700:77c0:5610:edd9:472d:4b89:9ab8) |
| 2021-07-09 22:50:51 +0200 | <ghais> | one none obvious thing i noticed is that to upload the documentation manually you have to have a specific directory name, and you need to tar but not gzip, and the tar needs to be done with a --format=ustar instead of the default format. I think adding this to the manual documentation upload page would have saved me a lot of time |
| 2021-07-09 22:52:03 +0200 | <sm> | good info |
| 2021-07-09 22:52:04 +0200 | <ghais> | another item that would be very useful is to understand the build process on hackage. It was only through my abusive trial and error that i leared that the build plan is dependent on the base library i specify in my cabal file |
| 2021-07-09 22:52:32 +0200 | <ghais> | It seems that the base library constraints selects which versions of GHC will be used |
| 2021-07-09 22:53:06 +0200 | <sm> | correct, GHC and base are locked together |
| 2021-07-09 22:53:16 +0200 | <davean> | but it deosn't select which ghc is used |
| 2021-07-09 22:53:34 +0200 | Lycurgus | (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-07-09 22:53:38 +0200 | <davean> | the direction is the other, you just can't find a build plan if you aren't compatible with that GHC's base |
| 2021-07-09 22:53:53 +0200 | <sm> | s/locked/semi-locked/ |
| 2021-07-09 22:54:37 +0200 | <ghais> | I understand this distinction, but look at it from the prespective of someone who started with "stack new projectX" |
| 2021-07-09 22:55:12 +0200 | <sm> | ghais: you're not wrong.. we know.. :/ |
| 2021-07-09 22:55:16 +0200 | <davean> | Yah, you'd have to talk to stack folk for their documentation, not sure any of them are around here? |
| 2021-07-09 22:55:23 +0200 | <ghais> | a base constraint is specified in the cabal file. A specific version of GHC is selected through which resolver you use, and then i start using some features |
| 2021-07-09 22:55:25 +0200 | <davean> | ghc documents this for sure |
| 2021-07-09 22:55:50 +0200 | <ghais> | No sorry, i was writing a multi line statement. I was trying to say that there is a disconnect between the tools |
| 2021-07-09 22:56:26 +0200 | <davean> | ghais: hum, can you explain? different tools do different things, so I might be confused here |
| 2021-07-09 22:56:59 +0200 | <davean> | (base being tied to GHC is a GHC-ism specificly) |
| 2021-07-09 22:57:08 +0200 | <ghais> | davean, i was trying to relay my experience as a new comer, and why it is not trivial to connect all the pieces together without a little bit of abuse |
| 2021-07-09 22:57:40 +0200 | acidjnk_new | (~acidjnk@p200300d0c72b9550509afe7c5cdd8ef5.dip0.t-ipconnect.de) |
| 2021-07-09 22:57:45 +0200 | <davean> | ghais: right, and I'm trying to figure out what you're saying specificly |
| 2021-07-09 22:58:00 +0200 | <ghais> | davean, yeah this is clear to me and makes sense. What i didnt realize is that stack on the other hand created a config for me that had more base versions than the one the resolver supported. |
| 2021-07-09 22:58:06 +0200 | <davean> | I think part of the confusion is "the way things are" vs "the way things can be" |
| 2021-07-09 22:58:12 +0200 | <sm> | I think the general point is obviously correct |
| 2021-07-09 22:58:15 +0200 | <sm> | ghais it's a well known problem. It's hard to change, and hard (costly) even to document |
| 2021-07-09 22:58:16 +0200 | <davean> | Ah, yes, I see |
| 2021-07-09 22:58:36 +0200 | <sclv> | so the command here for doc creation/upload is incorrect? https://hackage.haskell.org/upload |
| 2021-07-09 22:58:41 +0200 | <davean> | ghais: I didn't realize it would create an open base bound - do you happen to have which bound it used? |
| 2021-07-09 22:59:03 +0200 | <ghais> | sclv, gzip didn't work for me |
| 2021-07-09 22:59:23 +0200 | <sclv> | or ah we don’t show the command on the doc upload pge? |
| 2021-07-09 22:59:26 +0200 | <sclv> | hrm |
| 2021-07-09 22:59:44 +0200 | <ghais> | on the doc upload page there are no instructions |
| 2021-07-09 23:00:00 +0200 | <sclv> | right so we should put those there, assuming they work! |
| 2021-07-09 23:00:10 +0200 | <ghais> | stack sdist, produces a package that can be immediately uploaded (it is a tar.gz) |
| 2021-07-09 23:00:19 +0200 | <ghais> | however the documentation upload cannot be gzipped it seems |
| 2021-07-09 23:01:14 +0200 | <ghais> | also since i use stack, the command example at the end of the page doesn't work, because my locally installed GHC version is different than the one i needed to build |
| 2021-07-09 23:01:24 +0200 | favonia | (~favonia@user/favonia) (Ping timeout: 252 seconds) |
| 2021-07-09 23:01:57 +0200 | jumper149 | (~jumper149@80.240.31.34) (Quit: WeeChat 3.2) |
| 2021-07-09 23:02:12 +0200 | <davean> | Use stack's ghc then with cabal |
| 2021-07-09 23:02:28 +0200 | favonia | (~favonia@user/favonia) |
| 2021-07-09 23:03:13 +0200 | <ghais> | right, so stack haddock produced a folder. That i had to tar --format=ustar |
| 2021-07-09 23:03:21 +0200 | <ghais> | otherwise i cannot upload the documentation |
| 2021-07-09 23:04:29 +0200 | <ghais> | Sorry if it comes like i am complaining, truth is I am not |
| 2021-07-09 23:04:41 +0200 | <ghais> | just relaying my experience and I am happy to help improve things in any way i can |
| 2021-07-09 23:04:47 +0200 | <davean> | ghais: you can use "-w" to specify which ghc to use with cabal |
| 2021-07-09 23:04:52 +0200 | <davean> | BTW |
| 2021-07-09 23:05:02 +0200 | <ghais> | davean, i didn't know that. I appreciate that |
| 2021-07-09 23:05:38 +0200 | <davean> | I'd still be curious what base bound you ended up with |
| 2021-07-09 23:06:06 +0200 | <ghais> | base >= 4.11.0 && < 5 |
| 2021-07-09 23:06:17 +0200 | <davean> | wow, really? |
| 2021-07-09 23:06:35 +0200 | <davean> | I have no idea the logic behind that |
| 2021-07-09 23:06:54 +0200 | <davean> | I see people do the < 5 thing occasionally, I guess now I know where it comes from! |
| 2021-07-09 23:07:17 +0200 | <monochrom> | dons used "< 10". :) |
| 2021-07-09 23:07:37 +0200 | <davean> | (base often changes with breaking changes in the second digit, as would align with the PVP) |
| 2021-07-09 23:07:48 +0200 | <davean> | (so < 5 is clearly an insane choice) |
| 2021-07-09 23:07:56 +0200 | <ghais> | this comes from stack |
| 2021-07-09 23:08:06 +0200 | <davean> | ghais: sure |
| 2021-07-09 23:08:11 +0200 | <ghais> | if you do a "stack new X" you get: |
| 2021-07-09 23:08:12 +0200 | <ghais> | build-depends: |
| 2021-07-09 23:08:12 +0200 | <ghais> | base >=4.7 && <5 |
| 2021-07-09 23:08:17 +0200 | <davean> | I think I directly ackowleged it came from stack? |
| 2021-07-09 23:08:26 +0200 | <davean> | "21:06:53 davean I see people do the < 5 thing occasionally, I guess now I know where it comes from!" |
| 2021-07-09 23:08:55 +0200 | <ghais> | davean, i am not very good with implicit hints |
| 2021-07-09 23:08:58 +0200 | <ghais> | :D |
| 2021-07-09 23:09:11 +0200 | <monochrom> | "< 5" is or is not insane depending on how much of base you actually use. |
| 2021-07-09 23:09:20 +0200 | <sm> | it predates stack for sure |
| 2021-07-09 23:09:25 +0200 | <davean> | monochrom: I mean, prelude has broken that a lot |
| 2021-07-09 23:09:38 +0200 | <davean> | monochrom: You'd have to use almost no part of base for that to not have broken you in the last few years |
| 2021-07-09 23:09:53 +0200 | <sm> | it's an idiom that looks familiar and is simple, so it has stuck |
| 2021-07-09 23:10:15 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) |
| 2021-07-09 23:10:35 +0200 | <davean> | sm: Hum, wouldn't it be more sensible to but no upper bound? |
| 2021-07-09 23:10:37 +0200 | <monochrom> | base is so large that you can use only 0.1% of it, and if you do, the probability that a difference between 4.11 and 4.12 actually affects you is 0.1%. At this rate one wouldn't care. |
| 2021-07-09 23:10:57 +0200 | <sm> | perhaps back then base made larger version number jumps |
| 2021-07-09 23:11:08 +0200 | <davean> | monochrom: I mean the core type classes change - what you say is correct, but people reliably use the same 0.1% and thats where changes happen |
| 2021-07-09 23:11:43 +0200 | <davean> | (Probably because people use them?) |
| 2021-07-09 23:12:02 +0200 | <davean> | sm: hum, it predates stack? Interesting |
| 2021-07-09 23:12:17 +0200 | <sclv> | hackage requires a base upper bound to upload |
| 2021-07-09 23:12:34 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:af88:6c9:cc87:d82a) (Ping timeout: 240 seconds) |
| 2021-07-09 23:12:57 +0200 | <sclv> | stack devs don’t like bounds, so they put in a useless bound to check the box, sigh |
| 2021-07-09 23:13:09 +0200 | <davean> | It seems better to have no bound than a clearly wrong bound |
| 2021-07-09 23:13:16 +0200 | <sm> | I'm sure you are being uncharitable there |
| 2021-07-09 23:13:18 +0200 | <davean> | Is there a hacakge ticket about this? |
| 2021-07-09 23:13:29 +0200 | <davean> | sm: which part? |
| 2021-07-09 23:13:35 +0200 | <sm> | (sclv) |
| 2021-07-09 23:13:57 +0200 | <monochrom> | A natural tug war may actually cancel out "it gets used more therefore it gets improved more" with "it gets used more therefore it dares not break backward compatibility". |
| 2021-07-09 23:14:16 +0200 | <davean> | monochrom: I mean look at the change log |
| 2021-07-09 23:15:08 +0200 | yauhsien | (~yauhsien@61-231-39-135.dynamic-ip.hinet.net) (Ping timeout: 265 seconds) |
| 2021-07-09 23:15:57 +0200 | <davean> | monochrom: "Ix" stands out as being a bit unusual. I've wanted to use it but its got problems. So I'm unsure about its use rate |
| 2021-07-09 23:16:58 +0200 | norias | (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Quit: Leaving) |
| 2021-07-09 23:17:08 +0200 | <davean> | sm: I know there were first step bumps for some historic major rearrangements |
| 2021-07-09 23:17:40 +0200 | <monochrom> | Right, 3.x existed. |
| 2021-07-09 23:18:38 +0200 | <monochrom> | But 3.x may be before PVP, I forgot. |
| 2021-07-09 23:19:08 +0200 | <davean> | 4.0 was Nov 2008 |
| 2021-07-09 23:20:38 +0200 | <davean> | So well after PVP |
| 2021-07-09 23:22:23 +0200 | cuz | (~user@38.140.58.234) (Ping timeout: 255 seconds) |
| 2021-07-09 23:24:18 +0200 | yauhsien | (~yauhsien@118-167-64-241.dynamic-ip.hinet.net) |
| 2021-07-09 23:25:47 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-09 23:26:02 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-09 23:26:35 +0200 | <davean> | sclv: why does hackage have that base requirement? |
| 2021-07-09 23:27:06 +0200 | <davean> | Its unique vs. other packages |
| 2021-07-09 23:27:14 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) |
| 2021-07-09 23:27:29 +0200 | <sclv> | because base induced breakages were the most frequent iirc |
| 2021-07-09 23:27:59 +0200 | <monochrom> | Yikes, that contradicts my theory, heh. |
| 2021-07-09 23:28:18 +0200 | <davean> | It matches my experience updating packages I depend on |
| 2021-07-09 23:28:33 +0200 | <davean> | but, it doesn't make sense to make a more complicated, asymetric system because of that! |
| 2021-07-09 23:28:54 +0200 | yauhsien | (~yauhsien@118-167-64-241.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2021-07-09 23:29:09 +0200 | fizbin | (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Remote host closed the connection) |
| 2021-07-09 23:29:12 +0200 | <maerwald> | it violates PVP |
| 2021-07-09 23:29:25 +0200 | <monochrom> | But I have now taken a look at the 4.15.0.0 changelog and the 4.14.0.0 changelog. For me, they don't break my code. Perhaps they are even strictly improvements to my code too, without needing me to change my code. |
| 2021-07-09 23:29:26 +0200 | <davean> | maerwald: base does? |
| 2021-07-09 23:29:26 +0200 | <maerwald> | PVP doesn't demand an upper bound |
| 2021-07-09 23:29:39 +0200 | <davean> | maerwald: yes |
| 2021-07-09 23:29:46 +0200 | <maerwald> | from a spec perspective, it's arbitrary |
| 2021-07-09 23:29:56 +0200 | <ghais> | what is PVP? |
| 2021-07-09 23:29:58 +0200 | <davean> | So who made the decision to enforce it on hackage and why? |
| 2021-07-09 23:30:10 +0200 | <davean> | ghais: Package Version Policy - its what definates the meaning of the parts of the version field |
| 2021-07-09 23:30:17 +0200 | <davean> | https://pvp.haskell.org/ |
| 2021-07-09 23:30:19 +0200 | <ghais> | thank you! |
| 2021-07-09 23:30:20 +0200 | <monochrom> | I acknowledge YMMV very much in this case. But I would be making a safe bet if I used "< 5" or "< 4.20" or something. |
| 2021-07-09 23:30:39 +0200 | <Clint> | i always do "< 5" |
| 2021-07-09 23:31:01 +0200 | fluffyballoon | (~fluffybal@pat-verona-i.epic.com) (Quit: Client closed) |
| 2021-07-09 23:31:37 +0200 | fluffyballoon | (~fluffybal@pat-verona-i.epic.com) |
| 2021-07-09 23:32:28 +0200 | <monochrom> | I do acknowledge that once in a while I would be burned. For example at the transition point of the functor-applicative-monad proposal. But this would be a once-in-a-decade event for my kind of code. |
| 2021-07-09 23:33:33 +0200 | <monochrom> | And in 5-10 years the monad-of-no-return proposal. |
| 2021-07-09 23:33:57 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) (Remote host closed the connection) |
| 2021-07-09 23:34:02 +0200 | <monochrom> | (Even that one doesn't have a 100% chance of breaking everyone's code.) |
| 2021-07-09 23:34:42 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a1-224.dhcp.inet.fi) |
| 2021-07-09 23:34:54 +0200 | <monochrom> | On the other side, I'm also too lazy to relax a tight bound when cabal init auto-defaults to a tight bound, so there! |
| 2021-07-09 23:35:08 +0200 | <davean> | monochrom: thats very lazy :-p |
| 2021-07-09 23:36:03 +0200 | MQ-17J | (~MQ-17J@8.21.10.15) (Ping timeout: 252 seconds) |
| 2021-07-09 23:36:18 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-09 23:37:58 +0200 | <sm> | tightness of upper bounds has always been a situation-dependent trade-off between annoying users and maintainers with unnecessary bound failures and annoying them with build errors |
| 2021-07-09 23:38:07 +0200 | beka | (~beka@104.193.170-244.PUBLIC.monkeybrains.net) |
| 2021-07-09 23:39:26 +0200 | zes | (~zes@p2003000631de7b35c9a03d4c214f06a5.dip0.t-ipconnect.de) (Quit: zes) |
| 2021-07-09 23:40:46 +0200 | <hpc> | maybe being able to promise something's compatibility ahead of time would help? |
| 2021-07-09 23:40:48 +0200 | <davean> | sm: you left correctness out entirely there |
| 2021-07-09 23:41:15 +0200 | <hpc> | if i am writing a package, being able to say "this definition will behave the same way you expect for the next few major versions" could help consumers of that package |
| 2021-07-09 23:42:10 +0200 | <hpc> | and breaking that promise would be a first-digit change, or something like that |
| 2021-07-09 23:42:43 +0200 | <davean> | hpc: thats ... not an insane thing to do for some packages, put the high level semantic API on the first digit? |
| 2021-07-09 23:42:58 +0200 | <davean> | Detail oriented functions on the second |
| 2021-07-09 23:43:17 +0200 | <hpc> | it gives that digit a reason to be there, being just to be longer than semver |
| 2021-07-09 23:43:21 +0200 | <hpc> | *besides |
| 2021-07-09 23:43:43 +0200 | <davean> | hpc: haha, I mean semver wasn't a thing when it came into existance :) |
| 2021-07-09 23:43:55 +0200 | <hpc> | yeah, just being cheeky |
| 2021-07-09 23:44:04 +0200 | <hpc> | afaik there's no documented difference between the first two digits |
| 2021-07-09 23:44:10 +0200 | mikoto-chan | (~mikoto-ch@ip-213-49-189-31.dsl.scarlet.be) (Ping timeout: 240 seconds) |
| 2021-07-09 23:44:33 +0200 | jneira_ | (~jneira_@28.red-80-28-169.staticip.rima-tde.net) |
| 2021-07-09 23:44:50 +0200 | viluon | (uid453725@id-453725.brockwell.irccloud.com) |
| 2021-07-09 23:44:51 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) (Ping timeout: 252 seconds) |
| 2021-07-09 23:45:18 +0200 | <davean> | Correct |
| 2021-07-09 23:45:28 +0200 | <dsal> | I like the freedom of the first digit. |
| 2021-07-09 23:45:28 +0200 | <davean> | they're up to the library, other than that they are a major change |
| 2021-07-09 23:46:29 +0200 | MQ-17J | (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-09 23:46:52 +0200 | fendor | (~fendor@77.119.197.100.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-07-09 23:47:53 +0200 | slice | (~slice@user/slice) |
| 2021-07-09 23:51:49 +0200 | Kaipi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) |
| 2021-07-09 23:52:14 +0200 | Kaiepi | (~Kaiepi@nwcsnbsc03w-47-54-173-93.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection) |
| 2021-07-09 23:54:19 +0200 | fluffyballoon | (~fluffybal@pat-verona-i.epic.com) (Ping timeout: 246 seconds) |
| 2021-07-09 23:54:36 +0200 | Atum_ | (~IRC@user/atum/x-2392232) (Read error: Connection reset by peer) |
| 2021-07-09 23:56:35 +0200 | slice | (~slice@user/slice) (Quit: zzz) |
| 2021-07-09 23:57:14 +0200 | slice | (~slice@user/slice) |
| 2021-07-09 23:57:25 +0200 | slice | (~slice@user/slice) (Client Quit) |
