| 2022-11-18 00:01:18 +0100 | <cowboy8625> | hmmm that makes a lot of sense..... |
| 2022-11-18 00:01:25 +0100 | <cowboy8625> | thanks! |
| 2022-11-18 00:02:56 +0100 | <cowboy8625> | I dont understand why ocaml went with the `;;` for there deliminator. |
| 2022-11-18 00:03:08 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-18 00:03:14 +0100 | srz | (~srz@181.228.49.93) |
| 2022-11-18 00:03:32 +0100 | <cowboy8625> | been struggling with the pratt parser for a long time but I think I figured it out. |
| 2022-11-18 00:03:57 +0100 | califax | (~califax@user/califx) |
| 2022-11-18 00:04:01 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 00:04:04 +0100 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2022-11-18 00:04:30 +0100 | wonko | (~wjc@2a0e:1c80:2:0:45:15:19:130) (Ping timeout: 240 seconds) |
| 2022-11-18 00:05:06 +0100 | wonko | (~wjc@2a0e:1c80:2:0:45:15:19:130) |
| 2022-11-18 00:06:50 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-18 00:09:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 00:10:24 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 00:15:41 +0100 | <EvanR> | ;; is so you know it's ocaml |
| 2022-11-18 00:16:15 +0100 | <EvanR> | or more likely "someone picked that first, blame them" |
| 2022-11-18 00:16:21 +0100 | king_gs | (~Thunderbi@187.201.139.206) |
| 2022-11-18 00:16:27 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Ping timeout: 268 seconds) |
| 2022-11-18 00:16:41 +0100 | <hpc> | EvanR: it could still be bash ;) |
| 2022-11-18 00:18:18 +0100 | <EvanR> | see, told you |
| 2022-11-18 00:18:21 +0100 | <monochrom> | I think SML or even its predecessor started using ;; |
| 2022-11-18 00:21:00 +0100 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 260 seconds) |
| 2022-11-18 00:21:12 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 00:22:13 +0100 | denl^ | (~denl@76.145.185.103) |
| 2022-11-18 00:25:42 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 268 seconds) |
| 2022-11-18 00:27:17 +0100 | <EvanR> | when the question is too hard, use recursion |
| 2022-11-18 00:27:57 +0100 | <juri_> | when recursion is too hard, use violence? |
| 2022-11-18 00:28:24 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-18 00:29:22 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 00:29:42 +0100 | <hpc> | when recursion is too hard, use recursion |
| 2022-11-18 00:29:49 +0100 | <EvanR> | ^ |
| 2022-11-18 00:29:54 +0100 | <monochrom> | What hpc said. :) |
| 2022-11-18 00:34:10 +0100 | <cowboy8625> | What are yall working on? |
| 2022-11-18 00:35:34 +0100 | Guest5270 | money |
| 2022-11-18 00:36:06 +0100 | <EvanR> | advent of code 2020 |
| 2022-11-18 00:36:08 +0100 | <monochrom> | Um, writing a few lines of emacs lisp to tell emacs that for *.dump-* files emacs should auto-reload them whenever they are changed externally (by GHC in my case). |
| 2022-11-18 00:36:40 +0100 | <monochrom> | *.dump-* files are made by GHC when I request it to spit out intermediate code. |
| 2022-11-18 00:37:25 +0100 | <monochrom> | You can also white-paper-level-understand it as "writing emacs lisp to help me understand haskell"? >:) |
| 2022-11-18 00:37:38 +0100 | <monochrom> | or popsci-level-understand |
| 2022-11-18 00:41:30 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a332868e30cc8c30a1f.dip0.t-ipconnect.de) |
| 2022-11-18 00:41:31 +0100 | acidjnk | (~acidjnk@p200300d6e7137a338cbf33f376421589.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-18 00:47:30 +0100 | king_gs1 | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-18 00:47:31 +0100 | king_gs | (~Thunderbi@187.201.139.206) (Read error: Connection reset by peer) |
| 2022-11-18 00:47:31 +0100 | king_gs1 | king_gs |
| 2022-11-18 00:47:48 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-18 00:51:37 +0100 | mixfix41 | (~sdenynine@user/mixfix41) (Ping timeout: 268 seconds) |
| 2022-11-18 00:51:47 +0100 | ted[m] | (~tedmatrix@2001:470:69fc:105::2:bf60) |
| 2022-11-18 00:52:44 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 00:52:50 +0100 | fockerize | (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 268 seconds) |
| 2022-11-18 00:53:59 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-18 00:56:10 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Ping timeout: 240 seconds) |
| 2022-11-18 00:59:17 +0100 | king_gs | (~Thunderbi@187.201.139.206) |
| 2022-11-18 01:06:34 +0100 | titibandit | (~titibandi@xdsl-78-35-182-184.nc.de) (Remote host closed the connection) |
| 2022-11-18 01:09:29 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-18 01:10:22 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Ping timeout: 256 seconds) |
| 2022-11-18 01:10:46 +0100 | mauke_ | (~mauke@p57b6eb34.dip0.t-ipconnect.de) |
| 2022-11-18 01:12:19 +0100 | mauke | (~mauke@p54958ca8.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-18 01:14:54 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds) |
| 2022-11-18 01:14:58 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-18 01:15:57 +0100 | <cowboy8625> | what I dont understand is how to parse calls. |
| 2022-11-18 01:16:17 +0100 | <cowboy8625> | calls are kicking my butt |
| 2022-11-18 01:19:10 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) |
| 2022-11-18 01:19:11 +0100 | king_gs | (~Thunderbi@187.201.139.206) (Read error: Connection reset by peer) |
| 2022-11-18 01:19:30 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-18 01:19:32 +0100 | gqplox | (~textual@2a02:c7c:941d:fd00:c91:4591:f163:6ae7) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-11-18 01:20:33 +0100 | detuneattune | (~detuneatt@user/detuneattune) (Quit: The Lounge - https://thelounge.chat) |
| 2022-11-18 01:22:24 +0100 | <Axman6> | App <$> expr <*> expr? :P |
| 2022-11-18 01:23:20 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 01:24:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) (Ping timeout: 260 seconds) |
| 2022-11-18 01:24:49 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 01:25:09 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-18 01:28:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a332868e30cc8c30a1f.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 01:29:16 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.7.1) |
| 2022-11-18 01:29:47 +0100 | <cowboy8625> | yeah I get that |
| 2022-11-18 01:30:02 +0100 | <Axman6> | so, this might be more of a unix question, but I'm thinking about it from a haskell perspective - If you wanted to spawn two subprocesses and pipe the output from one to another, you's first spawn the recipient of the data, get its stdin handle, then use that as the stdout handle, correct? |
| 2022-11-18 01:31:19 +0100 | <geekosaur> | should work, I think. might need to use the lower level process stuff from the unix package though |
| 2022-11-18 01:31:38 +0100 | <Axman6> | I'm wondering if there's a way to find out how much data has been sent between the two processes - hFileSize specifically talks about being only for handles for real files |
| 2022-11-18 01:31:58 +0100 | <Axman6> | I guess trying the piping would be pretty easy |
| 2022-11-18 01:32:19 +0100 | <geekosaur> | there isn't, really |
| 2022-11-18 01:32:36 +0100 | <geekosaur> | a pipe has a kernel buffer and no other "memory" |
| 2022-11-18 01:32:49 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) |
| 2022-11-18 01:33:14 +0100 | <Axman6> | so if you wanted to do that, from haskell, you'd be better off forking a thread to read, keep track of stats and then write to separate handles? |
| 2022-11-18 01:33:29 +0100 | <geekosaur> | yeh |
| 2022-11-18 01:33:53 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 01:34:24 +0100 | <Axman6> | Wondering how hard writing something like pv would be in Haskell |
| 2022-11-18 01:34:31 +0100 | <Axman6> | (pipe viewer) |
| 2022-11-18 01:35:17 +0100 | <geekosaur> | the unix package should give you everything you need, unless it's accessing /proc directly, and possibly even then |
| 2022-11-18 01:35:47 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 01:37:18 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 01:37:54 +0100 | <Axman6> | is GHC2021 a base language or an extension? |
| 2022-11-18 01:38:08 +0100 | <Axman6> | (is it even GHC2021 or 2020?) |
| 2022-11-18 01:38:27 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-18 01:38:43 +0100 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
| 2022-11-18 01:39:52 +0100 | <monochrom> | How to parse calls: `some expr` to get a non-empty list, then you can split it or even foldl1 FunApp. |
| 2022-11-18 01:40:57 +0100 | <monochrom> | To a large extent I would parse s-expressions that way too. |
| 2022-11-18 01:43:58 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a332868e30cc8c30a1f.dip0.t-ipconnect.de) |
| 2022-11-18 01:44:51 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-18 01:45:16 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 01:50:44 +0100 | mmhat | (~mmh@p200300f1c722a143ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-18 01:50:46 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-11-18 01:51:36 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 01:53:06 +0100 | <cowboy8625> | WOOOOOOO I think I got it!!!!!!! |
| 2022-11-18 01:57:35 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) (Ping timeout: 260 seconds) |
| 2022-11-18 01:58:03 +0100 | srz | (~srz@181.228.49.93) |
| 2022-11-18 01:58:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:43db:c639:c914:6f0d) (Ping timeout: 256 seconds) |
| 2022-11-18 01:59:30 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 2022-11-18 01:59:51 +0100 | <geekosaur> | Axman6, it's a language, although ghc itself accepts all language designators with the same -X / LANGUAGE pragma as extensions |
| 2022-11-18 02:00:01 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 02:00:17 +0100 | <geekosaur> | cabal will accept `default-language: GHC2021` if you're using ghc 9.2 or later |
| 2022-11-18 02:00:29 +0100 | <geekosaur> | (stack as well, if it's recent enough) |
| 2022-11-18 02:00:58 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 02:01:33 +0100 | <Axman6> | yeah, cabal/ghc weren't happy with default-language: Haskell2010 and other-extensions: GHC2021, so tried changing the language and it's all good. I should read what's in GHC2021 now... |
| 2022-11-18 02:03:05 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds) |
| 2022-11-18 02:03:21 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Remote host closed the connection) |
| 2022-11-18 02:03:23 +0100 | <geekosaur> | https://downloads.haskell.org/ghc/9.4.2/docs/users_guide/exts/control.html?highlight=ghc2021#exten… |
| 2022-11-18 02:04:22 +0100 | td_ | (~td@83.135.9.50) (Ping timeout: 268 seconds) |
| 2022-11-18 02:04:52 +0100 | maerwald | (~maerwald@user/maerwald) (Ping timeout: 248 seconds) |
| 2022-11-18 02:05:27 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 02:05:30 +0100 | ubert | (~Thunderbi@77.119.167.253.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2022-11-18 02:05:36 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-18 02:05:55 +0100 | ubert | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) |
| 2022-11-18 02:06:06 +0100 | ub | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) |
| 2022-11-18 02:06:41 +0100 | akegalj | (~akegalj@210-96.dsl.iskon.hr) (Quit: leaving) |
| 2022-11-18 02:06:49 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Client Quit) |
| 2022-11-18 02:07:35 +0100 | maerwald | (~maerwald@mail.hasufell.de) |
| 2022-11-18 02:07:36 +0100 | ubert1 | (~Thunderbi@77.119.167.253.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2022-11-18 02:09:11 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 02:09:46 +0100 | xff0x | (~xff0x@2405:6580:b080:900:43db:c639:c914:6f0d) |
| 2022-11-18 02:10:00 +0100 | td_ | (~td@83.135.9.50) |
| 2022-11-18 02:10:05 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
| 2022-11-18 02:10:24 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-11-18 02:11:53 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-11-18 02:12:10 +0100 | malte | (~malte@mal.tc) (Ping timeout: 240 seconds) |
| 2022-11-18 02:14:58 +0100 | mmhat | (~mmh@p200300f1c722a143ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 02:15:44 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 2022-11-18 02:16:31 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-11-18 02:17:11 +0100 | pavonia | (~user@user/siracusa) (Ping timeout: 260 seconds) |
| 2022-11-18 02:17:45 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 02:18:50 +0100 | malte | (~malte@mal.tc) |
| 2022-11-18 02:19:47 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-18 02:19:56 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 02:24:22 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-18 02:25:29 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-18 02:25:34 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-18 02:28:23 +0100 | xff0x | (~xff0x@2405:6580:b080:900:43db:c639:c914:6f0d) (Ping timeout: 260 seconds) |
| 2022-11-18 02:29:07 +0100 | mmhat | (~mmh@p200300f1c701b7cbee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-18 02:29:32 +0100 | dtman34 | (~dtman34@2601:447:d080:83c8:24bc:55ba:13b9:cc55) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 2022-11-18 02:29:39 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 268 seconds) |
| 2022-11-18 02:29:39 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-11-18 02:29:49 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-11-18 02:29:53 +0100 | dtman34 | (~dtman34@2601:447:d080:83c8:3fe9:6f54:f618:67a8) |
| 2022-11-18 02:32:48 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 02:33:27 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-18 02:33:27 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-18 02:33:27 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-18 02:40:47 +0100 | maerwald | (~maerwald@mail.hasufell.de) (Quit: gone) |
| 2022-11-18 02:42:24 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-11-18 02:43:14 +0100 | maerwald | (~maerwald@mail.hasufell.de) |
| 2022-11-18 02:51:38 +0100 | srz_ | (~srz@179.36.100.24) |
| 2022-11-18 02:53:22 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-18 02:53:25 +0100 | hsw_ | (~hsw@112-104-142-182.adsl.dynamic.seed.net.tw) (Quit: Leaving) |
| 2022-11-18 02:53:37 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2022-11-18 02:54:04 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 256 seconds) |
| 2022-11-18 02:56:03 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-18 02:58:19 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 03:02:57 +0100 | <cowboy8625> | well I am extremly excited! Pratt Parsing is awesome! SOO simple really. |
| 2022-11-18 03:03:34 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-11-18 03:06:08 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-11-18 03:07:55 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-11-18 03:08:42 +0100 | srz_ | (~srz@179.36.100.24) (Remote host closed the connection) |
| 2022-11-18 03:12:46 +0100 | maerwald | (~maerwald@mail.hasufell.de) (Ping timeout: 256 seconds) |
| 2022-11-18 03:13:08 +0100 | maerwald | (~maerwald@mail.hasufell.de) |
| 2022-11-18 03:14:40 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2022-11-18 03:16:44 +0100 | mmhat | (~mmh@p200300f1c701b7cbee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 03:16:58 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-18 03:16:58 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-18 03:16:58 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-18 03:19:49 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-18 03:20:38 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) |
| 2022-11-18 03:24:32 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-18 03:25:20 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) (Ping timeout: 260 seconds) |
| 2022-11-18 03:27:04 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a332868e30cc8c30a1f.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2022-11-18 03:27:54 +0100 | shapr | (~user@68.54.166.125) (Ping timeout: 260 seconds) |
| 2022-11-18 03:28:58 +0100 | mmhat | (~mmh@p200300f1c70468f6ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-18 03:30:42 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-11-18 03:37:55 +0100 | youziqi | (~youziqi@103.37.140.45) (Ping timeout: 260 seconds) |
| 2022-11-18 03:42:49 +0100 | shapr | (~user@68.54.166.125) |
| 2022-11-18 03:45:13 +0100 | youziqi | (~youziqi@103.37.140.125) |
| 2022-11-18 03:45:14 +0100 | razetime | (~quassel@117.254.35.237) |
| 2022-11-18 03:45:51 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 03:48:30 +0100 | ddellacosta | (~ddellacos@143.244.47.83) (Ping timeout: 240 seconds) |
| 2022-11-18 03:48:54 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds) |
| 2022-11-18 03:50:12 +0100 | <elvishjerricco> | So I was trying to be clever, doing `asum $ fmap f [1..5] ++ [die "too many tries"]`, where `f` is an `IO` function. The bulk of `f` is a `callProcess`. I expected that `ctrl-c` would kill the whole thing, but it just kills one of the tries at a time. |
| 2022-11-18 03:50:44 +0100 | ddellacosta | (~ddellacos@143.244.47.70) |
| 2022-11-18 03:51:18 +0100 | <elvishjerricco> | I wanted it to be that if `callProcess` failed, `asum` would just cause it to try again through the `IO` instance of `Alternative` |
| 2022-11-18 03:51:52 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 256 seconds) |
| 2022-11-18 03:52:38 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 03:54:49 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Quit: leaving) |
| 2022-11-18 03:55:03 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-18 03:55:10 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Client Quit) |
| 2022-11-18 03:55:41 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-18 04:00:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-18 04:05:22 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 04:07:12 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-11-18 04:08:18 +0100 | td_ | (~td@83.135.9.50) (Ping timeout: 256 seconds) |
| 2022-11-18 04:10:05 +0100 | td_ | (~td@83.135.9.5) |
| 2022-11-18 04:15:08 +0100 | marc___ | (~marc@5.83.191.79) |
| 2022-11-18 04:18:31 +0100 | marc__ | (~marc@5.83.191.222) (Ping timeout: 260 seconds) |
| 2022-11-18 04:19:55 +0100 | Batzy | (~quassel@user/batzy) (Ping timeout: 260 seconds) |
| 2022-11-18 04:20:39 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-11-18 04:21:18 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-18 04:21:48 +0100 | Batzy | (~quassel@user/batzy) (Client Quit) |
| 2022-11-18 04:23:12 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-18 04:23:46 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-18 04:24:08 +0100 | maxfan8 | (~max@2a01:4f8:192:5356::2) |
| 2022-11-18 04:25:13 +0100 | Batzy_ | (~quassel@user/batzy) |
| 2022-11-18 04:25:27 +0100 | Batzy_ | (~quassel@user/batzy) (Client Quit) |
| 2022-11-18 04:26:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 04:27:01 +0100 | Batzy | (~quassel@user/batzy) (Read error: Connection reset by peer) |
| 2022-11-18 04:29:19 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-18 04:39:03 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-11-18 04:41:13 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-18 04:42:09 +0100 | cowboy8625 | (~cowboy@96-2-208-2-static.midco.net) (Quit: WeeChat 3.5) |
| 2022-11-18 04:42:55 +0100 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 2022-11-18 04:44:16 +0100 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-11-18 04:44:31 +0100 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-11-18 04:44:31 +0100 | jinsun | (~jinsun@user/jinsun) (Killed (silver.libera.chat (Nickname regained by services))) |
| 2022-11-18 04:44:31 +0100 | jinsun__ | jinsun |
| 2022-11-18 04:51:05 +0100 | evanvarvell | (~evanvarve@097-088-181-216.res.spectrum.com) (Quit: Leaving) |
| 2022-11-18 04:56:12 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-18 04:57:01 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-18 04:57:06 +0100 | polo | (~polo@user/polo) |
| 2022-11-18 04:57:36 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-18 04:57:40 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 04:59:29 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-18 05:00:02 +0100 | haasn | (~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2022-11-18 05:00:13 +0100 | <Inst> | ummm, i'm looking for some help on Cabal |
| 2022-11-18 05:00:30 +0100 | <Inst> | I'm on Windows, and somehow it's not allowing me to compile based on .configure scripts, but my installation is managed by maerwald's ghcup |
| 2022-11-18 05:00:42 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-18 05:01:14 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-18 05:01:24 +0100 | haasn | (~nand@haasn.dev) |
| 2022-11-18 05:02:52 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-11-18 05:03:09 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-18 05:06:49 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-11-18 05:09:09 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere) |
| 2022-11-18 05:09:22 +0100 | ddellacosta | (~ddellacos@143.244.47.70) (Ping timeout: 268 seconds) |
| 2022-11-18 05:09:53 +0100 | polo | (~polo@user/polo) (Ping timeout: 256 seconds) |
| 2022-11-18 05:10:17 +0100 | polo | (~polo@user/polo) |
| 2022-11-18 05:10:50 +0100 | polo | (~polo@user/polo) (Client Quit) |
| 2022-11-18 05:12:24 +0100 | Guest75 | (~Guest75@178.141.130.118) |
| 2022-11-18 05:15:09 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-18 05:17:10 +0100 | denl^ | (~denl@76.145.185.103) (Remote host closed the connection) |
| 2022-11-18 05:17:13 +0100 | Guest75 | (~Guest75@178.141.130.118) (Ping timeout: 260 seconds) |
| 2022-11-18 05:18:09 +0100 | <sm> | @where paste |
| 2022-11-18 05:18:09 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2022-11-18 05:21:23 +0100 | <Inst> | https://paste.tomsmeding.com/QX4w8JGZ |
| 2022-11-18 05:21:49 +0100 | <Inst> | except msys+mingw should be installed? |
| 2022-11-18 05:25:38 +0100 | <sm> | I'm not sure how that works with ghcup, #haskell-ghcup / maerwald may know |
| 2022-11-18 05:30:08 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-18 05:31:28 +0100 | <maerwald[m]> | Inst: your cabal.config? |
| 2022-11-18 05:31:32 +0100 | <maerwald[m]> | The global one |
| 2022-11-18 05:32:16 +0100 | mbuf | (~Shakthi@49.204.132.239) |
| 2022-11-18 05:33:31 +0100 | <Inst> | maerwald: |
| 2022-11-18 05:33:32 +0100 | <Inst> | https://paste.tomsmeding.com/51QGzezE |
| 2022-11-18 05:33:39 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 2022-11-18 05:34:02 +0100 | <Inst> | if i delete the config file and reinstall cabal, it should attempt to regenerate the bindings to msys, right? |
| 2022-11-18 05:34:41 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) |
| 2022-11-18 05:34:54 +0100 | <maerwald[m]> | extra-include-dirs, extra-lib-dirs and extra-prog-path are not set for some reason |
| 2022-11-18 05:35:00 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-11-18 05:35:02 +0100 | <maerwald[m]> | https://github.com/hasufell/ghcup-hs/blob/e924ad8278966795ea6f8393fc38900c549f6e2a/scripts/bootstr… |
| 2022-11-18 05:35:35 +0100 | <maerwald[m]> | The bootstrap script should set them. It's possible that you're using different shell or something and cabal.config.location is different |
| 2022-11-18 05:35:50 +0100 | <maerwald[m]> | Set those values manually |
| 2022-11-18 05:39:35 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-18 05:40:31 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-18 05:41:28 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 05:42:36 +0100 | <Inst> | how do i force the bootstrap script to run? |
| 2022-11-18 05:43:14 +0100 | razetime | (~quassel@117.254.35.237) (Ping timeout: 260 seconds) |
| 2022-11-18 05:44:27 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 256 seconds) |
| 2022-11-18 05:46:52 +0100 | <maerwald[m]> | It's invoked by the powershell script. If you're already in an msys2 bash shell, you can invoke the same as on unix |
| 2022-11-18 05:48:36 +0100 | <Inst> | i'm reinstalling ghcup, would that work? |
| 2022-11-18 05:49:37 +0100 | catern | (~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407) (Read error: Connection reset by peer) |
| 2022-11-18 05:53:35 +0100 | <Inst> | yup, it's refusing to run |
| 2022-11-18 05:53:40 +0100 | <Inst> | which powershell script? |
| 2022-11-18 05:55:58 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-18 05:56:57 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-18 05:58:26 +0100 | <Inst> | okay, got a fresh config file for cabal |
| 2022-11-18 06:02:38 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-18 06:02:57 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-18 06:03:54 +0100 | <maerwald[m]> | https://github.com/haskell/ghcup-hs/blob/master/scripts/bootstrap/bootstrap-haskell.ps1 |
| 2022-11-18 06:06:10 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 06:18:23 +0100 | pottsy | (~pottsy@129.227.183.244) |
| 2022-11-18 06:31:12 +0100 | freeside | (~mengwong@122.11.214.158) |
| 2022-11-18 06:31:59 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2022-11-18 06:32:08 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-11-18 06:32:14 +0100 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 256 seconds) |
| 2022-11-18 06:33:23 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2022-11-18 06:36:16 +0100 | Guest12 | (~Guest12@110.226.84.78) |
| 2022-11-18 06:36:41 +0100 | freeside | (~mengwong@122.11.214.158) (Read error: Connection reset by peer) |
| 2022-11-18 06:37:41 +0100 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-18 06:38:47 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-11-18 06:39:50 +0100 | rembo10 | (~rembo10@main.remulis.com) |
| 2022-11-18 06:44:07 +0100 | Guest12 | (~Guest12@110.226.84.78) (Quit: Client closed) |
| 2022-11-18 06:44:13 +0100 | mbuf | (~Shakthi@49.204.132.239) (Quit: Leaving) |
| 2022-11-18 06:45:50 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 256 seconds) |
| 2022-11-18 06:48:20 +0100 | red-snail | (~snail@static.151.210.203.116.clients.your-server.de) (Ping timeout: 260 seconds) |
| 2022-11-18 06:51:21 +0100 | ircbrowse_tom | (~ircbrowse@2a01:4f8:1c1c:9319::1) (ZNC 1.8.2+deb2build5 - https://znc.in) |
| 2022-11-18 06:51:36 +0100 | ircbrowse_tom | (~ircbrowse@2a01:4f8:1c1c:9319::1) |
| 2022-11-18 06:51:41 +0100 | Server | +Cnt |
| 2022-11-18 06:51:49 +0100 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) |
| 2022-11-18 06:52:25 +0100 | Hafydd | (~Hafydd@user/hafydd) (Ping timeout: 260 seconds) |
| 2022-11-18 06:52:33 +0100 | fiddlerwoaroof | (~fiddlerwo@user/fiddlerwoaroof) |
| 2022-11-18 06:53:40 +0100 | maxfan8 | (~max@personal.max.fan) |
| 2022-11-18 06:56:59 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 256 seconds) |
| 2022-11-18 06:59:51 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 07:04:32 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-18 07:10:20 +0100 | Hafydd | (~Hafydd@user/hafydd) |
| 2022-11-18 07:15:18 +0100 | res0nat0r0844909 | (~Fletch@fenrir.whatbox.ca) (Ping timeout: 256 seconds) |
| 2022-11-18 07:15:21 +0100 | DDR | (~DDR@2604:3d08:4c7f:8250:7257:f6a:ab73:6e5d) (Remote host closed the connection) |
| 2022-11-18 07:15:51 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-11-18 07:17:14 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 07:17:53 +0100 | mmhat | (~mmh@p200300f1c70468f6ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 2022-11-18 07:18:19 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-18 07:19:18 +0100 | Luj37 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) |
| 2022-11-18 07:20:07 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-18 07:21:35 +0100 | Luj3 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Ping timeout: 260 seconds) |
| 2022-11-18 07:21:35 +0100 | Luj37 | Luj3 |
| 2022-11-18 07:22:06 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 256 seconds) |
| 2022-11-18 07:22:40 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-11-18 07:26:59 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2022-11-18 07:29:17 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2022-11-18 07:31:59 +0100 | money | Guest1479 |
| 2022-11-18 07:32:23 +0100 | Guest1479 | (sid532813@user/polo) () |
| 2022-11-18 07:47:02 +0100 | tcard | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Quit: Leaving) |
| 2022-11-18 07:48:12 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-18 07:49:20 +0100 | nisstyre | (wes@user/nisstyre) (Quit: WeeChat 3.4) |
| 2022-11-18 07:50:03 +0100 | Guest1479 | (sid532813@user/polo) |
| 2022-11-18 07:50:06 +0100 | Guest1479 | money |
| 2022-11-18 07:52:29 +0100 | tcard | (~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) |
| 2022-11-18 07:53:19 +0100 | nisstyre | (wes@user/nisstyre) |
| 2022-11-18 07:58:56 +0100 | Guest75 | (~Guest75@178.141.130.118) |
| 2022-11-18 07:58:57 +0100 | youziqi | (~youziqi@103.37.140.125) (Ping timeout: 256 seconds) |
| 2022-11-18 08:01:51 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 08:02:08 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 08:06:28 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-18 08:06:52 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-18 08:13:30 +0100 | kaskal | (~kaskal@213-225-13-82.nat.highway.a1.net) (Ping timeout: 240 seconds) |
| 2022-11-18 08:14:11 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-11-18 08:16:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 08:20:18 +0100 | Major_Biscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 2022-11-18 08:23:52 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-11-18 08:26:36 +0100 | fockerize | (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-11-18 08:29:30 +0100 | kenran | (~user@user/kenran) |
| 2022-11-18 08:32:47 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2022-11-18 08:33:06 +0100 | mud | (~mud@user/kadoban) (Ping timeout: 255 seconds) |
| 2022-11-18 08:34:06 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 268 seconds) |
| 2022-11-18 08:34:32 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:65cf:cc10:c4dc:168) |
| 2022-11-18 08:43:49 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 08:47:49 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 08:50:51 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-18 08:56:12 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-18 08:56:50 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 08:57:45 +0100 | mud | (~mud@user/kadoban) |
| 2022-11-18 08:59:06 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-18 08:59:10 +0100 | youziqi | (~youziqi@103.37.140.90) |
| 2022-11-18 09:00:17 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 09:00:42 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-18 09:01:40 +0100 | <tomsmeding> | dminuoso: relevant to our discussion yesterday, and published two days before it :p https://serokell.io/blog/datakinds-are-not-what-you-think |
| 2022-11-18 09:02:03 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-11-18 09:02:38 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-11-18 09:08:20 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-18 09:09:28 +0100 | michalz | (~michalz@185.246.207.203) |
| 2022-11-18 09:12:03 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-18 09:15:35 +0100 | mncheck | (~mncheck@193.224.205.254) |
| 2022-11-18 09:17:20 +0100 | libertyprime | (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) |
| 2022-11-18 09:20:54 +0100 | <Inst> | this freaking toolchain |
| 2022-11-18 09:21:18 +0100 | <Inst> | why is it a bad idea to --lib with Cabal again? |
| 2022-11-18 09:21:27 +0100 | <Inst> | I think I just discovered why because I've been using --lib to get HLS to work |
| 2022-11-18 09:21:53 +0100 | <Inst> | now i'm stuck reinstalling GHCup and my whole Haskell toolchain |
| 2022-11-18 09:22:02 +0100 | <Inst> | VSC Haskell wouldn't recognize a bunch of libraries, etc |
| 2022-11-18 09:22:08 +0100 | <Inst> | VSC HLS |
| 2022-11-18 09:22:17 +0100 | <Inst> | then it stalled my attempt to get servant to work because fo types |
| 2022-11-18 09:22:19 +0100 | <Inst> | great |
| 2022-11-18 09:22:48 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-18 09:26:07 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 09:27:51 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: leaving) |
| 2022-11-18 09:28:54 +0100 | <tomsmeding> | Inst: HLS won't recognise a bunch of libraries? Are they correctly listed in the build-depends of you .cabal file, did you 'cabal build', and did you restart HLS? |
| 2022-11-18 09:29:11 +0100 | <tomsmeding> | doing those things hasn't failed me yet with semi-recent HLS versions |
| 2022-11-18 09:30:04 +0100 | <c_wraith> | if they're using cabal install --lib, they probably don't have a .cabal file |
| 2022-11-18 09:30:45 +0100 | <tomsmeding> | c_wraith: they said they've been using --lib to get HLS to work; presumably they at least have a .cabal file but something somehow doesn't work? |
| 2022-11-18 09:31:02 +0100 | <tomsmeding> | Otherwise it makes sense they're criticising the toolchain, because they don't understand it :p |
| 2022-11-18 09:31:12 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-11-18 09:31:43 +0100 | merijn | (~merijn@c-001-001-012.client.esciencecenter.eduvpn.nl) |
| 2022-11-18 09:32:03 +0100 | <Inst> | i have a cabal file |
| 2022-11-18 09:32:07 +0100 | <Inst> | i don't use cabal files that much |
| 2022-11-18 09:32:20 +0100 | <tomsmeding> | does it list all the dependencies you need? Does 'cabal build' work? |
| 2022-11-18 09:32:26 +0100 | <tomsmeding> | (or 'stack build') |
| 2022-11-18 09:32:31 +0100 | <Inst> | let me try this stuff again |
| 2022-11-18 09:32:43 +0100 | <Inst> | cabal build works, HLS on the other hand reports a type error |
| 2022-11-18 09:32:50 +0100 | <Inst> | sorry about this |
| 2022-11-18 09:32:51 +0100 | <Inst> | ugh |
| 2022-11-18 09:32:56 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 252 seconds) |
| 2022-11-18 09:32:59 +0100 | <tomsmeding> | do you have a stack.yaml file too? |
| 2022-11-18 09:33:12 +0100 | <tomsmeding> | Perhaps HLS is using the stack infrastructure to build and is getting different package versions |
| 2022-11-18 09:33:13 +0100 | <Inst> | i don't think i do |
| 2022-11-18 09:33:21 +0100 | <Inst> | just reinstalled GHCup, restarting VSC |
| 2022-11-18 09:33:22 +0100 | <tomsmeding> | is there a .stack-work folder in your project? |
| 2022-11-18 09:33:33 +0100 | <Inst> | nope |
| 2022-11-18 09:33:35 +0100 | <tomsmeding> | good |
| 2022-11-18 09:36:22 +0100 | <Inst> | hmmm, Haskell extension on VSC on Windows is demanding to install Stack |
| 2022-11-18 09:36:23 +0100 | <Inst> | ffff |
| 2022-11-18 09:36:42 +0100 | <tomsmeding> | don't |
| 2022-11-18 09:36:46 +0100 | <tomsmeding> | just say no |
| 2022-11-18 09:37:05 +0100 | <tomsmeding> | it's too pushy about that IMO |
| 2022-11-18 09:38:25 +0100 | <Inst> | too late |
| 2022-11-18 09:38:32 +0100 | <Inst> | i suppose ghcup rm stack, no? |
| 2022-11-18 09:39:16 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-18 09:40:03 +0100 | <tomsmeding> | if it used ghcup to install it, yes |
| 2022-11-18 09:40:24 +0100 | <maerwald[m]> | GHCup installs stack by default |
| 2022-11-18 09:40:31 +0100 | <maerwald[m]> | You can tell the vscode extension to never install stack |
| 2022-11-18 09:40:34 +0100 | <tomsmeding> | only if you ask it to, right? |
| 2022-11-18 09:40:35 +0100 | <tomsmeding> | OH |
| 2022-11-18 09:40:37 +0100 | <tomsmeding> | TELL ME HOW |
| 2022-11-18 09:40:44 +0100 | <tomsmeding> | I need to tell my students that |
| 2022-11-18 09:40:57 +0100 | <money> | HELP |
| 2022-11-18 09:41:00 +0100 | <maerwald[m]> | https://github.com/haskell/vscode-haskell#setting-a-specific-toolchain |
| 2022-11-18 09:42:10 +0100 | <maerwald[m]> | {"haskell.toolchain": { "stack": null }} |
| 2022-11-18 09:43:01 +0100 | <tomsmeding> | <3 |
| 2022-11-18 09:44:50 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-18 09:44:56 +0100 | <maerwald[m]> | Anyone knows why the survey results take so long? |
| 2022-11-18 09:46:11 +0100 | <dminuoso> | I havent fixed up the results, yet. |
| 2022-11-18 09:46:44 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 248 seconds) |
| 2022-11-18 09:48:33 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-11-18 09:49:45 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-18 09:51:52 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2022-11-18 09:53:28 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-18 09:54:35 +0100 | <tomsmeding> | dminuoso: are you running it this year? |
| 2022-11-18 09:55:41 +0100 | <dminuoso> | No sorry, that was just a snarky comment. |
| 2022-11-18 09:55:51 +0100 | <tomsmeding> | :p |
| 2022-11-18 09:56:38 +0100 | Inst_ | (~Inst@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-18 09:56:40 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-11-18 09:56:49 +0100 | acidjnk | (~acidjnk@p200300d6e7137a33bcc873a44fb839de.dip0.t-ipconnect.de) |
| 2022-11-18 09:57:33 +0100 | Robert35 | (~Robert@wpa52.eduroam.gu.se) |
| 2022-11-18 09:57:45 +0100 | Inst | (~Inst@2601:6c4:4081:54f0:155b:1b8c:fa18:504e) (Ping timeout: 256 seconds) |
| 2022-11-18 09:58:12 +0100 | <Robert35> | Hi! One or two weeks ago I brought up some questions of MVar and IORef. Someone posted a hack of creating an 'empty' ioref, but I did not save that code |
| 2022-11-18 09:58:36 +0100 | <dminuoso> | Robert35: foo <- newIORef (error "foo not initialized") |
| 2022-11-18 09:58:38 +0100 | <Robert35> | Does anyone have any tips for creating 'empty' IORef, similarly to MVar? I need to create & get a reference to an IORef before I actually can write to it |
| 2022-11-18 09:58:42 +0100 | dminuoso | is fairly sure that was himself |
| 2022-11-18 09:58:45 +0100 | <Robert35> | Oh right |
| 2022-11-18 09:58:59 +0100 | <Robert35> | newIORef does not evaluate the initial contents |
| 2022-11-18 09:59:01 +0100 | <dminuoso> | Robert35: Alternatively hide the IORef behind an interface that uses Maybe |
| 2022-11-18 09:59:20 +0100 | <dminuoso> | Benefit is that you can cleanly throw an IO exception upon your readIORef wrapper if the actual IORef has a Nothing |
| 2022-11-18 09:59:26 +0100 | <Robert35> | I think your LOC above is sufficient |
| 2022-11-18 09:59:43 +0100 | <Inst_> | the thing disables itself |
| 2022-11-18 09:59:44 +0100 | Inst_ | Inst |
| 2022-11-18 09:59:49 +0100 | <Robert35> | I wlll initialize them in a principled way, so I have no risk of reading it before there is an actual value in it |
| 2022-11-18 09:59:59 +0100 | <dminuoso> | Robert35: Is this more than just one use of it? |
| 2022-11-18 10:00:05 +0100 | <Inst> | if you say no |
| 2022-11-18 10:00:11 +0100 | <Inst> | thanks for the override to disable stack |
| 2022-11-18 10:00:12 +0100 | <dminuoso> | If yes, I would strongly consider using a wrapper interface. |
| 2022-11-18 10:00:48 +0100 | <Inst> | now HLS is complaining it can't find a package database |
| 2022-11-18 10:00:50 +0100 | <dminuoso> | Robert35: Anyway, there's a bunch of different perhaps better techniques - mostly "dont let this happen in the first place" |
| 2022-11-18 10:01:05 +0100 | <Inst> | haskell-language-server-9.2.4~1.8.0.0.exe: can't find a package database at C:\GHCup\cabal\store\ghc-9.2.4\package.dbcompiler |
| 2022-11-18 10:01:16 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 10:01:18 +0100 | <dminuoso> | Robert35: One example is using a higher kinded data type, where you have some `validateInput :: Input Maybe -> Validation Err (Input Identity)` |
| 2022-11-18 10:01:30 +0100 | <Robert35> | The codebase I am modifying is full of hacks anyway |
| 2022-11-18 10:01:39 +0100 | <Robert35> | This seems like a fairly simple hack |
| 2022-11-18 10:01:46 +0100 | <dminuoso> | With `data Input f = Input { inpUser :: f Text, inpEmail :: f Text, inpAge :: Int }` |
| 2022-11-18 10:02:23 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-18 10:02:29 +0100 | <dminuoso> | Robert35: fair enough, just use it sparingly. it is a powerful technique however |
| 2022-11-18 10:02:33 +0100 | <Robert35> | I will read from it more than once, but in a controlled way |
| 2022-11-18 10:02:36 +0100 | <Robert35> | With great power ~ |
| 2022-11-18 10:02:40 +0100 | <dminuoso> | GHC itself in its implementation actually uses this trick in a few places |
| 2022-11-18 10:02:57 +0100 | <dminuoso> | Mostly because it avoids the need to have multiple versions of a data type where one or two fields might be missing at some stage |
| 2022-11-18 10:04:10 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 256 seconds) |
| 2022-11-18 10:04:41 +0100 | <Inst> | i mean, it could be worse |
| 2022-11-18 10:04:48 +0100 | <Inst> | i'm sure if i reinstall windows this'll all of a sudden start working |
| 2022-11-18 10:08:34 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-11-18 10:09:50 +0100 | libertyprime | (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 256 seconds) |
| 2022-11-18 10:09:56 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-11-18 10:10:19 +0100 | <sm> | Inst: for hls stuff, try also #haskell-language-server |
| 2022-11-18 10:10:33 +0100 | <Inst> | thanks |
| 2022-11-18 10:10:38 +0100 | <Inst> | also, dead chat, but what can i do |
| 2022-11-18 10:12:33 +0100 | <__monty__> | Meditate and become a paragon of patience. |
| 2022-11-18 10:13:05 +0100 | Robert35 | (~Robert@wpa52.eduroam.gu.se) (Ping timeout: 260 seconds) |
| 2022-11-18 10:13:18 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) |
| 2022-11-18 10:13:19 +0100 | dibblego | (~dibblego@122-199-1-30.ip4.superloop.com) (Changing host) |
| 2022-11-18 10:13:19 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2022-11-18 10:13:43 +0100 | chele | (~chele@user/chele) |
| 2022-11-18 10:14:50 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-11-18 10:15:28 +0100 | simp|e | (skralg@user/simple) (Ping timeout: 252 seconds) |
| 2022-11-18 10:19:44 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-18 10:21:22 +0100 | <Inst> | meditate and drop off this mortal coil |
| 2022-11-18 10:21:26 +0100 | <Inst> | but programming is a lot about patience, tbh |
| 2022-11-18 10:22:11 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-18 10:22:13 +0100 | <Inst> | strangely enough, but this is part of an opinion of mine, that haskell is more about engineering, lisps are about wizardry |
| 2022-11-18 10:22:24 +0100 | <Inst> | are there any actual haskell gods / wizards? |
| 2022-11-18 10:22:39 +0100 | <Inst> | i hear more of haskell skill being ascribed to Haskell than Haskellers |
| 2022-11-18 10:22:44 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-11-18 10:29:54 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-18 10:30:57 +0100 | <__monty__> | There's the Kmettiverse and people like Oleg : ) |
| 2022-11-18 10:32:25 +0100 | nschoe | (~q@2a01:e0a:8e:a190:c3cc:9b76:de4b:1492) |
| 2022-11-18 10:32:52 +0100 | CiaoSen | (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-11-18 10:39:18 +0100 | <maerwald[m]> | __monty__: there's no one like Oleg. There's just Oleg. |
| 2022-11-18 10:39:36 +0100 | arthurs115 | (~arthurs11@2405:9800:b653:8c03:e450:c6b6:f077:6a04) |
| 2022-11-18 10:39:52 +0100 | arthurs115 | (~arthurs11@2405:9800:b653:8c03:e450:c6b6:f077:6a04) (Client Quit) |
| 2022-11-18 10:40:49 +0100 | simp|e | (~skralg@user/simple) |
| 2022-11-18 10:41:40 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2022-11-18 10:41:52 +0100 | <Inst> | Are Haskell gods different from other programming gods / wizards, though? |
| 2022-11-18 10:42:06 +0100 | <Inst> | To me, Oleg is known through his papers. |
| 2022-11-18 10:42:24 +0100 | <Inst> | Kmett is known for his libraries |
| 2022-11-18 10:42:46 +0100 | <Inst> | I'd assume other programmers would be known for their work; like, of prominent clojurists, what they're known for is that so and so can code without tests |
| 2022-11-18 10:43:07 +0100 | <Inst> | anyways, nuked my GHCide |
| 2022-11-18 10:43:32 +0100 | <Inst> | works now, but back to the older problem |
| 2022-11-18 10:43:36 +0100 | <dminuoso> | It should be said, we also have a second Oleg that is prominent for having authored or maintaining a lot of libraries too. |
| 2022-11-18 10:44:16 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 10:44:33 +0100 | <dminuoso> | Maintainer for what feels like a third of the widely used packages on hackage. |
| 2022-11-18 10:45:02 +0100 | <dminuoso> | (Well trustee in fact) |
| 2022-11-18 10:45:05 +0100 | <Inst> | Oleg Grenrus? |
| 2022-11-18 10:45:52 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3cb4:cd70:33e6:e916) (Ping timeout: 260 seconds) |
| 2022-11-18 10:46:10 +0100 | <__monty__> | How are libraries not "their work?" |
| 2022-11-18 10:46:43 +0100 | <Inst> | I assume one difference is that Haskell gods tend to be known for their papers and their libraries, in part because say, Oleg Kisarov: he seems to be a defense contractor so his "good stuff" is likely national security |
| 2022-11-18 10:47:02 +0100 | <__monty__> | And coding without tests sounds more like a disability. Only makes it harder for whoever comes after you. And they're probably constantly testing stuff in the REPL anyway which is just non-automated testing. |
| 2022-11-18 10:47:14 +0100 | <Inst> | oh, he's at Tohoku University right now |
| 2022-11-18 10:47:52 +0100 | <__monty__> | Also though, why are you looking for cults of personality? |
| 2022-11-18 10:48:17 +0100 | <dminuoso> | I think there is a misconception that good programmers are "gods given gift" that dont even need to write tests. |
| 2022-11-18 10:48:29 +0100 | <dminuoso> | What makes a programmer good it not really the ability to write complicated code. |
| 2022-11-18 10:48:44 +0100 | <Inst> | also possibly it might be an issue with Clojure culture, my understanding of Clojure is that it's all wizards who write unmaintainable code |
| 2022-11-18 10:48:55 +0100 | <Inst> | more powerful than Haskell, but substantially less scalable |
| 2022-11-18 10:49:05 +0100 | <Inst> | like Klarna abandoned Clojure |
| 2022-11-18 10:50:11 +0100 | <Inst> | https://news.ycombinator.com/item?id=27301219 |
| 2022-11-18 10:50:53 +0100 | <dminuoso> | I recall a stackoverflow thread, in which someone claimed that a language like go (or some other similar language) was good because it allowed complete newcomers to instantly dead and understood code that any senior expert wrote. |
| 2022-11-18 10:51:16 +0100 | <dminuoso> | And someone else (might have been edward even) remarked, that they thought this was scary and perhaps actually a downside to go. |
| 2022-11-18 10:51:32 +0100 | <dminuoso> | If the bar was so low, that you could only communicate the simplest thoughts that a beginner could express, then you could never express your actual thoughts. |
| 2022-11-18 10:52:11 +0100 | <dminuoso> | Part of what makes Haskell a bit more complicated, and perhaps imbue that legendary perception of some programmers, is that unlike many other languages, you can express thought much like you can express ideas in mathematics |
| 2022-11-18 10:52:40 +0100 | <dminuoso> | It lets you express domain specific things very well, but only for people well versed in that domain |
| 2022-11-18 10:53:00 +0100 | <probie> | Things like "not supporting a map function" are considered to be positive features of Go |
| 2022-11-18 10:53:28 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-11-18 10:53:47 +0100 | <dminuoso> | Well I mean this is by design. Go is designed to have the bar at the entry level, so you can hire people straight from high school en masse, and put them to work. |
| 2022-11-18 10:54:10 +0100 | <dminuoso> | That's not really a "downside", its a core design feature of the language. |
| 2022-11-18 10:54:51 +0100 | Cid47 | (~Cid47@110.226.84.78) |
| 2022-11-18 10:55:35 +0100 | <dminuoso> | It's designed for hiring and throwing lots of inexperienced people at a problem. And for that, it must not be even possible to express complicated thought. |
| 2022-11-18 10:58:05 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-11-18 10:58:45 +0100 | <dminuoso> | Much of edkmet code is not really that complicated, or requires magical powers to understand. It just requires a reader to study the domain for a moment |
| 2022-11-18 10:59:31 +0100 | acidjnk | (~acidjnk@p200300d6e7137a33bcc873a44fb839de.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 11:00:22 +0100 | <c_wraith> | :t confusing |
| 2022-11-18 11:00:23 +0100 | <lambdabot> | Applicative f => LensLike (Data.Functor.Day.Curried.Curried (Data.Functor.Yoneda.Yoneda f) (Data.Functor.Yoneda.Yoneda f)) s t a b -> LensLike f s t a b |
| 2022-11-18 11:00:27 +0100 | <c_wraith> | but sometimes there's that |
| 2022-11-18 11:01:21 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 11:04:50 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 11:04:53 +0100 | <dminuoso> | c_wraith: To be fair, that isnt even Edwards creation. Eric Mertens was responsible for that,. |
| 2022-11-18 11:05:55 +0100 | mncheck | (~mncheck@193.224.205.254) (Remote host closed the connection) |
| 2022-11-18 11:06:24 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-18 11:06:54 +0100 | <dminuoso> | And in addition, lens has received a lot of work over the years. If you start at how `confusing` was introduced, it seemed much simpler and more obvious this way. It was just over the years that it was generalized |
| 2022-11-18 11:07:15 +0100 | Cid47 | Sid47 |
| 2022-11-18 11:07:50 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 240 seconds) |
| 2022-11-18 11:12:45 +0100 | Sid47 | (~Cid47@110.226.84.78) (Quit: Connection closed) |
| 2022-11-18 11:13:32 +0100 | acidjnk | (~acidjnk@p200300d6e7137a33d8eab253bd5e2a70.dip0.t-ipconnect.de) |
| 2022-11-18 11:15:04 +0100 | Sid47 | (~sid@110.226.84.78) |
| 2022-11-18 11:15:32 +0100 | Sid47 | (~sid@110.226.84.78) (Client Quit) |
| 2022-11-18 11:19:06 +0100 | kuribas | (~user@ptr-17d51enw7vbqv4wetdn.18120a2.ip6.access.telenet.be) |
| 2022-11-18 11:24:30 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-11-18 11:28:29 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-11-18 11:31:20 +0100 | tabaqui | (~root@85.106.195.55) (Quit: WeeChat 3.7.1) |
| 2022-11-18 11:32:47 +0100 | vpan | (~0@212.117.1.172) |
| 2022-11-18 11:34:30 +0100 | <Inst> | also re maerwald: |
| 2022-11-18 11:34:31 +0100 | <Inst> | [ Warn ] New ghc version available. To upgrade, run 'ghcup install ghc 9.4.3' |
| 2022-11-18 11:34:31 +0100 | <Inst> | [ Info ] verifying digest of: gs.exe |
| 2022-11-18 11:34:31 +0100 | <Inst> | [ Warn ] stack-2.9.1 is already installed; if you really want to reinstall it, you may want to run 'ghcup install cabal --force 2.9.1' |
| 2022-11-18 11:36:30 +0100 | <tomsmeding> | lol typo |
| 2022-11-18 11:39:11 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-18 11:40:00 +0100 | fockerize | (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 2022-11-18 11:40:28 +0100 | <Guest75> | Hello. Can anyone help with producing an instance of FixF? https://hackage.haskell.org/package/data-fix-0.3.2/docs/Data-Fix.html |
| 2022-11-18 11:40:55 +0100 | <Guest75> | I fail, 'cause that List a isn't Fix f |
| 2022-11-18 11:40:57 +0100 | ubert | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-11-18 11:40:57 +0100 | ub | ubert |
| 2022-11-18 11:43:49 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-18 11:44:16 +0100 | <byorgey> | Guest75: not sure I understand your question. Can you put your code so far on https://paste.tomsmeding.com/ ? |
| 2022-11-18 11:45:15 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-18 11:47:13 +0100 | ubert1 | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) |
| 2022-11-18 11:48:31 +0100 | <dminuoso> | What is FixF? |
| 2022-11-18 11:50:08 +0100 | CiaoSen | (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 11:50:42 +0100 | <Guest75> | byorgey: here it is https://paste.tomsmeding.com/qYZmBqnp |
| 2022-11-18 11:51:19 +0100 | <Guest75> | dminuoso: I believe it's like Fixed point combinator, but for types |
| 2022-11-18 11:51:34 +0100 | <Guest75> | related video: https://www.youtube.com/watch?v=zkDVCQiveEo |
| 2022-11-18 11:51:55 +0100 | sid__ | (~sid@110.226.84.78) |
| 2022-11-18 11:52:07 +0100 | <kuribas> | Guest75: are you missing a Fix constructor? |
| 2022-11-18 11:52:22 +0100 | <sid__> | exit |
| 2022-11-18 11:52:29 +0100 | <dminuoso> | Guest75: Which `Fix` are you using? Did you define it yourself? Or which module is it from? |
| 2022-11-18 11:52:53 +0100 | <dminuoso> | Are we talking about Data.Fix from data-fix? |
| 2022-11-18 11:52:57 +0100 | <tomsmeding> | dminuoso: presumably https://hackage.haskell.org/package/data-fix-0.3.2/docs/Data-Fix.html which they linked before |
| 2022-11-18 11:53:07 +0100 | <dminuoso> | Oh I did not see that link |
| 2022-11-18 11:53:10 +0100 | <kuribas> | Cons 1 $ Fix $ Cons 2 $ Fix $ Cons 3 $ Fix Nil |
| 2022-11-18 11:53:17 +0100 | <Guest75> | aha |
| 2022-11-18 11:54:24 +0100 | <Guest75> | thanks kuribas, it works now! |
| 2022-11-18 11:55:11 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-18 11:55:28 +0100 | <kuribas> | np |
| 2022-11-18 11:55:28 +0100 | <Guest75> | so that menas that if I make my own type higher-kinded, then for all my data constructors I'll need to prepend them with Fix |
| 2022-11-18 11:55:35 +0100 | <kuribas> | yes |
| 2022-11-18 11:55:47 +0100 | <Guest75> | +about 50 lines of code :/ |
| 2022-11-18 11:56:13 +0100 | <kuribas> | So just use normal lists :) |
| 2022-11-18 11:56:22 +0100 | <kuribas> | And don't bother with recursion schemes |
| 2022-11-18 11:56:30 +0100 | <kuribas> | they don't add much anyway. |
| 2022-11-18 11:56:56 +0100 | sid__ | (~sid@110.226.84.78) (Ping timeout: 256 seconds) |
| 2022-11-18 11:56:57 +0100 | <byorgey> | Guest75: pattern synonyms can be helpful |
| 2022-11-18 11:57:10 +0100 | <kuribas> | ah true |
| 2022-11-18 11:57:19 +0100 | <kuribas> | and wrapping stuff in newtypes is pretty idiomatic haskell. |
| 2022-11-18 11:57:42 +0100 | <Guest75> | well: https://github.com/andrewboltachev/pyparts/blob/master/src/Lib.hs#L68 |
| 2022-11-18 11:57:46 +0100 | <kuribas> | I find the amount of boilerplate in haskell still much less than in java. |
| 2022-11-18 11:58:18 +0100 | <Guest75> | for this I think I it'll be helpful for many reasons if I'll make the type parametric |
| 2022-11-18 11:58:28 +0100 | <Guest75> | i.e. higher-kinded |
| 2022-11-18 11:59:01 +0100 | <kuribas> | Guest75: that's not higher-kinded? |
| 2022-11-18 11:59:33 +0100 | <Guest75> | it's just "data MatchPattern = ...", not "data MatchPattern a = ..." |
| 2022-11-18 12:02:53 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 2022-11-18 12:03:39 +0100 | <Guest75> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pattern_synonyms.html — giving programming languages as example — insane! (though that's what I also use) |
| 2022-11-18 12:04:01 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-18 12:04:07 +0100 | AkechiShiro | (~licht@user/akechishiro) (Ping timeout: 256 seconds) |
| 2022-11-18 12:04:09 +0100 | <kuribas> | Guest75: so what's wrong with that code? |
| 2022-11-18 12:04:39 +0100 | <Guest75> | no that's fine. just it's not "apples and bananas" or "cats and dogs", or "users and orders" etc |
| 2022-11-18 12:04:41 +0100 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 256 seconds) |
| 2022-11-18 12:04:52 +0100 | Luj3 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (Ping timeout: 256 seconds) |
| 2022-11-18 12:07:36 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-11-18 12:08:13 +0100 | <kuribas> | I find you often end up with GADTs, HKD types, etc, when trying to create declarative specs. |
| 2022-11-18 12:08:31 +0100 | <kuribas> | As opposed to using function combinators. |
| 2022-11-18 12:09:20 +0100 | <kuribas> | The advantage of a declarative spec is that you can use them in multiple ways, simplify or transform them, etc... |
| 2022-11-18 12:09:32 +0100 | <kuribas> | But you easily reach the limits of haskells type system. |
| 2022-11-18 12:09:56 +0100 | dminuoso | finds HKDs disstateful |
| 2022-11-18 12:10:12 +0100 | <kuribas> | Having to wrap a lot of stuff in newtypes is one result of it, though not a big deal. |
| 2022-11-18 12:10:18 +0100 | <kuribas> | dminuoso: that's a nice word :) |
| 2022-11-18 12:10:27 +0100 | <dminuoso> | Heh that typo |
| 2022-11-18 12:10:44 +0100 | <Guest75> | kuribas: I have similar feeling. that I will reach limits soon |
| 2022-11-18 12:11:23 +0100 | <Guest75> | moreover, I need this "structurre" to be mapped to sth else. i.e. to create an UI to construct this data type expressions |
| 2022-11-18 12:11:54 +0100 | <kuribas> | dminuoso: they are necessary when you want to make declarative specs like in lisp, but keep type safety. |
| 2022-11-18 12:12:15 +0100 | <Guest75> | kuribas: what's the minimal example of function combinators? |
| 2022-11-18 12:12:35 +0100 | <kuribas> | Guest75: a parser for example. |
| 2022-11-18 12:12:44 +0100 | <kuribas> | Guest75: like parsec |
| 2022-11-18 12:12:53 +0100 | <Guest75> | well, what I'm doing is essentially a parser |
| 2022-11-18 12:13:16 +0100 | <Guest75> | well, I need to read up and learn about on existing stuff first then |
| 2022-11-18 12:13:17 +0100 | <dminuoso> | kuribas: I dont think of them as being *necessary* |
| 2022-11-18 12:13:22 +0100 | dminuoso | shrugs |
| 2022-11-18 12:14:09 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 12:19:11 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-18 12:23:58 +0100 | ScK | (~ScK@110.226.84.78) |
| 2022-11-18 12:25:03 +0100 | ScK | (~ScK@110.226.84.78) (Quit: Leaving) |
| 2022-11-18 12:29:43 +0100 | swamp_ | (~zmt00@user/zmt00) (Ping timeout: 252 seconds) |
| 2022-11-18 12:30:21 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-18 12:30:41 +0100 | razetime | (~quassel@117.193.0.17) |
| 2022-11-18 12:37:23 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-11-18 12:44:17 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 12:48:53 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Ping timeout: 256 seconds) |
| 2022-11-18 12:50:14 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-18 12:50:53 +0100 | <lortabac> | I find that those who are used to dynamically-typed languages tend to use advanced types in Haskell more than those who come from an OOP background |
| 2022-11-18 12:52:02 +0100 | <lortabac> | maybe there is a desire to replicate the same flexibility and genericity that we enjoyed in the dynamically-typed world |
| 2022-11-18 12:52:57 +0100 | <merijn> | lortabac: I find that's mostly people getting excited about types and then overcorrecting and leaning on them too hard |
| 2022-11-18 12:53:02 +0100 | <merijn> | trying to do *everything* in the types |
| 2022-11-18 12:53:46 +0100 | <lortabac> | merijn: that's also an important factor |
| 2022-11-18 12:54:37 +0100 | <lortabac> | but there is also this habit of making super-generic duck-typed abstractions |
| 2022-11-18 12:54:41 +0100 | <dminuoso> | merijn: +1 |
| 2022-11-18 12:54:58 +0100 | <lortabac> | when you try to replicate them in Haskell you end up with HKD and other complicated stuff |
| 2022-11-18 12:55:13 +0100 | <dminuoso> | Once I realized that I increased complexity and issues by doing that, I've actually come down to writing simple code as much as possible. |
| 2022-11-18 12:55:20 +0100 | <lortabac> | at least that's my personal experience |
| 2022-11-18 12:56:12 +0100 | <lortabac> | it took me years to understand that in a statically-typed setting sometimes it's better to accept a little bit of duplication |
| 2022-11-18 12:57:43 +0100 | <dminuoso> | What I would really like is being able to attach data to constructors and fields, in a way that you can recover them. Quite a few non-trivial uses of HKDs or even weird Generics would be better solved by that. |
| 2022-11-18 12:58:12 +0100 | glguy | (~glguy@libera/staff-emeritus/glguy) (Ping timeout: 248 seconds) |
| 2022-11-18 12:58:15 +0100 | <lortabac> | that would be a great feature |
| 2022-11-18 12:59:18 +0100 | glguy | (~glguy@libera/staff-emeritus/glguy) |
| 2022-11-18 13:05:21 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 13:06:17 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-11-18 13:07:16 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-18 13:10:02 +0100 | Techcable | (~Techcable@user/Techcable) (Ping timeout: 256 seconds) |
| 2022-11-18 13:15:33 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-18 13:18:00 +0100 | Major_Biscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Ping timeout: 260 seconds) |
| 2022-11-18 13:21:13 +0100 | Luj3 | (~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) |
| 2022-11-18 13:25:14 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-18 13:26:42 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 13:26:45 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-18 13:27:47 +0100 | AkechiShiro | (~licht@user/akechishiro) |
| 2022-11-18 13:27:57 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-18 13:28:09 +0100 | <dminuoso> | tomsmeding: https://github.com/dminuoso/flatparse-state/blob/main/app/Main.hs |
| 2022-11-18 13:28:21 +0100 | <dminuoso> | Here we go, this is actually even better. :) |
| 2022-11-18 13:28:38 +0100 | <dminuoso> | Idea being to rework all of flatparse with `State# s` threading |
| 2022-11-18 13:28:56 +0100 | <dminuoso> | It's kind of cute you get a) pure parsers, b) IO parser and c) ST parsers all for free from this. |
| 2022-11-18 13:30:17 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-18 13:34:43 +0100 | <Xeroine> | Hi, what is the problem here https://bpa.st/LFDQ I was trying to install ghc-vis while using debian's repo cabal-install, ghc and ghci but after several hours of trying to find what was causing ghci not to find GHC.Vis despite it being installed I decided to reinstall ghc, ghci and cabal-install using ghcup since it has newer versions of them and now I'm getting this error |
| 2022-11-18 13:34:58 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-11-18 13:35:22 +0100 | <Xeroine> | previously I had a similar issue but I resolved it by installing a library with cairo or svg in it's name (don't remember what was the package's name) |
| 2022-11-18 13:35:57 +0100 | <Xeroine> | now I'm guessing there's some kind of issue with the version I have for that library from the debian repo? |
| 2022-11-18 13:38:03 +0100 | <Xeroine> | I don't really understand the error message, is it trying to install svgcairo as a dependency for ghc-vis and is trying different versions of svgcairo until it no longer satisfies the dependecy version? is that what's happening? |
| 2022-11-18 13:38:25 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-11-18 13:41:26 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-11-18 13:43:19 +0100 | mauke_ | mauke |
| 2022-11-18 13:44:20 +0100 | pottsy | (~pottsy@129.227.183.244) (Quit: Leaving) |
| 2022-11-18 13:46:04 +0100 | <Xeroine> | vacuum-graphviz also has some kind of version issue https://bpa.st/ACVQ |
| 2022-11-18 13:46:29 +0100 | <dminuoso> | https://github.com/gtk2hs/svgcairo/blob/master/svgcairo.cabal#L35 |
| 2022-11-18 13:46:44 +0100 | <dminuoso> | Xeroine: So this has an upper bound of Cabal to be lower than 3.1 |
| 2022-11-18 13:46:51 +0100 | frase | (~Fraser@159.196.13.21) () |
| 2022-11-18 13:46:55 +0100 | <dminuoso> | [__2] rejecting: svgcairo:setup.Cabal-3.6.3.0/installed-3.6.3.0 (conflict: svgcairo => svgcairo:setup.Cabal>=1.24 && <3.1) |
| 2022-11-18 13:47:12 +0100 | <dminuoso> | The cabal planner is trying to figure out version of cabal to pick that satisfies its constraints |
| 2022-11-18 13:47:24 +0100 | <dminuoso> | The installed version 3.6.3.0 cant be picked (because it violates the constraint <3.1) |
| 2022-11-18 13:49:02 +0100 | <dminuoso> | (it first tries the installed version) |
| 2022-11-18 13:49:13 +0100 | <dminuoso> | It then proceeds to skip cabal versions between 3.6.10 and 3.2.1.0 because they all fail the same constraint |
| 2022-11-18 13:49:31 +0100 | <dminuoso> | What I dont quite understand however, is this: |
| 2022-11-18 13:49:38 +0100 | <dminuoso> | svgcairo:setup.Cabal-1.24.1.0 (constraint from minimum version of Cabal used by Setup.hs requires >=3.4) |
| 2022-11-18 13:51:41 +0100 | <Xeroine> | oh |
| 2022-11-18 13:51:55 +0100 | <dminuoso> | That line really doesnt compute |
| 2022-11-18 13:52:38 +0100 | <Xeroine> | dminuoso: wait but so what happens when it figures out 3.6.3.0 can't be picked? it tries to install different cabal versions? |
| 2022-11-18 13:52:50 +0100 | <dminuoso> | Xeroine: Right. |
| 2022-11-18 13:52:53 +0100 | <Xeroine> | ah |
| 2022-11-18 13:52:54 +0100 | <dminuoso> | Xeroine: Cabal does this normally anyway |
| 2022-11-18 13:53:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 13:53:35 +0100 | <dminuoso> | So normally Cabal (the library!) should be installed at version 2.4.1.0 |
| 2022-11-18 13:53:39 +0100 | <dminuoso> | (or it should attempt that version) |
| 2022-11-18 13:53:50 +0100 | <dminuoso> | but for some reason I cant explain, a constraint >=3.4 is introduced |
| 2022-11-18 13:54:13 +0100 | <dminuoso> | (and >=3.4 combined with <3.1 is obviously mutually exclusive to the point that no version of Cabal could ever satisfy that) |
| 2022-11-18 13:54:59 +0100 | <dminuoso> | `cabal check` has some curious warnings about svgcairo, I wonder whether the cabal file might be broken |
| 2022-11-18 13:55:49 +0100 | <dminuoso> | Xeroine: My assumption is as follows: |
| 2022-11-18 13:55:52 +0100 | <dminuoso> | https://github.com/gtk2hs/svgcairo/blob/master/svgcairo.cabal#L9 |
| 2022-11-18 13:55:55 +0100 | <dminuoso> | This format with >= is no longer legit |
| 2022-11-18 13:57:01 +0100 | <dminuoso> | (It was only allowed before 1.12) |
| 2022-11-18 13:57:28 +0100 | <dminuoso> | https://cabal.readthedocs.io/en/stable/cabal-package.html says its supported up until >=2.0 however. |
| 2022-11-18 13:57:39 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-18 13:59:31 +0100 | youziqi | (~youziqi@103.37.140.90) (Ping timeout: 260 seconds) |
| 2022-11-18 14:00:01 +0100 | <Xeroine> | hmm |
| 2022-11-18 14:00:55 +0100 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) |
| 2022-11-18 14:01:10 +0100 | <Xeroine> | well I don't know, maybe it's easier to get something similar like vacuum-graphviz working then, but like I said I tried that as well and got different errors |
| 2022-11-18 14:01:40 +0100 | <Xeroine> | I just want to visualize data structures in haskell but looks like it's a pain in the ass to get those libraries installed and working =/ |
| 2022-11-18 14:04:52 +0100 | <dminuoso> | Aha! |
| 2022-11-18 14:04:56 +0100 | <dminuoso> | I have it figured out |
| 2022-11-18 14:05:39 +0100 | <dminuoso> | Xeroine: The package has a missing upper base constraint. |
| 2022-11-18 14:06:37 +0100 | <Xeroine> | dminuoso: you mean https://hackage.haskell.org/package/base ? |
| 2022-11-18 14:06:43 +0100 | <dminuoso> | (And an incorrect Cabal constraint in setup-depends) |
| 2022-11-18 14:06:48 +0100 | <dminuoso> | (or both, I guess) |
| 2022-11-18 14:07:01 +0100 | <dminuoso> | The Cabal constraint should be removed its redundant |
| 2022-11-18 14:07:06 +0100 | <dminuoso> | Roughly we have this: |
| 2022-11-18 14:07:23 +0100 | <dminuoso> | If you use a Setup.hs build, then cabal-install will automatically add a setup-depends constraint on Cabal |
| 2022-11-18 14:07:31 +0100 | <dminuoso> | In particular a minimum version |
| 2022-11-18 14:07:34 +0100 | <dminuoso> | https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/ProjectPlanning… |
| 2022-11-18 14:07:39 +0100 | <dminuoso> | That logic is used to select the minimum cabal version |
| 2022-11-18 14:08:04 +0100 | <dminuoso> | So presumably you use GHC 9.4, which is how cabal-install derives Cabal 3.4 or newer must be present |
| 2022-11-18 14:08:11 +0100 | <dminuoso> | However, that is in direct conflict with the author specified: |
| 2022-11-18 14:08:17 +0100 | <dminuoso> | https://github.com/gtk2hs/svgcairo/blob/master/svgcairo.cabal#L35 |
| 2022-11-18 14:08:24 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-11-18 14:09:34 +0100 | <dminuoso> | Using that table you can deduce, that this package at present can only build up until GHC 8.8, which means up until base 4.13.0.0 |
| 2022-11-18 14:09:54 +0100 | <Xeroine> | ah |
| 2022-11-18 14:10:12 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 14:10:25 +0100 | <Xeroine> | I'll try install a <= 8.8 GHC then |
| 2022-11-18 14:10:30 +0100 | <dminuoso> | I dont know whether there is actual restrictions, or whether the bounds can be bumped. Try it out or file a a bug report. Until then, use GHC 8.8 or older |
| 2022-11-18 14:13:46 +0100 | Major_Biscuit | (~MajorBisc@145.94.173.169) |
| 2022-11-18 14:14:27 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-18 14:18:30 +0100 | acidjnk | (~acidjnk@p200300d6e7137a33d8eab253bd5e2a70.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-11-18 14:24:05 +0100 | Major_Biscuit | (~MajorBisc@145.94.173.169) (Ping timeout: 256 seconds) |
| 2022-11-18 14:27:20 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-18 14:28:22 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-11-18 14:28:22 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-18 14:30:31 +0100 | ssw | (~ssw@user/ssw) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2022-11-18 14:31:53 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 14:32:58 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) |
| 2022-11-18 14:33:04 +0100 | ssw | (~ssw@user/ssw) |
| 2022-11-18 14:33:29 +0100 | blueonyx | (~blueonyx@user/blueonyx) |
| 2022-11-18 14:34:28 +0100 | pie_ | (~pie_bnc@user/pie/x-2818909) () |
| 2022-11-18 14:34:46 +0100 | pie_ | (~pie_bnc@user/pie/x-2818909) |
| 2022-11-18 14:37:35 +0100 | Major_Biscuit | (~MajorBisc@145.94.173.169) |
| 2022-11-18 14:38:12 +0100 | ssw | (~ssw@user/ssw) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2022-11-18 14:38:16 +0100 | <Xeroine> | dminuoso: it installed but I got a warning which said I might have needed to use --lib when installing but none of documentation for ghc-vis recommends --lib so I'm not sure if I should use it. Also ghc-vis window pops up when I run ":vis" in ghci but using ":view" on variables causes and error. Here's the paste with all of this https://bpa.st/ACVQ |
| 2022-11-18 14:39:16 +0100 | <Xeroine> | I'm on GHC 8.8.4 now by the way |
| 2022-11-18 14:41:17 +0100 | <dminuoso> | Xeroine: Is this the right paste? |
| 2022-11-18 14:41:34 +0100 | <dminuoso> | That looks like the output of `cabal install vacuum-graphviz`, not ghc-vis |
| 2022-11-18 14:42:30 +0100 | <Xeroine> | oh my bad |
| 2022-11-18 14:42:37 +0100 | <merijn> | hg diff |
| 2022-11-18 14:42:44 +0100 | <merijn> | terminal fail >.> |
| 2022-11-18 14:42:53 +0100 | <Xeroine> | I meant this one https://bpa.st/OJCA |
| 2022-11-18 14:45:24 +0100 | <dminuoso> | Xeroine: You can ignore the warning. |
| 2022-11-18 14:45:41 +0100 | <dminuoso> | ghc-vis is a bit special in that you do not get actual executables, but it is assumed you run this from ghci |
| 2022-11-18 14:46:02 +0100 | <Xeroine> | oh |
| 2022-11-18 14:46:12 +0100 | <dminuoso> | cabal-install acknowledges such cases by phrasing "it *might* not be completed" |
| 2022-11-18 14:47:00 +0100 | <dminuoso> | Xeroine: and the error you get is because you need the `dot` binary |
| 2022-11-18 14:47:08 +0100 | <dminuoso> | (s/binary/executable/) |
| 2022-11-18 14:48:22 +0100 | <Xeroine> | from the debian package manager or cabal? |
| 2022-11-18 14:48:33 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-11-18 14:49:02 +0100 | <dminuoso> | debian package manager |
| 2022-11-18 14:49:08 +0100 | <Xeroine> | alright |
| 2022-11-18 14:49:24 +0100 | <dminuoso> | http://felsin9.de/nnis/ghc-vis/installing-debian/ |
| 2022-11-18 14:49:32 +0100 | <dminuoso> | Note the installation of `graphviz` |
| 2022-11-18 14:49:48 +0100 | <dminuoso> | And some other dependencies you may need |
| 2022-11-18 14:51:54 +0100 | <Xeroine> | sigh... now it installed ghc from apt as well, I'll see if it causes problems in a sec |
| 2022-11-18 14:52:58 +0100 | <dminuoso> | oh, probably yes |
| 2022-11-18 14:53:12 +0100 | <dminuoso> | feel free to uninstall that, I did not closely go through the installed packages |
| 2022-11-18 14:53:50 +0100 | <Xeroine> | I think it installed it as a dependency of one of those libraries |
| 2022-11-18 14:54:12 +0100 | <Xeroine> | anyways the ghcup ghc is still being used over the debian one so I guess it's all good |
| 2022-11-18 14:54:15 +0100 | <Xeroine> | :view works as well now |
| 2022-11-18 14:54:18 +0100 | <Xeroine> | dminuoso: thanks |
| 2022-11-18 14:55:43 +0100 | <kuribas> | lortabac: the advantage of a declarative spec is that you can have multiple usecases for that spec. |
| 2022-11-18 14:56:24 +0100 | <kuribas> | lortabac: where a combinator usually just has a single usecase. |
| 2022-11-18 14:57:09 +0100 | <kuribas> | lortabac: or in other words, a combinator cannot be repurposed, while a data spec can. |
| 2022-11-18 14:57:47 +0100 | <kuribas> | or you have to go into metaprogramming using template haskell. |
| 2022-11-18 14:58:16 +0100 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2022-11-18 14:58:31 +0100 | ft | (~ft@i59F54BF7.versanet.de) |
| 2022-11-18 14:59:06 +0100 | <kuribas> | lortabac: take for example servant, you can generate openapi documentation, clients, etc... from a single spec. |
| 2022-11-18 14:59:13 +0100 | <kuribas> | you cannot do that with combinators. |
| 2022-11-18 14:59:43 +0100 | <dminuoso> | kuribas: You can do it with a code generator. |
| 2022-11-18 15:00:13 +0100 | <dminuoso> | Normally with OpenAPI the idea is the other way around. |
| 2022-11-18 15:00:21 +0100 | <dminuoso> | Start with the OpenAPI specification, generate boilerplate code from it. |
| 2022-11-18 15:01:12 +0100 | <kuribas> | that's easier for clients than for servers |
| 2022-11-18 15:01:28 +0100 | <dminuoso> | Why would it be any more difficult for servers? |
| 2022-11-18 15:02:12 +0100 | <kuribas> | how can you verify that your server matches the openapi spec, without unit tests? |
| 2022-11-18 15:02:23 +0100 | <kuribas> | you'll end up with redundant code. |
| 2022-11-18 15:02:41 +0100 | <dminuoso> | I can think of a few ways. |
| 2022-11-18 15:02:52 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 15:02:58 +0100 | <dminuoso> | You simply generate stub calls in the Setup.hs from the OpenAPI spec |
| 2022-11-18 15:03:06 +0100 | <dminuoso> | Which will assure matching types |
| 2022-11-18 15:03:07 +0100 | <kuribas> | and you know, openapi is actually a typed declarative spec :) |
| 2022-11-18 15:03:11 +0100 | <kuribas> | just not in the same language |
| 2022-11-18 15:03:15 +0100 | <dminuoso> | Sure. |
| 2022-11-18 15:03:28 +0100 | <kuribas> | dminuoso: and when you need to update the spec? |
| 2022-11-18 15:03:46 +0100 | <kuribas> | can you garantee the stub stays in sync? |
| 2022-11-18 15:04:01 +0100 | <dminuoso> | well, you can actually use the same stubs to actually call your code. |
| 2022-11-18 15:04:07 +0100 | <dminuoso> | then its a matter of you just fixing type errors. |
| 2022-11-18 15:04:55 +0100 | <dminuoso> | say an endpoint of `foo :: Int -> String -> IO Bool` is expected, and it gets changed to `foo :: Int -> String -> IO ()`, you have a "expected (), actual Bool" type of warning. |
| 2022-11-18 15:04:57 +0100 | <kuribas> | yes, that's a possibility |
| 2022-11-18 15:05:29 +0100 | <dminuoso> | this is roughly what the Corba IDL compilers do |
| 2022-11-18 15:05:56 +0100 | Everything | (~Everythin@37.115.210.35) |
| 2022-11-18 15:07:44 +0100 | <dminuoso> | kuribas: We do generate OpenAPI specs for one of our largest projects. |
| 2022-11-18 15:07:47 +0100 | <dminuoso> | via servant |
| 2022-11-18 15:07:55 +0100 | <dminuoso> | It's probably the most horrid haskell experience I've had., |
| 2022-11-18 15:08:04 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-18 15:08:04 +0100 | <dminuoso> | And I am comfortable with type level shenanigans |
| 2022-11-18 15:08:10 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-11-18 15:08:26 +0100 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2022-11-18 15:08:38 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2022-11-18 15:10:18 +0100 | mncheck | (~mncheck@193.224.205.254) |
| 2022-11-18 15:12:00 +0100 | srz | (~srz@157.92.5.222) |
| 2022-11-18 15:12:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 15:12:29 +0100 | mud | (~mud@user/kadoban) |
| 2022-11-18 15:13:37 +0100 | srz_ | (~srz@devil.dm.uba.ar) |
| 2022-11-18 15:15:37 +0100 | <lortabac> | it's a horrid experience because Haskell is not powerful enough for this kind of stuff, but given an imaginary infinitely expressive and ergonomic language I would definitely choose a Servant-like DSL to code-generation |
| 2022-11-18 15:16:38 +0100 | <lortabac> | code-generation is less powerful than types and introduces complexity at build level |
| 2022-11-18 15:16:47 +0100 | srz | (~srz@157.92.5.222) (Ping timeout: 256 seconds) |
| 2022-11-18 15:17:29 +0100 | <dminuoso> | But at least it is trivial to build said build level tools, and rig it with simple and expressive diagnostics |
| 2022-11-18 15:17:33 +0100 | <dminuoso> | Making it tractable in any way |
| 2022-11-18 15:20:27 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection) |
| 2022-11-18 15:21:27 +0100 | <lortabac> | yes I agree, I was thinking abstractly about the two approaches |
| 2022-11-18 15:22:03 +0100 | <lortabac> | but in practice I think you are right |
| 2022-11-18 15:22:36 +0100 | feliix42 | (~felix@gibbs.uberspace.de) (Ping timeout: 255 seconds) |
| 2022-11-18 15:23:18 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-18 15:25:21 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 15:30:44 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 248 seconds) |
| 2022-11-18 15:31:03 +0100 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2022-11-18 15:31:37 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-18 15:31:42 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-18 15:36:08 +0100 | Guest75 | (~Guest75@178.141.130.118) (Ping timeout: 260 seconds) |
| 2022-11-18 15:36:32 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 268 seconds) |
| 2022-11-18 15:37:22 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 15:38:38 +0100 | poljar | (~poljar@93-139-1-236.adsl.net.t-com.hr) |
| 2022-11-18 15:38:56 +0100 | econo | (uid147250@user/econo) |
| 2022-11-18 15:39:39 +0100 | _srz | (~srz@157.92.5.222) |
| 2022-11-18 15:42:05 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-18 15:42:41 +0100 | srz_ | (~srz@devil.dm.uba.ar) (Ping timeout: 268 seconds) |
| 2022-11-18 15:44:46 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) |
| 2022-11-18 15:47:12 +0100 | feliix42 | (~felix@gibbs.uberspace.de) |
| 2022-11-18 15:53:02 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-18 15:53:03 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-18 15:53:03 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-18 15:54:37 +0100 | srz_ | (~srz@devil.dm.uba.ar) |
| 2022-11-18 15:57:12 +0100 | _srz | (~srz@157.92.5.222) (Ping timeout: 256 seconds) |
| 2022-11-18 15:57:46 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 256 seconds) |
| 2022-11-18 16:07:58 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-18 16:15:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 16:19:18 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-18 16:20:28 +0100 | catern | (~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407) |
| 2022-11-18 16:20:31 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-18 16:22:12 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-11-18 16:26:34 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-11-18 16:29:42 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-11-18 16:29:53 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 16:34:36 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-18 16:42:33 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-18 16:45:56 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-18 16:47:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 16:49:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 16:51:23 +0100 | chomwitt | (~chomwitt@athedsl-351939.home.otenet.gr) |
| 2022-11-18 16:56:44 +0100 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-18 16:57:55 +0100 | srz_ | (~srz@devil.dm.uba.ar) (Ping timeout: 268 seconds) |
| 2022-11-18 16:58:10 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-18 16:59:24 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 17:06:05 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Ping timeout: 260 seconds) |
| 2022-11-18 17:07:37 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-18 17:14:27 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-18 17:17:44 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-18 17:20:28 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 17:21:39 +0100 | bjourne | (~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5) |
| 2022-11-18 17:22:11 +0100 | Major_Biscuit | (~MajorBisc@145.94.173.169) (Quit: WeeChat 3.6) |
| 2022-11-18 17:23:57 +0100 | vpan | (~0@212.117.1.172) (Quit: Leaving.) |
| 2022-11-18 17:24:18 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-18 17:24:50 +0100 | justGrit | (~justache@user/justache) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-18 17:25:15 +0100 | justache | (~justache@user/justache) |
| 2022-11-18 17:26:44 +0100 | <bjourne> | what is the haskell syntax for: data Eq a => Foo a = Blah a ...? |
| 2022-11-18 17:27:59 +0100 | <geekosaur> | it isn't. the "correct" syntax doesn't do what you expect or want, usually; you should put the constraint on functions that consume a Foo |
| 2022-11-18 17:28:28 +0100 | <geekosaur> | DatatypeContexts aka "stupid theta" was removed in Haskell2010 |
| 2022-11-18 17:29:21 +0100 | <geekosaur> | you can get something somewhat closer to what you usually intend with GADTs, but you're usually still better off putting it on consumers of a Foo than on its construction |
| 2022-11-18 17:29:59 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 2022-11-18 17:30:49 +0100 | justache | (~justache@user/justache) (Remote host closed the connection) |
| 2022-11-18 17:30:52 +0100 | rburkholder | (~blurb@96.45.2.121) (Remote host closed the connection) |
| 2022-11-18 17:31:09 +0100 | rburkholder | (~blurb@96.45.2.121) |
| 2022-11-18 17:31:12 +0100 | justache | (~justache@user/justache) |
| 2022-11-18 17:33:54 +0100 | kronicmage | (user93427@neotame.csclub.uwaterloo.ca) (Ping timeout: 246 seconds) |
| 2022-11-18 17:36:22 +0100 | kronicmage | (user90047@neotame.csclub.uwaterloo.ca) |
| 2022-11-18 17:40:20 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 256 seconds) |
| 2022-11-18 17:41:04 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-11-18 17:46:53 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-18 17:47:43 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 17:55:08 +0100 | blueonyx_ | (~blueonyx@user/blueonyx) |
| 2022-11-18 17:56:15 +0100 | blueonyx | (~blueonyx@user/blueonyx) (Ping timeout: 260 seconds) |
| 2022-11-18 17:56:53 +0100 | blueonyx_ | (~blueonyx@user/blueonyx) (Client Quit) |
| 2022-11-18 17:57:04 +0100 | blueonyx | (~blueonyx@user/blueonyx) |
| 2022-11-18 17:57:46 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-18 17:59:27 +0100 | bjourne | (~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5) (Quit: Konversation terminated!) |
| 2022-11-18 17:59:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-18 18:02:41 +0100 | lambdap237 | (~lambdap@static.167.190.119.168.clients.your-server.de) (Quit: lambdap237) |
| 2022-11-18 18:03:01 +0100 | lambdap237 | (~lambdap@static.167.190.119.168.clients.your-server.de) |
| 2022-11-18 18:06:03 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:65cf:cc10:c4dc:168) (Quit: WeeChat 2.8) |
| 2022-11-18 18:06:33 +0100 | Techcable | (~Techcable@user/Techcable) |
| 2022-11-18 18:09:29 +0100 | <probie> | I think you can emulate it with pattern synonyms |
| 2022-11-18 18:12:33 +0100 | nschoe | (~q@2a01:e0a:8e:a190:c3cc:9b76:de4b:1492) (Quit: Switching off) |
| 2022-11-18 18:19:43 +0100 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2022-11-18 18:20:41 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-18 18:21:24 +0100 | <Xeroine> | Here http://felsin9.de/nnis/ghc-vis/#introduction this "at" function to access the nth element of that infinite list but I don't understand why that function is used instead of !! and if there's any difference and why is there a 0 in the function declaration? |
| 2022-11-18 18:21:37 +0100 | <Xeroine> | function is used to access* |
| 2022-11-18 18:21:56 +0100 | jinsun | (~jinsun@user/jinsun) |
| 2022-11-18 18:24:52 +0100 | blueonyx | (~blueonyx@user/blueonyx) (Ping timeout: 268 seconds) |
| 2022-11-18 18:27:56 +0100 | <mauke> | Xeroine: the function is equivalent to !! (but with arguments swapped) |
| 2022-11-18 18:28:15 +0100 | <mauke> | it's probably defined like this to make it explicit what's going on |
| 2022-11-18 18:29:21 +0100 | <mauke> | the 0 is for pattern matching: to check whether the first argument is 0 |
| 2022-11-18 18:30:10 +0100 | <Xeroine> | oh right |
| 2022-11-18 18:30:20 +0100 | <Xeroine> | that was pretty obvious =D sry |
| 2022-11-18 18:32:06 +0100 | Guest|74 | (~Guest|74@65-23-213-182.prtc.net) |
| 2022-11-18 18:32:40 +0100 | Guest|74 | (~Guest|74@65-23-213-182.prtc.net) (Client Quit) |
| 2022-11-18 18:36:25 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 2022-11-18 18:39:03 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-11-18 18:39:23 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) |
| 2022-11-18 18:40:32 +0100 | <tomsmeding> | dminuoso: cool, so just one parser implementation now? :) |
| 2022-11-18 18:41:38 +0100 | goepsilongo | (~goepsilon@2603-7000-ab00-00e5-392a-bca4-733f-bcd4.res6.spectrum.com) |
| 2022-11-18 18:44:32 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-11-18 18:46:04 +0100 | shapr | (~user@68.54.166.125) (Remote host closed the connection) |
| 2022-11-18 18:46:23 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 18:50:11 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-18 18:50:57 +0100 | razetime | (~quassel@117.193.0.17) (Remote host closed the connection) |
| 2022-11-18 18:53:08 +0100 | money | Guest417 |
| 2022-11-18 18:58:29 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-18 19:04:22 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 19:09:24 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 248 seconds) |
| 2022-11-18 19:09:53 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 19:18:08 +0100 | DDR | (~DDR@2604:3d08:4c7f:8250:1acb:505b:bbc9:304c) |
| 2022-11-18 19:21:31 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 19:21:50 +0100 | DDR | (~DDR@2604:3d08:4c7f:8250:1acb:505b:bbc9:304c) (Remote host closed the connection) |
| 2022-11-18 19:23:08 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2022-11-18 19:23:10 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds) |
| 2022-11-18 19:27:25 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-18 19:27:42 +0100 | chomwitt | (~chomwitt@athedsl-351939.home.otenet.gr) (Read error: Connection reset by peer) |
| 2022-11-18 19:28:35 +0100 | Feuermagier_ | (~Feuermagi@2a02:2488:4211:3400:6419:933b:46e0:8942) |
| 2022-11-18 19:30:59 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) (Ping timeout: 260 seconds) |
| 2022-11-18 19:31:59 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) |
| 2022-11-18 19:37:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Quit: ZNC - https://znc.in) |
| 2022-11-18 19:37:38 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) (Ping timeout: 256 seconds) |
| 2022-11-18 19:38:23 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-18 19:38:52 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-18 19:40:34 +0100 | roconnor | (~quassel@coq/roconnor) |
| 2022-11-18 19:41:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 19:44:31 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-11-18 19:45:50 +0100 | Feuermagier_ | (~Feuermagi@2a02:2488:4211:3400:6419:933b:46e0:8942) (Ping timeout: 240 seconds) |
| 2022-11-18 19:46:56 +0100 | <roconnor> | Is there a way to create a Nix derivation to build a project using "cabal build" instead of "Setup build"? In particular I want to use "cabal haddock" because "Setup haddock" is broken for Backpack. |
| 2022-11-18 19:47:41 +0100 | mzan | (~quassel@mail.asterisell.com) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-18 19:49:06 +0100 | mzan | (~quassel@mail.asterisell.com) |
| 2022-11-18 19:49:06 +0100 | <geekosaur> | suspect the derivation would have to use either vendored deps or cabal.freeze or both |
| 2022-11-18 19:49:39 +0100 | systemhalted | (~systemhal@130.51.137.77) |
| 2022-11-18 19:50:39 +0100 | systemhalted | (~systemhal@130.51.137.77) (Remote host closed the connection) |
| 2022-11-18 19:51:42 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-18 19:52:14 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-18 19:52:55 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-18 19:53:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 19:54:01 +0100 | <davean> | haskell.nix has a thing to extract the deps from the cabal file using the solver |
| 2022-11-18 19:54:45 +0100 | stefan-_ | (~cri@42dots.de) (Remote host closed the connection) |
| 2022-11-18 19:55:33 +0100 | stefan-_ | (~cri@42dots.de) |
| 2022-11-18 19:56:17 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-18 19:58:51 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-18 19:59:55 +0100 | shof | (~shof@user/shof) (Ping timeout: 248 seconds) |
| 2022-11-18 20:00:43 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-11-18 20:01:24 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) |
| 2022-11-18 20:02:37 +0100 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-18 20:04:16 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 20:05:27 +0100 | kaskal | (~kaskal@213-147-167-253.nat.highway.webapn.at) |
| 2022-11-18 20:05:31 +0100 | <Athas> | Is there a way to specify a minimum GHC version that will make Cabal emit a user-comprehensible error when the minimum is not met? |
| 2022-11-18 20:05:53 +0100 | AdonisExberger | (~Adonis-Ex@176.54.36.182) |
| 2022-11-18 20:05:55 +0100 | AdonisExberger | (~Adonis-Ex@176.54.36.182) (Excess Flood) |
| 2022-11-18 20:06:17 +0100 | AdonisExberger | (~Adonis-Ex@176.54.36.182) |
| 2022-11-18 20:06:29 +0100 | <davean> | Athas: I mean, effectively the base dependency does that. There is also a field for listing the GHC versions that should work. |
| 2022-11-18 20:06:29 +0100 | bjobjo | (~bjobjo@user/bjobjo) |
| 2022-11-18 20:07:18 +0100 | <davean> | (the "compiler" field) |
| 2022-11-18 20:07:29 +0100 | <geekosaur> | base dep doesn't tell you "your ghc is too old" though |
| 2022-11-18 20:07:47 +0100 | <davean> | geekosaur: No, it EFFECTIVELY tells you that, it depends on what you consider comprehensible |
| 2022-11-18 20:08:02 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-18 20:08:02 +0100 | <davean> | it tells anyone with a passing familiarity with haskell that, but it doesn't say it outright |
| 2022-11-18 20:08:14 +0100 | <Athas> | davean: it's for people who are not Haskell programmers. |
| 2022-11-18 20:08:14 +0100 | <davean> | the tested-with field is often used and makes it pretty clear but doesn't emit a message. |
| 2022-11-18 20:08:28 +0100 | <Athas> | Even I have to look up a GHC:base mapping table every time to figure out what the actual requirement is. |
| 2022-11-18 20:08:51 +0100 | <davean> | so I don't think there is anything that strictly does what you want. |
| 2022-11-18 20:08:55 +0100 | <Athas> | I get error reports like this one: https://github.com/diku-dk/futhark/issues/1763 |
| 2022-11-18 20:09:05 +0100 | <Athas> | Alright, I think I will create an issue on the Cabal issue tracker about this. |
| 2022-11-18 20:09:23 +0100 | <Athas> | While not terribly principled, I think this should be solved simply by special-casing the error message for 'base' version bounds. |
| 2022-11-18 20:10:07 +0100 | <davean> | Athas: you can do a conditional on the compiler versions |
| 2022-11-18 20:10:48 +0100 | <davean> | So you could hack it in the meantime by depending on an unsatisfiable "ghc-version-too-old" package |
| 2022-11-18 20:10:53 +0100 | <davean> | (when the impl is too old) |
| 2022-11-18 20:11:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 20:11:16 +0100 | <davean> | It would be a hack |
| 2022-11-18 20:11:21 +0100 | Guest417 | money |
| 2022-11-18 20:13:00 +0100 | <roconnor> | I admit I'm totally lost when it comes to cabal, but cabal build seems to work for me right now without a cabal update. |
| 2022-11-18 20:14:41 +0100 | <davean> | Athas: if impl(ghc < 9.0): build-depends: new-enough-ghc == 0 |
| 2022-11-18 20:14:47 +0100 | <davean> | Athas: I don't know how you feel about hacks :-p |
| 2022-11-18 20:14:56 +0100 | <davean> | roconnor: what are you lost about? |
| 2022-11-18 20:15:10 +0100 | <monochrom> | ghcup list has a ghc<->base mapping |
| 2022-11-18 20:15:13 +0100 | <davean> | cabal update just gets you new information about what packages are available. |
| 2022-11-18 20:15:26 +0100 | <tomsmeding> | monochrom++ |
| 2022-11-18 20:15:33 +0100 | <roconnor> | mostly about how much cabal depends on hackage when building sthings. |
| 2022-11-18 20:15:57 +0100 | <tomsmeding> | that saves a lot of looking up that same page on the ghc wiki again and again |
| 2022-11-18 20:16:32 +0100 | <davean> | roconnor: it depends on hackage to download the packages, it depends on hackage to get a list of what is available when you run update. |
| 2022-11-18 20:16:37 +0100 | <davean> | roconnor: total list, we're done. |
| 2022-11-18 20:17:02 +0100 | <davean> | (you can also request it interact with hackage with cabal upload, but it doesn't "depend" in that case IMO and thats not building) |
| 2022-11-18 20:17:16 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-18 20:17:43 +0100 | <roconnor> | "we're done"? |
| 2022-11-18 20:19:59 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-18 20:20:33 +0100 | lisq | (~quassel@lis.moe) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-18 20:20:34 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-18 20:20:43 +0100 | <davean> | roconnor: There is nothing else to list |
| 2022-11-18 20:21:23 +0100 | <davean> | We've completely explored the dependencies cabal has on hackage for building packages |
| 2022-11-18 20:21:53 +0100 | lisq | (~quassel@lis.moe) |
| 2022-11-18 20:22:18 +0100 | <davean> | I guess I can add to the first, it only downloads if it hasn't downloaded it already or the cache has been cleared since it downloaded it |
| 2022-11-18 20:22:30 +0100 | <roconnor> | ls |
| 2022-11-18 20:22:32 +0100 | dequbed | (~dequbed@banana-new.kilobyte22.de) |
| 2022-11-18 20:22:39 +0100 | <roconnor> | sorry. |
| 2022-11-18 20:22:46 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-18 20:23:12 +0100 | <davean> | roconnor: basicly in principle cabal doesn't depend on hackage at all. Its just that hackage is where it usually gets package data from. |
| 2022-11-18 20:24:03 +0100 | <davean> | You can infact point it at a local directory instead for example. |
| 2022-11-18 20:24:06 +0100 | <geekosaur> | hypothetically any package system could set up its own hackage-server, point cabal at it, and thereby integrate cabal directly into its build system |
| 2022-11-18 20:24:34 +0100 | <davean> | geekosaur: huh what? No? cabal very explicitely is about Haskell |
| 2022-11-18 20:24:44 +0100 | <geekosaur> | that's not what I meant |
| 2022-11-18 20:25:10 +0100 | <geekosaur> | I meant it could use a private "hackage" with only the (Haskell) packages for that distro |
| 2022-11-18 20:25:10 +0100 | <monochrom> | pretty sure geekosaur means Haskell too. |
| 2022-11-18 20:25:22 +0100 | <geekosaur> | in the versions that distro packages |
| 2022-11-18 20:25:46 +0100 | systemhalted | (~systemhal@130.51.137.77) |
| 2022-11-18 20:26:00 +0100 | <monochrom> | My meta-level comment is that there seems to be a lot of "I need to educate all you people" today. |
| 2022-11-18 20:26:08 +0100 | <geekosaur> | it's just easier for them to go the Setup route instead of building a private hackage server |
| 2022-11-18 20:26:14 +0100 | <davean> | setting up alternative package ecosystems for haskell is perfectly standard. You don't need to use hackage at all. |
| 2022-11-18 20:26:50 +0100 | <davean> | I think the most common is a network share |
| 2022-11-18 20:27:16 +0100 | <geekosaur> | lots of companies use their own hackages of approved packages+versions |
| 2022-11-18 20:27:17 +0100 | <roconnor> | It seems like cabal build with locally installed packages (ghc-pkg list) if they are available. |
| 2022-11-18 20:27:27 +0100 | <geekosaur> | whether as a server or as a directory |
| 2022-11-18 20:27:29 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 20:27:32 +0100 | <roconnor> | no hackage needed. |
| 2022-11-18 20:30:40 +0100 | systemhalted | (~systemhal@130.51.137.77) (Ping timeout: 268 seconds) |
| 2022-11-18 20:31:01 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-18 20:32:34 +0100 | <davean> | roconnor: right so cabal never needs hackage if you have already downloaded the package tarballs. What is already installed somewhere isn't really a "thing" to cabal past the base set of packages that come with the compiler (and not all of them) |
| 2022-11-18 20:37:35 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-18 20:38:51 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-18 20:43:22 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-11-18 20:43:57 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 20:45:12 +0100 | libertyprime | (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) |
| 2022-11-18 20:48:42 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-18 20:50:09 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-11-18 20:51:06 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-11-18 20:51:10 +0100 | <EvanR> | speaking of which, is the arch linux situation resolved yet, or was there ever one or |
| 2022-11-18 20:52:31 +0100 | <davean> | No, its not resolved. They want the thing they want and what they want doesn't make much sense. |
| 2022-11-18 20:56:51 +0100 | <roconnor> | I think to register a package I need to run cabal install, but cabal install seems to want to rebuild my package (and it's failing due to some issue with my C dependencies that isn't a problem with cabal build). |
| 2022-11-18 20:58:25 +0100 | <davean> | you don't really install packages |
| 2022-11-18 20:58:43 +0100 | <roconnor> | how do I register cabal built packages with ghc? |
| 2022-11-18 20:58:59 +0100 | <davean> | you can but you almost definately don't want to |
| 2022-11-18 20:59:08 +0100 | <sclv> | `setup.hs install` |
| 2022-11-18 20:59:19 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-18 20:59:28 +0100 | <sclv> | if you're using the setup path |
| 2022-11-18 20:59:56 +0100 | <roconnor> | sclv: I'm trying to use cabal instead of setup becuase Setup.hs haddock is broken with backpack projects. |
| 2022-11-18 21:00:13 +0100 | <sclv> | does v1-build work? |
| 2022-11-18 21:00:22 +0100 | <davean> | That won't affect cabal build for other project for example though, about the only thing it will affect is bare "ghci" |
| 2022-11-18 21:00:50 +0100 | <roconnor> | right, bare ghci. |
| 2022-11-18 21:00:56 +0100 | <sclv> | if its just v2-build then registering v2-build built packages in the standard package db will be rough, and i'm not sure even possible :-/ |
| 2022-11-18 21:01:43 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-18 21:01:50 +0100 | <sclv> | v2-install just puts the package in the store and then modifies the global package environment file, it doesn't register it in the ghc pkgdb |
| 2022-11-18 21:01:55 +0100 | <roconnor> | sclv: I have cabal 3.8.1.0 I don't know if build is doing a v1-build or a v2-build. v1-build maybe? |
| 2022-11-18 21:02:01 +0100 | <davean> | v2 |
| 2022-11-18 21:02:02 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-11-18 21:02:03 +0100 | <sclv> | that's going to be v2-build by default |
| 2022-11-18 21:02:06 +0100 | <davean> | v1 is basicly gone |
| 2022-11-18 21:02:14 +0100 | <sclv> | you can explicitly say v1-build and v1-install and it will do it the v1 way |
| 2022-11-18 21:02:29 +0100 | <roconnor> | I see. it was using dist instead of new-dist so I thought it would be v1. |
| 2022-11-18 21:04:00 +0100 | <roconnor> | sclv: really, v2 doesn't support package registration? |
| 2022-11-18 21:04:21 +0100 | <davean> | roconnor: its against the design but I think it does? I think you need like --lib and ... |
| 2022-11-18 21:04:24 +0100 | <davean> | soemthing else |
| 2022-11-18 21:04:26 +0100 | <sclv> | no. it only registers packages in the "store" which is not a normal package database |
| 2022-11-18 21:04:28 +0100 | <davean> | but it is very much against the design |
| 2022-11-18 21:04:52 +0100 | <davean> | --package-env ? |
| 2022-11-18 21:05:03 +0100 | <sclv> | you can try to use ghc-pkg by hand to register the artifacts it has thus built into another package database but... errr.. good luck |
| 2022-11-18 21:05:37 +0100 | <roconnor> | I mean, all my dependencies are registered. It feels weird that cabal v2 doesn't support registring newly build stuff. |
| 2022-11-18 21:05:56 +0100 | <davean> | roconnor: it is supposed to create consistent enviroments |
| 2022-11-18 21:06:00 +0100 | <tomsmeding> | roconnor: wait, it was using 'dist'? v2 commands should definitely use dist-newstyle by default |
| 2022-11-18 21:06:01 +0100 | <davean> | you can create consistent enviroments with ti |
| 2022-11-18 21:06:41 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-11-18 21:07:05 +0100 | <roconnor> | tomsmeding: Oh it seems I was misreading it. |
| 2022-11-18 21:07:21 +0100 | <tomsmeding> | roconnor: why do you want to register a package? Is the purpose it being available in plain ghci? Or is the purpose it being available in other packages? Or something else? |
| 2022-11-18 21:07:21 +0100 | <davean> | roconnor: Why not create a package-env that is how you want it to be? |
| 2022-11-18 21:08:06 +0100 | <tomsmeding> | (And what do you want to happen when you "register" two different versions of the same package?) |
| 2022-11-18 21:08:31 +0100 | <roconnor> | tomsmeding: What I'd like to do is build a nix expression that builds with cabal instead of setup because setup haddock is broken for backpack builds (and I'm not optimisitic it will be fixed). |
| 2022-11-18 21:08:50 +0100 | <davean> | roconnor: ok, but what your proposing is like the opposite of that |
| 2022-11-18 21:08:58 +0100 | <tomsmeding> | roconnor: is this for an executable or a haskell library? |
| 2022-11-18 21:09:01 +0100 | <davean> | I pointed you at haskell.nxi above |
| 2022-11-18 21:09:09 +0100 | <roconnor> | tomsmeding: both. |
| 2022-11-18 21:09:14 +0100 | <davean> | *haskellnix |
| 2022-11-18 21:09:21 +0100 | <davean> | *haskell.nix god damn my typing |
| 2022-11-18 21:09:54 +0100 | <tomsmeding> | hm, ok, you'll need a nix expert, not me; hopefully my questions and your answers were useful for the other people in the conversation :) |
| 2022-11-18 21:10:05 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-18 21:10:17 +0100 | <roconnor> | davean: Okay I'll take a closer look. I thought because cabal build was so easy to use from the command line, I could whip up a simple nix expression. |
| 2022-11-18 21:10:39 +0100 | <davean> | roconnor: you'd have to extract the solver generally speaking, and you can do that. But what you want is NOT registration |
| 2022-11-18 21:12:08 +0100 | <sclv> | i think that building it with cabal v1-build is likely fine. the only problem is if you need to pass in special hardcoded paths relative to the store, because cabal currently doesn't let you do that (i have a patch in the works but it hasn't landed yet) |
| 2022-11-18 21:12:36 +0100 | <davean> | sclv: well there is also the purity thing with nix expressions |
| 2022-11-18 21:12:51 +0100 | <c_wraith> | sclv: did you see that my doc patch for internal libraries was accepted with minimal fuss? |
| 2022-11-18 21:12:51 +0100 | <roconnor> | cabal v1-haddock is just as broken as setup haddock, which probably isn't too surprising. |
| 2022-11-18 21:12:53 +0100 | <sclv> | if you assume all your deps are already available, which nix should handle for you, you're ok |
| 2022-11-18 21:13:00 +0100 | <sclv> | c_wraith: great :-) |
| 2022-11-18 21:13:08 +0100 | <davean> | sclv: I mean getting the registration out of the nix expression |
| 2022-11-18 21:13:17 +0100 | <roconnor> | davean: I was looking at the default install phase of Nix @ https://github.com/NixOS/nixpkgs/blob/ba90bab628277d977d3a381e91d4ce0af4ea4f91/pkgs/development/ha… |
| 2022-11-18 21:13:28 +0100 | <c_wraith> | Now (well, after the next update) the docs will actually explain what I was doing wrong! |
| 2022-11-18 21:13:30 +0100 | <roconnor> | it runs Setup register --gen-pkg-config |
| 2022-11-18 21:13:35 +0100 | <sclv> | davean: i don't understand what you mean -- the artifact will be in a consistent place in dist-newstyle |
| 2022-11-18 21:13:59 +0100 | <davean> | roconnor: Note that that VERY SPECIFICLY isn't doing a straight install |
| 2022-11-18 21:14:17 +0100 | <davean> | sclv: I mean that having the registration become relivent outside the nix expression takes setup |
| 2022-11-18 21:14:28 +0100 | <sclv> | i think setup.hs register is very much a thin wrapper around ghc-pkg and the latter could suffice |
| 2022-11-18 21:14:43 +0100 | <davean> | sclv: except nix expression builds are isolated from the system |
| 2022-11-18 21:14:49 +0100 | <davean> | sclv: so nothing will see what it does |
| 2022-11-18 21:14:54 +0100 | <roconnor> | Though I guess Setup register --gen-pkg-config=... is maybe kinda not a registration. |
| 2022-11-18 21:15:10 +0100 | <roconnor> | sclv: that would make sense. |
| 2022-11-18 21:15:10 +0100 | <davean> | roconnor: local packageConfFile="$packageConfDir/${pname}-${version}.conf" |
| 2022-11-18 21:15:20 +0100 | <davean> | Its making specific stuff for that exact package-version |
| 2022-11-18 21:15:27 +0100 | <davean> | other stuff gets that file searched |
| 2022-11-18 21:15:32 +0100 | <davean> | its NOT doing a global install |
| 2022-11-18 21:15:36 +0100 | <davean> | its making a very specific install |
| 2022-11-18 21:16:13 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-18 21:16:51 +0100 | <davean> | if it worked on the *global* database, from the perspective of the nix derivation, there would be *no way to combine nix derivations to get a set of registrations* |
| 2022-11-18 21:17:51 +0100 | <davean> | from the man page of cabal: |
| 2022-11-18 21:17:54 +0100 | <davean> | --gen-pkg-config [PKG] |
| 2022-11-18 21:17:55 +0100 | <davean> | instead of registering, generate a package registration file/directoryyy |
| 2022-11-18 21:18:26 +0100 | <davean> | We're effectively getting a file SOMETHING ELSE can refer to to make an envirment that includes it |
| 2022-11-18 21:18:43 +0100 | <sclv> | ah gotcha! |
| 2022-11-18 21:18:46 +0100 | <davean> | which is very specificly why I was saying I thought you didn't want what you were asking for at the top |
| 2022-11-18 21:18:51 +0100 | <sclv> | idk if there's a v2 version of that |
| 2022-11-18 21:19:15 +0100 | <roconnor> | there didn't seem to be any v2 versions of copy and register. |
| 2022-11-18 21:19:50 +0100 | <davean> | Don't quote me on this, but I think register might just work with v2-built libraries |
| 2022-11-18 21:20:10 +0100 | <davean> | The registration stuff is the same |
| 2022-11-18 21:21:05 +0100 | <davean> | sclv: Sorry I wasn't explaining it great |
| 2022-11-18 21:22:16 +0100 | systemhalted | (~systemhal@130.51.137.77) |
| 2022-11-18 21:25:36 +0100 | <roconnor> | wow, using cabal v1-register does seem to be promising. Using a depricated feature is a bit unnerving, but perhaps it is good enough for now. |
| 2022-11-18 21:26:11 +0100 | <roconnor> | OTOH maybe I should be looking at haskell.nix |
| 2022-11-18 21:26:13 +0100 | <sclv> | if it actually works, we arguably should just keep it around since we don't have a replacement, and its not clear if having one makes sense |
| 2022-11-18 21:26:21 +0100 | systemhalted | (~systemhal@130.51.137.77) (Read error: Connection reset by peer) |
| 2022-11-18 21:26:31 +0100 | <dminuoso> | tomsmeding: well no, stateful still needs to be duplicated sadlz. |
| 2022-11-18 21:26:46 +0100 | <dminuoso> | tomsmeding: but at least for both basic and stateful, we can have a single implementation indeed. |
| 2022-11-18 21:27:40 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-18 21:28:13 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-18 21:28:21 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-18 21:29:29 +0100 | <davean> | roconnor: right, it SHOULD work, you know, in principal. |
| 2022-11-18 21:29:38 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-18 21:31:20 +0100 | <davean> | roconnor: you should look at haskell.nix, mostly it has the production grade version of what we've talked about. OTOH, now you know how this ACTUALLY works, so you can fix things properly. |
| 2022-11-18 21:31:35 +0100 | <davean> | roconnor: and you are on a valuable but less trod pathway |
| 2022-11-18 21:31:39 +0100 | <davean> | so I'm glad you're using it! |
| 2022-11-18 21:31:43 +0100 | <roconnor> | does haskell.nix use cabal build? |
| 2022-11-18 21:32:22 +0100 | <tomsmeding> | dminuoso: oh right, you need stateful still because an STRef state wouldn't backtrack? |
| 2022-11-18 21:32:57 +0100 | <roconnor> | https://github.com/input-output-hk/haskell.nix/blob/d82e4c0e249e99259c083863e26a35509283f250/build… doesn't look promising. |
| 2022-11-18 21:33:04 +0100 | <dminuoso> | tomsmeding: For one that, and also an unboxed state is likely going to be faster than an STRef |
| 2022-11-18 21:33:19 +0100 | <tomsmeding> | right |
| 2022-11-18 21:33:27 +0100 | <dminuoso> | But I have my doubts |
| 2022-11-18 21:33:27 +0100 | <roconnor> | I think haskell.nix still uses Setup.hs |
| 2022-11-18 21:33:42 +0100 | <dminuoso> | Like you have pointed out, a single Int# worth of state is not enough for parsing whitespace sensitive things. |
| 2022-11-18 21:33:55 +0100 | <dminuoso> | At least not for reasonable inputs in programming languages |
| 2022-11-18 21:34:39 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 260 seconds) |
| 2022-11-18 21:34:45 +0100 | <dminuoso> | So I dont know how useful it truly is, to me it smells like a lot of baggage dragging along for no real world use |
| 2022-11-18 21:34:56 +0100 | <roconnor> | All right, I think I'll attempt to make a custom nix derivation using cabal build and cabal v1-register with lots of flags and see how far I can make it. |
| 2022-11-18 21:35:09 +0100 | <dminuoso> | If you are *that* desperate for cpu cycles you're probably better off writing some cbits |
| 2022-11-18 21:35:22 +0100 | <tomsmeding> | dminuoso: yeah I think so |
| 2022-11-18 21:35:24 +0100 | <davean> | roconnor: No ,but it sets up stuff correctly - like generating the dependencies with cabal |
| 2022-11-18 21:35:41 +0100 | <davean> | roconnor: so its just the build stuff that is a problem in it |
| 2022-11-18 21:36:02 +0100 | <dminuoso> | tomsmeding: Either way, if we have `State# s` threading through the pure parser, I dont have to care about it. :P |
| 2022-11-18 21:36:06 +0100 | <davean> | roconnor: you'd just have to override buildPhase I think |
| 2022-11-18 21:36:18 +0100 | <dminuoso> | (but like you pointed out, backtracking is still a problem) |
| 2022-11-18 21:36:18 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-11-18 21:36:39 +0100 | <dminuoso> | But that we could possibly work around |
| 2022-11-18 21:36:40 +0100 | <tomsmeding> | dminuoso: yeah a backtracking state is essential for parser state :p |
| 2022-11-18 21:36:47 +0100 | <tomsmeding> | like whitespace parsing |
| 2022-11-18 21:36:57 +0100 | <dminuoso> | well, if you cut early before state changes occur its not a big deal |
| 2022-11-18 21:37:15 +0100 | <dminuoso> | s/cut/backtrack/ |
| 2022-11-18 21:37:17 +0100 | <tomsmeding> | maybe, but I wouldn't like to have to watch for that |
| 2022-11-18 21:37:30 +0100 | <dminuoso> | maybe there is a way to do something akin to `bracket` but for backtracking |
| 2022-11-18 21:38:06 +0100 | <dminuoso> | The only alternative is to thread boxed state through, but duplicating every parser a third time.. I think backpack might be more interesting at that point. |
| 2022-11-18 21:38:29 +0100 | <tomsmeding> | dminuoso: the hack in the ghc grammar to properly parse layout springs to mind, where I believe there's some long distance backtracking going on (but I may be misremembering) |
| 2022-11-18 21:38:36 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-18 21:39:13 +0100 | <dminuoso> | tomsmeding: I mean realistically you will want to cut early *anyway* |
| 2022-11-18 21:39:19 +0100 | <dminuoso> | because it makes for much better diagnostics |
| 2022-11-18 21:39:20 +0100 | <tomsmeding> | dminuoso: probably naive suggestion, but it isn't possible to make the additional field a, you know, type parameter? |
| 2022-11-18 21:39:28 +0100 | <tomsmeding> | and {-# SPECIALIZE #-} the hell out of it |
| 2022-11-18 21:39:42 +0100 | <tomsmeding> | sure |
| 2022-11-18 21:40:21 +0100 | <tomsmeding> | but if I'm sure to cut that early always, I can really just rewrite my parser to not backtrack at all |
| 2022-11-18 21:40:41 +0100 | <dminuoso> | well no there is good reasons not to do that |
| 2022-11-18 21:40:42 +0100 | <tomsmeding> | because all the backtracking will be extremely local |
| 2022-11-18 21:40:43 +0100 | <dminuoso> | consider: |
| 2022-11-18 21:40:53 +0100 | <dminuoso> | say you want to branch behavior based on a keyword |
| 2022-11-18 21:41:25 +0100 | <tomsmeding> | or perhaps better formulated, not backtrack _in the parser framework_ at all |
| 2022-11-18 21:41:55 +0100 | <dminuoso> | https://gist.github.com/dminuoso/a73383874e06061c3526049997472f79 |
| 2022-11-18 21:42:02 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-18 21:42:32 +0100 | <dminuoso> | So you can simply `many topStanza` |
| 2022-11-18 21:42:53 +0100 | <dminuoso> | Of course you can rewrite topStanza as a recursive loop, but you will lose tons of expressivity |
| 2022-11-18 21:42:59 +0100 | <dminuoso> | And yet this cuts early after just one token |
| 2022-11-18 21:43:21 +0100 | <tomsmeding> | it will cut after just one token, but before or after the state update? |
| 2022-11-18 21:43:24 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-18 21:43:30 +0100 | <tomsmeding> | indentation updates can happen after every token |
| 2022-11-18 21:43:35 +0100 | <dminuoso> | Well in this case there is no state update, because its really just the switch |
| 2022-11-18 21:43:39 +0100 | <dminuoso> | Mmm |
| 2022-11-18 21:43:43 +0100 | <tomsmeding> | if I parse 'let', I now need to update my state because I'm starting a new layout block |
| 2022-11-18 21:43:44 +0100 | <dminuoso> | I see what you're getting at |
| 2022-11-18 21:43:49 +0100 | <tomsmeding> | okay 'let' is a bad example |
| 2022-11-18 21:43:53 +0100 | <tomsmeding> | the first token after the 'let', rather |
| 2022-11-18 21:44:11 +0100 | <dminuoso> | Know what really sucks? |
| 2022-11-18 21:44:19 +0100 | <tomsmeding> | you can architect this to work, but I don't want to need to |
| 2022-11-18 21:44:24 +0100 | <dminuoso> | That you cant just do boxed/unboxed-polymorphic code. |
| 2022-11-18 21:44:33 +0100 | <dminuoso> | If we could, this would be entirely trivial |
| 2022-11-18 21:44:35 +0100 | <tomsmeding> | if I need to think about this, I'd rather just not just parser backtracking at all :p |
| 2022-11-18 21:44:40 +0100 | <dminuoso> | since you could just set s ~ (##) for non-stateful and be done. |
| 2022-11-18 21:44:40 +0100 | <tomsmeding> | more transparent |
| 2022-11-18 21:44:51 +0100 | <dminuoso> | or s ~ Int#, or s ~ YourThing |
| 2022-11-18 21:44:52 +0100 | <tomsmeding> | hmm |
| 2022-11-18 21:45:10 +0100 | <tomsmeding> | isn't the thing that you can't make an unboxed field polymorphic? |
| 2022-11-18 21:45:33 +0100 | <dminuoso> | no you can make it polymorphic, but you can no longer provide binding sites in things like pattern matches |
| 2022-11-18 21:45:35 +0100 | <tomsmeding> | because different unboxed types have different representations in the heap block |
| 2022-11-18 21:45:42 +0100 | <dminuoso> | right |
| 2022-11-18 21:45:45 +0100 | <dminuoso> | roughly that |
| 2022-11-18 21:45:45 +0100 | <tomsmeding> | how does that even work? :') |
| 2022-11-18 21:45:50 +0100 | euandreh2 | (~Thunderbi@189.40.77.30) |
| 2022-11-18 21:46:07 +0100 | <tomsmeding> | how can a data type have a polymorphic unboxed field where the size of that field is potentially even runtime-dependent |
| 2022-11-18 21:46:28 +0100 | <dminuoso> | Ah no you cant have that |
| 2022-11-18 21:46:39 +0100 | <dminuoso> | I phrased it poorly, you can have it as a type (say phantom) |
| 2022-11-18 21:46:55 +0100 | <tomsmeding> | oh right you can have a phantom type variable of unboxed type, sure |
| 2022-11-18 21:47:03 +0100 | <dminuoso> | Proxy (TYPE r) |
| 2022-11-18 21:47:10 +0100 | <tomsmeding> | but for phantom type variables levity polymorphism is a thing I thought |
| 2022-11-18 21:47:17 +0100 | <tomsmeding> | but proxies don't get us anything here :p |
| 2022-11-18 21:47:17 +0100 | <dminuoso> | Yup |
| 2022-11-18 21:47:24 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds) |
| 2022-11-18 21:47:25 +0100 | euandreh2 | euandreh |
| 2022-11-18 21:47:27 +0100 | <dminuoso> | To be fair |
| 2022-11-18 21:47:31 +0100 | <dminuoso> | 21:45:35 tomsmeding | because different unboxed types have different representations in the heap block |
| 2022-11-18 21:47:38 +0100 | <dminuoso> | I dont think this is a fundamental problem |
| 2022-11-18 21:47:46 +0100 | <dminuoso> | Its merely that GHC wants to know it fairly early |
| 2022-11-18 21:47:58 +0100 | <tomsmeding> | one could write a runtime system that can handle that |
| 2022-11-18 21:48:02 +0100 | <dminuoso> | In principle GHC could just figure out the layout once you instantiate it at a given type |
| 2022-11-18 21:48:21 +0100 | <tomsmeding> | or, hm |
| 2022-11-18 21:48:35 +0100 | <dminuoso> | Im not saying it can be easily done, but its definitely not a fundamental problem |
| 2022-11-18 21:48:48 +0100 | <tomsmeding> | actually indeed, if the unboxed polymorphic type parameters are all monomorphic, you should be able to do all the usual things to a heap object |
| 2022-11-18 21:49:09 +0100 | <tomsmeding> | one just has to reject higher-rank types with explicitly polymorphic unboxed type variables |
| 2022-11-18 21:49:12 +0100 | <dminuoso> | tomsmeding: the real problem is still polymorphic code. |
| 2022-11-18 21:49:16 +0100 | <dminuoso> | not just higher rank |
| 2022-11-18 21:49:19 +0100 | <dminuoso> | even rank 1 |
| 2022-11-18 21:49:29 +0100 | <tomsmeding> | inline all the things |
| 2022-11-18 21:49:32 +0100 | <tomsmeding> | not fundamental |
| 2022-11-18 21:49:33 +0100 | <dminuoso> | Consider something as mundane as: |
| 2022-11-18 21:49:45 +0100 | <tomsmeding> | super inconvenient and probably non-optimal, sure |
| 2022-11-18 21:49:56 +0100 | <tomsmeding> | but at least you can SPECIALIZE your way out of that |
| 2022-11-18 21:50:07 +0100 | <dminuoso> | `foo :: Maybe (a :: TYPE r) -> ...` |
| 2022-11-18 21:50:16 +0100 | <dminuoso> | and export that in a module |
| 2022-11-18 21:50:20 +0100 | <dminuoso> | GHC must provide code that works for that. |
| 2022-11-18 21:50:37 +0100 | <tomsmeding> | ghc could just not, right? Only provide an inlineable Core snippet |
| 2022-11-18 21:50:56 +0100 | <tomsmeding> | but not sure whether this is a useful discussion to have, since ghc doesn't |
| 2022-11-18 21:51:24 +0100 | <dminuoso> | I think backpack would be a solution to all of this |
| 2022-11-18 21:51:39 +0100 | tomsmeding | gets nervous |
| 2022-11-18 21:51:41 +0100 | <dminuoso> | tomsmeding: or something more tight as SPECIALIZE |
| 2022-11-18 21:52:05 +0100 | <dminuoso> | Something like SPECIALIZE_EXACTLY, where code is instantiated for each pragma, and only exactly that. |
| 2022-11-18 21:52:17 +0100 | <tomsmeding> | and no polymorphic code generated? |
| 2022-11-18 21:52:19 +0100 | <dminuoso> | And if you try and run it with something else, get a bottom thrown in your face |
| 2022-11-18 21:52:22 +0100 | <dminuoso> | Right |
| 2022-11-18 21:52:27 +0100 | <tomsmeding> | right |
| 2022-11-18 21:52:29 +0100 | <dminuoso> | (Or well I guess GHC could catch that) |
| 2022-11-18 21:52:44 +0100 | <tomsmeding> | that's what I was trying to suggest above |
| 2022-11-18 21:52:52 +0100 | <dminuoso> | Mmm |
| 2022-11-18 21:52:54 +0100 | <tomsmeding> | well, not really |
| 2022-11-18 21:52:56 +0100 | <dminuoso> | Couldnt we use a typeclass for this? |
| 2022-11-18 21:53:02 +0100 | EvanR_ | (~EvanR@user/evanr) |
| 2022-11-18 21:53:02 +0100 | <dminuoso> | with an associated type synonym? |
| 2022-11-18 21:53:06 +0100 | <dminuoso> | something along the lines of |
| 2022-11-18 21:54:29 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds) |
| 2022-11-18 21:55:20 +0100 | <dminuoso> | class Thing a where type TYP a :: Type; po :: (a :: TYP a) -> Int -> Int |
| 2022-11-18 21:55:31 +0100 | <dminuoso> | % :set -XTypeFamilies |
| 2022-11-18 21:55:31 +0100 | <yahb2> | <no output> |
| 2022-11-18 21:55:37 +0100 | <dminuoso> | % :set -XPolyKinds |
| 2022-11-18 21:55:37 +0100 | <yahb2> | <no output> |
| 2022-11-18 21:55:40 +0100 | <dminuoso> | % class Thing a where type TYP a :: Type; po :: (a :: TYP a) -> Int -> Int |
| 2022-11-18 21:55:40 +0100 | <yahb2> | <interactive>:150:49: error: ; • Expected a type, but ‘a :: TYP a’ has kind ‘TYP a’ ; • In the type signature: po :: (a :: TYP a) -> Int -> Int ; In the class declaration for ‘Thing’ |
| 2022-11-18 21:55:42 +0100 | <dminuoso> | Mmmm |
| 2022-11-18 21:55:47 +0100 | <dminuoso> | % :set -XTypeInType |
| 2022-11-18 21:55:47 +0100 | <yahb2> | <no output> |
| 2022-11-18 21:55:50 +0100 | <dminuoso> | % class Thing a where type TYP a :: Type; po :: (a :: TYP a) -> Int -> Int |
| 2022-11-18 21:55:50 +0100 | <yahb2> | <interactive>:154:49: error: ; • Expected a type, but ‘a :: TYP a’ has kind ‘TYP a’ ; • In the type signature: po :: (a :: TYP a) -> Int -> Int ; In the class declaration for ‘Thing’ |
| 2022-11-18 21:55:54 +0100 | EvanR | (~EvanR@user/evanr) (Ping timeout: 256 seconds) |
| 2022-11-18 21:55:58 +0100 | <dminuoso> | Oh right, I remember that extension doesnt do anything |
| 2022-11-18 21:56:12 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 21:56:44 +0100 | <dminuoso> | % class Thing a r where type TYP a :: TYPE r; po :: (a :: TYP a) -> Int -> Int |
| 2022-11-18 21:56:45 +0100 | <yahb2> | <interactive>:156:53: error: ; • Expected a type, but ‘a :: TYP a’ has kind ‘TYP a’ ; • In the type signature: po :: (a :: TYP a) -> Int -> Int ; In the class declaration for ‘Thing’ |
| 2022-11-18 21:59:26 +0100 | <tomsmeding> | dminuoso: I think all actual function argument types must have kind either LiftedType or UnliftedType |
| 2022-11-18 21:59:47 +0100 | <tomsmeding> | since this might be anything (depending on the instance), including other kinds that are nonsensical in that position, ghc rejects it? |
| 2022-11-18 22:00:21 +0100 | <tomsmeding> | % class ThingNotRelly a where type TYP a :: Type; po :: (a :: UnliftedType) -> Int -> Int |
| 2022-11-18 22:00:21 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:00:25 +0100 | <tomsmeding> | that works fine, for example |
| 2022-11-18 22:00:42 +0100 | <tomsmeding> | % class ThingNotRelly a where type TYP a :: Type; po :: (a :: (UnliftedType :: Type)) -> Int -> Int |
| 2022-11-18 22:00:42 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:00:45 +0100 | <tomsmeding> | look at that |
| 2022-11-18 22:01:00 +0100 | <tomsmeding> | oh s/Relly/Really/ |
| 2022-11-18 22:01:55 +0100 | <tomsmeding> | % :k (Type :: (Type :: (Type :: (Type :: Type)))) |
| 2022-11-18 22:01:55 +0100 | <yahb2> | (Type :: (Type :: (Type :: (Type :: Type)))) :: Type |
| 2022-11-18 22:02:35 +0100 | <dminuoso> | oh hold on, we dont even need a method. |
| 2022-11-18 22:02:42 +0100 | <dminuoso> | % class Thing a r where type TYP a :: TYPE r |
| 2022-11-18 22:02:42 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:02:59 +0100 | <dminuoso> | % instance Thing Int LiftedRep |
| 2022-11-18 22:03:00 +0100 | <yahb2> | <interactive>:166:1: warning: [-Wmissing-methods] ; • No explicit associated type or default declaration for ‘TYP’ ; • In the instance declaration for ‘Thing Int LiftedRep’ |
| 2022-11-18 22:03:11 +0100 | <dminuoso> | Mmm, maybe even wiuthout the synonym |
| 2022-11-18 22:03:22 +0100 | <dminuoso> | % class Thing a r | a -> r |
| 2022-11-18 22:03:23 +0100 | <yahb2> | <interactive>:168:1: error: ; • Fundeps in class ‘Thing’ ; (Enable FunctionalDependencies to allow fundeps) ; • In the class declaration for ‘Thing’ |
| 2022-11-18 22:03:30 +0100 | <dminuoso> | % :set -XFunctionalDependencies |
| 2022-11-18 22:03:30 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:03:33 +0100 | <dminuoso> | % class Thing a r | a -> r |
| 2022-11-18 22:03:33 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:03:45 +0100 | <dminuoso> | % instance Thing Int (TYPE LiftedRep) |
| 2022-11-18 22:03:45 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:03:56 +0100 | <dminuoso> | % import GHC.Int |
| 2022-11-18 22:03:56 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:04:05 +0100 | <dminuoso> | % :set -XMagicHash |
| 2022-11-18 22:04:05 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:04:06 +0100 | <dminuoso> | % instance Thing Int# (TYPE UnliftedRep) |
| 2022-11-18 22:04:07 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:04:24 +0100 | <dminuoso> | % f :: Thing a b => (a :: b) -> Int; f = undefined |
| 2022-11-18 22:04:24 +0100 | <yahb2> | <interactive>:182:20: error: ; • Expected a type, but ‘a :: b’ has kind ‘b1’ ; ‘b1’ is a rigid type variable bound by ; the type signature for ‘f’ ; at <interactive>:182:1... |
| 2022-11-18 22:04:31 +0100 | <dminuoso> | tomsmeding: Gah I want this. :( |
| 2022-11-18 22:04:49 +0100 | <tomsmeding> | isn't this the precise same issue as with the 'po' method? |
| 2022-11-18 22:04:54 +0100 | <tomsmeding> | the type class is open |
| 2022-11-18 22:05:21 +0100 | <tomsmeding> | someone might write an instance 'instance Thing Double Bool' and what would f do |
| 2022-11-18 22:05:43 +0100 | <dminuoso> | Not mind. |
| 2022-11-18 22:05:51 +0100 | <dminuoso> | But you couldnt instantiate f at those. |
| 2022-11-18 22:05:58 +0100 | <dminuoso> | at least thats my expectancy |
| 2022-11-18 22:06:13 +0100 | <tomsmeding> | what if you're in a polymorphic context ;) |
| 2022-11-18 22:06:27 +0100 | <tomsmeding> | what would the dictionary even contain here |
| 2022-11-18 22:06:30 +0100 | <dminuoso> | uh okay. |
| 2022-11-18 22:06:51 +0100 | <dminuoso> | maybe tyfams can help here? |
| 2022-11-18 22:07:25 +0100 | <tomsmeding> | fundamentally you need >=two different generated assembly versions for f |
| 2022-11-18 22:07:35 +0100 | <tomsmeding> | one for lifted, and one for each unlifted type |
| 2022-11-18 22:07:41 +0100 | <dminuoso> | Yeah I get what you're saying. |
| 2022-11-18 22:07:46 +0100 | <tomsmeding> | some type level thing isn't going to do that |
| 2022-11-18 22:08:00 +0100 | <tomsmeding> | no matter how much we'd want that :p |
| 2022-11-18 22:08:04 +0100 | <dminuoso> | I expect to find something that type checks, and then magically conjures up differnet machine code out of thin air |
| 2022-11-18 22:08:17 +0100 | <dminuoso> | because clearly if it type checks, its gotta do the right thing |
| 2022-11-18 22:08:21 +0100 | <tomsmeding> | who wants a JITted haskell |
| 2022-11-18 22:09:45 +0100 | <tomsmeding> | dminuoso: this though https://github.com/ekmett/unboxed/blob/main/internal/Unboxed/Internal/Class.hs |
| 2022-11-18 22:10:14 +0100 | <dminuoso> | huh |
| 2022-11-18 22:10:23 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 255 seconds) |
| 2022-11-18 22:10:44 +0100 | <tomsmeding> | I was looking through this repo while we were discussing because I was pretty sure this kind of magic was in there |
| 2022-11-18 22:10:56 +0100 | <dminuoso> | I actually do know this heh |
| 2022-11-18 22:11:30 +0100 | <tomsmeding> | oh hey |
| 2022-11-18 22:11:39 +0100 | <dminuoso> | that FunctorRep typeclass looks interesting |
| 2022-11-18 22:11:46 +0100 | <tomsmeding> | isn't the point here that you cannot do (a :: k) but you can do (a :: TYPE k) |
| 2022-11-18 22:11:50 +0100 | <dminuoso> | Its sort of what I was trying to build |
| 2022-11-18 22:12:03 +0100 | <tomsmeding> | because the types that hold values are precisely those that are of the form TYPE r |
| 2022-11-18 22:12:24 +0100 | <dminuoso> | Ill have to do some thinking how this could be plugged into flatparse |
| 2022-11-18 22:12:27 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-18 22:12:54 +0100 | <dminuoso> | the main problem is, you would have to write *all* parser combinators as part of a singular typeclass |
| 2022-11-18 22:12:58 +0100 | <dminuoso> | because they all go like |
| 2022-11-18 22:13:27 +0100 | <tomsmeding> | all the basic ones, in any case |
| 2022-11-18 22:13:31 +0100 | <dminuoso> | word8 = Parser $ \fp r eob s n -> ... |
| 2022-11-18 22:13:34 +0100 | <tomsmeding> | or also derived ones? |
| 2022-11-18 22:13:59 +0100 | <dminuoso> | Which means every single combinator must live in this typeclass, because of the binding site of `n` |
| 2022-11-18 22:14:08 +0100 | <dminuoso> | even derived ones. |
| 2022-11-18 22:14:12 +0100 | <dminuoso> | so its actually fixewd |
| 2022-11-18 22:14:16 +0100 | <dminuoso> | (well you could subclass I suppose) |
| 2022-11-18 22:14:39 +0100 | <tomsmeding> | % class Thing r (a :: TYPE r) where po :: a -> Int -> Int |
| 2022-11-18 22:14:39 +0100 | <yahb2> | <no output> |
| 2022-11-18 22:14:43 +0100 | <tomsmeding> | just for completeness |
| 2022-11-18 22:14:57 +0100 | <tomsmeding> | note that the type parameters of Thing cannot be swapped! |
| 2022-11-18 22:15:00 +0100 | <dminuoso> | % instance Thing LiftedRep Int |
| 2022-11-18 22:15:01 +0100 | <yahb2> | <interactive>:186:10: warning: [-Wmissing-methods] ; • No explicit implementation for ; ‘po’ ; • In the instance declaration for ‘Thing LiftedRep Int’ |
| 2022-11-18 22:15:03 +0100 | <dminuoso> | % instance Thing LiftedRep Int# |
| 2022-11-18 22:15:03 +0100 | <yahb2> | <interactive>:188:26: error: ; • Expecting a lifted type, but ‘Int#’ is unlifted ; • In the second argument of ‘Thing’, namely ‘Int#’ ; In the instance declaration for ‘Thing LiftedRe... |
| 2022-11-18 22:15:05 +0100 | <dminuoso> | Nice |
| 2022-11-18 22:15:26 +0100 | <tomsmeding> | % instance Thing UnliftedRep Int# |
| 2022-11-18 22:15:26 +0100 | <yahb2> | <interactive>:190:28: error: ; • Couldn't match kind ‘'IntRep’ with ‘'BoxedRep 'Unlifted’ ; Expected kind ‘TYPE UnliftedRep’, ; but ‘Int#’ has kind ‘TYPE 'IntRep’ ; • In the s... |
| 2022-11-18 22:15:34 +0100 | <tomsmeding> | % instance Thing IntRep Int# |
| 2022-11-18 22:15:34 +0100 | <yahb2> | <interactive>:192:10: warning: [-Wmissing-methods] ; • No explicit implementation for ; ‘po’ ; • In the instance declaration for ‘Thing 'IntRep Int#’ |
| 2022-11-18 22:15:39 +0100 | <tomsmeding> | there we go |
| 2022-11-18 22:15:55 +0100 | <dminuoso> | Maybe.. |
| 2022-11-18 22:15:57 +0100 | <dminuoso> | Mmm. |
| 2022-11-18 22:16:26 +0100 | <dminuoso> | I have a bunch of really poor ideas |
| 2022-11-18 22:16:45 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-18 22:16:51 +0100 | <dminuoso> | Thinking whether we could just pass a Word# through, and unsafeCoerce# it into back |
| 2022-11-18 22:16:57 +0100 | <dminuoso> | And get polymorphism this way |
| 2022-11-18 22:17:02 +0100 | <tomsmeding> | into back? |
| 2022-11-18 22:17:05 +0100 | <dminuoso> | or hold on! |
| 2022-11-18 22:17:08 +0100 | <tomsmeding> | into what, a boxed pointer? |
| 2022-11-18 22:17:11 +0100 | <dminuoso> | Yes. |
| 2022-11-18 22:17:13 +0100 | <tomsmeding> | that ain't gonna fly with the gc |
| 2022-11-18 22:17:18 +0100 | <dminuoso> | I know, hence "poor ideas" |
| 2022-11-18 22:17:23 +0100 | <tomsmeding> | ::p |
| 2022-11-18 22:17:25 +0100 | <tomsmeding> | * :p |
| 2022-11-18 22:17:45 +0100 | <dminuoso> | well or we just remand the user only supply pinned objects. |
| 2022-11-18 22:17:48 +0100 | <dminuoso> | :p |
| 2022-11-18 22:17:53 +0100 | <dminuoso> | "if you dont, this will crash very horribly" |
| 2022-11-18 22:18:30 +0100 | <tomsmeding> | doesn't pinning objects have a performance penalty? |
| 2022-11-18 22:19:08 +0100 | <geekosaur> | just a GC penalty I think |
| 2022-11-18 22:19:09 +0100 | <dminuoso> | can you please not shoot down an idea that actually work with performance worries? |
| 2022-11-18 22:19:11 +0100 | <dminuoso> | :p |
| 2022-11-18 22:19:19 +0100 | <tomsmeding> | lol |
| 2022-11-18 22:19:24 +0100 | <money> | Okay |
| 2022-11-18 22:19:27 +0100 | <geekosaur> | since GC can't use memory optimally any more |
| 2022-11-18 22:19:34 +0100 | <tomsmeding> | ah |
| 2022-11-18 22:21:01 +0100 | <dminuoso> | tomsmeding: Ultimately this problem arises because in monadic parsers there is no barrier between the grammatic parsing and the parser action. |
| 2022-11-18 22:21:27 +0100 | <dminuoso> | If we did this in a traditional parser generator like happy, the backtracking happens on the BNF specification, but not after monadic actions occur. |
| 2022-11-18 22:21:47 +0100 | <tomsmeding> | right |
| 2022-11-18 22:22:28 +0100 | <dminuoso> | I mean it is cute that with a `ParserT (State Int)` you get to freely intermingle them |
| 2022-11-18 22:23:26 +0100 | <dminuoso> | Mmm Ill get some rest and think about it tomorrow. Good night |
| 2022-11-18 22:24:05 +0100 | <tomsmeding> | good night :) |
| 2022-11-18 22:26:52 +0100 | Everything | (~Everythin@37.115.210.35) (Quit: leaving) |
| 2022-11-18 22:26:53 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-18 22:33:28 +0100 | xilo | (~yourname@84.32.165.17) |
| 2022-11-18 22:34:16 +0100 | <tomsmeding> | dminuoso: seems to work https://paste.tomsmeding.com/ySfezf4q |
| 2022-11-18 22:36:29 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-18 22:36:49 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-18 22:39:44 +0100 | AdonisExberger | (~Adonis-Ex@176.54.36.182) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2022-11-18 22:40:15 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 22:43:16 +0100 | <Xeroine> | Data constructors and values are interchangeable/the same thing, right? Is that the case always? |
| 2022-11-18 22:43:33 +0100 | irrgit__ | (~irrgit@89.47.234.74) |
| 2022-11-18 22:44:58 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-11-18 22:45:04 +0100 | <geekosaur> | if you find yourself playing with Core at some point you'll discover that partially applied data constructors are handled a little differently, but in surface Haskell they are indistinguishable |
| 2022-11-18 22:46:01 +0100 | <EvanR_> | Xeroine, hold the phone |
| 2022-11-18 22:46:08 +0100 | <c_wraith> | Data constructors are values, but not all values are data constructors |
| 2022-11-18 22:46:12 +0100 | EvanR_ | EvanR |
| 2022-11-18 22:46:14 +0100 | <EvanR> | yeah, that |
| 2022-11-18 22:46:32 +0100 | <EvanR> | functions don't have a data constructor in haskell |
| 2022-11-18 22:46:54 +0100 | irrgit_ | (~irrgit@89.47.234.74) (Ping timeout: 256 seconds) |
| 2022-11-18 22:47:18 +0100 | <geekosaur> | also underneath a literal number isn't a data constructor, it's application of a function. but haskell tries hard to pretend they are |
| 2022-11-18 22:47:49 +0100 | irrgit_ | (~irrgit@89.47.234.74) |
| 2022-11-18 22:48:56 +0100 | <Xeroine> | geekosaur: isn't a literal number just a nullary data constructor which is a constant which is a value? |
| 2022-11-18 22:48:58 +0100 | <c_wraith> | I'd even argue that `Just' is a data constructor, but `Just ()` isn't. Data constructors are things that can be atoms of a pattern match. |
| 2022-11-18 22:49:22 +0100 | <geekosaur> | Xeroine, no. literal numbers are handled specially |
| 2022-11-18 22:49:33 +0100 | <geekosaur> | :t 5 |
| 2022-11-18 22:49:34 +0100 | <lambdabot> | Num p => p |
| 2022-11-18 22:49:44 +0100 | irrgit__ | (~irrgit@89.47.234.74) (Ping timeout: 256 seconds) |
| 2022-11-18 22:50:09 +0100 | <Xeroine> | it has a Num class type constraint, does that mean it's not a data constructor? |
| 2022-11-18 22:50:19 +0100 | <geekosaur> | underneath, this is compiled as `fromInteger <hardcoded Integer literal>` |
| 2022-11-18 22:50:46 +0100 | <geekosaur> | floating point literals do something similar but using `fromRational` |
| 2022-11-18 22:50:51 +0100 | <geekosaur> | :t 5.0 |
| 2022-11-18 22:50:52 +0100 | <lambdabot> | Fractional p => p |
| 2022-11-18 22:50:56 +0100 | <Xeroine> | oh right I've heard of fromInteger but didn't read much what it does |
| 2022-11-18 22:52:34 +0100 | <geekosaur> | that said, a Char literal is compiled to `C# <ordinal of character>#` so it is a normal data constructor |
| 2022-11-18 22:55:47 +0100 | <geekosaur> | (the #s there require the MagicHash extension, otherwise # is an ordinary operator character) |
| 2022-11-18 22:58:00 +0100 | <Xeroine> | what does the :% operator do? it's used a lot in https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.Real.html#fromIntegral and in the fromInteger definition as well |
| 2022-11-18 22:58:48 +0100 | <mauke> | data Ratio a = !a :% !a deriving (Eq) |
| 2022-11-18 22:58:51 +0100 | <geekosaur> | it's the raw constructor for a Rational |
| 2022-11-18 22:58:53 +0100 | <mauke> | data constructor |
| 2022-11-18 22:59:00 +0100 | <EvanR> | think of Functional p => p as like actually a function taking a dictionary, handled behind the scenes |
| 2022-11-18 22:59:21 +0100 | <EvanR> | nothing happens until something provides the implementation of Functional p |
| 2022-11-18 22:59:28 +0100 | <EvanR> | er Fractional |
| 2022-11-18 23:03:22 +0100 | <EvanR> | for instance, how to convert 5.0 to p |
| 2022-11-18 23:05:53 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-18 23:09:23 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-18 23:10:10 +0100 | <Xeroine> | geekosaur: does raw mean it's somehow special? I saw "data Ratio a = !a :% !a deriving (Eq)" as well but I don't understand :% in that context either |
| 2022-11-18 23:10:42 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-18 23:11:06 +0100 | <geekosaur> | that just defines :% as an infix data constructor (all infix data constructors must start with a colon) |
| 2022-11-18 23:11:40 +0100 | <geekosaur> | it's "raw" because Ratio wants to have normalized values, whereas a data constructor takes what it's given |
| 2022-11-18 23:12:18 +0100 | <geekosaur> | so we actually construct Rationals with % instead of :%, and % normalizes the values before using :% to create the actual value |
| 2022-11-18 23:12:32 +0100 | <geekosaur> | (% is therefore called a "smart constructor") |
| 2022-11-18 23:12:32 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-18 23:12:38 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Client Quit) |
| 2022-11-18 23:12:58 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-18 23:13:29 +0100 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 268 seconds) |
| 2022-11-18 23:14:24 +0100 | <Xeroine> | ah okay |
| 2022-11-18 23:14:40 +0100 | <geekosaur> | the "must start with a colon" thing is because of pattern matching, which has to tell the difference between constructors and variables. for normal constructors it uses case, which is why all normal data constructors start with uppercase |
| 2022-11-18 23:14:56 +0100 | <geekosaur> | but there's no such thing as an "uppercase symbol", so the prefix colon is used instead |
| 2022-11-18 23:15:44 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) |
| 2022-11-18 23:17:56 +0100 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2022-11-18 23:20:54 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 256 seconds) |
| 2022-11-18 23:22:32 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-18 23:27:03 +0100 | euandreh | (~Thunderbi@189.40.77.30) (Ping timeout: 268 seconds) |
| 2022-11-18 23:27:09 +0100 | euandreh2 | (~Thunderbi@179.214.113.107) |
| 2022-11-18 23:28:50 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-18 23:29:26 +0100 | euandreh2 | euandreh |
| 2022-11-18 23:30:58 +0100 | libertyprime | (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Quit: leaving) |
| 2022-11-18 23:32:35 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-18 23:33:56 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-18 23:38:15 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) |
| 2022-11-18 23:38:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-18 23:38:50 +0100 | <Guest99> | Hi. |
| 2022-11-18 23:40:38 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-11-18 23:41:59 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-18 23:46:27 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.7.1) |
| 2022-11-18 23:47:34 +0100 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-11-18 23:48:20 +0100 | <sclv> | let me mention because someone asked about arch and dynamic stuff earlier -- this pending pr will hopefully make the dynamic-only story supported a bit better in cabal, although i still don't like that story :-P https://github.com/haskell/cabal/pull/8461 |
| 2022-11-18 23:48:23 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) (Quit: Client closed) |
| 2022-11-18 23:48:26 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-18 23:49:22 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) |
| 2022-11-18 23:50:34 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-18 23:50:45 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-11-18 23:50:52 +0100 | <sclv> | EvanR: ^^ |
| 2022-11-18 23:51:47 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-18 23:54:34 +0100 | <Guest99> | I'm learning Agda by trying to imitate the Haskell code from the book "Discrete Mathematics Using a Computer". I'm trying to implement list comprehension in Agda and I would like to find the source code for the Haskell (..) operator. I haven't been able to find it anywhere. Not Hoogle, not Google, not the GHC docs, not in the Haskell docs! I'm sure |
| 2022-11-18 23:54:34 +0100 | <Guest99> | I'm just missing something obvious. Would you please be so kind as to point me to the source code for the (..) operator, i.e., [0..3] returns [1,2,3] ? Thanks! |
| 2022-11-18 23:55:17 +0100 | <geekosaur> | it's not an operator, it's special syntax. [x .. y] expands to `enumFromTo x y` |
| 2022-11-18 23:55:17 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-11-18 23:56:02 +0100 | <geekosaur> | `[x, y .. z]` is `enumFromThenTo x y z` |
| 2022-11-18 23:56:16 +0100 | <geekosaur> | `[x ..]` is `enumFrom x` |
| 2022-11-18 23:56:59 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) (Quit: Client closed) |
| 2022-11-18 23:57:23 +0100 | <geekosaur> | all the list-associated syntax in Haskell is hardwired into the compiler; a list "natively" uses the (:) constructor and `[]` for end-of-list |
| 2022-11-18 23:57:40 +0100 | <geekosaur> | didn't stick around long, did they? sigh |
| 2022-11-18 23:58:25 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) |