| 2024-04-23 00:15:41 +0200 | crook1389 | (uid581388@id-581388.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-23 00:19:55 +0200 | anon1123 | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) (Ping timeout: 272 seconds) |
| 2024-04-23 00:22:10 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-04-23 00:23:42 +0200 | acidjnk | (~acidjnk@p200300d6e714dc576d6928eb96b27a5a.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-04-23 00:24:21 +0200 | trev | (~trev@user/trev) (Ping timeout: 252 seconds) |
| 2024-04-23 00:26:32 +0200 | trev | (~trev@user/trev) |
| 2024-04-23 00:29:36 +0200 | anon1123 | (~anon1123@catv-176-63-0-119.catv.fixed.vodafone.hu) |
| 2024-04-23 00:30:25 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-04-23 00:30:39 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Quit: Leaving) |
| 2024-04-23 00:31:56 +0200 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) (Remote host closed the connection) |
| 2024-04-23 00:34:19 +0200 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-04-23 00:46:46 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 268 seconds) |
| 2024-04-23 00:48:35 +0200 | anon1123 | (~anon1123@catv-176-63-0-119.catv.fixed.vodafone.hu) (Ping timeout: 264 seconds) |
| 2024-04-23 00:48:39 +0200 | anon1123_ | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) |
| 2024-04-23 00:50:48 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-23 00:52:02 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-04-23 00:54:18 +0200 | Ptival | (~ptival@64.16.51.186) (Remote host closed the connection) |
| 2024-04-23 00:54:45 +0200 | Ptival | (~ptival@64.16.51.186) |
| 2024-04-23 00:55:05 +0200 | Ptival | (~ptival@64.16.51.186) (Remote host closed the connection) |
| 2024-04-23 00:55:11 +0200 | Ptival_ | (~ptival@64.16.51.186) |
| 2024-04-23 00:56:19 +0200 | mima | (~mmh@aftr-62-216-211-149.dynamic.mnet-online.de) (Ping timeout: 268 seconds) |
| 2024-04-23 00:57:32 +0200 | Ptival_ | (~ptival@64.16.51.186) (Remote host closed the connection) |
| 2024-04-23 00:58:20 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-04-23 01:00:46 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-23 01:01:11 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-04-23 01:01:27 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Remote host closed the connection) |
| 2024-04-23 01:02:48 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-04-23 01:05:07 +0200 | leah2 | (~leah@vuxu.org) (Ping timeout: 255 seconds) |
| 2024-04-23 01:22:12 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Remote host closed the connection) |
| 2024-04-23 01:22:26 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-04-23 01:29:25 +0200 | xal | (~xal@mx1.xal.systems) () |
| 2024-04-23 01:35:30 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Remote host closed the connection) |
| 2024-04-23 01:35:46 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-04-23 01:37:02 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-23 01:42:19 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 260 seconds) |
| 2024-04-23 01:44:40 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-23 01:56:42 +0200 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 244 seconds) |
| 2024-04-23 01:57:25 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 245 seconds) |
| 2024-04-23 01:57:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-04-23 02:01:01 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-23 02:15:05 +0200 | Ptival | (~ptival@64.16.51.186) |
| 2024-04-23 02:16:22 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-04-23 02:17:50 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 245 seconds) |
| 2024-04-23 02:20:52 +0200 | bilegeek | (~bilegeek@2600:1008:b048:47a6:69f5:273e:c742:c5f5) |
| 2024-04-23 02:24:23 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 256 seconds) |
| 2024-04-23 02:29:29 +0200 | ephemient | (uid407513@user/ephemient) |
| 2024-04-23 02:30:46 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-04-23 02:31:55 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-04-23 02:41:56 +0200 | <yin> | is it possible to run all operations that are not depedent on side effects at compile time? |
| 2024-04-23 02:45:13 +0200 | <geekosaur> | hypothetically. in practice, (a) bottoms at compile time will make you very unhappy (b) since `main :: IO a`, it's likely that most of your operations are ultimately dependent on `IO` |
| 2024-04-23 02:46:56 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 260 seconds) |
| 2024-04-23 02:48:23 +0200 | <yin> | but something like `primes = filter isPrime [0..100]` has no reason not to |
| 2024-04-23 02:48:24 +0200 | <c_wraith> | GHC really doesn't like to do recursion at compile time. |
| 2024-04-23 02:48:33 +0200 | <c_wraith> | mostly because.. it might bottom out |
| 2024-04-23 02:48:49 +0200 | <c_wraith> | Or proceed for an arbitrarily long time |
| 2024-04-23 02:49:03 +0200 | <EvanR> | this language zig really believes in doing a bunch of computation at compile time, so much so it's kind of hard to tell when it's going to do that |
| 2024-04-23 02:49:20 +0200 | <jackdk> | But also, in some sense, isn't this what optimisers do? Rewrite expressions into equivalent but faster forms? I saw something the other day that showed rustc could detect and optimise closed-form sums |
| 2024-04-23 02:49:40 +0200 | <yin> | C++ has consteval |
| 2024-04-23 02:49:52 +0200 | <EvanR> | yeah zig seems to take consteval to an extreme |
| 2024-04-23 02:49:57 +0200 | <c_wraith> | there's also the fact that simple things like [1 .. 1000000] are slower compile as constants than calculate. |
| 2024-04-23 02:50:30 +0200 | <geekosaur> | another point is that, while an operation might not depend on `IO` directly, its use might depend on it, and one aspect of laziness is that means your expression indeed depends on `IO` |
| 2024-04-23 02:52:27 +0200 | Inst | (~Inst@user/Inst) (Read error: Connection reset by peer) |
| 2024-04-23 02:52:39 +0200 | <c_wraith> | and from the other side... GHC *does* give you the tool to compile a lot of things as constants via template haskell, if you really need it. (not everything can be compiled that way, but a lot of things can) |
| 2024-04-23 02:52:57 +0200 | <yin> | ok i'm convinced it's not the best idea |
| 2024-04-23 02:55:10 +0200 | <c_wraith> | This isn't the hardest template haskell, though it *is* important to know why beta substitution doesn't work through quotes: primes = $(let x = filter isPrime [0..100] in [| x |]) |
| 2024-04-23 02:58:08 +0200 | <c_wraith> | actually, you'd probably want to use typed template haskell for that so it would infer the type from context correctly. But still. |
| 2024-04-23 03:01:07 +0200 | <c_wraith> | huh. apparently typed template haskell doesn't play nicely with let generalization. Weird. |
| 2024-04-23 03:01:47 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 264 seconds) |
| 2024-04-23 03:09:05 +0200 | nullobject | (~josh@user/nullobject) (Ping timeout: 245 seconds) |
| 2024-04-23 03:09:24 +0200 | Inst | (~Inst@user/Inst) |
| 2024-04-23 03:15:28 +0200 | tertek | (~tertek@user/tertek) |
| 2024-04-23 03:15:59 +0200 | zlqrvx | (~zlqrvx@user/zlqrvx) |
| 2024-04-23 03:22:33 +0200 | foul_owl | (~kerry@185.219.141.164) (Ping timeout: 252 seconds) |
| 2024-04-23 03:28:49 +0200 | Ptival | (~ptival@64.16.51.186) (Remote host closed the connection) |
| 2024-04-23 03:29:35 +0200 | Ptival | (~ptival@64.16.51.186) |
| 2024-04-23 03:31:54 +0200 | Ptival_ | (~ptival@64.16.51.186) |
| 2024-04-23 03:32:13 +0200 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2024-04-23 03:32:23 +0200 | xff0x | (~xff0x@2405:6580:b080:900:f58b:ec5b:d9ae:c39) (Ping timeout: 256 seconds) |
| 2024-04-23 03:34:05 +0200 | Ptival | (~ptival@64.16.51.186) (Ping timeout: 245 seconds) |
| 2024-04-23 03:34:32 +0200 | smoge | (~smoge@2603:7000:4b42:1100::1) |
| 2024-04-23 03:35:44 +0200 | yin | (~yin@user/zero) (Ping timeout: 252 seconds) |
| 2024-04-23 03:36:10 +0200 | Ptival_ | (~ptival@64.16.51.186) (Ping timeout: 245 seconds) |
| 2024-04-23 03:36:35 +0200 | foul_owl | (~kerry@157.97.134.165) |
| 2024-04-23 03:36:49 +0200 | hueso | (~root@user/hueso) |
| 2024-04-23 03:37:42 +0200 | yin | (~yin@user/zero) |
| 2024-04-23 03:37:50 +0200 | otto_s | (~user@p5b04489f.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-04-23 03:39:35 +0200 | otto_s | (~user@p5b044a05.dip0.t-ipconnect.de) |
| 2024-04-23 03:44:06 +0200 | Ptival | (~ptival@2601:1c0:4580:7650:4c3d:464d:57f8:c38) |
| 2024-04-23 03:45:14 +0200 | smoge | (~smoge@2603:7000:4b42:1100::1) (Quit: Client closed) |
| 2024-04-23 03:45:58 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 03:48:15 +0200 | Ptival | (~ptival@2601:1c0:4580:7650:4c3d:464d:57f8:c38) (Ping timeout: 245 seconds) |
| 2024-04-23 03:49:48 +0200 | yin | (~yin@user/zero) (Ping timeout: 255 seconds) |
| 2024-04-23 03:51:48 +0200 | yin | (~yin@user/zero) |
| 2024-04-23 03:55:35 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-23 03:56:29 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-23 04:13:29 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-04-23 04:36:48 +0200 | td_ | (~td@i53870931.versanet.de) (Ping timeout: 252 seconds) |
| 2024-04-23 04:38:29 +0200 | td_ | (~td@i5387090C.versanet.de) |
| 2024-04-23 04:40:47 +0200 | yin | (~yin@user/zero) (Ping timeout: 268 seconds) |
| 2024-04-23 04:46:26 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Quit: WeeChat 2.9) |
| 2024-04-23 04:46:42 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 04:47:27 +0200 | yin | (~yin@user/zero) |
| 2024-04-23 04:47:48 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-04-23 04:48:05 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2024-04-23 04:52:43 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-04-23 04:53:27 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Quit: WeeChat 2.9) |
| 2024-04-23 04:54:44 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2024-04-23 04:58:41 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:01:27 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
| 2024-04-23 05:06:17 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:06:36 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:09:36 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:09:53 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:11:29 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:11:43 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:13:09 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:15:01 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:15:11 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:16:58 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:18:54 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 05:19:24 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 05:22:10 +0200 | Axman6 | (~Axman6@user/axman6) |
| 2024-04-23 05:26:38 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-04-23 05:29:27 +0200 | <Inst> | why doesn't IO memory leak horrifically in Haskell? |
| 2024-04-23 05:29:47 +0200 | <Inst> | a naive look at Haskell's semantics implies that Haskell has to build the full IO value before it can execute |
| 2024-04-23 05:30:31 +0200 | <EvanR> | do you mean something like someprimitive >>= f |
| 2024-04-23 05:30:50 +0200 | <Inst> | https://hackage.haskell.org/package/base-4.19.1.0/docs/src/GHC.Base.html#thenIO |
| 2024-04-23 05:30:54 +0200 | <EvanR> | it has to execute someprimitive before going on |
| 2024-04-23 05:31:21 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 268 seconds) |
| 2024-04-23 05:31:29 +0200 | <Inst> | yeah, i know, because that's how I understand how Haskell actually works, but taking the lambdas literally it implies massive thunk buildup |
| 2024-04-23 05:31:34 +0200 | <EvanR> | that doesn't look like semantics to me xD |
| 2024-04-23 05:32:19 +0200 | <EvanR> | massive thunk buildup? |
| 2024-04-23 05:33:01 +0200 | <Inst> | it feels like there's some kind of magic going on because it feels like when you call main |
| 2024-04-23 05:33:15 +0200 | aforemny_ | (~aforemny@2001:9e8:6cde:9300:d77b:b228:6e32:ed32) (Ping timeout: 245 seconds) |
| 2024-04-23 05:33:46 +0200 | <Inst> | it'd have to fully evaluate your program (since all Haskell programs are single values of type IO a) |
| 2024-04-23 05:34:10 +0200 | <EvanR> | how can it even evaluate anything when it doesn't know the result of the first IO call |
| 2024-04-23 05:34:12 +0200 | aforemny | (~aforemny@2001:9e8:6cc5:7800:75d6:e4cb:e12d:1704) |
| 2024-04-23 05:34:18 +0200 | <EvanR> | to pass to the f |
| 2024-04-23 05:35:03 +0200 | <Inst> | well it has to go through all the thens and binds in IO |
| 2024-04-23 05:35:10 +0200 | <c_wraith> | Why? |
| 2024-04-23 05:35:17 +0200 | <c_wraith> | they're hidden behind lambdas |
| 2024-04-23 05:35:27 +0200 | <Inst> | derp |
| 2024-04-23 05:35:29 +0200 | <EvanR> | logically, it only has to hold the top most lambda |
| 2024-04-23 05:35:39 +0200 | <Inst> | so i don't understand lambda laziness then |
| 2024-04-23 05:35:53 +0200 | <Inst> | back to watching Alexis King, I guess |
| 2024-04-23 05:35:56 +0200 | <EvanR> | WHNF means the inside of a lambda isn't evaluated |
| 2024-04-23 05:36:06 +0200 | <EvanR> | yet |
| 2024-04-23 05:37:32 +0200 | <Inst> | https://www.youtube.com/watch?v=fSqE-HSh_NU |
| 2024-04-23 05:38:00 +0200 | <EvanR> | "Laziness. Is it good?" |
| 2024-04-23 05:38:21 +0200 | <Inst> | i read somewhere that you can accumulate thunks based on the chained function calls inside? |
| 2024-04-23 05:38:28 +0200 | <EvanR> | betteridge's law implies No |
| 2024-04-23 05:39:31 +0200 | <haskellbridge> | <irregularsphere> 1+1=2? |
| 2024-04-23 05:40:15 +0200 | <Inst> | (+) _ _ = _ |
| 2024-04-23 05:41:20 +0200 | <EvanR> | 1 + 1 + 1 + 1 + 1 + 1, but that's not a lambda |
| 2024-04-23 05:41:31 +0200 | <EvanR> | it's a bunch of applications |
| 2024-04-23 05:44:51 +0200 | <haskellbridge> | <irregularsphere> Inst: anyway, first of all, `do` is syntax sugar: `do { putStrLn a; b <- getLine; c <- getLine; return b ++ c }` -> `putStrLn a >>= \_ -> (getLine >>= \b -> (getLine >>= \c -> (return b ++ c)))` so no you really won't, moreover _should not_ have to evaluate the entire IO before executing |
| 2024-04-23 05:45:07 +0200 | <Inst> | i'm familiar with do, i'm just reviewing what i know to patch gaps |
| 2024-04-23 05:45:32 +0200 | <haskellbridge> | <irregularsphere> (...is sending multiline messages over the matrix <-> irc bridge acceptable?) |
| 2024-04-23 05:46:07 +0200 | <Inst> | iirc it should also be foo >> (bar >> (baz... ))), no? |
| 2024-04-23 05:46:27 +0200 | <haskellbridge> | <irregularsphere> a >> b is defined as a >>= \_ -> b |
| 2024-04-23 05:46:48 +0200 | <monochrom> | You will need a very good model of IO to see why for example "main = putStrLn "hi" >>= \_ -> main" is productive. |
| 2024-04-23 05:46:49 +0200 | <haskellbridge> | <irregularsphere> s/_/\_ |
| 2024-04-23 05:47:49 +0200 | <haskellbridge> | <irregularsphere> to be fair i just know IO as a magic state monad that uses the RealWorld |
| 2024-04-23 05:48:15 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-23 05:48:17 +0200 | <haskellbridge> | <irregularsphere> ~~I wonder if you can create your own `RealWorld`s~~ |
| 2024-04-23 05:48:49 +0200 | <Inst> | ruwRW# :3 |
| 2024-04-23 05:49:07 +0200 | <monochrom> | The "RealWorld -> (a, RealWorld)" model will not explain why putStrLn actually prints anything. |
| 2024-04-23 05:49:35 +0200 | <Inst> | or rather, GHC.Prim.html |
| 2024-04-23 05:49:42 +0200 | <Inst> | erm, GHC.Prim.realWorld# |
| 2024-04-23 05:49:45 +0200 | <haskellbridge> | <irregularsphere> fair, that's why i said "to be fair i just know" |
| 2024-04-23 05:49:51 +0200 | <monochrom> | By extension, you can create your own RealWorld's, there is enough stuff in GHC.* modules for that. And that still doesn't let you print anything. |
| 2024-04-23 05:49:56 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-04-23 05:50:14 +0200 | <monochrom> | Although, beginning with 9.6, it is enough for you to play with shift-reset. |
| 2024-04-23 05:50:18 +0200 | yin | (~yin@user/zero) |
| 2024-04-23 05:51:34 +0200 | <Inst> | also technically, >>= \_ -> main should be less efficient than >> main, no? |
| 2024-04-23 05:51:43 +0200 | <Inst> | since there is a specific thenIO# |
| 2024-04-23 05:51:50 +0200 | <EvanR> | if RealWorld Haskell was written by Inst it would be called IO Haskell |
| 2024-04-23 05:54:02 +0200 | <monochrom> | Not sure how knowing about thenIO# answers the questions you asked unless you intend to answer them by studying GHC source code and then GHC RTS source code. |
| 2024-04-23 05:56:55 +0200 | <haskellbridge> | <irregularsphere> looking at the source, `bindIO` and `thenIO` look similar, so I guess it'd not be that much of a performance penalty (or, any at all) |
| 2024-04-23 05:57:06 +0200 | <Inst> | on main = putStrLn "hi" >> main, >> is the function actually running, when then creates a lambda of IO (\s -> case runRW# (putStrLn "hi") s of (new_s, _) -> unIO main new_s) |
| 2024-04-23 05:57:43 +0200 | <haskellbridge> | <irregularsphere> I'm not familiar with haskell's internals unfortunately |
| 2024-04-23 05:58:48 +0200 | <Inst> | main unwraps, applies the state token |
| 2024-04-23 05:59:14 +0200 | <Inst> | forces the lambda to case runRW# (putStrLn "hi") s, running the effect |
| 2024-04-23 05:59:50 +0200 | <Inst> | pattern matches on a fictive new state, then unIO unwraps main and the evaluation engine tries to go to the next main |
| 2024-04-23 05:59:53 +0200 | <Inst> | wrong? |
| 2024-04-23 06:01:32 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-04-23 06:01:32 +0200 | <Inst> | ironically I do have to wonder if foo >> bar >> baz has different performance characteristics to foo >> (bar >> baz) |
| 2024-04-23 06:01:40 +0200 | <Inst> | or rather foo; bar; baz |
| 2024-04-23 06:01:46 +0200 | <glguy> | You don't have to wonder |
| 2024-04-23 06:02:06 +0200 | <Inst> | since it's infixl |
| 2024-04-23 06:02:17 +0200 | <Inst> | thus the bar baz >> is "in control" |
| 2024-04-23 06:02:57 +0200 | <haskellbridge> | <irregularsphere> I don't know what infix has to do with this |
| 2024-04-23 06:03:55 +0200 | <Inst> | infixl should mean it renders as (foo >> bar) >> baz |
| 2024-04-23 06:04:25 +0200 | <Inst> | by lazy semantics, (foo >> bar) is treated as a thunk, then evaluated first, no? |
| 2024-04-23 06:04:34 +0200 | <Inst> | then foo >> bar is part of its evaluation |
| 2024-04-23 06:04:54 +0200 | <Inst> | whereas foo; bar; baz is effectively foo >> (bar >> baz) |
| 2024-04-23 06:05:03 +0200 | <Inst> | and evaluates more cleannly |
| 2024-04-23 06:05:26 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-23 06:05:36 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-04-23 06:05:39 +0200 | <glguy> | Inst: you don't have to guess; you can just ask GHC to show you what it did |
| 2024-04-23 06:06:47 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-23 06:08:42 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 06:09:02 +0200 | demesne | (~demesne@50.35.88.207) |
| 2024-04-23 06:09:29 +0200 | <monochrom> | My https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107775.html is a great example. |
| 2024-04-23 06:09:43 +0200 | <monochrom> | of how armchair philosophy is always broken. |
| 2024-04-23 06:11:18 +0200 | michalz | (~michalz@185.246.207.218) |
| 2024-04-23 06:14:05 +0200 | <glguy> | monochrom: ugh, it didn't bother eval = fval ?? |
| 2024-04-23 06:14:38 +0200 | <monochrom> | Heh, I don't know why, but perhaps just because it was 2013. |
| 2024-04-23 06:15:47 +0200 | <monochrom> | With todays "f = (... >> ...) >> ...; g = ... >> (... >> ...)" example and recent GHC, yeah it just does "f = f1; g = f1; f1 = ..." |
| 2024-04-23 06:19:08 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2024-04-23 06:20:08 +0200 | <monochrom> | OK today's GHC does "eval = fval". :) |
| 2024-04-23 06:22:40 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2024-04-23 06:24:56 +0200 | <Inst> | oh wow, what happend to fllvm? |
| 2024-04-23 06:25:28 +0200 | <glguy> | I give uo |
| 2024-04-23 06:25:31 +0200 | <glguy> | up |
| 2024-04-23 06:27:40 +0200 | <monochrom> | You wanna have fun listening to a new fable I'm making up just now? >:) |
| 2024-04-23 06:27:58 +0200 | <Inst> | it's -ddump-simpl to see logs? |
| 2024-04-23 06:28:05 +0200 | <Inst> | sorry, I got distracted by trying to search for how to get the IR out |
| 2024-04-23 06:28:11 +0200 | <Inst> | ended up just stealing it off monochrom's link |
| 2024-04-23 06:28:21 +0200 | <Inst> | then i ended up playing around with trying to get -fllvm working |
| 2024-04-23 06:28:28 +0200 | <Inst> | which i suspect really should be called -O3 |
| 2024-04-23 06:28:37 +0200 | <monochrom> | I'm going to tell it anyway! Someone asks why 20 mod 10 = 0. |
| 2024-04-23 06:28:57 +0200 | <monochrom> | So everyone tries to explain like 20 is a multiple of 10 so the remainder is 0. |
| 2024-04-23 06:30:07 +0200 | <monochrom> | But the asker decided to not listen, instead compile with gcc -O2, and say "btw as shown by gcc -O2, isn't it more efficient to multiple by 1717986919 then do this left-shift then do this right-shift then ..." |
| 2024-04-23 06:30:07 +0200 | glguy | prepares for enlightenment |
| 2024-04-23 06:35:03 +0200 | <Inst> | has your enlightenment arrived? |
| 2024-04-23 06:38:45 +0200 | <jackdk> | Enlightenment came for me in the early 2000s, when I discovered the BlueSteel theme |
| 2024-04-23 06:38:59 +0200 | <Inst> | okay, looking at the IR of sample foo programs, which calls boo and baz |
| 2024-04-23 06:41:03 +0200 | <Inst> | cool, only at O0 do you see the different encodings |
| 2024-04-23 06:41:32 +0200 | <Inst> | but am i wrong if i say that fflvm is haskell's hidden O3 mode? |
| 2024-04-23 06:42:39 +0200 | <dolio> | Yes. |
| 2024-04-23 06:45:01 +0200 | <Inst> | why? |
| 2024-04-23 06:45:33 +0200 | <dolio> | Why would you even think that it is? |
| 2024-04-23 06:45:56 +0200 | <Inst> | since fflvm apparently grants some performance improvements when using vector |
| 2024-04-23 06:46:11 +0200 | <c_wraith> | and worse performance in other cases |
| 2024-04-23 06:46:30 +0200 | <Inst> | and i'm annoyed that when i benchmarked it via time, Haskell seems to run at 4x rust |
| 2024-04-23 06:46:35 +0200 | <dolio> | Anyhow, I haven't been paying close attention, but I recall seeing ghc people lamenting about how no one is even working on it anymore, so it may be getting worse over time. |
| 2024-04-23 06:46:42 +0200 | <Inst> | i know |
| 2024-04-23 06:46:53 +0200 | <Inst> | i'm also told llvm is terrible for FP, although someone's talking about setting up recursive macros |
| 2024-04-23 06:46:57 +0200 | <dolio> | And yeah, some examples might be better, others might be worse. |
| 2024-04-23 06:47:51 +0200 | Square | (~Square@user/square) |
| 2024-04-23 06:49:01 +0200 | <Inst> | if kuribas were here, i'd mention they claimed that they could get Haskell reliably within 50% of rust |
| 2024-04-23 06:49:05 +0200 | <Inst> | with trivial effort |
| 2024-04-23 06:49:16 +0200 | <dolio> | I wouldn't be surprised if no one's verified that -fllvm is actually better for vector in like 7 years. |
| 2024-04-23 06:49:53 +0200 | <dolio> | But, I mean, it might be. It's pretty particular code. |
| 2024-04-23 06:51:50 +0200 | <Inst> | minority of minority of performance obsessed haskellers |
| 2024-04-23 06:53:00 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
| 2024-04-23 06:53:26 +0200 | <haskellbridge> | <irregularsphere> Inst: "4x rust" would you please send us both codes that have been benchmarked |
| 2024-04-23 06:55:29 +0200 | <haskellbridge> | <irregularsphere> "if kuribas were here, i'd mention they claimed that they could get Haskell reliably within 50% of rust" I'm sorry, what does "get Haskell within 50% of Rust" mean |
| 2024-04-23 06:56:27 +0200 | <EvanR> | 4 times faster than rust is nothing to complain about! |
| 2024-04-23 06:57:32 +0200 | <haskellbridge> | <irregularsphere> I won't believe it till I replicate it |
| 2024-04-23 06:58:32 +0200 | <EvanR> | it would have to be something that benefits from skipping most of the work thanks to laziness, in which case the rust version could be excused for being written wrong |
| 2024-04-23 06:59:09 +0200 | <EvanR> | and not explicitly skipping work the long way |
| 2024-04-23 07:01:22 +0200 | <Inst> | i mean flatparse seems to outperform nom for some reason |
| 2024-04-23 07:01:28 +0200 | <Inst> | i can't find where chrisdone hid his benchmarks |
| 2024-04-23 07:03:08 +0200 | <Inst> | here we go |
| 2024-04-23 07:03:08 +0200 | <Inst> | https://gist.github.com/chrisdone/8551675bb99a0d66cf075fdcb1e6b757 |
| 2024-04-23 07:04:37 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-04-23 07:05:17 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-04-23 07:06:49 +0200 | euleritian | (~euleritia@dynamic-176-006-008-103.176.6.pool.telefonica.de) |
| 2024-04-23 07:07:07 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 260 seconds) |
| 2024-04-23 07:11:07 +0200 | kritzefitz_ | (~kritzefit@debian/kritzefitz) |
| 2024-04-23 07:13:11 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 264 seconds) |
| 2024-04-23 07:14:49 +0200 | <haskellbridge> | <irregularsphere> "it would have to be something that benefits from skipping most of the work thanks to laziness, in which case the rust version could be excused for being written wrong" yeah anything written in any language can be written in rust, or C if you're brave enough |
| 2024-04-23 07:14:59 +0200 | bilegeek | (~bilegeek@2600:1008:b048:47a6:69f5:273e:c742:c5f5) (Quit: Leaving) |
| 2024-04-23 07:15:58 +0200 | kritzefitz_ | kritzefitz |
| 2024-04-23 07:16:39 +0200 | <haskellbridge> | <irregularsphere> Rust is eager by default and Haskell is lazy by default, I would say |
| 2024-04-23 07:17:35 +0200 | <haskellbridge> | <irregularsphere> anyway I'm much more interested in the type system, and I don't even program seriously anyway |
| 2024-04-23 07:17:48 +0200 | <Axman6> | -fllvm can be useful for certain kinds of code, mostly code which uses lots of loops and/or numerical things that it can vectorise. But a lot of Haskell code sees no improvement |
| 2024-04-23 07:20:10 +0200 | <Inst> | now the challenge for me is to figure out how to get -fllvm working |
| 2024-04-23 07:21:44 +0200 | <Axman6> | do you have an error? |
| 2024-04-23 07:21:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-23 07:22:06 +0200 | <Axman6> | generally it's as simple as having llvm installed, and GHC just calls `opt` on its llvm output files |
| 2024-04-23 07:22:18 +0200 | <Axman6> | (oversimplification but roughly true) |
| 2024-04-23 07:23:48 +0200 | <Inst> | looks like this |
| 2024-04-23 07:23:48 +0200 | <Inst> | https://media.discordapp.net/attachments/968989726633779215/1232200171152998470/image.png?ex=66289… |
| 2024-04-23 07:24:29 +0200 | <Inst> | thanks for offering to help, Axman6 |
| 2024-04-23 07:25:07 +0200 | <haskellbridge> | <irregularsphere> unsupported llvm version? |
| 2024-04-23 07:25:19 +0200 | <Inst> | i have no idea why this is |
| 2024-04-23 07:25:28 +0200 | <haskellbridge> | <irregularsphere> I could only guess... |
| 2024-04-23 07:25:54 +0200 | mei | (~mei@user/mei) (Killed (mercury.libera.chat (Nickname regained by services))) |
| 2024-04-23 07:25:55 +0200 | <Inst> | i heard 9.10 or 9.12 supports up to llvm 18 |
| 2024-04-23 07:25:57 +0200 | <haskellbridge> | <irregularsphere> s/could/can |
| 2024-04-23 07:25:59 +0200 | mei | (~mei@user/mei) |
| 2024-04-23 07:26:19 +0200 | <Inst> | so i have clang14 installed via pacman and am trying to figure out how to change system default clang version |
| 2024-04-23 07:27:53 +0200 | <dolio> | -fllvm doesn't compile to C, though. It uses a GHC-specific calling convention in general llvm. |
| 2024-04-23 07:28:51 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-04-23 07:30:07 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-04-23 07:32:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-23 07:33:12 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-04-23 07:39:27 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 256 seconds) |
| 2024-04-23 07:45:03 +0200 | demesne | (~demesne@50.35.88.207) (Remote host closed the connection) |
| 2024-04-23 07:49:37 +0200 | <Axman6> | if you can use an older LLVM install in your path and/or alias opt=opt-14 or something then that might work |
| 2024-04-23 07:50:38 +0200 | <Axman6> | or you can use -pgmlo opt-14 -pgmlc llc-14 as GHC arguments |
| 2024-04-23 07:50:57 +0200 | dunj3 | (~dunj3@kingdread.de) (Ping timeout: 252 seconds) |
| 2024-04-23 07:51:05 +0200 | <Axman6> | https://downloads.haskell.org/ghc/latest/docs/users_guide/phases.html?highlight=pgm#ghc-flag--pgml…⟨cmd⟩ |
| 2024-04-23 07:52:17 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-23 07:53:13 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-23 07:54:22 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
| 2024-04-23 07:55:48 +0200 | dunj3 | (~dunj3@kingdread.de) |
| 2024-04-23 07:58:15 +0200 | <glguy> | You can fix a particular GHC to use a particular llc and opt executable by editing your local settings file, e.g. .ghcup/ghc/9.4.8/lib/ghc-9.4.8/lib/settings |
| 2024-04-23 07:58:35 +0200 | acidjnk | (~acidjnk@p200300d6e714dc429de1f5b63f3ace20.dip0.t-ipconnect.de) |
| 2024-04-23 07:59:10 +0200 | <Inst> | thanks |
| 2024-04-23 08:00:16 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-23 08:06:46 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-23 08:08:07 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 255 seconds) |
| 2024-04-23 08:11:10 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 245 seconds) |
| 2024-04-23 08:11:11 +0200 | julie_pilgrim | (~julie_pil@user/julie-pilgrim/x-1240752) |
| 2024-04-23 08:14:45 +0200 | danza | (~francesco@151.35.152.107) |
| 2024-04-23 08:17:35 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-04-23 08:20:05 +0200 | leah2 | (~leah@vuxu.org) |
| 2024-04-23 08:26:57 +0200 | mima | (~mmh@aftr-62-216-211-1.dynamic.mnet-online.de) |
| 2024-04-23 08:29:33 +0200 | <mauke> | glguy: "Note on syntax — the reader should understand why we need the brackets in f(2, 3). Not to make a list — that is done by the comma. Nor to denote functional application — mere juxtaposition does that. They are there because functional application binds more tightly than comma — without them we should be applying f to 2 only and not to the whole list." |
| 2024-04-23 08:30:38 +0200 | <mauke> | it's not exactly the same, but the parentheses in @xs = (2, 3); are also there purely because of precedence |
| 2024-04-23 08:37:13 +0200 | ft | (~ft@p4fc2a20e.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-04-23 08:38:19 +0200 | <glguy> | mauke: Simple Authentication and Security Layer (SASL) ? |
