| 2022-01-31 00:00:11 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) |
| 2022-01-31 00:01:01 +0100 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-01-31 00:02:47 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 250 seconds) |
| 2022-01-31 00:03:18 +0100 | burnside_ | (~burnsides@dhcp168-016.wadham.ox.ac.uk) |
| 2022-01-31 00:04:10 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-01-31 00:04:36 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-31 00:09:02 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-31 00:10:16 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 00:11:14 +0100 | <dminuoso> | Mmm, decisions decisions.. should I provide a Data instance but hide the data-constructor and only expose a smart constructor? |
| 2022-01-31 00:11:24 +0100 | <dminuoso> | Or should I not provide a Data instance? |
| 2022-01-31 00:11:28 +0100 | dminuoso | cant decide |
| 2022-01-31 00:14:28 +0100 | Null_A | (~null_a@c-98-210-133-39.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2022-01-31 00:14:41 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 250 seconds) |
| 2022-01-31 00:15:30 +0100 | jkaye | (~jkaye@2601:281:8300:7530:d551:c5d6:10bb:b867) (Quit: Leaving) |
| 2022-01-31 00:16:02 +0100 | <EvanR> | it's great when math and logic do not apply https://i.imgur.com/02hZzOS.png |
| 2022-01-31 00:16:50 +0100 | <dminuoso> | EvanR: hah, what is that? |
| 2022-01-31 00:16:57 +0100 | <EvanR> | glsl |
| 2022-01-31 00:17:26 +0100 | <dminuoso> | Is this implying that creating a can mutate m or n? |
| 2022-01-31 00:17:49 +0100 | <dminuoso> | (Or their memory stores, rather?) |
| 2022-01-31 00:17:53 +0100 | <EvanR> | no but who the F knows what else can happen xD |
| 2022-01-31 00:19:22 +0100 | <davean> | dminuoso: I mean if you add numbers twice, no reason to think they add to the same thing |
| 2022-01-31 00:19:31 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-01-31 00:19:33 +0100 | <EvanR> | ??? |
| 2022-01-31 00:19:34 +0100 | <dminuoso> | Oh mmm. |
| 2022-01-31 00:19:41 +0100 | <dminuoso> | Yeah I see what you're getting at |
| 2022-01-31 00:19:54 +0100 | <EvanR> | yeah if you're measuring a piece of lumber for cutting |
| 2022-01-31 00:19:58 +0100 | <EvanR> | or using glsl |
| 2022-01-31 00:20:05 +0100 | <hpc> | this is well known in ML circles |
| 2022-01-31 00:20:11 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 00:20:47 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-01-31 00:20:51 +0100 | <davean> | dminuoso: I'm kinda confused why you think they might, thats not how math works. |
| 2022-01-31 00:21:11 +0100 | <davean> | I've checked by running the calculations on a GPU |
| 2022-01-31 00:21:13 +0100 | EvanR | kicks the sarcasm detector |
| 2022-01-31 00:21:58 +0100 | <hpc> | i am 100.00000002% certain that davean is correct here |
| 2022-01-31 00:23:45 +0100 | <EvanR> | this is more egregious than I'm used to with floats |
| 2022-01-31 00:25:48 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:2541:beac:9acd:61a8) |
| 2022-01-31 00:27:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-31 00:28:06 +0100 | mmhat | (~mmh@55d4f2c4.access.ecotel.net) (Quit: WeeChat 3.4) |
| 2022-01-31 00:28:36 +0100 | <ephemient> | even without talking about the GPU, on x86 CPUs you'll get different results from x87 vs SSE arithmetic, and a compiler could decide to use both… |
| 2022-01-31 00:28:59 +0100 | <davean> | ephemient: Well, no, not EXACTLY. You CAN due to precision |
| 2022-01-31 00:29:08 +0100 | <davean> | it depends when and how you do register moves |
| 2022-01-31 00:29:33 +0100 | <EvanR> | does none of this happen in haskell because every float computation begins and ends in a heap object |
| 2022-01-31 00:29:46 +0100 | <davean> | haha, no it CAN happen in Haskell |
| 2022-01-31 00:29:54 +0100 | <davean> | Though we dropped x87 I think |
| 2022-01-31 00:29:56 +0100 | <davean> | a few versions back |
| 2022-01-31 00:30:07 +0100 | <EvanR> | ?_? |
| 2022-01-31 00:30:08 +0100 | <ephemient> | well in practice any compilers targeting x86-64 are gonna be using SSE only anyhow |
| 2022-01-31 00:30:42 +0100 | <davean> | ephemient: not entirely true |
| 2022-01-31 00:30:47 +0100 | <EvanR> | so how much precision does SSE use |
| 2022-01-31 00:30:53 +0100 | <ephemient> | I think SSE2 is implemented in all 64-bit processors except for some old atoms? |
| 2022-01-31 00:30:56 +0100 | <davean> | 16, 32, or 64 bits |
| 2022-01-31 00:31:09 +0100 | jgeerds_ | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 250 seconds) |
| 2022-01-31 00:31:16 +0100 | <davean> | But x87 does calculations in 80 bits, and stores and loads in 64 bits |
| 2022-01-31 00:31:17 +0100 | mud | (~mud@user/kadoban) (Ping timeout: 240 seconds) |
| 2022-01-31 00:31:56 +0100 | <davean> | ephemient: In practice 80 bit floats are still evailable, you just need to use them right |
| 2022-01-31 00:32:28 +0100 | <EvanR> | what do you call a compiler or property of compilation where the nonsense in Example 2 above is not possible |
| 2022-01-31 00:32:29 +0100 | <ephemient> | there's also the fact that x86-32 abi used the x87 registers to pass floating point around, but x86-64 abi uses xmm registers |
| 2022-01-31 00:32:38 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2022-01-31 00:32:48 +0100 | <davean> | ephemient: broken! |
| 2022-01-31 00:32:54 +0100 | <davean> | er, that was for EvanR |
| 2022-01-31 00:33:00 +0100 | <EvanR> | broken? |
| 2022-01-31 00:33:04 +0100 | <davean> | EvanR: Broken! |
| 2022-01-31 00:33:05 +0100 | <ephemient> | if everything's already in xmm you have to do extra work to get it over to the x87 fpu |
| 2022-01-31 00:33:05 +0100 | <EvanR> | or not-broken |
| 2022-01-31 00:33:20 +0100 | <davean> | EvanR: Thats what we call a compiler that gets the same results when it adds the same floats twice |
| 2022-01-31 00:33:27 +0100 | <EvanR> | >_> |
| 2022-01-31 00:33:57 +0100 | <davean> | Theres some 128bit float support in SSE I think, I've never used it though |
| 2022-01-31 00:34:11 +0100 | <davean> | EvanR: The reason x87 does 80 bits is very legitimate |
| 2022-01-31 00:34:16 +0100 | <davean> | it just causes problems for high level languages |
| 2022-01-31 00:34:21 +0100 | <EvanR> | I don't care about 80 bits |
| 2022-01-31 00:34:33 +0100 | <monochrom> | Oh I know! Functional is when a and b are the same. Imperative is when a and b are different. :) |
| 2022-01-31 00:34:35 +0100 | <EvanR> | I care about getting the same answer if you do the same thing |
| 2022-01-31 00:34:54 +0100 | <EvanR> | use 80 bits or not |
| 2022-01-31 00:35:07 +0100 | <davean> | EvanR: you DO get the same answer if you do the same thing, the problem is things like scheduling affect if they're the same thingh |
| 2022-01-31 00:35:18 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-01-31 00:35:20 +0100 | <EvanR> | on paper, they look exactly the same |
| 2022-01-31 00:35:27 +0100 | <EvanR> | i don't buy "x does not equal x, sorry" |
| 2022-01-31 00:35:43 +0100 | <ephemient> | in two different contexts, they may be optimized differently |
| 2022-01-31 00:35:47 +0100 | <EvanR> | depending on compiler, something could have happened between x and x |
| 2022-01-31 00:35:51 +0100 | <davean> | EvanR: No, see, they *DON'T* look the same on paper, thats why x87 is 80 bits |
| 2022-01-31 00:36:03 +0100 | <EvanR> | this paper |
| 2022-01-31 00:36:05 +0100 | <davean> | EvanR: it comes from an engenering precion requirement |
| 2022-01-31 00:36:08 +0100 | <EvanR> | a = m + n |
| 2022-01-31 00:36:10 +0100 | <EvanR> | b = m + n |
| 2022-01-31 00:36:15 +0100 | <ephemient> | or, the compiler might decide to compile them differently even if they're right next to each other, because it decides that's a better use of processor resources |
| 2022-01-31 00:36:30 +0100 | <davean> | Your system just makes it basicly impossible to use x87 rigth |
| 2022-01-31 00:36:40 +0100 | <davean> | ephemient: yep |
| 2022-01-31 00:36:50 +0100 | <EvanR> | alright well, I prefer broken then |
| 2022-01-31 00:36:51 +0100 | <davean> | I was just focusing on one side of the weirdness |
| 2022-01-31 00:37:07 +0100 | <davean> | EvanR: we all prefer broken |
| 2022-01-31 00:37:26 +0100 | <ephemient> | I think we're mostly coming to that conclusion anyhow |
| 2022-01-31 00:37:51 +0100 | <davean> | x87 was great in the days of cooperative multiprocessing with your kernels writen in ASM |
| 2022-01-31 00:38:10 +0100 | <davean> | now we can afford 128bit floats |
| 2022-01-31 00:38:16 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-01-31 00:38:21 +0100 | <ephemient> | Java 17 killed strictfp (making it the default) so they're definitely not using x87 anymore |
| 2022-01-31 00:38:41 +0100 | <EvanR> | I'm not even sure how 80 bits helps two 64bit additions |
| 2022-01-31 00:38:57 +0100 | <EvanR> | wouldn't 80 bits only matter in a series of computations that stay 80 bits |
| 2022-01-31 00:39:09 +0100 | <davean> | oh and I want to be clear we're talking bfloat here |
| 2022-01-31 00:39:34 +0100 | <ephemient> | maybe your inputs come from other computations and have intermediate 80-bit forms |
| 2022-01-31 00:39:50 +0100 | <davean> | EvanR: See thats the problem - your entire kernel isn't supposed to leave x87 |
| 2022-01-31 00:40:09 +0100 | <davean> | its a *coprocessor* |
| 2022-01-31 00:40:11 +0100 | <davean> | not an instruction set |
| 2022-01-31 00:40:29 +0100 | <davean> | its a *second computer you get answers out of* |
| 2022-01-31 00:40:39 +0100 | <EvanR> | the original GPU |
| 2022-01-31 00:40:46 +0100 | <EvanR> | DOS can't be pure |
| 2022-01-31 00:41:01 +0100 | <EvanR> | there's only 1 math coprocessor |
| 2022-01-31 00:41:28 +0100 | <dminuoso> | davean: In shaders, you dont have general assurance of invariance |
| 2022-01-31 00:41:44 +0100 | <dminuoso> | Which can lead to one operation being computed differently in different computation units |
| 2022-01-31 00:42:17 +0100 | <EvanR> | and different computation units conveniently are all configured with various precisions? |
| 2022-01-31 00:42:34 +0100 | <EvanR> | not your dad's parallelism |
| 2022-01-31 00:42:40 +0100 | <davean> | dminuoso: No, shaders are all sorts of fucked up - esp because they deal with the SIMT model so your other branches can mess with you |
| 2022-01-31 00:43:09 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:685d:59ed:4faf:3de1) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-31 00:43:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 00:43:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 00:43:45 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 00:44:10 +0100 | <dminuoso> | EvanR: Sorry a weird typo. Compilation units. |
| 2022-01-31 00:44:19 +0100 | <dminuoso> | EvanR: Reason being different optimizations |
| 2022-01-31 00:44:40 +0100 | <EvanR> | so why do the different compilation units have different optimizations |
| 2022-01-31 00:45:15 +0100 | <dminuoso> | Who knows. Optimizers do all kinds of funky things, maybe there's different levels of information available, different optimization passes that kick in because they spot funky things.. |
| 2022-01-31 00:45:19 +0100 | <davean> | You can't just use floats without doing your numerical methods |
| 2022-01-31 00:45:24 +0100 | <dminuoso> | Noboy can tell you why exactly the GHC simplifier does a particular thing either |
| 2022-01-31 00:45:34 +0100 | <dminuoso> | It's a strange interaction from all passes |
| 2022-01-31 00:46:48 +0100 | <SrPx> | github.com/kindelia/hvm feedbacks before I announce? :) |
| 2022-01-31 00:46:52 +0100 | <dminuoso> | EvanR: And perhaps the GLSL compiler takes advantage of non-invariance, when its free to do "kind of correct" optimizations based on local context |
| 2022-01-31 00:47:34 +0100 | monochrom | takes "premature optimization is the root of all evil" and deletes "premature". :) |
| 2022-01-31 00:47:38 +0100 | <EvanR> | that's what the section is about, moving computations around as if they are pure, redoing them sometimes, but at different precision |
| 2022-01-31 00:47:56 +0100 | Codaraxis__ | (~Codaraxis@user/codaraxis) (Read error: Connection reset by peer) |
| 2022-01-31 00:47:57 +0100 | Codaraxis_ | (~Codaraxis@user/codaraxis) |
| 2022-01-31 00:48:16 +0100 | <EvanR> | THAT seems broken |
| 2022-01-31 00:49:38 +0100 | <EvanR> | it seems within this context "optimization" doesn't entail "leaving the original behavior intact" |
| 2022-01-31 00:50:07 +0100 | <EvanR> | baby with the bathwater would take that and say why not return a black screen every time in the name of performance |
| 2022-01-31 00:51:21 +0100 | <ephemient> | in the context of shaders, floating point is only approximately defined. as long as the graphics that come out look close enough |
| 2022-01-31 00:52:42 +0100 | Ved2311 | (~Ved2311@2600:1700:d840:2370:2c7f:af63:1c:7efc) |
| 2022-01-31 00:53:09 +0100 | <monochrom> | Yeah "behaviour" allows a margin in this case. |
| 2022-01-31 00:53:37 +0100 | <monochrom> | But the margin is not large enough to include black screen. |
| 2022-01-31 00:55:07 +0100 | TonyStone31 | (~TonyStone@2603-7080-8607-c36a-cdff-5348-04ff-b4e2.res6.spectrum.com) |
| 2022-01-31 00:55:08 +0100 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Quit: Leaving) |
| 2022-01-31 00:55:10 +0100 | <monochrom> | People do not want to say "if sometimes you can afford more guard bits so you can be more accurate, don't, we want the original inaccuracy, because reproducible builds". |
| 2022-01-31 00:55:11 +0100 | <EvanR> | so in general are you supposed to interpret every float computation as having some noisy envelope around it, as if you're doing physics xD |
| 2022-01-31 00:55:11 +0100 | TonyStone31 | (~TonyStone@2603-7080-8607-c36a-cdff-5348-04ff-b4e2.res6.spectrum.com) (Remote host closed the connection) |
| 2022-01-31 00:55:28 +0100 | <monochrom> | I would. |
| 2022-01-31 00:55:37 +0100 | TonyStone | (~TonyStone@2603-7080-8607-c36a-cdff-5348-04ff-b4e2.res6.spectrum.com) |
| 2022-01-31 00:55:38 +0100 | <EvanR> | which seems to defeat the purpose of digital computers |
| 2022-01-31 00:56:09 +0100 | <monochrom> | Oh, "noise" "error" are just a simplified model. |
| 2022-01-31 00:56:23 +0100 | <Axman6> | I found out the other day that on PPC, long double is implemented as a pair of doubles, giving 106 bits of precision but the same exponent, and this can lead to both subnormal and "supernormal" numbers |
| 2022-01-31 00:56:38 +0100 | <Axman6> | The things you learn reading Apple's header files... |
| 2022-01-31 00:57:22 +0100 | <monochrom> | The same way tossing a coin is modelled by probability "uncertainty" because I can't be bothered to take measurements and use Newtonian mechanics to determinize it. |
| 2022-01-31 00:59:07 +0100 | <EvanR> | also, what about standards |
| 2022-01-31 00:59:08 +0100 | alx741 | (~alx741@157.100.197.240) (Quit: alx741) |
| 2022-01-31 00:59:15 +0100 | <monochrom> | The same way I don't commit to more than "sorting takes O(n lg n)" because I can't be bothered to look at the exact hardware and calculate that it's exactly 45 n lg n + 3 n - 2 lg n microseconds. |
| 2022-01-31 00:59:40 +0100 | charukiewicz | (~charukiew@2600:1702:a90:2750:724d:7bff:fe2b:f560) (Remote host closed the connection) |
| 2022-01-31 00:59:53 +0100 | <monochrom> | Right there the unknown constant multiplier and the unknown lower order terms are exactly noise and error. |
| 2022-01-31 00:59:54 +0100 | <EvanR> | the standard doesn't really speak in terms of noise or random results |
| 2022-01-31 01:00:04 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-01-31 01:00:12 +0100 | <ephemient> | while most programming languages nowadays say they have IEEE 754 floats, CPU's FPUs can often be configured in different modes (rounding, nan handling, etc.) and GPUs frequently have non-IEEE 754 compliant floats (different precisions, etc.) |
| 2022-01-31 01:00:29 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-01-31 01:00:52 +0100 | charukiewicz | (~charukiew@2600:1702:a90:2750::3c) |
| 2022-01-31 01:00:53 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-01-31 01:01:35 +0100 | <cjay> | rounding modes are part of 754 |
| 2022-01-31 01:01:54 +0100 | <cjay> | they are only a problem if some library changes it an leaves it changed |
| 2022-01-31 01:02:18 +0100 | <ephemient> | right, I just bring it up because your calculation will be different depending on outside state |
| 2022-01-31 01:02:25 +0100 | <cjay> | true |
| 2022-01-31 01:02:39 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2022-01-31 01:02:53 +0100 | <EvanR> | in fact this situation is WORSE than being random with a known simple distribution xD |
| 2022-01-31 01:03:20 +0100 | <EvanR> | because if you assume this and then show someone real results they will think you're nuts, not random at all |
| 2022-01-31 01:03:29 +0100 | <EvanR> | unless you painstakingly come up with all the test run environments |
| 2022-01-31 01:04:01 +0100 | <EvanR> | which isn't how a particular application works |
| 2022-01-31 01:04:51 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 276 seconds) |
| 2022-01-31 01:05:00 +0100 | <EvanR> | so quantum computers would be an upgrade in another way xD |
| 2022-01-31 01:05:47 +0100 | <EvanR> | IEEE quantum floats |
| 2022-01-31 01:07:01 +0100 | <jackdk> | are there (m)any data types whose `Num` instance includes noncommutative `(*)`? Matrix multiplication is the obvious candidate, but maybe they're all on special operators like `(!*!)`. And are there any common classes that require commutative `(*)` in their laws? |
| 2022-01-31 01:07:45 +0100 | <EvanR> | @pl \x -> (x * 2) |
| 2022-01-31 01:07:45 +0100 | <lambdabot> | (2 *) |
| 2022-01-31 01:08:07 +0100 | <EvanR> | lambdabot proves it's commutative |
| 2022-01-31 01:08:46 +0100 | <EvanR> | (didn't think anything depended on Num having laws) |
| 2022-01-31 01:10:04 +0100 | <dolio> | Maybe you should stop insisting that the error terms have anything to do with repeatedly sampling from some kind of distribution. |
| 2022-01-31 01:10:43 +0100 | <ephemient> | quaternions are another "obvious" one |
| 2022-01-31 01:11:08 +0100 | <EvanR> | a = m + n, b = m + n, c = m + n, d = m + n, look, sampling xD But admittedly, not from any coherent distribution |
| 2022-01-31 01:11:46 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-01-31 01:13:23 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-01-31 01:13:41 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2022-01-31 01:14:14 +0100 | burnside_ | (~burnsides@dhcp168-016.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-31 01:14:17 +0100 | kilolympus | (~kilolympu@31.205.200.235) (Quit: Quitting IRC :() |
| 2022-01-31 01:14:34 +0100 | <EvanR> | (also I wasn't talking about error, but inconsistency, the fact that we are even thinking of this as sequential samples) |
| 2022-01-31 01:14:41 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) |
| 2022-01-31 01:15:25 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-31 01:19:06 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) (Ping timeout: 260 seconds) |
| 2022-01-31 01:20:02 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection) |
| 2022-01-31 01:20:14 +0100 | <jackdk> | ephemient: thanks, and more likely to rely on num operators e.g. https://hackage.haskell.org/package/linear-1.21.8/docs/src/Linear.Quaternion.html#line-243 |
| 2022-01-31 01:21:35 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) |
| 2022-01-31 01:23:42 +0100 | hololeap | (~hololeap@user/hololeap) (Ping timeout: 276 seconds) |
| 2022-01-31 01:23:48 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) |
| 2022-01-31 01:24:33 +0100 | <EvanR> | cool, instance Monad Quaternion -- the diagonal of a sedenion is super useful! |
| 2022-01-31 01:25:30 +0100 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 256 seconds) |
| 2022-01-31 01:30:29 +0100 | Codaraxis__ | (~Codaraxis@user/codaraxis) |
| 2022-01-31 01:34:00 +0100 | Codaraxis_ | (~Codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-01-31 01:35:28 +0100 | Topsi | (~Tobias@dyndsl-095-033-024-223.ewe-ip-backbone.de) |
| 2022-01-31 01:41:11 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-31 01:45:41 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-01-31 01:45:57 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) (Ping timeout: 240 seconds) |
| 2022-01-31 01:46:30 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-31 01:47:18 +0100 | Ved2311 | (~Ved2311@2600:1700:d840:2370:2c7f:af63:1c:7efc) (Quit: Client closed) |
| 2022-01-31 01:48:43 +0100 | Akiva | (~Akiva@user/Akiva) |
| 2022-01-31 01:53:17 +0100 | myme | (~myme@40.51-175-185.customer.lyse.net) (Ping timeout: 250 seconds) |
| 2022-01-31 01:59:14 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2022-01-31 01:59:26 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 02:02:37 +0100 | Null_A | (~null_a@2601:645:8700:2290:9dfb:d74f:b509:d274) |
| 2022-01-31 02:10:46 +0100 | lateef | (~lateef@2603-6080-6740-0538-845d-1912-a53c-bf82.res6.spectrum.com) |
| 2022-01-31 02:10:49 +0100 | alp | (~alp@user/alp) (Ping timeout: 250 seconds) |
| 2022-01-31 02:10:50 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-01-31 02:11:51 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-01-31 02:17:58 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-01-31 02:18:00 +0100 | nineonine | (~nineonine@S0106a0ff7073d5d5.vf.shawcable.net) (Remote host closed the connection) |
| 2022-01-31 02:19:04 +0100 | mud | (~mud@user/kadoban) |
| 2022-01-31 02:20:52 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-01-31 02:21:12 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Quit: WeeChat 3.4) |
| 2022-01-31 02:21:25 +0100 | texasmynsted_ | (~texasmyns@99.96.221.112) |
| 2022-01-31 02:22:20 +0100 | texasmynsted | (~texasmyns@99.96.221.112) (Ping timeout: 250 seconds) |
| 2022-01-31 02:23:19 +0100 | retroid_ | (~retro@2e40edd9.skybroadband.com) |
| 2022-01-31 02:23:37 +0100 | lateef | (~lateef@2603-6080-6740-0538-845d-1912-a53c-bf82.res6.spectrum.com) (Quit: lateef) |
| 2022-01-31 02:23:49 +0100 | mystilleef | (~mystillee@2603-6080-6740-0538-845d-1912-a53c-bf82.res6.spectrum.com) |
| 2022-01-31 02:28:15 +0100 | <dminuoso> | Mmm, when a conduit receives an exception, will that flush the conduit first? |
| 2022-01-31 02:28:29 +0100 | <dminuoso> | (Does the question even make sense?) |
| 2022-01-31 02:33:17 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 02:35:21 +0100 | Kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-01-31 02:36:46 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:2541:beac:9acd:61a8) (Remote host closed the connection) |
| 2022-01-31 02:36:54 +0100 | jao | (~jao@68.235.43.84) (Ping timeout: 256 seconds) |
| 2022-01-31 02:38:53 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-01-31 02:39:54 +0100 | texasmynsted | (~texasmyns@99.96.221.112) |
| 2022-01-31 02:40:37 +0100 | texasmynsted_ | (~texasmyns@99.96.221.112) (Ping timeout: 240 seconds) |
| 2022-01-31 02:40:52 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 02:42:24 +0100 | <jackdk> | doubt it |
| 2022-01-31 02:49:09 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-01-31 02:50:54 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) |
| 2022-01-31 02:53:35 +0100 | deadmarshal | (~deadmarsh@95.38.231.75) |
| 2022-01-31 02:57:34 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-01-31 02:57:37 +0100 | deadmarshal | (~deadmarsh@95.38.231.75) (Ping timeout: 240 seconds) |
| 2022-01-31 02:57:39 +0100 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 256 seconds) |
| 2022-01-31 03:00:50 +0100 | vicfred | (~vicfred@user/vicfred) |
| 2022-01-31 03:07:59 +0100 | texasmynsted_ | (~texasmyns@99.96.221.112) |
| 2022-01-31 03:09:08 +0100 | texasmynsted | (~texasmyns@99.96.221.112) (Ping timeout: 250 seconds) |
| 2022-01-31 03:15:17 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-01-31 03:17:26 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-01-31 03:17:32 +0100 | mystilleef | (~mystillee@2603-6080-6740-0538-845d-1912-a53c-bf82.res6.spectrum.com) (Quit: mystilleef) |
| 2022-01-31 03:18:34 +0100 | neurocyte0917090 | (~neurocyte@user/neurocyte) (Ping timeout: 260 seconds) |
| 2022-01-31 03:24:51 +0100 | califax- | (~califax@user/califx) |
| 2022-01-31 03:27:12 +0100 | califax | (~califax@user/califx) (Ping timeout: 276 seconds) |
| 2022-01-31 03:27:12 +0100 | califax- | califax |
| 2022-01-31 03:29:43 +0100 | kilolympus | (~kilolympu@31.205.200.235) |
| 2022-01-31 03:31:14 +0100 | jkaye[m] | (~jkayematr@2001:470:69fc:105::1:86f7) |
| 2022-01-31 03:31:25 +0100 | xff0x | (~xff0x@2001:1a81:52f3:1d00:e2c8:a45c:f0af:d33) (Ping timeout: 250 seconds) |
| 2022-01-31 03:32:51 +0100 | Null_A | (~null_a@2601:645:8700:2290:9dfb:d74f:b509:d274) (Read error: Connection reset by peer) |
| 2022-01-31 03:33:16 +0100 | xff0x | (~xff0x@2001:1a81:5330:2600:3a82:23bb:1178:cc83) |
| 2022-01-31 03:37:15 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 03:39:05 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00::518) |
| 2022-01-31 03:40:30 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Remote host closed the connection) |
| 2022-01-31 03:40:45 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-01-31 03:46:07 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 03:51:08 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 256 seconds) |
| 2022-01-31 03:53:54 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2022-01-31 03:58:03 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) (Remote host closed the connection) |
| 2022-01-31 04:01:18 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-01-31 04:03:01 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-01-31 04:03:57 +0100 | lemonsnicks | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-01-31 04:08:29 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-01-31 04:10:50 +0100 | alx741 | (~alx741@157.100.197.240) (Quit: alx741) |
| 2022-01-31 04:13:27 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-01-31 04:16:20 +0100 | lemonsnicks | (~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) |
| 2022-01-31 04:16:26 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 04:16:26 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 04:16:26 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 04:19:02 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.4) |
| 2022-01-31 04:20:48 +0100 | trillp | (~trillp@2001:19f0:6401:72e:c092:4829:25d6:b788) |
| 2022-01-31 04:20:57 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-01-31 04:23:06 +0100 | burnsidesLlama | (~burnsides@dhcp168-016.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-31 04:34:32 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) (Remote host closed the connection) |
| 2022-01-31 04:35:04 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 04:38:07 +0100 | mbuf | (~Shakthi@136.185.77.246) |
| 2022-01-31 04:40:49 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-31 04:43:16 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Quit: Leaving) |
| 2022-01-31 04:44:40 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-01-31 04:46:40 +0100 | td_ | (~td@muedsl-82-207-238-178.citykom.de) (Ping timeout: 256 seconds) |
| 2022-01-31 04:48:17 +0100 | td_ | (~td@muedsl-82-207-238-222.citykom.de) |
| 2022-01-31 04:49:30 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 04:49:42 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Quit: This computer has gone to sleep) |
| 2022-01-31 04:53:24 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) |
| 2022-01-31 05:01:21 +0100 | euphrates[m] | (~euphrates@2001:470:69fc:105::fbb5) |
| 2022-01-31 05:03:58 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 250 seconds) |
| 2022-01-31 05:12:17 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00::518) (Read error: Connection reset by peer) |
| 2022-01-31 05:12:35 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00::518) |
| 2022-01-31 05:21:34 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00::518) (Remote host closed the connection) |
| 2022-01-31 05:21:52 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00:f6a1:f8c9:ad86:473d) |
| 2022-01-31 05:26:26 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-01-31 05:42:08 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 05:42:08 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 05:42:08 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 05:42:17 +0100 | foul_owl | (~kerry@174-21-143-101.tukw.qwest.net) (Ping timeout: 250 seconds) |
| 2022-01-31 05:43:16 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 245 seconds) |
| 2022-01-31 05:48:33 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-31 05:53:19 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-01-31 05:53:57 +0100 | kimjetwav | (~user@2607:fea8:2363:8f00:f6a1:f8c9:ad86:473d) (Ping timeout: 240 seconds) |
| 2022-01-31 05:54:08 +0100 | qrpnxz | (abc4f95c31@user/qrpnxz) |
| 2022-01-31 05:54:29 +0100 | qrpnxz | (abc4f95c31@user/qrpnxz) () |
| 2022-01-31 05:54:51 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 05:55:50 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-01-31 05:56:13 +0100 | foul_owl | (~kerry@94.140.8.108) |
| 2022-01-31 06:02:02 +0100 | foul_owl | (~kerry@94.140.8.108) (Ping timeout: 256 seconds) |
| 2022-01-31 06:02:39 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-01-31 06:03:48 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 06:03:48 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 06:03:48 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 06:06:08 +0100 | robosexual | (~spaceoyst@92.248.225.230) |
| 2022-01-31 06:07:09 +0100 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-01-31 06:07:57 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-01-31 06:12:52 +0100 | swistak | (~swistak@185.21.216.141) (Ping timeout: 250 seconds) |
| 2022-01-31 06:12:58 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) (Disconnected: Replaced by new connection) |
| 2022-01-31 06:13:13 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 06:13:30 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) () |
| 2022-01-31 06:13:53 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 06:14:19 +0100 | Topsi | (~Tobias@dyndsl-095-033-024-223.ewe-ip-backbone.de) (Read error: Connection reset by peer) |
| 2022-01-31 06:15:58 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) () |
| 2022-01-31 06:16:13 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 06:16:14 +0100 | foul_owl | (~kerry@94.140.8.107) |
| 2022-01-31 06:16:29 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) () |
| 2022-01-31 06:16:58 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 06:17:28 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) (Remote host closed the connection) |
| 2022-01-31 06:24:42 +0100 | cjb | (~cjb@user/cjb) (Quit: rcirc on GNU Emacs 29.0.50) |
| 2022-01-31 06:28:25 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) |
| 2022-01-31 06:31:47 +0100 | deadmarshal | (~deadmarsh@95.38.114.109) |
| 2022-01-31 06:34:07 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 06:34:56 +0100 | swistak | (~swistak@185.21.216.141) |
| 2022-01-31 06:36:13 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 06:38:56 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) (Remote host closed the connection) |
| 2022-01-31 06:39:00 +0100 | freemanX | (~user@138.75.106.242) |
| 2022-01-31 06:39:45 +0100 | andreabedini | (~andreabed@8s8kj6n5jr0p8rp4lths.ip6.superloop.com) |
| 2022-01-31 06:42:02 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 260 seconds) |
| 2022-01-31 06:48:01 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) |
| 2022-01-31 06:48:54 +0100 | <fvr> | what does `qAddDependentFile` do? https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH-Syntax.html… |
| 2022-01-31 06:51:10 +0100 | <andreabedini> | fvr: I guess the description of addDependentFile is more informative https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH-Syntax.html… |
| 2022-01-31 06:52:01 +0100 | <fvr> | that's informative, thanks! |
| 2022-01-31 06:56:19 +0100 | freemanX | (~user@138.75.106.242) (Remote host closed the connection) |
| 2022-01-31 06:57:03 +0100 | doxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 250 seconds) |
| 2022-01-31 06:57:32 +0100 | rusrushal13 | (~rusrushal@2401:4900:447c:7aab:9569:ad9c:2bdf:6f6e) |
| 2022-01-31 07:01:34 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-01-31 07:05:44 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 07:10:30 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2022-01-31 07:16:29 +0100 | cynomys | (~cynomys@user/cynomys) |
| 2022-01-31 07:18:58 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) |
| 2022-01-31 07:31:22 +0100 | rusrushal13 | (~rusrushal@2401:4900:447c:7aab:9569:ad9c:2bdf:6f6e) (Ping timeout: 256 seconds) |
| 2022-01-31 07:33:30 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-01-31 07:34:45 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 07:37:20 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 07:42:54 +0100 | jao | (~jao@static-68-235-44-71.cust.tzulo.com) (Ping timeout: 256 seconds) |
| 2022-01-31 07:43:14 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-31 07:44:21 +0100 | zeenk | (~zeenk@2a02:2f04:a204:7c00:d1e7:19c4:1020:b94b) |
| 2022-01-31 07:49:54 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-01-31 07:50:22 +0100 | robosexual | (~spaceoyst@92.248.225.230) (Quit: Konversation terminated!) |
| 2022-01-31 07:50:41 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Remote host closed the connection) |
| 2022-01-31 07:51:24 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 07:53:32 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 07:53:39 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 07:53:49 +0100 | zeenk2 | (~zeenk@2a02:2f04:a104:3700:5a8:957d:2155:a792) |
| 2022-01-31 07:54:01 +0100 | zeenk | (~zeenk@2a02:2f04:a204:7c00:d1e7:19c4:1020:b94b) (Ping timeout: 250 seconds) |
| 2022-01-31 07:54:23 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-01-31 07:57:16 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-01-31 07:57:53 +0100 | michalz | (~michalz@185.246.204.57) |
| 2022-01-31 07:58:16 +0100 | falafel | (~falafel@2603-8000-8403-e980-a564-89bf-cc0b-6efb.res6.spectrum.com) |
| 2022-01-31 07:58:23 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-01-31 07:58:33 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 08:02:16 +0100 | ensyde | (~ensyde@2600:1700:2050:1040:dde2:c55f:f2c9:43fc) |
| 2022-01-31 08:05:08 +0100 | trillp | (~trillp@2001:19f0:6401:72e:c092:4829:25d6:b788) (WeeChat 3.4) |
| 2022-01-31 08:12:39 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2022-01-31 08:15:15 +0100 | zeenk2 | (~zeenk@2a02:2f04:a104:3700:5a8:957d:2155:a792) (Ping timeout: 250 seconds) |
| 2022-01-31 08:16:07 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-01-31 08:17:01 +0100 | zeenk2 | (~zeenk@82-77-96-125.cable-modem.hdsnet.hu) |
| 2022-01-31 08:17:56 +0100 | zeenk2 | (~zeenk@82-77-96-125.cable-modem.hdsnet.hu) (Client Quit) |
| 2022-01-31 08:19:16 +0100 | dut | (~dut@user/dut) |
| 2022-01-31 08:19:52 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-01-31 08:28:33 +0100 | <Cheery> | haskell's type inference is not quite standard and deals with kinded variables, but does it have a name? |
| 2022-01-31 08:28:49 +0100 | <Cheery> | it's quite not higher-order unification, right? lambdas are missing. |
| 2022-01-31 08:29:57 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-01-31 08:31:35 +0100 | vysn | (~vysn@user/vysn) |
| 2022-01-31 08:32:26 +0100 | <Andrew> | So I've got something like a string "1 2 3 4", and I want to convert it to a list [Integer] [1, 2, 3, 4]... How do I do that? |
| 2022-01-31 08:32:59 +0100 | <jackdk> | What are some subproblems that you could solve to achieve this goal? |
| 2022-01-31 08:33:47 +0100 | <Andrew> | Hmm, splitting a string by spaces, and converting e.g. "1" to 1 |
| 2022-01-31 08:34:18 +0100 | <jackdk> | Sounds like I good start. I know that "splitting a string by spaces" has a function in the Prelude to do that |
| 2022-01-31 08:34:43 +0100 | <[exa]> | Cheery: it's a variant of system Fω, there's a pretty nice paper on it (I think the current pop name for the algorithm is OutsideIn) |
| 2022-01-31 08:34:46 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-01-31 08:35:15 +0100 | <Andrew> | heh, emerge doesn't want to install cabal for me lol |
| 2022-01-31 08:35:28 +0100 | <Andrew> | I'll go with prelude first... |
| 2022-01-31 08:35:35 +0100 | <dolio> | Cheery: It's not even close to higher-order unification. It's really not significantly different han what you'd do for HM. |
| 2022-01-31 08:35:53 +0100 | <Andrew> | "words" does the trick |
| 2022-01-31 08:35:57 +0100 | <jackdk> | I would use ghcup if at all possible. I don't know the state of haskell packaging on Gentoo |
| 2022-01-31 08:36:24 +0100 | <dolio> | The higher order variables can only be solved to partial-applications of higher-order constants, basically. |
| 2022-01-31 08:36:50 +0100 | <jackdk> | Andrew: yep. so now to turn the `[String] -> [Int]`. Where are you at with your Haskell learning? Are you still learning direct recursion, or are you comfortable with higher-order functions? |
| 2022-01-31 08:37:06 +0100 | <Andrew> | I'm comfortable with higher-order |
| 2022-01-31 08:37:37 +0100 | <[exa]> | Cheery: also SPJ has a pretty nice talk from zurihac somewhere on youtube (it's unfortunately clipped at the end but delivers the message) |
| 2022-01-31 08:37:41 +0100 | <Andrew> | I just need a function or whatever to turn a string into an integer |
| 2022-01-31 08:37:54 +0100 | Andrew | is okay with 'map' |
| 2022-01-31 08:38:05 +0100 | <jackdk> | yeah map is the way here |
| 2022-01-31 08:38:45 +0100 | <jackdk> | for now, `read :: Read a => String -> a` will do, but that can fail at runtime |
| 2022-01-31 08:39:00 +0100 | <dolio> | Or, replace HM with whatever strategy you want for the first-order case. |
| 2022-01-31 08:39:22 +0100 | <jackdk> | to do this for reals, I would use `Text.Read.readMaybe :: Read a => String -> Maybe a` |
| 2022-01-31 08:39:31 +0100 | <jackdk> | have you done typeclasses yet? |
| 2022-01-31 08:39:38 +0100 | <Andrew> | Typeclasses, yes |
| 2022-01-31 08:39:56 +0100 | <Andrew> | But I'm not that comfortable with Monads e.g. Maybe |
| 2022-01-31 08:40:22 +0100 | <Andrew> | It's to the point where I could understand it if people gave me example code (and I have the docs to the side) |
| 2022-01-31 08:40:48 +0100 | <jackdk> | sure, so let's get it working at all, first. Have you got something going with `map`, `read`, and `words`? |
| 2022-01-31 08:41:29 +0100 | <Andrew> | I waasn't careful with the typesig of read, that seems to be it |
| 2022-01-31 08:41:31 +0100 | <Andrew> | Thanks :) |
| 2022-01-31 08:42:43 +0100 | <jackdk> | no problem. if you want to try building a safer version, ignore the fact that Maybe has a Monad instance for now and just treat it as a data type. try to write a function `foo :: [Maybe a] -> Maybe [a]` |
| 2022-01-31 08:43:13 +0100 | andreabedini | (~andreabed@8s8kj6n5jr0p8rp4lths.ip6.superloop.com) (Quit: WeeChat 3.3) |
| 2022-01-31 08:46:17 +0100 | <Cheery> | so if I type inference in ukanren that has prolog-style terms, I could imitate this with tap(caller, arg) |
| 2022-01-31 08:46:33 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-01-31 08:46:38 +0100 | <Cheery> | tap(list, int) |
| 2022-01-31 08:48:55 +0100 | <Cheery> | but kinds should match, too. |
| 2022-01-31 08:49:46 +0100 | <Cheery> | I have a hunch that it can be done, though. |
| 2022-01-31 08:51:27 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-01-31 08:52:57 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 250 seconds) |
| 2022-01-31 08:53:06 +0100 | <Cheery> | tap(caller, arg), kind(tap(caller, arg), star).. then treat kind as a chr constraint. |
| 2022-01-31 08:53:56 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:e245:b598:3bd:262a) |
| 2022-01-31 08:54:03 +0100 | <dolio> | I don't know if I understand the question. If it's just whether you can do Haskell's inference with normal unification, then the answer is yes. |
| 2022-01-31 08:54:40 +0100 | <dolio> | And yeah, you need to do some kind checking to make sure your unifications of types don't go wrong. |
| 2022-01-31 08:55:21 +0100 | <dolio> | You don't need something like lambda prolog or whatever. |
| 2022-01-31 08:56:03 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-01-31 08:56:18 +0100 | <oscurochu> | is it true that haskell code does not need to be tested? |
| 2022-01-31 08:56:32 +0100 | <jackdk> | not at all |
| 2022-01-31 08:57:32 +0100 | <jackdk> | a large class of tests -- those that check argument and return types -- don't need to be written, but you still need to write tests. |
| 2022-01-31 08:57:32 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-01-31 08:57:39 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-31 08:58:11 +0100 | alp | (~alp@user/alp) |
| 2022-01-31 08:58:41 +0100 | <dolio> | Cheery: The spots where you actually need to do kind checking are usually pretty limited, though. Usually you wouldn't end up in a sitaution where a unification of types can be ill-kinded unless it's from something a programmer wrote. |
| 2022-01-31 08:58:46 +0100 | <Cheery> | kind(tap(F, A), B) <=> kind(F, TA → TB), kind(A, TA), kind(B, TB) |
| 2022-01-31 08:58:59 +0100 | <Cheery> | ok. |
| 2022-01-31 08:59:14 +0100 | <ski> | > case [ns | (ns,s) <- many (StateT (reads :: ReadS Integer)) `runStateT` "0 1 2 3",("","") <- lex s] of [ns] -> Just ns; _ -> Nothing -- Andrew ? |
| 2022-01-31 08:59:15 +0100 | <lambdabot> | Just [0,1,2,3] |
| 2022-01-31 09:00:18 +0100 | <oscurochu> | jackdk i just started learning how to write tests in javascript and clojure, and still don't 100% understand testing. how do i learn more about testing in haskell? |
| 2022-01-31 09:00:21 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) |
| 2022-01-31 09:00:38 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) |
| 2022-01-31 09:00:38 +0100 | <Cheery> | kind(F, X), kind(F, Y) <=> X != Y | false. |
| 2022-01-31 09:01:11 +0100 | <Cheery> | so.. I could probably get this done that way. |
| 2022-01-31 09:01:34 +0100 | max22- | (~maxime@2a01cb08833598005d2ea791b13aed90.ipv6.abo.wanadoo.fr) |
| 2022-01-31 09:01:55 +0100 | <jackdk> | oscurochu: unit testing is often the same as any other language: factor out your functions into smaller parts. pure functions are easier to test. Think about what the outputs should be for a given input, and write test cases that ensure it's actually the case. I like the tasty library, with tasty-hunit for writing unit tests |
| 2022-01-31 09:02:17 +0100 | <ski> | also, property testing |
| 2022-01-31 09:02:51 +0100 | <jackdk> | @check \x y -> x + y == y + x |
| 2022-01-31 09:02:52 +0100 | <lambdabot> | +++ OK, passed 100 tests. |
| 2022-01-31 09:03:20 +0100 | <ski> | @check \x y -> x == y |
| 2022-01-31 09:03:21 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:e245:b598:3bd:262a) (Ping timeout: 250 seconds) |
| 2022-01-31 09:03:22 +0100 | <lambdabot> | +++ OK, passed 100 tests. |
| 2022-01-31 09:03:33 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-01-31 09:03:39 +0100 | <jackdk> | I don't have a good intro for that handy, but yes definitely important. https://www.youtube.com/watch?v=NcJOiQlzlXQ maybe? |
| 2022-01-31 09:03:58 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:d2eb:19ab:f134:7a9c) |
| 2022-01-31 09:04:55 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) |
| 2022-01-31 09:05:00 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-01-31 09:05:25 +0100 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 256 seconds) |
| 2022-01-31 09:06:07 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2022-01-31 09:06:19 +0100 | ski | . o O ( "Don't Write Tests!" by John Hughes in 2017-06 at <https://www.youtube.com/watch?v=hXnS_Xjwk2Y> ) |
| 2022-01-31 09:06:57 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-01-31 09:08:34 +0100 | <Cheery> | hm. I got that one rule wrong. |
| 2022-01-31 09:08:42 +0100 | <Cheery> | kind(tap(F, A), TB) <=> kind(F, TA → TB), kind(A, TA). |
| 2022-01-31 09:11:03 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 276 seconds) |
| 2022-01-31 09:11:53 +0100 | <oscurochu> | what about tests that the output depends on the output of another function? i just started learning about haskell, so forgive my javascript-like syntax; func1 (x, func2) = func3(x, func2); |
| 2022-01-31 09:12:26 +0100 | prasad | (~user@c-73-170-49-136.hsd1.ca.comcast.net) (Ping timeout: 256 seconds) |
| 2022-01-31 09:13:47 +0100 | chele | (~chele@user/chele) |
| 2022-01-31 09:14:25 +0100 | <ski> | Cheery : .. i was thinking it looked like a type error |
| 2022-01-31 09:14:39 +0100 | <EvanR> | oscurochu, so func1 = func3 ? xD |
| 2022-01-31 09:15:03 +0100 | <EvanR> | I simplified your function |
| 2022-01-31 09:15:16 +0100 | <oscurochu> | lol let me find the actual example i had in mind, i wrote it down wrong. |
| 2022-01-31 09:15:20 +0100 | <ski> | presumably `func2' isn't universally quantified |
| 2022-01-31 09:15:56 +0100 | ardell | (~ardell@user/ardell) |
| 2022-01-31 09:16:29 +0100 | o | niko |
| 2022-01-31 09:17:50 +0100 | <oscurochu> | Func1 ( req, res ) = Func2(Func3, req.userId ); |
| 2022-01-31 09:18:32 +0100 | <ski> | `res' is singleton ? |
| 2022-01-31 09:18:48 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-01-31 09:19:46 +0100 | <oscurochu> | ( req, res ) are the arguments give by the expressjs router. not sure how that would work in haskell. |
| 2022-01-31 09:20:24 +0100 | <ski> | i mean, it seems a bit weird that `res' is only mentioned once |
| 2022-01-31 09:20:27 +0100 | <EvanR> | so you want to test a request handler |
| 2022-01-31 09:20:39 +0100 | <EvanR> | which means you'll need some test requests to handle |
| 2022-01-31 09:21:27 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 09:21:44 +0100 | <oscurochu> | but what if func3 also calls func4 and func4 calls func5, etc. |
| 2022-01-31 09:21:55 +0100 | <EvanR> | what if they do |
| 2022-01-31 09:22:08 +0100 | <EvanR> | you'll be doing a "end to end" test basically |
| 2022-01-31 09:22:13 +0100 | alp | (~alp@user/alp) (Ping timeout: 250 seconds) |
| 2022-01-31 09:22:13 +0100 | <EvanR> | which some people swear by |
| 2022-01-31 09:22:20 +0100 | <oscurochu> | true |
| 2022-01-31 09:24:18 +0100 | <oscurochu> | so im thinking that the idea of testing would be to start at the purest function, so that by the time i test a function like this, i should expect it to pass? |
| 2022-01-31 09:24:31 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) (Ping timeout: 245 seconds) |
| 2022-01-31 09:25:46 +0100 | ensyde | (~ensyde@2600:1700:2050:1040:dde2:c55f:f2c9:43fc) (Ping timeout: 245 seconds) |
| 2022-01-31 09:25:48 +0100 | <EvanR> | when you have working function f1 and working function f2, there's no guarantee putting them together works |
| 2022-01-31 09:25:57 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-01-31 09:26:10 +0100 | <EvanR> | if it does, presumably your test passes |
| 2022-01-31 09:26:19 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) |
| 2022-01-31 09:27:15 +0100 | <EvanR> | but making sure your pure functions are right is a huge step toward a working system |
| 2022-01-31 09:27:19 +0100 | <ski> | oscurochu : bottom-up ? |
| 2022-01-31 09:30:33 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-01-31 09:30:43 +0100 | charukiewicz | (~charukiew@2600:1702:a90:2750::3c) () |
| 2022-01-31 09:31:18 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 09:32:12 +0100 | <oscurochu> | Ok that makes sense. Thanks. That has already made a difference in how I see this code I wrote. I had a bunch of code that was largely untestable, and it feels really good to finally get to the point im at. Learing haskell has helped me see code i've written in new ways |
| 2022-01-31 09:32:28 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-01-31 09:32:54 +0100 | tom_ | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) |
| 2022-01-31 09:33:32 +0100 | fendor | (~fendor@178.165.174.170.wireless.dyn.drei.com) |
| 2022-01-31 09:34:10 +0100 | jiribenes | (~jiribenes@rosa.jiribenes.com) |
| 2022-01-31 09:34:13 +0100 | choucavalier_ | (~choucaval@peanutbuttervibes.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:13 +0100 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:13 +0100 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:13 +0100 | wallymathieu | (sid533252@id-533252.uxbridge.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:19 +0100 | Jon | (jon@dow.land) (Quit: ZNC - http://znc.in) |
| 2022-01-31 09:34:29 +0100 | terrorjack5 | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-01-31 09:34:50 +0100 | kaskal | (~kaskal@2001:4bb8:2cc:5073:e1cf:a3ef:264a:1e80) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:50 +0100 | lechner | (~lechner@debian/lechner) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:50 +0100 | jiribenes_ | (~jiribenes@rosa.jiribenes.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:34:52 +0100 | choucavalier | (~choucaval@peanutbuttervibes.com) |
| 2022-01-31 09:35:07 +0100 | kaskal | (~kaskal@2001:4bb8:2cc:5073:e1cf:a3ef:264a:1e80) |
| 2022-01-31 09:35:27 +0100 | xbreu | (~xbreu@2001:470:69fc:105::1:5061) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:27 +0100 | denbrahe | (~denbrahe@2001:470:69fc:105::19c0) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:27 +0100 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:27 +0100 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:27 +0100 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:28 +0100 | Yehoshua | (~yehoshua@2001:470:69fc:105::1:593f) (Ping timeout: 268 seconds) |
| 2022-01-31 09:35:28 +0100 | kristjansson | (sid126207@id-126207.tinside.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:02 +0100 | robertm | (robertm@lattice.rojoma.com) (Ping timeout: 240 seconds) |
| 2022-01-31 09:36:04 +0100 | zwro[m] | (~zwromatri@2001:470:69fc:105::1d4) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | quantum | (~quantum@user/quantum/x-8556232) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | alex[m]1234567 | (~alexchete@2001:470:69fc:105::1:1001) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | acidsys | (~LSD@2.lsd.systems) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | tom__ | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | ddb | (~ddb@ipv6two.tilde.club) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | lieven | (~mal@ns2.wyrd.be) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | davetapley | (sid666@id-666.uxbridge.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | dexterfoo | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | jocke-l | (jocke-l@a.x0.is) (Ping timeout: 268 seconds) |
| 2022-01-31 09:36:04 +0100 | terrorjack5 | terrorjack |
| 2022-01-31 09:36:19 +0100 | dut_ | (~dut@user/dut) |
| 2022-01-31 09:36:20 +0100 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) |
| 2022-01-31 09:37:23 +0100 | lieven | (~mal@ns2.wyrd.be) |
| 2022-01-31 09:37:27 +0100 | dexterfoo | (~dexter@li655-253.members.linode.com) |
| 2022-01-31 09:37:42 +0100 | kuribas | (~user@ptr-25vy0i9mijo6rhu39yx.18120a2.ip6.access.telenet.be) |
| 2022-01-31 09:37:42 +0100 | ddb | (~ddb@ipv6two.tilde.club) |
| 2022-01-31 09:37:51 +0100 | kristjansson | (sid126207@id-126207.tinside.irccloud.com) |
| 2022-01-31 09:38:00 +0100 | davetapley | (sid666@id-666.uxbridge.irccloud.com) |
| 2022-01-31 09:38:06 +0100 | lechner | (~lechner@debian/lechner) |
| 2022-01-31 09:38:14 +0100 | eggplant_ | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 09:39:25 +0100 | dut | (~dut@user/dut) (Ping timeout: 256 seconds) |
| 2022-01-31 09:40:33 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-01-31 09:43:22 +0100 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-01-31 09:46:59 +0100 | <oscurochu> | So haskell has web frameworks. Im kind of overwhelmed by the number of them. I just want to know how mutations work in a language thats immutable |
| 2022-01-31 09:47:18 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) (Quit: The BNC has broken!) |
| 2022-01-31 09:47:23 +0100 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) |
| 2022-01-31 09:47:38 +0100 | robertm | (~robertm@lattice.rojoma.com) |
| 2022-01-31 09:47:50 +0100 | xbreu | (~xbreu@2001:470:69fc:105::1:5061) |
| 2022-01-31 09:48:16 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-01-31 09:48:20 +0100 | jocke-l | (jocke-l@a.x0.is) |
| 2022-01-31 09:48:32 +0100 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Ping timeout: 240 seconds) |
| 2022-01-31 09:48:45 +0100 | <dminuoso> | oscurochu: Okay, so the immutability has to be understood in context |
| 2022-01-31 09:48:51 +0100 | <dminuoso> | It's not that we dont have mutations. |
| 2022-01-31 09:48:58 +0100 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) |
| 2022-01-31 09:48:58 +0100 | wallymathieu | (sid533252@id-533252.uxbridge.irccloud.com) |
| 2022-01-31 09:49:01 +0100 | <dminuoso> | We have a lot of different mutation tools, including those available to other languages |
| 2022-01-31 09:49:09 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-01-31 09:49:09 +0100 | Flow | (~none@gentoo/developer/flow) |
| 2022-01-31 09:49:10 +0100 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Ping timeout: 260 seconds) |
| 2022-01-31 09:49:20 +0100 | <dminuoso> | We can manipulate memory directly, we can have traditional "variables" (lets better call them mutable stores) that you can simply manipulate in a loop... |
| 2022-01-31 09:49:41 +0100 | <dminuoso> | It's just that the grammatical *expressions* themselves cant cause mutation |
| 2022-01-31 09:49:51 +0100 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2022-01-31 09:49:56 +0100 | <dminuoso> | That is, the act of *evaluating* an expression <expr> cant (usually) cause mutation |
| 2022-01-31 09:50:14 +0100 | denbrahe | (~denbrahe@2001:470:69fc:105::19c0) |
| 2022-01-31 09:50:25 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-31 09:50:26 +0100 | alex[m]1234567 | (~alexchete@2001:470:69fc:105::1:1001) |
| 2022-01-31 09:50:36 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) |
| 2022-01-31 09:50:37 +0100 | sayola | (~vekto@dslb-088-064-186-153.088.064.pools.vodafone-ip.de) (Ping timeout: 240 seconds) |
| 2022-01-31 09:50:41 +0100 | Yehoshua | (~yehoshua@2001:470:69fc:105::1:593f) |
| 2022-01-31 09:50:44 +0100 | sm1 | (~sm@plaintextaccounting/sm) |
| 2022-01-31 09:50:45 +0100 | <dminuoso> | A rough intuition to help guide you here, is that if we think of `IO A` as a list of assembly instructions which, if executed, could carry out some arbitrary things. Those assembly instructions themselves are free to do whatever, including manipulating memory or mutable stores. |
| 2022-01-31 09:50:52 +0100 | <dminuoso> | But evaluating that list of assembly instructions may not. |
| 2022-01-31 09:51:20 +0100 | <oscurochu> | that makes sense |
| 2022-01-31 09:51:21 +0100 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) |
| 2022-01-31 09:51:35 +0100 | zwro[m] | (~zwromatri@2001:470:69fc:105::1d4) |
| 2022-01-31 09:51:58 +0100 | quantum | (~quantum@user/quantum/x-8556232) |
| 2022-01-31 09:52:37 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) (Ping timeout: 240 seconds) |
| 2022-01-31 09:53:06 +0100 | acidsys | (~LSD@2.lsd.systems) |
| 2022-01-31 09:53:18 +0100 | <dminuoso> | oscurochu: In addition, we even have a special environment, in which we can carry out mutations *inside* the evaluation of pure code. |
| 2022-01-31 09:53:29 +0100 | <dminuoso> | But its limited in such a way, that these manipulations remain hidden outside, so you cant leak this state. |
| 2022-01-31 09:53:45 +0100 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Remote host closed the connection) |
| 2022-01-31 09:54:10 +0100 | <dminuoso> | This is called ST, and it enables us to say implementing a sort algorithm say like quicksort - which requires in-place mutation to remain efficient - but use it in otherwise pure code. |
| 2022-01-31 09:54:16 +0100 | <dminuoso> | % :t runST |
| 2022-01-31 09:54:16 +0100 | <yahb> | dminuoso: (forall s. ST s a) -> a |
| 2022-01-31 09:54:33 +0100 | ski | . o O ( STM ) |
| 2022-01-31 09:54:56 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-01-31 09:55:15 +0100 | <dminuoso> | So that way we have the benefit of both worlds, writing pure code while using localized mutations that cannot possibly leak out to write highly efficient algorithms. |
| 2022-01-31 09:55:17 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) (Ping timeout: 256 seconds) |
| 2022-01-31 09:55:26 +0100 | <dminuoso> | While preventing observable mutations |
| 2022-01-31 09:55:38 +0100 | <dminuoso> | inside that pure code. |
| 2022-01-31 09:56:05 +0100 | <ephemient> | if you go back to pre-monadic-IO Haskell, main was a pure function that returned a list of IO actions that the runtime should execute, with the results of those actions being fed back into main as input - and with laziness, it all worked out. monadic IO wraps that up into something that is easier to work with |
| 2022-01-31 09:56:25 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) |
| 2022-01-31 09:56:31 +0100 | <dminuoso> | ski: Yeah, I pondered mentioning it. :) |
| 2022-01-31 09:56:33 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 09:57:00 +0100 | mrmonday | (~robert@octarineparrot.com) |
| 2022-01-31 09:58:04 +0100 | <kuribas> | ah, records parameterised by higher kinded variables works just fine in idris :) |
| 2022-01-31 09:58:29 +0100 | <kuribas> | Maybe I should move on from this low level language callled haskell ... |
| 2022-01-31 09:59:40 +0100 | <kuribas> | https://gist.github.com/kuribas/c4d7fd7ce7ef963f7c02a266828095f3 |
| 2022-01-31 10:00:27 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-01-31 10:01:31 +0100 | yauhsien | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 10:01:52 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) |
| 2022-01-31 10:01:59 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) (Changing host) |
| 2022-01-31 10:01:59 +0100 | flipchan | (~filip@user/flipchan) |
| 2022-01-31 10:14:17 +0100 | chomwitt | (~chomwitt@2a02:587:dc03:8900:12c3:7bff:fe6d:d374) |
| 2022-01-31 10:17:21 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-01-31 10:17:35 +0100 | cstml | (~cstml@user/cstml) |
| 2022-01-31 10:17:39 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-31 10:17:57 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-01-31 10:20:21 +0100 | falafel | (~falafel@2603-8000-8403-e980-a564-89bf-cc0b-6efb.res6.spectrum.com) (Read error: Connection reset by peer) |
| 2022-01-31 10:22:58 +0100 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-01-31 10:23:48 +0100 | Jon | (jon@dow.land) |
| 2022-01-31 10:24:20 +0100 | jgeerds_ | (~jgeerds@55d4a547.access.ecotel.net) |
| 2022-01-31 10:24:46 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Read error: Connection reset by peer) |
| 2022-01-31 10:25:04 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-01-31 10:25:14 +0100 | phma__ | (~phma@2001:5b0:211f:83e8:ceab:d757:d3e2:cd8f) |
| 2022-01-31 10:26:45 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) |
| 2022-01-31 10:28:22 +0100 | Adeon | (sid418992@id-418992.lymington.irccloud.com) (Ping timeout: 260 seconds) |
| 2022-01-31 10:28:39 +0100 | Jon | (jon@dow.land) (Quit: ZNC - http://znc.in) |
| 2022-01-31 10:28:50 +0100 | phma | (phma@2001:5b0:211f:83e8:ceab:d757:d3e2:cd8f) (Ping timeout: 260 seconds) |
| 2022-01-31 10:29:19 +0100 | phma__ | phma |
| 2022-01-31 10:29:58 +0100 | Adeon | (sid418992@id-418992.lymington.irccloud.com) |
| 2022-01-31 10:33:15 +0100 | alp | (~alp@user/alp) |
| 2022-01-31 10:33:52 +0100 | phma_ | (phma@2001:5b0:211f:83e8:ceab:d757:d3e2:cd8f) |
| 2022-01-31 10:34:38 +0100 | Jon | (jon@dow.land) |
| 2022-01-31 10:35:14 +0100 | sa | (sid1055@id-1055.tinside.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:35:21 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:9145:1668:6954:3d71) (Remote host closed the connection) |
| 2022-01-31 10:35:31 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-01-31 10:36:04 +0100 | sa | (sid1055@id-1055.tinside.irccloud.com) |
| 2022-01-31 10:36:05 +0100 | agander_m | (sid407952@id-407952.tinside.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:37:23 +0100 | cln | (sid336875@id-336875.ilkley.irccloud.com) (Ping timeout: 252 seconds) |
| 2022-01-31 10:37:23 +0100 | ephemient | (uid407513@id-407513.lymington.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:37:23 +0100 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:37:26 +0100 | tritlo | (sid58727@user/tritlo) (Ping timeout: 245 seconds) |
| 2022-01-31 10:37:31 +0100 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2022-01-31 10:37:42 +0100 | phma | (~phma@2001:5b0:211f:83e8:ceab:d757:d3e2:cd8f) (Ping timeout: 260 seconds) |
| 2022-01-31 10:37:56 +0100 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) (Ping timeout: 252 seconds) |
| 2022-01-31 10:38:01 +0100 | agander_m | (sid407952@id-407952.tinside.irccloud.com) |
| 2022-01-31 10:38:15 +0100 | truckasaurus | (sid457088@id-457088.helmsley.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:38:15 +0100 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:38:29 +0100 | ehamberg | (sid18208@id-18208.hampstead.irccloud.com) (Ping timeout: 252 seconds) |
| 2022-01-31 10:38:30 +0100 | ski | (~ski@remote12.chalmers.se) (Ping timeout: 250 seconds) |
| 2022-01-31 10:39:06 +0100 | conjunctive | (sid433686@id-433686.helmsley.irccloud.com) (Ping timeout: 260 seconds) |
| 2022-01-31 10:39:06 +0100 | rune | (sid21167@id-21167.ilkley.irccloud.com) (Ping timeout: 260 seconds) |
| 2022-01-31 10:39:11 +0100 | cln | (sid336875@id-336875.ilkley.irccloud.com) |
| 2022-01-31 10:39:19 +0100 | ski | (~ski@remote12.chalmers.se) |
| 2022-01-31 10:39:35 +0100 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) (Ping timeout: 252 seconds) |
| 2022-01-31 10:39:56 +0100 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) (Ping timeout: 245 seconds) |
| 2022-01-31 10:40:01 +0100 | tritlo | (sid58727@user/tritlo) |
| 2022-01-31 10:40:13 +0100 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) |
| 2022-01-31 10:40:27 +0100 | dut_ | dut |
| 2022-01-31 10:40:34 +0100 | ephemient | (uid407513@id-407513.lymington.irccloud.com) |
| 2022-01-31 10:40:43 +0100 | conjunctive | (sid433686@id-433686.helmsley.irccloud.com) |
| 2022-01-31 10:40:45 +0100 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) |
| 2022-01-31 10:40:50 +0100 | phma_ | phma |
| 2022-01-31 10:40:50 +0100 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) |
| 2022-01-31 10:41:00 +0100 | ehamberg | (sid18208@id-18208.hampstead.irccloud.com) |
| 2022-01-31 10:41:06 +0100 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) |
| 2022-01-31 10:41:07 +0100 | truckasaurus | (sid457088@id-457088.helmsley.irccloud.com) |
| 2022-01-31 10:41:17 +0100 | alinab | (sid468903@helmsley.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:41:43 +0100 | rune | (sid21167@id-21167.ilkley.irccloud.com) |
| 2022-01-31 10:41:45 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) (Quit: Konversation terminated!) |
| 2022-01-31 10:42:01 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-01-31 10:43:09 +0100 | alinab | (sid468903@id-468903.helmsley.irccloud.com) |
| 2022-01-31 10:43:46 +0100 | vito | (sid1962@user/vito) (Ping timeout: 260 seconds) |
| 2022-01-31 10:44:30 +0100 | vito | (sid1962@user/vito) |
| 2022-01-31 10:44:45 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 250 seconds) |
| 2022-01-31 10:46:03 +0100 | Pent | (sid313808@id-313808.lymington.irccloud.com) (Ping timeout: 250 seconds) |
| 2022-01-31 10:49:24 +0100 | Pent | (sid313808@id-313808.lymington.irccloud.com) |
| 2022-01-31 10:49:41 +0100 | cynomys | (~cynomys@user/cynomys) (Ping timeout: 256 seconds) |
| 2022-01-31 10:54:46 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-01-31 10:55:59 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-01-31 10:56:01 +0100 | cfricke | (~cfricke@user/cfricke) (Client Quit) |
| 2022-01-31 10:56:12 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) |
| 2022-01-31 10:56:59 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 10:57:26 +0100 | max22- | (~maxime@2a01cb08833598005d2ea791b13aed90.ipv6.abo.wanadoo.fr) (Ping timeout: 245 seconds) |
| 2022-01-31 11:01:48 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 11:03:17 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 11:05:11 +0100 | Codaraxis__ | (~Codaraxis@user/codaraxis) (Read error: Connection reset by peer) |
| 2022-01-31 11:06:19 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) |
| 2022-01-31 11:06:54 +0100 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-01-31 11:08:12 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-01-31 11:09:50 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) (Read error: Connection reset by peer) |
| 2022-01-31 11:10:15 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) |
| 2022-01-31 11:12:50 +0100 | Graham31415 | (~Graham314@5.33.56.252) |
| 2022-01-31 11:17:59 +0100 | ncopa3 | ncopa |
| 2022-01-31 11:18:18 +0100 | ncopa | (~ncopa@gbr2-dev1.alpinelinux.org) (Changing host) |
| 2022-01-31 11:18:18 +0100 | ncopa | (~ncopa@alpine/developer/ncopa) |
| 2022-01-31 11:20:11 +0100 | <Graham31415> | Hi. I'm planning to learn Haskell, and I've noticed there are a variety of older docs/books that apply to Haskell98. Should I avoiding learning from older reference material (some of them look more my style compared to newer resources)? I have GHC 9.0.2 installed via my OS, and see that this does Haskell2010 by default, but that newer GHC versions |
| 2022-01-31 11:20:12 +0100 | <Graham31415> | enable GHC2021 by default (with a bewildering array of extensions enabled). Is there a reason to use/avoid any particular Haskell subset while learning? Is it just a matter of ignoring any syntax I don't understand when reading code (at least for now)? |
| 2022-01-31 11:20:32 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-01-31 11:21:46 +0100 | <geekosaur> | haskell2010 has maybe 3 smallish changes compared to haskell98 |
| 2022-01-31 11:22:25 +0100 | <geekosaur> | the bigger changes aren't captured by any standard but they're easy enough to deal with once you know about them |
| 2022-01-31 11:22:29 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7951:c786:1220:b402) |
| 2022-01-31 11:23:14 +0100 | <geekosaur> | (and ghc2021 is those extensions and nothing else, and you won't find any learning material for it. or for the extensions, aside from stuff that assumes you already learned standard Haskell) |
| 2022-01-31 11:24:15 +0100 | <geekosaur> | @where books |
| 2022-01-31 11:24:15 +0100 | <lambdabot> | https://www.extrema.is/articles/haskell-books, see also @where LYAH, RWH, YAHT, SOE, HR, PIH, TFwH, wikibook, PCPH, HPFFP, HTAC, TwT, FoP, PFAD, WYAH, non-haskell-books |
| 2022-01-31 11:24:57 +0100 | <geekosaur> | mm, guess that needs to be edited |
| 2022-01-31 11:25:23 +0100 | xsperry | (~xs@user/xsperry) |
| 2022-01-31 11:25:36 +0100 | <geekosaur> | or not, lyah seems to be back online |
| 2022-01-31 11:27:14 +0100 | <Graham31415> | Thanks! |
| 2022-01-31 11:29:13 +0100 | <geekosaur> | feel free to ask here if you have any questions or problems |
| 2022-01-31 11:29:24 +0100 | <geekosaur> | there's usually someone around who can help |
| 2022-01-31 11:29:35 +0100 | <Graham31415> | Awesome. Will do! |
| 2022-01-31 11:29:43 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:d2eb:19ab:f134:7a9c) (Quit: WeeChat 2.8) |
| 2022-01-31 11:30:28 +0100 | eggplant_ | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Remote host closed the connection) |
| 2022-01-31 11:32:00 +0100 | Codaraxis_ | (~Codaraxis@user/codaraxis) |
| 2022-01-31 11:35:48 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-01-31 11:36:32 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Remote host closed the connection) |
| 2022-01-31 11:39:17 +0100 | euandreh | (~euandreh@2804:14c:33:9fe5:8e08:7908:8918:48c0) (Ping timeout: 240 seconds) |
| 2022-01-31 11:39:31 +0100 | Franciman | (~Franciman@mx1.fracta.dev) |
| 2022-01-31 11:39:38 +0100 | <Franciman> | so you kept making fun of me |
| 2022-01-31 11:39:47 +0100 | <Franciman> | https://github.com/Kindelia/HVM here is the answer to y'all |
| 2022-01-31 11:40:46 +0100 | <Franciman> | and now i am happy i won't have to code in haskell ever again, this community has become toxic for me |
| 2022-01-31 11:40:50 +0100 | <Franciman> | enjoy making fun of people |
| 2022-01-31 11:40:51 +0100 | <Franciman> | bye |
| 2022-01-31 11:41:06 +0100 | <Franciman> | we are hopefully getting much better tools than haskell and much better communities |
| 2022-01-31 11:41:08 +0100 | <Franciman> | bye |
| 2022-01-31 11:41:36 +0100 | arjun | (~arjun@user/arjun) |
| 2022-01-31 11:41:47 +0100 | Franciman | (~Franciman@mx1.fracta.dev) (haskell is the richest esolang) |
| 2022-01-31 11:43:01 +0100 | <kuribas> | What's up with him? |
| 2022-01-31 11:44:27 +0100 | memowe | (~memowe@vpnpool6-3901-0442.uni-muenster.de) |
| 2022-01-31 11:44:50 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-01-31 11:45:15 +0100 | <opqdonut> | oh huh HVM sounds interesting |
| 2022-01-31 11:45:30 +0100 | <memowe> | o/ |
| 2022-01-31 11:46:37 +0100 | <geekosaur> | Franciman has been in the past rather pissy that we don't think like they do |
| 2022-01-31 11:46:47 +0100 | <kuribas> | geekosaur: there are more? |
| 2022-01-31 11:46:57 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 240 seconds) |
| 2022-01-31 11:46:59 +0100 | <geekosaur> | singular "they" |
| 2022-01-31 11:47:14 +0100 | geekosaur | tends to avoid gendering |
| 2022-01-31 11:47:43 +0100 | <kuribas> | ah, haha :) |
| 2022-01-31 11:47:45 +0100 | [exa] | foresees `theys` |
| 2022-01-31 11:47:51 +0100 | Franciman | (~Franciman@mx1.fracta.dev) |
| 2022-01-31 11:48:03 +0100 | <Franciman> | geekosaur: i've been pissy? Ok I apologise, but i did because i felt made fun of |
| 2022-01-31 11:48:11 +0100 | <Franciman> | because of your (noy specifically yours) sarcarsm |
| 2022-01-31 11:48:20 +0100 | <Franciman> | ok |
| 2022-01-31 11:48:22 +0100 | <Franciman> | sorry |
| 2022-01-31 11:48:23 +0100 | <dminuoso> | kuribas: This is a singular they as per Chicago Guide of Style |
| 2022-01-31 11:48:32 +0100 | <kuribas> | right :) |
| 2022-01-31 11:48:33 +0100 | <geekosaur> | I didn't see much sarcasm in the exchanges I saw, just a complete failure to agree on basics |
| 2022-01-31 11:48:33 +0100 | <Franciman> | but why make fun of me |
| 2022-01-31 11:48:45 +0100 | <maerwald> | geekosaur: "they" is also gendering |
| 2022-01-31 11:49:05 +0100 | <Franciman> | you can use "it" for me, please :) |
| 2022-01-31 11:49:14 +0100 | <kuribas> | haskellers are pedantic, academic, stubburn, dismissive, but I wouldn't call them toxic... |
| 2022-01-31 11:50:07 +0100 | <Franciman> | geekosaur: glad to be wrong |
| 2022-01-31 11:51:19 +0100 | <Franciman> | so i haven't been made fun of when i encouraged a friend, but received the equivalent in text of rolled eyes by by other people in the room |
| 2022-01-31 11:51:20 +0100 | <kuribas> | stubborn |
| 2022-01-31 11:51:22 +0100 | <Franciman> | ok |
| 2022-01-31 11:52:03 +0100 | memowe | (~memowe@vpnpool6-3901-0442.uni-muenster.de) () |
| 2022-01-31 11:52:06 +0100 | <Franciman> | proposing things and getting answers like: yes, and maybe let's also do this *dumb thing* |
| 2022-01-31 11:52:09 +0100 | <Franciman> | isn't sarcasm |
| 2022-01-31 11:52:11 +0100 | <Franciman> | ? |
| 2022-01-31 11:52:16 +0100 | <Franciman> | ok, then |
| 2022-01-31 11:52:19 +0100 | <Franciman> | i was wrong |
| 2022-01-31 11:52:19 +0100 | <[exa]> | Franciman: btw what happened? (for the others here, my scrollback doesnt seem to reach any problems) |
| 2022-01-31 11:53:07 +0100 | <Franciman> | nothing |
| 2022-01-31 11:53:09 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 11:53:10 +0100 | <Franciman> | i misinterpreted things |
| 2022-01-31 11:53:13 +0100 | <Franciman> | so enjoy |
| 2022-01-31 11:53:18 +0100 | <[exa]> | oh okay |
| 2022-01-31 11:53:22 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-01-31 11:53:25 +0100 | <Franciman> | enjoy your awesome perfect ultimate language |
| 2022-01-31 11:53:30 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-01-31 11:53:31 +0100 | <maerwald> | :D |
| 2022-01-31 11:53:45 +0100 | <Franciman> | being beaten by hvm by an exponential factor |
| 2022-01-31 11:53:58 +0100 | <Franciman> | pretty awesome result |
| 2022-01-31 11:54:01 +0100 | <Franciman> | btw |
| 2022-01-31 11:54:29 +0100 | <dminuoso> | Glad if you produce results that you're happy with. |
| 2022-01-31 11:54:38 +0100 | <Franciman> | and maybe in the future remember that some people may feel offended when you act in some ways |
| 2022-01-31 11:54:41 +0100 | <Franciman> | so ok |
| 2022-01-31 11:54:46 +0100 | <Franciman> | sorry , i misinterpreted |
| 2022-01-31 11:54:49 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 11:54:57 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) (Quit: My Ex-Girlfriend once told me: I'm not a slut, I'm just popular) |
| 2022-01-31 11:55:01 +0100 | <Franciman> | enjoy your esocommunity |
| 2022-01-31 11:55:05 +0100 | <Franciman> | bye |
| 2022-01-31 11:55:08 +0100 | Franciman | (~Franciman@mx1.fracta.dev) (TURBOquit(TM) - the fastest way to get out of awkward situations) |
| 2022-01-31 11:55:50 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 11:56:20 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2022-01-31 11:57:11 +0100 | <maerwald> | I think Haskell is more of a sunk cost fallacy by now (like 99% of all languages) |
| 2022-01-31 11:57:19 +0100 | <maerwald> | but that's ok |
| 2022-01-31 11:57:20 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 11:57:27 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) |
| 2022-01-31 11:59:21 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 12:00:22 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-01-31 12:01:05 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-01-31 12:01:18 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 12:02:01 +0100 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2022-01-31 12:02:06 +0100 | newhoggy | (sid198874@id-198874.helmsley.irccloud.com) |
| 2022-01-31 12:02:34 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-31 12:02:53 +0100 | fef | (~thedawn@user/thedawn) (Client Quit) |
| 2022-01-31 12:03:09 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 12:04:04 +0100 | <Benzi-Junior> | how do I set a ghc flag globally |
| 2022-01-31 12:04:06 +0100 | Graham31415 | (~Graham314@5.33.56.252) (Quit: Client closed) |
| 2022-01-31 12:04:31 +0100 | <Benzi-Junior> | i.e. whenever I run ghc I want certain flags sets |
| 2022-01-31 12:05:42 +0100 | <geekosaur> | there isn't really a way to do so. but these days it's unusual to run ghc by itself, and if you use cabal or stack there are ways to set "global" options |
| 2022-01-31 12:09:38 +0100 | <maerwald> | Benzi-Junior: a wrapper script |
| 2022-01-31 12:10:31 +0100 | <geekosaur> | beware that if you do that it could confuse stacdk/cabal if you do use them for some things |
| 2022-01-31 12:10:43 +0100 | <geekosaur> | depending on the option |
| 2022-01-31 12:13:04 +0100 | cynomys | (~cynomys@user/cynomys) |
| 2022-01-31 12:13:57 +0100 | <Benzi-Junior> | geekosaur, -fno-warn-tabs |
| 2022-01-31 12:15:08 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-31 12:15:25 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-01-31 12:15:38 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) (Quit: My Ex-Girlfriend once told me: I'm not a slut, I'm just popular) |
| 2022-01-31 12:15:44 +0100 | cynomys | (~cynomys@user/cynomys) (Client Quit) |
| 2022-01-31 12:16:22 +0100 | <yushyin> | I advise you not to use tabs unless you really really know how the layout rules work :D |
| 2022-01-31 12:16:37 +0100 | <geekosaur> | that one's probably fine although … that. people will warn you about it all over the place :) |
| 2022-01-31 12:16:58 +0100 | <yushyin> | like I just did :) |
| 2022-01-31 12:17:10 +0100 | chele | (~chele@user/chele) (Ping timeout: 256 seconds) |
| 2022-01-31 12:17:21 +0100 | <geekosaur> | also that you always use editors that agree with ghc on what a tab is |
| 2022-01-31 12:17:49 +0100 | <Benzi-Junior> | honestly, I have been writing haskell since years before ghc made -fwarn tabs the default |
| 2022-01-31 12:18:23 +0100 | <Benzi-Junior> | I have yet to find a single bug due to indentation |
| 2022-01-31 12:20:06 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2022-01-31 12:21:05 +0100 | gawen_ | (~gawen@user/gawen) (Read error: Connection reset by peer) |
| 2022-01-31 12:22:52 +0100 | <Benzi-Junior> | I have however had -fwarn-tabs break some builds beacuse of tools escalating warnings to errors |
| 2022-01-31 12:23:43 +0100 | gawen | (~gawen@user/gawen) |
| 2022-01-31 12:24:29 +0100 | gawen | (~gawen@user/gawen) (Read error: Connection reset by peer) |
| 2022-01-31 12:25:12 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) (Quit: Konversation terminated!) |
| 2022-01-31 12:26:44 +0100 | gawen | (~gawen@user/gawen) |
| 2022-01-31 12:28:58 +0100 | <maerwald> | Benzi-Junior: use a wrapper script |
| 2022-01-31 12:29:25 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 12:30:37 +0100 | vglfr | (~vglfr@46.96.161.0) (Ping timeout: 240 seconds) |
| 2022-01-31 12:30:50 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 12:30:57 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-31 12:31:11 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 12:31:40 +0100 | <maerwald> | exec ghc -fno-warn-tabs ${1+"$@"} |
| 2022-01-31 12:31:48 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-31 12:32:04 +0100 | max22- | (~maxime@2a01cb08833598000998630b2f1bfbaa.ipv6.abo.wanadoo.fr) |
| 2022-01-31 12:33:06 +0100 | <geekosaur> | use a path on that "ghc" so the script doesn't re-exec itself :) |
| 2022-01-31 12:33:42 +0100 | <geekosaur> | (also just tested to make sure it doesn't do weird stuff with --version, --supported-languages, or other things build systems might want to do with ghc behind your back) |
| 2022-01-31 12:35:57 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Ping timeout: 240 seconds) |
| 2022-01-31 12:36:47 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 12:38:28 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 12:39:03 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 12:40:40 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 12:47:02 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-01-31 12:49:37 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2022-01-31 12:52:29 +0100 | <Andrew> | When compiling and running https://termbin.com/v4fh, the evaluation sequence is wrong |
| 2022-01-31 12:52:41 +0100 | <Andrew> | i.e. I get the prompt '> ' after typing the input |
| 2022-01-31 12:53:40 +0100 | <yushyin> | you should flush stdout handle |
| 2022-01-31 12:53:47 +0100 | <dminuoso> | Or change the buffering mode. |
| 2022-01-31 12:53:59 +0100 | <Andrew> | Oh, thanks |
| 2022-01-31 12:54:12 +0100 | <Andrew> | I thought that it was a strictness issue, which confused me because I'm already in `do' |
| 2022-01-31 12:54:25 +0100 | <dminuoso> | This is some of the bizarre things you begin to appreciate, that in a terminal you have stdin echo and stdout together in one stream.. |
| 2022-01-31 12:54:38 +0100 | <dminuoso> | So its up to you to sort out the ambiguity/reordering issues |
| 2022-01-31 12:54:42 +0100 | <Andrew> | I mean, don't all interactive programs do that? |
| 2022-01-31 12:55:10 +0100 | <dminuoso> | All interactive CLI programs *must* do this one way or another |
| 2022-01-31 12:55:43 +0100 | <dminuoso> | That's simply a natural consequence of shared screen estate. If you want your output and input echo to occur on the same space. |
| 2022-01-31 12:56:08 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-01-31 12:57:02 +0100 | <dminuoso> | Amongst the toolbag of things to do is: tightly control buffering, toggle echo mode off, switch to raw mode and handle everything yourself.. |
| 2022-01-31 12:57:24 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 256 seconds) |
| 2022-01-31 12:58:59 +0100 | <dminuoso> | If you take a curses client, like say common IRC clients, they address this by switching to raw mode and then controlling the entirety of the terminal manually by emitting the right control sequences in the right order/time. |
| 2022-01-31 12:59:11 +0100 | <geekosaur> | the reason output is buffered is because even in 2022 if you turn off buffering you can see individual characters being output one at a time |
| 2022-01-31 12:59:31 +0100 | <geekosaur> | if every one needs its own systemj call for output |
| 2022-01-31 12:59:32 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 13:00:02 +0100 | Andrew | likes having individual outputs one-by-one |
| 2022-01-31 13:00:15 +0100 | <Andrew> | I hate it when UNIX pipes buffer too much |
| 2022-01-31 13:00:15 +0100 | <dminuoso> | Andrew: Your users might not for performance reasons. |
| 2022-01-31 13:00:20 +0100 | <Andrew> | Hehe true |
| 2022-01-31 13:00:42 +0100 | <yushyin> | only in haskell do people quickly blame lazyness for this, while the same behaviour is seen in all other languages |
| 2022-01-31 13:00:48 +0100 | <dminuoso> | Andrew: The ideal compromise here is raw mode. |
| 2022-01-31 13:01:02 +0100 | <Andrew> | dminuoso: I found that, thanks |
| 2022-01-31 13:01:41 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) |
| 2022-01-31 13:01:42 +0100 | <Andrew> | yushyin: I don't see that with TeX or C or python or shell, but yes, Haskell has laziness, and if you don't know what `do' does, that's a reasonable idea |
| 2022-01-31 13:01:43 +0100 | <dminuoso> | Andrew: Say curses actually uses custom buffering but with arbitrary degrees of freedom. But it means the terminal output is managed by you entiretly. |
| 2022-01-31 13:01:51 +0100 | boxscape_ | (~boxscape_@p4ff0b9d5.dip0.t-ipconnect.de) |
| 2022-01-31 13:01:56 +0100 | <Andrew> | Yeah, I know that |
| 2022-01-31 13:02:01 +0100 | <geekosaur> | I see it with C, it does exactly the same buffering |
| 2022-01-31 13:02:03 +0100 | gawen_ | (~gawen@user/gawen) |
| 2022-01-31 13:02:05 +0100 | <yushyin> | ^ |
| 2022-01-31 13:02:30 +0100 | <dminuoso> | Mmm, is that actually defined in C? |
| 2022-01-31 13:02:30 +0100 | gawen | (~gawen@user/gawen) (Ping timeout: 256 seconds) |
| 2022-01-31 13:02:35 +0100 | <boxscape_> | Is there a canonical haskell solution for putting on hold and waking up threads with signals from other threads? |
| 2022-01-31 13:02:41 +0100 | <dminuoso> | Id expect buffering defined in systems standards like POSIX, if anything. |
| 2022-01-31 13:02:59 +0100 | <dminuoso> | boxscape_: Yes. |
| 2022-01-31 13:03:09 +0100 | <dminuoso> | boxscape_: Use an T/MVar? |
| 2022-01-31 13:03:15 +0100 | <dminuoso> | And just block on it one way or another |
| 2022-01-31 13:03:23 +0100 | <boxscape_> | ah, right, those exist |
| 2022-01-31 13:03:24 +0100 | <boxscape_> | thanks |
| 2022-01-31 13:03:39 +0100 | <Andrew> | By the way, is there something like `read', but works for [char]? For example, `functionToBeDiscovered "123" :: Integer` is 123 |
| 2022-01-31 13:04:00 +0100 | <dminuoso> | Andrew: So read actually works for that, but it's a very poor fit. |
| 2022-01-31 13:04:01 +0100 | <geekosaur> | huh? |
| 2022-01-31 13:04:12 +0100 | <Andrew> | Hmm... |
| 2022-01-31 13:04:21 +0100 | <byorgey> | Andrew: [Char] is the same as String |
| 2022-01-31 13:04:21 +0100 | <__monty__> | :t read |
| 2022-01-31 13:04:22 +0100 | <geekosaur> | @src String |
| 2022-01-31 13:04:22 +0100 | <lambdabot> | type String = [Char] |
| 2022-01-31 13:04:22 +0100 | <lambdabot> | Read a => String -> a |
| 2022-01-31 13:04:28 +0100 | <dminuoso> | Andrew: The simple "get some quick practice" answer is read if you dont care about performance, bugs and poor diagnostics. |
| 2022-01-31 13:04:31 +0100 | <Andrew> | I know that char is same as string, yes |
| 2022-01-31 13:04:37 +0100 | <dminuoso> | The industrial answer is attoparsec/megaparsec. |
| 2022-01-31 13:04:50 +0100 | <Andrew> | I mean, `read "123" :: Integer` is errooneous |
| 2022-01-31 13:04:56 +0100 | <byorgey> | > read "123" :: Integer |
| 2022-01-31 13:04:58 +0100 | <lambdabot> | 123 |
| 2022-01-31 13:05:01 +0100 | <byorgey> | works for me |
| 2022-01-31 13:05:07 +0100 | <Andrew> | Wait, really sorry, that was my typing, sorry :( |
| 2022-01-31 13:05:16 +0100 | <byorgey> | hehe, no worries =) |
| 2022-01-31 13:05:20 +0100 | <dminuoso> | Andrew: So the first answer is, you likely never want read, readMaybe is the better solution |
| 2022-01-31 13:05:32 +0100 | <dminuoso> | Because you likely dont control the input, so you need to be able to deal with bugs. |
| 2022-01-31 13:05:48 +0100 | <Andrew> | Ah, yes |
| 2022-01-31 13:06:27 +0100 | <dminuoso> | The next step is that read extremely poor performance, the third step is that `read` is sort of like a haskell evaluator (that complements show) rather than a parser framework. Then final, read is unable to give any diagnostics as to why or where parsing something failed. |
| 2022-01-31 13:06:28 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 13:07:00 +0100 | <dminuoso> | Which is why if you want to turn textual data into something different, you likely want to use a proper parsing library like `attoparsec` or `megaparsec` |
| 2022-01-31 13:07:19 +0100 | <dminuoso> | Haskell certainly doesnt make the task of "process some text data" very easy for beginners (and experts). |
| 2022-01-31 13:07:36 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 256 seconds) |
| 2022-01-31 13:09:02 +0100 | <Andrew> | dminuoso: I noticed that, yeah. I think it's not that easy (but "better") in C either, the easiest is of course sh, which doesn't have types, and everything is a string |
| 2022-01-31 13:11:43 +0100 | <geekosaur> | well, except sh is short on a bunch of useful tools |
| 2022-01-31 13:11:47 +0100 | <geekosaur> | which is why awk and perl |
| 2022-01-31 13:12:35 +0100 | vysn | (~vysn@user/vysn) (Quit: WeeChat 3.3) |
| 2022-01-31 13:15:19 +0100 | jgeerds_ | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 256 seconds) |
| 2022-01-31 13:15:27 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-01-31 13:16:57 +0100 | Guest9250 | xstill- |
| 2022-01-31 13:17:05 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-31 13:17:27 +0100 | xstill- | Guest1281 |
| 2022-01-31 13:18:13 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-01-31 13:20:55 +0100 | <maerwald> | Andrew: sh has types, e.g. functions (arrays in bash) etc. |
| 2022-01-31 13:20:59 +0100 | <dminuoso> | Andrew: Better in C? As if all the string formatting and parsing functions have historically not been one of the largest source of CVEs... |
| 2022-01-31 13:21:53 +0100 | <dminuoso> | Astronomically poor support for textual data in C gave right to entire industries of red and blue teams... |
| 2022-01-31 13:21:58 +0100 | <dminuoso> | *gave birth |
| 2022-01-31 13:22:05 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Remote host closed the connection) |
| 2022-01-31 13:22:08 +0100 | <Andrew> | That's true |
| 2022-01-31 13:22:12 +0100 | <dminuoso> | So sure. Its good in the sense that it secures a lot of peoples lifes... :) |
| 2022-01-31 13:22:14 +0100 | <maerwald> | dminuoso: that's because people in C don't use parser combinators |
| 2022-01-31 13:22:18 +0100 | <maerwald> | it's not the fault of the language |
| 2022-01-31 13:22:22 +0100 | <Andrew> | Exactly |
| 2022-01-31 13:22:30 +0100 | <dminuoso> | maerwald: Its the fault of the language if they bring tools that are incredibly easy to misuse. |
| 2022-01-31 13:22:41 +0100 | <Andrew> | I mean, sh is really UNIXy, so things are supposed to be separate tools linked together |
| 2022-01-31 13:23:03 +0100 | <dminuoso> | It's like handing unstable explosives to a kid, but blaming them for playing with them, instead of the safe wooden toys |
| 2022-01-31 13:23:05 +0100 | <maerwald> | dminuoso: parser combinators didn't really exist back then I hink |
| 2022-01-31 13:23:11 +0100 | <maerwald> | so no, I don't think it's the fault of the language |
| 2022-01-31 13:23:22 +0100 | <Andrew> | By the way, are there any BUILTIN functions that are like the INVERSE of map? For example it takes a list of functions (do those exist? hmm) and a peice of data and applies all of them to a list |
| 2022-01-31 13:23:35 +0100 | <dminuoso> | Andrew: Yes, map! |
| 2022-01-31 13:23:41 +0100 | <Andrew> | What? |
| 2022-01-31 13:23:59 +0100 | <dminuoso> | % ($ 3) <$> [(+1), (*2)] |
| 2022-01-31 13:23:59 +0100 | <yahb> | dminuoso: [4,6] |
| 2022-01-31 13:24:03 +0100 | <dminuoso> | Voila! :) |
| 2022-01-31 13:24:15 +0100 | <dminuoso> | note, if you're unfamiliar, <$> is an infix variant of map |
| 2022-01-31 13:24:25 +0100 | <dminuoso> | % map ($ 3) [(+1), (*2)] |
| 2022-01-31 13:24:25 +0100 | <yahb> | dminuoso: [4,6] |
| 2022-01-31 13:24:35 +0100 | <Andrew> | why the $ there? |
| 2022-01-31 13:24:43 +0100 | <Guillaum[m]> | And if you are unfamiliar with ($ 3), that (\f -> f 3) |
| 2022-01-31 13:24:51 +0100 | <dminuoso> | a $ b = a b |
| 2022-01-31 13:24:56 +0100 | <Andrew> | Oh |
| 2022-01-31 13:25:05 +0100 | <dminuoso> | So ($ 3) is a partially applied ($) |
| 2022-01-31 13:25:09 +0100 | Andrew | recalls that `seq' is used somewhere there |
| 2022-01-31 13:25:10 +0100 | dsrt^ | (~dsrt@75-147-197-198-Atlanta.hfc.comcastbusiness.net) (Ping timeout: 256 seconds) |
| 2022-01-31 13:25:16 +0100 | <boxscape_> | % distribute [(+1), (*2)] 3 |
| 2022-01-31 13:25:16 +0100 | <yahb> | boxscape_: [4,6] |
| 2022-01-31 13:25:18 +0100 | <Andrew> | k, got it :) |
| 2022-01-31 13:25:20 +0100 | <boxscape_> | that's not in the standard library though |
| 2022-01-31 13:25:25 +0100 | <Andrew> | It feels a bit hacky though |
| 2022-01-31 13:25:30 +0100 | <dminuoso> | What's hacky about it? |
| 2022-01-31 13:25:38 +0100 | <dminuoso> | It's very idiomatic. |
| 2022-01-31 13:26:47 +0100 | <Guillaum[m]> | Andrew if you are not at ease with `$`, just write another function (let's say "g f = f 3") and use it in your map (such as "map g [(+1), (*2)]") |
| 2022-01-31 13:27:19 +0100 | dsrt^ | (~dsrt@75-147-197-198-Atlanta.hfc.comcastbusiness.net) |
| 2022-01-31 13:28:15 +0100 | <idnar> | % [(+1), (*2)] <*> pure 3 |
| 2022-01-31 13:28:15 +0100 | <yahb> | idnar: [4,6] |
| 2022-01-31 13:28:24 +0100 | <dminuoso> | Or write your own `distribute xs y = ($ y) <$> xs`, and then have the same comfort as boxscape_ above. |
| 2022-01-31 13:28:33 +0100 | <Andrew> | Yeah |
| 2022-01-31 13:28:37 +0100 | <Andrew> | Thanks |
| 2022-01-31 13:29:45 +0100 | chele | (~chele@user/chele) |
| 2022-01-31 13:29:46 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) |
| 2022-01-31 13:30:16 +0100 | <boxscape_> | (the one I used is from the "distributive" package by the way) |
| 2022-01-31 13:30:30 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:db29:cb0:7e70:ac05) |
| 2022-01-31 13:30:58 +0100 | <boxscape_> | % sequenceA [(+1), (*2)] 3 |
| 2022-01-31 13:30:58 +0100 | <yahb> | boxscape_: [4,6] |
| 2022-01-31 13:30:59 +0100 | <boxscape_> | hm |
| 2022-01-31 13:31:06 +0100 | <boxscape_> | I suppose that works, too |
| 2022-01-31 13:31:19 +0100 | <dminuoso> | % :t sequenceA |
| 2022-01-31 13:31:19 +0100 | <yahb> | dminuoso: (Traversable t, Applicative f) => t (f a) -> f (t a) |
| 2022-01-31 13:31:40 +0100 | <dminuoso> | That's quite cunning |
| 2022-01-31 13:31:55 +0100 | <boxscape_> | I only tried it because sequenceA's type signature is so similar to distribute |
| 2022-01-31 13:31:57 +0100 | <boxscape_> | :t distribute |
| 2022-01-31 13:31:58 +0100 | <lambdabot> | error: |
| 2022-01-31 13:31:58 +0100 | <lambdabot> | • Variable not in scope: distribute |
| 2022-01-31 13:31:58 +0100 | <lambdabot> | • Perhaps you meant ‘distrib’ (imported from Control.Lens) |
| 2022-01-31 13:32:00 +0100 | <boxscape_> | % :t distribute |
| 2022-01-31 13:32:00 +0100 | <yahb> | boxscape_: (Distributive g, Functor f) => f (g a) -> g (f a) |
| 2022-01-31 13:32:02 +0100 | <dminuoso> | But I think its too shrouded and not obvious what this does. |
| 2022-01-31 13:32:08 +0100 | <boxscape_> | that is true |
| 2022-01-31 13:32:23 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-01-31 13:32:55 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-01-31 13:33:05 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 13:33:27 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 13:37:38 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 13:42:52 +0100 | MasseR4 | (~MasseR@51.15.143.128) (Quit: The Lounge - https://thelounge.chat) |
| 2022-01-31 13:43:30 +0100 | MasseR4 | (~MasseR@51.15.143.128) |
| 2022-01-31 13:44:47 +0100 | Gurkenglas | (~Gurkengla@dslb-090-186-104-244.090.186.pools.vodafone-ip.de) |
| 2022-01-31 13:46:26 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) |
| 2022-01-31 13:48:36 +0100 | Guest4442 | (~Guest44@77.222.105.50) |
| 2022-01-31 13:57:03 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-01-31 13:57:48 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-01-31 13:58:00 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:7951:c786:1220:b402) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-01-31 13:59:31 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-01-31 14:00:38 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-31 14:02:09 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-01-31 14:02:41 +0100 | vglfr | (~vglfr@46.96.158.194) |
| 2022-01-31 14:05:34 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 14:09:24 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 276 seconds) |
| 2022-01-31 14:10:29 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-01-31 14:11:06 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-01-31 14:11:10 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) |
| 2022-01-31 14:11:13 +0100 | fendor_ | (~fendor@77.119.206.49.wireless.dyn.drei.com) |
| 2022-01-31 14:12:33 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) (Remote host closed the connection) |
| 2022-01-31 14:13:51 +0100 | fendor | (~fendor@178.165.174.170.wireless.dyn.drei.com) (Ping timeout: 250 seconds) |
| 2022-01-31 14:16:06 +0100 | Guest1281 | (xstill@lounge.fi.muni.cz) (Changing host) |
| 2022-01-31 14:16:06 +0100 | Guest1281 | (xstill@fimu/xstill) |
| 2022-01-31 14:17:12 +0100 | Guest1281 | xstill_ |
| 2022-01-31 14:24:40 +0100 | max22- | (~maxime@2a01cb08833598000998630b2f1bfbaa.ipv6.abo.wanadoo.fr) (Ping timeout: 268 seconds) |
| 2022-01-31 14:25:52 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) |
| 2022-01-31 14:26:46 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2022-01-31 14:27:47 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-01-31 14:32:22 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 14:34:06 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.4) |
| 2022-01-31 14:35:19 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) |
| 2022-01-31 14:37:36 +0100 | dsrt^ | (~dsrt@75-147-197-198-Atlanta.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 2022-01-31 14:39:11 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Quit: mikoto-chan) |
| 2022-01-31 14:40:14 +0100 | xstill_ | xstill- |
| 2022-01-31 14:40:17 +0100 | jespada | (~jespada@87.74.36.188) (Ping timeout: 250 seconds) |
| 2022-01-31 14:41:18 +0100 | jespada | (~jespada@87.74.36.188) |
| 2022-01-31 14:43:13 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) (Disconnected: Replaced by new connection) |
| 2022-01-31 14:43:28 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 14:48:21 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-01-31 14:49:14 +0100 | vysn | (~vysn@user/vysn) |
| 2022-01-31 14:49:35 +0100 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2022-01-31 14:50:00 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-31 14:50:20 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 14:51:09 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-31 14:51:17 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) (Disconnected: Replaced by new connection) |
| 2022-01-31 14:51:27 +0100 | qrpnxz | (abc4f95c31@user/qrpnxz) |
| 2022-01-31 14:51:40 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-31 14:51:42 +0100 | qrpnxz | (abc4f95c31@user/qrpnxz) () |
| 2022-01-31 14:52:01 +0100 | qrpnxz | (~qrpnxz@user/qrpnxz) |
| 2022-01-31 14:54:56 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-01-31 14:55:04 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Ping timeout: 256 seconds) |
| 2022-01-31 14:59:31 +0100 | newhoggy | (sid198874@id-198874.helmsley.irccloud.com) (Ping timeout: 245 seconds) |
| 2022-01-31 14:59:40 +0100 | newhoggy | (sid198874@id-198874.helmsley.irccloud.com) |
| 2022-01-31 15:01:07 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-31 15:03:46 +0100 | slack1256 | (~slack1256@191.126.99.84) |
| 2022-01-31 15:04:13 +0100 | slack1256 | (~slack1256@191.126.99.84) (Remote host closed the connection) |
| 2022-01-31 15:04:18 +0100 | Unhammer | (~Unhammer@user/unhammer) |
| 2022-01-31 15:08:14 +0100 | <Morrow> | boxscape_: I believe using sequence like that will use O(n) space, or so I've heard |
| 2022-01-31 15:08:31 +0100 | <boxscape_> | oh interesting |
| 2022-01-31 15:09:38 +0100 | y04nn | (~y04nn@92.223.89.196) |
| 2022-01-31 15:09:47 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-01-31 15:09:53 +0100 | <Morrow> | since you sessentially have sequence [a,b] = (\x -> a x : (\y -> b y : (\z -> []) y) x) |
| 2022-01-31 15:11:48 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-31 15:14:40 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:7942:5c67:99d0:7a74) |
| 2022-01-31 15:15:44 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.4) |
| 2022-01-31 15:16:00 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) |
| 2022-01-31 15:16:36 +0100 | <Morrow> | Although now I'm not so sure about that |
| 2022-01-31 15:17:56 +0100 | chenqisu1 | (~chenqisu1@183.217.200.249) (Ping timeout: 256 seconds) |
| 2022-01-31 15:19:33 +0100 | <Morrow> | Actually it seems to make a big difference when optimizations are turned on. |
| 2022-01-31 15:21:57 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 240 seconds) |
| 2022-01-31 15:22:38 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.4) |
| 2022-01-31 15:22:54 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) |
| 2022-01-31 15:25:36 +0100 | <boxscape_> | I suppose that makes sense |
| 2022-01-31 15:27:21 +0100 | tv | (~tv@user/tv) (Ping timeout: 256 seconds) |
| 2022-01-31 15:30:09 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 15:30:12 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Quit: leaving) |
| 2022-01-31 15:30:28 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 15:31:20 +0100 | tv | (~tv@user/tv) |
| 2022-01-31 15:33:24 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 15:33:24 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 15:33:24 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 15:33:26 +0100 | <Profpatsch> | ANy better way to convert a Map into a HashMap than going (HashMap.fromList . Map.toList)? |
| 2022-01-31 15:34:16 +0100 | <geekosaur> | nope. they're completely different structures, there's no shortcut to conversion |
| 2022-01-31 15:34:42 +0100 | <Guillaum[m]> | Profpatsch: I don't think so. You may want to use `fold` and `HashMap.insert`, but it won't be dramatically different. |
| 2022-01-31 15:34:58 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) |
| 2022-01-31 15:35:02 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2022-01-31 15:35:06 +0100 | <Profpatsch> | geekosaur: But conversion e.g. with foldMapWithKey is probably pretty similar? |
| 2022-01-31 15:35:33 +0100 | <geekosaur> | yes. you're still going through an intermediate, it's just hidden inside the fold |
| 2022-01-31 15:35:46 +0100 | <Profpatsch> | I guess it’s hard to know and I need to benchmark it if it ever becomes a speed problem |
| 2022-01-31 15:35:54 +0100 | <geekosaur> | either way you're building a completely different structure from the original |
| 2022-01-31 15:36:00 +0100 | <Profpatsch> | Or just convert to a builder directly |
| 2022-01-31 15:36:21 +0100 | <Profpatsch> | Oh but it will only recurse to the level of keys anyway and leave the values untouched |
| 2022-01-31 15:36:24 +0100 | <Profpatsch> | so it’s not a deep copy |
| 2022-01-31 15:38:30 +0100 | <boxscape_> | Is there a way to kill a thread harder than with killThread? |
| 2022-01-31 15:38:50 +0100 | <boxscape_> | in particular when the thread in question is blocked at the moment |
| 2022-01-31 15:39:49 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 15:39:58 +0100 | hueso | (~root@user/hueso) |
| 2022-01-31 15:40:34 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 15:41:33 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 15:42:06 +0100 | <boxscape_> | hm from I can find it seems like the answer is probably no |
| 2022-01-31 15:44:21 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 256 seconds) |
| 2022-01-31 15:48:45 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2022-01-31 15:49:40 +0100 | deadmarshal | (~deadmarsh@95.38.114.109) (Ping timeout: 256 seconds) |
| 2022-01-31 15:50:24 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-01-31 15:51:49 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) (Ping timeout: 240 seconds) |
| 2022-01-31 15:51:54 +0100 | hueso | (~root@user/hueso) |
| 2022-01-31 15:53:30 +0100 | cods | (~fred@82-65-232-44.subs.proxad.net) |
| 2022-01-31 15:57:04 +0100 | max22- | (~maxime@2a01cb08833598004ac57d9f58d5074f.ipv6.abo.wanadoo.fr) |
| 2022-01-31 15:57:04 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Read error: Connection reset by peer) |
| 2022-01-31 15:58:45 +0100 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2022-01-31 15:58:46 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) |
| 2022-01-31 15:59:25 +0100 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-01-31 15:59:50 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2022-01-31 16:03:05 +0100 | hueso | (~root@user/hueso) |
| 2022-01-31 16:04:24 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 16:05:02 +0100 | hueso | (~root@user/hueso) (Client Quit) |
| 2022-01-31 16:06:54 +0100 | <Guillaum[m]> | Profpatsch: The keys and values will be shared between both structures, but the spine of the structures will be totally different. |
| 2022-01-31 16:07:11 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 16:08:11 +0100 | hueso | (~root@user/hueso) |
| 2022-01-31 16:08:22 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-01-31 16:08:41 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) |
| 2022-01-31 16:10:19 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-01-31 16:11:33 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 16:13:53 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) (Ping timeout: 250 seconds) |
| 2022-01-31 16:16:35 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-31 16:16:35 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-31 16:16:35 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-31 16:16:54 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-31 16:17:24 +0100 | <RMSBach> | Isn't Map -> HashMap an apomorphism? I'm a bit rusty on my barbed wire and bananas though... |
| 2022-01-31 16:18:55 +0100 | <RMSBach> | Well, its probably a natural transformation too, but that isn't surprising. Sorry Profpatsch I'm not being very useful or practical |
| 2022-01-31 16:20:01 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-31 16:20:50 +0100 | flipchan | (~filip@user/flipchan) (Ping timeout: 256 seconds) |
| 2022-01-31 16:21:11 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-01-31 16:21:50 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-01-31 16:27:19 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-01-31 16:27:26 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) (Ping timeout: 256 seconds) |
| 2022-01-31 16:30:29 +0100 | <boxscape_> | hmm I wonder why the type of replicateM was changed to use Applicative, but the type of sequence still uses Monad |
| 2022-01-31 16:31:44 +0100 | <geekosaur> | it's a mishmash |
| 2022-01-31 16:31:52 +0100 | <boxscape_> | fun |
| 2022-01-31 16:31:57 +0100 | <geekosaur> | some things got changed, some got alternatives (e.g. sequenceA) |
| 2022-01-31 16:32:07 +0100 | <byorgey> | I guess because we already had sequenceA but we didn't have replicateA? |
| 2022-01-31 16:32:11 +0100 | <byorgey> | not that that's a good reason |
| 2022-01-31 16:33:26 +0100 | <boxscape_> | hm I suppose that would explain it |
| 2022-01-31 16:37:19 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) |
| 2022-01-31 16:38:01 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) |
| 2022-01-31 16:39:14 +0100 | Codaraxis__ | (~Codaraxis@user/codaraxis) |
| 2022-01-31 16:40:49 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) (Remote host closed the connection) |
| 2022-01-31 16:41:09 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) |
| 2022-01-31 16:41:48 +0100 | Codaraxis_ | (~Codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-01-31 16:43:00 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) (Remote host closed the connection) |
| 2022-01-31 16:43:17 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-01-31 16:44:04 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-01-31 16:45:34 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) (Ping timeout: 256 seconds) |
| 2022-01-31 16:46:02 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) |
| 2022-01-31 16:46:52 +0100 | slack1256 | (~slack1256@186.11.113.101) |
| 2022-01-31 16:48:44 +0100 | <slack1256> | When is recomended to run `+RTS -A32m -n8m --RTS` instead of bare `+RTS -A32m --RTS`. Asking in another way, how does separating the allocation area in chunk sizes help with threaded programs performance? |
| 2022-01-31 16:50:05 +0100 | Codaraxis__ | (~Codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-01-31 16:52:01 +0100 | dut | (~dut@user/dut) (Ping timeout: 250 seconds) |
| 2022-01-31 16:52:27 +0100 | wavemode | (~wavemode@c-98-223-145-19.hsd1.il.comcast.net) |
| 2022-01-31 16:54:55 +0100 | <[exa]> | slack1256: it eliminates false sharing |
| 2022-01-31 16:55:15 +0100 | jgeerds_ | (~jgeerds@55d4a547.access.ecotel.net) |
| 2022-01-31 16:56:46 +0100 | cstml | (~cstml@user/cstml) (Quit: Connection closed) |
| 2022-01-31 16:56:49 +0100 | <Guillaum[m]> | https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/runtime_control.html#rts-flag--n%20… there are details here, but [exa] I'm not sure it improves false sharing, because as I understand documentation, threads are always given a separate allocation area. |
| 2022-01-31 16:58:17 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-31 16:58:30 +0100 | alp | (~alp@user/alp) |
| 2022-01-31 16:58:36 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 17:00:09 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) |
| 2022-01-31 17:03:08 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Ping timeout: 256 seconds) |
| 2022-01-31 17:03:24 +0100 | <Guillaum[m]> | I tried to run a program with `-A100M -N1` and `-N8` and indeed, first program consumns 100M, when the other consums 800M (as stated by +RTS -s) |
| 2022-01-31 17:05:18 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 17:06:42 +0100 | <Guillaum[m]> | slack1256: now back to your question. Imagine you have 2 threads, the first one is not allocating much, when the second one is allocating a lot. When the 32m of the second one will be exhausted, a GC will happen, when actually only half of the allocation space was used. Now split that in chunks of 8mega, you have 8 chunks. thread 2 will consumns 7 chunks (so 7/8 of the available allocation area) before triggering a collection. There is a |
| 2022-01-31 17:06:43 +0100 | <Guillaum[m]> | bit more CPU used to dispatch chunks, but that not a lot. |
| 2022-01-31 17:07:00 +0100 | <slack1256> | Guillaum[m]: Just to be clear, I am asking about the lower case -n option though. |
| 2022-01-31 17:07:41 +0100 | <slack1256> | OK, you are clear on that. Give me a sec to read what you wrote. |
| 2022-01-31 17:08:58 +0100 | <slack1256> | Is the allocation area (-A) common for all the capabilities? |
| 2022-01-31 17:09:14 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Remote host closed the connection) |
| 2022-01-31 17:09:42 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-31 17:09:55 +0100 | <Guillaum[m]> | slack1256: my little experiment above let me think that there is a different allocation area for each capability. |
| 2022-01-31 17:10:12 +0100 | <boxscape_> | I just accidentally wrote code where it doesn't make a difference whether you use $ or <$>, was confused for a minute https://paste.tomsmeding.com/jMW5XzhZ |
| 2022-01-31 17:12:46 +0100 | <Guillaum[m]> | slack1256: you can have a similar effect (i.e. less GC) by increasing `-A`, but it will use more memory. |
| 2022-01-31 17:12:56 +0100 | <slack1256> | That was what I thought too. So I don't see how chunking each separate allocation area will help. I mean, the second capability allocation area is now chunked at the 4m. It still consumes the 32M faster than the first capability. |
| 2022-01-31 17:13:49 +0100 | <Guillaum[m]> | slack1256: I think that all the chunks are now avaialbel in a shared pool. So one capability can now use all of them. |
| 2022-01-31 17:14:06 +0100 | <slack1256> | Ooooh, that would be indeed helpful! |
| 2022-01-31 17:15:00 +0100 | <slack1256> | Also, you could set the chunks to be the size of your L2-cache. |
| 2022-01-31 17:16:38 +0100 | flipchan | (~filip@188-169-255-31.dsl.utg.ge) (Changing host) |
| 2022-01-31 17:16:38 +0100 | flipchan | (~filip@user/flipchan) |
| 2022-01-31 17:16:56 +0100 | <Guillaum[m]> | I'm not sure it may have an impact on performance. chunks are written linearly (so you don't really care about it being in cache) and are read randomly. |
| 2022-01-31 17:17:20 +0100 | <Guillaum[m]> | (sorry, need to go, nice technical discussion, I learned a few things will trying to answer your question, I appreciate that). |
| 2022-01-31 17:19:57 +0100 | max22- | (~maxime@2a01cb08833598004ac57d9f58d5074f.ipv6.abo.wanadoo.fr) (Remote host closed the connection) |
| 2022-01-31 17:20:02 +0100 | mbuf | (~Shakthi@136.185.77.246) (Quit: Leaving) |
| 2022-01-31 17:20:42 +0100 | max22- | (~maxime@lfbn-ren-1-1026-62.w92-139.abo.wanadoo.fr) |
| 2022-01-31 17:21:31 +0100 | <slack1256> | Guillaum[m]: Thanks to you too. |
| 2022-01-31 17:22:48 +0100 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat) |
| 2022-01-31 17:23:59 +0100 | Katarushisu | (~Katarushi@cpc147334-finc20-2-0-cust27.4-2.cable.virginm.net) |
| 2022-01-31 17:25:14 +0100 | <[exa]> | slack1256: basically I meant that there's a bit of delay whenever you need to exclusively access a page on a CPU after another CPU used it, so if you have more threads writing to the same location, the chance for these delays are expectably high (consider multithread garbage collection in this regard). I guess that adding chunks prevents this kind of race on the chunk headers (or generally any such |
| 2022-01-31 17:25:20 +0100 | <[exa]> | hotspots) |
| 2022-01-31 17:29:09 +0100 | max22- | (~maxime@lfbn-ren-1-1026-62.w92-139.abo.wanadoo.fr) (Remote host closed the connection) |
| 2022-01-31 17:31:34 +0100 | aeka | (~aeka@2606:6080:1001:18:8d41:9604:d435:36b6) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-01-31 17:31:54 +0100 | aeka | (~aeka@user/hiruji) |
| 2022-01-31 17:32:01 +0100 | jaror[m] | (~jaror@2001:470:69fc:105::265) |
| 2022-01-31 17:35:13 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:db29:cb0:7e70:ac05) (Ping timeout: 268 seconds) |
| 2022-01-31 17:35:20 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 17:39:37 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Ping timeout: 240 seconds) |
| 2022-01-31 17:41:24 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 17:44:08 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds) |
| 2022-01-31 17:44:44 +0100 | emf | (~emf@162.218.217.186) |
| 2022-01-31 17:47:00 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-01-31 17:47:03 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) |
| 2022-01-31 17:48:44 +0100 | emf_ | (~emf@163.114.132.4) |
| 2022-01-31 17:49:28 +0100 | arjun | (~arjun@user/arjun) (Remote host closed the connection) |
| 2022-01-31 17:49:48 +0100 | emf | (~emf@162.218.217.186) (Ping timeout: 256 seconds) |
| 2022-01-31 17:55:18 +0100 | chomwitt | (~chomwitt@2a02:587:dc03:8900:12c3:7bff:fe6d:d374) (Ping timeout: 250 seconds) |
| 2022-01-31 17:56:05 +0100 | chomwitt | (~chomwitt@2a02:587:dc03:8900:12c3:7bff:fe6d:d374) |
| 2022-01-31 17:59:53 +0100 | jgeerds_ | (~jgeerds@55d4a547.access.ecotel.net) (Ping timeout: 268 seconds) |
| 2022-01-31 18:00:33 +0100 | econo | (uid147250@user/econo) |
| 2022-01-31 18:00:53 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 18:01:27 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 276 seconds) |
| 2022-01-31 18:01:50 +0100 | <albet70> | for example, main = scotty 80 $ do {get "/test" $ doSomething} , every GET requests will let doSomething run, could save the variable doSomething out of it? so that all the variable can be get? |
| 2022-01-31 18:02:44 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Remote host closed the connection) |
| 2022-01-31 18:03:06 +0100 | <albet70> | with other languages, it would use global variable to archive, for example, set a global list variable, so every doSomething save its inner variable to that list |
| 2022-01-31 18:04:42 +0100 | lbseale | (~ep1ctetus@user/ep1ctetus) |
| 2022-01-31 18:07:06 +0100 | max22- | (~maxime@lfbn-ren-1-1026-62.w92-139.abo.wanadoo.fr) |
| 2022-01-31 18:07:46 +0100 | fruitfly | (~fruitfly@host-79-121-42-70.kabelnet.hu) |
| 2022-01-31 18:08:40 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) |
| 2022-01-31 18:08:41 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) |
| 2022-01-31 18:09:29 +0100 | dust_ | (~dust@2405:204:5488:ef4c:54b6:3467:52f3:e9f2) (Quit: Konversation terminated!) |
| 2022-01-31 18:12:52 +0100 | <fruitfly> | Hi, can I ask about this: |
| 2022-01-31 18:12:53 +0100 | <fruitfly> | Prelude> :t elem |
| 2022-01-31 18:12:53 +0100 | <fruitfly> | elem :: (Foldable t, Eq a) => a -> t a -> Bool |
| 2022-01-31 18:12:54 +0100 | <fruitfly> | Does "t a" mean a list? I find it a bit weird, it looks as though it where two parameters. |
| 2022-01-31 18:12:58 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 18:13:09 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 276 seconds) |
| 2022-01-31 18:13:27 +0100 | <Rembane> | fruitfly: It's a list written in a strange way. |
| 2022-01-31 18:13:36 +0100 | yauhsien_ | (~yauhsien@61-231-37-18.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 18:14:14 +0100 | <Rembane> | fruitfly: On a more formal level, t is anything that has an instance of the Foldable typeclass. List has an instance of the Foldable typeclass. |
| 2022-01-31 18:14:20 +0100 | neurocyte0917090 | (~neurocyte@IP-045143076117.dynamic.medianet-world.de) |
| 2022-01-31 18:14:20 +0100 | neurocyte0917090 | (~neurocyte@IP-045143076117.dynamic.medianet-world.de) (Changing host) |
| 2022-01-31 18:14:20 +0100 | neurocyte0917090 | (~neurocyte@user/neurocyte) |
| 2022-01-31 18:14:21 +0100 | <geekosaur> | % :t elem @[] |
| 2022-01-31 18:14:22 +0100 | <yahb> | geekosaur: Eq a => a -> [a] -> Bool |
| 2022-01-31 18:14:43 +0100 | <geekosaur> | there I filled in the list type as "t" |
| 2022-01-31 18:14:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-31 18:15:37 +0100 | <fruitfly> | Thank you! |
| 2022-01-31 18:15:50 +0100 | sa1_ | sa1 |
| 2022-01-31 18:16:19 +0100 | <geekosaur> | % :t elem @S.Set |
| 2022-01-31 18:16:19 +0100 | <yahb> | geekosaur: Eq a => a -> S.Set a -> Bool |
| 2022-01-31 18:16:28 +0100 | <geekosaur> | since Set is also a member of Foldable |
| 2022-01-31 18:16:37 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-31 18:16:58 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 18:17:15 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) |
| 2022-01-31 18:17:43 +0100 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-01-31 18:21:20 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Ping timeout: 256 seconds) |
| 2022-01-31 18:22:12 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2022-01-31 18:24:35 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-01-31 18:25:36 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-01-31 18:27:09 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-01-31 18:27:20 +0100 | jao | (~jao@static-68-235-44-23.cust.tzulo.com) |
| 2022-01-31 18:27:49 +0100 | sagax | (~sagax_nb@user/sagax) |
| 2022-01-31 18:28:00 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 18:28:46 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-31 18:32:16 +0100 | russruss | (~russruss@my.russellmcc.com) (Quit: The Lounge - https://thelounge.chat) |
| 2022-01-31 18:34:06 +0100 | russruss | (~russruss@my.russellmcc.com) |
| 2022-01-31 18:34:55 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 18:37:55 +0100 | Guest4442 | (~Guest44@77.222.105.50) (Quit: Client closed) |
| 2022-01-31 18:38:13 +0100 | AWizzArd | (~code@gehrels.uberspace.de) (Changing host) |
| 2022-01-31 18:38:13 +0100 | AWizzArd | (~code@user/awizzard) |
| 2022-01-31 18:38:56 +0100 | boxscape_ | (~boxscape_@p4ff0b9d5.dip0.t-ipconnect.de) (Quit: Connection closed) |
| 2022-01-31 18:38:57 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-01-31 18:40:15 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:5d4f:b362:d270:61b0) |
| 2022-01-31 18:41:12 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 268 seconds) |
| 2022-01-31 18:41:33 +0100 | <segfaultfizzbuzz> | for nonstrict/lazy evaluation, is it possible to have your cake and eat it too? by that i mean, can i have many/most of the benefits of laziness but operate a system where the performance impact is provably no worse than a strict evaluation approach? |
| 2022-01-31 18:41:52 +0100 | <segfaultfizzbuzz> | or is it an inherent trade-off, that laziness simply has a performance overhead |
| 2022-01-31 18:42:24 +0100 | <dsal> | laziness isn't opposed to efficiency. |
| 2022-01-31 18:42:46 +0100 | burnsidesLlama | (~burnsides@dhcp168-030.wadham.ox.ac.uk) |
| 2022-01-31 18:44:00 +0100 | fruitfly | (~fruitfly@host-79-121-42-70.kabelnet.hu) (Ping timeout: 256 seconds) |
| 2022-01-31 18:44:07 +0100 | Topsi | (~Tobias@dyndsl-095-033-094-250.ewe-ip-backbone.de) |
| 2022-01-31 18:44:31 +0100 | <kuribas> | segfaultfizzbuzz: define "performance impact". I don't think lazyness is going to matter significantly over other factors. |
| 2022-01-31 18:44:51 +0100 | <Andrew> | Laziness => efficency for some programs |
| 2022-01-31 18:44:59 +0100 | <Andrew> | And laziness does mean more memory usage |
| 2022-01-31 18:45:12 +0100 | <segfaultfizzbuzz> | well with strictness when i ask for a value, it will have already been evaluated |
| 2022-01-31 18:45:14 +0100 | <maerwald> | it can also mean worse performance |
| 2022-01-31 18:45:18 +0100 | <segfaultfizzbuzz> | but with laziness, if i ask for a value, i may need to wait |
| 2022-01-31 18:45:19 +0100 | <kuribas> | Andrew: Not necessarily |
| 2022-01-31 18:45:27 +0100 | <Andrew> | kuribas: I know |
| 2022-01-31 18:45:32 +0100 | <maerwald> | but this is so general, there's no clear answer |
| 2022-01-31 18:45:37 +0100 | <Andrew> | Generally, for large thunks |
| 2022-01-31 18:46:17 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 18:46:18 +0100 | alx741 | (~alx741@157.100.197.240) (Quit: alx741) |
| 2022-01-31 18:46:21 +0100 | <segfaultfizzbuzz> | meaning that to achieve laziness much of the benefit comes from calculating things after they are requested |
| 2022-01-31 18:46:33 +0100 | alx741 | (~alx741@157.100.197.240) |
| 2022-01-31 18:46:44 +0100 | <maerwald> | the performance problem with laziness is that it can cause memory allocations in hot loops, which are unnecessary |
| 2022-01-31 18:47:12 +0100 | <maerwald> | you can easily throw ram at all other problems, but not at this one |
| 2022-01-31 18:48:11 +0100 | Sgeo_ | (~Sgeo@user/sgeo) |
| 2022-01-31 18:48:27 +0100 | <maerwald> | and strict evaluation can calculate an entire subcomputation that's not needed |
| 2022-01-31 18:49:07 +0100 | <maerwald> | IME, the latter is easier to find and reason about |
| 2022-01-31 18:49:20 +0100 | <maerwald> | unless you don't understand your own algorithm |
| 2022-01-31 18:49:39 +0100 | <maerwald> | the laziness problem is only solvable via debugging |
| 2022-01-31 18:50:13 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 256 seconds) |
| 2022-01-31 18:50:52 +0100 | <maerwald> | there are also some edge cases where laziness allows much better optimizations (e.g. in lens library) |
| 2022-01-31 18:51:22 +0100 | <maerwald> | for most programs, it's usually not worth it |
| 2022-01-31 18:53:48 +0100 | Megant | (megant@user/megant) (Ping timeout: 250 seconds) |
| 2022-01-31 18:55:42 +0100 | Megant | (megant@user/megant) |
| 2022-01-31 18:57:57 +0100 | neverfindme | (~hayden@158.123.160.43) |
| 2022-01-31 18:59:37 +0100 | neverfindme | (~hayden@158.123.160.43) (Max SendQ exceeded) |
| 2022-01-31 19:00:02 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-31 19:00:16 +0100 | neverfindme | (~hayden@158.123.160.43) |
| 2022-01-31 19:01:41 +0100 | <segfaultfizzbuzz> | ok thanks (bbiab) |
| 2022-01-31 19:01:49 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:5d4f:b362:d270:61b0) (Quit: Leaving) |
| 2022-01-31 19:02:31 +0100 | neverfindme | (~hayden@158.123.160.43) (Client Quit) |
| 2022-01-31 19:02:48 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-01-31 19:03:47 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:7942:5c67:99d0:7a74) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-31 19:04:21 +0100 | <polyphem> | albet70: main = do sharedVar <- newTVarIO Nothing ; _ <- forkIO (taskA sharedVar) ; scotty 80 $ do {get "/test" $ doSomething sharedVar } |
| 2022-01-31 19:04:29 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-01-31 19:04:37 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-31 19:06:17 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-01-31 19:06:52 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 256 seconds) |
| 2022-01-31 19:07:43 +0100 | MajorBiscuit | (~MajorBisc@c-001-028-049.client.tudelft.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-01-31 19:08:35 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 19:09:42 +0100 | <dminuoso> | 18:42:24 dsal | laziness isn't opposed to efficiency. |
| 2022-01-31 19:09:57 +0100 | shailangsa | (~shailangs@host86-185-98-37.range86-185.btcentralplus.com) |
| 2022-01-31 19:10:10 +0100 | <dminuoso> | Mmm, if that was accurate, the inability to predict performance wouldn't be such an ubiquitous topic in all the Haskell discussion forums. |
| 2022-01-31 19:10:19 +0100 | <dminuoso> | Even amongst more experienced Haskellers. |
| 2022-01-31 19:10:34 +0100 | <dsal> | Yeah, but the answer isn't "make everything strict" |
| 2022-01-31 19:10:54 +0100 | <geekosaur> | I also wouldn;t say opposed to. I would say "makes much harder to reason about" |
| 2022-01-31 19:11:03 +0100 | <dsal> | Sometimes laziness helps. Sometimes it makes it weird and confusing. |
| 2022-01-31 19:11:07 +0100 | deadmarshal | (~deadmarsh@95.38.228.65) |
| 2022-01-31 19:11:22 +0100 | <c_wraith> | you can learn to understand Haskell performance |
| 2022-01-31 19:11:40 +0100 | <c_wraith> | it mostly comes down to learning how to write code that doesn't break things. |
| 2022-01-31 19:12:12 +0100 | <dminuoso> | When you have to learn how to write code that pleases the current flavour of combinations in the GHC simplifier for your current versions, I'm not convinced this is a viable strategy. |
| 2022-01-31 19:12:27 +0100 | <c_wraith> | unfortunately there isn't compiler support for getting it right, and that's a huge issue in a language that depends on the compiler to tell you so much |
| 2022-01-31 19:12:41 +0100 | <dminuoso> | As it is right now, I cant even have guaranteed sharing. Say writing `let a = ... a ... a` does not guarantee sharing - I lack the tools to guide the implementations. |
| 2022-01-31 19:14:15 +0100 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2022-01-31 19:14:30 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 268 seconds) |
| 2022-01-31 19:14:38 +0100 | <c_wraith> | Haskell doesn't guarantee that - Haskell doesn't even guarantee lazy evaluation. I'm pretty sure GHC guarantees it |
| 2022-01-31 19:14:53 +0100 | <maerwald> | dsal: the times where I thought "thank god Haskell is lazy, otherwise my program would be slow now" is probably zero, except for various libraries that rely on all the optimization tricks |
| 2022-01-31 19:15:13 +0100 | <dminuoso> | If memory serves right, GHC developers told me that no assurances can be made. |
| 2022-01-31 19:15:44 +0100 | <dminuoso> | The point Im making here is, it all relis on some specific knowledge of GHC internals that may very well differ between versions. |
| 2022-01-31 19:15:44 +0100 | <geekosaur> | everyone is convinced laziness is evil and should be banned :( |
| 2022-01-31 19:15:54 +0100 | <c_wraith> | honestly, I think GHC's strictness analysts was an error |
| 2022-01-31 19:15:55 +0100 | pgib | (~textual@173.38.117.89) |
| 2022-01-31 19:16:15 +0100 | <kuribas> | geekosaur: I think optional lazyness is nice. |
| 2022-01-31 19:16:19 +0100 | <c_wraith> | it lets people write bad code and have it still work |
| 2022-01-31 19:16:26 +0100 | <maerwald> | geekosaur: no, I think we need better ideas about how to mix both concepts |
| 2022-01-31 19:16:38 +0100 | <c_wraith> | *analysis |
| 2022-01-31 19:16:40 +0100 | <maerwald> | in a way that makes the code not insane spaghetti chaos |
| 2022-01-31 19:16:41 +0100 | <geekosaur> | you sure don't sound like it |
| 2022-01-31 19:16:45 +0100 | <dminuoso> | geekosaur: Im not saying its fundamentally broken, just that it's very incompatible with reasonable expectations of performance analysis. |
| 2022-01-31 19:16:45 +0100 | <wavemode> | Most people come to realize that it's easier to reason about performance when you write strict code by default and only use laziness where it's desirable, than when writing lazy code by default |
| 2022-01-31 19:16:53 +0100 | <geekosaur> | every time laziness comes up you're all over how laziness was a mistake |
| 2022-01-31 19:17:09 +0100 | <kuribas> | geekosaur: the benefits of lazyness aren't that big. |
| 2022-01-31 19:17:10 +0100 | <dminuoso> | It's certainly convenient for writing expressive code, as long as you dont mind about performance too much. And yes, you can write highly performant code, but that's almost an art. |
| 2022-01-31 19:17:16 +0100 | <geekosaur> | you even posted links about how laziness was so much of an error in so many places |
| 2022-01-31 19:17:23 +0100 | <c_wraith> | wavemode: it can't work that way, though. opt-in laziness is the same as no laziness |
| 2022-01-31 19:17:29 +0100 | <maerwald> | geekosaur: aha |
| 2022-01-31 19:17:55 +0100 | <maerwald> | I literally just said that laziness facilitates certain optimizations |
| 2022-01-31 19:18:04 +0100 | <kuribas> | I even managed to get self-recursive parser combinators working in clojure :) |
| 2022-01-31 19:18:16 +0100 | <c_wraith> | so many libraries get on the strictness cargo cult that they break code using them correctly |
| 2022-01-31 19:18:19 +0100 | <maerwald> | and libraries like lens and streamly rely on those tricks |
| 2022-01-31 19:18:27 +0100 | <maerwald> | but that's not what most programmers want or need |
| 2022-01-31 19:18:36 +0100 | <c_wraith> | because they can't imagine people using laziness vorrectly |
| 2022-01-31 19:18:42 +0100 | <dminuoso> | wavemode: The problem is just lazyness doesnt work well in a strict-by-default language, it makes writing modular code much more comfortable. |
| 2022-01-31 19:18:44 +0100 | <c_wraith> | or correctly, for that matter |
| 2022-01-31 19:19:13 +0100 | <kuribas> | dminuoso: also not if the language insert "force" for you? |
| 2022-01-31 19:19:18 +0100 | <kuribas> | and "delay"? |
| 2022-01-31 19:19:27 +0100 | <dminuoso> | Something that was suggested a few times before, is something like levity polymorphism or multiplicity polymorphism but for strictness. |
| 2022-01-31 19:19:43 +0100 | <dminuoso> | Such that the type system would track and infer for you, but would at the same time be tractable. |
| 2022-01-31 19:19:57 +0100 | <dminuoso> | (Or perhaps a separate, orthogonal type system) |
| 2022-01-31 19:20:15 +0100 | <dminuoso> | Has this been explored in some languages before? |
| 2022-01-31 19:20:18 +0100 | <wavemode> | I do often wish laziness were part of the type system somehow, yeah |
| 2022-01-31 19:20:23 +0100 | <geekosaur> | uh, dminuoso who's wavemode? |
| 2022-01-31 19:20:29 +0100 | <geekosaur> | oh, sorry, missed that |
| 2022-01-31 19:20:33 +0100 | <kuribas> | dminuoso: would that even be possible? How do you know if a value is intended lazyly or strictly? |
| 2022-01-31 19:20:52 +0100 | <dminuoso> | kuribas: Same as with any polymorphism - callers/consumers choice. |
| 2022-01-31 19:21:04 +0100 | <c_wraith> | I just don't want to have correct code made impossible by other programmer's lack of imagination |
| 2022-01-31 19:21:04 +0100 | <dminuoso> | I dont know the details because I havent actually done this. |
| 2022-01-31 19:21:20 +0100 | <kuribas> | dminuoso: that implies explicit "force"? |
| 2022-01-31 19:21:34 +0100 | <dminuoso> | kuribas: I dont know what that implies. Let a PhD student figure this out. |
| 2022-01-31 19:21:38 +0100 | <c_wraith> | any kind of opt-in laziness results in my being at the mercy of others' imagination |
| 2022-01-31 19:22:53 +0100 | <maerwald> | dminuoso: my fear is that such a system would be very complicated and make it hard to correctly use libraries, because now you need to know that some functoins don't behave very well lazy/strict etc. I mean we already have this problem and hope library maintainers figure it out... but if the caller has to figure it out |
| 2022-01-31 19:22:56 +0100 | <maerwald> | uff |
| 2022-01-31 19:23:18 +0100 | <dminuoso> | maerwald: See, this is why we should have some poor PhD spend 5 years of his or her life on this, to tell us whether its truly complicated or not. |
| 2022-01-31 19:23:31 +0100 | <dminuoso> | That's what PhD students are for, no? |
| 2022-01-31 19:23:57 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-01-31 19:23:57 +0100 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) |
| 2022-01-31 19:23:58 +0100 | <maerwald> | I think this topic will lead to at least a couple of burnt out students |
| 2022-01-31 19:24:03 +0100 | <maerwald> | but it's for the greater good |
| 2022-01-31 19:24:16 +0100 | <maerwald> | a few smashed dreams, that's ok |
| 2022-01-31 19:24:38 +0100 | <dminuoso> | You're acting as if SPJ and friends haven't burned out a couple students before. :p |
| 2022-01-31 19:26:03 +0100 | <EvanR> | is "strict almost everything" and "lazy almost everything" really silly positions to take when my program relies on laziness to work remotely right, while the compiler uses strictness analysis to strictfy a zillion things and give me even more performance |
| 2022-01-31 19:26:20 +0100 | <kuribas> | dminuoso: idris has opt in lazyness. |
| 2022-01-31 19:26:35 +0100 | <EvanR> | you can't write idris anywhere like haskell |
| 2022-01-31 19:26:38 +0100 | <EvanR> | because of that |
| 2022-01-31 19:27:04 +0100 | <EvanR> | strict almost everything and NOT that maybe too incompatible universes of programming mentality |
| 2022-01-31 19:27:32 +0100 | sus | (zero@user/zeromomentum) (Quit: Ping timeout (120 seconds)) |
| 2022-01-31 19:27:44 +0100 | sus | (zero@user/zeromomentum) |
| 2022-01-31 19:27:49 +0100 | <EvanR> | strict almost everything seems to kind of defeat the purpose of haskell even |
| 2022-01-31 19:27:58 +0100 | <EvanR> | many other languages exist, ocaml xD |
| 2022-01-31 19:28:37 +0100 | <wavemode> | you're right, we should all switch to ocaml |
| 2022-01-31 19:28:39 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) (Remote host closed the connection) |
| 2022-01-31 19:28:39 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.4) |
| 2022-01-31 19:29:06 +0100 | <kuribas> | EvanR: well, idris borrows a lot from haskell. |
| 2022-01-31 19:29:17 +0100 | <kuribas> | EvanR: and even then not enough IMO :) |
| 2022-01-31 19:29:31 +0100 | alx741 | (~alx741@157.100.197.240) (Quit: leaving) |
| 2022-01-31 19:30:54 +0100 | <EvanR> | I'm thinking there are wildly different ways to use haskell, like, blue collar web code may be entirely made of monad transformers, and laziness may seem ridiculous to crunch a web request (lazy I/O not being sane, so you used a streaming library) |
| 2022-01-31 19:31:23 +0100 | <EvanR> | or less crunchy settings could get away with being more mathlike and composable |
| 2022-01-31 19:34:18 +0100 | romesrf | (~romes@44.190.189.46.rev.vodafone.pt) |
| 2022-01-31 19:34:22 +0100 | <romesrf> | o/ |
| 2022-01-31 19:36:21 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-01-31 19:37:02 +0100 | MatthiasG2 | (~matthias@i6DFA01BB.versanet.de) |
| 2022-01-31 19:40:07 +0100 | <monochrom> | But I don't like the argument order of OCaml's foldl and foldr! |
| 2022-01-31 19:40:39 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-01-31 19:43:24 +0100 | polyphem_ | (~rod@2a02:810d:840:8754:5126:c335:5f23:8358) |
| 2022-01-31 19:44:14 +0100 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) (Quit: I'm gonna win SETI@home.) |
| 2022-01-31 19:44:57 +0100 | <maerwald> | you'll like it after a bank throws 300k at you |
| 2022-01-31 19:45:11 +0100 | polyphem | (~rod@2a02:810d:840:8754:a057:eb16:35f3:4c79) (Ping timeout: 252 seconds) |
| 2022-01-31 19:45:51 +0100 | <geekosaur> | or not |
| 2022-01-31 19:46:41 +0100 | <EvanR> | s/ocaml/purescript/ |
| 2022-01-31 19:46:51 +0100 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2022-01-31 19:51:14 +0100 | xkuru | (~xkuru@user/xkuru) |
| 2022-01-31 19:54:35 +0100 | <maerwald> | is there a library for emitting diffs of two Texts? like `diff -u` |
| 2022-01-31 19:57:03 +0100 | michalz | (~michalz@185.246.204.57) (Ping timeout: 250 seconds) |
| 2022-01-31 19:58:04 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-31 20:00:47 +0100 | <EvanR> | hmm https://hackage.haskell.org/package/Diff-0.3.2/docs/Data-Algorithm-Diff.html |
| 2022-01-31 20:01:08 +0100 | <EvanR> | well that's a link to an older version |
| 2022-01-31 20:01:38 +0100 | <maerwald> | that doesn't diff text well |
| 2022-01-31 20:01:51 +0100 | <EvanR> | getGroupedDiff :: Eq a => [a] -> [a] -> [Diff [a]] |
| 2022-01-31 20:01:52 +0100 | <maerwald> | https://hackage.haskell.org/package/ormolu-0.4.0.0/docs/src/Ormolu.Diff.Text.html#diffText |
| 2022-01-31 20:01:58 +0100 | <maerwald> | I'll just salvage that |
| 2022-01-31 20:03:28 +0100 | yassernasc | (~yassernas@2804:29b8:505a:f33d:1872:f10d:d91b:b66) (Remote host closed the connection) |
| 2022-01-31 20:05:47 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-01-31 20:15:55 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-31 20:18:37 +0100 | y04nn | (~y04nn@92.223.89.196) (Ping timeout: 256 seconds) |
| 2022-01-31 20:21:32 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-01-31 20:22:48 +0100 | lechner | (~lechner@debian/lechner) (Ping timeout: 256 seconds) |
| 2022-01-31 20:23:56 +0100 | deadmarshal | (~deadmarsh@95.38.228.65) (Ping timeout: 256 seconds) |
| 2022-01-31 20:25:36 +0100 | lechner | (~lechner@debian/lechner) |
| 2022-01-31 20:26:26 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) (Remote host closed the connection) |
| 2022-01-31 20:26:48 +0100 | oscurochu | (~oscurochu@097-096-050-227.res.spectrum.com) |
| 2022-01-31 20:29:07 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) |
| 2022-01-31 20:31:23 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 20:32:20 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-01-31 20:34:45 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-01-31 20:34:48 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Client Quit) |
| 2022-01-31 20:35:05 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-01-31 20:39:48 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 20:41:24 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 20:43:22 +0100 | ensyde | (~ensyde@2600:1700:2050:1040:ac63:f3f7:89ad:2997) |
| 2022-01-31 20:43:27 +0100 | mmhat | (~mmh@55d4f68d.access.ecotel.net) |
| 2022-01-31 20:45:34 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.4) |
| 2022-01-31 20:45:39 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-31 20:46:52 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection) |
| 2022-01-31 20:47:37 +0100 | Guest6735 | (~sam@c-93bfe655.020-348-73746f1.bbcust.telenor.se) |
| 2022-01-31 20:51:00 +0100 | alt-romes | (~romes@44.190.189.46.rev.vodafone.pt) |
| 2022-01-31 20:51:42 +0100 | romesrf | (~romes@44.190.189.46.rev.vodafone.pt) (Ping timeout: 256 seconds) |
| 2022-01-31 20:53:50 +0100 | <Guest6735> | Hi! I'm trying to make a static binary using musl, but it's not really working. I posted my entire question here with details: https://paste.tomsmeding.com/KFupcwRc |
| 2022-01-31 20:54:52 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) (Remote host closed the connection) |
| 2022-01-31 20:55:01 +0100 | Topsi | (~Tobias@dyndsl-095-033-094-250.ewe-ip-backbone.de) (Ping timeout: 268 seconds) |
| 2022-01-31 20:55:16 +0100 | <maerwald> | Guest6735: I wouldn't use that docker image, just a plain alpine image |
| 2022-01-31 20:55:54 +0100 | <geekosaur> | also specifying a compiler version as a resolver is apt to get you fairly old packages. I'd use an appropriate LTS |
| 2022-01-31 20:56:17 +0100 | <maerwald> | Guest6735: here's an example: https://github.com/hasufell/stack2cabal/blob/b18eda25237221b32994910a3bbcc8ee6ad2163a/.github/work… |
| 2022-01-31 20:56:28 +0100 | <maerwald> | it works pretty much the same with stack |
| 2022-01-31 20:58:00 +0100 | <Guest6735> | Thank you both! I'll try both out now. |
| 2022-01-31 20:58:09 +0100 | <maerwald> | --ghc-options='-split-sections -optl-static' is usually enough |
| 2022-01-31 20:58:55 +0100 | <maerwald> | use ghcup in the alpine container to get GHC bindists for stack |
| 2022-01-31 20:58:59 +0100 | <maerwald> | then use --system-ghc |
| 2022-01-31 21:00:07 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-01-31 21:00:43 +0100 | <maerwald> | here's an example of a dockerfile https://gist.github.com/hasufell/f0893abfbba63ac4ea40feb0520946ee |
| 2022-01-31 21:01:47 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-31 21:01:51 +0100 | alt-romes | (~romes@44.190.189.46.rev.vodafone.pt) (Quit: WeeChat 3.4) |
| 2022-01-31 21:02:24 +0100 | <Guest6735> | Thank you, I'm reading the alpine-haskell-stack docs. |
| 2022-01-31 21:04:31 +0100 | rusrushal13 | (~rusrushal@2409:4056:e82:6bda:bd0e:9743:fccb:b2a0) (Ping timeout: 256 seconds) |
| 2022-01-31 21:05:18 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-31 21:08:55 +0100 | vicfred | (~vicfred@user/vicfred) |
| 2022-01-31 21:09:12 +0100 | alp | (~alp@user/alp) (Ping timeout: 268 seconds) |
| 2022-01-31 21:10:01 +0100 | janus | (janus@anubis.0x90.dk) (Quit: CPU quota exceeded) |
| 2022-01-31 21:10:05 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-01-31 21:12:36 +0100 | y04nn | (~y04nn@92.223.89.196) |
| 2022-01-31 21:13:44 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-01-31 21:14:16 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:f579:9b2b:4d0d:2d44) |
| 2022-01-31 21:18:27 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-01-31 21:21:19 +0100 | hololeap | (~hololeap@user/hololeap) (Quit: Bye) |
| 2022-01-31 21:22:26 +0100 | slack1256 | (~slack1256@186.11.113.101) (Remote host closed the connection) |
| 2022-01-31 21:22:55 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2022-01-31 21:24:46 +0100 | <SrPx> | my post about HVM has been filtered on /r/haskell |
| 2022-01-31 21:24:54 +0100 | <SrPx> | does that mean I'm shadow banned!? |
| 2022-01-31 21:25:22 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) (Read error: Connection reset by peer) |
| 2022-01-31 21:25:37 +0100 | Codaraxis | (~Codaraxis@user/codaraxis) |
| 2022-01-31 21:26:10 +0100 | <yushyin> | maybe ask the subreddit mods? |
| 2022-01-31 21:27:55 +0100 | fendor_ | (~fendor@77.119.206.49.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-01-31 21:28:57 +0100 | <EvanR> | HVM? |
| 2022-01-31 21:29:38 +0100 | <dsal> | Haskell's Very Monadic |
| 2022-01-31 21:30:01 +0100 | Akiva | (~Akiva@user/Akiva) |
| 2022-01-31 21:30:07 +0100 | <geekosaur> | github.com/kindelia/hvm I believe |
| 2022-01-31 21:30:46 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-01-31 21:31:25 +0100 | fendor | (~fendor@77.119.206.49.wireless.dyn.drei.com) |
| 2022-01-31 21:32:13 +0100 | <SrPx> | yep, just PM'ed them |
| 2022-01-31 21:32:24 +0100 | <SrPx> | just asked here to check if this is a common issue |
| 2022-01-31 21:33:12 +0100 | <geekosaur> | I have no clue; I rarely visit reddit |
| 2022-01-31 21:33:23 +0100 | <yushyin> | shadow banning and filtering of posts is a very common reddit issue |
| 2022-01-31 21:33:48 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) |
| 2022-01-31 21:34:58 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:5d4f:b362:d270:61b0) |
| 2022-01-31 21:34:59 +0100 | <yushyin> | SrPx: https://www.reddit.com/r/ShadowBan/comments/8a2gpk/an_unofficial_guide_on_how_to_avoid_being/ |
| 2022-01-31 21:35:07 +0100 | <segfaultfizzbuzz> | this was pretty interesting: https://github.com/Kindelia/HVM |
| 2022-01-31 21:35:58 +0100 | <SrPx> | I see, where you get FP news? |
| 2022-01-31 21:36:08 +0100 | <SrPx> | would appreciate ideas about where else I can post HVM |
| 2022-01-31 21:36:18 +0100 | <SrPx> | segfaultfizzbuzz: hm thanks :) |
| 2022-01-31 21:36:48 +0100 | <yushyin> | HN ofc |
| 2022-01-31 21:42:01 +0100 | sprout | (~quassel@2a02:a467:ccd6:1:8844:e45a:1aab:92c2) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-01-31 21:42:51 +0100 | mindwarp | (~mindwarp@sdf.org) |
| 2022-01-31 21:44:15 +0100 | <segfaultfizzbuzz> | SrPx sent me a dm asking if i was "someone they know" ... i have no prior knowledge of SrPx... is SrPx a spammer...? |
| 2022-01-31 21:44:25 +0100 | mindwarp | (~mindwarp@sdf.org) (Client Quit) |
| 2022-01-31 21:44:53 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-31 21:45:02 +0100 | <geekosaur> | no, or at least not previously |
| 2022-01-31 21:45:18 +0100 | <maerwald> | well, that's one way to decline a friendship :D |
| 2022-01-31 21:45:23 +0100 | <[exa]> | what trickery happens here btw? https://github.com/Kindelia/HVM#composition-optimal |
| 2022-01-31 21:46:16 +0100 | <segfaultfizzbuzz> | i have no knowledge of the HVM repo or the person who posted it btw, i am just kinda trying to learn bits and bobs where i can ;-) |
| 2022-01-31 21:46:37 +0100 | <[exa]> | I guess someone forgot a ! somewhere to really measure the same bits |
| 2022-01-31 21:46:40 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-01-31 21:47:00 +0100 | <segfaultfizzbuzz> | lol yeah it's just a strictness annotation issue looks like? |
| 2022-01-31 21:47:50 +0100 | briandaed | (~root@185.234.208.208.r.toneticgroup.pl) |
| 2022-01-31 21:48:41 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-01-31 21:49:10 +0100 | <maerwald> | huh? |
| 2022-01-31 21:49:17 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2022-01-31 21:50:11 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) |
| 2022-01-31 21:51:09 +0100 | briandaed | (~root@185.234.208.208.r.toneticgroup.pl) (Client Quit) |
| 2022-01-31 21:52:54 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 256 seconds) |
| 2022-01-31 21:55:17 +0100 | y04nn | (~y04nn@92.223.89.196) (Ping timeout: 240 seconds) |
| 2022-01-31 22:01:07 +0100 | CHUD | (~CHUD@host-80-41-89-108.as13285.net) |
| 2022-01-31 22:07:52 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-01-31 22:08:41 +0100 | cynomys | (~cynomys@user/cynomys) |
| 2022-01-31 22:09:39 +0100 | pavonia | (~user@user/siracusa) |
| 2022-01-31 22:10:25 +0100 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-01-31 22:10:27 +0100 | <wavemode> | it's not strictness per se, it's the fact that it's doing millions of function compositions |
| 2022-01-31 22:11:10 +0100 | cjb | (~cjb@user/cjb) |
| 2022-01-31 22:11:39 +0100 | doxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-01-31 22:14:00 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-01-31 22:14:10 +0100 | <carbolymer> | % du -h -s .stack |
| 2022-01-31 22:14:10 +0100 | <carbolymer> | 38G .stack |
| 2022-01-31 22:14:10 +0100 | <carbolymer> | ah yes, node_modules successor |
| 2022-01-31 22:14:10 +0100 | <yahb> | carbolymer: ; <interactive>:18:1: error:; * Variable not in scope: du :: a -> c; * Perhaps you meant `au' (imported from Control.Lens); <interactive>:18:5: error: Variable not in scope: h :: a -> c; <interactive>:18:8: error: Variable not in scope: s :: b0 -> c; <interactive>:18:11: error: Variable not in scope: stack :: a -> b0 |
| 2022-01-31 22:14:16 +0100 | <carbolymer> | :S |
| 2022-01-31 22:15:11 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 268 seconds) |
| 2022-01-31 22:15:39 +0100 | cynomys | (~cynomys@user/cynomys) (Quit: leaving) |
| 2022-01-31 22:16:42 +0100 | doxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-01-31 22:17:16 +0100 | jao | (~jao@static-68-235-44-23.cust.tzulo.com) (Remote host closed the connection) |
| 2022-01-31 22:18:10 +0100 | matijja | (~matijja@193.77.181.201) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2022-01-31 22:18:11 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-01-31 22:19:47 +0100 | jao | (~jao@static-68-235-44-23.cust.tzulo.com) |
| 2022-01-31 22:21:00 +0100 | matijja | (~matijja@193.77.181.201) |
| 2022-01-31 22:22:35 +0100 | zebrag | (~chris@user/zebrag) (Ping timeout: 268 seconds) |
| 2022-01-31 22:23:23 +0100 | timmot | (~timmot@207.148.85.201) () |
| 2022-01-31 22:23:25 +0100 | mon_aaraj | (~MonAaraj@user/mon-aaraj/x-4416475) |
| 2022-01-31 22:25:10 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 260 seconds) |
| 2022-01-31 22:26:13 +0100 | jao | (~jao@static-68-235-44-23.cust.tzulo.com) (Remote host closed the connection) |
| 2022-01-31 22:28:46 +0100 | jao | (~jao@static-68-235-44-23.cust.tzulo.com) |
| 2022-01-31 22:29:59 +0100 | <maerwald> | carbolymer: everything assumes infinite storage these days: docker, nix, stack, ... |
| 2022-01-31 22:30:02 +0100 | segfaultfizzbuzz | (~rustisafu@2602:306:cd3c:9350:5d4f:b362:d270:61b0) (Quit: Leaving) |
| 2022-01-31 22:30:52 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 256 seconds) |
| 2022-01-31 22:32:19 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 22:32:28 +0100 | <carbolymer> | maerwald: it's the age of the cloud! we need cloud-scale storage for those, like pingfs https://github.com/yarrick/pingfs |
| 2022-01-31 22:32:56 +0100 | <maerwald> | carbolymer: you mean https://github.com/fpco/cache-s3 |
| 2022-01-31 22:37:36 +0100 | <carbolymer> | maerwald: if you mean plain old boring build caching, then probably yes |
| 2022-01-31 22:38:04 +0100 | y04nn | (~y04nn@92.223.89.196) |
| 2022-01-31 22:38:50 +0100 | <maerwald> | and has the benefit that you can pay amazon a lot of money for it |
| 2022-01-31 22:40:16 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-01-31 22:41:31 +0100 | texasmynsted_ | (~texasmyns@99.96.221.112) (Quit: ZNC - http://znc.in) |
| 2022-01-31 22:44:10 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2022-01-31 22:44:50 +0100 | nineonine | (~nineonine@2604:3d08:7780:cd00:1deb:a18f:f447:b812) |
| 2022-01-31 22:45:00 +0100 | <nineonine> | hey all, question about exception |
| 2022-01-31 22:45:16 +0100 | <nineonine> | I want to write a function that logs exceptions in my app |
| 2022-01-31 22:45:35 +0100 | <nineonine> | should the type of the parameter by SomeException or Exception e => e ? |
| 2022-01-31 22:45:39 +0100 | <nineonine> | be* |
| 2022-01-31 22:45:47 +0100 | <nineonine> | and what would be the difference\ |
| 2022-01-31 22:46:03 +0100 | <EvanR> | what would it do, print out the exception? |
| 2022-01-31 22:46:10 +0100 | <nineonine> | yes, just printing |
| 2022-01-31 22:46:22 +0100 | <EvanR> | then String works |
| 2022-01-31 22:46:55 +0100 | <nineonine> | the function is intended to be called from `catch` and friends |
| 2022-01-31 22:46:58 +0100 | stef204 | (~stef204@user/stef204) |
| 2022-01-31 22:47:20 +0100 | <EvanR> | well if you don't want to call show there, you can use Show a => a xD |
| 2022-01-31 22:47:34 +0100 | zincy | (~zincy@2a00:23c8:970c:4801:f0bc:c4cb:1665:1c67) (Remote host closed the connection) |
| 2022-01-31 22:47:43 +0100 | <nineonine> | ok, I will ask question differently |
| 2022-01-31 22:47:55 +0100 | <nineonine> | what is the difference between SomeException and Exception e => e |
| 2022-01-31 22:48:34 +0100 | <EvanR> | because any exception type e can be converted to SomeException, and converted back (if it makes sense), very little |
| 2022-01-31 22:49:05 +0100 | <nineonine> | got it, thanks |
| 2022-01-31 22:49:34 +0100 | yauhsien_ | (~yauhsien@118-167-40-21.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-31 22:50:20 +0100 | <awpr> | `catch` cares what exception type you instantiate it with (by virtue of using the `fromException` method of `Exception`) |
| 2022-01-31 22:51:18 +0100 | <geekosaur> | the constraint version lets you do a little more but is more annoying to work with, whereas SomeException lets you avoid it but only allows a few operations (like you can't ask for more detail that many exceptions provide) |
| 2022-01-31 22:51:22 +0100 | <geekosaur> | iirc |
| 2022-01-31 22:51:30 +0100 | <awpr> | from the perspective of the handler function itself `SomeException -> IO ()` and `Exception e => e -> IO ()` are equivalent, because the latter is just a "curried" form of the latter |
| 2022-01-31 22:51:37 +0100 | <geekosaur> | if all you're doing is "show" then SomeException is easier |
| 2022-01-31 22:51:53 +0100 | <awpr> | er, former |
| 2022-01-31 22:52:01 +0100 | <EvanR> | SomeException would also require you to manually convert, or else catch SomeException |
| 2022-01-31 22:52:44 +0100 | <nineonine> | how can I "ask for more detail"? |
| 2022-01-31 22:52:49 +0100 | <nineonine> | which function should I use? |
| 2022-01-31 22:54:19 +0100 | <awpr> | but, from the perspective of passing it to `catch`, the `SomeException` version specifies `SomeException` is the type that will be caught, i.e. will catch all exceptions; while the `e` version will require you to use TypeApplications or something to specify yourself what to catch, and if you choose something more specific than `SomeException`, then fewer exceptions will be handled by that `catch` |
| 2022-01-31 22:56:17 +0100 | <awpr> | "ask for more detail" is probably `displayException`. you can do that with both forms equally, because `data SomeException = Exception e => SomeException e`. there is no difference in the capabilities of the two, only in how they interact with type inference |
| 2022-01-31 22:56:36 +0100 | <geekosaur> | nineonine, some exceptions have multiple constructors and some of those constructors have parameters, so you pattern match on the specific exception type with a type application |
| 2022-01-31 22:57:07 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 2022-01-31 22:57:26 +0100 | <nineonine> | thanks everyone! |
| 2022-01-31 22:58:07 +0100 | <geekosaur> | you can extract most of it from the "show" output but it's pretty unstructured |
| 2022-01-31 22:58:12 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-01-31 22:58:48 +0100 | soxen | (~bbrahms@pool-173-54-217-168.nwrknj.fios.verizon.net) |
| 2022-01-31 22:58:52 +0100 | <awpr> | this is still not a difference between `SomeException -> ...` and `Exception e => e -> ...`. this is a difference between either of those two and e.g. `IOException -> ...` |
| 2022-01-31 23:00:14 +0100 | <awpr> | (and with either of the former two, you can still `case fromException x of Just (x' :: IO Exception) -> ...; Nothing -> "Not an IOException"`) |
| 2022-01-31 23:01:35 +0100 | <EvanR> | so I'm writing a "foldr" function for some type. The type is recursive. Up to this point I half thought that folding a list took a "state" that could be used by the visiting function. But in my fold I didn't think of that and just map each constructor with some callback. Am I tripping and you don't have a state even with lists? |
| 2022-01-31 23:02:09 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-31 23:02:49 +0100 | <monochrom> | I don't think of []'s foldr having state either. |
| 2022-01-31 23:02:58 +0100 | CHUD | (~CHUD@host-80-41-89-108.as13285.net) (Ping timeout: 256 seconds) |
| 2022-01-31 23:03:18 +0100 | <Morrow> | I think of foldl as having a state, but not foldr (for lists, at least). |
| 2022-01-31 23:03:18 +0100 | <awpr> | is it a "foldr" in the sense of "visit elements sequentially right-to-left" or in the sense of "collapse the structure from the bottom up" (i.e. catamorphism)? |
| 2022-01-31 23:03:37 +0100 | jinsun__ | (~quassel@user/jinsun) |
| 2022-01-31 23:03:57 +0100 | <awpr> | looking at foldr, the catamorphism for lists, the thing that looks like "state" is actually the 0-ary "callback" for the 0-ary constructor `[]` |
| 2022-01-31 23:04:33 +0100 | <awpr> | er, the "initial state" is that and the "ongoing state" is the result for each sub-structure |
| 2022-01-31 23:04:51 +0100 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.4) |
| 2022-01-31 23:05:01 +0100 | <EvanR> | it's like foldr |
| 2022-01-31 23:05:41 +0100 | <EvanR> | so now I'm wondering how to do a traversal with state, is that not a thing xD |
| 2022-01-31 23:05:44 +0100 | <awpr> | so if your type doesn't have any empty constructors, then its catamorphism wouldn't have any 0-ary "callbacks", i.e. nothing that looks like an "initial state" |
| 2022-01-31 23:06:00 +0100 | <EvanR> | the leaves can be interpreted by one of the callbacks |
| 2022-01-31 23:06:13 +0100 | jinsun | (~quassel@user/jinsun) (Ping timeout: 240 seconds) |
| 2022-01-31 23:06:15 +0100 | <EvanR> | no 0-ary though |
| 2022-01-31 23:06:25 +0100 | <tomsmeding> | EvanR: does it make sense to define your function as 'myfoldr f z thing = foldr f z (toList thing)' |
| 2022-01-31 23:06:37 +0100 | <EvanR> | no it's a tree |
| 2022-01-31 23:06:46 +0100 | <tomsmeding> | still |
| 2022-01-31 23:07:09 +0100 | <monochrom> | Both foldlM and foldrM exist, and you can set the monad to a state monad. |
| 2022-01-31 23:07:28 +0100 | <EvanR> | foldrM... |
| 2022-01-31 23:08:16 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-01-31 23:08:53 +0100 | <EvanR> | "do you guys just put 'monadic' in front of everything" --antman |
| 2022-01-31 23:09:20 +0100 | <monochrom> | Nah but "traversal with state" was brought up. |
| 2022-01-31 23:09:29 +0100 | <EvanR> | just kidding |
| 2022-01-31 23:09:31 +0100 | <EvanR> | looking that up |
| 2022-01-31 23:09:44 +0100 | <tomsmeding> | EvanR: data Tree a = Node (Tree a) (Tree a) | Leaf a; treefoldr :: (s -> Either (b, b) a -> (s, b)) -> s -> Tree a -> (s, b); treefoldr f s (Node a b) = let (s1, a') = treefoldr f s a; (s2, b') = treefoldr f s1 b in f s2 (Left (a', b')); treefoldr f s (Leaf x) = f s (Right x) |
| 2022-01-31 23:09:51 +0100 | <tomsmeding> | is that kind of what you were looking for? |
| 2022-01-31 23:10:13 +0100 | <tomsmeding> | also it's a foldl not a foldr |
| 2022-01-31 23:10:17 +0100 | <tomsmeding> | but never mind that |
| 2022-01-31 23:10:28 +0100 | modnar | (~modnar@shell.sonic.net) |
| 2022-01-31 23:10:41 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 268 seconds) |
| 2022-01-31 23:10:49 +0100 | <tomsmeding> | this is a post-order traversal, but can be easily rewritten to do whatever order you like |
| 2022-01-31 23:11:01 +0100 | <tomsmeding> | note that the only reason you have to choose an order is because it's threading state through |
| 2022-01-31 23:11:28 +0100 | <EvanR> | so you write a tree fold (l) with an explicit state... ok |
| 2022-01-31 23:11:52 +0100 | Morrow | (~user@bzq-110-168-31-106.red.bezeqint.net) |
| 2022-01-31 23:11:57 +0100 | <tomsmeding> | the standard no-state fold (nostatefold f1 f2 (Node a b) = f1 (nostatefold f1 f2 a) (nostatefold f1 f2 b2); nostatefold f1 f2 (Leaf x) = f2 x) is order-agnostic |
| 2022-01-31 23:12:28 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-01-31 23:13:40 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-01-31 23:14:09 +0100 | <EvanR> | in Data.Foldable foldrM's default implementation uses foldl, so I'm thinking if I'm thinking "foldr" I'm not thinking state or effects |
| 2022-01-31 23:15:02 +0100 | <tomsmeding> | well Data.Foldable's foldr is basically foldr over toList, except that the instance can choose traversal order to a limited extent |
| 2022-01-31 23:15:30 +0100 | <EvanR> | it's funny I'm not seeing how List is relevant |
| 2022-01-31 23:15:34 +0100 | <tomsmeding> | my nostatefold is the standard catamorphism for the Tree type, also known as its church envoding, also known as "the" fold |
| 2022-01-31 23:15:53 +0100 | <tomsmeding> | and my treefoldr is an odd thing |
| 2022-01-31 23:16:05 +0100 | <EvanR> | yeah |
| 2022-01-31 23:16:06 +0100 | <tomsmeding> | EvanR: it's just how the Foldable class is set up |
| 2022-01-31 23:16:12 +0100 | <tomsmeding> | it treats everything as a list, basically |
| 2022-01-31 23:16:14 +0100 | <EvanR> | I like "the" fold |
| 2022-01-31 23:16:38 +0100 | <EvanR> | https://paste.tomsmeding.com/RfJueAQF |
| 2022-01-31 23:17:19 +0100 | <EvanR> | how do you comprehend this one as a list xD |
| 2022-01-31 23:18:46 +0100 | <tomsmeding> | EvanR: ok that's not a parameterised datatype so doesn't fit Foldable in the first place |
| 2022-01-31 23:18:54 +0100 | <EvanR> | yeah, working on it |
| 2022-01-31 23:19:01 +0100 | <tomsmeding> | but I have absolutely no idea what your foldULC is supposed to do |
| 2022-01-31 23:19:09 +0100 | <tomsmeding> | when do you call the (a -> a) -> a argument??? |
| 2022-01-31 23:19:15 +0100 | <EvanR> | on Lam |
| 2022-01-31 23:19:38 +0100 | <EvanR> | after interpreting the body as a function |
| 2022-01-31 23:19:38 +0100 | <tomsmeding> | and how do you interpret a Bar, and why is the argument order Far, App, ???, and what is Far even anyway :p |
| 2022-01-31 23:19:41 +0100 | tomsmeding | is confused |
| 2022-01-31 23:20:08 +0100 | <EvanR> | sorry, bound variable, free variable |
| 2022-01-31 23:20:15 +0100 | wombat875 | (~wombat875@pool-72-89-24-154.nycmny.fios.verizon.net) (Quit: WeeChat 2.2-dev) |
| 2022-01-31 23:20:35 +0100 | <EvanR> | so it's not a pure foldr, it's interpreting a lambda term as a thing with functions and scope |
| 2022-01-31 23:20:48 +0100 | <tomsmeding> | Bound vARiable? |
| 2022-01-31 23:20:53 +0100 | <tomsmeding> | right |
| 2022-01-31 23:22:24 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-01-31 23:22:56 +0100 | <EvanR> | and I guess it's not enough to write a thing that "numbers" nodes or names variables |
| 2022-01-31 23:23:14 +0100 | <EvanR> | (renames) |
| 2022-01-31 23:24:49 +0100 | <tomsmeding> | EvanR: those Ints are De Bruijn indices? |
| 2022-01-31 23:25:07 +0100 | <tomsmeding> | was this the intent https://paste.tomsmeding.com/q64QaWM9 |
| 2022-01-31 23:26:27 +0100 | <EvanR> | yes precisely |
| 2022-01-31 23:26:45 +0100 | <EvanR> | you improved my code xD |
| 2022-01-31 23:27:00 +0100 | <tomsmeding> | interesting, basically conversion to a church-encoded HOAS representation of the untyped lambda calculus with free variables |
| 2022-01-31 23:27:53 +0100 | MatthiasG2 | (~matthias@i6DFA01BB.versanet.de) (Ping timeout: 256 seconds) |
| 2022-01-31 23:28:15 +0100 | <EvanR> | ikr |
| 2022-01-31 23:28:29 +0100 | <tomsmeding> | B) |
| 2022-01-31 23:28:55 +0100 | <tomsmeding> | needs more GADT tho |
| 2022-01-31 23:29:24 +0100 | <EvanR> | is your environment being built backward though |
| 2022-01-31 23:29:44 +0100 | <tomsmeding> | the variables with the smallest scope are closest to the head of the list |
| 2022-01-31 23:29:47 +0100 | <tomsmeding> | i.e. have smallest indices |
| 2022-01-31 23:29:54 +0100 | <tomsmeding> | which is precisely De Bruijn indices in standard use |
| 2022-01-31 23:30:05 +0100 | <EvanR> | hmm |
| 2022-01-31 23:30:12 +0100 | <tomsmeding> | you also have the reverse variant, where variables are numbered from the top, which is perhaps what you had in mind |
| 2022-01-31 23:30:45 +0100 | <tomsmeding> | EvanR: https://tomsmeding.com/ss/get/tomsmeding/7N8lJI |
| 2022-01-31 23:30:57 +0100 | <tomsmeding> | ignore the odd syntax if possible |
| 2022-01-31 23:31:08 +0100 | <EvanR> | yes to construct a Lam from a ULC I was thinking increment all the bound variables and replace some free variable with a 0 |
| 2022-01-31 23:31:19 +0100 | <tomsmeding> | right, that's de bruijn levels |
| 2022-01-31 23:32:03 +0100 | <tomsmeding> | downside of de bruijn levels is that you need to traverse the whole tree in order to put it under a binder |
| 2022-01-31 23:32:54 +0100 | <tomsmeding> | both indices and levels have the downside that substitution of the topmost binder requires renumbering all indices |
| 2022-01-31 23:33:13 +0100 | <tomsmeding> | so if I'm not mistaken (may well be), indices are usually better because they require less renumbering |
| 2022-01-31 23:33:13 +0100 | <EvanR> | unless we use this fold here |
| 2022-01-31 23:33:20 +0100 | <tomsmeding> | well you can also use HOAS :p |
| 2022-01-31 23:33:22 +0100 | <EvanR> | which doesn't renumber anything |
| 2022-01-31 23:33:32 +0100 | <tomsmeding> | which is representing a lambda with a function precisely like you did |
| 2022-01-31 23:34:40 +0100 | <EvanR> | you mentioned GADTs, in the case of ULC where would it benefit |
| 2022-01-31 23:34:50 +0100 | <tomsmeding> | EvanR: https://paste.tomsmeding.com/kuTS60x4 that's HOAS |
| 2022-01-31 23:35:55 +0100 | <EvanR> | ah you convert made a new structure that did away with bound vars |
| 2022-01-31 23:36:03 +0100 | <tomsmeding> | kind of yes |
| 2022-01-31 23:36:35 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-01-31 23:38:36 +0100 | <EvanR> | ULC can be saved and restored from text |
| 2022-01-31 23:38:48 +0100 | <EvanR> | so can we get it back from HAOS |
| 2022-01-31 23:39:59 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-01-31 23:40:54 +0100 | <EvanR> | I mean the name hints are gone but |
| 2022-01-31 23:47:09 +0100 | <EvanR> | ah |
| 2022-01-31 23:47:29 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-01-31 23:49:03 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-01-31 23:52:34 +0100 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-01-31 23:54:18 +0100 | CHUD | (~CHUD@host-80-41-89-108.as13285.net) |
| 2022-01-31 23:58:30 +0100 | CHUD | (~CHUD@host-80-41-89-108.as13285.net) (Ping timeout: 256 seconds) |
| 2022-01-31 23:59:21 +0100 | <EvanR> | https://paste.tomsmeding.com/f3XaHI1U |
| 2022-01-31 23:59:49 +0100 | ph88 | (~ph88@2a02:8109:9e00:71d0:bc3f:ae22:7b02:63e) (Quit: Leaving) |
| 2022-01-31 23:59:50 +0100 | <tomsmeding> | EvanR: higher-order abstract syntax |
| 2022-01-31 23:59:54 +0100 | <tomsmeding> | not haos :p |
