IRCBrowse

2023/06/07

2023-06-07 00:00:33 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-06-07 00:00:53 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 00:03:18 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-06-07 00:05:45 +0200jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Quit: Textual IRC Client: www.textualapp.com)
2023-06-07 00:08:25 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds)
2023-06-07 00:11:41 +0200DustinStiles[m](~duwstiles@2001:470:69fc:105::3:699b)
2023-06-07 00:18:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 00:19:01 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-06-07 00:20:26 +0200chromoblob(~user@37.113.158.8)
2023-06-07 00:20:54 +0200cheater(~Username@user/cheater) (Read error: Connection reset by peer)
2023-06-07 00:20:56 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 00:21:31 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 00:23:31 +0200acidjnk(~acidjnk@p200300d6e7072f266d84e9375f346e43.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-06-07 00:24:32 +0200cheater(~Username@user/cheater)
2023-06-07 00:28:13 +0200cheater_(~Username@user/cheater)
2023-06-07 00:28:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 00:30:48 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-06-07 00:30:49 +0200cheater_cheater
2023-06-07 00:31:28 +0200mmhat(~mmh@p200300f1c7066881ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-06-07 00:31:50 +0200mmhat(~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de)
2023-06-07 00:35:30 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 00:36:37 +0200shinjipf4(~shinjipf@137.184.4.49)
2023-06-07 00:36:58 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection)
2023-06-07 00:37:18 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net)
2023-06-07 00:37:22 +0200shinjipf(~shinjipf@137.184.4.49) (Read error: Connection reset by peer)
2023-06-07 00:37:22 +0200shinjipf4shinjipf
2023-06-07 00:37:53 +0200elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Ping timeout: 256 seconds)
2023-06-07 00:40:00 +0200zeenk(~zeenk@2a02:2f04:a106:3c00::7fe) (Quit: Konversation terminated!)
2023-06-07 00:41:13 +0200elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru)
2023-06-07 00:42:49 +0200d34df00d(~d34df00d@2600:1702:4f1b:7c10::e)
2023-06-07 00:42:51 +0200 <d34df00d> Hi!
2023-06-07 00:43:01 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-06-07 00:43:06 +0200ec_(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-06-07 00:43:11 +0200 <d34df00d> It's more of a tooling question, but is it possible to have a version of ghc (as managed by ghcup) local to a project?
2023-06-07 00:43:19 +0200ddellacosta(~ddellacos@143.244.47.100)
2023-06-07 00:43:30 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 00:43:37 +0200 <d34df00d> I have a cabal project that builds successfully after `ghcup set 8.10`, say, but I don't want to have ghc 8.10 as the global default.
2023-06-07 00:44:01 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-06-07 00:44:30 +0200 <DustinStiles[m]> I'm a noob, so take my answer with a grain of salt, but I know that you can do this in stack, either by setting the ghc version in the new command, or by telling stack to depend on whatever ghcup is using.
2023-06-07 00:44:48 +0200 <DustinStiles[m]> Unfortunately I'm not as familiar with cabal proper 😶
2023-06-07 00:44:55 +0200 <yushyin> d34df00d: see the with-compiler option for cabal.project
2023-06-07 00:45:01 +0200 <d34df00d> Yep, writing a simple stack.yaml that sets resolver to the right ghc version is my fallback.
2023-06-07 00:46:19 +0200 <ddellacosta> you can also do this with nix pretty easily, but, then you are getting involved with nix https://serokell.io/blog/practical-nix-flakes#potential-modifications-and-troubleshooting
2023-06-07 00:46:21 +0200 <yushyin> ghcup has symlinks to versioned filenames for every compilerversion, you can use that with `with-compiler'
2023-06-07 00:46:36 +0200 <d34df00d> yushyin: that seems right what I need! Just curious, can I do that in cabal.project.local? Other folks building this project might have slightly different ghc versions they prefer, so I don't want to force my choices on anybody else.
2023-06-07 00:47:50 +0200 <yushyin> i guess? you'll have to try it out ^^
2023-06-07 00:47:57 +0200 <glguy> Yes, it goes into the cabal.project.local; you can make that file with: cabal configure -w ghc-X.y.z
2023-06-07 00:48:25 +0200 <yushyin> ^ there you go ;)
2023-06-07 00:48:42 +0200 <d34df00d> Also, I'm fairly new to ghcup stuff, so how do I get the right hls version that works with this ghc version? Or do I just ghcup install hls and it does the rest for all ghc versions installed?
2023-06-07 00:48:47 +0200 <d34df00d> glguy: yay nice!
2023-06-07 00:48:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 00:49:01 +0200 <glguy> ghcup tui will show you which GHC's have HLS support
2023-06-07 00:49:13 +0200 <glguy> so once you install hls, those are the versions that will be supported
2023-06-07 00:49:23 +0200 <glguy> installing hls installs support for all the supported versions at once
2023-06-07 00:49:38 +0200 <d34df00d> Nice, that's much easier than building hls manually.
2023-06-07 00:49:40 +0200 <yushyin> and hls has a wrapper binary that selects the correct versioned hls binary
2023-06-07 00:51:23 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 00:54:56 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds)
2023-06-07 00:58:08 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 00:58:17 +0200nckx(~nckx@tobias.gr) (Ping timeout: 256 seconds)
2023-06-07 00:58:41 +0200 <eugenrh> Ok, so now, after more studying, I think I understand the folding on infinite lists. First, foldl never works on them, since it calls itself recursively -- no matter what -- for each element in the list:
2023-06-07 00:58:58 +0200 <eugenrh> @src foldl
2023-06-07 00:58:58 +0200 <lambdabot> foldl f z [] = z
2023-06-07 00:58:58 +0200 <lambdabot> foldl f z (x:xs) = foldl f (f z x) xs
2023-06-07 00:59:25 +0200 <eugenrh> By contrast, foldr calls the folding function f:
2023-06-07 00:59:45 +0200 <eugenrh> @src foldr
2023-06-07 00:59:45 +0200 <lambdabot> foldr f z [] = z
2023-06-07 00:59:45 +0200 <lambdabot> foldr f z (x:xs) = f x (foldr f z xs)
2023-06-07 01:00:13 +0200 <eugenrh> Here, the recursion happens *only* when that 2nd argument of f needs to be evaluated. So, we can implement the function f (\x z -> ...) in such a way that, at some point, we stop refering to the accumulator z -- "short-circuting", like this:
2023-06-07 01:00:33 +0200mei(~mei@user/mei)
2023-06-07 01:00:37 +0200nckx(~nckx@tobias.gr)
2023-06-07 01:00:43 +0200 <eugenrh> > foldr (\x z -> if mod x 10==0 then 0 else ( x `mod` 10)*z) undefined [1..]
2023-06-07 01:00:44 +0200 <lambdabot> 0
2023-06-07 01:01:12 +0200 <eugenrh> ^ Example adopted from https://wiki.haskell.org/Foldr_Foldl_Foldl' where it also suggests using 'undefined' as initial value when working only with infinite lists.
2023-06-07 01:01:40 +0200 <eugenrh> Thanks everybody for the previous disscusion and help!
2023-06-07 01:02:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 01:05:53 +0200michalz(~michalz@185.246.207.197) (Remote host closed the connection)
2023-06-07 01:06:33 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 01:10:24 +0200mauke_(~mauke@user/mauke)
2023-06-07 01:11:17 +0200abrantesasf(~abrantesa@177.137.232.92)
2023-06-07 01:12:00 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 01:12:08 +0200mauke(~mauke@user/mauke) (Ping timeout: 268 seconds)
2023-06-07 01:12:08 +0200mauke_mauke
2023-06-07 01:19:48 +0200mei(~mei@user/mei)
2023-06-07 01:20:53 +0200zxrom(~zxrom@mm-163-23-212-37.vitebsk.dynamic.pppoe.byfly.by) (Remote host closed the connection)
2023-06-07 01:21:17 +0200zxrom(~zxrom@mm-163-23-212-37.vitebsk.dynamic.pppoe.byfly.by)
2023-06-07 01:23:45 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-07 01:24:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 01:24:27 +0200gabiruh(~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in)
2023-06-07 01:25:09 +0200gabiruh(~gabiruh@191.252.222.55)
2023-06-07 01:25:39 +0200 <juri_> hmm. where's the quickcheck maintainer? i'd like to punch them in the face, and then buy them a beer.
2023-06-07 01:26:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 01:26:16 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-06-07 01:27:07 +0200 <sm> lol
2023-06-07 01:27:18 +0200AlexNoo_AlexNoo
2023-06-07 01:28:15 +0200 <geekosaur> @remember juri_ <juri_> hmm. where's the quickcheck maintainer? i'd like to punch them in the face, and then buy them a beer.
2023-06-07 01:28:15 +0200 <lambdabot> Done.
2023-06-07 01:30:12 +0200 <juri_> quickcheck got a lot better at feeding my program values that break everything (on a minor release, bad!). so i just spent the last week fixing up property tests, and have actually found a bug in my engine, that was hiding behing all of the flakiness.
2023-06-07 01:30:38 +0200 <sm> awesome
2023-06-07 01:30:49 +0200 <sm> maybe the violence is not justified after all
2023-06-07 01:31:14 +0200 <juri_> major change on a minor release.. boo. :)
2023-06-07 01:31:36 +0200 <sm> ah.. unfortunate
2023-06-07 01:32:06 +0200 <juri_> still, good job. poked holes in all kinds of thing. i had to learn new math, just to make my tests green.
2023-06-07 01:32:16 +0200jmd_(~jmdaemon@user/jmdaemon)
2023-06-07 01:35:01 +0200 <hpc> if that counts as a breaking change, i don't know what to think anymore :P
2023-06-07 01:35:53 +0200oo_miguel(~Thunderbi@77.252.47.84) (Ping timeout: 246 seconds)
2023-06-07 01:37:10 +0200 <sm> generating harder tests, for a test generator .. sounds a bit breakingish ?
2023-06-07 01:37:26 +0200 <sm> maybe not breaking, but not minor either
2023-06-07 01:39:10 +0200 <hpc> it doesn't make you change your test suite though, which is arguably the user of that api here
2023-06-07 01:39:17 +0200 <hpc> it just makes the runtime behavior better :D
2023-06-07 01:46:36 +0200 <sm> ...QuickCheck maintainer looks for an exit while drunken devs continue their loud debate ... :)
2023-06-07 01:51:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 01:52:07 +0200freeside(~mengwong@103.252.202.189)
2023-06-07 01:53:02 +0200nate2(~nate@98.45.169.16)
2023-06-07 01:54:54 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 01:56:28 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 240 seconds)
2023-06-07 01:57:00 +0200Square(~Square@user/square)
2023-06-07 01:57:28 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-06-07 01:58:07 +0200forell(~forell@user/forell) (Ping timeout: 240 seconds)
2023-06-07 02:01:38 +0200 <juri_> "drawn, quartered, or given many beers"?
2023-06-07 02:02:33 +0200 <juri_> this showed up as "CI is busted, no-one can merge anything"
2023-06-07 02:03:27 +0200forell(~forell@user/forell)
2023-06-07 02:03:46 +0200 <juri_> so, good job, enjoy the assassination squad at zurihac.
2023-06-07 02:06:53 +0200byte(~byte@user/byte) (Remote host closed the connection)
2023-06-07 02:07:42 +0200 <geekosaur> I think the assassination squad is reserved for the cryptonite -> crypton mess
2023-06-07 02:07:43 +0200byte(~byte@user/byte)
2023-06-07 02:11:11 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 02:13:36 +0200mei(~mei@user/mei)
2023-06-07 02:17:01 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 02:18:36 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 02:19:45 +0200forell(~forell@user/forell) (Ping timeout: 240 seconds)
2023-06-07 02:21:38 +0200 <Axman6> the what???
2023-06-07 02:22:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 02:23:17 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 256 seconds)
2023-06-07 02:24:16 +0200paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Read error: Connection reset by peer)
2023-06-07 02:24:48 +0200 <Axman6> argh, why does that exist? I feel I missed some drama (not looking for the drama, just want to know why this is a thing now)
2023-06-07 02:25:36 +0200forell(~forell@user/forell)
2023-06-07 02:25:42 +0200 <Axman6> "Crypton is a fork from cryptonite with the original authoer's permission." I guess the haskell-crypto fork is without permission?
2023-06-07 02:26:01 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 02:27:21 +0200jmd_(~jmdaemon@user/jmdaemon) (Ping timeout: 250 seconds)
2023-06-07 02:28:08 +0200Me-me(~me-me@2602:ff16:3:0:1:dc:beef:d00d) (Changing host)
2023-06-07 02:28:08 +0200Me-me(~me-me@user/me-me)
2023-06-07 02:29:52 +0200 <glguy> Isn't the haskell-crypto one just the official repo?
2023-06-07 02:29:58 +0200 <glguy> (linked from https://hackage.haskell.org/package/cryptonite)
2023-06-07 02:30:53 +0200 <Axman6> it was started after the original author stopped responding or accepting any contrbutions, so it was forked and replaced. I don't think Vincent was very happy with that, but too much of hackage relies on cryptonite for it to go unmaintained
2023-06-07 02:30:56 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 248 seconds)
2023-06-07 02:32:15 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-06-07 02:32:36 +0200user____3(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-06-07 02:32:36 +0200 <segfaultfizzbuzz> wow i didn't realize that the paper which coined the term "memoization" was a nature publication: https://www.cs.utexas.edu/users/hunt/research/hash-cons/hash-cons-papers/michie-memo-nature-1968.pdf
2023-06-07 02:33:02 +0200 <segfaultfizzbuzz> i am doing some searches for *compressed* memoization and nothing is turning up... has stuff been written about such a thing?
2023-06-07 02:33:22 +0200 <Axman6> compressed in which sense?
2023-06-07 02:33:54 +0200ijqq(uid603979@id-603979.helmsley.irccloud.com) (Quit: Connection closed for inactivity)
2023-06-07 02:34:02 +0200mvk(~mvk@2607:fea8:5c9a:a600::94ca)
2023-06-07 02:34:03 +0200 <segfaultfizzbuzz> well when memoization occurs i assume there is some kind of hash table which mutates and stores the function input-output mapping?
2023-06-07 02:34:33 +0200 <Axman6> that very much depends on the types of the arguments
2023-06-07 02:34:42 +0200 <segfaultfizzbuzz> and ordinarily i would suppose that table would be uncompressed,... so i am wondering whether people have looked at some mechanism for compressing the table itself
2023-06-07 02:35:07 +0200 <Axman6> using hash-tables is one implementation, but it's not sensible to do tat for many types, or there are more efficient implementations
2023-06-07 02:35:12 +0200mvk(~mvk@2607:fea8:5c9a:a600::94ca) (Client Quit)
2023-06-07 02:36:27 +0200 <segfaultfizzbuzz> put another way i suppose would be that typically the storage requirement would grow linearly with the number of distinct function arguments which are encountered, and so one would expect that there could be a rather deeply sublinear method
2023-06-07 02:36:36 +0200 <segfaultfizzbuzz> like maybe more like O(log(N)) or something
2023-06-07 02:36:37 +0200forell(~forell@user/forell) (Ping timeout: 240 seconds)
2023-06-07 02:36:44 +0200mvk(~mvk@2607:fea8:5c9a:a600::94ca)
2023-06-07 02:37:55 +0200 <Axman6> you should go look at the MemoTrie package (and I'm sure there's an associated paper)
2023-06-07 02:38:10 +0200extor(~extor@ns3018124.ip-149-202-82.eu)
2023-06-07 02:38:22 +0200 <segfaultfizzbuzz> cool i will check it out
2023-06-07 02:38:34 +0200 <Axman6> using a hashtable for Bool doesn't make any sense, a fiunction Bool -> a can be represented as (a,a)
2023-06-07 02:38:57 +0200 <segfaultfizzbuzz> well that's a somewhat pathological example
2023-06-07 02:39:10 +0200mvk(~mvk@2607:fea8:5c9a:a600::94ca) (Client Quit)
2023-06-07 02:39:33 +0200 <segfaultfizzbuzz> wow MemoTrie was last maintained in 2019 though
2023-06-07 02:40:05 +0200 <Axman6> not really relevant for a fundamental idea
2023-06-07 02:40:19 +0200 <segfaultfizzbuzz> ok sure if we are talking about this as a concept rather than as software
2023-06-07 02:41:20 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds)
2023-06-07 02:41:28 +0200 <Axman6> you should understand the concept before trying to optimise it :)
2023-06-07 02:42:31 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2023-06-07 02:45:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 02:46:45 +0200 <segfaultfizzbuzz> ok i don't see a mention of a *compressed* trie in this repo,... maybe something in the code makes use of this?
2023-06-07 02:48:44 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 02:50:46 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds)
2023-06-07 02:51:16 +0200 <probie> You can compress your memoization table to 0 bytes by just not memoizing
2023-06-07 02:51:51 +0200 <segfaultfizzbuzz> sigh, mathematics classes can really damage the mind, enroll with caution
2023-06-07 02:53:40 +0200 <probie> What does it have to be compression, why not an LRU cache?
2023-06-07 02:56:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 02:57:03 +0200 <Axman6> segfaultfizzbuzz: you should consider reading Conal's posts on the topic: http://conal.net/blog/tag/trie
2023-06-07 02:59:58 +0200 <Axman6> hashtables are a pretty rare implementation in Haskell, we can take advantage of laziness pretty easily. in the Bool example, you'd have memoBool :: (Bool -> a) -> (Bool -> a); memoBool f = let (a,b) = (f False, f True) in \case False -> a; True -> b. for Word8 you'd use an array of 256 elements pointing to f index, so each evaluation only happens once, and ones which never happen aren't taking up space
2023-06-07 03:01:31 +0200 <Axman6> efficient memoisation depends strongly on the argument types
2023-06-07 03:04:46 +0200 <EvanR> segfaultfizzbuzz, tablemaker's dilemma is... the generally unknown amount of extra precision needed to compute a correctly rounded transcendental function. I've seen claims that libm guarantee sin, cos, are correct in the range -2^64 to +2^64 or so
2023-06-07 03:05:13 +0200 <Axman6> 64 bits should be enough for anyone
2023-06-07 03:05:15 +0200 <EvanR> a tiny part of the range of Double
2023-06-07 03:05:36 +0200 <segfaultfizzbuzz> oh wow hashtables are rare? i didn't realize
2023-06-07 03:05:37 +0200wroathe(~wroathe@207.153.38.140)
2023-06-07 03:05:37 +0200wroathe(~wroathe@207.153.38.140) (Changing host)
2023-06-07 03:05:37 +0200wroathe(~wroathe@user/wroathe)
2023-06-07 03:07:22 +0200 <segfaultfizzbuzz> EvanR: tablemaker's dilemma is the poor man's halting problem? hehe
2023-06-07 03:08:42 +0200 <segfaultfizzbuzz> probie: doesn't *have* to be compression, and yes LRU cache is relevant here,... basically i want to hire all the people working on smart toothbrushes and have them make memoization work better
2023-06-07 03:08:59 +0200 <segfaultfizzbuzz> Smart Memoization (TM)
2023-06-07 03:09:08 +0200 <segfaultfizzbuzz> the first trademarked computer language feature
2023-06-07 03:09:36 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 03:09:57 +0200 <EvanR> https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma
2023-06-07 03:10:43 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-06-07 03:16:51 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-06-07 03:22:11 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 265 seconds)
2023-06-07 03:24:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 03:25:33 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 03:29:59 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2023-06-07 03:31:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 03:32:23 +0200 <segfaultfizzbuzz> what do haskell folks thing of kokalang?
2023-06-07 03:36:55 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 03:37:51 +0200abrantesasf(~abrantesa@177.137.232.92) (Remote host closed the connection)
2023-06-07 03:38:26 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 03:43:11 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds)
2023-06-07 03:44:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 03:45:54 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 03:56:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 03:57:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 03:58:53 +0200xff0x_(~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 265 seconds)
2023-06-07 03:59:25 +0200 <Inst> here's a question, is it worth it
2023-06-07 03:59:38 +0200 <segfaultfizzbuzz> Inst: talking to me?
2023-06-07 03:59:41 +0200 <Inst> to pass huge numbers of variables around instead of using the <- closure
2023-06-07 03:59:49 +0200 <Inst> for monadic code?
2023-06-07 04:00:15 +0200 <Inst> i guess you could use let and implicit params to avoid the performance cost, no?
2023-06-07 04:00:21 +0200 <Inst> the fear is 100-line do blocks
2023-06-07 04:07:39 +0200mmhat(~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8)
2023-06-07 04:09:02 +0200dcoutts(~duncan@212.221.20.36) (Ping timeout: 265 seconds)
2023-06-07 04:12:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 04:14:08 +0200werneta(~werneta@70.142.214.115)
2023-06-07 04:14:50 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 04:15:47 +0200nate2(~nate@98.45.169.16)
2023-06-07 04:20:35 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-06-07 04:20:35 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-06-07 04:20:35 +0200finn_elijaFinnElija
2023-06-07 04:21:31 +0200whatsupdoc(uid509081@id-509081.hampstead.irccloud.com)
2023-06-07 04:21:46 +0200merijn(~merijn@86.86.29.250)
2023-06-07 04:23:17 +0200 <Inst> also, is the a well-known haskell meme?
2023-06-07 04:23:32 +0200 <Inst> https://hackage.haskell.org/package/base-4.18.0.0/docs/src/GHC.Exts.html#the
2023-06-07 04:24:05 +0200forell(~forell@user/forell)
2023-06-07 04:24:39 +0200 <segfaultfizzbuzz> that's a nice function, i like it
2023-06-07 04:25:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 04:26:34 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-06-07 04:29:26 +0200 <sm> why :)
2023-06-07 04:29:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 04:31:20 +0200 <Inst> "segfaultfizzbuzz"
2023-06-07 04:31:30 +0200 <Inst> felt inclined to compare Data.Array to the
2023-06-07 04:31:42 +0200 <Inst> some folk brought it up on Discord
2023-06-07 04:33:48 +0200 <sm> nope the is not a thing people use
2023-06-07 04:34:47 +0200eggplantade(~Eggplanta@104.55.37.220)
2023-06-07 04:37:32 +0200 <Inst> i mean that it's a meme
2023-06-07 04:37:53 +0200 <Inst> "advanced head"
2023-06-07 04:38:16 +0200 <sm> nope not a meme either :)
2023-06-07 04:40:30 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-06-07 04:42:02 +0200 <sm> what did you mean by passing huge numbers or variables Inst ? ie, function arguments instead of using Reader monad ?
2023-06-07 04:46:35 +0200 <Inst> i guess you're talking more readerT IO?
2023-06-07 04:46:45 +0200 <Inst> but straight IO functions are more lightweight
2023-06-07 04:47:40 +0200 <sm> you can always collect parameters in a single type and pass that around
2023-06-07 04:47:42 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-06-07 04:48:04 +0200 <Inst> or just keep them open
2023-06-07 04:48:13 +0200taupiqueur4(~taupiqueu@2a02-842a-8180-4601-fc1a-de08-4257-8549.rev.sfr.net) (Ping timeout: 265 seconds)
2023-06-07 04:49:25 +0200dcoutts(~duncan@212.140.138.201)
2023-06-07 04:51:36 +0200td_(~td@i53870912.versanet.de) (Ping timeout: 265 seconds)
2023-06-07 04:52:00 +0200taupiqueur4(~taupiqueu@2a02-842a-8180-4601-fc1a-de08-4257-8549.rev.sfr.net)
2023-06-07 04:52:59 +0200td_(~td@i5387091A.versanet.de)
2023-06-07 04:55:07 +0200merijn(~merijn@86.86.29.250) (Ping timeout: 250 seconds)
2023-06-07 05:00:41 +0200 <davean> Inst: what do you think is more light weight about IO functions?
2023-06-07 05:01:00 +0200 <Inst> readerT, I'm told, imposes a performance overhead?
2023-06-07 05:01:13 +0200dcoutts_(~duncan@81.145.206.41)
2023-06-07 05:01:23 +0200 <davean> Who tells you that?⎈
2023-06-07 05:01:36 +0200 <davean> And I mean doing anything imposes and overhead
2023-06-07 05:01:58 +0200 <davean> but is it exactly the same one you were proposing as another option? And I don't mean same performance, I mean same implimentation too
2023-06-07 05:03:36 +0200 <Inst> the alternative is straight IO functions that take an argument
2023-06-07 05:03:39 +0200 <davean> You realize that -> is Reader, right? Every function is Reader.
2023-06-07 05:03:42 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Remote host closed the connection)
2023-06-07 05:03:45 +0200dcoutts(~duncan@212.140.138.201) (Ping timeout: 240 seconds)
2023-06-07 05:03:51 +0200 <davean> So are you talking about an alternative here?
2023-06-07 05:04:01 +0200 <Inst> calling ask / asks to get the argument imposes an overhead
2023-06-07 05:04:03 +0200 <davean> Or are you talking about two ways of writing *litterly exactly the same thing*
2023-06-07 05:04:22 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-06-07 05:04:49 +0200 <davean> ask = id
2023-06-07 05:05:23 +0200 <davean> Really? Really? Go compile them - look at the assembly, see *exactly the same instructions*
2023-06-07 05:05:49 +0200 <Inst> so you're implying readerT is free, no?
2023-06-07 05:06:02 +0200 <Inst> asks shouldn't be free, though
2023-06-07 05:06:11 +0200 <davean> Yes, yes they should.
2023-06-07 05:06:32 +0200 <davean> I just showed you hwo
2023-06-07 05:07:04 +0200 <Inst> you're passing a value of a packaging datatype around, then having a function extract the specific data you want from the packaging datatype
2023-06-07 05:07:07 +0200 <davean> And you're not even looking at the only place you can get a difference - the ReaderT wrapper, not Reader, but taht actually DOES reliably eliminate. Reader of (->) doesn't even eliminate, it just is
2023-06-07 05:07:17 +0200 <davean> You are *not* passing it around, thats crazy talk.
2023-06-07 05:07:34 +0200 <davean> No more than a function does.
2023-06-07 05:07:38 +0200 <Inst> okay, more correctly, it's a composition of functions
2023-06-07 05:07:49 +0200 <Inst> ReaderT has a constructor, though, around the function
2023-06-07 05:07:56 +0200 <sm> Inst: I hear you
2023-06-07 05:08:34 +0200 <davean> Note I mentioned that was the part that COULD but it DOES eliminate reliably, but *ask* on (->) can not.
2023-06-07 05:08:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 05:09:01 +0200 <Inst> the other advantage of just directly using IO functions to pass arguments around
2023-06-07 05:09:09 +0200 <Inst> you don't have to go through the readerT apparatus
2023-06-07 05:09:24 +0200 <Inst> just straight, arguments to a function
2023-06-07 05:09:54 +0200 <Inst> data MyPackage might be better structure
2023-06-07 05:10:04 +0200 <davean> newtype r (m :: Type -> Type) a = ReaderT (r -> m a)
2023-06-07 05:10:23 +0200 <Inst> ah
2023-06-07 05:11:16 +0200 <davean> You're looking in the wrong places for performance differences
2023-06-07 05:11:44 +0200 <davean> the thing that *actually* affects things are like potential arity change by you implimenting it differently.
2023-06-07 05:11:57 +0200 <davean> GHC spots "expected" arity and optimizes based on that.
2023-06-07 05:12:13 +0200 <Inst> so the compiler optimizations / rewrite rules are done already for readerT
2023-06-07 05:12:34 +0200 <Inst> it's probably my fault, I was discussing whether Reader was actually a closure
2023-06-07 05:12:52 +0200 <davean> so "f :: a -> b - c" done "f a b = g" and "f a = \b -> g" and "f = \a -> \b -> g" all perform differently.
2023-06-07 05:12:56 +0200 <Inst> the difference is probably based on the notion that closures can pass data more efficiently than normal functions can
2023-06-07 05:13:17 +0200 <davean> Its not even rewrites.
2023-06-07 05:13:19 +0200meinside(uid24933@id-24933.helmsley.irccloud.com)
2023-06-07 05:13:51 +0200 <Inst> i guess i'll screw around with that for a while
2023-06-07 05:14:47 +0200 <davean> "do p <- e1; e2 = e1 >>= \p -> e2" BTW
2023-06-07 05:14:52 +0200 <davean> https://www.haskell.org/tutorial/monads.html
2023-06-07 05:14:55 +0200 <davean> So you see?
2023-06-07 05:15:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 05:15:53 +0200 <davean> There *are* ways to get efficiency differences but they're not quite where you're looking
2023-06-07 05:16:05 +0200 <Inst> i know about do desugaring
2023-06-07 05:16:07 +0200 <davean> Its about the information you give the compiler
2023-06-07 05:16:09 +0200 <davean> like arity
2023-06-07 05:18:00 +0200 <sm> practically speaking in the context of a GUI app this stuff just doesn't matter, right
2023-06-07 05:18:14 +0200 <davean> Not even a tiny, tiny bit
2023-06-07 05:18:34 +0200 <davean> Not on the GUI side at least
2023-06-07 05:18:57 +0200nate2(~nate@98.45.169.16) (Ping timeout: 250 seconds)
2023-06-07 05:20:27 +0200 <davean> These things come up when you want to be faster than C. Which isn't actually that hard with Haskell.
2023-06-07 05:21:14 +0200 <sm> forgetaboutit Inst. Long do blocks aren't the end of the world if the logic has that shape, some prefer that to a zillion fragmented functions
2023-06-07 05:22:00 +0200 <sm> does it run, does it make pretty pictures, is it useful, is it proving Haskell has apps
2023-06-07 05:22:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 05:24:07 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 240 seconds)
2023-06-07 05:25:37 +0200dcoutts_(~duncan@81.145.206.41) (Ping timeout: 240 seconds)
2023-06-07 05:27:56 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 05:49:40 +0200trev(~trev@user/trev)
2023-06-07 05:53:13 +0200dcoutts_(~duncan@81.145.206.45)
2023-06-07 05:56:27 +0200mokee(~mokee@37.228.215.134) (Quit: Lost terminal)
2023-06-07 06:02:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 06:02:55 +0200 <Inst> tbh i need to get better at this, like, at least i need to figure out how three-penny-gui works
2023-06-07 06:03:04 +0200 <Inst> it'd be really cool to figure out how to adopt monomer to servant
2023-06-07 06:03:24 +0200 <Inst> someone told me that they were planning to move monomer to Android, at least
2023-06-07 06:04:15 +0200 <Inst> it'd be really really cool to have one framework, no matter how much people might knock it, that can deliver a comparable GUI experience on web, app, and desktop, without having to go through the trouble of Electron or Tauri
2023-06-07 06:04:22 +0200 <sm> that's a long shot, I'd be writing smaller easier apps long before that
2023-06-07 06:04:42 +0200 <Inst> yeah i'm totally sidetracked by trying to understand how the library works at the source code level
2023-06-07 06:04:44 +0200 <sm> well today that's kind of swift or flutter
2023-06-07 06:04:48 +0200 <sm> or the web
2023-06-07 06:06:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 06:07:12 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-06-07 06:12:14 +0200dcoutts__(~duncan@212.140.138.205)
2023-06-07 06:13:45 +0200 <Square> is there some way of writing lambda expression for multiple argument patterns? like, "fkn = \a (Just b) c -> ... ; \a Nothing c -> ..."
2023-06-07 06:14:14 +0200 <Axman6> I think there'd discussion of a proposal to do it, lambda cases or something
2023-06-07 06:14:31 +0200 <Square> ok. Thanks. Ill google that
2023-06-07 06:14:37 +0200 <Axman6> so, \cases a (Just b) c -> ...; a Nothing b -> ... IIRC
2023-06-07 06:14:37 +0200dcoutts_(~duncan@81.145.206.45) (Ping timeout: 240 seconds)
2023-06-07 06:17:32 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-06-07 06:18:03 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 06:19:44 +0200foul_owl(~kerry@94.140.8.26) (Ping timeout: 246 seconds)
2023-06-07 06:21:05 +0200chromoblob(~user@37.113.158.8)
2023-06-07 06:22:37 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds)
2023-06-07 06:23:08 +0200dcoutts_(~duncan@81.145.206.45)
2023-06-07 06:23:31 +0200 <Inst> \cases iirc is active in latest GHC
2023-06-07 06:23:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 06:23:50 +0200 <Inst> since 9.4, i think
2023-06-07 06:23:52 +0200 <Inst> also, a question
2023-06-07 06:23:57 +0200 <Inst> philosophical, I guess
2023-06-07 06:24:05 +0200 <Inst> is VoidF a functor? If so, why isn't it an applicative?
2023-06-07 06:24:07 +0200dcoutts__(~duncan@212.140.138.205) (Ping timeout: 256 seconds)
2023-06-07 06:24:22 +0200 <Inst> the way I understand it is that you can't implement pure
2023-06-07 06:24:31 +0200 <Inst> data VoidF a
2023-06-07 06:24:33 +0200 <Axman6> what is VoidF
2023-06-07 06:24:53 +0200 <Axman6> oh, yeah can't implement pure without absurd I guess
2023-06-07 06:25:07 +0200 <Inst> there's three stances I think can be taken, first, VoidF can't be a functor because implementing fmap is equivalent to implementing undefined
2023-06-07 06:25:28 +0200 <Inst> second, VoidF can be a functor, but can't be an applicative, because you can't implement pure without absurd / undefined / semantic equivalents
2023-06-07 06:25:38 +0200 <Inst> third, VoidF can be a functor, applicative, and monad, via the undefined trick
2023-06-07 06:25:51 +0200 <Axman6> ap/<*> is fine because you're saying "IF someone can give me two VoidF's, I can make one" where as pure says "If you give me anything, I can make a VoidF"
2023-06-07 06:26:15 +0200 <Inst> i wonder what exciting segfaults I'll get from unsafeCoerce void
2023-06-07 06:26:19 +0200 <Inst> VoidF
2023-06-07 06:26:35 +0200 <Axman6> fmap is fine for the same reasons, someone has top provide your fmap with a VoidF, which they can't do, so it doesn't matter that your fmap can never return anything
2023-06-07 06:26:55 +0200 <Inst> so applicative is where the whole thing falls apart
2023-06-07 06:27:15 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 06:27:36 +0200 <Axman6> If we had Apply and ... I can't remember the canonical name for the class with just pure in it, then Apply would be fine but not the other one
2023-06-07 06:29:07 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-07 06:30:17 +0200 <Inst> I'm just trying to ruin someone by teaching them monads via Void ;)
2023-06-07 06:31:01 +0200 <Axman6> I prefer to do that with https://tomstu.art/refactoring-ruby-with-monads, since the concepts are familiar to most and the syntax isn't foreign
2023-06-07 06:33:11 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 256 seconds)
2023-06-07 06:33:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 06:33:37 +0200foul_owl(~kerry@71.212.137.212)
2023-06-07 06:36:57 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 250 seconds)
2023-06-07 06:36:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 06:37:01 +0200 <jackdk> Axman6: `Pointed` is usually the name for it, but it's not very popular.
2023-06-07 06:37:15 +0200 <dibblego> stab it in its useless face
2023-06-07 06:37:21 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-06-07 06:38:24 +0200dcoutts_(~duncan@81.145.206.45) (Ping timeout: 248 seconds)
2023-06-07 06:40:00 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-06-07 06:41:56 +0200 <Axman6> it's a rebel class with out a cause, lawless and free
2023-06-07 06:47:10 +0200michalz(~michalz@185.246.207.201)
2023-06-07 06:47:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 06:50:57 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 06:54:14 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac)
2023-06-07 06:54:32 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 07:00:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 07:02:57 +0200turlando(~turlando@user/turlando) (Ping timeout: 250 seconds)
2023-06-07 07:03:40 +0200turlando(~turlando@user/turlando)
2023-06-07 07:05:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 07:06:33 +0200 <Inst> interesting
2023-06-07 07:06:45 +0200 <Inst> if you trigger an incomplete patterns error, for anyone actually using Haskell's exception mechanism
2023-06-07 07:07:07 +0200 <Inst> it'll evaluate the term in the case expression
2023-06-07 07:07:29 +0200 <Axman6> the one you're matching over?
2023-06-07 07:07:44 +0200 <Axman6> that's basically the whole point of case statements, to evaluate things
2023-06-07 07:09:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 07:09:21 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 265 seconds)
2023-06-07 07:10:25 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 07:11:09 +0200 <Inst> ummm, why?
2023-06-07 07:11:40 +0200 <Inst> but tbh it's a weird edge case
2023-06-07 07:11:59 +0200 <Inst> hmmm, let me try again with an infinite list
2023-06-07 07:13:46 +0200 <Inst> also this is pretty weird
2023-06-07 07:13:57 +0200 <Inst> with an infinite list, the first term is actually evaluated
2023-06-07 07:14:16 +0200 <Inst> it doesn't actually need to evaluate such, can :sprint (_:_)
2023-06-07 07:18:32 +0200 <Inst> production haskeller i knew told me simply "nothing about non-exhaustive patterns is weird. They break everything"
2023-06-07 07:20:36 +0200chromoblob(~user@37.113.158.8)
2023-06-07 07:21:35 +0200 <Axman6> Inst: th epoint of a case statement is literally to evaluate an expression far enough to know if it matches the cases
2023-06-07 07:21:59 +0200 <Inst> which is what's weird
2023-06-07 07:22:02 +0200 <Inst> it's matching too far
2023-06-07 07:22:18 +0200 <Inst> like, it only needs to evaluate the list as far as the constructors go
2023-06-07 07:22:28 +0200 <Axman6> only if you told it to, or the const6ructor's value depends on evaluating something else first
2023-06-07 07:22:36 +0200 <c_wraith> if you just want to bind names and defer evaluation, that's what ~ is for
2023-06-07 07:22:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 07:23:31 +0200 <Inst> iirc, lists are doubly lazy, right?
2023-06-07 07:23:35 +0200 <Inst> lazy in leaves, lazy in spine
2023-06-07 07:23:53 +0200 <Inst> if code needs to see : vs [], there's no reason either to evaluate the leaf or the spine, right?
2023-06-07 07:24:24 +0200 <Inst> the sprint should only return an (_:_)
2023-06-07 07:24:27 +0200 <c_wraith> and if that's all you match, it won't evaluate further.
2023-06-07 07:24:40 +0200 <c_wraith> but you need to consider the body of the case as well
2023-06-07 07:24:49 +0200ddellacosta(~ddellacos@143.244.47.100) (Ping timeout: 265 seconds)
2023-06-07 07:25:13 +0200byte(~byte@user/byte) (Ping timeout: 268 seconds)
2023-06-07 07:25:35 +0200 <Inst> oh, i think i know the difficulty
2023-06-07 07:25:43 +0200 <Inst> the weirdness is coming because i'm using enum ranges
2023-06-07 07:25:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 07:26:03 +0200 <c_wraith> like... `sum :: [Int] -> Int ; sum [] = 0; sum (x:xs) = x + sum xs'.. the body in that last clause forces evaluation of everything, not the pattern.
2023-06-07 07:26:46 +0200 <Inst> or maybe it's overloaded lists being weird? Ugh
2023-06-07 07:27:31 +0200 <c_wraith> Well, overloaded lists do mean you're no longer working with []. They had better have different semantics.
2023-06-07 07:28:05 +0200 <Inst> [1,2,3] :: [Int]
2023-06-07 07:28:19 +0200 <Inst> gets the entire list fully evaluated when passed to foo [] = 3, foo bar = 4
2023-06-07 07:28:47 +0200 <c_wraith> as in, that literal appears in code? Well, GHC probably compiles it such that it never contains an unevaluated expression.
2023-06-07 07:29:04 +0200 <Inst> okay, what the hell
2023-06-07 07:29:08 +0200 <Inst> without overloaded lists being on
2023-06-07 07:29:26 +0200 <Inst> adding a type annotation causes the list to be fully evaluated in GHCI?
2023-06-07 07:29:48 +0200 <c_wraith> sure. why wouldn't it?
2023-06-07 07:30:04 +0200 <c_wraith> there is no potential bottom hiding there. Everything is a literal with a known type
2023-06-07 07:30:09 +0200 <c_wraith> and a known value
2023-06-07 07:30:50 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-06-07 07:31:04 +0200 <Inst> <Inst> like, it only needs to evaluate the list as far as the constructors go
2023-06-07 07:31:10 +0200 <c_wraith> only *needs to*
2023-06-07 07:31:14 +0200 <Inst> excuse me
2023-06-07 07:31:16 +0200 <Inst> mispaste
2023-06-07 07:31:24 +0200 <Inst> ghci> u = [1,2,undefined] :: [Int]
2023-06-07 07:31:24 +0200 <Inst> ghci> :sprint u
2023-06-07 07:31:24 +0200 <Inst> u = [1,2,_]
2023-06-07 07:31:45 +0200 <c_wraith> and? what's wrong with that?
2023-06-07 07:32:04 +0200 <Inst> is it correct to call it semantics because this is an evaluation thing?
2023-06-07 07:32:17 +0200 <c_wraith> it's not an evaluation thing because you're not doing any evaluation
2023-06-07 07:32:29 +0200 <c_wraith> That's just what it's compiled to.
2023-06-07 07:32:36 +0200 <Inst> well, u :: [Int] as a type signature behaves differently from u :: [Int] as a type annotation
2023-06-07 07:33:03 +0200byte(~byte@user/byte)
2023-06-07 07:33:17 +0200 <c_wraith> You're going very far into the weeds.
2023-06-07 07:33:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 07:33:35 +0200mbuf(~Shakthi@49.207.178.186)
2023-06-07 07:33:44 +0200 <c_wraith> The relevant questions are "when I evaluate this, what does it need to be evaluated?"
2023-06-07 07:34:18 +0200 <c_wraith> "did GHC remove some thunks from how it compiled this literal?" is completely irrelevant
2023-06-07 07:34:35 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1115876404563816478/image.png?width=54…
2023-06-07 07:34:39 +0200 <Inst> this is too late, i guess
2023-06-07 07:34:42 +0200 <Inst> thanks for humoring me
2023-06-07 07:35:38 +0200 <c_wraith> that's interesting, though. It would suggest ghci treats multiline literals specially.
2023-06-07 07:35:50 +0200 <c_wraith> That's kinda neat.
2023-06-07 07:35:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 07:36:00 +0200 <c_wraith> err, multiline definitions
2023-06-07 07:38:56 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1115877492906012773/image.png?width=78…
2023-06-07 07:39:38 +0200Feuermagier_(~Feuermagi@user/feuermagier)
2023-06-07 07:42:13 +0200Feuermagier(~Feuermagi@user/feuermagier) (Ping timeout: 265 seconds)
2023-06-07 07:43:28 +0200shapr(~user@2600:1700:c640:3100:a42a:82d6:7ced:1441) (Ping timeout: 240 seconds)
2023-06-07 07:43:37 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 07:44:27 +0200notzmv(~zmv@user/notzmv)
2023-06-07 07:45:59 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-06-07 07:46:28 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-07 07:46:44 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-06-07 07:47:12 +0200 <segfaultfizzbuzz> what purpose does writing "let" in languages (such as haskell) serve? it seems unnecessary...?
2023-06-07 07:49:34 +0200lottaquestions(~nick@2607:fa49:503f:6d00:2ffc:724d:26ca:ea57) (Remote host closed the connection)
2023-06-07 07:50:00 +0200lottaquestions(~nick@2607:fa49:503f:6d00:8fc2:91a1:b755:da93)
2023-06-07 07:50:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 07:51:24 +0200mei(~mei@user/mei) (Ping timeout: 265 seconds)
2023-06-07 07:53:56 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 07:54:05 +0200werneta(~werneta@70.142.214.115) (Ping timeout: 250 seconds)
2023-06-07 07:54:32 +0200jinsun(~jinsun@user/jinsun) (Ping timeout: 250 seconds)
2023-06-07 07:54:34 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac)
2023-06-07 07:54:52 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 07:56:00 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-06-07 08:00:00 +0200 <c_wraith> segfaultfizzbuzz: it makes it easier for the parser. It sees let and knows it should be followed by some declarations. Otherwise it would expect an expression in that context, and the appearance of = would cause it to have to backtrack. Also the same for humans.
2023-06-07 08:00:47 +0200CiaoSen(~Jura@145.224.74.19)
2023-06-07 08:00:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 08:02:37 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 240 seconds)
2023-06-07 08:04:11 +0200jinsun(~jinsun@user/jinsun)
2023-06-07 08:05:05 +0200Square(~Square@user/square) (Ping timeout: 240 seconds)
2023-06-07 08:05:29 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 08:08:57 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac)
2023-06-07 08:16:07 +0200 <Axman6> definitions in let can also me mutually recursive, which the translation to lambdas doesn't allow: let a = 1 : b; b = 2 : a in a works, but if you use (\a -> (\b -> xxx )) (1:???) (2:???) doesn't work
2023-06-07 08:16:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 08:17:02 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-06-07 08:17:07 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds)
2023-06-07 08:17:18 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 08:17:28 +0200mei(~mei@user/mei)
2023-06-07 08:22:13 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-06-07 08:23:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 08:24:59 +0200user____3(~user@dynamic-046-114-176-088.46.114.pool.telefonica.de)
2023-06-07 08:26:15 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-07 08:27:05 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-06-07 08:27:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 08:29:54 +0200rembo10(~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in)
2023-06-07 08:32:06 +0200rembo10(~rembo10@main.remulis.com)
2023-06-07 08:44:03 +0200ec_(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-06-07 08:46:10 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1)
2023-06-07 08:46:14 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 08:52:29 +0200Jade17(~Jade@ip-178-200-061-149.um45.pools.vodafone-ip.de)
2023-06-07 08:52:56 +0200Jade17Jade256
2023-06-07 08:54:47 +0200coot(~coot@89.69.206.216)
2023-06-07 08:56:46 +0200Jade256(~Jade@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit)
2023-06-07 08:56:48 +0200coot_(~coot@89-69-206-216.dynamic.chello.pl)
2023-06-07 08:57:01 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-06-07 08:57:31 +0200Jade256(~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de)
2023-06-07 08:58:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 08:59:21 +0200Feuermagier(~Feuermagi@user/feuermagier)
2023-06-07 08:59:52 +0200Jade256(~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit)
2023-06-07 08:59:57 +0200coot(~coot@89.69.206.216) (Ping timeout: 250 seconds)
2023-06-07 08:59:57 +0200coot_coot
2023-06-07 09:00:05 +0200 <fr33domlover> Does anyone know a DB migration library that use a type-level schema, such that the "current version" schema is generated from that, rather than specified separately? (e.g. the model definition used by persistent-esqueleto is directly generated by TH without specifying migrations in the model itself)
2023-06-07 09:00:10 +0200Jade256(~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de)
2023-06-07 09:00:50 +0200 <fr33domlover> Asking because I'm probably going to write such a thing (for my specific use case though, not a general-purpose one) and looking for prior art, and surprised that I can't find any
2023-06-07 09:01:05 +0200Feuermagier_(~Feuermagi@user/feuermagier) (Ping timeout: 256 seconds)
2023-06-07 09:02:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 09:02:05 +0200Jade256(~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit)
2023-06-07 09:02:49 +0200 <fr33domlover> (Prior art I found that is great and useful but isn't about DBs: aeson-schemas, servant, DataVersion)
2023-06-07 09:03:09 +0200 <jackdk> I believe beam-migrate does this, but I never figured out how to drive beam
2023-06-07 09:03:15 +0200acidjnk(~acidjnk@p200300d6e7072f2409bf9167a1faa0fe.dip0.t-ipconnect.de)
2023-06-07 09:08:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 09:10:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 09:11:12 +0200oo_miguel(~Thunderbi@77.252.47.84) (Quit: oo_miguel)
2023-06-07 09:11:41 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-06-07 09:12:46 +0200 <Axman6> Hmmm, anyone know what name Jake McArthur goes by? I want to resurrect https://hackage.haskell.org/package/fixed-point but it looks like the website where it was hosted is not a bikie club...
2023-06-07 09:12:50 +0200 <Axman6> now*
2023-06-07 09:14:00 +0200Feuermagier_(~Feuermagi@user/feuermagier)
2023-06-07 09:14:35 +0200FeuermagierGuest6932
2023-06-07 09:14:35 +0200Guest6932(~Feuermagi@user/feuermagier) (Killed (cadmium.libera.chat (Nickname regained by services)))
2023-06-07 09:14:35 +0200Feuermagier_feuermagier
2023-06-07 09:14:54 +0200Guest6932(~Feuermagi@user/feuermagier)
2023-06-07 09:15:13 +0200feuermagier(~Feuermagi@user/feuermagier) (Killed (zirconium.libera.chat (Nickname regained by services)))
2023-06-07 09:15:13 +0200Guest6932feuermagier
2023-06-07 09:15:33 +0200Guest6955(~Feuermagi@user/feuermagier)
2023-06-07 09:16:13 +0200 <jade[m]> what about the email that's given?
2023-06-07 09:16:41 +0200 <Axman6> oh man, email is a thing hey. I hate email though - I guess I could try
2023-06-07 09:17:21 +0200Guest6955(~Feuermagi@user/feuermagier) (Client Quit)
2023-06-07 09:17:23 +0200feuermagier(~Feuermagi@user/feuermagier) (Client Quit)
2023-06-07 09:17:28 +0200lortabac(~lortabac@2001:620:130:6092:819c:2ab5:89a3:3c36)
2023-06-07 09:22:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 09:23:14 +0200lortabac(~lortabac@2001:620:130:6092:819c:2ab5:89a3:3c36) (Ping timeout: 265 seconds)
2023-06-07 09:24:23 +0200 <Axman6> I thought I'd heard the name - he's still active on github! but not with that repo. The quest to avoid email shall continue
2023-06-07 09:24:25 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 09:26:06 +0200 <Axman6> It is shocking to me that github has no way to message another user directly - probably a good thing really to avoid the "Hey can you please teach me how to write game in OpenGL and DirectX????" messages, but still
2023-06-07 09:26:13 +0200jtza8(~user@165.255.145.149)
2023-06-07 09:27:33 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 09:31:30 +0200lortabac(~lortabac@2001:620:130:6092:af4b:5add:1ec1:8fbe)
2023-06-07 09:31:56 +0200 <Profpatsch> data Product f g a = Pair (f a) (f b) whyyyyyy would you name your constructor like that
2023-06-07 09:32:20 +0200 <Profpatsch> The goal must be to make base as annoying as possible
2023-06-07 09:32:37 +0200vandita(~vandit@178-164-208-246.pool.digikabel.hu) (Ping timeout: 240 seconds)
2023-06-07 09:33:00 +0200 <Profpatsch> I suggest we change
2023-06-07 09:33:17 +0200 <Profpatsch> data Compose f g a = Compose (f (g a))
2023-06-07 09:33:19 +0200 <Profpatsch> to
2023-06-07 09:33:25 +0200 <Profpatsch> data Compose f g a = Nest (f (g a))
2023-06-07 09:33:38 +0200 <Profpatsch> just to add more confusion
2023-06-07 09:34:19 +0200vandita(~vandit@84-236-21-42.pool.digikabel.hu)
2023-06-07 09:37:22 +0200 <Axman6> jade[m]: I did it, I wrote an email. from scratch. urgh, this feels like work.
2023-06-07 09:37:32 +0200 <Axman6> Profpatsch: ew, yeah I do not like that
2023-06-07 09:37:57 +0200 <Axman6> Prod I could live with, Pair is just obnoxious
2023-06-07 09:40:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 09:42:31 +0200hisa386(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net)
2023-06-07 09:43:09 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-07 09:43:54 +0200gmg(~user@user/gehmehgeh)
2023-06-07 09:44:07 +0200hisa38(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 240 seconds)
2023-06-07 09:44:07 +0200hisa386hisa38
2023-06-07 09:45:18 +0200titibandit(~titibandi@user/titibandit)
2023-06-07 09:50:33 +0200eggplantade(~Eggplanta@104.55.37.220) (Remote host closed the connection)
2023-06-07 09:50:38 +0200chele(~chele@user/chele)
2023-06-07 09:52:36 +0200 <probie> Profpatsch: How about `newtype (.) f g a = Nest (f (g a))`? :p
2023-06-07 09:54:13 +0200 <probie> Jokes aside, I sometimes want to be able to, given `type (~>) f g = forall a . f a -> g a`, write something like `foo :: (f . g) ~> (g . f)` (or even `foo :: (Compose f g) ~> (Compose g f)`)
2023-06-07 09:54:38 +0200 <probie> but avoid it because whilst it may make the type neater (at least in my eyes), it makes the actual code so much nosier
2023-06-07 09:57:02 +0200 <int-e> such curious code ("nosier", yeah I know it's a typo)
2023-06-07 09:57:14 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 09:58:25 +0200 <ski> Profpatsch : i'd support that (`Nest') change
2023-06-07 09:58:38 +0200 <int-e> Type-level lambdas make type inference much harder. I think the standard reason for not having them is the lack of principal types (most general unifiers).
2023-06-07 10:01:14 +0200 <merijn> int-e: undecidable even, no?
2023-06-07 10:01:32 +0200 <int-e> merijn: well, yes
2023-06-07 10:02:16 +0200 <int-e> (but that still allows for incomplete implementations that try as well as they can)
2023-06-07 10:06:49 +0200m1dnight(~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 3.8)
2023-06-07 10:08:25 +0200 <Profpatsch> ski: it was meant sarcasticalyl
2023-06-07 10:08:57 +0200 <Profpatsch> but yes, let’s introduce more accidental mental overhead, the language doesn’t have enough yet
2023-06-07 10:09:59 +0200m1dnight(~christoph@78-22-4-67.access.telenet.be)
2023-06-07 10:10:24 +0200 <mzg> Profpatsch: that's how you start evolving
2023-06-07 10:10:52 +0200 <Profpatsch> If anything, change Pair to Product
2023-06-07 10:11:36 +0200 <int-e> s/Compose/B/g, force people to learn standard combinator names.
2023-06-07 10:14:58 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-06-07 10:15:05 +0200 <c_wraith> So are we going to rename Identity to I? that would save so much typing.
2023-06-07 10:15:25 +0200 <probie> didn't generics-sop actually do this?
2023-06-07 10:16:00 +0200zxrom(~zxrom@mm-163-23-212-37.vitebsk.dynamic.pppoe.byfly.by) (Quit: Leaving)
2023-06-07 10:16:06 +0200 <int-e> c_wraith: Yes, and Const to K.
2023-06-07 10:16:20 +0200 <int-e> also const to k, just to mess with people using i,j,k as indices
2023-06-07 10:16:41 +0200 <c_wraith> might as well rename id to i if we're going that direction
2023-06-07 10:16:47 +0200 <int-e> of course
2023-06-07 10:16:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 10:16:59 +0200 <int-e> I'm happy we're all in agreement here ;)
2023-06-07 10:17:26 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 10:18:29 +0200Pickchea(~private@user/pickchea)
2023-06-07 10:19:10 +0200 <Profpatsch> probie: I’ve been unironically wishing for $ on the typelevel
2023-06-07 10:19:13 +0200 <jackdk> I wish the `(:+:)`, `(:*:)` and `(:.:)` were canonical and we didn't have the ones in Data.Functor.*
2023-06-07 10:19:33 +0200 <Profpatsch> but yeah, something like ~> would be good, though it’s a bit too close to -> for my liking
2023-06-07 10:19:36 +0200 <Profpatsch> maybe -->
2023-06-07 10:19:43 +0200 <Profpatsch> “big arrow”
2023-06-07 10:20:14 +0200 <Profpatsch> tho in general I think operators and symbol zoo are bad and should be banned
2023-06-07 10:20:22 +0200 <Profpatsch> Just write words
2023-06-07 10:20:38 +0200 <jackdk> nah, I think we're pretty good about using a consistent visual language in our operators around here
2023-06-07 10:20:49 +0200 <Profpatsch> not sure if irony
2023-06-07 10:21:08 +0200 <Profpatsch> I mean, you get used to it
2023-06-07 10:21:15 +0200 <Profpatsch> But lens overdoes it, by a lot
2023-06-07 10:21:35 +0200 <jackdk> 100% serious. $ and <$> have similar meaning but the "wings" mean "with a layer of functor", roughly speaking
2023-06-07 10:21:38 +0200 <Profpatsch> (not that I use lens in production, that would be a grave mistake)
2023-06-07 10:21:46 +0200 <Profpatsch> jackdk: yeah, that convention is :100:
2023-06-07 10:21:54 +0200 <jackdk> & is the opposite of $, so <&> is easily guessable
2023-06-07 10:21:58 +0200 <Profpatsch> agreed
2023-06-07 10:22:05 +0200 <jackdk> <* and *> as variants of <*>
2023-06-07 10:22:10 +0200 <Profpatsch> Now let’s just tell people to use & and <&> more
2023-06-07 10:22:28 +0200 <jackdk> you can probably guess what <$?> and <&?> in `witherable` do: mapMaybe and flipped mapMaybe
2023-06-07 10:24:05 +0200 <jackdk> Lens does this too, within its own operator convention: <<%@= is: "modify" (% - mnemonic "mod") an "indexed lens" (@ - mnemonic "at") of a value in a MonadState (=) and return the old value (<<)
2023-06-07 10:31:52 +0200lortabac(~lortabac@2001:620:130:6092:af4b:5add:1ec1:8fbe) (Ping timeout: 265 seconds)
2023-06-07 10:34:52 +0200 <probie> Profpatsch: what stops you? You can already go `type ($) f x = f x`
2023-06-07 10:35:44 +0200 <probie> I guess it probably doesn't play with `->` in the way you'd like
2023-06-07 10:36:14 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e) (Quit: use-value)
2023-06-07 10:36:49 +0200 <Profpatsch> probie: pretty sure you can’t do infix definitions on the type level
2023-06-07 10:37:17 +0200 <Profpatsch> jackdk: I know that lens has a convention, but the matrix is way too large
2023-06-07 10:39:30 +0200lortabac(~lortabac@2001:620:130:6092:a46f:9a9:efa8:9c69)
2023-06-07 10:40:49 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-06-07 10:42:05 +0200 <probie> Profpatsch: What makes you so sure that you can't? So `->` is effectively `infixr -1` so you can't make `$` below it, but I can write `infixr 0 $` in the same file as my `type ($) f x = f x` and then it will accept something like `Nothing :: Maybe $ Either String $ Maybe Int`
2023-06-07 10:42:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 10:42:49 +0200 <Profpatsch> probie: Oh, then that’s pretty cool
2023-06-07 10:42:54 +0200cfricke(~cfricke@user/cfricke)
2023-06-07 10:43:11 +0200 <Profpatsch> but yeah, -> being -1 is kinda crappy
2023-06-07 10:44:01 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 10:44:08 +0200chromoblob(~user@37.113.158.8)
2023-06-07 10:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 10:51:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 10:51:03 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 10:55:15 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:523d:9a8b:b2f4:ac13)
2023-06-07 10:55:28 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 248 seconds)
2023-06-07 10:55:53 +0200shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 246 seconds)
2023-06-07 10:56:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 10:57:57 +0200tzh_(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2023-06-07 10:59:28 +0200caryhartline(~caryhartl@168.182.58.169)
2023-06-07 10:59:29 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.8)
2023-06-07 11:03:17 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds)
2023-06-07 11:03:48 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-06-07 11:06:42 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:09:35 +0200 <Inst> pfft, the pythonistas are terrible
2023-06-07 11:09:46 +0200 <Inst> at least the julians have an excuse that they're few in number
2023-06-07 11:10:06 +0200 <Inst> i'm trying to build an extremely cleaned-up variant of the bentley quicksort in Python and Haskell
2023-06-07 11:18:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 11:21:17 +0200lortabac(~lortabac@2001:620:130:6092:a46f:9a9:efa8:9c69) (Quit: WeeChat 2.8)
2023-06-07 11:22:27 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:24:31 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving)
2023-06-07 11:27:32 +0200mbuf(~Shakthi@49.207.178.186) (Quit: Leaving)
2023-06-07 11:27:51 +0200jtza8(~user@165.255.145.149) (ERC 5.4 (IRC client for GNU Emacs 28.2))
2023-06-07 11:28:30 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-06-07 11:28:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 11:30:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:33:28 +0200m1dnight(~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 3.8)
2023-06-07 11:33:55 +0200m1dnight(~christoph@78-22-4-67.access.telenet.be)
2023-06-07 11:39:39 +0200mheinzel(~mheinzel@152.96.94.71)
2023-06-07 11:41:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 11:43:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:52:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 11:53:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:53:21 +0200user____3gurkenglas
2023-06-07 11:58:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 11:59:28 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 11:59:29 +0200le_ka(~l_k@213.24.134.106)
2023-06-07 12:01:33 +0200__monty__(~toonn@user/toonn)
2023-06-07 12:03:07 +0200 <gurkenglas> Given let's say two sorting algorithms :: Ord a => [a] -> [a] (if you like, it's written in a domain-specific language), is there some algorithm for constructing lists on which each is faster than the other?
2023-06-07 12:03:27 +0200 <gurkenglas> s/it's/they're/
2023-06-07 12:04:01 +0200 <gurkenglas> ("let's say" because i'd hope that algorithm to generalize beyond that type)
2023-06-07 12:05:03 +0200 <_________> yes, bruteforce
2023-06-07 12:05:04 +0200 <gurkenglas> (it's fine if that generalized algorithm needs some "structure of the type" to understand what it means for one of the two to be slower on an input)
2023-06-07 12:05:08 +0200 <probie> what does "faster" mean?
2023-06-07 12:05:22 +0200 <gurkenglas> _________: i'm hoping for automated symbolic reasoning
2023-06-07 12:05:25 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) (Ping timeout: 250 seconds)
2023-06-07 12:05:39 +0200enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7)
2023-06-07 12:06:05 +0200 <probie> I can (given enough time) probably come up with two algorithms and several lists where your choice of actual machine will determine which algorithm is faster
2023-06-07 12:06:35 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 246 seconds)
2023-06-07 12:06:37 +0200maerwald(~maerwald@mail.hasufell.de) (Quit: gone)
2023-06-07 12:06:44 +0200 <gurkenglas> probie: faster as in the kind of theoretical analysis you do to say things like "quicksort has worst-case performance O(n²)"
2023-06-07 12:06:59 +0200maerwald(~maerwald@mail.hasufell.de)
2023-06-07 12:08:09 +0200 <probie> let f = if f is log(n) then bubbleSort else mergeSort
2023-06-07 12:08:55 +0200 <gurkenglas> probie: i don't follow
2023-06-07 12:09:08 +0200mmhat(~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de)
2023-06-07 12:09:17 +0200 <gurkenglas> i think you're trying to give me an algorithm on which it'd be hard to run that symbolic reasoning, but what exactly is f
2023-06-07 12:09:32 +0200 <gurkenglas> or is
2023-06-07 12:09:44 +0200 <gurkenglas> (since f appears to be recursively defined here?)
2023-06-07 12:10:14 +0200 <gurkenglas> ah, you're doing the halting problem impossiblity proof as applied to sorting algorithms?
2023-06-07 12:11:22 +0200 <gurkenglas> my answer is that the symbolic reasoning wouldn't halt on your sorting algorithm, which is fine since your sorting algorithm doesn't halt
2023-06-07 12:11:25 +0200 <gurkenglas> :P
2023-06-07 12:11:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 12:13:02 +0200 <gurkenglas> the oracle is only supposed to be ~exponentially faster than running the algorithm on all lists and measuring runtime
2023-06-07 12:13:36 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 12:13:41 +0200ajf___[m](~ajfmatrix@2001:470:69fc:105::2:5be3) (Remote host closed the connection)
2023-06-07 12:13:47 +0200 <probie> To do the sort of analysis you want, you probably need a rather restricted language for describing (terminating) sorting algorithms
2023-06-07 12:15:02 +0200 <gurkenglas> i was thinking it'd simply automate the usual trick of executing the algorithm without having chosen the input and picking the most inconvenient input during that
2023-06-07 12:17:34 +0200 <gurkenglas> compare: given a function Stream -> Bool that *always* returns True or False after some finite time, and there is some input that makes it return True, you can find one such in finite time, this trick is afaik known as berger :: (Stream a -> Bool) -> Stream a
2023-06-07 12:18:04 +0200 <gurkenglas> (Eq a, I guess.)
2023-06-07 12:19:38 +0200 <ncf> that seems very different
2023-06-07 12:19:49 +0200 <gurkenglas> (and Enum a, actually, so let's say s/Stream -> Bool/Stream Bool -> Bool/)
2023-06-07 12:20:14 +0200 <ncf> the space of lists isn't really searchable in that sense
2023-06-07 12:20:50 +0200 <gurkenglas> I see, can you give some other kind of algorithm than sorting where I could do that kind of worst-case-runtime construction?
2023-06-07 12:21:17 +0200 <ncf> i'm not that familiar with it
2023-06-07 12:21:23 +0200 <gurkenglas> (conceptually similar to sorting, perhaps)
2023-06-07 12:22:24 +0200 <ncf> (also, does that work for other types than, say, a ~ Bool ?)
2023-06-07 12:22:44 +0200 <ncf> the whole trick relies on the compactness of the Cantor space 2^ℕ, but e.g. ℕ^ℕ isn't compact
2023-06-07 12:22:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 12:22:56 +0200 <gurkenglas> ncf: i remember exercises where i needed to apply that lazy-adversarial-input trick i mentioned. i assume you mean that trick sometimes fails. is there then some algorithm for when it doesn't?
2023-06-07 12:23:34 +0200 <ncf> i'm basically repiping https://math.andrej.com/2007/09/28/seemingly-impossible-functional-programs/, you might want to read that and adjacent papers/articles
2023-06-07 12:23:37 +0200 <gurkenglas> ncf: presumably you're not amused with Enum a
2023-06-07 12:23:49 +0200 <gurkenglas> yes that's where i picked up that trick :D
2023-06-07 12:23:53 +0200 <somerandomnick[m> Profpatsch: I agree, introducing <&> when <$> already exists was a mathematical defeat. i suspect kmett settled for getting rid of chains of fmaps, so now code looks less absurd but now all the more scary
2023-06-07 12:24:08 +0200 <ncf> i actually have no idea if 3^ℕ is compact
2023-06-07 12:24:48 +0200 <gurkenglas> oh damn \mathbb{N} is Enum in Haskell, i meant "finite enumerable"
2023-06-07 12:25:02 +0200 <gurkenglas> i'm willing to bet 3^\mathbb{N} is compact
2023-06-07 12:25:07 +0200 <ncf> yeah i got what you meant
2023-06-07 12:26:29 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 12:27:38 +0200 <gurkenglas> ncf: I first found (it was recent) your last link in https://www.cs.bham.ac.uk/~mhe/papers/exhaustive.pdf (thus didn't read the meat of exhaustive.pdf) which is I think exactly about which of those are compact
2023-06-07 12:28:12 +0200 <gurkenglas> (but I was under the impression "conceptually similar to sorting" makes my question slightly different)
2023-06-07 12:28:43 +0200 <gurkenglas> (i am not, on reflection, staking any significant credit on that impression ^^)
2023-06-07 12:29:17 +0200 <ncf> yeah ok 3^ℕ is compact via tychonoff
2023-06-07 12:29:28 +0200 <ncf> so any (Fin n)^ℕ is
2023-06-07 12:29:32 +0200dcoutts(~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f)
2023-06-07 12:29:55 +0200 <gurkenglas> i dont know tychonoff off the top of my head but the algorithm for exhaustively searching 2^N seems to me like it just works the same way for 3^N
2023-06-07 12:30:04 +0200 <gurkenglas> actually, we're being silly, the two are isomorphic.
2023-06-07 12:30:23 +0200 <ncf> are they homeomorphic?
2023-06-07 12:30:42 +0200 <gurkenglas> (aka turn your 3^N->Bool into 2^N->Bool by encoding your ternary digits with two binary digits each)
2023-06-07 12:31:18 +0200 <Inst> wait, question if anyone wants to play
2023-06-07 12:31:28 +0200 <Inst> if i'm actually doing a non-recursive quicksort
2023-06-07 12:31:39 +0200 <Inst> do i even need ST monad and mutable vectors
2023-06-07 12:31:42 +0200mheinzel(~mheinzel@152.96.94.71) (Ping timeout: 265 seconds)
2023-06-07 12:31:52 +0200 <gurkenglas> non-recursive, in Haskell? what are you using for that?
2023-06-07 12:32:14 +0200 <Inst> i'm working on bentley quicksort to try to get the cleanest possible true quicksort in Haskell
2023-06-07 12:32:31 +0200 <Inst> the current version is in python, but i can translate pretty reliably between recursive and non-recursive idioms
2023-06-07 12:32:59 +0200 <Inst> well, probably not, unless i can figure out some way to make it tail recursive?
2023-06-07 12:33:42 +0200 <gurkenglas> Inst: Give some example of a pair of Haskell functions where you'd one is a non-recursive version of the other?
2023-06-07 12:33:51 +0200 <gurkenglas> s/you'd/you'd say/
2023-06-07 12:34:02 +0200 <Inst> well, i mean, TCO-ed
2023-06-07 12:34:15 +0200 <Inst> the Python version, predictably to an extent
2023-06-07 12:34:21 +0200 <Inst> is cleaner and more comprehensible when it's non-recursive
2023-06-07 12:34:36 +0200 <Inst> it's a while loop using a control list of tuples
2023-06-07 12:34:42 +0200 <Inst> erm, a control list of lists
2023-06-07 12:35:22 +0200 <gurkenglas> ah so you're referring to explicit recursion, and it's fine if the implementation merely *looks* non-recursive because all the recursion is done by library functions, right?
2023-06-07 12:35:33 +0200 <Inst> translating that back to Haskell, I get the feeling it'd be TCO-ed
2023-06-07 12:35:53 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in)
2023-06-07 12:36:04 +0200 <Inst> so i'm unsure as to whether i'd need mutable references to get an in-place... ah crap, i would
2023-06-07 12:36:04 +0200 <gurkenglas> link the python version?
2023-06-07 12:36:05 +0200 <Inst> ;_;
2023-06-07 12:36:22 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1115950265623912528/image.png?width=28…
2023-06-07 12:36:41 +0200 <gurkenglas> image of text x.x
2023-06-07 12:40:04 +0200 <gurkenglas> i expect my refactoring of that to do whatever is necessary to get rid of the 0s and 1s
2023-06-07 12:40:05 +0200 <Inst> https://paste.tomsmeding.com/2jkuCqnT
2023-06-07 12:40:15 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2023-06-07 12:40:24 +0200dcoutts(~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) (Ping timeout: 265 seconds)
2023-06-07 12:40:36 +0200 <Inst> the only benefit of the non-recursive version is that it can be run as a simple while loop
2023-06-07 12:41:09 +0200 <Inst> avoiding the relatively costly function definitions, i.e, in haskell, functions are the basic unit of programming, in imperative languages, it's some kind of loop and assignment / reassignment
2023-06-07 12:41:10 +0200 <gurkenglas> do you favor that for the performance or the readability?
2023-06-07 12:41:15 +0200 <Inst> readability
2023-06-07 12:41:20 +0200 <gurkenglas> then dont use ST :D
2023-06-07 12:41:27 +0200 <Inst> remember when we had the haskell treesort as an advertisement
2023-06-07 12:41:38 +0200 <Inst> i want to see what a cleaned up true quicksort in Haskell looks like
2023-06-07 12:41:47 +0200 <Inst> and how far we can compare vs python etc
2023-06-07 12:42:36 +0200 <gurkenglas> is your motivation-to-see flavored as a motivation-to-play or as intellectual curiosity?
2023-06-07 12:43:06 +0200 <Inst> both
2023-06-07 12:43:20 +0200 <Inst> i assume Haskell quicksort will lose to py or any imperative language concerned with readability
2023-06-07 12:44:14 +0200 <gurkenglas> :t mapAccumL :: are you familiar with this?
2023-06-07 12:44:15 +0200 <lambdabot> error: Operator applied to too few arguments: ?
2023-06-07 12:44:26 +0200 <gurkenglas> :t mapAccumL -- whoops
2023-06-07 12:44:27 +0200 <lambdabot> Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c)
2023-06-07 12:44:30 +0200 <Inst> i know mapAccum exists
2023-06-07 12:44:35 +0200 <Inst> i haven't used it much
2023-06-07 12:44:53 +0200 <Inst> holy shit, have you worked on this problem before?
2023-06-07 12:45:01 +0200 <jade[m]> Inst: how so?
2023-06-07 12:45:32 +0200 <Inst> are you implying that we can do a true inplace quicksort via HoF and beat imperative quicksorts?
2023-06-07 12:46:08 +0200 <gurkenglas> beat as in timing experiments?
2023-06-07 12:46:12 +0200 <Inst> not in timing
2023-06-07 12:46:17 +0200 <Inst> in terms of readability
2023-06-07 12:46:21 +0200 <Inst> and concision
2023-06-07 12:46:27 +0200 <gurkenglas> :t auf (iso runState state) traverse -- equivalent to mapAccumL, closer to ST
2023-06-07 12:46:28 +0200 <lambdabot> Traversable t => (a -> s -> (b, s)) -> t a -> s -> (t b, s)
2023-06-07 12:46:29 +0200 <Inst> bentley quicksort isn't performant anyways
2023-06-07 12:47:05 +0200 <gurkenglas> do you have a haskell version based on ST already?
2023-06-07 12:47:15 +0200 <Profpatsch> somerandomnick[m: “mathematical defeat” lol
2023-06-07 12:47:53 +0200 <Profpatsch> I’d argue mathematics got the definition wrong in the first place
2023-06-07 12:48:00 +0200 <Inst> https://paste.tomsmeding.com/f4paIt6g
2023-06-07 12:48:04 +0200 <Profpatsch> f.g should have been g(f(x)) not f(g(x))
2023-06-07 12:48:08 +0200 <Inst> this isn't bentley
2023-06-07 12:48:25 +0200 <Inst> i'm still giggling that i confused a bunch of pythonistas with the direct py translation
2023-06-07 12:48:38 +0200 <Profpatsch> Anywho, any Haskell code using & and <&> heavily will be more readable.
2023-06-07 12:48:40 +0200 <Inst> then again, quicksort is ugly in general
2023-06-07 12:49:10 +0200 <Profpatsch> Most other functional languages have recognized this, |> (the same as (&) in haskell) is heavily used in both F# and modern Ocaml
2023-06-07 12:49:29 +0200 <fendor[m]> and elm :)
2023-06-07 12:49:40 +0200 <Profpatsch> <&> composes better with >>=, forming amazing pipeline behaviour
2023-06-07 12:50:31 +0200 <Profpatsch> Combine that with \case and you’re going places
2023-06-07 12:50:40 +0200 <Inst> ugh, this version is bugged
2023-06-07 12:50:43 +0200 <jade[m]> Profpatsch: yes but only if it had another name. `.` is borrowed from mathematics where it means `f(g(x))`
2023-06-07 12:51:16 +0200 <probie> Inst: I'm pretty sure that use of `unsafeThaw` is genuinely unsafe
2023-06-07 12:51:57 +0200 <Profpatsch> jade[m]: I just said that I believe the mathematics definition was ill-advised
2023-06-07 12:52:07 +0200 <Profpatsch> It should have been defined as g(f(x))
2023-06-07 12:52:08 +0200 <Inst> it's not the unsafe freeze / unsafe thaw
2023-06-07 12:52:13 +0200 <Inst> version without the unsafes is still bugged
2023-06-07 12:52:14 +0200 <Profpatsch> In math
2023-06-07 12:52:16 +0200 <__monty__> I've never been a fan of `flip (.)`, I guess I'll try using it exclusively for a while to see if you can change my mind.
2023-06-07 12:52:18 +0200 <Inst> i had a version which was bugged like this
2023-06-07 12:52:44 +0200 <Profpatsch> Don’t forget >>> from Control.Category
2023-06-07 12:52:51 +0200 <c_wraith> However, Haskell isn't match, and so (.) goes the correct direction in Haskell. in `(f. g) x', the first thing evaluated is f
2023-06-07 12:52:54 +0200 <Profpatsch> Also immensely useful
2023-06-07 12:52:56 +0200 <c_wraith> err, isn't math
2023-06-07 12:53:07 +0200 <Profpatsch> c_wraith: what even does that mean
2023-06-07 12:53:16 +0200 <Profpatsch> That statement has literally no content :P
2023-06-07 12:53:23 +0200 <c_wraith> it's 100% true
2023-06-07 12:53:24 +0200 <Profpatsch> no offense
2023-06-07 12:53:35 +0200 <__monty__> c_wraith: Isn't `(.)` evaluated first?
2023-06-07 12:53:55 +0200 <c_wraith> sure, but it's the whole context
2023-06-07 12:54:02 +0200 <Inst> there, i fixed it
2023-06-07 12:54:04 +0200 <c_wraith> also, it's usually evaluated at compile time
2023-06-07 12:54:06 +0200 <Inst> the code in the swap logic was flawed
2023-06-07 12:54:18 +0200fendor(~fendor@2a02:8388:1605:7500:3974:8f28:6b80:17ec)
2023-06-07 12:54:43 +0200 <Inst> the swap logic has it incrementing the front element
2023-06-07 12:55:06 +0200 <Inst> erm, decrementing the rear element variable when it should be incrementing the front element variable
2023-06-07 12:55:41 +0200 <probie> Inst: that doesn't change the fact you're unsafely mutating in place the (supposedly) immutable vector `quicksort` is given. Try `f v = let sorted = quicksort v in print sorted >> print v` and see what you get
2023-06-07 12:55:59 +0200 <c_wraith> Profpatsch: given `(foo bar baz . zot kabooie) (more tokens here)', look at the demand order. `foo bar baz' is the first value that needs to be evaluated. depending on what it is, the rest might not need to be evaluated at all.
2023-06-07 12:56:50 +0200 <c_wraith> Profpatsch: if it turns out that its argument *is* required, `zot kabooie' will be evaluated next. Only if that requires its argument will `more tokens here' be evaluated.
2023-06-07 12:57:51 +0200 <c_wraith> this is why Haskell's evaluation model is sometimes called outermost-first
2023-06-07 12:58:07 +0200 <Inst> ruh roh
2023-06-07 12:58:11 +0200 <Inst> something's wrong with this code
2023-06-07 12:58:12 +0200 <Inst> :(
2023-06-07 12:58:39 +0200 <jade[m]> I should also say that I don't have a problem reading `.`, and it might even be more appropriate for a declarative style.
2023-06-07 12:58:39 +0200 <jade[m]> While you read `.` as `after` or `of`, which you can reason about like this: `foo . bar . baz` foo of bar of baz, or foo after bar after baz, I feel like forwards composition has an unsettling imperative feel about it when you read it as `after` or `then`
2023-06-07 12:58:48 +0200 <Inst> groan, kill me
2023-06-07 12:58:59 +0200 <Inst> need to find my newer non-buggy version
2023-06-07 12:59:23 +0200 <__monty__> Superficially it strikes me as similar to let-in v. where, in that let-in and &/<&> lead with the unimportant stuff, while where and ./<$> lead with the interesting bit. I've also been known to use =<< though so maybe I'm irredeemable.
2023-06-07 12:59:31 +0200 <jade[m]> I've been learning haskell for like half a year properly (I actually have no idea lol?) and reading function composition is pretty intuitive to menow
2023-06-07 12:59:40 +0200 <jade[m]> s/menow/me now
2023-06-07 12:59:54 +0200 <probie> `f . g` is leading with the important bit
2023-06-07 13:00:00 +0200 <Profpatsch> c_wraith: yeah, but as a user I don’t care about evaluation order
2023-06-07 13:00:04 +0200 <Profpatsch> I care about logical order
2023-06-07 13:00:12 +0200 <Profpatsch> eval order is secondart
2023-06-07 13:00:14 +0200 <c_wraith> oh, then you like space leaks
2023-06-07 13:00:14 +0200 <Profpatsch> y
2023-06-07 13:00:15 +0200 <Inst> the only problem with haskell tbh is that & and >>> don't play together nicely
2023-06-07 13:00:22 +0200 <Inst> if you look at streamly they're pushing a & idiom
2023-06-07 13:00:24 +0200 <Profpatsch> Again, what even does that mean
2023-06-07 13:00:29 +0200 <jade[m]> logical order is also from the outside imo
2023-06-07 13:00:42 +0200 <jade[m]> it really just depends on how you look at it
2023-06-07 13:00:53 +0200 <Profpatsch> c_wraith: jade[m] take a look at this function: https://github.com/possehl-analytics/pa-hackage/blob/master/pa-error-tree/src/Data/Error/Tree.hs#L…
2023-06-07 13:00:57 +0200 <Inst> & and >>> have the wrong precedence for their combined use to work as a flipped replacement for $ and .
2023-06-07 13:01:10 +0200 <Profpatsch> would you seriously opine that “logical order” opposite the way it was written?
2023-06-07 13:01:12 +0200 <c_wraith> Profpatsch: why is it all backwards?
2023-06-07 13:01:15 +0200 <Inst> probie: the f v actually works properly on [4,3,2,1]
2023-06-07 13:01:28 +0200 <Inst> for whatever reason, the new code is broken, even if I swap unsafe freeze to freeze etc
2023-06-07 13:01:34 +0200 <Profpatsch> So a user will think “okay, I have mapped things (over which I have mapped things (over
2023-06-07 13:01:56 +0200 <Profpatsch> Instead of “I have to do this, then that, then draw the tree, then convert to string”
2023-06-07 13:01:59 +0200 <jade[m]> I do actually have a hard time reading it like that and in my head im going from the last one to the first
2023-06-07 13:01:59 +0200 <jade[m]> lol
2023-06-07 13:02:23 +0200 <Profpatsch> jade[m]: only HAskellers would read code back-to-front and right-to-left
2023-06-07 13:02:25 +0200 <jade[m]> because I want to know what the function returns first and foremost, and then slowly go 'inwards'
2023-06-07 13:02:39 +0200 <jade[m]> Profpatsch: nonono, just yours
2023-06-07 13:02:40 +0200 <probie> To know the result of `(f . g) x`, it is `f` _not_ `g` that needs to reduce first
2023-06-07 13:02:41 +0200 <Profpatsch> this is stockholm syndrome final stage
2023-06-07 13:03:11 +0200 <c_wraith> Profpatsch: or... it's better and you haven't realized yet.
2023-06-07 13:03:23 +0200 <Profpatsch> jade[m]: if you want to know the result, look at the type signatrue
2023-06-07 13:03:34 +0200 <c_wraith> Profpatsch: the thing that really stands out to me is that it's needlessly pointful
2023-06-07 13:03:39 +0200 <c_wraith> Profpatsch: you're not thinking in functions
2023-06-07 13:04:11 +0200 <Profpatsch> c_wraith: I have been writing Haskell full-time for 5 years now, I don’t think “you’re not in a Haskell mindset” applies to me
2023-06-07 13:04:24 +0200 <c_wraith> Profpatsch: 5 years is... a start
2023-06-07 13:04:35 +0200hays(rootvegeta@fsf/member/hays) (Remote host closed the connection)
2023-06-07 13:05:11 +0200 <Profpatsch> To the contrary, I’ve worked with both extensively, and left-to-right top-to-bottom pipelining always wins in readability and writability
2023-06-07 13:05:18 +0200 <jade[m]> also, shouldn't sequential `<$>`/fmaps be a single one?
2023-06-07 13:05:24 +0200 <jade[m]> using said composition?
2023-06-07 13:05:34 +0200 <c_wraith> Like.. you've contorted the logic really hard instead of... doing what jade[m] is suggesting
2023-06-07 13:05:38 +0200 <Profpatsch> jade[m]: See, you are trying to do the compiler’s work
2023-06-07 13:05:53 +0200 <c_wraith> that's for readability, not for the compiler
2023-06-07 13:06:03 +0200 <Profpatsch> you people are lost lol
2023-06-07 13:06:08 +0200 <Inst> there, if you're still here, gurkenglas
2023-06-07 13:06:13 +0200 <Inst> this version works
2023-06-07 13:06:18 +0200 <Inst> with and without unsafeFreeze / unsafeThaw
2023-06-07 13:06:35 +0200 <jade[m]> Profpatsch: alright then
2023-06-07 13:06:37 +0200 <Inst> iirc unsafe is, #1, not for use with reference versions, #2, only a post-finalization optimization that requires testing
2023-06-07 13:06:54 +0200 <Inst> https://paste.tomsmeding.com/FY60Fw1F
2023-06-07 13:07:49 +0200xff0x_(~xff0x@ai098135.d.east.v6connect.net)
2023-06-07 13:08:28 +0200 <gurkenglas> my opinion on &/>>= vs ./$ is that whichever is fine but it should please be consistent, meaning that if function application is "f x" then you use ./$ and also your type signatures should look like "Output <- Input"
2023-06-07 13:08:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:09:17 +0200__monty__(~toonn@user/toonn) (Ping timeout: 256 seconds)
2023-06-07 13:10:00 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-06-07 13:10:09 +0200 <gurkenglas> (.) :: (c<-a) <- (c<-b) <- (b<-a) -- reasonable, right?
2023-06-07 13:10:20 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:10:52 +0200 <c_wraith> that doesn't play nicely with currying
2023-06-07 13:11:01 +0200 <gurkenglas> explain?
2023-06-07 13:11:17 +0200 <probie> I feel like this the functional equivalent of arguing abound endianness
2023-06-07 13:11:32 +0200 <c_wraith> it requires you to provide arguments in the opposite order of how they appear in the type
2023-06-07 13:11:39 +0200 <gurkenglas> probie: sure. do you agree that endianness is arbtirary but should be consistent?
2023-06-07 13:11:59 +0200 <jade[m]> I personally use medium sized endian instead of going for the extremes
2023-06-07 13:12:19 +0200 <gurkenglas> c_wraith: (f::c<-b) . (g::b<-a) :: c<-a
2023-06-07 13:12:20 +0200 <probie> Ah, the RISC-V op approach
2023-06-07 13:12:33 +0200__monty__(~toonn@user/toonn)
2023-06-07 13:12:44 +0200 <jade[m]> oh shit, I just realized that actually sorta exists
2023-06-07 13:12:46 +0200 <chromoblob> I use the endianness in which the lesser byte is in front of you and the bigger byte is further away
2023-06-07 13:12:51 +0200 <jade[m]> I just wanted to make a dumb joke, damn
2023-06-07 13:13:19 +0200 <c_wraith> gurkenglas: only if you've swapped binary operator application order, too
2023-06-07 13:13:31 +0200 <gurkenglas> if you find yourself thinking about endianness, notice that you are doing pointer arithmetic, and find another way to solve your problem
2023-06-07 13:14:03 +0200 <gurkenglas> c_wraith: (.) (f::c<-b) (g::b<-a) :: c<-a
2023-06-07 13:14:27 +0200 <c_wraith> gurkenglas: so yes, you've reversed argument order.
2023-06-07 13:14:28 +0200 <probie> gurkenglas: I don't think it needs to be globally consistent, just locally consistent (I'm not mandating everything should be little/big endian, but this powerpc nonsense of supporting both on the same CPU is a step too far)
2023-06-07 13:15:08 +0200 <gurkenglas> probie: fiiiine i will accept it if the alien planet across the galaxy uses the other one
2023-06-07 13:15:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:15:44 +0200 <gurkenglas> the 50% chance of war in a million years is on your hands.
2023-06-07 13:17:26 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:17:59 +0200 <gurkenglas> c_wraith: ah, that's what you meant by reversed order, fair enough. eta reduction does operate on the middle of the string rather than an end under my proposal.
2023-06-07 13:18:31 +0200mei(~mei@user/mei) (Ping timeout: 240 seconds)
2023-06-07 13:18:45 +0200 <probie> but back to the original topic - I prefer `(.)` when writing code which is consciously relying on non-strict semantics. Most of the time, I'd rather `(&)` (but don't use it because it's not the norm). So I guess my preference is "the first function I read is the first one I need to think about"
2023-06-07 13:19:20 +0200 <probie> which really just sounds like "I want to read left to right using the minimal amount of additional mental storage"
2023-06-07 13:19:36 +0200 <gurkenglas> but if i'm not pathetically missing a second degree of freedom, i'm willing to bite the bullet that apparently you have to pick between composition having the intuitive order and eta reduction having the familiar order, and claim that the former is more important and maybe the latter is a hint at underlying math
2023-06-07 13:22:43 +0200mei(~mei@user/mei)
2023-06-07 13:22:49 +0200 <gurkenglas> probie: very sensible. to defeat that perspective i would have to find a canonical-up-to-isomorphism grid of all the sensible algorithms and show that we only need the one order
2023-06-07 13:23:06 +0200 <gurkenglas> s/a/the/
2023-06-07 13:23:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:25:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:29:28 +0200 <Inst> this can't be real
2023-06-07 13:29:29 +0200 <Inst> https://paste.tomsmeding.com/Op9LaV6e
2023-06-07 13:29:33 +0200 <Inst> haven't tested it yet
2023-06-07 13:30:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:30:43 +0200hays(rootvegeta@fsf/member/hays)
2023-06-07 13:30:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:33:53 +0200 <Inst> nope, it's not
2023-06-07 13:33:55 +0200 <Inst> but this one is
2023-06-07 13:33:55 +0200 <Inst> https://paste.tomsmeding.com/dblZbXpa
2023-06-07 13:35:28 +0200acidjnk(~acidjnk@p200300d6e7072f2409bf9167a1faa0fe.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-06-07 13:36:38 +0200dcoutts(~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f)
2023-06-07 13:38:52 +0200 <ncf> can #haskell go one day without bickering about composition order or other syntactic bs
2023-06-07 13:38:59 +0200 <ncf> @where wadler's law
2023-06-07 13:38:59 +0200 <lambdabot> I know nothing about wadler's.
2023-06-07 13:39:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:40:03 +0200 <geekosaur> https://wiki.haskell.org/Wadler%27s_Law
2023-06-07 13:40:18 +0200 <geekosaur> which implies the answer is no 🙂
2023-06-07 13:42:17 +0200 <hpc> what we really need is to find somemthing pettier than the lexical syntax of comments to dominate our time
2023-06-07 13:42:26 +0200 <hpc> i vote for the interpretation of unicode graphemes :D
2023-06-07 13:42:32 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:42:58 +0200mheinzel(~mheinzel@2001:620:130:6092:f411:94c0:886d:9915)
2023-06-07 13:46:08 +0200__monty__(~toonn@user/toonn) (Ping timeout: 248 seconds)
2023-06-07 13:47:32 +0200lortabac(~lortabac@152.96.92.233)
2023-06-07 13:47:55 +0200 <geekosaur> I thought IRC vs. Matrix had self-nominated 😛
2023-06-07 13:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 13:49:15 +0200 <Profpatsch> probie: fwiw I follow the same rule
2023-06-07 13:49:25 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369)
2023-06-07 13:49:40 +0200 <Profpatsch> 90% of the time “what I want to think about first” is the f in f.g
2023-06-07 13:49:45 +0200 <Profpatsch> *err the g in f.g
2023-06-07 13:50:01 +0200 <ncf> we should jump to ω and argue about what to argue about next
2023-06-07 13:50:33 +0200 <Profpatsch> ncf: Composition order and ease & consistency of reading becomes hugely important once you try to get Haskell adopted in teams >3
2023-06-07 13:50:33 +0200 <hpc> ncf: i agree... wait a minute...
2023-06-07 13:50:45 +0200 <Profpatsch> With people who don’t breathe programming
2023-06-07 13:51:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 13:51:42 +0200 <hpc> i find that describing it as "f(g(...)), not f().g()" works well
2023-06-07 13:53:22 +0200 <probie> ncf: How about the benefits of ImportQualifiedPost?
2023-06-07 13:55:14 +0200 <merijn> I don't think the "intuitiveness" is as clear cut as all the people arguing for & like to pretend it is
2023-06-07 13:56:00 +0200 <merijn> I've taught Haskell to several people, several with 0 programming experience and nobody ever had any issues with ., so clearly it's not remotely universally more intuitive
2023-06-07 13:57:27 +0200 <Helle> I mean it makes sense if you have any mathematics background
2023-06-07 13:57:37 +0200 <merijn> Helle: None of them had that
2023-06-07 13:57:53 +0200 <gurkenglas> the allegedly intuitive order has going for it that you can describe the first steps of your program before you need to explain what the goal of your program is, which takes up additional swapspace
2023-06-07 13:58:16 +0200 <merijn> ?
2023-06-07 13:59:15 +0200mmhat(~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8)
2023-06-07 13:59:44 +0200 <gurkenglas> "Consider a MacGuffin. Its parts suggest that it would be generally useful to reorder it as follows. Corollary: We can now easily count its atoms." instead of "Here's how to count the atoms of a MacGuffin: ..."
2023-06-07 14:00:02 +0200 <jade[m]> imo it's simply because f . g is the 'same order' as f(g(x))
2023-06-07 14:00:10 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 14:00:21 +0200 <merijn> gurkenglas: You can make the reverse argument just as easily
2023-06-07 14:01:05 +0200 <Profpatsch> People say Lisp is “very intuitive”, yet I tried to teach a bunch of programming noobs the same thing in Scheme and Haskell, and they only got it when I used Haskell
2023-06-07 14:01:13 +0200 <probie> <half joking> If I have `f (g (h x))` I need to allocate space to temporarily store `f` and `g` when interpreting the meaning of the statement. If I CPS-ify thpse functions and go with `h x $ \hRes -> g hRes $ \gRes -> f gRes id` I don't need to remember what `h` or `g` was when considering `f`, just `gRes`
2023-06-07 14:01:19 +0200 <gurkenglas> merijn: you mean, start without specifying that the thing you have is a MacGuffin, instead deriving that your procedure for counting atoms works exactly on MacGuffins? that would be fair
2023-06-07 14:01:28 +0200 <Profpatsch> So there must be some objective parts, but many things are rather subjective and experience-based
2023-06-07 14:01:46 +0200 <merijn> gurkenglas: "We compute the X of (computing the Y of some input)"
2023-06-07 14:02:06 +0200 <Inst> Haskell tbh has a better syntax than Lisp for newbies; Lisp might be "simple" once you get it, but the parens thing is really offputting to the uninitiated
2023-06-07 14:02:18 +0200 <merijn> Profpatsch: 1) how big was your sample size and how representative was it? That's what you need to answer before you can attempt to generalise
2023-06-07 14:02:35 +0200mei(~mei@user/mei)
2023-06-07 14:02:36 +0200 <Profpatsch> merijn: iirc like 4
2023-06-07 14:02:44 +0200 <Profpatsch> anecdote of course
2023-06-07 14:02:46 +0200 <merijn> Profpatsch: and, not intended to be mean spirited, but 2) how do you know the problem is not your teaching?
2023-06-07 14:02:49 +0200 <Helle> Haskell's syntax is honestly one of the things that keeps having me go back to it even if I sometimes forget certain things exist by having to do stuff in other languages for too long
2023-06-07 14:03:04 +0200 <Profpatsch> merijn: I kinda controlled for it cause it was the same lesson just in different languages
2023-06-07 14:03:19 +0200 <Profpatsch> after they didn’t get the Scheme thing one bit, but maybe they were primed ofc
2023-06-07 14:03:21 +0200 <jade[m]> just from my own experience I would probably agree that haskell 'looks' easier than lisp and it less threatening
2023-06-07 14:03:29 +0200 <merijn> Profpatsch: That doesn't control for it, though. Because you might be good at teaching one language without being good at teaching the other
2023-06-07 14:03:33 +0200 <Profpatsch> heh
2023-06-07 14:03:59 +0200 <Profpatsch> anecdotally again, I switched to Haskell because I couldn’t figure out how `fold` works in clojure
2023-06-07 14:04:59 +0200 <probie> as in `reduce` or as in `reducers/fold`?
2023-06-07 14:05:53 +0200 <gurkenglas> merijn: to model how the reader digests it, we should split this into "Suppose we want to compute the X of something. We can do that if that thing was computed as the Y of something. We can do that if that something looks like our input.". ...I want to note that I know a person who I predict to have lost in the middle of that because of the ~"non-concreteness".
2023-06-07 14:06:03 +0200 <jade[m]> on a sidenote, I programmed in java again for the first time in like half a year again after mostly doing haskell, and I kept forgetting that I could use state?
2023-06-07 14:06:09 +0200 <jade[m]> I suppose that's a good thing?
2023-06-07 14:07:01 +0200 <merijn> jade[m]: Wait until you rediscover having to think about deep vs shallow copies :\
2023-06-07 14:07:11 +0200 <jade[m]> oh no.
2023-06-07 14:07:14 +0200 <[exa]> savage.
2023-06-07 14:07:15 +0200 <merijn> That's one day of python debugging I never got back
2023-06-07 14:07:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 14:08:05 +0200 <jade[m]> the problem is that I'll be working with probably mostly java in the next uh four years
2023-06-07 14:08:10 +0200 <jade[m]> starting at the first of august
2023-06-07 14:08:11 +0200 <merijn> For, like, 7 years all I did was Haskell and C++ and then I wante to write a simple recursive tree walk and collecting a dictionary of states at every leaf...got completely scuffed results
2023-06-07 14:08:29 +0200 <merijn> Forgot python has no value semantics and I have to explicitly copy the dictionary at each recursion
2023-06-07 14:08:44 +0200 <jade[m]> 😬
2023-06-07 14:08:48 +0200 <jade[m]> unfortunate
2023-06-07 14:09:09 +0200 <gurkenglas> merijn: did that take a day because you thought you knew what caused the bug, and the corresponding "fix" took a while?
2023-06-07 14:09:10 +0200 <merijn> I think I'd honestly rather write C++ (assuming C++11 or later) than python
2023-06-07 14:09:34 +0200 <merijn> gurkenglas: I thought my tree walk was wrong
2023-06-07 14:11:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 14:11:31 +0200machinedgod(~machinedg@93-136-37-239.adsl.net.t-com.hr)
2023-06-07 14:11:37 +0200gurkenglas.oO(could one run python in an expensive debug mode where everything is immutable?)
2023-06-07 14:12:03 +0200 <[exa]> gurkenglas: yeah but how do you monkeypatch classes to support __add__ etc?
2023-06-07 14:13:18 +0200 <gurkenglas> [exa]: on every method call, copy the RAM region
2023-06-07 14:13:52 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 248 seconds)
2023-06-07 14:14:25 +0200 <[exa]> gurkenglas: yeah but you typically need to replace it for everyone
2023-06-07 14:15:04 +0200 <gurkenglas> every pointer is dereferenced immediately. a dag that's 500 diamonds of pointers in sequence crashes with "benign immutable-debug-mode failure due to memory blowup"
2023-06-07 14:16:01 +0200 <jade[m]> <jade[m]> "the problem is that I'll be..." <- maybe they have scala teams
2023-06-07 14:16:32 +0200 <gurkenglas> just code in scala and have chatgpt mediate all your interactions with the company
2023-06-07 14:16:54 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 14:17:09 +0200CiaoSen(~Jura@145.224.74.19) (Ping timeout: 250 seconds)
2023-06-07 14:17:16 +0200 <jade[m]> hahaha
2023-06-07 14:17:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 14:19:19 +0200mei(~mei@user/mei)
2023-06-07 14:19:44 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 248 seconds)
2023-06-07 14:21:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 14:21:56 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-06-07 14:27:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 14:31:31 +0200comerijn(~merijn@145.90.225.5)
2023-06-07 14:31:44 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 14:32:27 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Read error: Connection reset by peer)
2023-06-07 14:37:10 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-07 14:37:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 14:37:55 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-06-07 14:38:10 +0200raehik(~raehik@82.21.176.157)
2023-06-07 14:38:20 +0200 <raehik> does there exist a unit type class? one with no superclasses or functions
2023-06-07 14:39:07 +0200 <raehik> I have an associated constraint and want an "identity" instance where there is no constraint
2023-06-07 14:39:07 +0200 <geekosaur> it'd be inaccessible…
2023-06-07 14:40:00 +0200 <raehik> is there any other way with ConstraintKinds to say `() =>`?
2023-06-07 14:40:19 +0200 <comerijn> raehik: Why do you need another way than that?
2023-06-07 14:40:30 +0200 <raehik> I have `type ClassC a :: Type -> Constraint` and I can't do `type ClassC Foo = ()`
2023-06-07 14:40:38 +0200 <geekosaur> because I don't think that works?
2023-06-07 14:40:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 14:41:02 +0200 <geekosaur> my first guess at it would be `x ~ x` for some `x`
2023-06-07 14:41:38 +0200 <geekosaur> (here would presumably be `Foo`)
2023-06-07 14:41:46 +0200 <comerijn> raehik: Why not?
2023-06-07 14:41:57 +0200 <comerijn> raehik: Pretty sure I did that in the past
2023-06-07 14:42:13 +0200 <raehik> comerijn: () is a Type. I don't know how to get a Constraint here
2023-06-07 14:42:14 +0200 <ncf> boo, uniqueness of identity proofs
2023-06-07 14:42:31 +0200 <comerijn> raehik: Ah, so it's TypeInType screwing everything up :p
2023-06-07 14:42:38 +0200 <comerijn> raehik: Lemme look up my old gist
2023-06-07 14:42:43 +0200 <geekosaur> comerijn, it may have worked by accident, back when `Constraint` was secretly `Type`
2023-06-07 14:43:25 +0200 <comerijn> Well, the problem is that () can be both the type () and emptry constraint :p
2023-06-07 14:44:01 +0200 <raehik> is my problem that I did `Type -> Constraint` in the assoc type..>?
2023-06-07 14:44:08 +0200 <comerijn> https://gist.github.com/merijn/6130082
2023-06-07 14:44:15 +0200 <comerijn> That used to work as recently as 8.10 or so
2023-06-07 14:44:18 +0200 <comerijn> I haven't tried 9.x
2023-06-07 14:44:46 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Remote host closed the connection)
2023-06-07 14:46:22 +0200 <raehik> comerijn: thanks. I think that would work fine, but I need a `Type -> Constraint` because it needs to have other arbitrary types plugged into it down the road
2023-06-07 14:46:46 +0200 <raehik> and that seems to be the issue. maybe I just write a type level Const?
2023-06-07 14:47:08 +0200 <comerijn> raehik: Can you paste the full snippet?
2023-06-07 14:47:08 +0200 <geekosaur> there is one, isn't there?
2023-06-07 14:47:57 +0200 <raehik> https://paste.tomsmeding.com/1EGVRc5f
2023-06-07 14:48:07 +0200 <geekosaur> (Data.Functor.Const)
2023-06-07 14:48:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 14:49:32 +0200 <raehik> geekosaur: Looks like Const on my 9.6 isn't kind polymorphic
2023-06-07 14:49:37 +0200 <raehik> %:k Const
2023-06-07 14:49:54 +0200 <raehik> how do I ask the bot to play ghci for me
2023-06-07 14:50:15 +0200 <geekosaur> % :set -XPolyKinds
2023-06-07 14:50:15 +0200 <yahb2> <no output>
2023-06-07 14:50:21 +0200 <geekosaur> % :k Const
2023-06-07 14:50:21 +0200 <yahb2> <interactive>:1:1: error: ; Not in scope: type constructor or class ‘Const’
2023-06-07 14:50:29 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-07 14:50:35 +0200 <geekosaur> % import Data.Functor.Const
2023-06-07 14:50:35 +0200 <yahb2> <no output>
2023-06-07 14:50:38 +0200 <geekosaur> % :k Const
2023-06-07 14:50:38 +0200 <yahb2> Const :: * -> k -> *
2023-06-07 14:52:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 14:53:07 +0200machinedgod(~machinedg@93-136-37-239.adsl.net.t-com.hr) (Ping timeout: 240 seconds)
2023-06-07 14:53:22 +0200 <raehik> oh well term-level Const can't be fully kind polymorphic b/c it has an 'a' value
2023-06-07 14:55:14 +0200 <raehik> can't use a type family either because they have to be fully expanded >:(
2023-06-07 14:55:43 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-06-07 14:56:30 +0200 <raehik> I don't like it, but `class UnitClass a where; instance UnitClass a where` works...
2023-06-07 14:56:44 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-07 14:56:52 +0200 <raehik> surely something like that exists somewhere. the nothing class
2023-06-07 14:57:04 +0200 <comerijn> I think it's somewhere in the kmetti-verse
2023-06-07 14:57:13 +0200 <raehik> the extended kmettverse
2023-06-07 14:58:17 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 14:59:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:01:14 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:04:35 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369)
2023-06-07 15:06:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:07:14 +0200chomwitt(~chomwitt@94.69.70.96)
2023-06-07 15:08:53 +0200le__ka(~l_k@213.24.134.106)
2023-06-07 15:09:35 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:10:56 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 248 seconds)
2023-06-07 15:11:17 +0200Pickchea(~private@user/pickchea)
2023-06-07 15:11:41 +0200le_ka(~l_k@213.24.134.106) (Ping timeout: 265 seconds)
2023-06-07 15:12:09 +0200 <raehik> Figured out the answer. I can move the Type arg to the left, so I'm returning a Constraint instead of a `Type -> Constraint`. I simply hadn't used that syntax before, weirdly enough, my assoc types always mirrored my instance type exactly :)
2023-06-07 15:12:29 +0200 <raehik> that way I can use `() :: Constraint` as normal
2023-06-07 15:12:35 +0200 <comerijn> \o/
2023-06-07 15:12:43 +0200 <comerijn> I was wondering if that was it, but I forgot to mention it
2023-06-07 15:12:45 +0200 <raehik> cheers for the help comerijn, geekosaur
2023-06-07 15:14:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:15:45 +0200 <Inst> i also finally understand where the Clojure guy is coming from
2023-06-07 15:16:10 +0200 <Inst> like, I'm trying to backport a modified Haskell / Python Bentley quicksort into C
2023-06-07 15:16:24 +0200 <Inst> turns out it's not trivial because Python is dynamic, while Haskell has ad-hoc polymorphism
2023-06-07 15:16:48 +0200 <Inst> or, in this case, parametric polymorphism
2023-06-07 15:17:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:23:08 +0200UnMecQuiSeBalade(~UnMecQuiS@2a01cb059179a60060cb669c531951e0.ipv6.abo.wanadoo.fr)
2023-06-07 15:23:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:23:46 +0200UnMecQuiSeBalade(~UnMecQuiS@2a01cb059179a60060cb669c531951e0.ipv6.abo.wanadoo.fr) (Client Quit)
2023-06-07 15:24:51 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-07 15:27:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:27:58 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:acb1:db44:b81f:adc5)
2023-06-07 15:28:21 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac)
2023-06-07 15:28:26 +0200Inst_(~Inst@2601:6c4:4081:2fc0:f10d:fbfc:9509:13bb)
2023-06-07 15:28:38 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 15:29:22 +0200use-value1(~Thunderbi@2a00:23c6:8a03:2f01:11c4:bb75:150b:3612)
2023-06-07 15:30:46 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-07 15:31:44 +0200Inst(~Inst@2601:6c4:4081:2fc0:c1fa:d834:4b7c:236d) (Ping timeout: 248 seconds)
2023-06-07 15:32:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:32:33 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:acb1:db44:b81f:adc5) (Ping timeout: 250 seconds)
2023-06-07 15:32:33 +0200use-value1use-value
2023-06-07 15:34:32 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369)
2023-06-07 15:34:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:35:48 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-06-07 15:39:22 +0200CiaoSen(~Jura@145.224.74.19)
2023-06-07 15:40:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 15:42:20 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net)
2023-06-07 15:43:42 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac)
2023-06-07 15:44:12 +0200oac__(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 15:44:35 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 15:52:07 +0200chomwitt(~chomwitt@94.69.70.96) (Ping timeout: 268 seconds)
2023-06-07 15:55:13 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-07 16:00:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 16:00:41 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-06-07 16:02:27 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 16:04:03 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-06-07 16:05:52 +0200cheater(~Username@user/cheater) (Read error: Connection reset by peer)
2023-06-07 16:06:01 +0200shapr(~user@2600:1700:c640:3100:65fd:cc0d:69b7:c4ce)
2023-06-07 16:08:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 16:09:14 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 16:09:36 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369)
2023-06-07 16:13:21 +0200mheinzel_(~mheinzel@2001:620:130:6092:2930:ff3b:d938:8b1b)
2023-06-07 16:15:20 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-07 16:16:20 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2023-06-07 16:16:27 +0200mheinzel(~mheinzel@2001:620:130:6092:f411:94c0:886d:9915) (Ping timeout: 265 seconds)
2023-06-07 16:16:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 16:20:15 +0200CiaoSen(~Jura@145.224.74.19) (Ping timeout: 256 seconds)
2023-06-07 16:20:35 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-06-07 16:21:05 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-06-07 16:21:14 +0200caryhartline(~caryhartl@168.182.58.169)
2023-06-07 16:26:23 +0200acidjnk(~acidjnk@p200300d6e7072f24f1c50d012e792cf9.dip0.t-ipconnect.de)
2023-06-07 16:28:25 +0200machinedgod(~machinedg@93-136-37-239.adsl.net.t-com.hr)
2023-06-07 16:30:15 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-06-07 16:31:01 +0200 <Athas> Is there a standard/library definition of this type? data Tree t = Leaf t | Node [Tree t]
2023-06-07 16:31:22 +0200 <Athas> It seems one of the simplest ways to define an n-ary tree, and it'd be nice to not have to define all the utility functions and instances myself.
2023-06-07 16:32:11 +0200 <comerijn> Athas: No values at the nodes?
2023-06-07 16:32:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 16:32:59 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369)
2023-06-07 16:33:09 +0200 <Athas> comerijn: no.
2023-06-07 16:33:11 +0200 <comerijn> Athas: Because if you have values at the nodes, then that's just Data.Tree from containers. If not, then I think I've seen it somewhere, but I don't recall where
2023-06-07 16:33:14 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-07 16:33:48 +0200 <Athas> Is this the kind of tree that is called a rose tree?
2023-06-07 16:34:18 +0200 <Athas> Looks like multiple things are called rose trees, but this is one of them.
2023-06-07 16:34:24 +0200 <comerijn> Athas: I think so, but then Data.Tree also claims to be a rose tree
2023-06-07 16:35:08 +0200 <geekosaur> was gonna say, I've certainly seen that style called out as a rose tree
2023-06-07 16:36:07 +0200 <Athas> Guess I'll have to spend some time writing up my own data type.
2023-06-07 16:36:20 +0200 <Athas> Might be fun. I rarely have a reason to write generic data structures.
2023-06-07 16:37:21 +0200 <probie> type Tree = Free ([])
2023-06-07 16:38:19 +0200 <Athas> Oh yeah, I guess that would do it. I wonder if all the instances are exactly as I need them.
2023-06-07 16:38:34 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-06-07 16:38:43 +0200 <Inst_> well, that's nice
2023-06-07 16:38:46 +0200Inst_Inst
2023-06-07 16:39:08 +0200 <Athas> And I already depend on 'free'.
2023-06-07 16:39:35 +0200 <Inst> It's probably because I can't figure out how to do this without cons, but it turns out that recursive quicksort in ST with vector is way more efficient than
2023-06-07 16:39:58 +0200 <Inst> with a list or vector buffer reducing the recursion to iteration
2023-06-07 16:43:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 16:45:03 +0200bionade24(~bionade24@2a03:4000:33:45b::1) (Remote host closed the connection)
2023-06-07 16:45:43 +0200bionade24(~bionade24@2a03:4000:33:45b::1)
2023-06-07 16:46:41 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-06-07 16:46:43 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 16:49:43 +0200lbseale(~quassel@user/ep1ctetus) (Remote host closed the connection)
2023-06-07 16:50:59 +0200lbseale(~quassel@user/ep1ctetus)
2023-06-07 16:55:57 +0200 <segfaultfizzbuzz> oh wow: " As such, just because you can do something in a single instruction doesn't necessarily mean it's fast. A few jobs ago a co-worker asked me to implement a copy function in embedded assembler to see if it would be faster. Turns out that the dozen instructions generated by the compiler were about 3x faster than my one-instruction party trick" - someone on the internet
2023-06-07 16:57:07 +0200 <[exa]> rare yet true
2023-06-07 16:57:15 +0200 <comerijn> I'm not even sure that's rare, tbh
2023-06-07 16:58:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 16:58:15 +0200 <comerijn> People like to pretend people working on, say, gcc are apparently morons whose only goal is generating bloat and unnecessary instructions, meanwhile 90% of programmers doesn't understand anything about modern CPUs
2023-06-07 16:58:32 +0200 <comerijn> Like the people working on compilers don't generate that code for a reason
2023-06-07 16:58:58 +0200 <segfaultfizzbuzz> i don't understand anything about modern cpus,...
2023-06-07 16:59:16 +0200 <probie> If I'm writing assembly by hand, I'm probably not going to be able to do loop unrolling as well as a compiler (and it makes changing my code so much harder)
2023-06-07 16:59:36 +0200 <comerijn> probie: You also don't spend your entire day staring at Intel architecture manuals ;)
2023-06-07 17:00:56 +0200 <comerijn> segfaultfizzbuzz: understandable, they're complicated messes and most people are content to just operate on how they *imagine* they work :p
2023-06-07 17:01:31 +0200 <comerijn> segfaultfizzbuzz: FWIW, Intel actually publishes really high quality documentation on what's *actually* fast for their chips
2023-06-07 17:01:46 +0200 <comerijn> segfaultfizzbuzz: If you google "Intel Optimization Reference Manual", you should find them
2023-06-07 17:01:55 +0200 <segfaultfizzbuzz> hehe yeah i only ride with intel
2023-06-07 17:02:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 17:02:11 +0200 <comerijn> But those are really low level details :p
2023-06-07 17:02:41 +0200 <comerijn> segfaultfizzbuzz: even if you don't, a lot of the things in there are transferable to other architectures to some extent
2023-06-07 17:03:59 +0200EvanR(~EvanR@user/evanr) (Ping timeout: 250 seconds)
2023-06-07 17:05:38 +0200 <geekosaur> that about one instruction being worse has been true on intel since the 8086/8088. the one-instruction copy loop has always been slower than doing it "by hand"
2023-06-07 17:07:10 +0200 <comerijn> Not to mention things like SIMD instructions downclocking your CPU, so alternating between SIMD and "regular" instructions cratering performance
2023-06-07 17:08:31 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-07 17:16:47 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-06-07 17:17:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 17:18:42 +0200bionade24(~bionade24@2a03:4000:33:45b::1) (Remote host closed the connection)
2023-06-07 17:19:04 +0200vandita(~vandit@84-236-21-42.pool.digikabel.hu) (Ping timeout: 268 seconds)
2023-06-07 17:20:17 +0200bionade24(~bionade24@2a03:4000:33:45b::1)
2023-06-07 17:20:21 +0200vandita(~vandit@178-164-213-114.pool.digikabel.hu)
2023-06-07 17:20:22 +0200AndreiDuma(~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-07 17:20:41 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 17:20:43 +0200lortabac(~lortabac@152.96.92.233) (Quit: WeeChat 2.8)
2023-06-07 17:21:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 17:24:07 +0200 <segfaultfizzbuzz> 128 core x86 cpus are coming 🤯
2023-06-07 17:24:23 +0200gmg(~user@user/gehmehgeh)
2023-06-07 17:24:28 +0200dcoutts(~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) (Ping timeout: 240 seconds)
2023-06-07 17:24:32 +0200 <geekosaur> now you need software that doesn't choke on the overhead of managing 128 cores
2023-06-07 17:25:04 +0200 <segfaultfizzbuzz> jobs
2023-06-07 17:27:01 +0200mheinzel_(~mheinzel@2001:620:130:6092:2930:ff3b:d938:8b1b) (Ping timeout: 265 seconds)
2023-06-07 17:27:10 +0200 <geekosaur> easy to say. but there's a couple dozen code monkeys who won't handle that many cores right for one davean who will
2023-06-07 17:27:18 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-06-07 17:27:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 17:27:32 +0200 <segfaultfizzbuzz> hehe
2023-06-07 17:28:54 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-06-07 17:31:24 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 265 seconds)
2023-06-07 17:31:39 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Quit: segfaultfizzbuzz)
2023-06-07 17:42:37 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-07 17:44:37 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-06-07 17:45:46 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 17:53:03 +0200econo(uid147250@user/econo)
2023-06-07 17:54:43 +0200caryhartline(~caryhartl@168.182.58.169)
2023-06-07 17:56:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 17:56:31 +0200machinedgod(~machinedg@93-136-37-239.adsl.net.t-com.hr) (Ping timeout: 240 seconds)
2023-06-07 17:57:08 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:01:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:02:19 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:06:37 +0200euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 240 seconds)
2023-06-07 18:09:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:10:34 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection)
2023-06-07 18:10:40 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:11:03 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-06-07 18:16:18 +0200oneeyedalien(~oneeyedal@125-63-26-10.ip4.superloop.au)
2023-06-07 18:17:11 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de)
2023-06-07 18:18:59 +0200oneeyedalien(~oneeyedal@125-63-26-10.ip4.superloop.au) (Client Quit)
2023-06-07 18:19:28 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:523d:9a8b:b2f4:ac13) (Remote host closed the connection)
2023-06-07 18:20:00 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-06-07 18:20:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:22:13 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:22:41 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2023-06-07 18:24:20 +0200_ht(~Thunderbi@82.174.52.28)
2023-06-07 18:26:35 +0200Sciencentistguy5(~sciencent@hacksoc/ordinary-member)
2023-06-07 18:29:20 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-06-07 18:29:27 +0200Sciencentistguy(~sciencent@hacksoc/ordinary-member) (Ping timeout: 256 seconds)
2023-06-07 18:29:28 +0200Sciencentistguy5Sciencentistguy
2023-06-07 18:30:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:33:35 +0200Lycurgus(~juan@user/Lycurgus)
2023-06-07 18:33:48 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:39:16 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-06-07 18:39:51 +0200vandita(~vandit@178-164-213-114.pool.digikabel.hu) (Ping timeout: 268 seconds)
2023-06-07 18:41:05 +0200vandita(~vandit@84-236-97-3.pool.digikabel.hu)
2023-06-07 18:41:35 +0200notzmv(~zmv@user/notzmv)
2023-06-07 18:45:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:47:44 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:49:02 +0200oac__(~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac__)
2023-06-07 18:49:21 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 18:50:43 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2023-06-07 18:50:47 +0200Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz)
2023-06-07 18:53:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 18:56:13 +0200comerijn(~merijn@145.90.225.5) (Ping timeout: 250 seconds)
2023-06-07 18:56:45 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 18:57:51 +0200ddellacosta(~ddellacos@146.70.166.139)
2023-06-07 19:02:52 +0200y04nn(~username@2a03:1b20:5:f011::aaae)
2023-06-07 19:03:11 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-06-07 19:05:55 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 19:08:45 +0200ystael(~ystael@user/ystael) (Read error: Connection reset by peer)
2023-06-07 19:09:23 +0200ystael(~ystael@user/ystael)
2023-06-07 19:11:41 +0200johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2023-06-07 19:16:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 19:20:35 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 19:23:01 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 19:28:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 19:30:03 +0200johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net)
2023-06-07 19:35:15 +0200 <[Leary]> If anyone figures out how to write a sorting algorithm with better than O(n^2) complexity in System F (or proves it impossible), let me know.
2023-06-07 19:35:34 +0200 <[Leary]> I'm unsniping myself of this problem ... devil willing, let some other poor sod be sniped in my place.
2023-06-07 19:36:16 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 19:37:38 +0200 <jade[m]> hm
2023-06-07 19:37:48 +0200 <jade[m]> sounds interesting
2023-06-07 19:38:29 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-06-07 19:40:41 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-07 19:41:31 +0200 <ncf> [Leary]: shouldn't you be able to adapt https://agda.github.io/agda-stdlib/Data.List.Sort.MergeSort.html#2550 ?
2023-06-07 19:47:48 +0200oac(~oac@72-50-214-210.fttp.usinternet.com) (Remote host closed the connection)
2023-06-07 19:51:50 +0200hisa387(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net)
2023-06-07 19:52:32 +0200fendor(~fendor@2a02:8388:1605:7500:3974:8f28:6b80:17ec) (Remote host closed the connection)
2023-06-07 19:52:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 19:54:28 +0200hisa38(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 268 seconds)
2023-06-07 19:54:28 +0200hisa387hisa38
2023-06-07 19:56:17 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds)
2023-06-07 19:59:26 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 20:01:15 +0200vandita(~vandit@84-236-97-3.pool.digikabel.hu) (Ping timeout: 256 seconds)
2023-06-07 20:02:49 +0200vandita(~vandit@92-249-193-31.pool.digikabel.hu)
2023-06-07 20:03:39 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 265 seconds)
2023-06-07 20:04:47 +0200 <[Leary]> ncf: Maybe, but it's not at all clear to me. There's a lot of casual pattern matching and constructor application involved, but doing the equivalent in System F without performance penalties requires extreme care.
2023-06-07 20:04:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 20:05:40 +0200 <ncf> have you tried asking on cstheory.stackexchange?
2023-06-07 20:07:07 +0200 <[Leary]> Nah, I haven't been on any of the stackexchanges in forever. Probably not worth breaking back in just for this curiosity.
2023-06-07 20:08:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 20:09:32 +0200 <ncf> wtf
2023-06-07 20:15:18 +0200 <sm> also, there's a strike on (stack exchange contributors protesting SE's new AI policy)
2023-06-07 20:15:53 +0200 <jade[m]> the one that disallows the use of chatgpt?
2023-06-07 20:16:33 +0200 <darkling> The one that forbids mods from removing things produced by AI.
2023-06-07 20:17:08 +0200 <sm> I think it's the reverse, SE has disallowed policies blocking chatgpt and (I read, do verify) disallowed them from talking about it
2023-06-07 20:17:28 +0200 <jade[m]> ahh, then a strike is reasonable
2023-06-07 20:17:38 +0200 <jade[m]> I agree with the ban fully
2023-06-07 20:17:53 +0200 <jade[m]> s/the ban/the ban of chatgpt/
2023-06-07 20:18:14 +0200EvanR(~EvanR@user/evanr)
2023-06-07 20:19:34 +0200 <sm> I heard about it on mastodon (#stackexchange tag) and https://openletter.mousetail.nl seems to be the home
2023-06-07 20:20:15 +0200 <sm> "the details of the policies issued directly to moderators differ substantially from the guidelines outlined publicly, with moderators barred from publicly sharing the details" - obvious red flag
2023-06-07 20:20:31 +0200 <sm> if true
2023-06-07 20:21:16 +0200 <jade[m]> I would hope and also assume they wouldn't lie about such a thing
2023-06-07 20:21:36 +0200 <jade[m]> i agree with this strike if it truly is how they say
2023-06-07 20:21:50 +0200 <sm> indeed, it's just we truly have to to fact check everything seen on the net these days
2023-06-07 20:22:32 +0200 <jade[m]> mhm
2023-06-07 20:22:42 +0200 <jade[m]> I have a lot of issues with chatgpt
2023-06-07 20:23:47 +0200 <EvanR> I read something suspicious, better consult chat-GPT
2023-06-07 20:24:33 +0200 <EvanR> I mean it's been 22 years since they achieved a computer who is incapable of making mistakes
2023-06-07 20:28:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 20:28:16 +0200 <probie> I wonder if we can use an LLM like ChatGPT to resolve the truly hard questions like "tabs or spaces"
2023-06-07 20:29:21 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-06-07 20:29:39 +0200 <jade[m]> it'll probably be the most generic "both have their advantages" answer with a few factual errors sprinkled in between
2023-06-07 20:29:43 +0200 <[exa]> we should have a formal class of tabspace-hard problems, with a reductions that allow us to also cease people from trying to solve other nonsense
2023-06-07 20:29:49 +0200 <[exa]> s/ a / /
2023-06-07 20:30:05 +0200 <[Leary]> I think dmwit already resolved that one. The answer, surprisingly, is "both".
2023-06-07 20:30:10 +0200gmg(~user@user/gehmehgeh)
2023-06-07 20:30:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 20:30:57 +0200 <geekosaur> "wadler-complete"
2023-06-07 20:31:45 +0200 <[exa]> [Leary]: (link? I'm curious. I'm using tabs for indent and spaces for aligning stuff, so wondering if there are other ways)
2023-06-07 20:32:19 +0200 <[Leary]> [exa]: http://dmwit.com/tabs/
2023-06-07 20:32:24 +0200biberu\(~biberu@user/biberu)
2023-06-07 20:32:31 +0200 <jade[m]> I just space everything, tabs are confusing and my brain is too small for that
2023-06-07 20:32:33 +0200 <darkling> I generally use carriage returns, backspace, and vertical tab for laying out my code. Zero-width space every so often, when it can't be spotted. :)
2023-06-07 20:32:48 +0200 <[Leary]> Though it sounds like you've already come to the same conclusion.
2023-06-07 20:33:10 +0200 <EvanR> what about form feed?
2023-06-07 20:33:34 +0200 <darkling> That would be weird.
2023-06-07 20:33:55 +0200 <[exa]> [Leary]: thanks! yeah that's it
2023-06-07 20:34:44 +0200 <[exa]> EvanR: I actually saw someone to use either that or vertical tabs to separate functions in the code
2023-06-07 20:35:08 +0200 <geekosaur> FF to separate C functions goes back further than I do 🙂
2023-06-07 20:35:12 +0200 <EvanR> that's why you should always have visible form feeds enabled
2023-06-07 20:35:28 +0200biberu(~biberu@user/biberu) (Ping timeout: 250 seconds)
2023-06-07 20:35:28 +0200biberu\biberu
2023-06-07 20:36:19 +0200 <jade[m]> > tabs for indentation, spaces for alignment
2023-06-07 20:36:19 +0200 <jade[m]> seems decent enough
2023-06-07 20:36:21 +0200 <lambdabot> <hint>:1:21: error: parse error on input ‘,’
2023-06-07 20:37:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 20:41:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 20:42:00 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection)
2023-06-07 20:42:55 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 20:43:17 +0200011AAD3PH(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-07 20:44:46 +0200 <sm> interesting: https://libera.chat/minutes/2023-03-31-public#where-are-we-on-matrix-changes
2023-06-07 20:47:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 20:47:57 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net)
2023-06-07 20:48:27 +0200raehik(~raehik@82.21.176.157) (Ping timeout: 250 seconds)
2023-06-07 20:50:48 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 20:50:55 +0200euandreh(~Thunderbi@189.6.18.7)
2023-06-07 20:52:54 +0200k``(~user@152.7.255.207)
2023-06-07 20:53:06 +0200euandreh1(~Thunderbi@189.6.18.7)
2023-06-07 20:53:28 +0200euandreh(~Thunderbi@189.6.18.7) (Client Quit)
2023-06-07 20:53:29 +0200euandreh1euandreh
2023-06-07 20:55:04 +0200Feuermagier(~Feuermagi@user/feuermagier)
2023-06-07 20:56:07 +0200ddellacosta(~ddellacos@146.70.166.139) (Ping timeout: 240 seconds)
2023-06-07 20:56:08 +0200 <k``> The package ffunctor defines `ffmap :: (Functor m, Functor n)=> (forall x. m x -> n x) -> f m -> f n` -- any idea why it has those `Functor` constraints?
2023-06-07 20:57:23 +0200 <jean-paul[m]> sm: it reads like "Libera channels must now opt-in to Matrix bridging"? Do I understand right?
2023-06-07 20:57:46 +0200 <k``> (by analogy, the `a` and `b` in `fmap :: (a -> b) -> m a -> m b` are not constrained)
2023-06-07 20:58:08 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 248 seconds)
2023-06-07 20:58:09 +0200 <ncf> k``: FFunctor is supposed to represent an endofunctor on the category of endofunctors on Hask
2023-06-07 20:58:20 +0200 <geekosaur> but I'm off for a bit
2023-06-07 20:59:09 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 21:01:11 +0200 <ncf> i don't know how ffunctor is used in practice so i can't tell if it would make sense to relax those constraints, but it at least theoretically makes a lot of sense
2023-06-07 21:01:19 +0200 <sm> jean-paul.: it reads to me like "portalled bridging (being able to join any libera channel from matrix) may go away at some point, plumbed bridging (rooms/channels which have explicitly set up a bridge) will remain"
2023-06-07 21:02:34 +0200 <k``> I don't understand category theory very well, but what is the meaning of endofunctor on the category of endofunctors on Hask when Hask isn't a category?
2023-06-07 21:02:42 +0200zxrom(~zxrom@mm-62-27-212-37.vitebsk.dynamic.pppoe.byfly.by)
2023-06-07 21:03:11 +0200 <ncf> ah, well i'm pretending it is :)
2023-06-07 21:03:13 +0200 <jade[m]> afaik hask has neither shown nor be disproven to be a category
2023-06-07 21:03:27 +0200 <[Leary]> k``: One or both of them (usually just the first) is liable to be necessary in practice. E.g. suppose you have `newtype Dup f x = Dup (f (f x))` and want `FFunctor Dup`.
2023-06-07 21:04:07 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 240 seconds)
2023-06-07 21:04:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 21:04:32 +0200 <ncf> jade[m]: well, the burden is arguably on the people who talk about "the category Hask" to define such a category; i'm just doing "fast-and-loose" reasoning here
2023-06-07 21:07:58 +0200 <k``> Fair enough. So you need ffmap f (Dup ffx) = Dup (f (fmap f ffx)), or Dup (fmap f (f ffx)), and there's no obvious choice which fmap should be used, so the best choice is to constrain both. Thanks, that completely answers my question.
2023-06-07 21:08:24 +0200 <probie> I've written a similar function before (or, I guess, really an instance of `ffmap` on `Fix`) `mapNT :: (Functor f, Functor g) => (forall x . f x -> g x) -> Fix f -> Fix g`
2023-06-07 21:08:27 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net)
2023-06-07 21:09:02 +0200 <ncf> (btw, note that it does not matter which of the definitions you give is used because f is assumed to be a natural transformation)
2023-06-07 21:09:24 +0200 <probie> I ended up requiring `g` to be a functor because in practice it pretty much always is, and it allowed me to add some `{-# RULES` I otherwise wouldn't have been able to write
2023-06-07 21:09:26 +0200 <EvanR> Hask is a category in the sense that pluto is a planet
2023-06-07 21:09:43 +0200 <jade[m]> heh
2023-06-07 21:09:52 +0200d34df00d(~d34df00d@2600:1702:4f1b:7c10::e) (Remote host closed the connection)
2023-06-07 21:09:52 +0200 <k``> (ncf: although it might matter a lot depending on the cost of `fmap` :)
2023-06-07 21:10:45 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:96ee:7cb:56b8:8ea4)
2023-06-07 21:11:19 +0200 <ncf> EvanR: at least i'm fairly certain that "Pluto" has a well-agreed-upon definition :p
2023-06-07 21:11:34 +0200 <probie> It's a dog
2023-06-07 21:11:55 +0200 <ncf> import System.Solar (Pluto)
2023-06-07 21:12:31 +0200 <chromoblob> poor Pluto :..(
2023-06-07 21:12:58 +0200 <k``> Just switch to a language where it's a "star".
2023-06-07 21:13:30 +0200 <k``> Pluto :: *
2023-06-07 21:13:31 +0200 <ncf> probie: just in case, that's hoistFix' from data-fix
2023-06-07 21:13:48 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-b9db-66de-a2df-2e68.rev.sfr.net)
2023-06-07 21:15:46 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 21:16:23 +0200 <k``> But, seriously though, now that I've got my real question answered, which is better Hask-wise? `instance Functor ((->) i) where fmap f g = f `seq` \ x -> f (g x)` or `instance Functor ((->) i) where fmap !f !g = \ x -> f (g x)`
2023-06-07 21:16:24 +0200 <probie> ncf: It's neither `hostFix` nor `hoistFix'`, since the constraint is on both. It doesn't really matter, since this bit of code (intentionally) has no non-base dependencies
2023-06-07 21:16:38 +0200 <probie> s/hostFix/hoistFix/
2023-06-07 21:17:03 +0200 <ncf> okay
2023-06-07 21:17:24 +0200 <probie> so my Fix doesn't come from `data-fix` (of course, it is the exact same definition)
2023-06-07 21:18:22 +0200 <k``> probis: What do you use it for?
2023-06-07 21:19:00 +0200 <probie> k``: If I told you `map` and `filter` over lists, would you believe me?
2023-06-07 21:21:08 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:96ee:7cb:56b8:8ea4) (Ping timeout: 240 seconds)
2023-06-07 21:21:46 +0200 <probie> https://paste.tomsmeding.com/sIfoZjzb
2023-06-07 21:22:02 +0200enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2023-06-07 21:22:08 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection)
2023-06-07 21:22:11 +0200 <k``> probis: Uhhh... I guess I'd be willing to believe that a Haskell programmer might do just about anything, but using a custom class to map natural transformations instead of `filter` ...
2023-06-07 21:23:01 +0200 <EvanR> so you want to delete an item from an array, first let me introduce you to some category theory
2023-06-07 21:24:00 +0200 <probie> Going back 10 steps, I wanted to create a functional programming language without recursion, or value level `fix`. Just `fold` and `unfold`. My belief was that by writing all these things as nice simple non-recursive functions and knowing how fold and unfold work we'd be able to do some decent optimisation
2023-06-07 21:24:12 +0200jade[m]fails to even understand the Fix type
2023-06-07 21:24:37 +0200vandita(~vandit@92-249-193-31.pool.digikabel.hu) (Ping timeout: 240 seconds)
2023-06-07 21:24:48 +0200 <probie> However, I wasn't sure if a) my belief about being easy to optimise was true, and b) whether it'd be a sufficiently painless language to live in
2023-06-07 21:25:49 +0200 <jade[m]> probie: sounds a little like APL heh
2023-06-07 21:25:55 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-06-07 21:26:34 +0200vandita(~vandit@178-164-188-17.pool.digikabel.hu)
2023-06-07 21:26:49 +0200 <probie> but I realised I can test both of those things myself in Haskell (the first by sprinkling appropriate rewrite rules, and the second by trying to write programs that use my library)
2023-06-07 21:29:30 +0200 <ncf> probie: you know you can get fix from Fix, yeah?
2023-06-07 21:30:22 +0200 <[Leary]> probie: I like to play around in such languages (System F, Dhall) sometimes. My conclusion: recursion is an optimisation.
2023-06-07 21:30:47 +0200dfit^(~dfit@c-71-204-38-59.hsd1.ga.comcast.net)
2023-06-07 21:33:37 +0200 <probie> ncf: You can probably get it more directly, but I've constructed it from `Fix (Either a)`. I don't want to lose turing completeness, I just don't want arbitrary recursion to be the first tool reached for.
2023-06-07 21:34:19 +0200 <EvanR> one way to achieve that is to name the arbitrary recursion something like ArbitraryRecursionTool
2023-06-07 21:34:36 +0200 <EvanR> instead of fix
2023-06-07 21:34:45 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 240 seconds)
2023-06-07 21:34:51 +0200 <EvanR> (syntactic salt)
2023-06-07 21:34:52 +0200 <probie> How about `arbitraryRecursionToolIConsiderToBeAsMorallyQuestionableAsGoto`?
2023-06-07 21:35:42 +0200 <ncf> probie: wait, how do you construct fix from Fix (Either a)?
2023-06-07 21:35:45 +0200 <jade[m]> that just looks like a class from an enterprise level java application
2023-06-07 21:35:55 +0200 <EvanR> scott manley had a recent video of the software for the gemini computer being drafted on huge paper in perfect pen strokes as a huge flow chart
2023-06-07 21:36:18 +0200 <EvanR> as long as that flow chart isn't broken, GOTO is the best way to implement it xD
2023-06-07 21:36:27 +0200 <monochrom> :)
2023-06-07 21:38:00 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:73b4:7d09:b688:3bad)
2023-06-07 21:38:08 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 240 seconds)
2023-06-07 21:38:33 +0200 <sm> jean-paul.: more recent info: https://libera.chat/news/matrix-irc-bridge-updates . Sounds like both sides are doing good work
2023-06-07 21:38:50 +0200 <ncf> (i'm actually fairly sure you can't, since Either a has a fixed point in the topos of trees)
2023-06-07 21:39:30 +0200 <ncf> no wait never mind
2023-06-07 21:39:58 +0200monochromfounds the Free Open Recursion Software movement. FORS.
2023-06-07 21:40:11 +0200machinedgod(~machinedg@93-136-37-239.adsl.net.t-com.hr)
2023-06-07 21:40:32 +0200 <monochrom> "free as in free monad" >:)
2023-06-07 21:40:40 +0200 <jean-paul[m]> sm: thanks
2023-06-07 21:41:35 +0200 <probie> ncf: you might be right. I think I'm getting confused with something else I did (it's 5:40 in the morning local time and I'm yet to go to bed)
2023-06-07 21:42:30 +0200 <probie> I'm probably thinking of something like `(a -> Either b a) -> b`
2023-06-07 21:42:41 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-06-07 21:42:42 +0200 <ncf> that sounds more plausible
2023-06-07 21:44:09 +0200 <monochrom> I use "newtype D a = MkD (D a -> a)". So with Fix it's probably first "newtype F a r = MkF (r -> a)" and then Fix (F a).
2023-06-07 21:46:40 +0200 <probie> ncf: fix = hylo (uncurry ($)) (\x -> (x,x)) -- Either and (,) are pretty much the same. It's an easy mistake to make
2023-06-07 21:47:09 +0200 <ncf> :t hylo
2023-06-07 21:47:10 +0200 <lambdabot> error: Variable not in scope: hylo
2023-06-07 21:47:22 +0200 <ncf> hylo :: Functor f => (f b -> b) -> (a -> f a) -> a -> b
2023-06-07 21:47:59 +0200 <ncf> hmm
2023-06-07 21:48:42 +0200pavonia(~user@user/siracusa)
2023-06-07 21:48:52 +0200 <ncf> confused
2023-06-07 21:49:16 +0200 <probie> let hylo f g = go where go = f . fmap go . g in hylo (uncurry ($)) (\x -> (x,x)) (\r n -> if n == 0 then 1 else n * r (n - 1)) 5
2023-06-07 21:49:25 +0200 <probie> > let hylo f g = go where go = f . fmap go . g in hylo (uncurry ($)) (\x -> (x,x)) (\r n -> if n == 0 then 1 else n * r (n - 1)) 5
2023-06-07 21:49:27 +0200 <lambdabot> 120
2023-06-07 21:49:30 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds)
2023-06-07 21:50:10 +0200 <probie> (in my world, hylo is primitive, hence why it's allowed a recursive definition)
2023-06-07 21:50:21 +0200 <ncf> oh right
2023-06-07 21:50:30 +0200 <k``> I am reminded of http://comonad.com/reader/2022/internalized-guarded-recursion-for-equational-reasoning/
2023-06-07 21:50:37 +0200 <ncf> so you're unfolding (a -> a) to an infinite tuple of itself, and then folding that by application
2023-06-07 21:50:45 +0200 <ncf> nice
2023-06-07 21:50:47 +0200 <probie> Yep
2023-06-07 21:50:48 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds)
2023-06-07 21:53:15 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 21:53:53 +0200 <probie> except I've lost the `Fix` along the way by merging my fold and unfold. `hylo f g = cata f . ana g` (and `ana :: Functor f => (a -> f a) -> a -> Fix f` and `cata :: Functor f => (f a -> a) -> Fix f -> a`
2023-06-07 21:56:29 +0200 <probie> those aren't the same as `cata` and `ana` from the recursion-schemes package, because there's no base functor shenanigans
2023-06-07 21:57:29 +0200nschoe(~q@2a01:e0a:8e:a190:9e55:3755:287b:82c1)
2023-06-07 21:58:32 +0200enoq(~enoq@194-208-133-121.lampert.tv)
2023-06-07 21:58:40 +0200 <probie> but the important thing is that given `calc = prod . map (+1) . filter even . map (+1) . enumTo`, I've got GHC generating reasonable core https://paste.tomsmeding.com/g8KzfGT6
2023-06-07 21:58:44 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net)
2023-06-07 21:58:58 +0200 <probie> which I was worried wouldn't happen with my weird filter definition
2023-06-07 21:59:10 +0200trev(~trev@user/trev) (Quit: trev)
2023-06-07 22:00:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:01:03 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:73b4:7d09:b688:3bad) (Remote host closed the connection)
2023-06-07 22:01:20 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:3e67:58a3:77f7:d5a5)
2023-06-07 22:02:06 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:07:42 +0200_ht(~Thunderbi@82.174.52.28) (Remote host closed the connection)
2023-06-07 22:08:01 +0200mheinzel_(~mheinzel@2001:1716:4614:4250:3e67:58a3:77f7:d5a5) (Ping timeout: 240 seconds)
2023-06-07 22:08:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:11:35 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:11:39 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection)
2023-06-07 22:12:32 +0200notzmv(~zmv@user/notzmv)
2023-06-07 22:13:30 +0200gurkenglas(~user@dynamic-046-114-176-088.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-06-07 22:13:50 +0200 <probie> monochrom: I assume you wanted something like this `fix f = (\x -> f (g x x)) $ Fix $ MkF $ \x -> f (g x x) where g (Fix (MkF a)) = a` (GHC's arch nemesis in another form)
2023-06-07 22:14:51 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-06-07 22:19:20 +0200gurkenglas(~user@46.114.176.88)
2023-06-07 22:19:33 +0200chomwitt(~chomwitt@94.69.70.96)
2023-06-07 22:19:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:21:44 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:25:22 +0200Pickchea(~private@user/pickchea)
2023-06-07 22:25:38 +0200le__ka(~l_k@213.24.134.106) (Quit: Leaving)
2023-06-07 22:29:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:31:11 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:36:13 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Quit: Leaving)
2023-06-07 22:36:54 +0200o-90(~o-90@gateway/tor-sasl/o-90)
2023-06-07 22:36:59 +0200o-90(~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection)
2023-06-07 22:41:28 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
2023-06-07 22:42:06 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-06-07 22:42:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:44:01 +0200zeenk(~zeenk@2a02:2f04:a106:3c00::7fe)
2023-06-07 22:44:54 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:51:05 +0200hugo(znc@verdigris.lysator.liu.se)
2023-06-07 22:52:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 22:54:02 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 22:55:48 +0200Square(~Square@user/square)
2023-06-07 22:56:10 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-06-07 22:56:32 +0200k``(~user@152.7.255.207) (Ping timeout: 248 seconds)
2023-06-07 23:03:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 23:04:34 +0200nek0(~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat)
2023-06-07 23:04:57 +0200lortabac(~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 250 seconds)
2023-06-07 23:06:13 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-06-07 23:06:29 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 23:10:09 +0200enoq(~enoq@194-208-133-121.lampert.tv) (Quit: enoq)
2023-06-07 23:10:18 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-06-07 23:11:55 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection)
2023-06-07 23:12:20 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-07 23:14:27 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-07 23:15:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 23:23:37 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 23:27:49 +0200michalz(~michalz@185.246.207.201) (Remote host closed the connection)
2023-06-07 23:30:32 +0200011AAD3PH(~oac@72-50-214-210.fttp.usinternet.com) (Remote host closed the connection)
2023-06-07 23:30:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 23:32:34 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-b9db-66de-a2df-2e68.rev.sfr.net) (Remote host closed the connection)
2023-06-07 23:32:44 +0200chomwitt(~chomwitt@94.69.70.96) (Remote host closed the connection)
2023-06-07 23:33:08 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-07 23:35:02 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 23:40:47 +0200biberu(~biberu@user/biberu) (Ping timeout: 268 seconds)
2023-06-07 23:41:07 +0200nschoe(~q@2a01:e0a:8e:a190:9e55:3755:287b:82c1) (Quit: Switching off)
2023-06-07 23:41:07 +0200vglfr(~vglfr@188.239.201.89) (Ping timeout: 256 seconds)
2023-06-07 23:42:36 +0200biberu(~biberu@user/biberu)
2023-06-07 23:43:02 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Remote host closed the connection)
2023-06-07 23:44:29 +0200vglfr(~vglfr@2a0d:3344:140c:2810:a8ed:895f:3485:d7a6)
2023-06-07 23:47:44 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds)
2023-06-07 23:48:13 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-07 23:52:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-07 23:53:38 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-07 23:53:38 +0200andreas303(andreas303@is.drunk.and.ready-to.party) (Ping timeout: 246 seconds)
2023-06-07 23:54:05 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-06-07 23:58:40 +0200cheater(~Username@user/cheater)
2023-06-07 23:58:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)