Logs on 2023-06-07 (liberachat/#haskell)
| 00:01:38 | <juri_> | "drawn, quartered, or given many beers"? |
| 00:02:33 | <juri_> | this showed up as "CI is busted, no-one can merge anything" |
| 00:03:27 | → | forell joins (~forell@user/forell) |
| 00:03:46 | <juri_> | so, good job, enjoy the assassination squad at zurihac. |
| 00:06:53 | × | byte quits (~byte@user/byte) (Remote host closed the connection) |
| 00:07:42 | <geekosaur> | I think the assassination squad is reserved for the cryptonite -> crypton mess |
| 00:07:43 | → | byte joins (~byte@user/byte) |
| 00:11:11 | × | mei quits (~mei@user/mei) (Remote host closed the connection) |
| 00:13:36 | → | mei joins (~mei@user/mei) |
| 00:17:01 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 00:18:36 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 00:19:45 | × | forell quits (~forell@user/forell) (Ping timeout: 240 seconds) |
| 00:21:38 | <Axman6> | the what??? |
| 00:22:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 00:23:17 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 256 seconds) |
| 00:24:16 | × | paddymahoney quits (~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Read error: Connection reset by peer) |
| 00:24:48 | <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) |
| 00:25:36 | → | forell joins (~forell@user/forell) |
| 00:25:42 | <Axman6> | "Crypton is a fork from cryptonite with the original authoer's permission." I guess the haskell-crypto fork is without permission? |
| 00:26:01 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 00:27:21 | × | jmd_ quits (~jmdaemon@user/jmdaemon) (Ping timeout: 250 seconds) |
| 00:28:08 | × | Me-me quits (~me-me@2602:ff16:3:0:1:dc:beef:d00d) (Changing host) |
| 00:28:08 | → | Me-me joins (~me-me@user/me-me) |
| 00:29:52 | <glguy> | Isn't the haskell-crypto one just the official repo? |
| 00:29:58 | <glguy> | (linked from https://hackage.haskell.org/package/cryptonite) |
| 00:30:53 | <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 |
| 00:30:56 | × | bontaq quits (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 00:32:15 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 00:32:36 | × | user____3 quits (~user@dynamic-046-114-177-202.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 00:32:36 | <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 |
| 00:33:02 | <segfaultfizzbuzz> | i am doing some searches for *compressed* memoization and nothing is turning up... has stuff been written about such a thing? |
| 00:33:22 | <Axman6> | compressed in which sense? |
| 00:33:54 | × | ijqq quits (uid603979@id-603979.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 00:34:02 | → | mvk joins (~mvk@2607:fea8:5c9a:a600::94ca) |
| 00:34:03 | <segfaultfizzbuzz> | well when memoization occurs i assume there is some kind of hash table which mutates and stores the function input-output mapping? |
| 00:34:33 | <Axman6> | that very much depends on the types of the arguments |
| 00:34:42 | <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 |
| 00:35:07 | <Axman6> | using hash-tables is one implementation, but it's not sensible to do tat for many types, or there are more efficient implementations |
| 00:35:12 | × | mvk quits (~mvk@2607:fea8:5c9a:a600::94ca) (Client Quit) |
| 00:36:27 | <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 |
| 00:36:36 | <segfaultfizzbuzz> | like maybe more like O(log(N)) or something |
| 00:36:37 | × | forell quits (~forell@user/forell) (Ping timeout: 240 seconds) |
| 00:36:44 | → | mvk joins (~mvk@2607:fea8:5c9a:a600::94ca) |
| 00:37:55 | <Axman6> | you should go look at the MemoTrie package (and I'm sure there's an associated paper) |
| 00:38:10 | → | extor joins (~extor@ns3018124.ip-149-202-82.eu) |
| 00:38:22 | <segfaultfizzbuzz> | cool i will check it out |
| 00:38:34 | <Axman6> | using a hashtable for Bool doesn't make any sense, a fiunction Bool -> a can be represented as (a,a) |
| 00:38:57 | <segfaultfizzbuzz> | well that's a somewhat pathological example |
| 00:39:10 | × | mvk quits (~mvk@2607:fea8:5c9a:a600::94ca) (Client Quit) |
| 00:39:33 | <segfaultfizzbuzz> | wow MemoTrie was last maintained in 2019 though |
| 00:40:05 | <Axman6> | not really relevant for a fundamental idea |
| 00:40:19 | <segfaultfizzbuzz> | ok sure if we are talking about this as a concept rather than as software |
| 00:41:20 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds) |
| 00:41:28 | <Axman6> | you should understand the concept before trying to optimise it :) |
| 00:42:31 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 00:45:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 00:46:45 | <segfaultfizzbuzz> | ok i don't see a mention of a *compressed* trie in this repo,... maybe something in the code makes use of this? |
| 00:48:44 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 00:50:46 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds) |
| 00:51:16 | <probie> | You can compress your memoization table to 0 bytes by just not memoizing |
| 00:51:51 | <segfaultfizzbuzz> | sigh, mathematics classes can really damage the mind, enroll with caution |
| 00:53:40 | <probie> | What does it have to be compression, why not an LRU cache? |
| 00:56:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 00:57:03 | <Axman6> | segfaultfizzbuzz: you should consider reading Conal's posts on the topic: http://conal.net/blog/tag/trie |
| 00:59:58 | <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 |
| 01:01:31 | <Axman6> | efficient memoisation depends strongly on the argument types |
| 01:04:46 | <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 |
| 01:05:13 | <Axman6> | 64 bits should be enough for anyone |
| 01:05:15 | <EvanR> | a tiny part of the range of Double |
| 01:05:36 | <segfaultfizzbuzz> | oh wow hashtables are rare? i didn't realize |
| 01:05:37 | → | wroathe joins (~wroathe@207.153.38.140) |
| 01:05:37 | × | wroathe quits (~wroathe@207.153.38.140) (Changing host) |
| 01:05:37 | → | wroathe joins (~wroathe@user/wroathe) |
| 01:07:22 | <segfaultfizzbuzz> | EvanR: tablemaker's dilemma is the poor man's halting problem? hehe |
| 01:08:42 | <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 |
| 01:08:59 | <segfaultfizzbuzz> | Smart Memoization (TM) |
| 01:09:08 | <segfaultfizzbuzz> | the first trademarked computer language feature |
| 01:09:36 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 01:09:57 | <EvanR> | https://en.wikipedia.org/wiki/Rounding#Table-maker.27s_dilemma |
| 01:10:43 | × | albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 01:16:51 | → | albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 01:22:11 | × | waleee quits (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 265 seconds) |
| 01:24:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 01:25:33 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 01:29:59 | × | zaquest quits (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 01:31:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 01:32:23 | <segfaultfizzbuzz> | what do haskell folks thing of kokalang? |
| 01:36:55 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 01:37:51 | × | abrantesasf quits (~abrantesa@177.137.232.92) (Remote host closed the connection) |
| 01:38:26 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 01:43:11 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 01:44:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 01:45:54 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 01:56:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 01:57:04 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 01:58:53 | × | xff0x_ quits (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 265 seconds) |
| 01:59:25 | <Inst> | here's a question, is it worth it |
| 01:59:38 | <segfaultfizzbuzz> | Inst: talking to me? |
| 01:59:41 | <Inst> | to pass huge numbers of variables around instead of using the <- closure |
| 01:59:49 | <Inst> | for monadic code? |
| 02:00:15 | <Inst> | i guess you could use let and implicit params to avoid the performance cost, no? |
| 02:00:21 | <Inst> | the fear is 100-line do blocks |
| 02:07:39 | × | mmhat quits (~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
| 02:09:02 | × | dcoutts quits (~duncan@212.221.20.36) (Ping timeout: 265 seconds) |
| 02:12:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 02:14:08 | → | werneta joins (~werneta@70.142.214.115) |
| 02:14:50 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 02:15:47 | → | nate2 joins (~nate@98.45.169.16) |
| 02:20:35 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 02:20:35 | → | finn_elija joins (~finn_elij@user/finn-elija/x-0085643) |
| 02:20:35 | finn_elija | is now known as FinnElija |
| 02:21:31 | → | whatsupdoc joins (uid509081@id-509081.hampstead.irccloud.com) |
| 02:21:46 | → | merijn joins (~merijn@86.86.29.250) |
| 02:23:17 | <Inst> | also, is the a well-known haskell meme? |
| 02:23:32 | <Inst> | https://hackage.haskell.org/package/base-4.18.0.0/docs/src/GHC.Exts.html#the |
| 02:24:05 | → | forell joins (~forell@user/forell) |
| 02:24:39 | <segfaultfizzbuzz> | that's a nice function, i like it |
| 02:25:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 02:26:34 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 02:29:26 | <sm> | why :) |
| 02:29:34 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 02:31:20 | <Inst> | "segfaultfizzbuzz" |
| 02:31:30 | <Inst> | felt inclined to compare Data.Array to the |
| 02:31:42 | <Inst> | some folk brought it up on Discord |
| 02:33:48 | <sm> | nope the is not a thing people use |
| 02:34:47 | → | eggplantade joins (~Eggplanta@104.55.37.220) |
| 02:37:32 | <Inst> | i mean that it's a meme |
| 02:37:53 | <Inst> | "advanced head" |
| 02:38:16 | <sm> | nope not a meme either :) |
| 02:40:30 | → | xff0x_ joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 02:42:02 | <sm> | what did you mean by passing huge numbers or variables Inst ? ie, function arguments instead of using Reader monad ? |
| 02:46:35 | <Inst> | i guess you're talking more readerT IO? |
| 02:46:45 | <Inst> | but straight IO functions are more lightweight |
| 02:47:40 | <sm> | you can always collect parameters in a single type and pass that around |
| 02:47:42 | × | [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 02:48:04 | <Inst> | or just keep them open |
| 02:48:13 | × | taupiqueur4 quits (~taupiqueu@2a02-842a-8180-4601-fc1a-de08-4257-8549.rev.sfr.net) (Ping timeout: 265 seconds) |
| 02:49:25 | → | dcoutts joins (~duncan@212.140.138.201) |
| 02:51:36 | × | td_ quits (~td@i53870912.versanet.de) (Ping timeout: 265 seconds) |
| 02:52:00 | → | taupiqueur4 joins (~taupiqueu@2a02-842a-8180-4601-fc1a-de08-4257-8549.rev.sfr.net) |
| 02:52:59 | → | td_ joins (~td@i5387091A.versanet.de) |
| 02:55:07 | × | merijn quits (~merijn@86.86.29.250) (Ping timeout: 250 seconds) |
| 03:00:41 | <davean> | Inst: what do you think is more light weight about IO functions? |
| 03:01:00 | <Inst> | readerT, I'm told, imposes a performance overhead? |
| 03:01:13 | → | dcoutts_ joins (~duncan@81.145.206.41) |
| 03:01:23 | <davean> | Who tells you that?⎈ |
| 03:01:36 | <davean> | And I mean doing anything imposes and overhead |
| 03:01:58 | <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 |
| 03:03:36 | <Inst> | the alternative is straight IO functions that take an argument |
| 03:03:39 | <davean> | You realize that -> is Reader, right? Every function is Reader. |
| 03:03:42 | × | jero98772 quits (~jero98772@2800:484:1d7f:5d36::1) (Remote host closed the connection) |
| 03:03:45 | × | dcoutts quits (~duncan@212.140.138.201) (Ping timeout: 240 seconds) |
| 03:03:51 | <davean> | So are you talking about an alternative here? |
| 03:04:01 | <Inst> | calling ask / asks to get the argument imposes an overhead |
| 03:04:03 | <davean> | Or are you talking about two ways of writing *litterly exactly the same thing* |
| 03:04:22 | × | Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 03:04:49 | <davean> | ask = id |
| 03:05:23 | <davean> | Really? Really? Go compile them - look at the assembly, see *exactly the same instructions* |
| 03:05:49 | <Inst> | so you're implying readerT is free, no? |
| 03:06:02 | <Inst> | asks shouldn't be free, though |
| 03:06:11 | <davean> | Yes, yes they should. |
| 03:06:32 | <davean> | I just showed you hwo |
| 03:07:04 | <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 |
| 03:07:07 | <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 |
| 03:07:17 | <davean> | You are *not* passing it around, thats crazy talk. |
| 03:07:34 | <davean> | No more than a function does. |
| 03:07:38 | <Inst> | okay, more correctly, it's a composition of functions |
| 03:07:49 | <Inst> | ReaderT has a constructor, though, around the function |
| 03:07:56 | <sm> | Inst: I hear you |
| 03:08:34 | <davean> | Note I mentioned that was the part that COULD but it DOES eliminate reliably, but *ask* on (->) can not. |
| 03:08:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 03:09:01 | <Inst> | the other advantage of just directly using IO functions to pass arguments around |
| 03:09:09 | <Inst> | you don't have to go through the readerT apparatus |
| 03:09:24 | <Inst> | just straight, arguments to a function |
| 03:09:54 | <Inst> | data MyPackage might be better structure |
| 03:10:04 | <davean> | newtype r (m :: Type -> Type) a = ReaderT (r -> m a) |
| 03:10:23 | <Inst> | ah |
| 03:11:16 | <davean> | You're looking in the wrong places for performance differences |
| 03:11:44 | <davean> | the thing that *actually* affects things are like potential arity change by you implimenting it differently. |
| 03:11:57 | <davean> | GHC spots "expected" arity and optimizes based on that. |
| 03:12:13 | <Inst> | so the compiler optimizations / rewrite rules are done already for readerT |
| 03:12:34 | <Inst> | it's probably my fault, I was discussing whether Reader was actually a closure |
| 03:12:52 | <davean> | so "f :: a -> b - c" done "f a b = g" and "f a = \b -> g" and "f = \a -> \b -> g" all perform differently. |
| 03:12:56 | <Inst> | the difference is probably based on the notion that closures can pass data more efficiently than normal functions can |
| 03:13:17 | <davean> | Its not even rewrites. |
| 03:13:19 | → | meinside joins (uid24933@id-24933.helmsley.irccloud.com) |
| 03:13:51 | <Inst> | i guess i'll screw around with that for a while |
| 03:14:47 | <davean> | "do p <- e1; e2 = e1 >>= \p -> e2" BTW |
| 03:14:52 | <davean> | https://www.haskell.org/tutorial/monads.html |
| 03:14:55 | <davean> | So you see? |
| 03:15:34 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 03:15:53 | <davean> | There *are* ways to get efficiency differences but they're not quite where you're looking |
| 03:16:05 | <Inst> | i know about do desugaring |
| 03:16:07 | <davean> | Its about the information you give the compiler |
| 03:16:09 | <davean> | like arity |
| 03:18:00 | <sm> | practically speaking in the context of a GUI app this stuff just doesn't matter, right |
| 03:18:14 | <davean> | Not even a tiny, tiny bit |
| 03:18:34 | <davean> | Not on the GUI side at least |
| 03:18:57 | × | nate2 quits (~nate@98.45.169.16) (Ping timeout: 250 seconds) |
| 03:20:27 | <davean> | These things come up when you want to be faster than C. Which isn't actually that hard with Haskell. |
| 03:21:14 | <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 |
| 03:22:00 | <sm> | does it run, does it make pretty pictures, is it useful, is it proving Haskell has apps |
| 03:22:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 03:24:07 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 240 seconds) |
| 03:25:37 | × | dcoutts_ quits (~duncan@81.145.206.41) (Ping timeout: 240 seconds) |
| 03:27:56 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 03:49:40 | → | trev joins (~trev@user/trev) |
| 03:53:13 | → | dcoutts_ joins (~duncan@81.145.206.45) |
| 03:56:27 | × | mokee quits (~mokee@37.228.215.134) (Quit: Lost terminal) |
| 04:02:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 04:02:55 | <Inst> | tbh i need to get better at this, like, at least i need to figure out how three-penny-gui works |
| 04:03:04 | <Inst> | it'd be really cool to figure out how to adopt monomer to servant |
| 04:03:24 | <Inst> | someone told me that they were planning to move monomer to Android, at least |
| 04:04:15 | <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 |
| 04:04:22 | <sm> | that's a long shot, I'd be writing smaller easier apps long before that |
| 04:04:42 | <Inst> | yeah i'm totally sidetracked by trying to understand how the library works at the source code level |
| 04:04:44 | <sm> | well today that's kind of swift or flutter |
| 04:04:48 | <sm> | or the web |
| 04:06:00 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 04:07:12 | → | _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 04:12:14 | → | dcoutts__ joins (~duncan@212.140.138.205) |
| 04:13:45 | <Square> | is there some way of writing lambda expression for multiple argument patterns? like, "fkn = \a (Just b) c -> ... ; \a Nothing c -> ..." |
| 04:14:14 | <Axman6> | I think there'd discussion of a proposal to do it, lambda cases or something |
| 04:14:31 | <Square> | ok. Thanks. Ill google that |
| 04:14:37 | <Axman6> | so, \cases a (Just b) c -> ...; a Nothing b -> ... IIRC |
| 04:14:37 | × | dcoutts_ quits (~duncan@81.145.206.45) (Ping timeout: 240 seconds) |
| 04:17:32 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 04:18:03 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 04:19:44 | × | foul_owl quits (~kerry@94.140.8.26) (Ping timeout: 246 seconds) |
| 04:21:05 | → | chromoblob joins (~user@37.113.158.8) |
| 04:22:37 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 04:23:08 | → | dcoutts_ joins (~duncan@81.145.206.45) |
| 04:23:31 | <Inst> | \cases iirc is active in latest GHC |
| 04:23:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 04:23:50 | <Inst> | since 9.4, i think |
| 04:23:52 | <Inst> | also, a question |
| 04:23:57 | <Inst> | philosophical, I guess |
| 04:24:05 | <Inst> | is VoidF a functor? If so, why isn't it an applicative? |
| 04:24:07 | × | dcoutts__ quits (~duncan@212.140.138.205) (Ping timeout: 256 seconds) |
| 04:24:22 | <Inst> | the way I understand it is that you can't implement pure |
| 04:24:31 | <Inst> | data VoidF a |
| 04:24:33 | <Axman6> | what is VoidF |
| 04:24:53 | <Axman6> | oh, yeah can't implement pure without absurd I guess |
| 04:25:07 | <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 |
| 04:25:28 | <Inst> | second, VoidF can be a functor, but can't be an applicative, because you can't implement pure without absurd / undefined / semantic equivalents |
| 04:25:38 | <Inst> | third, VoidF can be a functor, applicative, and monad, via the undefined trick |
| 04:25:51 | <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" |
| 04:26:15 | <Inst> | i wonder what exciting segfaults I'll get from unsafeCoerce void |
| 04:26:19 | <Inst> | VoidF |
| 04:26:35 | <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 |
| 04:26:55 | <Inst> | so applicative is where the whole thing falls apart |
| 04:27:15 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 04:27:36 | <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 |
| 04:29:07 | × | chromoblob quits (~user@37.113.158.8) (Ping timeout: 240 seconds) |
| 04:30:17 | <Inst> | I'm just trying to ruin someone by teaching them monads via Void ;) |
| 04:31:01 | <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 |
| 04:33:11 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 256 seconds) |
| 04:33:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 04:33:37 | → | foul_owl joins (~kerry@71.212.137.212) |
| 04:36:57 | × | wroathe quits (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 04:36:59 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 04:37:01 | <jackdk> | Axman6: `Pointed` is usually the name for it, but it's not very popular. |
| 04:37:15 | <dibblego> | stab it in its useless face |
| 04:37:21 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 04:38:24 | × | dcoutts_ quits (~duncan@81.145.206.45) (Ping timeout: 248 seconds) |
| 04:40:00 | → | takuan joins (~takuan@178-116-218-225.access.telenet.be) |
| 04:41:56 | <Axman6> | it's a rebel class with out a cause, lawless and free |
| 04:47:10 | → | michalz joins (~michalz@185.246.207.201) |
| 04:47:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 04:50:57 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 04:54:14 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac) |
| 04:54:32 | → | oac joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 05:00:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 05:02:57 | × | turlando quits (~turlando@user/turlando) (Ping timeout: 250 seconds) |
| 05:03:40 | → | turlando joins (~turlando@user/turlando) |
| 05:05:04 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 05:06:33 | <Inst> | interesting |
| 05:06:45 | <Inst> | if you trigger an incomplete patterns error, for anyone actually using Haskell's exception mechanism |
| 05:07:07 | <Inst> | it'll evaluate the term in the case expression |
| 05:07:29 | <Axman6> | the one you're matching over? |
| 05:07:44 | <Axman6> | that's basically the whole point of case statements, to evaluate things |
| 05:09:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 05:09:21 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 265 seconds) |
| 05:10:25 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 05:11:09 | <Inst> | ummm, why? |
| 05:11:40 | <Inst> | but tbh it's a weird edge case |
| 05:11:59 | <Inst> | hmmm, let me try again with an infinite list |
| 05:13:46 | <Inst> | also this is pretty weird |
| 05:13:57 | <Inst> | with an infinite list, the first term is actually evaluated |
| 05:14:16 | <Inst> | it doesn't actually need to evaluate such, can :sprint (_:_) |
| 05:18:32 | <Inst> | production haskeller i knew told me simply "nothing about non-exhaustive patterns is weird. They break everything" |
| 05:20:36 | → | chromoblob joins (~user@37.113.158.8) |
| 05:21:35 | <Axman6> | Inst: th epoint of a case statement is literally to evaluate an expression far enough to know if it matches the cases |
| 05:21:59 | <Inst> | which is what's weird |
| 05:22:02 | <Inst> | it's matching too far |
| 05:22:18 | <Inst> | like, it only needs to evaluate the list as far as the constructors go |
| 05:22:28 | <Axman6> | only if you told it to, or the const6ructor's value depends on evaluating something else first |
| 05:22:36 | <c_wraith> | if you just want to bind names and defer evaluation, that's what ~ is for |
| 05:22:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 05:23:31 | <Inst> | iirc, lists are doubly lazy, right? |
| 05:23:35 | <Inst> | lazy in leaves, lazy in spine |
| 05:23:53 | <Inst> | if code needs to see : vs [], there's no reason either to evaluate the leaf or the spine, right? |
| 05:24:24 | <Inst> | the sprint should only return an (_:_) |
| 05:24:27 | <c_wraith> | and if that's all you match, it won't evaluate further. |
| 05:24:40 | <c_wraith> | but you need to consider the body of the case as well |
| 05:24:49 | × | ddellacosta quits (~ddellacos@143.244.47.100) (Ping timeout: 265 seconds) |
| 05:25:13 | × | byte quits (~byte@user/byte) (Ping timeout: 268 seconds) |
| 05:25:35 | <Inst> | oh, i think i know the difficulty |
| 05:25:43 | <Inst> | the weirdness is coming because i'm using enum ranges |
| 05:25:58 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 05:26:03 | <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. |
| 05:26:46 | <Inst> | or maybe it's overloaded lists being weird? Ugh |
| 05:27:31 | <c_wraith> | Well, overloaded lists do mean you're no longer working with []. They had better have different semantics. |
| 05:28:05 | <Inst> | [1,2,3] :: [Int] |
| 05:28:19 | <Inst> | gets the entire list fully evaluated when passed to foo [] = 3, foo bar = 4 |
| 05:28:47 | <c_wraith> | as in, that literal appears in code? Well, GHC probably compiles it such that it never contains an unevaluated expression. |
| 05:29:04 | <Inst> | okay, what the hell |
| 05:29:08 | <Inst> | without overloaded lists being on |
| 05:29:26 | <Inst> | adding a type annotation causes the list to be fully evaluated in GHCI? |
| 05:29:48 | <c_wraith> | sure. why wouldn't it? |
| 05:30:04 | <c_wraith> | there is no potential bottom hiding there. Everything is a literal with a known type |
| 05:30:09 | <c_wraith> | and a known value |
| 05:30:50 | × | _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 05:31:04 | <Inst> | <Inst> like, it only needs to evaluate the list as far as the constructors go |
| 05:31:10 | <c_wraith> | only *needs to* |
| 05:31:14 | <Inst> | excuse me |
| 05:31:16 | <Inst> | mispaste |
| 05:31:24 | <Inst> | ghci> u = [1,2,undefined] :: [Int] |
| 05:31:24 | <Inst> | ghci> :sprint u |
| 05:31:24 | <Inst> | u = [1,2,_] |
| 05:31:45 | <c_wraith> | and? what's wrong with that? |
| 05:32:04 | <Inst> | is it correct to call it semantics because this is an evaluation thing? |
| 05:32:17 | <c_wraith> | it's not an evaluation thing because you're not doing any evaluation |
| 05:32:29 | <c_wraith> | That's just what it's compiled to. |
| 05:32:36 | <Inst> | well, u :: [Int] as a type signature behaves differently from u :: [Int] as a type annotation |
| 05:33:03 | → | byte joins (~byte@user/byte) |
| 05:33:17 | <c_wraith> | You're going very far into the weeds. |
| 05:33:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 05:33:35 | → | mbuf joins (~Shakthi@49.207.178.186) |
| 05:33:44 | <c_wraith> | The relevant questions are "when I evaluate this, what does it need to be evaluated?" |
| 05:34:18 | <c_wraith> | "did GHC remove some thunks from how it compiled this literal?" is completely irrelevant |
| 05:34:35 | <Inst> | https://media.discordapp.net/attachments/968989726633779215/1115876404563816478/image.png?width=540&height=540 |
| 05:34:39 | <Inst> | this is too late, i guess |
| 05:34:42 | <Inst> | thanks for humoring me |
| 05:35:38 | <c_wraith> | that's interesting, though. It would suggest ghci treats multiline literals specially. |
| 05:35:50 | <c_wraith> | That's kinda neat. |
| 05:35:52 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 05:36:00 | <c_wraith> | err, multiline definitions |
| 05:38:56 | <Inst> | https://media.discordapp.net/attachments/968989726633779215/1115877492906012773/image.png?width=780&height=434 |
| 05:39:38 | → | Feuermagier_ joins (~Feuermagi@user/feuermagier) |
| 05:42:13 | × | Feuermagier quits (~Feuermagi@user/feuermagier) (Ping timeout: 265 seconds) |
| 05:43:28 | × | shapr quits (~user@2600:1700:c640:3100:a42a:82d6:7ced:1441) (Ping timeout: 240 seconds) |
| 05:43:37 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 05:44:27 | → | notzmv joins (~zmv@user/notzmv) |
| 05:45:59 | → | bgs joins (~bgs@212-85-160-171.dynamic.telemach.net) |
| 05:46:28 | × | chromoblob quits (~user@37.113.158.8) (Ping timeout: 240 seconds) |
| 05:46:44 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 05:47:12 | <segfaultfizzbuzz> | what purpose does writing "let" in languages (such as haskell) serve? it seems unnecessary...? |
| 05:49:34 | × | lottaquestions quits (~nick@2607:fa49:503f:6d00:2ffc:724d:26ca:ea57) (Remote host closed the connection) |
| 05:50:00 | → | lottaquestions joins (~nick@2607:fa49:503f:6d00:8fc2:91a1:b755:da93) |
| 05:50:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 05:51:24 | × | mei quits (~mei@user/mei) (Ping timeout: 265 seconds) |
| 05:53:56 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 05:54:05 | × | werneta quits (~werneta@70.142.214.115) (Ping timeout: 250 seconds) |
| 05:54:32 | × | jinsun quits (~jinsun@user/jinsun) (Ping timeout: 250 seconds) |
| 05:54:34 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac) |
| 05:54:52 | → | oac joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 05:56:00 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 06:00:00 | <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. |
| 06:00:47 | → | CiaoSen joins (~Jura@145.224.74.19) |
| 06:00:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 06:02:37 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 240 seconds) |
| 06:04:11 | → | jinsun joins (~jinsun@user/jinsun) |
| 06:05:05 | × | Square quits (~Square@user/square) (Ping timeout: 240 seconds) |
| 06:05:29 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 06:08:57 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac) |
| 06:16:07 | <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 |
| 06:16:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 06:17:02 | → | oo_miguel joins (~Thunderbi@77.252.47.84) |
| 06:17:07 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 06:17:18 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 06:17:28 | → | mei joins (~mei@user/mei) |
| 06:22:13 | × | bgs quits (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 06:23:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 06:24:59 | → | user____3 joins (~user@dynamic-046-114-176-088.46.114.pool.telefonica.de) |
| 06:26:15 | → | gnalzo joins (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 06:27:05 | × | emmanuelux quits (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 06:27:10 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 06:29:54 | × | rembo10 quits (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 06:32:06 | → | rembo10 joins (~rembo10@main.remulis.com) |
| 06:44:03 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 06:46:10 | → | chomwitt joins (~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) |
| 06:46:14 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 06:52:29 | → | Jade17 joins (~Jade@ip-178-200-061-149.um45.pools.vodafone-ip.de) |
| 06:52:56 | Jade17 | is now known as Jade256 |
| 06:54:47 | → | coot joins (~coot@89.69.206.216) |
| 06:56:46 | × | Jade256 quits (~Jade@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit) |
| 06:56:48 | → | coot_ joins (~coot@89-69-206-216.dynamic.chello.pl) |
| 06:57:01 | × | Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 06:57:31 | → | Jade256 joins (~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) |
| 06:58:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 06:59:21 | → | Feuermagier joins (~Feuermagi@user/feuermagier) |
| 06:59:52 | × | Jade256 quits (~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit) |
| 06:59:57 | × | coot quits (~coot@89.69.206.216) (Ping timeout: 250 seconds) |
| 06:59:57 | coot_ | is now known as coot |
| 07:00:05 | <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) |
| 07:00:10 | → | Jade256 joins (~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) |
| 07:00:50 | <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 |
| 07:01:05 | × | Feuermagier_ quits (~Feuermagi@user/feuermagier) (Ping timeout: 256 seconds) |
| 07:02:05 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 07:02:05 | × | Jade256 quits (~Jade256@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Client Quit) |
| 07:02:49 | <fr33domlover> | (Prior art I found that is great and useful but isn't about DBs: aeson-schemas, servant, DataVersion) |
| 07:03:09 | <jackdk> | I believe beam-migrate does this, but I never figured out how to drive beam |
| 07:03:15 | → | acidjnk joins (~acidjnk@p200300d6e7072f2409bf9167a1faa0fe.dip0.t-ipconnect.de) |
| 07:08:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 07:10:04 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 07:11:12 | × | oo_miguel quits (~Thunderbi@77.252.47.84) (Quit: oo_miguel) |
| 07:11:41 | → | oo_miguel joins (~Thunderbi@77.252.47.84) |
| 07:12:46 | <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... |
| 07:12:50 | <Axman6> | now* |
| 07:14:00 | → | Feuermagier_ joins (~Feuermagi@user/feuermagier) |
| 07:14:35 | Feuermagier | is now known as Guest6932 |
| 07:14:35 | × | Guest6932 quits (~Feuermagi@user/feuermagier) (Killed (cadmium.libera.chat (Nickname regained by services))) |
| 07:14:35 | Feuermagier_ | is now known as feuermagier |
| 07:14:54 | → | Guest6932 joins (~Feuermagi@user/feuermagier) |
| 07:15:13 | × | feuermagier quits (~Feuermagi@user/feuermagier) (Killed (zirconium.libera.chat (Nickname regained by services))) |
| 07:15:13 | Guest6932 | is now known as feuermagier |
| 07:15:33 | → | Guest6955 joins (~Feuermagi@user/feuermagier) |
| 07:16:13 | <jade[m]> | what about the email that's given? |
| 07:16:41 | <Axman6> | oh man, email is a thing hey. I hate email though - I guess I could try |
| 07:17:21 | × | Guest6955 quits (~Feuermagi@user/feuermagier) (Client Quit) |
| 07:17:23 | × | feuermagier quits (~Feuermagi@user/feuermagier) (Client Quit) |
| 07:17:28 | → | lortabac joins (~lortabac@2001:620:130:6092:819c:2ab5:89a3:3c36) |
| 07:22:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 07:23:14 | × | lortabac quits (~lortabac@2001:620:130:6092:819c:2ab5:89a3:3c36) (Ping timeout: 265 seconds) |
| 07:24:23 | <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 |
| 07:24:25 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 07:26:06 | <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 |
| 07:26:13 | → | jtza8 joins (~user@165.255.145.149) |
| 07:27:33 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 07:31:30 | → | lortabac joins (~lortabac@2001:620:130:6092:af4b:5add:1ec1:8fbe) |
| 07:31:56 | <Profpatsch> | data Product f g a = Pair (f a) (f b) whyyyyyy would you name your constructor like that |
| 07:32:20 | <Profpatsch> | The goal must be to make base as annoying as possible |
| 07:32:37 | × | vandita quits (~vandit@178-164-208-246.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 07:33:00 | <Profpatsch> | I suggest we change |
| 07:33:17 | <Profpatsch> | data Compose f g a = Compose (f (g a)) |
| 07:33:19 | <Profpatsch> | to |
| 07:33:25 | <Profpatsch> | data Compose f g a = Nest (f (g a)) |
| 07:33:38 | <Profpatsch> | just to add more confusion |
| 07:34:19 | → | vandita joins (~vandit@84-236-21-42.pool.digikabel.hu) |
| 07:37:22 | <Axman6> | jade[m]: I did it, I wrote an email. from scratch. urgh, this feels like work. |
| 07:37:32 | <Axman6> | Profpatsch: ew, yeah I do not like that |
| 07:37:57 | <Axman6> | Prod I could live with, Pair is just obnoxious |
| 07:40:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 07:42:31 | → | hisa386 joins (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
| 07:43:09 | × | gnalzo quits (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 07:43:54 | → | gmg joins (~user@user/gehmehgeh) |
| 07:44:07 | × | hisa38 quits (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 240 seconds) |
| 07:44:07 | hisa386 | is now known as hisa38 |
| 07:45:18 | → | titibandit joins (~titibandi@user/titibandit) |
| 07:50:33 | × | eggplantade quits (~Eggplanta@104.55.37.220) (Remote host closed the connection) |
| 07:50:38 | → | chele joins (~chele@user/chele) |
| 07:52:36 | <probie> | Profpatsch: How about `newtype (.) f g a = Nest (f (g a))`? :p |
| 07:54:13 | <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)`) |
| 07:54:38 | <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 |
| 07:57:02 | <int-e> | such curious code ("nosier", yeah I know it's a typo) |
| 07:57:14 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 07:58:25 | <ski> | Profpatsch : i'd support that (`Nest') change |
| 07:58:38 | <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). |
| 08:01:14 | <merijn> | int-e: undecidable even, no? |
| 08:01:32 | <int-e> | merijn: well, yes |
| 08:02:16 | <int-e> | (but that still allows for incomplete implementations that try as well as they can) |
| 08:06:49 | × | m1dnight quits (~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 3.8) |
| 08:08:25 | <Profpatsch> | ski: it was meant sarcasticalyl |
| 08:08:57 | <Profpatsch> | but yes, let’s introduce more accidental mental overhead, the language doesn’t have enough yet |
| 08:09:59 | → | m1dnight joins (~christoph@78-22-4-67.access.telenet.be) |
| 08:10:24 | <mzg> | Profpatsch: that's how you start evolving |
| 08:10:52 | <Profpatsch> | If anything, change Pair to Product |
| 08:11:36 | <int-e> | s/Compose/B/g, force people to learn standard combinator names. |
| 08:14:58 | × | econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 08:15:05 | <c_wraith> | So are we going to rename Identity to I? that would save so much typing. |
| 08:15:25 | <probie> | didn't generics-sop actually do this? |
| 08:16:00 | × | zxrom quits (~zxrom@mm-163-23-212-37.vitebsk.dynamic.pppoe.byfly.by) (Quit: Leaving) |
| 08:16:06 | <int-e> | c_wraith: Yes, and Const to K. |
| 08:16:20 | <int-e> | also const to k, just to mess with people using i,j,k as indices |
| 08:16:41 | <c_wraith> | might as well rename id to i if we're going that direction |
| 08:16:47 | <int-e> | of course |
| 08:16:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 08:16:59 | <int-e> | I'm happy we're all in agreement here ;) |
| 08:17:26 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 08:18:29 | → | Pickchea joins (~private@user/pickchea) |
| 08:19:10 | <Profpatsch> | probie: I’ve been unironically wishing for $ on the typelevel |
| 08:19:13 | <jackdk> | I wish the `(:+:)`, `(:*:)` and `(:.:)` were canonical and we didn't have the ones in Data.Functor.* |
| 08:19:33 | <Profpatsch> | but yeah, something like ~> would be good, though it’s a bit too close to -> for my liking |
| 08:19:36 | <Profpatsch> | maybe --> |
| 08:19:43 | <Profpatsch> | “big arrow” |
| 08:20:14 | <Profpatsch> | tho in general I think operators and symbol zoo are bad and should be banned |
| 08:20:22 | <Profpatsch> | Just write words |
| 08:20:38 | <jackdk> | nah, I think we're pretty good about using a consistent visual language in our operators around here |
| 08:20:49 | <Profpatsch> | not sure if irony |
| 08:21:08 | <Profpatsch> | I mean, you get used to it |
| 08:21:15 | <Profpatsch> | But lens overdoes it, by a lot |
| 08:21:35 | <jackdk> | 100% serious. $ and <$> have similar meaning but the "wings" mean "with a layer of functor", roughly speaking |
| 08:21:38 | <Profpatsch> | (not that I use lens in production, that would be a grave mistake) |
| 08:21:46 | <Profpatsch> | jackdk: yeah, that convention is :100: |
| 08:21:54 | <jackdk> | & is the opposite of $, so <&> is easily guessable |
| 08:21:58 | <Profpatsch> | agreed |
| 08:22:05 | <jackdk> | <* and *> as variants of <*> |
| 08:22:10 | <Profpatsch> | Now let’s just tell people to use & and <&> more |
| 08:22:28 | <jackdk> | you can probably guess what <$?> and <&?> in `witherable` do: mapMaybe and flipped mapMaybe |
| 08:24:05 | <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 (<<) |
| 08:31:52 | × | lortabac quits (~lortabac@2001:620:130:6092:af4b:5add:1ec1:8fbe) (Ping timeout: 265 seconds) |
| 08:34:52 | <probie> | Profpatsch: what stops you? You can already go `type ($) f x = f x` |
| 08:35:44 | <probie> | I guess it probably doesn't play with `->` in the way you'd like |
| 08:36:14 | × | use-value quits (~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e) (Quit: use-value) |
| 08:36:49 | <Profpatsch> | probie: pretty sure you can’t do infix definitions on the type level |
| 08:37:17 | <Profpatsch> | jackdk: I know that lens has a convention, but the matrix is way too large |
| 08:39:30 | → | lortabac joins (~lortabac@2001:620:130:6092:a46f:9a9:efa8:9c69) |
| 08:40:49 | × | gmg quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 08:42:05 | <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` |
| 08:42:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 08:42:49 | <Profpatsch> | probie: Oh, then that’s pretty cool |
| 08:42:54 | → | cfricke joins (~cfricke@user/cfricke) |
| 08:43:11 | <Profpatsch> | but yeah, -> being -1 is kinda crappy |
| 08:44:01 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 08:44:08 | → | chromoblob joins (~user@37.113.158.8) |
| 08:48:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 08:51:00 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 08:51:03 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 08:55:15 | → | ubert joins (~Thunderbi@2a02:8109:abc0:6434:523d:9a8b:b2f4:ac13) |
| 08:55:28 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 248 seconds) |
| 08:55:53 | × | shriekingnoise quits (~shrieking@186.137.175.87) (Ping timeout: 246 seconds) |
| 08:56:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 08:57:57 | × | tzh_ quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 08:59:28 | → | caryhartline joins (~caryhartl@168.182.58.169) |
| 08:59:29 | × | cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 09:03:17 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 09:03:48 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 09:06:42 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:09:35 | <Inst> | pfft, the pythonistas are terrible |
| 09:09:46 | <Inst> | at least the julians have an excuse that they're few in number |
| 09:10:06 | <Inst> | i'm trying to build an extremely cleaned-up variant of the bentley quicksort in Python and Haskell |
| 09:18:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 09:21:17 | × | lortabac quits (~lortabac@2001:620:130:6092:a46f:9a9:efa8:9c69) (Quit: WeeChat 2.8) |
| 09:22:27 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:24:31 | × | ft quits (~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving) |
| 09:27:32 | × | mbuf quits (~Shakthi@49.207.178.186) (Quit: Leaving) |
| 09:27:51 | ← | jtza8 parts (~user@165.255.145.149) (ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 09:28:30 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 09:28:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 09:30:10 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:33:28 | × | m1dnight quits (~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 3.8) |
| 09:33:55 | → | m1dnight joins (~christoph@78-22-4-67.access.telenet.be) |
| 09:39:39 | → | mheinzel joins (~mheinzel@152.96.94.71) |
| 09:41:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 09:43:05 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:52:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 09:53:05 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:53:21 | user____3 | is now known as gurkenglas |
| 09:58:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 09:59:28 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 09:59:29 | → | le_ka joins (~l_k@213.24.134.106) |
| 10:01:33 | → | __monty__ joins (~toonn@user/toonn) |
| 10:03:07 | <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? |
| 10:03:27 | <gurkenglas> | s/it's/they're/ |
| 10:04:01 | <gurkenglas> | ("let's say" because i'd hope that algorithm to generalize beyond that type) |
| 10:05:03 | <_________> | yes, bruteforce |
| 10:05:04 | <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) |
| 10:05:08 | <probie> | what does "faster" mean? |
| 10:05:22 | <gurkenglas> | _________: i'm hoping for automated symbolic reasoning |
| 10:05:25 | × | chomwitt quits (~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) (Ping timeout: 250 seconds) |
| 10:05:39 | → | enoq joins (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 10:06:05 | <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 |
| 10:06:35 | × | xff0x_ quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 246 seconds) |
| 10:06:37 | × | maerwald quits (~maerwald@mail.hasufell.de) (Quit: gone) |
| 10:06:44 | <gurkenglas> | probie: faster as in the kind of theoretical analysis you do to say things like "quicksort has worst-case performance O(n²)" |
| 10:06:59 | → | maerwald joins (~maerwald@mail.hasufell.de) |
| 10:08:09 | <probie> | let f = if f is log(n) then bubbleSort else mergeSort |
| 10:08:55 | <gurkenglas> | probie: i don't follow |
| 10:09:08 | → | mmhat joins (~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de) |
| 10:09:17 | <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 |
| 10:09:32 | <gurkenglas> | or is |
| 10:09:44 | <gurkenglas> | (since f appears to be recursively defined here?) |
| 10:10:14 | <gurkenglas> | ah, you're doing the halting problem impossiblity proof as applied to sorting algorithms? |
| 10:11:22 | <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 |
| 10:11:25 | <gurkenglas> | :P |
| 10:11:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 10:13:02 | <gurkenglas> | the oracle is only supposed to be ~exponentially faster than running the algorithm on all lists and measuring runtime |
| 10:13:36 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 10:13:41 | × | ajf___[m] quits (~ajfmatrix@2001:470:69fc:105::2:5be3) (Remote host closed the connection) |
| 10:13:47 | <probie> | To do the sort of analysis you want, you probably need a rather restricted language for describing (terminating) sorting algorithms |
| 10:15:02 | <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 |
| 10:17:34 | <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 |
| 10:18:04 | <gurkenglas> | (Eq a, I guess.) |
| 10:19:38 | <ncf> | that seems very different |
| 10:19:49 | <gurkenglas> | (and Enum a, actually, so let's say s/Stream -> Bool/Stream Bool -> Bool/) |
| 10:20:14 | <ncf> | the space of lists isn't really searchable in that sense |
| 10:20:50 | <gurkenglas> | I see, can you give some other kind of algorithm than sorting where I could do that kind of worst-case-runtime construction? |
| 10:21:17 | <ncf> | i'm not that familiar with it |
| 10:21:23 | <gurkenglas> | (conceptually similar to sorting, perhaps) |
| 10:22:24 | <ncf> | (also, does that work for other types than, say, a ~ Bool ?) |
| 10:22:44 | <ncf> | the whole trick relies on the compactness of the Cantor space 2^ℕ, but e.g. ℕ^ℕ isn't compact |
| 10:22:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 10:22:56 | <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? |
| 10:23:34 | <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 |
| 10:23:37 | <gurkenglas> | ncf: presumably you're not amused with Enum a |
| 10:23:49 | <gurkenglas> | yes that's where i picked up that trick :D |
| 10:23:53 | <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 |
| 10:24:08 | <ncf> | i actually have no idea if 3^ℕ is compact |
| 10:24:48 | <gurkenglas> | oh damn \mathbb{N} is Enum in Haskell, i meant "finite enumerable" |
| 10:25:02 | <gurkenglas> | i'm willing to bet 3^\mathbb{N} is compact |
| 10:25:07 | <ncf> | yeah i got what you meant |
| 10:26:29 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 10:27:38 | <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 |
| 10:28:12 | <gurkenglas> | (but I was under the impression "conceptually similar to sorting" makes my question slightly different) |
| 10:28:43 | <gurkenglas> | (i am not, on reflection, staking any significant credit on that impression ^^) |
| 10:29:17 | <ncf> | yeah ok 3^ℕ is compact via tychonoff |
| 10:29:28 | <ncf> | so any (Fin n)^ℕ is |
| 10:29:32 | → | dcoutts joins (~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) |
| 10:29:55 | <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 |
| 10:30:04 | <gurkenglas> | actually, we're being silly, the two are isomorphic. |
| 10:30:23 | <ncf> | are they homeomorphic? |
| 10:30:42 | <gurkenglas> | (aka turn your 3^N->Bool into 2^N->Bool by encoding your ternary digits with two binary digits each) |
| 10:31:18 | <Inst> | wait, question if anyone wants to play |
| 10:31:28 | <Inst> | if i'm actually doing a non-recursive quicksort |
| 10:31:39 | <Inst> | do i even need ST monad and mutable vectors |
| 10:31:42 | × | mheinzel quits (~mheinzel@152.96.94.71) (Ping timeout: 265 seconds) |
| 10:31:52 | <gurkenglas> | non-recursive, in Haskell? what are you using for that? |
| 10:32:14 | <Inst> | i'm working on bentley quicksort to try to get the cleanest possible true quicksort in Haskell |
| 10:32:31 | <Inst> | the current version is in python, but i can translate pretty reliably between recursive and non-recursive idioms |
| 10:32:59 | <Inst> | well, probably not, unless i can figure out some way to make it tail recursive? |
| 10:33:42 | <gurkenglas> | Inst: Give some example of a pair of Haskell functions where you'd one is a non-recursive version of the other? |
| 10:33:51 | <gurkenglas> | s/you'd/you'd say/ |
| 10:34:02 | <Inst> | well, i mean, TCO-ed |
| 10:34:15 | <Inst> | the Python version, predictably to an extent |
| 10:34:21 | <Inst> | is cleaner and more comprehensible when it's non-recursive |
| 10:34:36 | <Inst> | it's a while loop using a control list of tuples |
| 10:34:42 | <Inst> | erm, a control list of lists |
| 10:35:22 | <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? |
| 10:35:33 | <Inst> | translating that back to Haskell, I get the feeling it'd be TCO-ed |
| 10:35:53 | × | p3n quits (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 10:36:04 | <Inst> | so i'm unsure as to whether i'd need mutable references to get an in-place... ah crap, i would |
| 10:36:04 | <gurkenglas> | link the python version? |
| 10:36:05 | <Inst> | ;_; |
| 10:36:22 | <Inst> | https://media.discordapp.net/attachments/968989726633779215/1115950265623912528/image.png?width=2878&height=1178 |
| 10:36:41 | <gurkenglas> | image of text x.x |
| 10:40:04 | <gurkenglas> | i expect my refactoring of that to do whatever is necessary to get rid of the 0s and 1s |
| 10:40:05 | <Inst> | https://paste.tomsmeding.com/2jkuCqnT |
| 10:40:15 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 10:40:24 | × | dcoutts quits (~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) (Ping timeout: 265 seconds) |
| 10:40:36 | <Inst> | the only benefit of the non-recursive version is that it can be run as a simple while loop |
| 10:41:09 | <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 |
| 10:41:10 | <gurkenglas> | do you favor that for the performance or the readability? |
| 10:41:15 | <Inst> | readability |
| 10:41:20 | <gurkenglas> | then dont use ST :D |
| 10:41:27 | <Inst> | remember when we had the haskell treesort as an advertisement |
| 10:41:38 | <Inst> | i want to see what a cleaned up true quicksort in Haskell looks like |
| 10:41:47 | <Inst> | and how far we can compare vs python etc |
| 10:42:36 | <gurkenglas> | is your motivation-to-see flavored as a motivation-to-play or as intellectual curiosity? |
| 10:43:06 | <Inst> | both |
| 10:43:20 | <Inst> | i assume Haskell quicksort will lose to py or any imperative language concerned with readability |
| 10:44:14 | <gurkenglas> | :t mapAccumL :: are you familiar with this? |
| 10:44:15 | <lambdabot> | error: Operator applied to too few arguments: ? |
| 10:44:26 | <gurkenglas> | :t mapAccumL -- whoops |
| 10:44:27 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 10:44:30 | <Inst> | i know mapAccum exists |
| 10:44:35 | <Inst> | i haven't used it much |
| 10:44:53 | <Inst> | holy shit, have you worked on this problem before? |
| 10:45:01 | <jade[m]> | Inst: how so? |
| 10:45:32 | <Inst> | are you implying that we can do a true inplace quicksort via HoF and beat imperative quicksorts? |
| 10:46:08 | <gurkenglas> | beat as in timing experiments? |
| 10:46:12 | <Inst> | not in timing |
| 10:46:17 | <Inst> | in terms of readability |
| 10:46:21 | <Inst> | and concision |
| 10:46:27 | <gurkenglas> | :t auf (iso runState state) traverse -- equivalent to mapAccumL, closer to ST |
| 10:46:28 | <lambdabot> | Traversable t => (a -> s -> (b, s)) -> t a -> s -> (t b, s) |
| 10:46:29 | <Inst> | bentley quicksort isn't performant anyways |
| 10:47:05 | <gurkenglas> | do you have a haskell version based on ST already? |
| 10:47:15 | <Profpatsch> | somerandomnick[m: “mathematical defeat” lol |
| 10:47:53 | <Profpatsch> | I’d argue mathematics got the definition wrong in the first place |
| 10:48:00 | <Inst> | https://paste.tomsmeding.com/f4paIt6g |
| 10:48:04 | <Profpatsch> | f.g should have been g(f(x)) not f(g(x)) |
| 10:48:08 | <Inst> | this isn't bentley |
| 10:48:25 | <Inst> | i'm still giggling that i confused a bunch of pythonistas with the direct py translation |
| 10:48:38 | <Profpatsch> | Anywho, any Haskell code using & and <&> heavily will be more readable. |
| 10:48:40 | <Inst> | then again, quicksort is ugly in general |
| 10:49:10 | <Profpatsch> | Most other functional languages have recognized this, |> (the same as (&) in haskell) is heavily used in both F# and modern Ocaml |
| 10:49:29 | <fendor[m]> | and elm :) |
| 10:49:40 | <Profpatsch> | <&> composes better with >>=, forming amazing pipeline behaviour |
| 10:50:31 | <Profpatsch> | Combine that with \case and you’re going places |
| 10:50:40 | <Inst> | ugh, this version is bugged |
| 10:50:43 | <jade[m]> | Profpatsch: yes but only if it had another name. `.` is borrowed from mathematics where it means `f(g(x))` |
| 10:51:16 | <probie> | Inst: I'm pretty sure that use of `unsafeThaw` is genuinely unsafe |
| 10:51:57 | <Profpatsch> | jade[m]: I just said that I believe the mathematics definition was ill-advised |
| 10:52:07 | <Profpatsch> | It should have been defined as g(f(x)) |
| 10:52:08 | <Inst> | it's not the unsafe freeze / unsafe thaw |
| 10:52:13 | <Inst> | version without the unsafes is still bugged |
| 10:52:14 | <Profpatsch> | In math |
| 10:52:16 | <__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. |
| 10:52:18 | <Inst> | i had a version which was bugged like this |
| 10:52:44 | <Profpatsch> | Don’t forget >>> from Control.Category |
| 10:52:51 | <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 |
| 10:52:54 | <Profpatsch> | Also immensely useful |
| 10:52:56 | <c_wraith> | err, isn't math |
| 10:53:07 | <Profpatsch> | c_wraith: what even does that mean |
| 10:53:16 | <Profpatsch> | That statement has literally no content :P |
| 10:53:23 | <c_wraith> | it's 100% true |
| 10:53:24 | <Profpatsch> | no offense |
| 10:53:35 | <__monty__> | c_wraith: Isn't `(.)` evaluated first? |
| 10:53:55 | <c_wraith> | sure, but it's the whole context |
| 10:54:02 | <Inst> | there, i fixed it |
| 10:54:04 | <c_wraith> | also, it's usually evaluated at compile time |
| 10:54:06 | <Inst> | the code in the swap logic was flawed |
| 10:54:18 | → | fendor joins (~fendor@2a02:8388:1605:7500:3974:8f28:6b80:17ec) |
| 10:54:43 | <Inst> | the swap logic has it incrementing the front element |
| 10:55:06 | <Inst> | erm, decrementing the rear element variable when it should be incrementing the front element variable |
| 10:55:41 | <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 |
| 10:55:59 | <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. |
| 10:56:50 | <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. |
| 10:57:51 | <c_wraith> | this is why Haskell's evaluation model is sometimes called outermost-first |
| 10:58:07 | <Inst> | ruh roh |
| 10:58:11 | <Inst> | something's wrong with this code |
| 10:58:12 | <Inst> | :( |
| 10:58:39 | <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. |
| 10:58:39 | <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` |
| 10:58:48 | <Inst> | groan, kill me |
| 10:58:59 | <Inst> | need to find my newer non-buggy version |
| 10:59:23 | <__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. |
| 10:59:31 | <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 |
| 10:59:40 | <jade[m]> | s/menow/me now |
| 10:59:54 | <probie> | `f . g` is leading with the important bit |
| 11:00:00 | <Profpatsch> | c_wraith: yeah, but as a user I don’t care about evaluation order |
| 11:00:04 | <Profpatsch> | I care about logical order |
| 11:00:12 | <Profpatsch> | eval order is secondart |
| 11:00:14 | <c_wraith> | oh, then you like space leaks |
| 11:00:14 | <Profpatsch> | y |
| 11:00:15 | <Inst> | the only problem with haskell tbh is that & and >>> don't play together nicely |
| 11:00:22 | <Inst> | if you look at streamly they're pushing a & idiom |
| 11:00:24 | <Profpatsch> | Again, what even does that mean |
| 11:00:29 | <jade[m]> | logical order is also from the outside imo |
| 11:00:42 | <jade[m]> | it really just depends on how you look at it |
| 11:00:53 | <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#L101 |
| 11:00:57 | <Inst> | & and >>> have the wrong precedence for their combined use to work as a flipped replacement for $ and . |
| 11:01:10 | <Profpatsch> | would you seriously opine that “logical order” opposite the way it was written? |
| 11:01:12 | <c_wraith> | Profpatsch: why is it all backwards? |
| 11:01:15 | <Inst> | probie: the f v actually works properly on [4,3,2,1] |
| 11:01:28 | <Inst> | for whatever reason, the new code is broken, even if I swap unsafe freeze to freeze etc |
| 11:01:34 | <Profpatsch> | So a user will think “okay, I have mapped things (over which I have mapped things (over |
| 11:01:56 | <Profpatsch> | Instead of “I have to do this, then that, then draw the tree, then convert to string” |
| 11:01:59 | <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 |
| 11:01:59 | <jade[m]> | lol |
| 11:02:23 | <Profpatsch> | jade[m]: only HAskellers would read code back-to-front and right-to-left |
| 11:02:25 | <jade[m]> | because I want to know what the function returns first and foremost, and then slowly go 'inwards' |
| 11:02:39 | <jade[m]> | Profpatsch: nonono, just yours |
| 11:02:40 | <probie> | To know the result of `(f . g) x`, it is `f` _not_ `g` that needs to reduce first |
| 11:02:41 | <Profpatsch> | this is stockholm syndrome final stage |
| 11:03:11 | <c_wraith> | Profpatsch: or... it's better and you haven't realized yet. |
| 11:03:23 | <Profpatsch> | jade[m]: if you want to know the result, look at the type signatrue |
| 11:03:34 | <c_wraith> | Profpatsch: the thing that really stands out to me is that it's needlessly pointful |
| 11:03:39 | <c_wraith> | Profpatsch: you're not thinking in functions |
| 11:04:11 | <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 |
| 11:04:24 | <c_wraith> | Profpatsch: 5 years is... a start |
| 11:04:35 | × | hays quits (rootvegeta@fsf/member/hays) (Remote host closed the connection) |
| 11:05:11 | <Profpatsch> | To the contrary, I’ve worked with both extensively, and left-to-right top-to-bottom pipelining always wins in readability and writability |
| 11:05:18 | <jade[m]> | also, shouldn't sequential `<$>`/fmaps be a single one? |
| 11:05:24 | <jade[m]> | using said composition? |
| 11:05:34 | <c_wraith> | Like.. you've contorted the logic really hard instead of... doing what jade[m] is suggesting |
| 11:05:38 | <Profpatsch> | jade[m]: See, you are trying to do the compiler’s work |
| 11:05:53 | <c_wraith> | that's for readability, not for the compiler |
| 11:06:03 | <Profpatsch> | you people are lost lol |
| 11:06:08 | <Inst> | there, if you're still here, gurkenglas |
| 11:06:13 | <Inst> | this version works |
| 11:06:18 | <Inst> | with and without unsafeFreeze / unsafeThaw |
| 11:06:35 | <jade[m]> | Profpatsch: alright then |
| 11:06:37 | <Inst> | iirc unsafe is, #1, not for use with reference versions, #2, only a post-finalization optimization that requires testing |
| 11:06:54 | <Inst> | https://paste.tomsmeding.com/FY60Fw1F |
| 11:07:49 | → | xff0x_ joins (~xff0x@ai098135.d.east.v6connect.net) |
| 11:08:28 | <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" |
| 11:08:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:09:17 | × | __monty__ quits (~toonn@user/toonn) (Ping timeout: 256 seconds) |
| 11:10:00 | → | szkl joins (uid110435@id-110435.uxbridge.irccloud.com) |
| 11:10:09 | <gurkenglas> | (.) :: (c<-a) <- (c<-b) <- (b<-a) -- reasonable, right? |
| 11:10:20 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:10:52 | <c_wraith> | that doesn't play nicely with currying |
| 11:11:01 | <gurkenglas> | explain? |
| 11:11:17 | <probie> | I feel like this the functional equivalent of arguing abound endianness |
| 11:11:32 | <c_wraith> | it requires you to provide arguments in the opposite order of how they appear in the type |
| 11:11:39 | <gurkenglas> | probie: sure. do you agree that endianness is arbtirary but should be consistent? |
| 11:11:59 | <jade[m]> | I personally use medium sized endian instead of going for the extremes |
| 11:12:19 | <gurkenglas> | c_wraith: (f::c<-b) . (g::b<-a) :: c<-a |
| 11:12:20 | <probie> | Ah, the RISC-V op approach |
| 11:12:33 | → | __monty__ joins (~toonn@user/toonn) |
| 11:12:44 | <jade[m]> | oh shit, I just realized that actually sorta exists |
| 11:12:46 | <chromoblob> | I use the endianness in which the lesser byte is in front of you and the bigger byte is further away |
| 11:12:51 | <jade[m]> | I just wanted to make a dumb joke, damn |
| 11:13:19 | <c_wraith> | gurkenglas: only if you've swapped binary operator application order, too |
| 11:13:31 | <gurkenglas> | if you find yourself thinking about endianness, notice that you are doing pointer arithmetic, and find another way to solve your problem |
| 11:14:03 | <gurkenglas> | c_wraith: (.) (f::c<-b) (g::b<-a) :: c<-a |
| 11:14:27 | <c_wraith> | gurkenglas: so yes, you've reversed argument order. |
| 11:14:28 | <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) |
| 11:15:08 | <gurkenglas> | probie: fiiiine i will accept it if the alien planet across the galaxy uses the other one |
| 11:15:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:15:44 | <gurkenglas> | the 50% chance of war in a million years is on your hands. |
| 11:17:26 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:17:59 | <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. |
| 11:18:31 | × | mei quits (~mei@user/mei) (Ping timeout: 240 seconds) |
| 11:18:45 | <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" |
| 11:19:20 | <probie> | which really just sounds like "I want to read left to right using the minimal amount of additional mental storage" |
| 11:19:36 | <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 |
| 11:22:43 | → | mei joins (~mei@user/mei) |
| 11:22:49 | <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 |
| 11:23:06 | <gurkenglas> | s/a/the/ |
| 11:23:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:25:05 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:29:28 | <Inst> | this can't be real |
| 11:29:29 | <Inst> | https://paste.tomsmeding.com/Op9LaV6e |
| 11:29:33 | <Inst> | haven't tested it yet |
| 11:30:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:30:43 | → | hays joins (rootvegeta@fsf/member/hays) |
| 11:30:59 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:33:53 | <Inst> | nope, it's not |
| 11:33:55 | <Inst> | but this one is |
| 11:33:55 | <Inst> | https://paste.tomsmeding.com/dblZbXpa |
| 11:35:28 | × | acidjnk quits (~acidjnk@p200300d6e7072f2409bf9167a1faa0fe.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 11:36:38 | → | dcoutts joins (~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) |
| 11:38:52 | <ncf> | can #haskell go one day without bickering about composition order or other syntactic bs |
| 11:38:59 | <ncf> | @where wadler's law |
| 11:38:59 | <lambdabot> | I know nothing about wadler's. |
| 11:39:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:40:03 | <geekosaur> | https://wiki.haskell.org/Wadler%27s_Law |
| 11:40:18 | <geekosaur> | which implies the answer is no 🙂 |
| 11:42:17 | <hpc> | what we really need is to find somemthing pettier than the lexical syntax of comments to dominate our time |
| 11:42:26 | <hpc> | i vote for the interpretation of unicode graphemes :D |
| 11:42:32 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:42:58 | → | mheinzel joins (~mheinzel@2001:620:130:6092:f411:94c0:886d:9915) |
| 11:46:08 | × | __monty__ quits (~toonn@user/toonn) (Ping timeout: 248 seconds) |
| 11:47:32 | → | lortabac joins (~lortabac@152.96.92.233) |
| 11:47:55 | <geekosaur> | I thought IRC vs. Matrix had self-nominated 😛 |
| 11:48:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 11:49:15 | <Profpatsch> | probie: fwiw I follow the same rule |
| 11:49:25 | → | AndreiDuma joins (~textual@2001:620:130:6092:54b2:c871:96f8:3369) |
| 11:49:40 | <Profpatsch> | 90% of the time “what I want to think about first” is the f in f.g |
| 11:49:45 | <Profpatsch> | *err the g in f.g |
| 11:50:01 | <ncf> | we should jump to ω and argue about what to argue about next |
| 11:50:33 | <Profpatsch> | ncf: Composition order and ease & consistency of reading becomes hugely important once you try to get Haskell adopted in teams >3 |
| 11:50:33 | <hpc> | ncf: i agree... wait a minute... |
| 11:50:45 | <Profpatsch> | With people who don’t breathe programming |
| 11:51:10 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 11:51:42 | <hpc> | i find that describing it as "f(g(...)), not f().g()" works well |
| 11:53:22 | <probie> | ncf: How about the benefits of ImportQualifiedPost? |
| 11:55:14 | <merijn> | I don't think the "intuitiveness" is as clear cut as all the people arguing for & like to pretend it is |
| 11:56:00 | <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 |
| 11:57:27 | <Helle> | I mean it makes sense if you have any mathematics background |
| 11:57:37 | <merijn> | Helle: None of them had that |
| 11:57:53 | <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 |
| 11:58:16 | <merijn> | ? |
| 11:59:15 | × | mmhat quits (~mmh@p200300f1c70668f3ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
| 11:59:44 | <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: ..." |
| 12:00:02 | <jade[m]> | imo it's simply because f . g is the 'same order' as f(g(x)) |
| 12:00:10 | × | mei quits (~mei@user/mei) (Remote host closed the connection) |
| 12:00:21 | <merijn> | gurkenglas: You can make the reverse argument just as easily |
| 12:01:05 | <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 |
| 12:01:13 | <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` |
| 12:01:19 | <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 |
| 12:01:28 | <Profpatsch> | So there must be some objective parts, but many things are rather subjective and experience-based |
| 12:01:46 | <merijn> | gurkenglas: "We compute the X of (computing the Y of some input)" |
| 12:02:06 | <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 |
| 12:02:18 | <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 |
| 12:02:35 | → | mei joins (~mei@user/mei) |
| 12:02:36 | <Profpatsch> | merijn: iirc like 4 |
| 12:02:44 | <Profpatsch> | anecdote of course |
| 12:02:46 | <merijn> | Profpatsch: and, not intended to be mean spirited, but 2) how do you know the problem is not your teaching? |
| 12:02:49 | <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 |
| 12:03:04 | <Profpatsch> | merijn: I kinda controlled for it cause it was the same lesson just in different languages |
| 12:03:19 | <Profpatsch> | after they didn’t get the Scheme thing one bit, but maybe they were primed ofc |
| 12:03:21 | <jade[m]> | just from my own experience I would probably agree that haskell 'looks' easier than lisp and it less threatening |
| 12:03:29 | <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 |
| 12:03:33 | <Profpatsch> | heh |
| 12:03:59 | <Profpatsch> | anecdotally again, I switched to Haskell because I couldn’t figure out how `fold` works in clojure |
| 12:04:59 | <probie> | as in `reduce` or as in `reducers/fold`? |
| 12:05:53 | <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". |
| 12:06:03 | <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? |
| 12:06:09 | <jade[m]> | I suppose that's a good thing? |
| 12:07:01 | <merijn> | jade[m]: Wait until you rediscover having to think about deep vs shallow copies :\ |
| 12:07:11 | <jade[m]> | oh no. |
| 12:07:14 | <[exa]> | savage. |
| 12:07:15 | <merijn> | That's one day of python debugging I never got back |
| 12:07:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 12:08:05 | <jade[m]> | the problem is that I'll be working with probably mostly java in the next uh four years |
| 12:08:10 | <jade[m]> | starting at the first of august |
| 12:08:11 | <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 |
| 12:08:29 | <merijn> | Forgot python has no value semantics and I have to explicitly copy the dictionary at each recursion |
| 12:08:44 | <jade[m]> | 😬 |
| 12:08:48 | <jade[m]> | unfortunate |
| 12:09:09 | <gurkenglas> | merijn: did that take a day because you thought you knew what caused the bug, and the corresponding "fix" took a while? |
| 12:09:10 | <merijn> | I think I'd honestly rather write C++ (assuming C++11 or later) than python |
| 12:09:34 | <merijn> | gurkenglas: I thought my tree walk was wrong |
| 12:11:17 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 12:11:31 | → | machinedgod joins (~machinedg@93-136-37-239.adsl.net.t-com.hr) |
| 12:11:37 | gurkenglas | .oO(could one run python in an expensive debug mode where everything is immutable?) |
| 12:12:03 | <[exa]> | gurkenglas: yeah but how do you monkeypatch classes to support __add__ etc? |
| 12:13:18 | <gurkenglas> | [exa]: on every method call, copy the RAM region |
| 12:13:52 | × | notzmv quits (~zmv@user/notzmv) (Ping timeout: 248 seconds) |
| 12:14:25 | <[exa]> | gurkenglas: yeah but you typically need to replace it for everyone |
| 12:15:04 | <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" |
| 12:16:01 | <jade[m]> | <jade[m]> "the problem is that I'll be..." <- maybe they have scala teams |
| 12:16:32 | <gurkenglas> | just code in scala and have chatgpt mediate all your interactions with the company |
| 12:16:54 | × | mei quits (~mei@user/mei) (Remote host closed the connection) |
| 12:17:09 | × | CiaoSen quits (~Jura@145.224.74.19) (Ping timeout: 250 seconds) |
| 12:17:16 | <jade[m]> | hahaha |
| 12:17:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 12:19:19 | → | mei joins (~mei@user/mei) |
| 12:19:44 | × | TheCoffeMaker quits (~TheCoffeM@user/thecoffemaker) (Ping timeout: 248 seconds) |
| 12:21:04 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 12:21:56 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 12:27:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 12:31:31 | → | comerijn joins (~merijn@145.90.225.5) |
| 12:31:44 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 12:32:27 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Read error: Connection reset by peer) |
| 12:37:10 | → | gnalzo joins (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 12:37:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 12:37:55 | → | waleee joins (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 12:38:10 | → | raehik joins (~raehik@82.21.176.157) |
| 12:38:20 | <raehik> | does there exist a unit type class? one with no superclasses or functions |
| 12:39:07 | <raehik> | I have an associated constraint and want an "identity" instance where there is no constraint |
| 12:39:07 | <geekosaur> | it'd be inaccessible… |
| 12:40:00 | <raehik> | is there any other way with ConstraintKinds to say `() =>`? |
| 12:40:19 | <comerijn> | raehik: Why do you need another way than that? |
| 12:40:30 | <raehik> | I have `type ClassC a :: Type -> Constraint` and I can't do `type ClassC Foo = ()` |
| 12:40:38 | <geekosaur> | because I don't think that works? |
| 12:40:52 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 12:41:02 | <geekosaur> | my first guess at it would be `x ~ x` for some `x` |
| 12:41:38 | <geekosaur> | (here would presumably be `Foo`) |
| 12:41:46 | <comerijn> | raehik: Why not? |
| 12:41:57 | <comerijn> | raehik: Pretty sure I did that in the past |
| 12:42:13 | <raehik> | comerijn: () is a Type. I don't know how to get a Constraint here |
| 12:42:14 | <ncf> | boo, uniqueness of identity proofs |
| 12:42:31 | <comerijn> | raehik: Ah, so it's TypeInType screwing everything up :p |
| 12:42:38 | <comerijn> | raehik: Lemme look up my old gist |
| 12:42:43 | <geekosaur> | comerijn, it may have worked by accident, back when `Constraint` was secretly `Type` |
| 12:43:25 | <comerijn> | Well, the problem is that () can be both the type () and emptry constraint :p |
| 12:44:01 | <raehik> | is my problem that I did `Type -> Constraint` in the assoc type..>? |
| 12:44:08 | <comerijn> | https://gist.github.com/merijn/6130082 |
| 12:44:15 | <comerijn> | That used to work as recently as 8.10 or so |
| 12:44:18 | <comerijn> | I haven't tried 9.x |
| 12:44:46 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Remote host closed the connection) |
| 12:46:22 | <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 |
| 12:46:46 | <raehik> | and that seems to be the issue. maybe I just write a type level Const? |
| 12:47:08 | <comerijn> | raehik: Can you paste the full snippet? |
| 12:47:08 | <geekosaur> | there is one, isn't there? |
| 12:47:57 | <raehik> | https://paste.tomsmeding.com/1EGVRc5f |
| 12:48:07 | <geekosaur> | (Data.Functor.Const) |
| 12:48:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 12:49:32 | <raehik> | geekosaur: Looks like Const on my 9.6 isn't kind polymorphic |
| 12:49:37 | <raehik> | %:k Const |
| 12:49:54 | <raehik> | how do I ask the bot to play ghci for me |
| 12:50:15 | <geekosaur> | % :set -XPolyKinds |
| 12:50:15 | <yahb2> | <no output> |
| 12:50:21 | <geekosaur> | % :k Const |
| 12:50:21 | <yahb2> | <interactive>:1:1: error: ; Not in scope: type constructor or class ‘Const’ |
| 12:50:29 | → | jero98772 joins (~jero98772@2800:484:1d7f:5d36::1) |
| 12:50:35 | <geekosaur> | % import Data.Functor.Const |
| 12:50:35 | <yahb2> | <no output> |
| 12:50:38 | <geekosaur> | % :k Const |
| 12:50:38 | <yahb2> | Const :: * -> k -> * |
| 12:52:00 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 12:53:07 | × | machinedgod quits (~machinedg@93-136-37-239.adsl.net.t-com.hr) (Ping timeout: 240 seconds) |
| 12:53:22 | <raehik> | oh well term-level Const can't be fully kind polymorphic b/c it has an 'a' value |
| 12:55:14 | <raehik> | can't use a type family either because they have to be fully expanded >:( |
| 12:55:43 | → | kuribas joins (~user@ip-188-118-57-242.reverse.destiny.be) |
| 12:56:30 | <raehik> | I don't like it, but `class UnitClass a where; instance UnitClass a where` works... |
| 12:56:44 | × | AndreiDuma quits (~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:56:52 | <raehik> | surely something like that exists somewhere. the nothing class |
| 12:57:04 | <comerijn> | I think it's somewhere in the kmetti-verse |
| 12:57:13 | <raehik> | the extended kmettverse |
| 12:58:17 | → | oac joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 12:59:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:01:14 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:04:35 | → | AndreiDuma joins (~textual@2001:620:130:6092:54b2:c871:96f8:3369) |
| 13:06:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:07:14 | → | chomwitt joins (~chomwitt@94.69.70.96) |
| 13:08:53 | → | le__ka joins (~l_k@213.24.134.106) |
| 13:09:35 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:10:56 | × | jero98772 quits (~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 248 seconds) |
| 13:11:17 | → | Pickchea joins (~private@user/pickchea) |
| 13:11:41 | × | le_ka quits (~l_k@213.24.134.106) (Ping timeout: 265 seconds) |
| 13:12:09 | <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 :) |
| 13:12:29 | <raehik> | that way I can use `() :: Constraint` as normal |
| 13:12:35 | <comerijn> | \o/ |
| 13:12:43 | <comerijn> | I was wondering if that was it, but I forgot to mention it |
| 13:12:45 | <raehik> | cheers for the help comerijn, geekosaur |
| 13:14:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:15:45 | <Inst> | i also finally understand where the Clojure guy is coming from |
| 13:16:10 | <Inst> | like, I'm trying to backport a modified Haskell / Python Bentley quicksort into C |
| 13:16:24 | <Inst> | turns out it's not trivial because Python is dynamic, while Haskell has ad-hoc polymorphism |
| 13:16:48 | <Inst> | or, in this case, parametric polymorphism |
| 13:17:17 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:23:08 | → | UnMecQuiSeBalade joins (~UnMecQuiS@2a01cb059179a60060cb669c531951e0.ipv6.abo.wanadoo.fr) |
| 13:23:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:23:46 | × | UnMecQuiSeBalade quits (~UnMecQuiS@2a01cb059179a60060cb669c531951e0.ipv6.abo.wanadoo.fr) (Client Quit) |
| 13:24:51 | → | jero98772 joins (~jero98772@2800:484:1d7f:5d36::1) |
| 13:27:00 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:27:58 | → | use-value joins (~Thunderbi@2a00:23c6:8a03:2f01:acb1:db44:b81f:adc5) |
| 13:28:21 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac) |
| 13:28:26 | → | Inst_ joins (~Inst@2601:6c4:4081:2fc0:f10d:fbfc:9509:13bb) |
| 13:28:38 | → | oac joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 13:29:22 | → | use-value1 joins (~Thunderbi@2a00:23c6:8a03:2f01:11c4:bb75:150b:3612) |
| 13:30:46 | × | AndreiDuma quits (~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:31:44 | × | Inst quits (~Inst@2601:6c4:4081:2fc0:c1fa:d834:4b7c:236d) (Ping timeout: 248 seconds) |
| 13:32:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:32:33 | × | use-value quits (~Thunderbi@2a00:23c6:8a03:2f01:acb1:db44:b81f:adc5) (Ping timeout: 250 seconds) |
| 13:32:33 | use-value1 | is now known as use-value |
| 13:34:32 | → | AndreiDuma joins (~textual@2001:620:130:6092:54b2:c871:96f8:3369) |
| 13:34:52 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:35:48 | × | coot quits (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 13:39:22 | → | CiaoSen joins (~Jura@145.224.74.19) |
| 13:40:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 13:42:20 | → | elain4 joins (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) |
| 13:43:42 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac) |
| 13:44:12 | → | oac__ joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 13:44:35 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 13:52:07 | × | chomwitt quits (~chomwitt@94.69.70.96) (Ping timeout: 268 seconds) |
| 13:55:13 | × | AndreiDuma quits (~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:00:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 14:00:41 | → | coot joins (~coot@89-69-206-216.dynamic.chello.pl) |
| 14:02:27 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 14:04:03 | × | caryhartline quits (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 14:05:52 | × | cheater quits (~Username@user/cheater) (Read error: Connection reset by peer) |
| 14:06:01 | → | shapr joins (~user@2600:1700:c640:3100:65fd:cc0d:69b7:c4ce) |
| 14:08:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 14:09:14 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 14:09:36 | → | AndreiDuma joins (~textual@2001:620:130:6092:54b2:c871:96f8:3369) |
| 14:13:21 | → | mheinzel_ joins (~mheinzel@2001:620:130:6092:2930:ff3b:d938:8b1b) |
| 14:15:20 | × | AndreiDuma quits (~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:16:20 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 14:16:27 | × | mheinzel quits (~mheinzel@2001:620:130:6092:f411:94c0:886d:9915) (Ping timeout: 265 seconds) |
| 14:16:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 14:20:15 | × | CiaoSen quits (~Jura@145.224.74.19) (Ping timeout: 256 seconds) |
| 14:20:35 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 14:21:05 | × | jero98772 quits (~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds) |
| 14:21:14 | → | caryhartline joins (~caryhartl@168.182.58.169) |
| 14:26:23 | → | acidjnk joins (~acidjnk@p200300d6e7072f24f1c50d012e792cf9.dip0.t-ipconnect.de) |
| 14:28:25 | → | machinedgod joins (~machinedg@93-136-37-239.adsl.net.t-com.hr) |
| 14:30:15 | → | shriekingnoise joins (~shrieking@186.137.175.87) |
| 14:31:01 | <Athas> | Is there a standard/library definition of this type? data Tree t = Leaf t | Node [Tree t] |
| 14:31:22 | <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. |
| 14:32:11 | <comerijn> | Athas: No values at the nodes? |
| 14:32:58 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 14:32:59 | → | AndreiDuma joins (~textual@2001:620:130:6092:54b2:c871:96f8:3369) |
| 14:33:09 | <Athas> | comerijn: no. |
| 14:33:11 | <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 |
| 14:33:14 | → | jero98772 joins (~jero98772@2800:484:1d7f:5d36::1) |
| 14:33:48 | <Athas> | Is this the kind of tree that is called a rose tree? |
| 14:34:18 | <Athas> | Looks like multiple things are called rose trees, but this is one of them. |
| 14:34:24 | <comerijn> | Athas: I think so, but then Data.Tree also claims to be a rose tree |
| 14:35:08 | <geekosaur> | was gonna say, I've certainly seen that style called out as a rose tree |
| 14:36:07 | <Athas> | Guess I'll have to spend some time writing up my own data type. |
| 14:36:20 | <Athas> | Might be fun. I rarely have a reason to write generic data structures. |
| 14:37:21 | <probie> | type Tree = Free ([]) |
| 14:38:19 | <Athas> | Oh yeah, I guess that would do it. I wonder if all the instances are exactly as I need them. |
| 14:38:34 | → | [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470) |
| 14:38:43 | <Inst_> | well, that's nice |
| 14:38:46 | Inst_ | is now known as Inst |
| 14:39:08 | <Athas> | And I already depend on 'free'. |
| 14:39:35 | <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 |
| 14:39:58 | <Inst> | with a list or vector buffer reducing the recursion to iteration |
| 14:43:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 14:45:03 | × | bionade24 quits (~bionade24@2a03:4000:33:45b::1) (Remote host closed the connection) |
| 14:45:43 | → | bionade24 joins (~bionade24@2a03:4000:33:45b::1) |
| 14:46:41 | × | caryhartline quits (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 14:46:43 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 14:49:43 | × | lbseale quits (~quassel@user/ep1ctetus) (Remote host closed the connection) |
| 14:50:59 | → | lbseale joins (~quassel@user/ep1ctetus) |
| 14:55:57 | <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 |
| 14:57:07 | <[exa]> | rare yet true |
| 14:57:15 | <comerijn> | I'm not even sure that's rare, tbh |
| 14:58:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 14:58:15 | <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 |
| 14:58:32 | <comerijn> | Like the people working on compilers don't generate that code for a reason |
| 14:58:58 | <segfaultfizzbuzz> | i don't understand anything about modern cpus,... |
| 14:59:16 | <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) |
| 14:59:36 | <comerijn> | probie: You also don't spend your entire day staring at Intel architecture manuals ;) |
| 15:00:56 | <comerijn> | segfaultfizzbuzz: understandable, they're complicated messes and most people are content to just operate on how they *imagine* they work :p |
| 15:01:31 | <comerijn> | segfaultfizzbuzz: FWIW, Intel actually publishes really high quality documentation on what's *actually* fast for their chips |
| 15:01:46 | <comerijn> | segfaultfizzbuzz: If you google "Intel Optimization Reference Manual", you should find them |
| 15:01:55 | <segfaultfizzbuzz> | hehe yeah i only ride with intel |
| 15:02:10 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 15:02:11 | <comerijn> | But those are really low level details :p |
| 15:02:41 | <comerijn> | segfaultfizzbuzz: even if you don't, a lot of the things in there are transferable to other architectures to some extent |
| 15:03:59 | × | EvanR quits (~EvanR@user/evanr) (Ping timeout: 250 seconds) |
| 15:05:38 | <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" |
| 15:07:10 | <comerijn> | Not to mention things like SIMD instructions downclocking your CPU, so alternating between SIMD and "regular" instructions cratering performance |
| 15:08:31 | × | gnalzo quits (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 15:16:47 | × | mei quits (~mei@user/mei) (Remote host closed the connection) |
| 15:17:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 15:18:42 | × | bionade24 quits (~bionade24@2a03:4000:33:45b::1) (Remote host closed the connection) |
| 15:19:04 | × | vandita quits (~vandit@84-236-21-42.pool.digikabel.hu) (Ping timeout: 268 seconds) |
| 15:20:17 | → | bionade24 joins (~bionade24@2a03:4000:33:45b::1) |
| 15:20:21 | → | vandita joins (~vandit@178-164-213-114.pool.digikabel.hu) |
| 15:20:22 | × | AndreiDuma quits (~textual@2001:620:130:6092:54b2:c871:96f8:3369) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:20:41 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 15:20:43 | × | lortabac quits (~lortabac@152.96.92.233) (Quit: WeeChat 2.8) |
| 15:21:07 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 15:24:07 | <segfaultfizzbuzz> | 128 core x86 cpus are coming 🤯 |
| 15:24:23 | → | gmg joins (~user@user/gehmehgeh) |
| 15:24:28 | × | dcoutts quits (~duncan@2001:620:130:6092:8b6f:ee09:26cb:f12f) (Ping timeout: 240 seconds) |
| 15:24:32 | <geekosaur> | now you need software that doesn't choke on the overhead of managing 128 cores |
| 15:25:04 | <segfaultfizzbuzz> | jobs |
| 15:27:01 | × | mheinzel_ quits (~mheinzel@2001:620:130:6092:2930:ff3b:d938:8b1b) (Ping timeout: 265 seconds) |
| 15:27:10 | <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 |
| 15:27:18 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 15:27:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 15:27:32 | <segfaultfizzbuzz> | hehe |
| 15:28:54 | → | bontaq joins (~user@ool-45779b84.dyn.optonline.net) |
| 15:31:24 | × | jero98772 quits (~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 265 seconds) |
| 15:31:39 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Quit: segfaultfizzbuzz) |
| 15:42:37 | → | jero98772 joins (~jero98772@2800:484:1d7f:5d36::1) |
| 15:44:37 | × | coot quits (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 15:45:46 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 15:53:03 | → | econo joins (uid147250@user/econo) |
| 15:54:43 | → | caryhartline joins (~caryhartl@168.182.58.169) |
| 15:56:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 15:56:31 | × | machinedgod quits (~machinedg@93-136-37-239.adsl.net.t-com.hr) (Ping timeout: 240 seconds) |
| 15:57:08 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:01:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:02:19 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:06:37 | × | euandreh quits (~Thunderbi@189.6.18.7) (Ping timeout: 240 seconds) |
| 16:09:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:10:34 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection) |
| 16:10:40 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:11:03 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 16:16:18 | → | oneeyedalien joins (~oneeyedal@125-63-26-10.ip4.superloop.au) |
| 16:17:11 | → | ft joins (~ft@p4fc2a88b.dip0.t-ipconnect.de) |
| 16:18:59 | × | oneeyedalien quits (~oneeyedal@125-63-26-10.ip4.superloop.au) (Client Quit) |
| 16:19:28 | × | ubert quits (~Thunderbi@2a02:8109:abc0:6434:523d:9a8b:b2f4:ac13) (Remote host closed the connection) |
| 16:20:00 | → | dhil joins (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 16:20:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:22:13 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:22:41 | × | kuribas quits (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 16:24:20 | → | _ht joins (~Thunderbi@82.174.52.28) |
| 16:26:35 | → | Sciencentistguy5 joins (~sciencent@hacksoc/ordinary-member) |
| 16:29:20 | × | titibandit quits (~titibandi@user/titibandit) (Remote host closed the connection) |
| 16:29:27 | × | Sciencentistguy quits (~sciencent@hacksoc/ordinary-member) (Ping timeout: 256 seconds) |
| 16:29:28 | Sciencentistguy5 | is now known as Sciencentistguy |
| 16:30:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:33:35 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 16:33:48 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:39:16 | → | eggplantade joins (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 16:39:51 | × | vandita quits (~vandit@178-164-213-114.pool.digikabel.hu) (Ping timeout: 268 seconds) |
| 16:41:05 | → | vandita joins (~vandit@84-236-97-3.pool.digikabel.hu) |
| 16:41:35 | → | notzmv joins (~zmv@user/notzmv) |
| 16:45:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:47:44 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:49:02 | × | oac__ quits (~oac@72-50-214-210.fttp.usinternet.com) (Quit: oac__) |
| 16:49:21 | → | oac joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 16:50:43 | → | p3n joins (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 16:50:47 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
| 16:53:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 16:56:13 | × | comerijn quits (~merijn@145.90.225.5) (Ping timeout: 250 seconds) |
| 16:56:45 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 16:57:51 | → | ddellacosta joins (~ddellacos@146.70.166.139) |
| 17:02:52 | → | y04nn joins (~username@2a03:1b20:5:f011::aaae) |
| 17:03:11 | × | eggplantade quits (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 17:05:55 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 17:08:45 | × | ystael quits (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 17:09:23 | → | ystael joins (~ystael@user/ystael) |
| 17:11:41 | × | johnw quits (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 17:16:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 17:20:35 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 17:23:01 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 17:28:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 17:30:03 | → | johnw joins (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 17:35:15 | <[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. |
| 17:35:34 | <[Leary]> | I'm unsniping myself of this problem ... devil willing, let some other poor sod be sniped in my place. |
| 17:36:16 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 17:37:38 | <jade[m]> | hm |
| 17:37:48 | <jade[m]> | sounds interesting |
| 17:38:29 | × | caryhartline quits (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 17:40:41 | → | gnalzo joins (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 17:41:31 | <ncf> | [Leary]: shouldn't you be able to adapt https://agda.github.io/agda-stdlib/Data.List.Sort.MergeSort.html#2550 ? |
| 17:47:48 | × | oac quits (~oac@72-50-214-210.fttp.usinternet.com) (Remote host closed the connection) |
| 17:51:50 | → | hisa387 joins (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
| 17:52:32 | × | fendor quits (~fendor@2a02:8388:1605:7500:3974:8f28:6b80:17ec) (Remote host closed the connection) |
| 17:52:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 17:54:28 | × | hisa38 quits (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 268 seconds) |
| 17:54:28 | hisa387 | is now known as hisa38 |
| 17:56:17 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 17:59:26 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 18:01:15 | × | vandita quits (~vandit@84-236-97-3.pool.digikabel.hu) (Ping timeout: 256 seconds) |
| 18:02:49 | → | vandita joins (~vandit@92-249-193-31.pool.digikabel.hu) |
| 18:03:39 | × | notzmv quits (~zmv@user/notzmv) (Ping timeout: 265 seconds) |
| 18:04:47 | <[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. |
| 18:04:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 18:05:40 | <ncf> | have you tried asking on cstheory.stackexchange? |
| 18:07:07 | <[Leary]> | Nah, I haven't been on any of the stackexchanges in forever. Probably not worth breaking back in just for this curiosity. |
| 18:08:05 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 18:09:32 | <ncf> | wtf |
| 18:15:18 | <sm> | also, there's a strike on (stack exchange contributors protesting SE's new AI policy) |
| 18:15:53 | <jade[m]> | the one that disallows the use of chatgpt? |
| 18:16:33 | <darkling> | The one that forbids mods from removing things produced by AI. |
| 18:17:08 | <sm> | I think it's the reverse, SE has disallowed policies blocking chatgpt and (I read, do verify) disallowed them from talking about it |
| 18:17:28 | <jade[m]> | ahh, then a strike is reasonable |
| 18:17:38 | <jade[m]> | I agree with the ban fully |
| 18:17:53 | <jade[m]> | s/the ban/the ban of chatgpt/ |
| 18:18:14 | → | EvanR joins (~EvanR@user/evanr) |
| 18:19:34 | <sm> | I heard about it on mastodon (#stackexchange tag) and https://openletter.mousetail.nl seems to be the home |
| 18:20:15 | <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 |
| 18:20:31 | <sm> | if true |
| 18:21:16 | <jade[m]> | I would hope and also assume they wouldn't lie about such a thing |
| 18:21:36 | <jade[m]> | i agree with this strike if it truly is how they say |
| 18:21:50 | <sm> | indeed, it's just we truly have to to fact check everything seen on the net these days |
| 18:22:32 | <jade[m]> | mhm |
| 18:22:42 | <jade[m]> | I have a lot of issues with chatgpt |
| 18:23:47 | <EvanR> | I read something suspicious, better consult chat-GPT |
| 18:24:33 | <EvanR> | I mean it's been 22 years since they achieved a computer who is incapable of making mistakes |
| 18:28:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 18:28:16 | <probie> | I wonder if we can use an LLM like ChatGPT to resolve the truly hard questions like "tabs or spaces" |
| 18:29:21 | × | gmg quits (~user@user/gehmehgeh) (Remote host closed the connection) |
| 18:29:39 | <jade[m]> | it'll probably be the most generic "both have their advantages" answer with a few factual errors sprinkled in between |
| 18:29:43 | <[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 |
| 18:29:49 | <[exa]> | s/ a / / |
| 18:30:05 | <[Leary]> | I think dmwit already resolved that one. The answer, surprisingly, is "both". |
| 18:30:10 | → | gmg joins (~user@user/gehmehgeh) |
| 18:30:12 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 18:30:57 | <geekosaur> | "wadler-complete" |
| 18:31:45 | <[exa]> | [Leary]: (link? I'm curious. I'm using tabs for indent and spaces for aligning stuff, so wondering if there are other ways) |
| 18:32:19 | <[Leary]> | [exa]: http://dmwit.com/tabs/ |
| 18:32:24 | → | biberu\ joins (~biberu@user/biberu) |
| 18:32:31 | <jade[m]> | I just space everything, tabs are confusing and my brain is too small for that |
| 18:32:33 | <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. :) |
| 18:32:48 | <[Leary]> | Though it sounds like you've already come to the same conclusion. |
| 18:33:10 | <EvanR> | what about form feed? |
| 18:33:34 | <darkling> | That would be weird. |
| 18:33:55 | <[exa]> | [Leary]: thanks! yeah that's it |
| 18:34:44 | <[exa]> | EvanR: I actually saw someone to use either that or vertical tabs to separate functions in the code |
| 18:35:08 | <geekosaur> | FF to separate C functions goes back further than I do 🙂 |
| 18:35:12 | <EvanR> | that's why you should always have visible form feeds enabled |
| 18:35:28 | × | biberu quits (~biberu@user/biberu) (Ping timeout: 250 seconds) |
| 18:35:28 | biberu\ | is now known as biberu |
| 18:36:19 | <jade[m]> | > tabs for indentation, spaces for alignment |
| 18:36:19 | <jade[m]> | seems decent enough |
| 18:36:21 | <lambdabot> | <hint>:1:21: error: parse error on input ‘,’ |
| 18:37:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 18:41:34 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 18:42:00 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection) |
| 18:42:55 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 18:43:17 | → | 011AAD3PH joins (~oac@72-50-214-210.fttp.usinternet.com) |
| 18:44:46 | <sm> | interesting: https://libera.chat/minutes/2023-03-31-public#where-are-we-on-matrix-changes |
| 18:47:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 18:47:57 | → | lortabac joins (~lortabac@46-253-188-2.dynamic.monzoon.net) |
| 18:48:27 | × | raehik quits (~raehik@82.21.176.157) (Ping timeout: 250 seconds) |
| 18:50:48 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 18:50:55 | → | euandreh joins (~Thunderbi@189.6.18.7) |
| 18:52:54 | → | k`` joins (~user@152.7.255.207) |
| 18:53:06 | → | euandreh1 joins (~Thunderbi@189.6.18.7) |
| 18:53:28 | × | euandreh quits (~Thunderbi@189.6.18.7) (Client Quit) |
| 18:53:29 | euandreh1 | is now known as euandreh |
| 18:55:04 | → | Feuermagier joins (~Feuermagi@user/feuermagier) |
| 18:56:07 | × | ddellacosta quits (~ddellacos@146.70.166.139) (Ping timeout: 240 seconds) |
| 18:56:08 | <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? |
| 18:57:23 | <jean-paul[m]> | sm: it reads like "Libera channels must now opt-in to Matrix bridging"? Do I understand right? |
| 18:57:46 | <k``> | (by analogy, the `a` and `b` in `fmap :: (a -> b) -> m a -> m b` are not constrained) |
| 18:58:08 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 248 seconds) |
| 18:58:08 | <geekosaur> | not yet apparently, since that was in March? |
| 18:58:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 18:58:09 | <ncf> | k``: FFunctor is supposed to represent an endofunctor on the category of endofunctors on Hask |
| 18:58:20 | <geekosaur> | but I'm off for a bit |
| 18:59:09 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 19:01:11 | <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 |
| 19:01:19 | <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" |
| 19:02:34 | <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? |
| 19:02:42 | → | zxrom joins (~zxrom@mm-62-27-212-37.vitebsk.dynamic.pppoe.byfly.by) |
| 19:03:11 | <ncf> | ah, well i'm pretending it is :) |
| 19:03:13 | <jade[m]> | afaik hask has neither shown nor be disproven to be a category |
| 19:03:27 | <[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`. |
| 19:04:07 | × | lortabac quits (~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 240 seconds) |
| 19:04:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 19:04:32 | <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 |
| 19:07:58 | <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. |
| 19:08:24 | <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` |
| 19:08:27 | → | lortabac joins (~lortabac@46-253-188-2.dynamic.monzoon.net) |
| 19:09:02 | <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) |
| 19:09:24 | <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 |
| 19:09:26 | <EvanR> | Hask is a category in the sense that pluto is a planet |
| 19:09:43 | <jade[m]> | heh |
| 19:09:52 | × | d34df00d quits (~d34df00d@2600:1702:4f1b:7c10::e) (Remote host closed the connection) |
| 19:09:52 | <k``> | (ncf: although it might matter a lot depending on the cost of `fmap` :) |
| 19:10:45 | → | mheinzel_ joins (~mheinzel@2001:1716:4614:4250:96ee:7cb:56b8:8ea4) |
| 19:11:19 | <ncf> | EvanR: at least i'm fairly certain that "Pluto" has a well-agreed-upon definition :p |
| 19:11:34 | <probie> | It's a dog |
| 19:11:55 | <ncf> | import System.Solar (Pluto) |
| 19:12:31 | <chromoblob> | poor Pluto :..( |
| 19:12:58 | <k``> | Just switch to a language where it's a "star". |
| 19:13:30 | <k``> | Pluto :: * |
| 19:13:31 | <ncf> | probie: just in case, that's hoistFix' from data-fix |
| 19:13:48 | → | alexherbo2 joins (~alexherbo@2a02-842a-8180-4601-b9db-66de-a2df-2e68.rev.sfr.net) |
| 19:15:46 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 19:16:23 | <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)` |
| 19:16:24 | <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 |
| 19:16:38 | <probie> | s/hostFix/hoistFix/ |
| 19:17:03 | <ncf> | okay |
| 19:17:24 | <probie> | so my Fix doesn't come from `data-fix` (of course, it is the exact same definition) |
| 19:18:22 | <k``> | probis: What do you use it for? |
| 19:19:00 | <probie> | k``: If I told you `map` and `filter` over lists, would you believe me? |
| 19:21:08 | × | mheinzel_ quits (~mheinzel@2001:1716:4614:4250:96ee:7cb:56b8:8ea4) (Ping timeout: 240 seconds) |
| 19:21:46 | <probie> | https://paste.tomsmeding.com/sIfoZjzb |
| 19:22:02 | × | enoq quits (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 19:22:08 | × | czy quits (~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 19:22:11 | <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` ... |
| 19:23:01 | <EvanR> | so you want to delete an item from an array, first let me introduce you to some category theory |
| 19:24:00 | <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 |
| 19:24:12 | jade[m] | fails to even understand the Fix type |
| 19:24:37 | × | vandita quits (~vandit@92-249-193-31.pool.digikabel.hu) (Ping timeout: 240 seconds) |
| 19:24:48 | <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 |
| 19:25:49 | <jade[m]> | probie: sounds a little like APL heh |
| 19:25:55 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 19:26:34 | → | vandita joins (~vandit@178-164-188-17.pool.digikabel.hu) |
| 19:26:49 | <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) |
| 19:29:30 | <ncf> | probie: you know you can get fix from Fix, yeah? |
| 19:30:22 | <[Leary]> | probie: I like to play around in such languages (System F, Dhall) sometimes. My conclusion: recursion is an optimisation. |
| 19:30:47 | → | dfit^ joins (~dfit@c-71-204-38-59.hsd1.ga.comcast.net) |
| 19:33:37 | <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. |
| 19:34:19 | <EvanR> | one way to achieve that is to name the arbitrary recursion something like ArbitraryRecursionTool |
| 19:34:36 | <EvanR> | instead of fix |
| 19:34:45 | × | lortabac quits (~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 240 seconds) |
| 19:34:51 | <EvanR> | (syntactic salt) |
| 19:34:52 | <probie> | How about `arbitraryRecursionToolIConsiderToBeAsMorallyQuestionableAsGoto`? |
| 19:35:42 | <ncf> | probie: wait, how do you construct fix from Fix (Either a)? |
| 19:35:45 | <jade[m]> | that just looks like a class from an enterprise level java application |
| 19:35:55 | <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 |
| 19:36:18 | <EvanR> | as long as that flow chart isn't broken, GOTO is the best way to implement it xD |
| 19:36:27 | <monochrom> | :) |
| 19:38:00 | → | mheinzel_ joins (~mheinzel@2001:1716:4614:4250:73b4:7d09:b688:3bad) |
| 19:38:08 | × | dhil quits (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 240 seconds) |
| 19:38:33 | <sm> | jean-paul.: more recent info: https://libera.chat/news/matrix-irc-bridge-updates . Sounds like both sides are doing good work |
| 19:38:50 | <ncf> | (i'm actually fairly sure you can't, since Either a has a fixed point in the topos of trees) |
| 19:39:30 | <ncf> | no wait never mind |
| 19:39:58 | monochrom | founds the Free Open Recursion Software movement. FORS. |
| 19:40:11 | → | machinedgod joins (~machinedg@93-136-37-239.adsl.net.t-com.hr) |
| 19:40:32 | <monochrom> | "free as in free monad" >:) |
| 19:40:40 | <jean-paul[m]> | sm: thanks |
| 19:41:35 | <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) |
| 19:42:30 | <probie> | I'm probably thinking of something like `(a -> Either b a) -> b` |
| 19:42:41 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 19:42:42 | <ncf> | that sounds more plausible |
| 19:44:09 | <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). |
| 19:46:40 | <probie> | ncf: fix = hylo (uncurry ($)) (\x -> (x,x)) -- Either and (,) are pretty much the same. It's an easy mistake to make |
| 19:47:09 | <ncf> | :t hylo |
| 19:47:10 | <lambdabot> | error: Variable not in scope: hylo |
| 19:47:22 | <ncf> | hylo :: Functor f => (f b -> b) -> (a -> f a) -> a -> b |
| 19:47:59 | <ncf> | hmm |
| 19:48:42 | → | pavonia joins (~user@user/siracusa) |
| 19:48:52 | <ncf> | confused |
| 19:49:16 | <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 |
| 19:49:25 | <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 |
| 19:49:27 | <lambdabot> | 120 |
| 19:49:30 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds) |
| 19:50:10 | <probie> | (in my world, hylo is primitive, hence why it's allowed a recursive definition) |
| 19:50:21 | <ncf> | oh right |
| 19:50:30 | <k``> | I am reminded of http://comonad.com/reader/2022/internalized-guarded-recursion-for-equational-reasoning/ |
| 19:50:37 | <ncf> | so you're unfolding (a -> a) to an infinite tuple of itself, and then folding that by application |
| 19:50:45 | <ncf> | nice |
| 19:50:47 | <probie> | Yep |
| 19:50:48 | × | waleee quits (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds) |
| 19:53:15 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 19:53:53 | <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` |
| 19:56:29 | <probie> | those aren't the same as `cata` and `ana` from the recursion-schemes package, because there's no base functor shenanigans |
| 19:57:29 | → | nschoe joins (~q@2a01:e0a:8e:a190:9e55:3755:287b:82c1) |
| 19:58:32 | → | enoq joins (~enoq@194-208-133-121.lampert.tv) |
| 19:58:40 | <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 |
| 19:58:44 | → | lortabac joins (~lortabac@46-253-188-2.dynamic.monzoon.net) |
| 19:58:58 | <probie> | which I was worried wouldn't happen with my weird filter definition |
| 19:59:10 | × | trev quits (~trev@user/trev) (Quit: trev) |
| 20:00:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:01:03 | × | mheinzel_ quits (~mheinzel@2001:1716:4614:4250:73b4:7d09:b688:3bad) (Remote host closed the connection) |
| 20:01:20 | → | mheinzel_ joins (~mheinzel@2001:1716:4614:4250:3e67:58a3:77f7:d5a5) |
| 20:02:06 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:07:42 | × | _ht quits (~Thunderbi@82.174.52.28) (Remote host closed the connection) |
| 20:08:01 | × | mheinzel_ quits (~mheinzel@2001:1716:4614:4250:3e67:58a3:77f7:d5a5) (Ping timeout: 240 seconds) |
| 20:08:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:11:35 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:11:39 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 20:12:32 | → | notzmv joins (~zmv@user/notzmv) |
| 20:13:30 | × | gurkenglas quits (~user@dynamic-046-114-176-088.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 20:13:50 | <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) |
| 20:14:51 | → | waleee joins (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 20:19:20 | → | gurkenglas joins (~user@46.114.176.88) |
| 20:19:33 | → | chomwitt joins (~chomwitt@94.69.70.96) |
| 20:19:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:21:44 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:25:22 | → | Pickchea joins (~private@user/pickchea) |
| 20:25:38 | × | le__ka quits (~l_k@213.24.134.106) (Quit: Leaving) |
| 20:29:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:31:11 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:36:13 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 20:36:54 | → | o-90 joins (~o-90@gateway/tor-sasl/o-90) |
| 20:36:59 | × | o-90 quits (~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection) |
| 20:41:28 | × | hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 20:42:06 | → | TheCoffeMaker joins (~TheCoffeM@user/thecoffemaker) |
| 20:42:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:44:01 | → | zeenk joins (~zeenk@2a02:2f04:a106:3c00::7fe) |
| 20:44:54 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:51:05 | → | hugo joins (znc@verdigris.lysator.liu.se) |
| 20:52:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 20:54:02 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 20:55:48 | → | Square joins (~Square@user/square) |
| 20:56:10 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 20:56:32 | × | k`` quits (~user@152.7.255.207) (Ping timeout: 248 seconds) |
| 21:03:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 21:04:34 | × | nek0 quits (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 21:04:57 | × | lortabac quits (~lortabac@46-253-188-2.dynamic.monzoon.net) (Ping timeout: 250 seconds) |
| 21:06:13 | × | szkl quits (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 21:06:29 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 21:10:09 | × | enoq quits (~enoq@194-208-133-121.lampert.tv) (Quit: enoq) |
| 21:10:18 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 21:11:55 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection) |
| 21:12:20 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 21:14:27 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 21:15:44 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 21:23:37 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 21:27:49 | × | michalz quits (~michalz@185.246.207.201) (Remote host closed the connection) |
| 21:30:32 | × | 011AAD3PH quits (~oac@72-50-214-210.fttp.usinternet.com) (Remote host closed the connection) |
| 21:30:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 21:32:34 | × | alexherbo2 quits (~alexherbo@2a02-842a-8180-4601-b9db-66de-a2df-2e68.rev.sfr.net) (Remote host closed the connection) |
| 21:32:44 | × | chomwitt quits (~chomwitt@94.69.70.96) (Remote host closed the connection) |
| 21:33:08 | × | chromoblob quits (~user@37.113.158.8) (Ping timeout: 240 seconds) |
| 21:35:02 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 21:40:47 | × | biberu quits (~biberu@user/biberu) (Ping timeout: 268 seconds) |
| 21:41:07 | × | nschoe quits (~q@2a01:e0a:8e:a190:9e55:3755:287b:82c1) (Quit: Switching off) |
| 21:41:07 | × | vglfr quits (~vglfr@188.239.201.89) (Ping timeout: 256 seconds) |
| 21:42:36 | → | biberu joins (~biberu@user/biberu) |
| 21:43:02 | × | elain4 quits (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Remote host closed the connection) |
| 21:44:29 | → | vglfr joins (~vglfr@2a0d:3344:140c:2810:a8ed:895f:3485:d7a6) |
| 21:47:44 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 21:48:13 | × | gnalzo quits (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 21:52:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 21:53:38 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 21:53:38 | × | andreas303 quits (andreas303@is.drunk.and.ready-to.party) (Ping timeout: 246 seconds) |
| 21:54:05 | × | bontaq quits (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 240 seconds) |
| 21:58:40 | → | cheater joins (~Username@user/cheater) |
| 21:58:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 22:01:18 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 22:03:18 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection) |
| 22:06:49 | × | gmg quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 22:22:59 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 22:25:05 | → | andreas303 joins (andreas303@is.drunk.and.ready-to.party) |
| 22:28:56 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 22:30:12 | → | Tuplanolla joins (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 22:31:01 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 22:35:00 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 22:36:07 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) |
| 22:38:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 22:38:44 | × | machinedgod quits (~machinedg@93-136-37-239.adsl.net.t-com.hr) (Ping timeout: 246 seconds) |
| 22:39:23 | × | vulpine quits (xfnw@tilde.team) (Quit: Connection reset by purr) |
| 22:40:06 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 22:44:40 | → | thegeekinside joins (~thegeekin@189.217.90.138) |
| 22:46:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 22:47:07 | × | xff0x_ quits (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 240 seconds) |
| 22:49:08 | → | xff0x_ joins (~xff0x@178.255.149.135) |
| 22:49:24 | × | andreas303 quits (andreas303@is.drunk.and.ready-to.party) (Ping timeout: 250 seconds) |
| 22:52:56 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 22:55:05 | → | vulpine joins (xfnw@tilde.team) |
| 22:58:08 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 23:00:59 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 23:01:22 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 23:02:09 | → | jargon joins (~jargon@184.101.71.62) |
| 23:04:46 | × | xff0x_ quits (~xff0x@178.255.149.135) (Ping timeout: 265 seconds) |
| 23:06:24 | → | xff0x_ joins (~xff0x@2405:6580:b080:900:7473:54f9:1e2f:2bc) |
| 23:09:12 | → | mauke_ joins (~mauke@user/mauke) |
| 23:09:27 | → | merijn joins (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) |
| 23:10:45 | × | shriekingnoise quits (~shrieking@186.137.175.87) (Ping timeout: 240 seconds) |
| 23:11:13 | × | mauke quits (~mauke@user/mauke) (Ping timeout: 256 seconds) |
| 23:11:13 | mauke_ | is now known as mauke |
| 23:11:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 23:13:03 | × | gurkenglas quits (~user@46.114.176.88) (Read error: Connection reset by peer) |
| 23:15:04 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 23:15:28 | → | andreas303 joins (andreas303@is.drunk.and.ready-to.party) |
| 23:20:23 | × | acidjnk quits (~acidjnk@p200300d6e7072f24f1c50d012e792cf9.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 23:20:32 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 23:24:56 | × | zeenk quits (~zeenk@2a02:2f04:a106:3c00::7fe) (Quit: Konversation terminated!) |
| 23:28:07 | × | _d0t quits (~{-d0t-}@user/-d0t-/x-7915216) (Remote host closed the connection) |
| 23:34:22 | × | hexology quits (~hexology@user/hexology) (Quit: hex on you ...) |
| 23:34:43 | → | hexology joins (~hexology@user/hexology) |
| 23:36:40 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
| 23:36:46 | → | Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 23:42:46 | → | nek0 joins (~nek0@2a01:4f8:222:2b41::12) |
| 23:43:01 | × | merijn quits (~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 23:47:29 | → | blackpill0w joins (~blackpill@user/blackpill0w) |
| 23:50:23 | → | Albina_Pavlovna joins (~Albina_Pa@2600:4040:9526:fe00:c14:24f5:954f:f0a3) |
| 23:56:40 | → | shriekingnoise joins (~shrieking@186.137.175.87) |
| 23:57:20 | × | ec_ quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 23:58:20 | → | ec_ joins (~ec@gateway/tor-sasl/ec) |
All times are in UTC on 2023-06-07.