| 2024-04-15 00:04:06 +0200 | ph88 | (~ph88@91.64.63.48) (Remote host closed the connection) |
| 2024-04-15 00:11:39 +0200 | Achylles_ | (~Achylles@45.182.57.98) |
| 2024-04-15 00:24:00 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-04-15 00:31:13 +0200 | Achylles_ | (~Achylles@45.182.57.98) (Remote host closed the connection) |
| 2024-04-15 00:32:04 +0200 | bitmapper_ | (uid464869@id-464869.lymington.irccloud.com) |
| 2024-04-15 00:36:53 +0200 | bitmapper_ | bitmapper |
| 2024-04-15 00:51:47 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-04-15 00:59:58 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-15 01:00:12 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Client Quit) |
| 2024-04-15 01:09:42 +0200 | <haskellbridge> | <sm> Liamzee: ansi-terminal-game is better suited to games |
| 2024-04-15 01:11:27 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-15 01:15:28 +0200 | <janus> | cheater: i don't know but i use fast-tags: https://hackage.haskell.org/package/fast-tags |
| 2024-04-15 01:15:45 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2024-04-15 01:18:19 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 256 seconds) |
| 2024-04-15 01:40:18 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) |
| 2024-04-15 01:41:06 +0200 | acidjnk | (~acidjnk@p200300d6e714dc113d01b076fdd4c432.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-04-15 01:41:12 +0200 | <Inst> | thanks for the suggestion @sm |
| 2024-04-15 01:41:26 +0200 | <Inst> | also, I'm not being reckless, and this is embarrassing, but... |
| 2024-04-15 01:41:43 +0200 | <Inst> | I'm testing hackage-server right now on my system, and I can't get the behavior to be the way I need it to be |
| 2024-04-15 01:41:56 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 260 seconds) |
| 2024-04-15 01:42:36 +0200 | <geekosaur> | you probably want to ask in #hackage:matrix.org |
| 2024-04-15 01:42:46 +0200 | <geekosaur> | (or #hackage on libera) |
| 2024-04-15 01:44:23 +0200 | <Inst> | thanks |
| 2024-04-15 01:44:43 +0200 | <geekosaur> | that said, there's no guarantee that "the way you need it to be" was included as a design consideration |
| 2024-04-15 01:45:19 +0200 | <Inst> | oh, it's simply getting browse to sort by lastUpload |
| 2024-04-15 01:54:28 +0200 | <Inst> | so unless I'm missing something, sm, doesn't seem to be as simple as you suggested? |
| 2024-04-15 01:54:39 +0200 | <Inst> | in ref to a convo a couple of days back |
| 2024-04-15 01:59:11 +0200 | <Inst> | sm: should I consider this beyond my paygrade and simply submit it as an issue and walk off? |
| 2024-04-15 01:59:37 +0200 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2024-04-15 02:01:10 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-04-15 02:02:01 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-04-15 02:06:22 +0200 | delyan_ | (sid523379@id-523379.hampstead.irccloud.com) |
| 2024-04-15 02:06:43 +0200 | califax | (~califax@user/califx) |
| 2024-04-15 02:11:12 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-15 02:15:10 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-15 02:29:23 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 264 seconds) |
| 2024-04-15 02:36:35 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds) |
| 2024-04-15 02:48:09 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 255 seconds) |
| 2024-04-15 03:10:53 +0200 | mei | (~mei@user/mei) (Ping timeout: 240 seconds) |
| 2024-04-15 03:17:55 +0200 | <haskellbridge> | <sm> which conversation Inst ? |
| 2024-04-15 03:18:21 +0200 | <Inst> | the time i was annoyed at hackage, you suggested i just try to pr it |
| 2024-04-15 03:18:44 +0200 | <Inst> | so of course i'm testing the pr, and nope, doesn't seem to work :( |
| 2024-04-15 03:19:23 +0200 | <haskellbridge> | <sm> really, if so I'm sure I wasn't to rash as to use the word simple ;) |
| 2024-04-15 03:19:40 +0200 | <haskellbridge> | <sm> I thought I suggested flora |
| 2024-04-15 03:20:01 +0200 | <Inst> | i mean that i was talking about how the browse page doesn't show the packages by last upload |
| 2024-04-15 03:21:10 +0200 | <haskellbridge> | <sm> oh right, I remember |
| 2024-04-15 03:21:42 +0200 | <haskellbridge> | <sm> nothing is as simple as it seems.. but relatively, hopefully |
| 2024-04-15 03:21:44 +0200 | <haskellbridge> | <sm> (afk) |
| 2024-04-15 03:31:28 +0200 | mjs2600 | (~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 03:42:39 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-04-15 03:48:11 +0200 | otto_s | (~user@p4ff27ad3.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-04-15 03:48:31 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-04-15 03:49:02 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-15 03:49:50 +0200 | otto_s | (~user@p4ff27773.dip0.t-ipconnect.de) |
| 2024-04-15 03:52:17 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-15 03:53:43 +0200 | werneta | (~werneta@71.83.160.242) |
| 2024-04-15 03:57:01 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-04-15 04:02:11 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 04:11:39 +0200 | She | (haveident@libera/staff/she/her) (Quit: Either upgrades, or the world's ending.) |
| 2024-04-15 04:12:17 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-04-15 04:19:50 +0200 | <Axman6> | It's been a while since I've wrapped a C library, are there any tools which help automate the job? |
| 2024-04-15 04:20:00 +0200 | <Axman6> | any new tools I guess |
| 2024-04-15 04:25:44 +0200 | <probie> | Not exactly a tool, but if a while is longer than 12 years, capi is a "cool new thing" (https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/ffi.html#the-capi-calling-convention) |
| 2024-04-15 04:26:25 +0200 | <geekosaur> | of course, if it's been long enough, it's a cool old thing |
| 2024-04-15 04:30:07 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2024-04-15 04:32:09 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-15 04:33:36 +0200 | <Axman6> | Mostly I'm looking for any assistance for working with/parsing structs I think |
| 2024-04-15 04:33:57 +0200 | <geekosaur> | I think c2hs is still the last word there |
| 2024-04-15 04:40:59 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-15 04:42:39 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-04-15 04:45:27 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2024-04-15 04:46:47 +0200 | td_ | (~td@i53870917.versanet.de) (Ping timeout: 264 seconds) |
| 2024-04-15 04:48:09 +0200 | td_ | (~td@i53870931.versanet.de) |
| 2024-04-15 04:50:51 +0200 | <jackdk> | Last time I wrapped a C lib (many years ago) I struggled to make c2hs do what I want and wrote raw hsc2hs. But libtelnet was small |
| 2024-04-15 04:59:04 +0200 | igemnace | (~ian@user/igemnace) |
| 2024-04-15 05:02:20 +0200 | rosco | (~rosco@aq027043.dynamic.ppp.asahi-net.or.jp) (Ping timeout: 252 seconds) |
| 2024-04-15 05:05:46 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-15 05:10:17 +0200 | bcksl | (~bcksl@user/bcksl) (Quit: \) |
| 2024-04-15 05:10:17 +0200 | end | (~end@user/end/x-0094621) (Quit: end) |
| 2024-04-15 05:11:21 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-04-15 05:11:53 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-15 05:12:18 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-04-15 05:19:19 +0200 | rosco | (~rosco@2001:240:2479:ed58:69a0:efe8:3c3a:6c48) |
| 2024-04-15 05:23:21 +0200 | bcksl | (~bcksl@user/bcksl) |
| 2024-04-15 05:28:32 +0200 | end | (~end@user/end/x-0094621) |
| 2024-04-15 05:29:06 +0200 | JimL | (~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-04-15 05:30:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-15 05:31:58 +0200 | JimL | (~quassel@89.162.16.26) |
| 2024-04-15 05:34:26 +0200 | steew_ | (~steew@user/steew) |
| 2024-04-15 05:35:16 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-15 05:35:16 +0200 | steew | (~steew@user/steew) (Ping timeout: 260 seconds) |
| 2024-04-15 05:35:16 +0200 | steew_ | steew |
| 2024-04-15 05:42:16 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) |
| 2024-04-15 05:51:07 +0200 | reki | (~halloy490@broadband-5-228-80-43.ip.moscow.rt.ru) |
| 2024-04-15 05:54:42 +0200 | xigua | (~xigua@user/xigua) (Read error: Connection reset by peer) |
| 2024-04-15 05:54:56 +0200 | xigua | (~xigua@user/xigua) |
| 2024-04-15 05:56:03 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Quit: Leaving) |
| 2024-04-15 05:56:42 +0200 | xdminsy | (~xdminsy@117.147.70.203) |
| 2024-04-15 06:00:00 +0200 | aforemny_ | (~aforemny@2001:9e8:6cdd:b100:9200:9bf0:8eb2:3efb) |
| 2024-04-15 06:00:09 +0200 | xal | (~xal@mx1.xal.systems) () |
| 2024-04-15 06:00:31 +0200 | aforemny | (~aforemny@2001:9e8:6cf7:a400:800f:dec:5362:bd8) (Ping timeout: 256 seconds) |
| 2024-04-15 06:00:33 +0200 | actioninja | (~actioninj@user/actioninja) (Quit: see ya mane) |
| 2024-04-15 06:00:37 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-15 06:00:57 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-04-15 06:00:59 +0200 | actioninja | (~actioninj@user/actioninja) |
| 2024-04-15 06:04:03 +0200 | hippoid | (~hippoid@c-98-213-162-40.hsd1.il.comcast.net) (Changing host) |
| 2024-04-15 06:04:03 +0200 | hippoid | (~hippoid@user/hippoid) |
| 2024-04-15 06:07:51 +0200 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.2) |
| 2024-04-15 06:11:38 +0200 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-04-15 06:26:33 +0200 | michalz | (~michalz@185.246.207.215) |
| 2024-04-15 06:28:25 +0200 | euleritian | (~euleritia@dynamic-176-004-201-124.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-15 06:28:43 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 06:32:32 +0200 | igemnace | (~ian@user/igemnace) |
| 2024-04-15 06:33:41 +0200 | <geekosaur> | The bridge is down because my Internet connection is out |
| 2024-04-15 06:34:07 +0200 | <geekosaur> | Sending this from my phone |
| 2024-04-15 06:41:19 +0200 | Square | (~Square@user/square) (Ping timeout: 256 seconds) |
| 2024-04-15 06:50:59 +0200 | mei | (~mei@user/mei) (Ping timeout: 264 seconds) |
| 2024-04-15 06:51:32 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 06:58:34 +0200 | <Inst> | thanks for having it up at all :) |
| 2024-04-15 07:01:46 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-04-15 07:02:15 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-04-15 07:04:07 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-04-15 07:16:30 +0200 | greenflower | (~greenflow@2401:4900:1cb9:42b6:23bf:816c:a5c5:7803) |
| 2024-04-15 07:18:03 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-04-15 07:30:07 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-04-15 07:34:32 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-15 07:37:47 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-04-15 07:41:40 +0200 | euleritian | (~euleritia@dynamic-176-004-201-124.176.4.pool.telefonica.de) |
| 2024-04-15 07:48:04 +0200 | greenflower | (~greenflow@2401:4900:1cb9:42b6:23bf:816c:a5c5:7803) (Ping timeout: 250 seconds) |
| 2024-04-15 07:50:14 +0200 | Guest79 | (~Guest79@89.185.25.131) |
| 2024-04-15 07:53:02 +0200 | Guest79 | (~Guest79@89.185.25.131) (Client Quit) |
| 2024-04-15 08:17:03 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-04-15 08:20:49 +0200 | mima | (~mmh@aftr-62-216-211-38.dynamic.mnet-online.de) |
| 2024-04-15 08:21:09 +0200 | califax | (~califax@user/califx) |
| 2024-04-15 08:26:43 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 256 seconds) |
| 2024-04-15 08:28:57 +0200 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2024-04-15 08:29:32 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 08:29:54 +0200 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-04-15 08:30:33 +0200 | yeitrafferin | (~user@2a04:4540:720f:f000:1c8b:86e5:bfad:3ed4) |
| 2024-04-15 08:32:26 +0200 | euleritian | (~euleritia@dynamic-176-004-201-124.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-15 08:33:53 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 08:34:43 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2024-04-15 08:37:00 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-15 08:45:29 +0200 | rekahsoft | (~rekahsoft@184.148.6.204) |
| 2024-04-15 08:47:32 +0200 | igemnace | (~ian@user/igemnace) |
| 2024-04-15 08:52:22 +0200 | Miroboru | (~myrvoll@178-164-114.82.3p.ntebredband.no) |
| 2024-04-15 08:54:34 +0200 | reki | (~halloy490@broadband-5-228-80-43.ip.moscow.rt.ru) (Remote host closed the connection) |
| 2024-04-15 08:54:58 +0200 | rekahsoft | (~rekahsoft@184.148.6.204) (Ping timeout: 256 seconds) |
| 2024-04-15 08:59:12 +0200 | <tomsmeding> | does a Coercible constraint have a runtime representation? If I put a 'Coercible a b =>' constraint on a GADT constructor, will there be an actual dictionary at runtime? |
| 2024-04-15 08:59:21 +0200 | werneta | (~werneta@71.83.160.242) (Quit: leaving) |
| 2024-04-15 09:01:19 +0200 | zetef | (~quassel@5.2.182.99) (Ping timeout: 260 seconds) |
| 2024-04-15 09:04:20 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-04-15 09:05:16 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 260 seconds) |
| 2024-04-15 09:08:20 +0200 | rvalue- | rvalue |
| 2024-04-15 09:12:02 +0200 | <probie> | tomsmeding: It looks like it to me. See the generated core for `foo` in https://play.haskell.org/saved/bpferROD |
| 2024-04-15 09:13:01 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-04-15 09:21:44 +0200 | mei | (~mei@user/mei) (Quit: mei) |
| 2024-04-15 09:23:15 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 09:25:06 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-04-15 09:25:54 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2024-04-15 09:27:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 09:28:32 +0200 | <[Leary]> | Core contains types (including coersions) and calls to `cast` which presumably are all erased. I wouldn't presume the `Coercible` dictionary is represented at runtime based on its presence in Core. The STG might be more illuminating. Or just ask #ghc. |
| 2024-04-15 09:29:11 +0200 | danza | (~francesco@151.37.246.125) |
| 2024-04-15 09:29:50 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-15 09:31:30 +0200 | <lyxia> | the dictionary takes a spot in the constructor arguments even in the cmm |
| 2024-04-15 09:31:54 +0200 | acidjnk | (~acidjnk@p200300d6e714dc36e896bc542a6281cf.dip0.t-ipconnect.de) |
| 2024-04-15 09:34:04 +0200 | <probie> | [Leary]: You're right, relying on core is not actually indicative. However, looking at the generated assembly, the Coercible dictionary definitely gets passed to the constructor, as to what it contains, I'm not sure |
| 2024-04-15 09:37:25 +0200 | <[Leary]> | I imagine it's entirely vestigial. |
| 2024-04-15 09:38:34 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 256 seconds) |
| 2024-04-15 09:38:39 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-15 09:39:47 +0200 | <probie> | A pointer to whatever `GHC.Types.MkCoercible_con_info` is |
| 2024-04-15 09:43:00 +0200 | danza | (~francesco@151.37.246.125) (Ping timeout: 268 seconds) |
| 2024-04-15 09:45:03 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-15 09:48:52 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-04-15 09:49:04 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-04-15 09:52:42 +0200 | chele | (~chele@user/chele) |
| 2024-04-15 10:00:50 +0200 | Core2410 | (~rosco@2001:240:242c:d62d:b170:9c25:b014:c1d3) |
| 2024-04-15 10:02:26 +0200 | rosco | (~rosco@2001:240:2479:ed58:69a0:efe8:3c3a:6c48) (Ping timeout: 268 seconds) |
| 2024-04-15 10:04:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 10:05:02 +0200 | <mesaoptimizer> | how do I get auto-import in emacs in haskell? I'm using eglot and HLS |
| 2024-04-15 10:06:07 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-04-15 10:12:41 +0200 | <tomsmeding> | thanks all! I can't imagine there to be actual interesting data in the MkCoercible object though; I guess (from grepping ghc) it ought to be a ~R# object inside, which perhaps has no runtime representation? |
| 2024-04-15 10:13:06 +0200 | Rodney_ | (~Rodney@176.254.244.83) (Ping timeout: 252 seconds) |
| 2024-04-15 10:21:42 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-04-15 10:21:57 +0200 | rosco | (~rosco@2001:240:242c:d62d:de59:f92f:5995:ec84) |
| 2024-04-15 10:22:08 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) |
| 2024-04-15 10:22:08 +0200 | mei | (~mei@user/mei) (Killed (calcium.libera.chat (Nickname regained by services))) |
| 2024-04-15 10:22:13 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 10:22:16 +0200 | Miroboru | (~myrvoll@178-164-114.82.3p.ntebredband.no) (Ping timeout: 260 seconds) |
| 2024-04-15 10:22:38 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) (Read error: Connection reset by peer) |
| 2024-04-15 10:24:08 +0200 | Core2410 | (~rosco@2001:240:242c:d62d:b170:9c25:b014:c1d3) (Ping timeout: 260 seconds) |
| 2024-04-15 10:25:03 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) |
| 2024-04-15 10:29:18 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-04-15 10:29:35 +0200 | gehmehgeh | gmg |
| 2024-04-15 10:29:45 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-15 10:31:30 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-04-15 10:37:10 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-15 10:42:44 +0200 | Etabeta13 | (~Etabeta1@151.30.10.212) |
| 2024-04-15 10:43:51 +0200 | Etabeta1 | (~Etabeta1@user/meow/Etabeta1) (Ping timeout: 256 seconds) |
| 2024-04-15 10:43:51 +0200 | Etabeta13 | Etabeta1 |
| 2024-04-15 10:43:55 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) (Remote host closed the connection) |
| 2024-04-15 10:44:17 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) |
| 2024-04-15 10:48:10 +0200 | Miroboru | (~myrvoll@178-164-114.82.3p.ntebredband.no) |
| 2024-04-15 10:55:07 +0200 | ft | (~ft@p4fc2a20e.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-04-15 10:55:36 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2024-04-15 10:55:42 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) |
| 2024-04-15 11:11:17 +0200 | zetef | (~quassel@5.2.182.99) (Ping timeout: 272 seconds) |
| 2024-04-15 11:11:30 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 11:12:24 +0200 | img | (~img@user/img) |
| 2024-04-15 11:18:24 +0200 | Pixi` | (~Pixi@user/pixi) |
| 2024-04-15 11:21:35 +0200 | Pixi | (~Pixi@user/pixi) (Ping timeout: 264 seconds) |
| 2024-04-15 11:25:45 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-15 11:29:35 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-04-15 11:38:41 +0200 | raoul | (~raoul@95.179.203.88) (Remote host closed the connection) |
| 2024-04-15 11:49:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 11:50:05 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 11:51:26 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) (Read error: Connection reset by peer) |
| 2024-04-15 11:52:21 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) |
| 2024-04-15 12:03:59 +0200 | Core5214 | (~rosco@2001:240:242c:d62d:8006:d50:9606:4eb4) |
| 2024-04-15 12:06:20 +0200 | danse-nr3 | (~danse-nr3@151.37.246.125) (Ping timeout: 260 seconds) |
| 2024-04-15 12:06:53 +0200 | rosco | (~rosco@2001:240:242c:d62d:de59:f92f:5995:ec84) (Ping timeout: 240 seconds) |
| 2024-04-15 12:08:38 +0200 | zfnmxt | (~zfnmxt@user/zfnmxt) (Remote host closed the connection) |
| 2024-04-15 12:11:16 +0200 | zfnmxt | (~zfnmxt@user/zfnmxt) |
| 2024-04-15 12:18:18 +0200 | acidjnk | (~acidjnk@p200300d6e714dc36e896bc542a6281cf.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-04-15 12:20:39 +0200 | <lyxia> | yes |
| 2024-04-15 12:30:38 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) (Read error: Connection reset by peer) |
| 2024-04-15 12:33:01 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) |
| 2024-04-15 12:33:02 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) (Changing host) |
| 2024-04-15 12:33:02 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) |
| 2024-04-15 12:40:04 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-04-15 12:40:30 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2024-04-15 12:41:04 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-04-15 13:00:20 +0200 | zetef | (~quassel@5.2.182.99) (Ping timeout: 268 seconds) |
| 2024-04-15 13:00:40 +0200 | danse-nr3 | (~danse-nr3@151.43.234.51) |
| 2024-04-15 13:01:51 +0200 | Core5214 | (~rosco@2001:240:242c:d62d:8006:d50:9606:4eb4) (Read error: Connection reset by peer) |
| 2024-04-15 13:02:05 +0200 | rosco | (~rosco@aq052236.dynamic.ppp.asahi-net.or.jp) |
| 2024-04-15 13:02:23 +0200 | haocrcmt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 264 seconds) |
| 2024-04-15 13:02:34 +0200 | danse-nr3 | (~danse-nr3@151.43.234.51) (Remote host closed the connection) |
| 2024-04-15 13:02:59 +0200 | danse-nr3 | (~danse-nr3@151.43.234.51) |
| 2024-04-15 13:03:05 +0200 | haocrcmt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-04-15 13:03:52 +0200 | Core6846 | (~rosco@aq052236.dynamic.ppp.asahi-net.or.jp) |
| 2024-04-15 13:04:01 +0200 | rosco | (~rosco@aq052236.dynamic.ppp.asahi-net.or.jp) (Read error: Connection reset by peer) |
| 2024-04-15 13:14:42 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-04-15 13:36:38 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-15 13:37:00 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 13:42:05 +0200 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.2) |
| 2024-04-15 13:49:44 +0200 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2024-04-15 13:52:16 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-04-15 14:03:43 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-04-15 14:08:02 +0200 | igemnace | (~ian@user/igemnace) |
| 2024-04-15 14:09:49 +0200 | anon8697 | (~anon1123@catv-176-63-0-119.catv.fixed.vodafone.hu) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 14:10:45 +0200 | anon1123 | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) |
| 2024-04-15 14:10:53 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 240 seconds) |
| 2024-04-15 14:13:32 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-04-15 14:15:47 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Ping timeout: 256 seconds) |
| 2024-04-15 14:19:46 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 246 seconds) |
| 2024-04-15 14:20:29 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-15 14:20:56 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-04-15 14:23:24 +0200 | chele_ | (~chele@user/chele) |
| 2024-04-15 14:24:14 +0200 | chele | (~chele@user/chele) (Read error: Connection reset by peer) |
| 2024-04-15 14:25:00 +0200 | Nixkernal | (~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) (Ping timeout: 252 seconds) |
| 2024-04-15 14:26:10 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-04-15 14:26:40 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-04-15 14:27:41 +0200 | tv | (~tv@user/tv) (Quit: derp) |
| 2024-04-15 14:28:14 +0200 | tv | (~tv@user/tv) |
| 2024-04-15 14:31:04 +0200 | r5c4571lh01987 | (rscastilho@179.221.142.8) |
| 2024-04-15 14:31:51 +0200 | r5c4571lh01987 | (rscastilho@179.221.142.8) (Remote host closed the connection) |
| 2024-04-15 14:32:09 +0200 | Nixkernal | (~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) |
| 2024-04-15 14:41:24 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-04-15 14:41:24 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2024-04-15 14:48:29 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-15 14:48:36 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 14:50:47 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2024-04-15 14:54:27 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-15 14:55:17 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-15 14:56:00 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 14:59:04 +0200 | PiDelport | (uid25146@id-25146.lymington.irccloud.com) |
| 2024-04-15 15:04:32 +0200 | n8n | (n8n@user/n8n) |
| 2024-04-15 15:16:42 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 15:17:54 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-04-15 15:18:36 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Quit: WeeChat 4.2.1) |
| 2024-04-15 15:20:00 +0200 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) |
| 2024-04-15 15:20:53 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds) |
| 2024-04-15 15:27:44 +0200 | She | (haveident@libera/staff/she/her) |
| 2024-04-15 15:28:26 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-04-15 15:30:02 +0200 | <Inst> | EvanR: Haskell is essentially a scripting language, isn't it? :) |
| 2024-04-15 15:30:05 +0200 | <Inst> | That's what purity amounts to |
| 2024-04-15 15:30:27 +0200 | <Inst> | The pure part of your program is essentially a high-performance library that's called by the impure part of your program |
| 2024-04-15 15:30:36 +0200 | <Inst> | for data calculation |
| 2024-04-15 15:30:42 +0200 | <Inst> | and the impure part is essentially a Python ;) |
| 2024-04-15 15:35:09 +0200 | <EvanR> | a useful difference from other languages is your whole program is pure |
| 2024-04-15 15:35:29 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 15:36:35 +0200 | <Inst> | "technically" |
| 2024-04-15 15:37:10 +0200 | <Inst> | since all the statements are essentially quoted |
| 2024-04-15 15:37:35 +0200 | <Inst> | but yeah, massive state reduction is actually good for scripting |
| 2024-04-15 15:38:03 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection) |
| 2024-04-15 15:39:07 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-04-15 15:39:42 +0200 | masaeedu | (~masaeedu@user/masaeedu) (Read error: Connection reset by peer) |
| 2024-04-15 15:40:30 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-04-15 15:42:21 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-04-15 15:42:51 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-15 15:45:51 +0200 | masaeedu | (~masaeedu@user/masaeedu) |
| 2024-04-15 15:45:51 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-15 15:46:15 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 15:50:33 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-15 15:53:28 +0200 | <EvanR> | quotation is a thing when you do template haskell |
| 2024-04-15 15:54:03 +0200 | <EvanR> | speaking of code instead of using code |
| 2024-04-15 15:58:15 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-04-15 16:00:19 +0200 | euleritian | (~euleritia@dynamic-176-004-212-165.176.4.pool.telefonica.de) |
| 2024-04-15 16:00:49 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:01:04 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-04-15 16:01:20 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-04-15 16:04:21 +0200 | <Inst> | I mean in the sense that the IO type functions analogously to quotation in Lisps |
| 2024-04-15 16:04:55 +0200 | <Inst> | I'm still stunned by the fact that if you, in an impure language, call a function with statements as arguments, the statements run first |
| 2024-04-15 16:05:09 +0200 | <Inst> | and I've heard the effectfulness of the statements is actually UB when more than one statement is used |
| 2024-04-15 16:05:37 +0200 | <EvanR> | no |
| 2024-04-15 16:06:11 +0200 | <Inst> | at least in C |
| 2024-04-15 16:06:18 +0200 | <Inst> | order of statement execution isn't specified |
| 2024-04-15 16:06:19 +0200 | Inst | giggles |
| 2024-04-15 16:07:00 +0200 | <EvanR> | IO isn't like quotation, since you don't have access to syntax at any point |
| 2024-04-15 16:07:59 +0200 | <Inst> | i mean IO wraps primitives that trigger effects, and the design of it with a 0 bit RealWorld# token controls the sequencing of effects |
| 2024-04-15 16:08:06 +0200 | <EvanR> | in C do the statements "run first?" If it contains subexpressions they need to be evaluated which could cause side effects |
| 2024-04-15 16:09:02 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Read error: Connection reset by peer) |
| 2024-04-15 16:09:02 +0200 | <Inst> | contain 0 or more, technically, since, well, pure :) |
| 2024-04-15 16:12:58 +0200 | <Inst> | btw sm: I have the sort working, but it's ugly, it's based on corrupting a template file somewhere with two sort('lastUpload')s ;_; |
| 2024-04-15 16:14:24 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:15:33 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Read error: Connection reset by peer) |
| 2024-04-15 16:18:18 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) (Ping timeout: 252 seconds) |
| 2024-04-15 16:19:29 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 16:22:09 +0200 | Arsen | (arsen@gentoo/developer/managarm.dev.Arsen) (Quit: Quit.) |
| 2024-04-15 16:23:54 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:24:00 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 255 seconds) |
| 2024-04-15 16:27:28 +0200 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-04-15 16:28:00 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) |
| 2024-04-15 16:28:02 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Read error: Connection reset by peer) |
| 2024-04-15 16:30:34 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:36:06 +0200 | AlexNoo_ | AlexNoo |
| 2024-04-15 16:36:07 +0200 | <glguy> | Order of execution in C is partially defined. All the function arguments evaluate before the function is called, for example. But it's perhaps less defined than you'd guess https://en.cppreference.com/w/c/language/eval_order |
| 2024-04-15 16:37:23 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Read error: Connection reset by peer) |
| 2024-04-15 16:39:44 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:40:17 +0200 | CrunchyFlakes_ | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 16:44:16 +0200 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) |
| 2024-04-15 16:45:06 +0200 | igemnace | (~ian@user/igemnace) |
| 2024-04-15 16:45:52 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Ping timeout: 260 seconds) |
| 2024-04-15 16:48:04 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Read error: Connection reset by peer) |
| 2024-04-15 16:49:08 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) |
| 2024-04-15 16:50:28 +0200 | dcompoze | (~dcompoze@dcsoftware.org) |
| 2024-04-15 16:52:10 +0200 | dcompoze | (~dcompoze@dcsoftware.org) (Client Quit) |
| 2024-04-15 16:55:50 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-15 16:56:26 +0200 | Arsen | (~arsen@gentoo/developer/managarm.dev.Arsen) |
| 2024-04-15 16:58:26 +0200 | dcompoze | (~dcompoze@dcsoftware.org) |
| 2024-04-15 16:58:36 +0200 | dcompoze | (~dcompoze@dcsoftware.org) (Client Quit) |
| 2024-04-15 17:00:39 +0200 | danse-nr3 | (~danse-nr3@151.43.234.51) (Ping timeout: 252 seconds) |
| 2024-04-15 17:00:42 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-04-15 17:00:52 +0200 | danse-nr3 | (~danse-nr3@151.57.231.212) |
| 2024-04-15 17:01:42 +0200 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.2) |
| 2024-04-15 17:05:15 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:d3e2:41ab:d1ec:83b3:f5ca:bc85) (Ping timeout: 260 seconds) |
| 2024-04-15 17:08:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 17:12:20 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-15 17:14:44 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 17:17:13 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 17:18:12 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-15 17:18:17 +0200 | Arsen | (~arsen@gentoo/developer/managarm.dev.Arsen) (Quit: Quit.) |
| 2024-04-15 17:18:29 +0200 | Arsen | (~arsen@gentoo/developer/managarm.dev.Arsen) |
| 2024-04-15 17:18:42 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-04-15 17:19:05 +0200 | euleritian | (~euleritia@dynamic-176-004-212-165.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-15 17:19:25 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 17:22:07 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 268 seconds) |
| 2024-04-15 17:23:12 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:2c60:c178:6804:dd74:ec24:3be4) |
| 2024-04-15 17:27:39 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-04-15 17:30:13 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2024-04-15 17:32:12 +0200 | <Lycurgus> | order of execution is always well defined |
| 2024-04-15 17:32:32 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Remote host closed the connection) |
| 2024-04-15 17:32:43 +0200 | <Lycurgus> | in ordinary programming languages like c |
| 2024-04-15 17:32:48 +0200 | <Lycurgus> | and haskell |
| 2024-04-15 17:32:50 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 17:32:50 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-04-15 17:33:04 +0200 | <Lycurgus> | ordinary generic |
| 2024-04-15 17:33:24 +0200 | <Lycurgus> | a purpose built lang or dsl could decide ofc |
| 2024-04-15 17:33:41 +0200 | <Lycurgus> | otherwise the programmer does |
| 2024-04-15 17:34:26 +0200 | <Lycurgus> | in the non generic case the order is irrelevant |
| 2024-04-15 17:34:29 +0200 | JeremyB99 | (~JeremyB99@2607:fb90:2c60:c178:6804:dd74:ec24:3be4) (Ping timeout: 240 seconds) |
| 2024-04-15 17:35:03 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-15 17:36:49 +0200 | <c_wraith> | I'm not sure what you mean by "well-defined" there. |
| 2024-04-15 17:36:54 +0200 | <Lycurgus> | would apply locally in cases like the procedure division of cobol, or calcs in rpg |
| 2024-04-15 17:37:24 +0200 | <Lycurgus> | unless ofc the lang itself isn |
| 2024-04-15 17:37:32 +0200 | <c_wraith> | are you including "unspecified" as part of defined? |
| 2024-04-15 17:37:34 +0200 | <Lycurgus> | which would be odd |
| 2024-04-15 17:38:11 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:7c5:4d04:6cf3:f0f9:5199:7b3) |
| 2024-04-15 17:38:17 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:7c5:4d04:6cf3:f0f9:5199:7b3) (Read error: Connection reset by peer) |
| 2024-04-15 17:38:25 +0200 | <Lycurgus> | c_wraith, no, why would i do that? have you observed me to talk like that wo explanation? |
| 2024-04-15 17:38:58 +0200 | <Lycurgus> | in statement oriented langs |
| 2024-04-15 17:39:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-04-15 17:39:17 +0200 | <c_wraith> | well, because I'm trying to match what you're saying to how C works. foo(bar(), baz()) does not specify whether bar() or baz() is called first in C. either order is valid. |
| 2024-04-15 17:39:41 +0200 | <Lycurgus> | the order is implicitly the programmers specified serial execution plus any task constructs |
| 2024-04-15 17:40:02 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 17:40:24 +0200 | <Lycurgus> | ofc it does |
| 2024-04-15 17:40:49 +0200 | <Lycurgus> | in whatever constructs spec it occurs |
| 2024-04-15 17:41:00 +0200 | <Lycurgus> | per whatever level C11, etc |
| 2024-04-15 17:41:12 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-15 17:41:25 +0200 | <Lycurgus> | back to K&R |
| 2024-04-15 17:43:18 +0200 | <Lycurgus> | saw this on the log and felt compelled to public service. You're Welcome! |
| 2024-04-15 17:43:21 +0200 | <c_wraith> | check glguy's link above. |
| 2024-04-15 17:43:23 +0200 | <jle`> | it looks like according to the C spec, the compiler is allowed to decide which one gets called first, and so if the programmer wants control, they have to explicitly sequence it |
| 2024-04-15 17:43:34 +0200 | <jle`> | https://en.cppreference.com/w/c/language/eval_order |
| 2024-04-15 17:43:38 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Lycurgus) |
| 2024-04-15 17:43:45 +0200 | <jle`> | oh they quit |
| 2024-04-15 17:43:59 +0200 | <c_wraith> | and that's the same link glguy provided above |
| 2024-04-15 17:44:26 +0200 | <jle`> | ah yeah i saw they joined after the think was posted, but then i realized that they read it through the logs |
| 2024-04-15 17:44:30 +0200 | <jle`> | quite a mystery |
| 2024-04-15 17:45:22 +0200 | <jle`> | also reading through the link it just occurred to me that it's kind of wierd that version 99 came out before version 11 |
| 2024-04-15 17:45:27 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Ping timeout: 256 seconds) |
| 2024-04-15 17:45:46 +0200 | <c_wraith> | I always found that lack of ordering in C to be really inconvenient for things like recursive-descent parsers. |
| 2024-04-15 17:46:11 +0200 | <c_wraith> | Lots of mandatory naming of subexpressions to control order of evaluation. |
| 2024-04-15 17:49:15 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:7c5:4d04:6cf3:f0f9:5199:7b3) |
| 2024-04-15 17:49:24 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:7c5:4d04:6cf3:f0f9:5199:7b3) (Read error: Connection reset by peer) |
| 2024-04-15 17:49:47 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2024-04-15 17:49:53 +0200 | <Lycurgus> | so |
| 2024-04-15 17:50:20 +0200 | <Lycurgus> | the fact the spec allows the compiler to decide when the programmer doesn ... ? |
| 2024-04-15 17:50:29 +0200 | <Lycurgus> | ??? |
| 2024-04-15 17:52:11 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2024-04-15 17:52:32 +0200 | euleritian | (~euleritia@dynamic-176-004-212-165.176.4.pool.telefonica.de) |
| 2024-04-15 17:53:16 +0200 | <Lycurgus> | take ur time, i'll respond if it's called for; this is kinda an important point |
| 2024-04-15 17:53:39 +0200 | Lycurgus | (~juan@user/Lycurgus) (Client Quit) |
| 2024-04-15 17:57:40 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3140-0274-8942-7e1a-ff10-b141.rev.sfr.net) |
| 2024-04-15 17:58:16 +0200 | <jle`> | that's pretty much the definition of "undefined behavior" in the context of progamming languages, though. the compiler is allowed to decide instead of the spec. in ie multithreaded situations it could very well be nondeterministic |
| 2024-04-15 17:58:27 +0200 | remedan | (~remedan@ip-78-102-118-253.bb.vodafone.cz) (Quit: Bye!) |
| 2024-04-15 17:58:29 +0200 | dcompoze | (~dcompoze@dcsoftware.org) |
| 2024-04-15 17:59:34 +0200 | <jle`> | although i don't mean to conflate undefined behavior with nondeterministic behavior |
| 2024-04-15 18:00:09 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-04-15 18:01:21 +0200 | <jle`> | but my main point is that order of evaluation in this situation is classified as "undefined" within the standard terminology when talking about programming languages |
| 2024-04-15 18:01:44 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2024-04-15 18:01:45 +0200 | acidjnk | (~acidjnk@p200300d6e714dc36e896bc542a6281cf.dip0.t-ipconnect.de) |
| 2024-04-15 18:02:03 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-04-15 18:02:49 +0200 | <Lycurgus> | ok, this thread had an origin I don't want to be associated with or seem to have encouraged but I do think my point is clear and well made and ofc public |
| 2024-04-15 18:03:40 +0200 | <Lycurgus> | the last comment is in the class of those I won't respond to but I will continue to see if one is warranted |
| 2024-04-15 18:04:27 +0200 | <Lycurgus> | bbl |
| 2024-04-15 18:04:51 +0200 | Lycurgus | (~juan@user/Lycurgus) (Client Quit) |
| 2024-04-15 18:05:32 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 18:05:44 +0200 | <janus> | what's with this bloated language... urgh |
| 2024-04-15 18:06:08 +0200 | danse-nr3 | (~danse-nr3@151.57.231.212) (Ping timeout: 260 seconds) |
| 2024-04-15 18:06:26 +0200 | <janus> | jle`: i applaud you for trying, i would have given up already |
| 2024-04-15 18:07:49 +0200 | Square2 | (~Square4@user/square) |
| 2024-04-15 18:07:56 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2024-04-15 18:08:21 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 18:08:34 +0200 | <segfaultfizzbuzz> | says someone on the internet: "people coming from a functional programming background mention higher kinded types as a better alternative to macros in some cases" -- ?? |
| 2024-04-15 18:10:38 +0200 | ft | (~ft@p4fc2a20e.dip0.t-ipconnect.de) |
| 2024-04-15 18:11:18 +0200 | remedan | (~remedan@ip-78-102-118-253.bb.vodafone.cz) |
| 2024-04-15 18:13:02 +0200 | foul_owl | (~kerry@185.219.141.162) (Read error: Connection reset by peer) |
| 2024-04-15 18:14:41 +0200 | <nitrix> | Macros usually are in the form of a preprocessing step that operates on lexical tokens. |
| 2024-04-15 18:15:27 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 18:15:48 +0200 | <nitrix> | It's mediocre at best when you need a separate language in your language just to do meta things that, well, most of the time are just to express very general things that the existing type system cannot make generic enough. |
| 2024-04-15 18:16:29 +0200 | swistak | (~swistak@185.21.216.141) (Ping timeout: 240 seconds) |
| 2024-04-15 18:17:10 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 18:17:24 +0200 | <nitrix> | Haskell isn't completely absolved from the issue, it still has Template Haskell as its own DSL for meta programming, but you don't use it nearly as much as, say, C macros, because the type system is already quite competent. |
| 2024-04-15 18:18:04 +0200 | swistak | (~swistak@185.21.216.141) |
| 2024-04-15 18:19:35 +0200 | <nitrix> | Kinds lets you have specific type signatures be manipulated at the type level. Just like you can have higher-order functions on values, you can have higher-order functions on types. |
| 2024-04-15 18:20:31 +0200 | <Inst> | about the only thing macros can do that functions can't is codewalk, which makes me cry every day :( |
| 2024-04-15 18:20:39 +0200 | <Inst> | then again, even in languages with good codewalking, the macros can be ugly :( |
| 2024-04-15 18:21:17 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds) |
| 2024-04-15 18:21:46 +0200 | <Inst> | I went to Julia to get a taste of macros, since Julia seems to be alive and reasonably vibrant (everyone's fighting to be Rust's little sister) compared to CLisp, but apparently codewalking with Julia macros is painful |
| 2024-04-15 18:23:29 +0200 | <EvanR> | I feel like Lycurgus could be vindicated maybe by saying regardless of specs, every implementation of C any of us ever used has some well defined but perhaps unknown ordering |
| 2024-04-15 18:23:29 +0200 | <nitrix> | Even the ultimate macro language, Lisp, it's miserable having to quote/quasiquote. It's like programming inside of a string and having to escape all the sensitive characters constantly. |
| 2024-04-15 18:24:16 +0200 | <segfaultfizzbuzz> | i am playing with rust macros for the first time right now |
| 2024-04-15 18:24:31 +0200 | <segfaultfizzbuzz> | and am debating about whether i should be writing repetitious boilerplate or writing mostly in macros |
| 2024-04-15 18:24:37 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2024-04-15 18:24:46 +0200 | <nitrix> | Rust macros are interesting because they've given types to the lexical tokens so the errors are less. Still annoying though. |
| 2024-04-15 18:24:56 +0200 | <Lycurgus> | a vindicator! I am so charmed. |
| 2024-04-15 18:25:05 +0200 | <segfaultfizzbuzz> | writing quote! {} with no compiler help is kinda scary tho |
| 2024-04-15 18:25:14 +0200 | <EvanR> | are you logging out and lurking logs only? lol |
| 2024-04-15 18:25:46 +0200 | <ski> | type synonyms are kinda macros, at the type level. from this perspective, `LiberalTypeSynonyms' allow higher-order type macros |
| 2024-04-15 18:26:12 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-04-15 18:26:26 +0200 | <nitrix> | I think it'd only be higher-order if it's at least the form * -> * |
| 2024-04-15 18:26:33 +0200 | <ski> | (also CLisp is a particular implementation of Common Lisp) |
| 2024-04-15 18:26:45 +0200 | <Lycurgus> | EvanR, after this if there's a comment to be made in this thread i'll do it tommorow |
| 2024-04-15 18:27:37 +0200 | <ski> | well, `ApInt Id', given `type Id a = a; type ApInt f = f Int', would be an example. here `ApInt' has kind `(* -> *) -> *', yea |
| 2024-04-15 18:27:37 +0200 | <Lycurgus> | at one level 'the programmers specified order' is simplicity itself but there's a lot to unpack in this actual thread and the matter of C and its specs |
| 2024-04-15 18:27:54 +0200 | <masaeedu> | EvanR: unfortunately if the cppreference page is to be believed, not even this is true |
| 2024-04-15 18:27:56 +0200 | <Lycurgus> | i apologize if articulate english is a problem |
| 2024-04-15 18:29:16 +0200 | <Lycurgus> | so i take it that when a spec says that behaviour is undefined that is informing you in natural language abouit the definition of the language |
| 2024-04-15 18:29:31 +0200 | <Lycurgus> | *about |
| 2024-04-15 18:30:16 +0200 | <Lycurgus> | also the class of langs is important and i've delimited them |
| 2024-04-15 18:31:30 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-15 18:31:35 +0200 | foul_owl | (~kerry@185.219.141.164) |
| 2024-04-15 18:31:37 +0200 | <Lycurgus> | in some general purpose langs, prolog being the main one that comes to mind, the actual order specified by the programmer is not ofc like in C |
| 2024-04-15 18:33:53 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 18:34:09 +0200 | <Lycurgus> | 'well defined' and 'perhaps unkown' for an ordering are antithetical opposites and so ofc i'm not saying that for any correct C implementation |
| 2024-04-15 18:34:41 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-04-15 18:35:51 +0200 | <Lycurgus> | *unknown |
| 2024-04-15 18:36:19 +0200 | Square2 | (~Square4@user/square) (Ping timeout: 246 seconds) |
| 2024-04-15 18:38:02 +0200 | <Lycurgus> | in pl u got ur socalled flow of satisfaction which serves the same purpose, seeya tommorrow |
| 2024-04-15 18:38:10 +0200 | dcompoze | (~dcompoze@dcsoftware.org) (Quit: Weechat 4.2.2) |
| 2024-04-15 18:38:20 +0200 | dcompoze | (~dcompoze@dcsoftware.org) |
| 2024-04-15 18:38:29 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Lycurgus) |
| 2024-04-15 18:38:46 +0200 | <nitrix> | This isn't quite the place for that but C has sequence points. Not everything is guaranteed to happen in the specified order. |
| 2024-04-15 18:40:15 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3140-0274-8942-7e1a-ff10-b141.rev.sfr.net) (Remote host closed the connection) |
| 2024-04-15 18:40:36 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3140-0274-8942-7e1a-ff10-b141.rev.sfr.net) |
| 2024-04-15 18:40:55 +0200 | <nitrix> | Instructions can be re-ordered as long as it's semantically not observable, similar to Haskell's purity + lazy evaluation combo, but as a general rule for optimizations. |
| 2024-04-15 18:43:22 +0200 | <nitrix> | Excluding optimizations and sequence points, the leftover has undefined behavior. e.g. i++ + ++i. |
| 2024-04-15 18:49:51 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 18:51:15 +0200 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Quit: Leaving) |
| 2024-04-15 18:51:53 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 18:54:53 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 272 seconds) |
| 2024-04-15 18:55:11 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 18:55:21 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-04-15 18:55:25 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-04-15 18:55:48 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-04-15 18:56:39 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-04-15 18:57:30 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-15 18:58:47 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 19:02:08 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2024-04-15 19:04:04 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3140-0274-8942-7e1a-ff10-b141.rev.sfr.net) (Remote host closed the connection) |
| 2024-04-15 19:04:22 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 19:05:44 +0200 | dcompoze | (~dcompoze@dcsoftware.org) (Quit: Weechat 4.2.2) |
| 2024-04-15 19:05:45 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 19:06:38 +0200 | zetef | (~quassel@5.2.182.99) (Ping timeout: 268 seconds) |
| 2024-04-15 19:11:09 +0200 | dcoutts | (~duncan@cpc69400-oxfd27-2-0-cust750.4-3.cable.virginm.net) |
| 2024-04-15 19:13:32 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 19:15:24 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 19:16:08 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 19:22:11 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-04-15 19:23:06 +0200 | Square | (~Square@user/square) |
| 2024-04-15 19:23:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 19:28:06 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 19:33:28 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-04-15 19:34:33 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-15 19:44:07 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-15 19:45:51 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-04-15 19:45:57 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 19:51:02 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-04-15 19:51:13 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 19:53:12 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 19:55:08 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-15 19:57:33 +0200 | mei | (~mei@user/mei) |
| 2024-04-15 20:03:24 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 20:05:27 +0200 | <monochrom> | Although, I am not sure why evaluation order ruins recursive descent parsing, even in C. In Haskell, recursive descent parsing is done monadically or at least applicatively, >>= and <*> become the equivalent of programmer-specified sequence points; this is no better than in C. |
| 2024-04-15 20:08:17 +0200 | <dolio> | I suppose depending on exactly how it looks, certain C expressions do not have a defined sequencing. So you can write an ill-defined parser in that respect. |
| 2024-04-15 20:08:29 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2024-04-15 20:08:30 +0200 | <monochrom> | So I guess s/I am not sure why evaluation order ruins recursive descent parsing, even in C/I am not sure why you would expect evaluation order to not ruin recursive descent parsing, even in Haskell/ |
| 2024-04-15 20:08:31 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 20:09:52 +0200 | <dolio> | When you nest all the monad combinators, it all has a well-defined sequence according the parser. |
| 2024-04-15 20:11:05 +0200 | <dolio> | The C case would be like using algebraic effects to write things direct style, but then the algebraic effects stuff telling you that `f (g x) (h y)` has no defined sequencing between the effects of `g` and `h`. |
| 2024-04-15 20:11:23 +0200 | <monochrom> | Yeah but exactly what I was addressing. In Haskell, such a parser goes like "do { e1 <- subexpr; op <- operator; e2 <- subexpr; pure f(e1, op, e2) }". Even in Haskell you would not write it as "f(subexpr(), operator(), subexpr())". So I would not expect anyone to write like that in C. |
| 2024-04-15 20:11:41 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2024-04-15 20:13:44 +0200 | <dolio> | Algebraic effect systems generally don't do that, from what I've seen. |
| 2024-04-15 20:13:46 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2024-04-15 20:13:50 +0200 | <dolio> | I.E. C sucks. :) |
| 2024-04-15 20:14:57 +0200 | <monochrom> | Ugh I didn't expect algebraic effects and C to appear together in the same sentence like that haha. |
| 2024-04-15 20:16:19 +0200 | <monochrom> | And perhaps s/evaluation order/effect order/g for much better diction. |
| 2024-04-15 20:16:47 +0200 | <dolio> | I mean, there are other examples, too. |
| 2024-04-15 20:16:59 +0200 | <dolio> | Racket tells you what order arguments are evaluated. |
| 2024-04-15 20:17:41 +0200 | <dolio> | C is probably the odd one at this point. |
| 2024-04-15 20:21:11 +0200 | <mauke> | what was that article that described C as being based on a formal mathematical concept, the monoid? |
| 2024-04-15 20:21:32 +0200 | <dolio> | Because the syntax is text? |
| 2024-04-15 20:21:35 +0200 | <mauke> | yeah |
| 2024-04-15 20:21:43 +0200 | <c_wraith> | monochrom: usually I write parsers in an applicative style. Sure, the operators count as sequence points, but they do it without me being required to invent names for their results. |
| 2024-04-15 20:21:44 +0200 | <monochrom> | I bet the original undocumented intention had just two orders in mind and the committee couldn't agree to ban either one. |
| 2024-04-15 20:22:14 +0200 | <dolio> | Yeah, should be right-to-left, right? :) |
| 2024-04-15 20:22:16 +0200 | <mauke> | it had something like, "C refers to strings as char * using a notation borrowed from Kleene" |
| 2024-04-15 20:22:30 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 20:22:51 +0200 | <c_wraith> | I told my friend about this, and she dug up her (paper!) copy of the C99 spec, and was like "yep, it says 'shall'". Which is the C99 way of saying "any program that doesn't do this is out of spec". |
| 2024-04-15 20:23:12 +0200 | yeitrafferin | (~user@2a04:4540:720f:f000:1c8b:86e5:bfad:3ed4) (Remote host closed the connection) |
| 2024-04-15 20:24:29 +0200 | <c_wraith> | The C99 spec is remarkably circuitous about undefined behavior. It rarely says anything is. It just describes what valid programs do, and leaves it up to you to infer what it thinks of programs that do otherwise. |
| 2024-04-15 20:24:30 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 20:24:48 +0200 | <mauke> | most C programs have undefined behavior :-) |
| 2024-04-15 20:24:56 +0200 | <c_wraith> | I'm pretty sure that's "all" |
| 2024-04-15 20:25:00 +0200 | <mauke> | the standard just characterizes the exceptional cases that don't |
| 2024-04-15 20:25:23 +0200 | <monochrom> | And then perhaps languages after C saw the annoyance and decided to not follow, leaving C as the oddity in hindsight. |
| 2024-04-15 20:25:47 +0200 | <dolio> | Is `f(g(x), h(x))` undefined? Or is only the sequencing undefined? |
| 2024-04-15 20:25:55 +0200 | <Franciman> | mauke: most haskell programs too |
| 2024-04-15 20:25:59 +0200 | <mauke> | sequencing is unspecified* |
| 2024-04-15 20:26:01 +0200 | <Franciman> | since there is no formal semantics |
| 2024-04-15 20:26:10 +0200 | <c_wraith> | dolio: it's undefined if g(x) and h(x) mutate the same object. |
| 2024-04-15 20:26:17 +0200 | <dolio> | Okay. |
| 2024-04-15 20:26:18 +0200 | <mauke> | c_wraith: no |
| 2024-04-15 20:26:25 +0200 | <mauke> | function calls don't overlap |
| 2024-04-15 20:26:45 +0200 | <mauke> | either g executes first, or h |
| 2024-04-15 20:26:51 +0200 | <c_wraith> | mauke: "If a side effect on a scalar object is unsequenced relative to either a different side effect on the |
| 2024-04-15 20:26:51 +0200 | <c_wraith> | same scalar object or a value computation using the value of the same scalar object, the behavior |
| 2024-04-15 20:26:51 +0200 | <c_wraith> | is undefined." |
| 2024-04-15 20:26:56 +0200 | <c_wraith> | whoops. newlines made it in. |
| 2024-04-15 20:27:19 +0200 | <mauke> | yes, but function bodies/calls are sequenced to each other |
| 2024-04-15 20:27:57 +0200 | <mauke> | actually, I should check whether there is a sequence point between different arguments |
| 2024-04-15 20:28:12 +0200 | <c_wraith> | I mean, the lack of sequence points there was the whole point of my complaint.... |
| 2024-04-15 20:28:39 +0200 | <mauke> | IIRC there is a sequence point before each function call |
| 2024-04-15 20:28:49 +0200 | <mauke> | or maybe in each function call, before the body is entered |
| 2024-04-15 20:29:27 +0200 | anon1123 | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 20:30:45 +0200 | anon1123 | (~anon1123@catv-176-63-0-119.catv.fixed.vodafone.hu) |
| 2024-04-15 20:30:55 +0200 | <monochrom> | I give students assignments like that too. I just write like "the input is a positive odd number n, the output is 3*n". I am not going to bother to add explicitly "unspecified behaviour for other inputs", eh. At most I add, just for FAQ purposes, "I only test with positive odd numbers". |
| 2024-04-15 20:31:51 +0200 | <c_wraith> | She then dug up the same portion of the C2x draft, and was like "hey, this actually explicitly lists when it's undefined behavior, instead of just describing defined behavior" |
| 2024-04-15 20:32:14 +0200 | haskellbridge | (~haskellbr@69.135.3.34) |
| 2024-04-15 20:32:14 +0200 | ChanServ | +v haskellbridge |
| 2024-04-15 20:32:38 +0200 | <geekosaur> | aaaand we're back |
| 2024-04-15 20:32:39 +0200 | <mauke> | ok, there is no sequence point between arguments, but "There is a sequence point after the evaluations of the function designator and the actual arguments but before the actual call." |
| 2024-04-15 20:33:04 +0200 | <mauke> | (C17, 6.5.2.2/10) |
| 2024-04-15 20:33:42 +0200 | sammelweis | (~quassel@96.76.243.253) (Read error: Connection reset by peer) |
| 2024-04-15 20:33:52 +0200 | sammelweis | (~quassel@96.76.243.253) |
| 2024-04-15 20:34:28 +0200 | <mauke> | so: int x; void f(int x, int y) {} int main(void) { f(x = 1, x = 2); } // undefined behavior |
| 2024-04-15 20:34:40 +0200 | <c_wraith> | man, it's a lot to wrap my head around sequence points being both syntactic and temporal. |
| 2024-04-15 20:35:08 +0200 | <mauke> | but: int x; void g(void) { x = 1; } void h(void) { x = 2; } void f(int x, int y) {} int main(void) { f(g(), h()); } // fine |
| 2024-04-15 20:37:30 +0200 | Core6846 | (~rosco@aq052236.dynamic.ppp.asahi-net.or.jp) (Remote host closed the connection) |
| 2024-04-15 20:37:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 20:37:46 +0200 | rosco | (~rosco@aq052236.dynamic.ppp.asahi-net.or.jp) |
| 2024-04-15 20:37:55 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) |
| 2024-04-15 20:38:38 +0200 | JeremyB99 | (~JeremyB99@2607:fb91:1062:10b3:b1f8:d4ff:4235:d3a9) (Read error: Connection reset by peer) |
| 2024-04-15 20:38:45 +0200 | <c_wraith> | oddly, that quote leaves it possible for there to be UB if the function designator might be changed by evaluating arguments. And I guess you could make that happen with function pointers. I hope no one has ever encountered that specific UB. |
| 2024-04-15 20:39:11 +0200 | <monochrom> | hahaha how did I not think of that |
| 2024-04-15 20:39:30 +0200 | <mauke> | yes, also a[i](i++); and similar |
| 2024-04-15 20:39:38 +0200 | <dolio> | You'd have to be doing some really evil stuff. |
| 2024-04-15 20:39:53 +0200 | <c_wraith> | mauke: thanks for the clarification. |
| 2024-04-15 20:41:02 +0200 | <mauke> | also, { int i = 0; return i; } technically has undefined behavior because there is no sequence point between the write and read of i :-) |
| 2024-04-15 20:41:19 +0200 | <monochrom> | "implementing algebraic effects in C: monads for free in C" https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/algeff-in-c-tr-v2.pdf |
| 2024-04-15 20:41:21 +0200 | <c_wraith> | ... yikes. |
| 2024-04-15 20:41:34 +0200 | <glguy> | Also C++ and C have different evaluation orders |
| 2024-04-15 20:41:43 +0200 | <mauke> | which I'm pretty sure is a either bug in the standard or me reading it wrong |
| 2024-04-15 20:42:02 +0200 | <glguy> | In C++17: In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument. |
| 2024-04-15 20:42:18 +0200 | <c_wraith> | I was under the impression a semicolon was always intended to be a sequence point. But possibly the spec misseed a case. |
| 2024-04-15 20:42:29 +0200 | <mauke> | intended, yes |
| 2024-04-15 20:42:47 +0200 | <glguy> | 4) There is a sequence point after the evaluation of a full expression (an expression that is not a subexpression: typically something that ends with a semicolon |
| 2024-04-15 20:43:00 +0200 | <mauke> | right. "full expression" is the crucial thing |
| 2024-04-15 20:43:11 +0200 | <mauke> | because normally = is an operator and thus part of the expression |
| 2024-04-15 20:43:32 +0200 | <mauke> | but with initializers = is part of the initialization syntax and not part of the expression |
| 2024-04-15 20:43:40 +0200 | <glguy> | 5) There is a sequence point at the end of a full declarator. |
| 2024-04-15 20:43:49 +0200 | <mauke> | the declarator is 0 |
| 2024-04-15 20:44:09 +0200 | <glguy> | the initializer is 0, the declarator is int i |
| 2024-04-15 20:44:15 +0200 | <mauke> | oops |
| 2024-04-15 20:44:25 +0200 | <mauke> | ah, not quite |
| 2024-04-15 20:44:28 +0200 | <mauke> | the declarator is i |
| 2024-04-15 20:44:42 +0200 | <mauke> | "declarator" is the name of the pseudo-expression that follows the typey names in declarations |
| 2024-04-15 20:45:10 +0200 | <mauke> | the idea being that with VLAs you could have something like int a[f()]; IIRC |
| 2024-04-15 20:46:04 +0200 | <c_wraith> | ... too much astronomy. VL is variable-length, not very large. |
| 2024-04-15 20:46:04 +0200 | <mauke> | so: we have a sequence point after `i` (which is pointless) and a sequence point after `0` (also pointless), but nothing after the implied write that happens during initialization |
| 2024-04-15 20:47:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-15 20:48:11 +0200 | JeremyB99 | (~JeremyB99@208.64.173.20) |
| 2024-04-15 20:49:13 +0200 | <glguy> | mauke: the standard does have a paragraph: A statement specifies an action to be performed. Except as indicated, statements are executed in sequence. |
| 2024-04-15 20:49:34 +0200 | <mauke> | declarations aren't statements (at least not in C99) |
| 2024-04-15 20:52:46 +0200 | zetef | (~quassel@5.2.182.99) (Remote host closed the connection) |
| 2024-04-15 20:54:01 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-15 20:59:40 +0200 | euleritian | (~euleritia@dynamic-176-004-212-165.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-15 21:00:28 +0200 | <glguy> | mauke: how about this: https://en.cppreference.com/w/c/language/statements#Compound_statements The initializers of the variables with automatic storage duration declared inside a block and the VLA declarators are executed when flow of control passes over these declarations in order, as if they were statements: |
| 2024-04-15 21:00:52 +0200 | <glguy> | I still need to tie that back to the standard document, but I think we're closer |
| 2024-04-15 21:01:06 +0200 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2024-04-15 21:02:10 +0200 | <mauke> | yes, that's part of the problem |
| 2024-04-15 21:02:29 +0200 | <mauke> | variable initializers are executed like statements, but without the sequence point at the end that comes with normal statements |
| 2024-04-15 21:02:53 +0200 | <glguy> | If they were executed "as if they were statements" then that gets us back to statements being sequenced |
| 2024-04-15 21:03:30 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-15 21:06:04 +0200 | <glguy> | mauke: The following are full expressions: an initializer that is not part of a compound literal (6.7.9); ... |
| 2024-04-15 21:06:32 +0200 | tessier | (~treed@ec2-184-72-149-67.compute-1.amazonaws.com) |
| 2024-04-15 21:07:00 +0200 | <mauke> | that's the 0 |
| 2024-04-15 21:07:44 +0200 | <glguy> | OK, so you're saying that the assignment of that expression's value to i is not sufficiently sequenced |
| 2024-04-15 21:08:11 +0200 | <mauke> | yes |
| 2024-04-15 21:08:24 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-15 21:08:56 +0200 | <glguy> | I don't think initializers are considered assignment in the same way that actual assignment statements are |
| 2024-04-15 21:09:06 +0200 | <glguy> | it's not being assigned to i, it's the initial value of it |
| 2024-04-15 21:09:38 +0200 | <mauke> | that part is weird, too |
| 2024-04-15 21:10:04 +0200 | <mauke> | because for automatic variables, storage is reserved when their block is entered |
| 2024-04-15 21:10:24 +0200 | <mauke> | but IIRC their value stays indeterminate until execution reaches the initialization |
| 2024-04-15 21:14:11 +0200 | mechap | (~mechap@user/mechap) (Quit: WeeChat 4.2.2) |
| 2024-04-15 21:15:03 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-15 21:18:27 +0200 | <EvanR> | masaeedu, yeah I figured |
| 2024-04-15 21:18:41 +0200 | <EvanR> | modulo "implementations that any of us have used" |
| 2024-04-15 21:19:09 +0200 | <EvanR> | holy crap so much C rabbit holing |
| 2024-04-15 21:20:20 +0200 | qhong | (~qhong@DN160vrd000d6kpg009l6c0000fj.stanford.edu) |
| 2024-04-15 21:20:31 +0200 | <c_wraith> | this is how I know anyone who says "C is simple" doesn't know C |
| 2024-04-15 21:22:19 +0200 | woffs | (3cd46299b2@woffs.de) () |
| 2024-04-15 21:22:37 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-04-15 21:24:23 +0200 | <EvanR> | moral, more or less self consistent C as gradually dreamed up while taking university courses "is simple" xD |
| 2024-04-15 21:25:05 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 268 seconds) |
| 2024-04-15 21:26:04 +0200 | <mauke> | fun C fact: all keywords at the start of a declaration can be permuted arbitrarily; their order doesn't matter |
| 2024-04-15 21:26:58 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-04-15 21:27:23 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-04-15 21:27:40 +0200 | <mauke> | so why declare a `const unsigned long int` when you can also declare an `int unsigned const long`? |
| 2024-04-15 21:31:47 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 264 seconds) |
| 2024-04-15 21:31:57 +0200 | xdminsy | (~xdminsy@117.147.70.203) (Ping timeout: 272 seconds) |
| 2024-04-15 21:35:26 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-04-15 21:36:45 +0200 | <EvanR> | what in the world |
| 2024-04-15 21:37:15 +0200 | <EvanR> | int long unsigned const |
| 2024-04-15 21:38:25 +0200 | <geekosaur> | a C of keywords |
| 2024-04-15 21:39:07 +0200 | <janus> | but that can't be since 'const int*' is not the same as 'int const *' |
| 2024-04-15 21:39:58 +0200 | <ncf> | it is; but that's not the same as int * const |
| 2024-04-15 21:40:00 +0200 | <EvanR> | * being technically not a keyword |
| 2024-04-15 21:40:01 +0200 | <masaeedu> | the closest i've come to having a systematic way of parsing c declarations is the spiral rule |
| 2024-04-15 21:40:25 +0200 | <masaeedu> | but apparently even that only works in happy circumstances |
| 2024-04-15 21:41:02 +0200 | <janus> | ok so i can only swap keywords if i don't go past a *? |
| 2024-04-15 21:41:54 +0200 | <EvanR> | this one weird trick your coworkers will hate |
| 2024-04-15 21:42:30 +0200 | <meejah> | const int * is a different type than int * const |
| 2024-04-15 21:42:48 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-04-15 21:42:56 +0200 | <meejah> | IIRC ... been a while ;) |
| 2024-04-15 21:42:57 +0200 | <masaeedu> | however happy a circumstance one might consider `void (*signal(int, void (*fp)(int)))(int);` to be |
| 2024-04-15 21:43:24 +0200 | euleritian | (~euleritia@dynamic-176-004-212-165.176.4.pool.telefonica.de) |
| 2024-04-15 21:43:41 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-04-15 21:49:12 +0200 | <dolio> | Is `int * const` the one where the pointer is constant? |
| 2024-04-15 21:50:14 +0200 | <tomsmeding> | dolio: correct |
| 2024-04-15 21:54:06 +0200 | <dolio> | I guess it probably wouldn't be surprising if people who say, "C is simple," have never actually written a C program. :) |
| 2024-04-15 21:54:12 +0200 | <dolio> | Like, a well defined one. |
| 2024-04-15 21:55:03 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-04-15 21:56:23 +0200 | <janus> | if you consider that almost every other language boils down to C its RTS or such, isn't C simpler then? i mean, to understand the GHC RTS you need to know both haskell and C |
| 2024-04-15 21:56:56 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2024-04-15 21:57:20 +0200 | <geekosaur> | only if you need to understand the details of its implementation. if it provides a well defined API and hides the C RTS API, you need only understand the exported API |
| 2024-04-15 21:57:26 +0200 | <geekosaur> | (at least until you start doing FFI) |
| 2024-04-15 21:58:18 +0200 | <sprout> | janus: you don't need to understand C, you need to understand a Von Neumann architecture |
| 2024-04-15 21:58:44 +0200 | <sprout> | and the most popular manner of programming against a Von Neumann architecture is C |
| 2024-04-15 21:58:51 +0200 | <dolio> | It wouldn't be surprising if every RTS is not a C program. :) |
| 2024-04-15 21:58:56 +0200 | <janus> | sprout: i need the VonNeumann understanding to understand the K&R book? or do debug a PDP-11? or to debug the GHC RTS? |
| 2024-04-15 21:59:10 +0200 | <janus> | i can see why someone who read the K&R book would say C is simple |
| 2024-04-15 21:59:19 +0200 | <meejah> | dolio: yeah, one is "the pointer is const" and the other is "the thing pointed at is const" |
| 2024-04-15 21:59:28 +0200 | <janus> | if they are confronted with Visual Studio.NET and a commercial codebase right after :P |
| 2024-04-15 21:59:38 +0200 | <janus> | and that probably happened to a lot of colleague graduates :P |
| 2024-04-15 21:59:43 +0200 | <sprout> | you need to understand the essentials of the machine your working on |
| 2024-04-15 21:59:47 +0200 | <dolio> | meejah: Yeah, I knew that. The trick is remembering which is which. |
| 2024-04-15 21:59:51 +0200 | <sprout> | well, some people do |
| 2024-04-15 21:59:53 +0200 | <janus> | microcode, that seems pretty essential |
| 2024-04-15 22:00:00 +0200 | <janus> | good thing everybody understands that |
| 2024-04-15 22:00:00 +0200 | <meejah> | dolio: indeed, many such "tricks" in C/C++ ;) |
| 2024-04-15 22:00:02 +0200 | <janus> | NOT :D |
| 2024-04-15 22:00:30 +0200 | <meejah> | you can also like "const int * const" approximately. |
| 2024-04-15 22:00:59 +0200 | <sprout> | I don't think you can understand C without having some grasp of the machine your programming |
| 2024-04-15 22:01:16 +0200 | <dolio> | mauke: Actually, are C programs a monoid? Probably not. You can't just concatenate two C programs and get a C program. |
| 2024-04-15 22:01:24 +0200 | <janus> | it all boils down to the fact that C can mean a billion things |
| 2024-04-15 22:01:49 +0200 | <janus> | and it changes every few decades, new standards come out |
| 2024-04-15 22:02:13 +0200 | <meejah> | yeah .. and most "C" now is really like "C, but built by a C++ compiler" so certainly C++-isms sneak in |
| 2024-04-15 22:03:16 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-04-15 22:04:28 +0200 | systemfault | (sid267009@about/typescript/member/systemfault) (Remote host closed the connection) |
| 2024-04-15 22:04:40 +0200 | systemfault | (sid267009@about/typescript/member/systemfault) |
| 2024-04-15 22:05:20 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-04-15 22:06:56 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-04-15 22:10:20 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-04-15 22:10:20 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-04-15 22:10:51 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2024-04-15 22:11:02 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-04-15 22:11:10 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-04-15 22:12:57 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-04-15 22:14:03 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-04-15 22:14:22 +0200 | Shires | (~Shires@user/shires) |
| 2024-04-15 22:15:03 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-04-15 22:15:22 +0200 | Shires | (~Shires@user/shires) () |
| 2024-04-15 22:21:28 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-04-15 22:28:54 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 268 seconds) |
| 2024-04-15 22:29:14 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-04-15 22:39:47 +0200 | roboguy_ | (~roboguy_@2605:a601:ac42:2600:fc17:bce5:59ef:6c46) |
| 2024-04-15 22:42:42 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2024-04-15 22:47:32 +0200 | Vajb | (~Vajb@85-76-14-24-nat.elisa-mobile.fi) |
| 2024-04-15 22:54:51 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 256 seconds) |
| 2024-04-15 22:55:48 +0200 | roboguy_ | (~roboguy_@2605:a601:ac42:2600:fc17:bce5:59ef:6c46) (Quit: Leaving...) |
| 2024-04-15 22:56:10 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3141-2665-793a-5dc9-a564-c4a6.rev.sfr.net) |
| 2024-04-15 22:56:46 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-04-15 22:56:48 +0200 | <monochrom> | The von Neumann model is pretty easy to understand, and most people already understand it, even presume it, without knowing the name. |
| 2024-04-15 22:57:28 +0200 | <monochrom> | The same way successful merchants deeply understand "higher demand = higher price" without knowing that it has an academic name too. |
| 2024-04-15 22:58:56 +0200 | <monochrom> | To read K&R (for example) you do need to not presume the lambda calculus, for example. |
| 2024-04-15 22:59:20 +0200 | <sprout> | the point is that you don't really need to understand C except for as a device to instruct a Von Neumann machine |
| 2024-04-15 22:59:26 +0200 | <sprout> | it's isn't about C |
| 2024-04-15 22:59:39 +0200 | <sprout> | could've been Ada just as well |
| 2024-04-15 23:01:50 +0200 | <sprout> | janus made the point that for understanding GHC you'ld need to understand C |
| 2024-04-15 23:01:53 +0200 | <sprout> | not really |
| 2024-04-15 23:02:06 +0200 | <sprout> | you need to be aware of what the machine roughly does |
| 2024-04-15 23:02:10 +0200 | <monochrom> | I think that was already addressed. |
| 2024-04-15 23:02:20 +0200 | sprout | shuts up |
| 2024-04-15 23:05:50 +0200 | qqq | (~qqq@92.43.167.61) (Quit: Lost terminal) |
| 2024-04-15 23:06:11 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection) |
| 2024-04-15 23:13:17 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-15 23:14:32 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-15 23:15:18 +0200 | JeremyB99 | (~JeremyB99@208.64.173.20) (Ping timeout: 255 seconds) |
| 2024-04-15 23:16:17 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-04-15 23:19:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-15 23:21:37 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2024-04-15 23:29:18 +0200 | michalz | (~michalz@185.246.207.215) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-15 23:31:40 +0200 | pavonia | (~user@user/siracusa) |
| 2024-04-15 23:34:00 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-04-15 23:38:17 +0200 | JeremyB99 | (~JeremyB99@208.64.173.20) |
| 2024-04-15 23:46:00 +0200 | lainon | (~lainon@2607:fb90:af24:4a15:91e7:ba33:e025:e099) |
| 2024-04-15 23:52:47 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-04-15 23:59:49 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |