| 2023-11-15 00:03:41 +0100 | chaitlatte0 | (ea29c0bb16@user/chaitlatte0) (Server closed connection) |
| 2023-11-15 00:03:51 +0100 | chaitlatte0 | (ea29c0bb16@user/chaitlatte0) |
| 2023-11-15 00:04:16 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-11-15 00:04:36 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-11-15 00:12:25 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 00:20:44 +0100 | fn_lumi | (3d621153a5@2604:bf00:561:2000::df7) (Server closed connection) |
| 2023-11-15 00:20:52 +0100 | fn_lumi | (3d621153a5@2604:bf00:561:2000::df7) |
| 2023-11-15 00:22:23 +0100 | jkoshy | (99b9359beb@user/jkoshy) (Server closed connection) |
| 2023-11-15 00:22:33 +0100 | jkoshy | (99b9359beb@user/jkoshy) |
| 2023-11-15 00:23:42 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2023-11-15 00:30:47 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) (Server closed connection) |
| 2023-11-15 00:32:08 +0100 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2023-11-15 00:34:18 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Server closed connection) |
| 2023-11-15 00:34:40 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2023-11-15 00:35:23 +0100 | myxos | (~myxos@cpe-65-28-251-121.cinci.res.rr.com) |
| 2023-11-15 00:37:14 +0100 | JoelMcCracken | (5ea8252fbb@2604:bf00:561:2000::10e3) (Server closed connection) |
| 2023-11-15 00:37:26 +0100 | JoelMcCracken | (5ea8252fbb@2604:bf00:561:2000::10e3) |
| 2023-11-15 00:41:50 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 252 seconds) |
| 2023-11-15 00:42:28 +0100 | michalz | (~michalz@185.246.207.222) (Remote host closed the connection) |
| 2023-11-15 00:51:30 +0100 | larnee | (~gm@APN-123-251-154-gprs.simobil.net) |
| 2023-11-15 00:59:24 +0100 | puke | (~puke@user/puke) (Ping timeout: 240 seconds) |
| 2023-11-15 00:59:42 +0100 | talismanick | (~user@campus-116-122.ucdavis.edu) |
| 2023-11-15 01:10:47 +0100 | landonf | (landonf@mac68k.info) (Server closed connection) |
| 2023-11-15 01:10:56 +0100 | landonf | (landonf@mac68k.info) |
| 2023-11-15 01:10:57 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-11-15 01:10:59 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Ping timeout: 252 seconds) |
| 2023-11-15 01:12:39 +0100 | thegeekinside | (~thegeekin@189.141.80.123) (Remote host closed the connection) |
| 2023-11-15 01:20:24 +0100 | johnw | (~johnw@69.62.242.138) |
| 2023-11-15 01:22:23 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-11-15 01:25:51 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 260 seconds) |
| 2023-11-15 01:30:00 +0100 | Guest21 | (~Guest21@178.255.149.181) |
| 2023-11-15 01:30:00 +0100 | immae | (~immae@2a01:4f8:141:53e7::) (Server closed connection) |
| 2023-11-15 01:30:19 +0100 | immae | (~immae@2a01:4f8:141:53e7::) |
| 2023-11-15 01:34:03 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) |
| 2023-11-15 01:34:21 +0100 | thegeekinside | (~thegeekin@189.141.80.123) |
| 2023-11-15 01:47:59 +0100 | <Guest21> | hi. i'm not sure if this is the best place to ask this, but i'm encountering problems while trying to install readline through cabal on macos. i already installed readline through brew and it currently sits at: `/opt/homebrew/Cellar/readline/8.2.1/` . after numerous threads about the issue, i ended up at following command (which seemed to work for |
| 2023-11-15 01:48:00 +0100 | <Guest21> | some people): https://paste.tomsmeding.com/X27wQMlq. unfortunately the logs (https://paste.tomsmeding.com/kP4Zf2Yo) say that readline wasn't found. i can't figure out what's wrong here, does anyone have a clue? |
| 2023-11-15 01:52:32 +0100 | <EvanR> | try closing the terminal in case environment variables haven't updated |
| 2023-11-15 01:53:39 +0100 | <Guest21> | unfortunately it doesn't work. logs stay the same |
| 2023-11-15 01:54:29 +0100 | thaumavorio | (~thaumavor@thaumavor.io) (Server closed connection) |
| 2023-11-15 01:55:49 +0100 | thaumavorio | (~thaumavor@thaumavor.io) |
| 2023-11-15 01:58:56 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) (Remote host closed the connection) |
| 2023-11-15 01:59:15 +0100 | <geekosaur> | actually that log says it was found, but is apparently the wrong version |
| 2023-11-15 01:59:36 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) |
| 2023-11-15 01:59:55 +0100 | <geekosaur> | it has rl_readline_version but not rl_begin_undo_group |
| 2023-11-15 02:00:23 +0100 | <geekosaur> | (the earlier failure was llooking for a different variety of readline install, via a MacOS framework instead of a normal library) |
| 2023-11-15 02:01:11 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-11-15 02:01:15 +0100 | <mauke> | according to the configure script, this means "-lreadline" is actually libedit |
| 2023-11-15 02:01:26 +0100 | <mauke> | the "readline not found" error is generic |
| 2023-11-15 02:01:38 +0100 | <mauke> | so it's finding the wrong library |
| 2023-11-15 02:01:59 +0100 | califax | (~califax@user/califx) |
| 2023-11-15 02:03:51 +0100 | <Guest21> | is the problem here with order of search locations? first it goes for system location where it finds libedit without all necessary features and then it would search the extra locations? |
| 2023-11-15 02:03:57 +0100 | <mauke> | Guest21: vague idea: what does 'ls -l /opt/homebrew/Cellar/readline/8.2.1/lib' report? |
| 2023-11-15 02:04:05 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-15 02:04:34 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) (Remote host closed the connection) |
| 2023-11-15 02:05:07 +0100 | <Guest21> | `-r--r--r--@ 1 user admin 91888 Nov 15 00:38 libhistory.8.2.dylib` |
| 2023-11-15 02:05:08 +0100 | <Guest21> | `lrwxr-xr-x@ 1 user admin 20 Sep 23 2022 libhistory.8.dylib@ -> libhistory.8.2.dylib` |
| 2023-11-15 02:05:08 +0100 | <Guest21> | `-r--r--r--@ 1 user admin 46504 Sep 23 2022 libhistory.a` |
| 2023-11-15 02:05:09 +0100 | <Guest21> | `lrwxr-xr-x@ 1 user admin 20 Sep 23 2022 libhistory.dylib@ -> libhistory.8.2.dylib` |
| 2023-11-15 02:05:09 +0100 | <Guest21> | `-rw-r--r--@ 1 user admin 311648 Nov 15 00:38 libreadline.8.2.dylib` |
| 2023-11-15 02:05:10 +0100 | <Guest21> | `lrwxr-xr-x@ 1 user admin 21 Sep 23 2022 libreadline.8.dylib@ -> libreadline.8.2.dylib` |
| 2023-11-15 02:05:10 +0100 | <Guest21> | `-r--r--r--@ 1 user admin 468504 Sep 23 2022 libreadline.a` |
| 2023-11-15 02:05:11 +0100 | <Guest21> | `lrwxr-xr-x@ 1 user admin 21 Sep 23 2022 libreadline.dylib@ -> libreadline.8.2.dylib` |
| 2023-11-15 02:05:11 +0100 | <Guest21> | `drwxr-xr-x@ 4 user admin 128 Nov 15 00:38 pkgconfig/` |
| 2023-11-15 02:05:12 +0100 | <Guest21> | i'm sorry, is there a multiline quote? |
| 2023-11-15 02:05:23 +0100 | noteness | (~noteness@user/noteness) (Server closed connection) |
| 2023-11-15 02:05:28 +0100 | <EvanR> | OOF |
| 2023-11-15 02:06:27 +0100 | <mauke> | as a general rule, don't paste into IRC (beyond a single line). we use paste sites for that |
| 2023-11-15 02:06:30 +0100 | <geekosaur> | not in IRC; use a pastebin |
| 2023-11-15 02:06:33 +0100 | <geekosaur> | @where paste |
| 2023-11-15 02:06:33 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2023-11-15 02:06:39 +0100 | noteness | (~noteness@user/noteness) |
| 2023-11-15 02:06:45 +0100 | <Guest21> | https://paste.tomsmeding.com/ClRzpeMh |
| 2023-11-15 02:09:12 +0100 | <mauke> | looks normal to me |
| 2023-11-15 02:09:52 +0100 | <geekosaur> | looks reasonable to me as well, granting it's been several years since I dealt with Macs |
| 2023-11-15 02:10:26 +0100 | <mauke> | for fun, you could try 'nm /opt/homebrew/Cellar/readline/8.2.1/lib/libreadline.a | grep rl_begin_undo_group', but I'm not sure what nm output looks like on macos |
| 2023-11-15 02:11:32 +0100 | dostoyevsky2 | (~sck@user/dostoyevsky2) (Server closed connection) |
| 2023-11-15 02:11:37 +0100 | <mauke> | on my linux system, the output contains "00000000000004d0 T rl_begin_undo_group", indicating that the symbol is defined somewhere in the "T"ext section |
| 2023-11-15 02:11:41 +0100 | <Guest21> | mauke: https://paste.tomsmeding.com/WWuZfqAw |
| 2023-11-15 02:11:42 +0100 | dostoyevsky2 | (~sck@user/dostoyevsky2) |
| 2023-11-15 02:12:13 +0100 | <mauke> | ah, decorated with a leading underscore |
| 2023-11-15 02:12:18 +0100 | <geekosaur> | what's worrying me is that recentish MacOS has this system loader cache thing that might be overriding the actual selected library |
| 2023-11-15 02:12:43 +0100 | <geekosaur> | although it's more likely that it's just not looking where it was told to for some reason |
| 2023-11-15 02:14:08 +0100 | <geekosaur> | hm, actually I wonder if that command line works with v2-install |
| 2023-11-15 02:14:19 +0100 | <geekosaur> | which is intended for binaries, not libraries |
| 2023-11-15 02:15:32 +0100 | <geekosaur> | (if you have cabal 3.x, install is v2-install) |
| 2023-11-15 02:16:13 +0100 | <Guest21> | wow, it worked with v1-install |
| 2023-11-15 02:16:15 +0100 | <Guest21> | thank you |
| 2023-11-15 02:16:51 +0100 | <geekosaur> | right, but anything you build that depends on it won't work unless you use v1-install for those |
| 2023-11-15 02:19:44 +0100 | talismanick | (~user@campus-116-122.ucdavis.edu) (Ping timeout: 252 seconds) |
| 2023-11-15 02:20:41 +0100 | <geekosaur> | I think for v2 install you need a cabal.project.local that looks like https://paste.tomsmeding.com/Xe1savDh |
| 2023-11-15 02:21:13 +0100 | <geekosaur> | lemme doublecheck that configure-option works there |
| 2023-11-15 02:22:17 +0100 | <Guest21> | is cabal.project.local declaration different from passing it as arguments? (cabal.project.local) |
| 2023-11-15 02:22:33 +0100 | <Guest21> | (https://paste.tomsmeding.com/X27wQMlq)* |
| 2023-11-15 02:22:38 +0100 | <Guest21> | https://paste.tomsmeding.com/X27wQMlq |
| 2023-11-15 02:22:48 +0100 | <geekosaur> | yes, because it allows specifying them per dependency |
| 2023-11-15 02:22:54 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) |
| 2023-11-15 02:23:25 +0100 | <geekosaur> | whereas (v2-)install has no idea what to do aside from applying them to the current package, not its dependencies |
| 2023-11-15 02:25:26 +0100 | <geekosaur> | (you should probably read up on https://cabal.readthedocs.io/en/3.8/nix-local-build-overview.html#nix-style-local-builds to understand what's up with v2-install) |
| 2023-11-15 02:28:24 +0100 | <geekosaur> | unfortunately cases like this suggest a need for a cabal.project.global that could be used any time readline or similar libraries were needed as a dependency, but that doesn't currently exist |
| 2023-11-15 02:33:54 +0100 | <Guest21> | is there a way to successfully v2-install readline globally? |
| 2023-11-15 02:34:40 +0100 | <geekosaur> | I think you'll have to ask in #hackage, but I suspect this is one of those cases where v2-commands don't quite do what you need yet |
| 2023-11-15 02:35:05 +0100 | <geekosaur> | sclv might know more if they'[re around |
| 2023-11-15 02:37:45 +0100 | <Guest21> | i see, i'll keep chiseling away at this topic, thanks a lot for monumental help |
| 2023-11-15 02:38:44 +0100 | <EvanR> | installing stuff globally is what used to cause cabal hell right, and now we have sandboxing which is avoids it? |
| 2023-11-15 02:39:51 +0100 | <geekosaur> | yes, but sometimes it's a bit too sandboxed |
| 2023-11-15 02:40:26 +0100 | <geekosaur> | everything that uses readline needs a cabal.project.local that tells its readline dependency how to build |
| 2023-11-15 02:40:41 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA2006F74B99BA9A50702.dsl.pool.telekom.hu) (Ping timeout: 260 seconds) |
| 2023-11-15 02:40:54 +0100 | <geekosaur> | a cabal.project.global that sat next to (or within) the global cabal config would ameliorate this |
| 2023-11-15 02:43:58 +0100 | <Guest21> | to add some context why i wanted to do it globally. i tried compiling jhc (i know editline is sufficient, but i wanted to understand why passing readline location arguments failed), which i think expected global installations of packages and it was this that made me want to learn how global installations work |
| 2023-11-15 02:44:19 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2023-11-15 02:46:15 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-11-15 02:46:30 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 02:48:01 +0100 | Guest21 | (~Guest21@178.255.149.181) (Quit: Client closed) |
| 2023-11-15 02:51:25 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-11-15 02:54:05 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6c8e:2e92:196f:e24b) (Ping timeout: 240 seconds) |
| 2023-11-15 03:00:16 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-11-15 03:00:53 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 03:01:03 +0100 | jathan | (~jathan@69.61.93.38) (Quit: WeeChat 2.3) |
| 2023-11-15 03:02:41 +0100 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 240 seconds) |
| 2023-11-15 03:05:38 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) (Ping timeout: 250 seconds) |
| 2023-11-15 03:08:34 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 03:11:06 +0100 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2023-11-15 03:12:29 +0100 | otto_s | (~user@p5de2f612.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-11-15 03:14:23 +0100 | otto_s | (~user@p5b044a1d.dip0.t-ipconnect.de) |
| 2023-11-15 03:15:52 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2023-11-15 03:19:22 +0100 | jocke-l | (jocke-l@a.x0.is) (Server closed connection) |
| 2023-11-15 03:19:47 +0100 | jocke-l | (jocke-l@a.x0.is) |
| 2023-11-15 03:32:00 +0100 | vilya | (~vilya@user/vilya) (Ping timeout: 245 seconds) |
| 2023-11-15 03:32:07 +0100 | vilya_ | (~vilya@user/vilya) |
| 2023-11-15 03:36:01 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 240 seconds) |
| 2023-11-15 03:36:35 +0100 | thegeekinside | (~thegeekin@189.141.80.123) (Remote host closed the connection) |
| 2023-11-15 03:37:51 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 245 seconds) |
| 2023-11-15 03:38:22 +0100 | erty` | (~user@122.161.49.213) |
| 2023-11-15 03:39:18 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 256 seconds) |
| 2023-11-15 03:39:28 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-11-15 03:39:55 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Ping timeout: 245 seconds) |
| 2023-11-15 03:40:02 +0100 | erty | (~user@user/aeroplane) (Ping timeout: 252 seconds) |
| 2023-11-15 03:46:52 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 264 seconds) |
| 2023-11-15 03:50:39 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) |
| 2023-11-15 03:58:00 +0100 | euleritian | (~euleritia@dynamic-089-204-135-248.89.204.135.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 03:58:18 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 04:09:46 +0100 | edr | (~edr@user/edr) (Quit: Leaving) |
| 2023-11-15 04:11:30 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-15 04:15:42 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-11-15 04:16:50 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 04:18:41 +0100 | td_ | (~td@i53870929.versanet.de) (Ping timeout: 245 seconds) |
| 2023-11-15 04:19:23 +0100 | kiriakos | (~kiriakos@p57b6414b.dip0.t-ipconnect.de) |
| 2023-11-15 04:20:29 +0100 | td_ | (~td@i53870918.versanet.de) |
| 2023-11-15 04:21:17 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 04:34:54 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) (Ping timeout: 250 seconds) |
| 2023-11-15 04:34:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-11-15 04:34:59 +0100 | She | (haveident@libera/staff/she/her) (*.net *.split) |
| 2023-11-15 04:34:59 +0100 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) (*.net *.split) |
| 2023-11-15 04:35:10 +0100 | She | (haveident@libera/staff/she/her) |
| 2023-11-15 04:35:21 +0100 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) |
| 2023-11-15 04:35:54 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-11-15 04:48:19 +0100 | erty` | (~user@122.161.49.213) (ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2023-11-15 04:51:01 +0100 | larnee | (~gm@APN-123-251-154-gprs.simobil.net) (Quit: larnee) |
| 2023-11-15 04:52:10 +0100 | telser | (~quassel@user/telser) |
| 2023-11-15 04:59:01 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 04:59:01 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-11-15 04:59:01 +0100 | finn_elija | FinnElija |
| 2023-11-15 04:59:31 +0100 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) (Quit: ZNC 1.8.2+cygwin2 - https://znc.in) |
| 2023-11-15 05:00:34 +0100 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) |
| 2023-11-15 05:00:48 +0100 | vilya_ | vilya |
| 2023-11-15 05:07:55 +0100 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split) |
| 2023-11-15 05:08:24 +0100 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2023-11-15 05:09:04 +0100 | friendshipaka | (~Friendshi@user/Friendship) (Read error: Connection reset by peer) |
| 2023-11-15 05:09:31 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 245 seconds) |
| 2023-11-15 05:09:39 +0100 | cstml | (~pi@user/cstml) (Read error: Connection reset by peer) |
| 2023-11-15 05:10:44 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-11-15 05:10:54 +0100 | aforemny | (~aforemny@i59F516FE.versanet.de) (Ping timeout: 268 seconds) |
| 2023-11-15 05:11:11 +0100 | aforemny | (~aforemny@2001:9e8:6cf2:3800:48da:c417:67b:551b) |
| 2023-11-15 05:13:13 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-15 05:18:18 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2023-11-15 05:19:06 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 245 seconds) |
| 2023-11-15 05:37:10 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 256 seconds) |
| 2023-11-15 05:37:56 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-11-15 05:38:56 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-11-15 05:47:24 +0100 | xsarnik | (xsarnik@lounge.fi.muni.cz) (Server closed connection) |
| 2023-11-15 05:47:40 +0100 | xsarnik | (xsarnik@lounge.fi.muni.cz) |
| 2023-11-15 05:49:35 +0100 | qqq | (~qqq@92.43.167.61) |
| 2023-11-15 05:54:21 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-11-15 05:54:53 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 06:04:55 +0100 | rosco | (~rosco@175.136.157.149) |
| 2023-11-15 06:05:26 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) |
| 2023-11-15 06:10:39 +0100 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Server closed connection) |
| 2023-11-15 06:11:50 +0100 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) |
| 2023-11-15 06:24:34 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) (Quit: derpyxdhs) |
| 2023-11-15 06:28:52 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 264 seconds) |
| 2023-11-15 06:31:17 +0100 | trev | (~trev@user/trev) |
| 2023-11-15 06:31:23 +0100 | jinsun_ | (~jinsun@user/jinsun) |
| 2023-11-15 06:31:23 +0100 | jinsun | (~jinsun@user/jinsun) (Killed (silver.libera.chat (Nickname regained by services))) |
| 2023-11-15 06:31:24 +0100 | jinsun_ | jinsun |
| 2023-11-15 06:31:43 +0100 | biberu | (~biberu@user/biberu) |
| 2023-11-15 06:36:31 +0100 | jinsun_ | (~jinsun@user/jinsun) |
| 2023-11-15 06:36:31 +0100 | jinsun | Guest5766 |
| 2023-11-15 06:36:32 +0100 | jinsun_ | jinsun |
| 2023-11-15 06:36:46 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 06:40:37 +0100 | Guest5766 | (~jinsun@user/jinsun) (Ping timeout: 268 seconds) |
| 2023-11-15 06:41:44 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-11-15 06:42:09 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 06:45:52 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-11-15 06:49:17 +0100 | thegeekinside | (~thegeekin@189.141.80.123) |
| 2023-11-15 06:52:30 +0100 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2023-11-15 06:56:38 +0100 | jinsun | (~jinsun@user/jinsun) |
| 2023-11-15 06:59:41 +0100 | telser | (~quassel@user/telser) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2023-11-15 07:05:36 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-11-15 07:13:39 +0100 | Inst | (~Inst@120.244.192.250) (Ping timeout: 246 seconds) |
| 2023-11-15 07:14:07 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-11-15 07:15:07 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-11-15 07:15:43 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 07:17:50 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2023-11-15 07:17:54 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-11-15 07:17:58 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) |
| 2023-11-15 07:19:07 +0100 | seeg123456 | (~seeg12345@64.176.64.83) |
| 2023-11-15 07:19:30 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 07:19:46 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 07:19:57 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 246 seconds) |
| 2023-11-15 07:27:15 +0100 | acidjnk | (~acidjnk@p200300d6e72b9310fd221caae09ed082.dip0.t-ipconnect.de) |
| 2023-11-15 07:27:23 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-15 07:28:48 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2023-11-15 07:29:07 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) |
| 2023-11-15 07:33:37 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-11-15 07:33:56 +0100 | kmein | (~weechat@user/kmein) (Server closed connection) |
| 2023-11-15 07:34:06 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-11-15 07:34:21 +0100 | kmein | (~weechat@user/kmein) |
| 2023-11-15 07:35:03 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-15 07:47:38 +0100 | thegeekinside | (~thegeekin@189.141.80.123) (Remote host closed the connection) |
| 2023-11-15 07:51:50 +0100 | michalz | (~michalz@185.246.207.193) |
| 2023-11-15 07:56:00 +0100 | kiriakos | (~kiriakos@p57b6414b.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2023-11-15 07:56:58 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-11-15 08:08:48 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-11-15 08:09:16 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-15 08:09:27 +0100 | thegeekinside | (~thegeekin@189.141.80.123) |
| 2023-11-15 08:10:21 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-11-15 08:11:53 +0100 | rosco | (~rosco@175.136.157.149) (Ping timeout: 268 seconds) |
| 2023-11-15 08:12:06 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 246 seconds) |
| 2023-11-15 08:16:28 +0100 | <Inst> | http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf |
| 2023-11-15 08:16:30 +0100 | <Inst> | wat |
| 2023-11-15 08:17:15 +0100 | <Inst> | check section 4, takes py and perl 2 hours to do this |
| 2023-11-15 08:17:19 +0100 | <Inst> | on average |
| 2023-11-15 08:17:48 +0100 | <Inst> | sequence . fmap (toList) . show |
| 2023-11-15 08:18:05 +0100 | <Inst> | if you don't care about performance, this is so easy |
| 2023-11-15 08:18:15 +0100 | <Inst> | 30 minutes in Haskell, and I suck |
| 2023-11-15 08:20:56 +0100 | thegeekinside | (~thegeekin@189.141.80.123) (Ping timeout: 256 seconds) |
| 2023-11-15 08:27:41 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) |
| 2023-11-15 08:29:08 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-11-15 08:31:23 +0100 | <mauke> | perl 5.003? oh, baby |
| 2023-11-15 08:31:42 +0100 | <mauke> | that's 1996 |
| 2023-11-15 08:37:34 +0100 | yosef` | (~yosef`@user/yosef/x-2947716) (Ping timeout: 250 seconds) |
| 2023-11-15 08:37:40 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 08:37:57 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 08:46:07 +0100 | fendor | (~fendor@2a02:8388:1640:be00:ca17:ceee:5bbe:1594) |
| 2023-11-15 08:47:15 +0100 | _73_ | (~anon_73@2600:4040:5205:d800:21e8:9777:49a5:db28) |
| 2023-11-15 08:47:51 +0100 | _73 | (~anon_73@2600:4040:5205:d800:21e8:9777:49a5:db28) (Ping timeout: 245 seconds) |
| 2023-11-15 08:52:01 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 245 seconds) |
| 2023-11-15 09:00:40 +0100 | chomwitt | (~chomwitt@2a02:587:7a1f:e00:1ac0:4dff:fedb:a3f1) |
| 2023-11-15 09:02:23 +0100 | vpan | (~vpan@mail.elitnet.lt) |
| 2023-11-15 09:05:47 +0100 | <Inst> | lol you're kidding me |
| 2023-11-15 09:05:54 +0100 | <Inst> | subsequences probably isn't what's wanted |
| 2023-11-15 09:06:39 +0100 | <Inst> | filter isInDict . fmap (subsequences =<<) . sequence . fmap (toListOfChars) . show |
| 2023-11-15 09:10:59 +0100 | <ski> | what is this `toList'/`toListOfChars', that you're passing `Char's into it ? |
| 2023-11-15 09:12:01 +0100 | <Inst> | i mean the problem of the paper |
| 2023-11-15 09:12:06 +0100 | <Inst> | look up all possible words from a given telephone number |
| 2023-11-15 09:12:51 +0100 | <ski> | mhm, okay |
| 2023-11-15 09:13:09 +0100 | <ski> | @src mapM |
| 2023-11-15 09:13:10 +0100 | <lambdabot> | mapM f as = sequence (map f as) |
| 2023-11-15 09:13:13 +0100 | <Inst> | ah |
| 2023-11-15 09:13:16 +0100 | <Inst> | whoos |
| 2023-11-15 09:13:18 +0100 | <Inst> | whoops |
| 2023-11-15 09:13:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-15 09:13:37 +0100 | <ski> | so `sequence . fmap blah' is `mapM blah' |
| 2023-11-15 09:13:58 +0100 | <Inst> | so just traverse (toListOfChars) . show |
| 2023-11-15 09:14:08 +0100 | <ski> | or `traverse' sure |
| 2023-11-15 09:14:14 +0100 | <Inst> | I just find it funny because it's almost a one-liner in Haskell, but performance will suffer |
| 2023-11-15 09:14:30 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-11-15 09:14:55 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-11-15 09:14:56 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-15 09:17:36 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2023-11-15 09:18:20 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) |
| 2023-11-15 09:19:29 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:93f2:661e:d61:f6f4) |
| 2023-11-15 09:22:11 +0100 | cstml | (~cstml@user/cstml) |
| 2023-11-15 09:28:18 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Quit: FinnElija) |
| 2023-11-15 09:32:02 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-11-15 09:35:45 +0100 | rosco | (~rosco@175.136.157.149) |
| 2023-11-15 09:41:12 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-11-15 09:42:14 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2023-11-15 09:42:14 +0100 | zetef | (~quassel@95.77.17.251) |
| 2023-11-15 09:42:37 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2023-11-15 09:42:56 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-11-15 09:44:39 +0100 | euleritian | (~euleritia@dynamic-089-204-130-178.89.204.130.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 09:44:56 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 09:54:09 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-11-15 10:03:22 +0100 | fendor | (~fendor@2a02:8388:1640:be00:ca17:ceee:5bbe:1594) (Remote host closed the connection) |
| 2023-11-15 10:04:12 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-15 10:04:17 +0100 | benjaminl | (~benjaminl@user/benjaminl) (Server closed connection) |
| 2023-11-15 10:04:33 +0100 | benjaminl | (~benjaminl@user/benjaminl) |
| 2023-11-15 10:10:07 +0100 | Buggys | (Buggys@Buggy.shelltalk.net) (Ping timeout: 264 seconds) |
| 2023-11-15 10:10:29 +0100 | lawt | (~lawt@129.159.36.129) (Server closed connection) |
| 2023-11-15 10:10:53 +0100 | lawt | (~lawt@2603:c024:c008:d000:5b4f:1ef2:fed2:ef3d) |
| 2023-11-15 10:15:23 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-15 10:17:32 +0100 | sclv | (sid39734@haskell/developer/sclv) (Server closed connection) |
| 2023-11-15 10:17:44 +0100 | sclv | (sid39734@haskell/developer/sclv) |
| 2023-11-15 10:20:12 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 246 seconds) |
| 2023-11-15 10:22:11 +0100 | Buggys | (Buggys@Buggy.shelltalk.net) |
| 2023-11-15 10:24:16 +0100 | mechap | (~mechap@user/mechap) |
| 2023-11-15 10:27:11 +0100 | integral | (sid296274@user/integral) (Server closed connection) |
| 2023-11-15 10:27:26 +0100 | integral | (sid296274@user/integral) |
| 2023-11-15 10:27:48 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200CF385604A8335158.dsl.pool.telekom.hu) |
| 2023-11-15 10:33:37 +0100 | snek | (sid280155@id-280155.lymington.irccloud.com) (Server closed connection) |
| 2023-11-15 10:33:48 +0100 | snek | (sid280155@id-280155.lymington.irccloud.com) |
| 2023-11-15 10:34:27 +0100 | santiagopim | (~user@90.167.66.131) (Remote host closed the connection) |
| 2023-11-15 10:34:48 +0100 | CiaoSen | (~Jura@2a05:5800:289:5000:2a3a:4dff:fe84:dbd5) |
| 2023-11-15 10:36:50 +0100 | iphy | (sid67735@id-67735.lymington.irccloud.com) (Server closed connection) |
| 2023-11-15 10:37:00 +0100 | iphy | (sid67735@id-67735.lymington.irccloud.com) |
| 2023-11-15 10:40:00 +0100 | chele | (~chele@user/chele) |
| 2023-11-15 10:40:42 +0100 | zetef | (~quassel@95.77.17.251) |
| 2023-11-15 10:44:21 +0100 | fendor | (~fendor@2a02:8388:1640:be00:2528:5dc7:a36e:9b87) |
| 2023-11-15 10:47:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Remote host closed the connection) |
| 2023-11-15 10:48:12 +0100 | <dminuoso> | Dense code is rarely also performant. |
| 2023-11-15 10:48:46 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-15 10:51:25 +0100 | <dminuoso> | There's some strange bits in that PDF |
| 2023-11-15 10:51:30 +0100 | <dminuoso> | "Please do not over-optimize your program. Deliver your first reasonable solution." |
| 2023-11-15 10:51:50 +0100 | <dminuoso> | Those are some two contradicting extremes. |
| 2023-11-15 10:52:25 +0100 | alp_ | (~alp@2001:861:5e02:eff0:acc6:6062:8e53:293f) |
| 2023-11-15 10:53:12 +0100 | <dminuoso> | But yeah, if you just use subsequences and `filter`, you are not going to be happy. |
| 2023-11-15 10:53:20 +0100 | <dminuoso> | It's just not a *reasonable* solution. |
| 2023-11-15 10:54:24 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-11-15 10:57:07 +0100 | hsw_ | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 2023-11-15 10:57:24 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-11-15 11:04:55 +0100 | puke | (~puke@user/puke) |
| 2023-11-15 11:05:35 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-11-15 11:08:28 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 11:15:21 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-15 11:17:35 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 11:18:14 +0100 | kiriakos | (~kiriakos@p57b647b8.dip0.t-ipconnect.de) |
| 2023-11-15 11:19:33 +0100 | Square2 | (~Square4@user/square) |
| 2023-11-15 11:21:38 +0100 | <Square2> | Are there any publicly available applauded applications of GADTs. Ie, not just a tutorial but some production ready app/lib usage. |
| 2023-11-15 11:23:03 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 268 seconds) |
| 2023-11-15 11:24:24 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 11:24:45 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2023-11-15 11:26:48 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-11-15 11:33:52 +0100 | danse-nr3 | (~danse@151.43.223.187) (Read error: Connection reset by peer) |
| 2023-11-15 11:34:00 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 11:35:00 +0100 | Pickchea | (~private@user/pickchea) |
| 2023-11-15 11:40:05 +0100 | <Inst> | i think the specification wants this: |
| 2023-11-15 11:40:07 +0100 | <Inst> | phoneSub [] = [] |
| 2023-11-15 11:40:07 +0100 | <Inst> | phoneSub (x:xs) = ((x:) <$> inits xs) <> phoneSub xs |
| 2023-11-15 11:40:19 +0100 | <Inst> | which annoys me because I keep on thinking there's probably a more performant way to write this using scanl' etc |
| 2023-11-15 11:40:39 +0100 | <Inst> | oh, i'm a freaking idiot, again |
| 2023-11-15 11:41:03 +0100 | <Inst> | tails =<< inits foo |
| 2023-11-15 11:51:54 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 246 seconds) |
| 2023-11-15 11:52:36 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 246 seconds) |
| 2023-11-15 11:54:40 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2023-11-15 11:54:45 +0100 | califax_ | (~califax@user/califx) |
| 2023-11-15 11:55:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2023-11-15 11:56:02 +0100 | califax_ | califax |
| 2023-11-15 11:57:37 +0100 | coot_ | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-11-15 11:57:54 +0100 | ft | (~ft@p508db3bc.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-11-15 11:57:57 +0100 | <Inst> | or rather concatMap (tail . inits) . tail . inits |
| 2023-11-15 11:58:32 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 256 seconds) |
| 2023-11-15 11:58:37 +0100 | coot_ | coot |
| 2023-11-15 12:06:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Ping timeout: 268 seconds) |
| 2023-11-15 12:06:28 +0100 | <bwe> | how can I let the (Scalpel) parser return `Either Text a` instead of `a`? https://gist.github.com/benjaminweb/a85b8713790dc0b0d08702406d01dc51 |
| 2023-11-15 12:07:09 +0100 | [exa] | (~exa@user/exa/x-3587197) (Server closed connection) |
| 2023-11-15 12:07:18 +0100 | [exa] | (~exa@srv3n.blesmrt.net) |
| 2023-11-15 12:08:55 +0100 | <ncf> | use the Alternative instance? |
| 2023-11-15 12:11:35 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-11-15 12:12:39 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Ping timeout: 260 seconds) |
| 2023-11-15 12:13:15 +0100 | CiaoSen | (~Jura@2a05:5800:289:5000:2a3a:4dff:fe84:dbd5) (Ping timeout: 245 seconds) |
| 2023-11-15 12:13:18 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3141:d1c2:46a9:b11c) |
| 2023-11-15 12:13:42 +0100 | <bwe> | ncf: How? |
| 2023-11-15 12:13:59 +0100 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-11-15 12:14:37 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200CF385604A8335158.dsl.pool.telekom.hu) (Remote host closed the connection) |
| 2023-11-15 12:16:53 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 12:19:08 +0100 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) (Server closed connection) |
| 2023-11-15 12:19:21 +0100 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) |
| 2023-11-15 12:20:30 +0100 | <ncf> | Right <$> text ... <|> pure (Left "no") |
| 2023-11-15 12:22:06 +0100 | <danse-nr3> | interesting |
| 2023-11-15 12:22:06 +0100 | <danse-nr3> | % :t \f a b c -> f <$> a <|> b <|> c |
| 2023-11-15 12:22:06 +0100 | <yahb2> | <interactive>:1:21: error: ; • Variable not in scope: (<|>) :: f b -> t -> t0 ; • Perhaps you meant one of these: ; ‘<*>’ (imported from Prelude), ‘<>’ (imported from Prelude), ; ... |
| 2023-11-15 12:22:16 +0100 | <danse-nr3> | import Data.Applicative |
| 2023-11-15 12:22:21 +0100 | <danse-nr3> | % import Data.Applicative |
| 2023-11-15 12:22:21 +0100 | <yahb2> | <no location info>: error: ; Could not find module ‘Data.Applicative’ ; It is not a module in the current program, or in any known package. |
| 2023-11-15 12:22:26 +0100 | <danse-nr3> | % import Control.Applicative |
| 2023-11-15 12:22:26 +0100 | <yahb2> | <no output> |
| 2023-11-15 12:22:30 +0100 | <danse-nr3> | % :t \f a b c -> f <$> a <|> b <|> c |
| 2023-11-15 12:22:30 +0100 | <yahb2> | \f a b c -> f <$> a <|> b <|> c ; :: Alternative f => (a1 -> a2) -> f a1 -> f a2 -> f a2 -> f a2 |
| 2023-11-15 12:23:15 +0100 | <danse-nr3> | not sure about the role of that `Right` at the beginning, seems unnecessary |
| 2023-11-15 12:23:28 +0100 | Inst | (~Inst@120.244.192.250) (Ping timeout: 256 seconds) |
| 2023-11-15 12:24:09 +0100 | <ncf> | well they wanted an Either |
| 2023-11-15 12:25:08 +0100 | <danse-nr3> | like `Right text <|> Left "no"`? |
| 2023-11-15 12:25:31 +0100 | <ncf> | text is a scraper |
| 2023-11-15 12:25:41 +0100 | <danse-nr3> | oh makes sense, thanks |
| 2023-11-15 12:26:30 +0100 | <bwe> | I get the idea but what's needed to get the implementation compile? https://gist.github.com/benjaminweb/a85b8713790dc0b0d08702406d01dc51 |
| 2023-11-15 12:27:46 +0100 | <ncf> | In the expression: pure Left "no" |
| 2023-11-15 12:29:20 +0100 | <bwe> | pure $ Left "no" -- compiles |
| 2023-11-15 12:30:18 +0100 | <bwe> | (Right <$> text ( "span" @: [hasClass "author"])) <|> pure $ Left "no" -- doesn't |
| 2023-11-15 12:30:24 +0100 | jackdk | (sid373013@cssa/jackdk) (Server closed connection) |
| 2023-11-15 12:30:33 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-11-15 12:30:36 +0100 | jackdk | (sid373013@cssa/jackdk) |
| 2023-11-15 12:30:39 +0100 | <ncf> | $ has the lowest precedence |
| 2023-11-15 12:30:40 +0100 | <bwe> | (Right <$> text ( "span" @: [hasClass "author"])) <|> (pure $ Left "no") -- compiles |
| 2023-11-15 12:31:24 +0100 | <bwe> | yeah, could be simplified in parentheses terms, but it compiles at least |
| 2023-11-15 12:31:44 +0100 | <bwe> | ncf: kudos for the obvious solution I overlooked! |
| 2023-11-15 12:31:57 +0100 | ProofTechnique_ | (sid79547@id-79547.ilkley.irccloud.com) (Server closed connection) |
| 2023-11-15 12:32:13 +0100 | ProofTechnique_ | (sid79547@id-79547.ilkley.irccloud.com) |
| 2023-11-15 12:34:21 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2023-11-15 12:36:36 +0100 | JSharp | (sid4580@id-4580.lymington.irccloud.com) (Server closed connection) |
| 2023-11-15 12:36:53 +0100 | JSharp | (sid4580@id-4580.lymington.irccloud.com) |
| 2023-11-15 12:37:56 +0100 | <bwe> | https://gist.github.com/benjaminweb/a85b8713790dc0b0d08702406d01dc51 -- rev 3 |
| 2023-11-15 12:39:07 +0100 | <bwe> | how can I combine multiple `Scraper String (Either String String)` in a `combinedScraper` that fails and returns on the first `Left` produced by a sub scraper? I've added a blueprint of combinedScraper to the gist ^. |
| 2023-11-15 12:40:28 +0100 | chomwitt | (~chomwitt@2a02:587:7a1f:e00:1ac0:4dff:fedb:a3f1) (Ping timeout: 256 seconds) |
| 2023-11-15 12:45:00 +0100 | vpan | (~vpan@mail.elitnet.lt) (Ping timeout: 256 seconds) |
| 2023-11-15 12:46:06 +0100 | cstml | (~cstml@user/cstml) (Quit: WeeChat 2.3) |
| 2023-11-15 12:46:21 +0100 | cstml | (~cstml@user/cstml) |
| 2023-11-15 12:47:31 +0100 | <dminuoso> | I have a list of numbers [1,2,3,6,8,9,10] and I would like to work with all subsequent pairs. I dont care about the behavior on the edges (wrap around, drop one element), anything is fine here |
| 2023-11-15 12:48:05 +0100 | <dminuoso> | i.e. something like [1,2,6,7] -> [(1,2), (2,6), (6, 7)] |
| 2023-11-15 12:48:13 +0100 | <stefan-__> | zip xs (tail xs) ? |
| 2023-11-15 12:48:25 +0100 | <ncf> | > zip <$> id <*> tail $ [1,2,6,7] |
| 2023-11-15 12:48:27 +0100 | <lambdabot> | [(1,2),(2,6),(6,7)] |
| 2023-11-15 12:48:28 +0100 | <dminuoso> | Oh yes, works for me. :) |
| 2023-11-15 12:48:33 +0100 | <dminuoso> | Thanks, stefan-__. |
| 2023-11-15 12:48:38 +0100 | <stefan-__> | yw :) |
| 2023-11-15 12:49:08 +0100 | <[Leary]> | @quote aztec.god |
| 2023-11-15 12:49:08 +0100 | <lambdabot> | quicksilver says: zip`ap`tail - the Aztec god of consecutive numbers |
| 2023-11-15 12:49:59 +0100 | <ncf> | haha |
| 2023-11-15 12:52:15 +0100 | <ncf> | bwe: maybe you want ScraperT Either? |
| 2023-11-15 12:52:51 +0100 | <ncf> | (or ExceptT Scalpel) |
| 2023-11-15 12:53:05 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2023-11-15 12:53:11 +0100 | <bwe> | ncf: I feel so but haven't had any experience with Monad transformers yet. Is that a case for monad transformers? |
| 2023-11-15 12:53:24 +0100 | <ncf> | T is for transformer yes |
| 2023-11-15 12:54:00 +0100 | <cstml> | > mconcat $ (const "ha") <$> [1..3] |
| 2023-11-15 12:54:02 +0100 | <lambdabot> | "hahaha" |
| 2023-11-15 12:55:38 +0100 | <cstml> | > :t mconcat $ (const "ha") <$> [1..3] |
| 2023-11-15 12:55:39 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2023-11-15 12:55:48 +0100 | mauke | (~mauke@user/mauke) (Ping timeout: 240 seconds) |
| 2023-11-15 12:56:09 +0100 | <bwe> | ncf: what's the easiest way you could recommend to grasp Monad transformers? |
| 2023-11-15 12:56:45 +0100 | <ncf> | use them |
| 2023-11-15 12:56:52 +0100 | mauke | (~mauke@user/mauke) |
| 2023-11-15 12:57:15 +0100 | mechap | (~mechap@user/mechap) |
| 2023-11-15 12:57:55 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Remote host closed the connection) |
| 2023-11-15 12:58:39 +0100 | <dminuoso> | bwe: Invent them. |
| 2023-11-15 12:58:40 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 12:58:42 +0100 | chomwitt | (~chomwitt@ppp-94-67-217-242.home.otenet.gr) |
| 2023-11-15 12:59:15 +0100 | <bwe> | so, I understand them to connect two worlds, let's say contexts, is that right? |
| 2023-11-15 12:59:30 +0100 | <dminuoso> | bwe: Its best not to describe them in vague terms. |
| 2023-11-15 12:59:41 +0100 | <cstml> | bwe: use IdentityT. Then stack it. Then look at what it does. Then look at the code. |
| 2023-11-15 12:59:47 +0100 | <dminuoso> | Imagine a highly sophisticiated mathematician explaining stuff in abstract terms to a beginner. |
| 2023-11-15 12:59:50 +0100 | <dminuoso> | It just wont connect. |
| 2023-11-15 13:00:43 +0100 | <dminuoso> | The vague terms make sense for those that have achieved higher levels of understanding, but they are not good vehicles for learning |
| 2023-11-15 13:01:23 +0100 | <bwe> | dminuoso: You're right, I should go bottom-up, like cstml suggests. |
| 2023-11-15 13:02:00 +0100 | <cstml> | bwe: It helps understanding the trivial case, then taking that understanding and expanding. |
| 2023-11-15 13:02:11 +0100 | juri__ | (~juri@79.140.117.145) |
| 2023-11-15 13:02:50 +0100 | <dminuoso> | bwe: But the short intuition is really simple. `State` lets you do stateful computations, and `Either` lets you do computations with exceptions. |
| 2023-11-15 13:02:59 +0100 | <dminuoso> | Wouldn't it be great to have computations with both state and exceptions? |
| 2023-11-15 13:03:13 +0100 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 258 seconds) |
| 2023-11-15 13:03:18 +0100 | <dminuoso> | So that's the motivation that starts all of this. |
| 2023-11-15 13:04:18 +0100 | <cstml> | dminuoso: Both state and exceptions, or both exceptions and state? |
| 2023-11-15 13:04:26 +0100 | <dminuoso> | cstml: :) |
| 2023-11-15 13:04:36 +0100 | <dminuoso> | Ill leave that distinction as a lesson for another day. |
| 2023-11-15 13:04:49 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-15 13:04:50 +0100 | <cstml> | dminuoso: exercise left for the reader. |
| 2023-11-15 13:04:53 +0100 | <dminuoso> | Sure |
| 2023-11-15 13:04:55 +0100 | <cstml> | or ReaderT |
| 2023-11-15 13:04:57 +0100 | juri__ | (~juri@79.140.117.145) (Read error: Connection reset by peer) |
| 2023-11-15 13:05:21 +0100 | <dminuoso> | I think State and Either T/Maybe are better learning vehicles, because their effects are much more intuitive and obvious |
| 2023-11-15 13:06:51 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-15 13:07:11 +0100 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) |
| 2023-11-15 13:10:33 +0100 | tremon | (~tremon@83.80.159.219) |
| 2023-11-15 13:10:51 +0100 | actioninja7 | (~actioninj@user/actioninja) |
| 2023-11-15 13:11:57 +0100 | <bwe> | cstml: How can I go a step back from that trivial case? I am struggling to define the working base case of IdentityT. |
| 2023-11-15 13:12:28 +0100 | actioninja | (~actioninj@user/actioninja) (Ping timeout: 255 seconds) |
| 2023-11-15 13:12:28 +0100 | actioninja7 | actioninja |
| 2023-11-15 13:13:55 +0100 | larnee | (~gm@APN-123-243-222-gprs.simobil.net) |
| 2023-11-15 13:14:36 +0100 | <cstml> | bwe: have a look on hackage https://hackage.haskell.org/package/transformers-0.6.1.1/docs/src/Control.Monad.Trans.Identity.htm… |
| 2023-11-15 13:15:52 +0100 | <bwe> | it's basically a wrapper but what does it wrap? |
| 2023-11-15 13:20:23 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200D010BAADCC2D344F.dsl.pool.telekom.hu) |
| 2023-11-15 13:20:26 +0100 | <dminuoso> | bwe: rather than thinking about IdentityT, I would start by just handrolling State. |
| 2023-11-15 13:20:40 +0100 | <dminuoso> | And once you have done that, handroll Maybe. And once you have done that, write a custom monad that does both. |
| 2023-11-15 13:20:57 +0100 | <dminuoso> | The first transformer you would conceive is just a generalization of that custom monad. |
| 2023-11-15 13:24:03 +0100 | <dminuoso> | And the approach to do that, is after you have done state + maybe, start doing reader + maybe. And then perhaps IO + maybe. A pattern will emerge, and if you codify it, it will be named MaybeT. |
| 2023-11-15 13:24:49 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2023-11-15 13:24:51 +0100 | <dminuoso> | The motivation doesnt even become clear until you have realized that writing a custom newtype, slapping `Maybe` in the right spot every time, becomes cumbersome and silly - because it will always go into a particular spot. |
| 2023-11-15 13:25:04 +0100 | <dminuoso> | And the Monad instances will be mechanical |
| 2023-11-15 13:32:21 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Ping timeout: 246 seconds) |
| 2023-11-15 13:32:36 +0100 | larnee | (~gm@APN-123-243-222-gprs.simobil.net) (Quit: larnee) |
| 2023-11-15 13:34:18 +0100 | danse-nr3 | (~danse@151.43.223.187) (Ping timeout: 256 seconds) |
| 2023-11-15 13:34:59 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 13:36:05 +0100 | vpan | (~vpan@mail.elitnet.lt) |
| 2023-11-15 13:36:13 +0100 | vpan | (~vpan@mail.elitnet.lt) (Client Quit) |
| 2023-11-15 13:36:22 +0100 | vpan | (~vpan@mail.elitnet.lt) |
| 2023-11-15 13:36:29 +0100 | vpan | Guest5869 |
| 2023-11-15 13:36:38 +0100 | eso | (a0662dfd5e@2604:bf00:561:2000::1266) (Server closed connection) |
| 2023-11-15 13:36:49 +0100 | eso | (a0662dfd5e@2604:bf00:561:2000::1266) |
| 2023-11-15 13:37:01 +0100 | edr | (~edr@user/edr) |
| 2023-11-15 13:37:41 +0100 | Guest5869 | vpan |
| 2023-11-15 13:38:11 +0100 | chessai | (sid225296@id-225296.lymington.irccloud.com) (Server closed connection) |
| 2023-11-15 13:38:20 +0100 | chessai | (sid225296@id-225296.lymington.irccloud.com) |
| 2023-11-15 13:41:06 +0100 | larnee | (~gm@APN-123-243-222-gprs.simobil.net) |
| 2023-11-15 13:43:56 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Ping timeout: 256 seconds) |
| 2023-11-15 13:44:18 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 13:46:37 +0100 | xerox | (~edi@user/edi) (Server closed connection) |
| 2023-11-15 13:46:46 +0100 | xerox | (~edi@user/edi) |
| 2023-11-15 13:50:09 +0100 | larnee | (~gm@APN-123-243-222-gprs.simobil.net) (Remote host closed the connection) |
| 2023-11-15 13:53:35 +0100 | ialwaysC | (~ialwaysC@2409:40e5:2:da77:8000::) |
| 2023-11-15 13:55:37 +0100 | ialwaysC | (~ialwaysC@2409:40e5:2:da77:8000::) (Read error: Connection reset by peer) |
| 2023-11-15 13:55:49 +0100 | _73_ | (~anon_73@2600:4040:5205:d800:21e8:9777:49a5:db28) (Quit: Leaving) |
| 2023-11-15 13:56:03 +0100 | _73_ | (~anon_73@2600:4040:5205:d800:21e8:9777:49a5:db28) |
| 2023-11-15 14:02:46 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 268 seconds) |
| 2023-11-15 14:04:08 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 14:06:00 +0100 | falafel_ | (~falafel@62.175.113.194.dyn.user.ono.com) |
| 2023-11-15 14:09:15 +0100 | alp_ | (~alp@2001:861:5e02:eff0:acc6:6062:8e53:293f) (Ping timeout: 268 seconds) |
| 2023-11-15 14:09:21 +0100 | mechap | (~mechap@user/mechap) |
| 2023-11-15 14:11:22 +0100 | _73_ | (~anon_73@2600:4040:5205:d800:21e8:9777:49a5:db28) (Quit: Leaving) |
| 2023-11-15 14:12:21 +0100 | noctuks | (HNnDKbX6rY@user/noctux) (Server closed connection) |
| 2023-11-15 14:12:38 +0100 | danse-nr3 | (~danse@151.43.223.187) (Ping timeout: 268 seconds) |
| 2023-11-15 14:12:41 +0100 | noctuks | (ccm7rRIFr2@user/noctux) |
| 2023-11-15 14:12:50 +0100 | falafel_ | (~falafel@62.175.113.194.dyn.user.ono.com) (Ping timeout: 256 seconds) |
| 2023-11-15 14:17:14 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 14:18:43 +0100 | danse-nr3 | (~danse@151.43.223.187) (Remote host closed the connection) |
| 2023-11-15 14:19:07 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 14:19:36 +0100 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds) |
| 2023-11-15 14:20:09 +0100 | juri_ | (~juri@79.140.117.145) |
| 2023-11-15 14:20:46 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3141:d1c2:46a9:b11c) (Ping timeout: 256 seconds) |
| 2023-11-15 14:21:41 +0100 | juri_ | (~juri@79.140.117.145) (Read error: Connection reset by peer) |
| 2023-11-15 14:22:37 +0100 | xff0x | (~xff0x@178.255.149.135) |
| 2023-11-15 14:23:48 +0100 | danse-nr3 | (~danse@151.43.223.187) (Ping timeout: 246 seconds) |
| 2023-11-15 14:24:22 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2023-11-15 14:24:39 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Remote host closed the connection) |
| 2023-11-15 14:25:10 +0100 | juri_ | (~juri@84-19-175-187.pool.ovpn.com) |
| 2023-11-15 14:26:17 +0100 | danse-nr3 | (~danse@151.43.223.187) |
| 2023-11-15 14:28:46 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 14:31:51 +0100 | xff0x | (~xff0x@178.255.149.135) (Ping timeout: 246 seconds) |
| 2023-11-15 14:31:54 +0100 | danse-nr3 | (~danse@151.43.223.187) (Read error: Connection reset by peer) |
| 2023-11-15 14:32:34 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2023-11-15 14:32:39 +0100 | danse-nr3 | (~danse@151.57.219.68) |
| 2023-11-15 14:32:58 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-11-15 14:33:23 +0100 | CiaoSen | (~Jura@2a05:5800:289:5000:2a3a:4dff:fe84:dbd5) |
| 2023-11-15 14:33:55 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3141:d1c2:46a9:b11c) |
| 2023-11-15 14:34:24 +0100 | wagle | (~wagle@quassel.wagle.io) (Server closed connection) |
| 2023-11-15 14:34:40 +0100 | wagle | (~wagle@quassel.wagle.io) |
| 2023-11-15 14:35:30 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Ping timeout: 256 seconds) |
| 2023-11-15 14:36:16 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 14:36:23 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds) |
| 2023-11-15 14:40:58 +0100 | elkcl | (~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) |
| 2023-11-15 14:48:24 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1) |
| 2023-11-15 14:50:52 +0100 | <bwe> | dminuoso: building blocks in place: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 |
| 2023-11-15 14:51:50 +0100 | <dminuoso> | You have a rather curious indention style |
| 2023-11-15 14:52:35 +0100 | <bwe> | dminuoso: inconsistent, right? |
| 2023-11-15 14:53:15 +0100 | <dminuoso> | Hold on. What just happened. I alt tabbed, and suddenly it looks all different now. |
| 2023-11-15 14:55:01 +0100 | <bwe> | dminuoso: now, writing a custom monad that does both... I would start with a type signature that carries Maybee and State, right? How does that look like? I've no clue here. |
| 2023-11-15 14:55:45 +0100 | <dminuoso> | bwe: So its all a bit adhoc, I would now start writing some examples using those monads. |
| 2023-11-15 14:56:11 +0100 | <dminuoso> | Some stateful computation that may fail. |
| 2023-11-15 15:04:13 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200D010BAADCC2D344F.dsl.pool.telekom.hu) (Remote host closed the connection) |
| 2023-11-15 15:06:30 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200A8C1C5D762EA8C40.dsl.pool.telekom.hu) |
| 2023-11-15 15:10:23 +0100 | alp_ | (~alp@2001:861:5e02:eff0:e086:39d1:f48d:94d6) |
| 2023-11-15 15:11:13 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2023-11-15 15:17:01 +0100 | <ski> | bwe : (<*>) (State f) (State g) could be State f <*> State g and ditto for the other definitions of infix operators |
| 2023-11-15 15:17:56 +0100 | <ski> | i'd probably use `let'-`in', rather than `let' commands inside a `do' (that's not even monadic here), inside the definition of `>>=' |
| 2023-11-15 15:18:51 +0100 | <ski> | (and there's really no need to use `case' at the bottom, you could pattern-match in the parameters on the left-hand side of the definition, as with your other definitions) |
| 2023-11-15 15:19:05 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 15:19:23 +0100 | <ski> | (personally i'd also prefer seeing `Justt (f x)' over `Justt $ f x') |
| 2023-11-15 15:19:46 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2023-11-15 15:20:04 +0100 | <ski> | (oh, i guess the strange `do' is also in definition of `<*>') |
| 2023-11-15 15:21:22 +0100 | <ski> | right, also the outer brackets in `(State s (a -> b))' are redundant |
| 2023-11-15 15:23:22 +0100 | <bwe> | updated: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 |
| 2023-11-15 15:23:34 +0100 | <ski> | bwe : "I would start with a type signature that carries Maybee and State, right?" -- i suppose you perhaps actually meant "define a data type for a monad that both carries the ability to propagate state, and to fail", is that right ? |
| 2023-11-15 15:24:04 +0100 | <bwe> | I've incorporated ski's input and started to sketch out a login function that takes a state and some input |
| 2023-11-15 15:24:10 +0100 | <bwe> | ski: correct |
| 2023-11-15 15:24:10 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 268 seconds) |
| 2023-11-15 15:24:37 +0100 | <bwe> | I seem not to understand how to use the State I defined in an example application :( |
| 2023-11-15 15:24:41 +0100 | <ski> | ah, the brackets in `(Justt f) <*> (Justt x)' are still redundant |
| 2023-11-15 15:25:22 +0100 | <ski> | (and `>>=' for `Maybee' can also be defined infix (and you forgot a little something, there)) |
| 2023-11-15 15:26:40 +0100 | thegeekinside | (~thegeekin@189.141.80.123) |
| 2023-11-15 15:26:59 +0100 | <ski> | (heh, and did didn't touch `(<*>) (State f) (State g)' (instead `(<*>) (Justt f) (Justt x)', where the same point applied), actually) |
| 2023-11-15 15:27:35 +0100 | pavonia | (~user@user/siracusa) |
| 2023-11-15 15:27:51 +0100 | benjaminedwardwe | (~benjamine@ool-45707daf.dyn.optonline.net) |
| 2023-11-15 15:28:10 +0100 | <ski> | is `validLogin' supposed to throw away the password ? |
| 2023-11-15 15:28:46 +0100 | <bwe> | ski: yes, it's just a dummy |
| 2023-11-15 15:28:59 +0100 | <bwe> | but actually, we can propagate it |
| 2023-11-15 15:29:24 +0100 | Hooloovoo | (~Hooloovoo@hax0rbana.org) (Ping timeout: 240 seconds) |
| 2023-11-15 15:29:46 +0100 | <ski> | ok |
| 2023-11-15 15:30:25 +0100 | <ski> | is the `Maybe' in `login' intended to express that your computation could possibly fail ? |
| 2023-11-15 15:30:41 +0100 | <ski> | (s/did didn't/you didn't/) |
| 2023-11-15 15:31:36 +0100 | CiaoSen | (~Jura@2a05:5800:289:5000:2a3a:4dff:fe84:dbd5) (Ping timeout: 256 seconds) |
| 2023-11-15 15:31:52 +0100 | <ski> | also not quite sure why `login' is taking a state action as an input |
| 2023-11-15 15:32:02 +0100 | <bwe> | updated: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 |
| 2023-11-15 15:32:47 +0100 | <bwe> | ski: well, I am trying to come up with some example function that is stateful and can fail |
| 2023-11-15 15:33:21 +0100 | <bwe> | but not sure here how to approach it - I assume the it takes state as an input, right? |
| 2023-11-15 15:33:43 +0100 | <bwe> | or would it just be LoginStatus in my case? |
| 2023-11-15 15:33:55 +0100 | <ski> | (still `(>>=) (State g) f' left. obvviously, if you really prefer defining infix operators prefix, you can do so. although it tends to be nice with consistency, unless there's some reason one wants to do it differently in some case) |
| 2023-11-15 15:34:40 +0100 | <ski> | "trying to come up with some example function that is stateful and can fail" -- right |
| 2023-11-15 15:35:00 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2023-11-15 15:35:10 +0100 | <bwe> | updated: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 |
| 2023-11-15 15:35:51 +0100 | <ski> | "I assume the it takes state as an input, right?" -- `login' will be given an input state (of type `Maybe (String,String)' in your case), *implicitly*, yes. this `s' parameter of yours is not that input state, it's a callback action. that may or may not be reasonable here, i don't know |
| 2023-11-15 15:35:52 +0100 | euleritian | (~euleritia@x52717980.dyn.telefonica.de) |
| 2023-11-15 15:36:49 +0100 | <ski> | perhaps `login' wants to first login, and only then (if that succeeds), run the callback action (and then perhaps do something more after that) |
| 2023-11-15 15:37:23 +0100 | <bwe> | I have come up with an unclear function intention. |
| 2023-11-15 15:37:30 +0100 | <ski> | or, perhaps instead, whoever is going to call `login' could instead directly perform the code that would have been in the callback, *after* `login' (successfully) finishes (in the case there was nothing more to do after it in `login') |
| 2023-11-15 15:38:10 +0100 | <bwe> | which example function would you like me to write instead? |
| 2023-11-15 15:38:40 +0100 | <ski> | however, it *looks* like, to me, that the `LoginStatus' that you intend to `case' on in `login' is what your current callback is supposed to give as result, is that so ? |
| 2023-11-15 15:38:53 +0100 | <bwe> | "trying to come up with some example function that is stateful and can fail" -- right -- so using Maybee and State |
| 2023-11-15 15:40:18 +0100 | <ski> | well .. perhaps it could be more suitable to use `State (String,String) (Maybe LoginStatus)' rather than `State (Maybe (String,String)) LoginStatus' |
| 2023-11-15 15:40:39 +0100 | <ski> | "which example function would you like me to write instead?" -- sorry, i'm not quite clear about that (since i'm not quite clear of what's your aim) |
| 2023-11-15 15:41:20 +0100 | <bwe> | ski: trying to create a situation where I stumble over the need to write a Monad transformer, so a Monad that handles both Maybee and State! |
| 2023-11-15 15:41:51 +0100 | <ski> | i assume you mean, a monad that handles both failure and state-threading/passing |
| 2023-11-15 15:42:12 +0100 | <ski> | (do note that you have *not* defined such a monad, yet) |
| 2023-11-15 15:42:36 +0100 | cods | (~fred@tuxee.net) (Server closed connection) |
| 2023-11-15 15:42:49 +0100 | cods | (~fred@tuxee.net) |
| 2023-11-15 15:42:54 +0100 | <bwe> | dminuoso: here? |
| 2023-11-15 15:43:03 +0100 | <ski> | (but going down alleys and deadends can be quite edifying, too) |
| 2023-11-15 15:44:19 +0100 | <ski> | e.g. it's useful to understand the difference between (your current) `State (Maybe (String,String)) LoginStatus', and the `State (String,String) (Maybe LoginStatus)' i mentioned, and the third alternative i just hinted at |
| 2023-11-15 15:45:55 +0100 | <bwe> | well, I am trying to understand the concept of State here, still |
| 2023-11-15 15:46:23 +0100 | <bwe> | since I don't I mess it up, nor can I conceive a sensible type signature |
| 2023-11-15 15:46:37 +0100 | <ski> | anyway .. since you switched from `String' to `(String,String)' in the signature for `login', when you did the same for the (possible) result in `validLogin', i'm presuming that the `(String,String)' (which is in the state that's implicitly carried around) in `login' are supposed to be the user and password, is that right ? |
| 2023-11-15 15:47:19 +0100 | <bwe> | ski: and yes, dminuoso asked me to write some stateful function that can fail -- to realise the need to write a custom monad for state and Maybee |
| 2023-11-15 15:47:20 +0100 | qhong | (~qhong@DN160vrd000d6kpg009l6c0000fj.stanford.edu) (Read error: Connection reset by peer) |
| 2023-11-15 15:47:30 +0100 | qhong | (~qhong@rescomp-21-400677.stanford.edu) |
| 2023-11-15 15:47:48 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 246 seconds) |
| 2023-11-15 15:48:02 +0100 | vilya | (~vilya@user/vilya) (Ping timeout: 256 seconds) |
| 2023-11-15 15:48:15 +0100 | <ski> | yes, it's good advice, to get more concrete, to understand the ramifications of your probably initially rather vaguely grasped monad definitions (vague in how they're to be applied in practice) |
| 2023-11-15 15:48:48 +0100 | <bwe> | ski: yes, but again, I first would like to understand the State thing and don't want to waste our time with a badly defined function (due to not understood State) |
| 2023-11-15 15:49:05 +0100 | <ski> | well, okay |
| 2023-11-15 15:49:17 +0100 | <bwe> | so, why does State carry a result of a function and not only the state? |
| 2023-11-15 15:49:41 +0100 | <ski> | i was thinking maybe you already had decided you understood basic `State' (as you've defined it) well, and now wanted to tackle the combination of state and failure |
| 2023-11-15 15:49:43 +0100 | vilya | (~vilya@user/vilya) |
| 2023-11-15 15:50:10 +0100 | <ski> | i'm assuming you're asking why the `a' in `State s a', and not just `s' ? |
| 2023-11-15 15:50:16 +0100 | <bwe> | correct |
| 2023-11-15 15:50:23 +0100 | <ski> | it's a good question |
| 2023-11-15 15:50:53 +0100 | aljazmc | (~aljazmc@user/aljazmc) |
| 2023-11-15 15:51:00 +0100 | bwe | *sighs* |
| 2023-11-15 15:51:26 +0100 | danse-nr3 | (~danse@151.57.219.68) (Ping timeout: 256 seconds) |
| 2023-11-15 15:51:28 +0100 | <bwe> | it's because of using Monad Transformers? |
| 2023-11-15 15:51:33 +0100 | <ski> | no |
| 2023-11-15 15:51:39 +0100 | <ski> | it's simpler than that |
| 2023-11-15 15:51:45 +0100 | zero | listens |
| 2023-11-15 15:51:47 +0100 | <ski> | okay, so are you familiar with binary trees ? |
| 2023-11-15 15:52:22 +0100 | <ski> | could you e.g. define a data type of binary trees, with elements in the internal nodes, but not in the leaves ? |
| 2023-11-15 15:52:43 +0100 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) (Ping timeout: 264 seconds) |
| 2023-11-15 15:52:50 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-15 15:53:01 +0100 | <ski> | (monad transformers is a bit more advanced that what i think you need to be worrying about tackling here) |
| 2023-11-15 15:53:01 +0100 | <bwe> | you mentioned it'd be simpler? |
| 2023-11-15 15:53:20 +0100 | <ski> | yea, the issue is about the state monad (and monads in general) |
| 2023-11-15 15:53:50 +0100 | <ski> | i have an example in mind, pertaining to binary trees, that might help you see the point better |
| 2023-11-15 15:53:57 +0100 | <ski> | if you're willing to try it ? |
| 2023-11-15 15:54:00 +0100 | zero | ... https://yewtu.be/watch?v=WYysg5Nf7AU |
| 2023-11-15 15:54:23 +0100 | <bwe> | ski: binary tree: each node at max two children, that's what I've got |
| 2023-11-15 15:54:41 +0100 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) |
| 2023-11-15 15:54:47 +0100 | mechap | (~mechap@user/mechap) |
| 2023-11-15 15:55:17 +0100 | akegalj | (~akegalj@141-136-147-15.dsl.iskon.hr) |
| 2023-11-15 15:55:21 +0100 | <ski> | (i mean .. i *could* just try to write a succinct answer for why the `a' .. but i'm not sure how helpful that would be, how easy it would be to understand. i'm thinking it would be more useful to gain some understanding, through an example. but if you really wish, i could try to give a short explanation) |
| 2023-11-15 15:55:52 +0100 | <bwe> | ski: either a node has children (1 or 2) or it carries a value, correct? |
| 2023-11-15 15:56:12 +0100 | <ski> | well, the `1' case is unnecessary. you could just have one of the two children be the empty tree |
| 2023-11-15 15:57:02 +0100 | <zero> | could we make a parallel with IO to show how parameterizing 'a' is useful? |
| 2023-11-15 15:57:08 +0100 | <ski> | so, an internal node always carries a value, and has two child trees. a tree can also be a leaf which in this case carries no value (so is an empty tree) |
| 2023-11-15 15:57:51 +0100 | <ski> | zero : i'm not sure at all to which extent bwe understands (even at a very basic practical level "how to use" to do simple I/O) `IO' |
| 2023-11-15 15:58:15 +0100 | <zero> | ski: ah ok. i just got here. shutting up now and listening as i'm interested in your example |
| 2023-11-15 16:01:04 +0100 | <bwe> | data Node a = Node (Node a) (Node a) | Leaf a -- something like this? |
| 2023-11-15 16:01:05 +0100 | <bwe> | zero: Let me watch that later. thanks for sharing it with me. |
| 2023-11-15 16:01:05 +0100 | dminuoso | (~dminuoso@user/dminuoso) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-15 16:01:05 +0100 | TMA | (tma@twin.jikos.cz) (Ping timeout: 245 seconds) |
| 2023-11-15 16:01:06 +0100 | <ski> | (btw, i said "with elements in the internal nodes", so no elements at the leaves) |
| 2023-11-15 16:01:45 +0100 | TMA | (tma@twin.jikos.cz) |
| 2023-11-15 16:01:57 +0100 | dminuoso | (~dminuoso@user/dminuoso) |
| 2023-11-15 16:02:01 +0100 | dontdieych_ | (~alarm@132.226.169.184) (Ping timeout: 245 seconds) |
| 2023-11-15 16:02:01 +0100 | <bwe> | ski: data Tree a = Node (Tree a) (Tree a) | Leaf |
| 2023-11-15 16:02:17 +0100 | <ski> | you'd need to put the `a' in the other alternative, in that case |
| 2023-11-15 16:02:47 +0100 | <ski> | well, i guess it works either way, not too much of a difference. do put the elements either in the binary node case (internal nodes), or in the nullary node case (leaves) |
| 2023-11-15 16:02:55 +0100 | <ski> | (whichever you prefer) |
| 2023-11-15 16:03:15 +0100 | dontdieych_ | (~alarm@132.226.169.184) |
| 2023-11-15 16:04:09 +0100 | <ski> | (if one's doing binary search trees, one do want the elements in the internal nodes. but we don't really need that here, it's just the shape of tree i first had in mind. but it doesn't matter for my example, really) |
| 2023-11-15 16:05:04 +0100 | <bwe> | ski: pls write what you specifically mean with internal nodes |
| 2023-11-15 16:05:09 +0100 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2023-11-15 16:05:33 +0100 | <ski> | oh, your `Node' alternative above is the "internal node" case (because that's the case that has child trees) |
| 2023-11-15 16:05:46 +0100 | <ski> | so, i'm suggesting either |
| 2023-11-15 16:06:02 +0100 | <ski> | data Tree a = Leaf a | Node (Tree a) (Tree a) |
| 2023-11-15 16:06:06 +0100 | <bwe> | ski: I've removed the a from the Leaf, therefore the Leaf is no more carrying a value |
| 2023-11-15 16:06:09 +0100 | <ski> | as you initially gave above |
| 2023-11-15 16:06:11 +0100 | <ski> | or else |
| 2023-11-15 16:06:20 +0100 | <ski> | data Tree a = Leaf | Node a (Tree a) (Tree a) |
| 2023-11-15 16:06:52 +0100 | <bwe> | oh, that Node is also carrying a value! not only its children! |
| 2023-11-15 16:06:54 +0100 | <bwe> | got that |
| 2023-11-15 16:06:56 +0100 | <bwe> | check |
| 2023-11-15 16:06:57 +0100 | <ski> | (but `data Tree a = Node (Tree a) (Tree a) | Leaf' is no good, since now there's no `a' elements at all in the tree) |
| 2023-11-15 16:07:06 +0100 | <bwe> | true |
| 2023-11-15 16:07:13 +0100 | <ski> | ok |
| 2023-11-15 16:07:13 +0100 | <bwe> | now it's obvious |
| 2023-11-15 16:07:44 +0100 | <ski> | so, now the task is : write a function that labels each element in the tree with an integer, counting from `0' upwards |
| 2023-11-15 16:07:58 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2023-11-15 16:08:07 +0100 | <ski> | iow, replace the `i'th element `x' with `(i,x)' |
| 2023-11-15 16:09:01 +0100 | <bwe> | so I need some state that is propagated and incremented each time we access some Tree a element |
| 2023-11-15 16:09:19 +0100 | <bwe> | Counter -> Tree -> (Counter, Tree) |
| 2023-11-15 16:09:23 +0100 | <bwe> | something like that |
| 2023-11-15 16:09:41 +0100 | <ski> | so `Node 2 (Node 3 Leaf Leaf) (Node 5 (Node 7 Leaf Leaf) Leaf)' should get turned into `Node (0,2) (Node (1,3) Leaf Leaf) (Node (2,5) (Node (3,7) Leaf Leaf) Leaf)' |
| 2023-11-15 16:09:44 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2023-11-15 16:09:58 +0100 | <ski> | yea, we can take `Counter' to be `Integer' or `Int', for concreteness sake |
| 2023-11-15 16:10:18 +0100 | <ski> | (but you also need to provide the type parameter to `Tree' there) |
| 2023-11-15 16:10:50 +0100 | <ski> | the function shouldn't care about what the `x' elements in the tree are, so the input tree should have type `Tree a', so it works for any element type `a' |
| 2023-11-15 16:10:57 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Quit: Leaving) |
| 2023-11-15 16:11:24 +0100 | aljazmc | (~aljazmc@user/aljazmc) |
| 2023-11-15 16:11:33 +0100 | <bwe> | we don't do anything on a Leaf, right? |
| 2023-11-15 16:11:37 +0100 | <ski> | "so I need some state that is propagated and incremented each time we access some Tree a element" -- exactly. and i'd say it's good to solve this, both directly, and solve it using `State', to compare and contrast |
| 2023-11-15 16:11:54 +0100 | <ski> | right, no elements in a leaf, so nothing to update there |
| 2023-11-15 16:14:04 +0100 | sabino | (~sabino@user/sabino) |
| 2023-11-15 16:14:14 +0100 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) (Remote host closed the connection) |
| 2023-11-15 16:14:57 +0100 | <bwe> | enumerateTree n (Node a b c) = (_, Node (n+1) b c) |
| 2023-11-15 16:15:09 +0100 | <ski> | (i guess i'd typically go for the naming `data Tree a = Leaf a | Branch (Tree a) (Tree a)' for the elements-at-leaves case, and `data Tree a = Empty | Node a (Tree a) (Tree a)' (or `Nil' or `Tip' instead of `Empty') for the internal-elements case .. but that doesn't really matter. you're fine as you are) |
| 2023-11-15 16:15:17 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-11-15 16:15:20 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-11-15 16:15:32 +0100 | <ski> | bwe : yea, you need some recursion going there, somehow |
| 2023-11-15 16:15:56 +0100 | zero | thinks haskell has the most elegant code for tree traversals |
| 2023-11-15 16:16:07 +0100 | <ski> | for a `Node x l r', you need to traverse the two subtrees `l' and `r', labelling their elements (and getting back the updated counter) |
| 2023-11-15 16:16:38 +0100 | <bwe> | ski: |
| 2023-11-15 16:16:50 +0100 | danse-nr3 | (~danse@151.57.219.68) |
| 2023-11-15 16:16:50 +0100 | <bwe> | ski: so I do the children first? |
| 2023-11-15 16:17:44 +0100 | haskellbridge | (~haskellbr@069-135-003-034.biz.spectrum.com) |
| 2023-11-15 16:17:44 +0100 | ChanServ | +v haskellbridge |
| 2023-11-15 16:18:20 +0100 | <sshine> | zero, it's definitely easier to traverse trees when you're allowed to assume they exist indefinitely in memory. :-D |
| 2023-11-15 16:18:25 +0100 | <ski> | well, you need to pick some traversal order in which to visit the elements. for internal-element trees, the typical orderings would be preorder, inorder, and postorder (all three of those are depth-first). it'd also be possible to do breath-first ordering (walking through level after level), but that's more involved. i was thinking depth-first (which is what a simple recursion will give you) |
| 2023-11-15 16:18:49 +0100 | <ski> | and since we have `Node x l r', why not label first `x', then elements in `l', then elements in `r' ? (that'd be preorder) |
| 2023-11-15 16:19:05 +0100 | <sshine> | zero, (a comment about how ADTs in Rust are pretty great except when you want to pattern match across Box<T>s.) |
| 2023-11-15 16:19:17 +0100 | <ski> | (inorder would be : first `l', then `x', then `r'. postorder is : first `l', then `r', and finally `x') |
| 2023-11-15 16:20:16 +0100 | <ski> | .. it doesn't really matter which alternative you pick, as long as you realize there's a choice, and you know which alternative you're picking (and that you're sticking consistently to it, of course) |
| 2023-11-15 16:20:36 +0100 | lhpitn | (~tn@mail.lebenshilfe-pi.de) (Ping timeout: 268 seconds) |
| 2023-11-15 16:21:27 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) |
| 2023-11-15 16:22:06 +0100 | <ski> | (the example input->output i gave above was preorder too, btw) |
| 2023-11-15 16:24:20 +0100 | absence | (torgeihe@hildring.pvv.ntnu.no) |
| 2023-11-15 16:25:56 +0100 | <bwe> | ski: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L49-L55 -- promising: it compiles (for the Tree part) |
| 2023-11-15 16:26:13 +0100 | <bwe> | ski: I need a break. are you here around in 2 hrs? |
| 2023-11-15 16:28:08 +0100 | <ski> | bwe : yea, that looks about right |
| 2023-11-15 16:28:16 +0100 | <ski> | you're doing postorder, not preorder. but that's fine |
| 2023-11-15 16:28:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-15 16:28:49 +0100 | <ski> | (so you'll not get the exact same result as i suggested in my example input->output mapping) |
| 2023-11-15 16:28:50 +0100 | <zero> | sshine: i'm talking about this kind of poetry: https://paste.jrvieira.com/1700062115929 |
| 2023-11-15 16:28:57 +0100 | <ski> | bwe : and yes |
| 2023-11-15 16:29:01 +0100 | <absence> | If I want to have multiple threads send messages to a queue, and have a pool of workers process those messages, is there a library I can use to set that up? I can implement it myself with TBQueue from stm or something, but a battle tested library would be nice. Just not sure what this concept is called, so I'm not sure what to search for. |
| 2023-11-15 16:29:25 +0100 | <bwe> | ski: great. thank you until here. I'll ping you then, ok? |
| 2023-11-15 16:30:16 +0100 | <ski> | (oh, you're also using preincrement, rather than postincrement. so if `n' is `0' initially, you'll still start labelling at `1'. that's not a problem, as long as you're aware that that's what you're doing |
| 2023-11-15 16:30:18 +0100 | ystael | (~ystael@user/ystael) |
| 2023-11-15 16:30:21 +0100 | <ski> | ) |
| 2023-11-15 16:30:21 +0100 | <ski> | sure |
| 2023-11-15 16:31:11 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) (Ping timeout: 245 seconds) |
| 2023-11-15 16:32:40 +0100 | <ski> | zero : good old difference lists / list accumulator :) |
| 2023-11-15 16:33:14 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Ping timeout: 268 seconds) |
| 2023-11-15 16:33:33 +0100 | alp_ | (~alp@2001:861:5e02:eff0:e086:39d1:f48d:94d6) (Ping timeout: 268 seconds) |
| 2023-11-15 16:34:20 +0100 | <zero> | ski: i have this snippet in a collection of 'beautiful code' snippets i keep :) |
| 2023-11-15 16:34:46 +0100 | <ski> | (: |
| 2023-11-15 16:35:32 +0100 | benjaminedwardwe | (~benjamine@ool-45707daf.dyn.optonline.net) (Ping timeout: 250 seconds) |
| 2023-11-15 16:40:56 +0100 | vpan | (~vpan@mail.elitnet.lt) (Quit: Leaving.) |
| 2023-11-15 16:40:56 +0100 | <zero> | heres another one in haskell: https://paste.jrvieira.com/1700062849674 |
| 2023-11-15 16:43:10 +0100 | <cstml> | bwe: IdentityT does nothing. That's basically the point - it's a transformer that simply wraps a monad. All you can do with it is wrap/unwrap it. |
| 2023-11-15 16:44:06 +0100 | <cstml> | It wraps a Monad, just like Identity wraps a Type. |
| 2023-11-15 16:46:54 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-11-15 16:46:55 +0100 | <cstml> | StateT wraps a Monad and adds the methods of the State Monad to it. Then to unwrap out of it, you need to provide it with the initial state, etc. |
| 2023-11-15 16:47:27 +0100 | zero | ... https://hackage.haskell.org/package/base-4.19.0.0/docs/Data-Tuple.html |
| 2023-11-15 16:47:50 +0100 | gm | (~gm@cpe-46-164-2-67.dynamic.amis.net) |
| 2023-11-15 16:55:49 +0100 | <EvanR> | IdentityT is the monad transformer which yields a monad with nothing different |
| 2023-11-15 16:58:52 +0100 | <cstml> | the only thing that is different is that in order to work with the transformed/wrapped monad is that you now have to `lift` to it. |
| 2023-11-15 16:59:24 +0100 | <EvanR> | which is the case for any MonadTrans |
| 2023-11-15 16:59:59 +0100 | <EvanR> | we usually think of monad transformers as "adding abilities". Can they remove abilities? |
| 2023-11-15 17:01:04 +0100 | <EvanR> | or is that impossible due to parametricity |
| 2023-11-15 17:02:49 +0100 | absence | (torgeihe@hildring.pvv.ntnu.no) (Quit: leaving) |
| 2023-11-15 17:03:43 +0100 | absence | (torgeihe@hildring.pvv.ntnu.no) |
| 2023-11-15 17:04:25 +0100 | <ski> | zero : second doesn't include empty subset ? |
| 2023-11-15 17:05:25 +0100 | <ski> | .. is there a point to suggesting `IdentityT' above, rather than `Identity' ? |
| 2023-11-15 17:05:33 +0100 | <c_wraith> | EvanR: well, if they implement lift lawfully, they can't remove abilities. |
| 2023-11-15 17:05:33 +0100 | <ncf> | newtype VoidT m a = VoidT -- is this a lawful transformer? |
| 2023-11-15 17:06:25 +0100 | <geekosaur> | (what's its `lift`?) |
| 2023-11-15 17:06:30 +0100 | <EvanR> | what is return? |
| 2023-11-15 17:06:41 +0100 | <ncf> | everything is the unique function to the unit type |
| 2023-11-15 17:06:44 +0100 | <ski> | const VoidT |
| 2023-11-15 17:07:37 +0100 | <EvanR> | alright then |
| 2023-11-15 17:07:43 +0100 | <c_wraith> | Hmm. I suppose the MonadTrans laws don't forbid the empty transformer |
| 2023-11-15 17:07:56 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) |
| 2023-11-15 17:08:15 +0100 | euleritian | (~euleritia@x52717980.dyn.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 17:08:32 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 17:09:56 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-11-15 17:10:36 +0100 | <cstml> | bwe: check this example out. https://play.haskell.org/saved/dGZnby3d |
| 2023-11-15 17:11:59 +0100 | <cstml> | I'd hazard myself and say: it's as simple as that ^. But yeah, hope it gets the intuition across. |
| 2023-11-15 17:15:24 +0100 | <EvanR> | also data VoidT m a -- no constructors -- |
| 2023-11-15 17:17:08 +0100 | <ski> | well, `return's not total |
| 2023-11-15 17:18:38 +0100 | gm_ | (~gm@cpe-46-164-2-67.dynamic.amis.net) |
| 2023-11-15 17:18:54 +0100 | <EvanR> | ah, the total subset of haskell xD |
| 2023-11-15 17:20:09 +0100 | gm | (~gm@cpe-46-164-2-67.dynamic.amis.net) (Read error: Connection reset by peer) |
| 2023-11-15 17:20:09 +0100 | gm_ | gm |
| 2023-11-15 17:20:11 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:93f2:661e:d61:f6f4) (Quit: WeeChat 3.5) |
| 2023-11-15 17:20:59 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-15 17:22:00 +0100 | <monochrom> | You can always try ProxyT instead. Almost as good. :) |
| 2023-11-15 17:23:31 +0100 | <monochrom> | Informtation theoretically, empty information does not mean empty set, instead singleton set. |
| 2023-11-15 17:24:25 +0100 | mvk | (~mvk@2607:fea8:5c9a:a600::900d) |
| 2023-11-15 17:24:33 +0100 | mvk | (~mvk@2607:fea8:5c9a:a600::900d) (Client Quit) |
| 2023-11-15 17:25:28 +0100 | <ski> | > logBase 2 0 |
| 2023-11-15 17:25:29 +0100 | <lambdabot> | -Infinity |
| 2023-11-15 17:26:19 +0100 | <ncf> | trick i got from conor: Const 0 is a functor but not an applicative, Const 2 is an applicative but not a monad, Const 1 is a monad |
| 2023-11-15 17:26:53 +0100 | <monochrom> | That is beautiful. :) |
| 2023-11-15 17:30:50 +0100 | Square | (~Square@user/square) |
| 2023-11-15 17:32:55 +0100 | gm | (~gm@cpe-46-164-2-67.dynamic.amis.net) (Quit: gm) |
| 2023-11-15 17:33:11 +0100 | gm | (~gm@cpe-46-164-2-67.dynamic.amis.net) |
| 2023-11-15 17:33:26 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 256 seconds) |
| 2023-11-15 17:33:27 +0100 | Inst | (~Inst@120.244.192.250) (Leaving) |
| 2023-11-15 17:33:55 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2023-11-15 17:36:32 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-15 17:40:36 +0100 | <EvanR> | and Const 3? |
| 2023-11-15 17:40:51 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-11-15 17:42:16 +0100 | <ncf> | Const n with n ≥ 2 is an applicative but not a monad |
| 2023-11-15 17:42:55 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 268 seconds) |
| 2023-11-15 17:43:17 +0100 | <EvanR> | uniquely? |
| 2023-11-15 17:43:22 +0100 | <dolio> | No. |
| 2023-11-15 17:43:51 +0100 | <ncf> | applicatives correspond to monoid structures on Fin n |
| 2023-11-15 17:44:12 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) (Ping timeout: 256 seconds) |
| 2023-11-15 17:44:19 +0100 | tango88 | (~tango88@45.129.56.151) |
| 2023-11-15 17:50:17 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) |
| 2023-11-15 17:52:18 +0100 | gm | (~gm@cpe-46-164-2-67.dynamic.amis.net) (Quit: gm) |
| 2023-11-15 17:52:48 +0100 | Pozyomka | (~pyon@user/pyon) (Server closed connection) |
| 2023-11-15 17:53:07 +0100 | Pozyomka | (~pyon@user/pyon) |
| 2023-11-15 17:54:00 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-11-15 17:54:59 +0100 | johnw | (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in) |
| 2023-11-15 17:57:37 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2023-11-15 18:02:44 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2023-11-15 18:04:51 +0100 | alp_ | (~alp@2001:861:5e02:eff0:2593:ef1a:f448:eef7) |
| 2023-11-15 18:08:29 +0100 | rosco | (~rosco@175.136.157.149) (Quit: Lost terminal) |
| 2023-11-15 18:10:54 +0100 | <danse-nr3> | someone mentioned "chordify" in haskell cafe', but i did not find any haskell project with that name. Is that a company running haskell? |
| 2023-11-15 18:16:03 +0100 | <danse-nr3> | i think it's fair to add a link ... https://mail.haskell.org/pipermail/haskell-cafe/2023-November/136443.html |
| 2023-11-15 18:17:27 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) (Ping timeout: 268 seconds) |
| 2023-11-15 18:19:19 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.0) |
| 2023-11-15 18:22:17 +0100 | thegman | (~thegman@072-239-207-086.res.spectrum.com) |
| 2023-11-15 18:22:41 +0100 | <EvanR> | choridy - instance chords for any song |
| 2023-11-15 18:22:49 +0100 | <EvanR> | man |
| 2023-11-15 18:22:52 +0100 | <EvanR> | chordify |
| 2023-11-15 18:23:13 +0100 | <danse-nr3> | oh nice, i will took that up. Thanks! |
| 2023-11-15 18:25:39 +0100 | <danse-nr3> | huh ... this one chordify.net ? |
| 2023-11-15 18:26:29 +0100 | VioletJewel | (~violet@user/violetjewel) (Server closed connection) |
| 2023-11-15 18:26:42 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 246 seconds) |
| 2023-11-15 18:26:43 +0100 | VioletJewel | (violet@user/violetjewel) |
| 2023-11-15 18:27:35 +0100 | euleritian | (~euleritia@x52717980.dyn.telefonica.de) |
| 2023-11-15 18:30:18 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 18:31:21 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800::302a) (Quit: Leaving) |
| 2023-11-15 18:32:35 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) |
| 2023-11-15 18:34:40 +0100 | danse-nr3 | (~danse@151.57.219.68) (Read error: Connection reset by peer) |
| 2023-11-15 18:35:32 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Remote host closed the connection) |
| 2023-11-15 18:35:35 +0100 | danse-nr3 | (~danse@151.43.130.136) |
| 2023-11-15 18:35:46 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 18:40:28 +0100 | ec_ | ec |
| 2023-11-15 18:41:16 +0100 | <EvanR> | danse-nr3, looks like they use haskell somehow https://www.reddit.com/r/haskell/comments/q6q4zr/job_haskell_developer_chordify/ |
| 2023-11-15 18:42:53 +0100 | <danse-nr3> | oh i see, there is also github.com/chordify. Thanks |
| 2023-11-15 18:45:23 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 18:50:30 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 256 seconds) |
| 2023-11-15 18:51:02 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-11-15 18:51:41 +0100 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-11-15 18:54:33 +0100 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-11-15 18:59:03 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-11-15 19:00:08 +0100 | alp_ | (~alp@2001:861:5e02:eff0:2593:ef1a:f448:eef7) (Ping timeout: 256 seconds) |
| 2023-11-15 19:01:31 +0100 | telser | (~quassel@user/telser) |
| 2023-11-15 19:02:47 +0100 | johnw | (~johnw@69.62.242.138) |
| 2023-11-15 19:05:32 +0100 | euleritian | (~euleritia@x52717980.dyn.telefonica.de) (Read error: Connection reset by peer) |
| 2023-11-15 19:05:51 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2023-11-15 19:12:06 +0100 | <bwe> | ski: ping |
| 2023-11-15 19:12:44 +0100 | <ski> | syn |
| 2023-11-15 19:13:33 +0100 | <bwe> | ski: latest version is https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 -- I've incorporated your comments |
| 2023-11-15 19:14:28 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) |
| 2023-11-15 19:14:48 +0100 | <bwe> | ski: where were we? why were we building the Tree example? it was about propagating the State through the function, as input through to output |
| 2023-11-15 19:14:59 +0100 | <bwe> | nice example that Tree, btw |
| 2023-11-15 19:15:30 +0100 | <bwe> | cstml: I've seen your piece and will consult it later, as of now thanks. |
| 2023-11-15 19:16:16 +0100 | <tango88> | hi. i was wondering if `data A = A!Int` is valid grammatically and if so, why doesn't GHC accept it? |
| 2023-11-15 19:17:00 +0100 | <cstml> | bwe: no worries - hope "you get it". |
| 2023-11-15 19:17:14 +0100 | <ski> | bwe : oh, you've actually introduced a bug now, as compared to the last version of `enumerateTree' |
| 2023-11-15 19:17:37 +0100 | <bwe> | ski: I should have sticked with the good-enough version :) |
| 2023-11-15 19:17:45 +0100 | <bwe> | cstml: thanks for your faith! |
| 2023-11-15 19:18:02 +0100 | <ski> | tango88 : works here |
| 2023-11-15 19:18:18 +0100 | <ski> | bwe : can you identify the bug ? |
| 2023-11-15 19:18:44 +0100 | <ski> | @let data A = A!Int |
| 2023-11-15 19:18:46 +0100 | <lambdabot> | Defined. |
| 2023-11-15 19:18:56 +0100 | <ski> | > case A undefined of A _ -> () |
| 2023-11-15 19:18:59 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-15 19:19:15 +0100 | <cstml> | bwe: keep at it - it's really not as hard as it might seem. I have faith. |
| 2023-11-15 19:22:58 +0100 | <ski> | (bwe : i could give hints, if you want any. but perhaps you'd first like to try and see if you can identify a problem, and then perhaps what is causing it) |
| 2023-11-15 19:23:19 +0100 | <bwe> | ski: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L58 |
| 2023-11-15 19:23:55 +0100 | <bwe> | if I label sth. with an incremented number, the state should incorporate that - which it didn't |
| 2023-11-15 19:24:14 +0100 | <ski> | yep, right. you weren't incrementing the counter at all |
| 2023-11-15 19:24:22 +0100 | derpyxdhs | (~Thunderbi@user/derpyxdhs) (Quit: derpyxdhs) |
| 2023-11-15 19:24:47 +0100 | <ski> | so you were passing the same counter number through all the computation, labelling every element with the same number (one more than the counter) |
| 2023-11-15 19:25:30 +0100 | <ski> | ok, good, now you're back to preincrement (so if you start at zero, first element will be labelled with one) |
| 2023-11-15 19:26:03 +0100 | <ski> | my `Branch 2 (Branch 3 Leaf Leaf) (Branch 5 (Branch 7 Leaf Leaf) Leaf)' example was formulated in terms of labelling first element at zero, not one |
| 2023-11-15 19:27:02 +0100 | <ski> | if you want to, you could figure out what makes your code preincrement and not postincrement. (it could be nice to understand.) but if you'd rather move on, that's also fine. it's not too important for the main lesson |
| 2023-11-15 19:27:09 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Remote host closed the connection) |
| 2023-11-15 19:27:20 +0100 | <bwe> | in (n2+1, Branch (n2, x) l' r') |
| 2023-11-15 19:27:30 +0100 | <ski> | that would postincrement, yep |
| 2023-11-15 19:28:05 +0100 | <ski> | `n2' is the current counter, after labelling `l' and `r'. so you're labelling the element with the current counter, and *then* incrementing the counter on the way out |
| 2023-11-15 19:28:41 +0100 | <ski> | (this last version line above is doing that i mean) |
| 2023-11-15 19:28:58 +0100 | <bwe> | so we are on line with your example output |
| 2023-11-15 19:28:58 +0100 | <ski> | okay |
| 2023-11-15 19:29:02 +0100 | <ski> | yep |
| 2023-11-15 19:29:19 +0100 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-11-15 19:29:27 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2023-11-15 19:29:41 +0100 | <tango88> | ski: it seems that this stopped working with GHC 9 |
| 2023-11-15 19:29:41 +0100 | <tango88> | https://play.haskell.org/saved/HnpUO4at |
| 2023-11-15 19:29:42 +0100 | <tango88> | this works on GHC 8.10.7, but it doesn't on GHC 9.0.2 |
| 2023-11-15 19:30:13 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) (Ping timeout: 268 seconds) |
| 2023-11-15 19:30:26 +0100 | <ski> | so, what you've done now, is to manually "thread" the state (the counter) through your computation. into each recursive call, and also out of it, and then into the next recursive call. and incrementing it, while passing through each element that you encounter, and at the end of a node give back the current counter, so far, as part of output |
| 2023-11-15 19:30:38 +0100 | <ski> | curious, tango88 |
| 2023-11-15 19:30:44 +0100 | <ski> | tango88 : what if you add a space before `!' ? |
| 2023-11-15 19:31:15 +0100 | <ski> | bwe : would you like to see how to do preorder and inorder, too ? or should we move on ? |
| 2023-11-15 19:31:35 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 19:31:55 +0100 | <ski> | (breath-first is more involved, requires changing the code more seriously) |
| 2023-11-15 19:32:25 +0100 | <bwe> | let's do preorder and inorder :) |
| 2023-11-15 19:33:02 +0100 | <geekosaur> | % data A = A!Int |
| 2023-11-15 19:33:02 +0100 | <yahb2> | <interactive>:15:11: error: Not a data constructor: ‘!’ |
| 2023-11-15 19:33:15 +0100 | <ski> | (oh, and if it isn't clear, "inorder" is named so, because the element in a node is encountered inbetween traversing the two child subtrees. while for "preorder", the element is before them, and for "postorder", the element is after them) |
| 2023-11-15 19:33:37 +0100 | <ski> | % data A = A !Int |
| 2023-11-15 19:33:38 +0100 | <yahb2> | <no output> |
| 2023-11-15 19:33:49 +0100 | <geekosaur> | I *think* this was part of rationalizing the way prefixes are parsed |
| 2023-11-15 19:33:53 +0100 | <ski> | bwe : any hunch of how to adapt the code ? |
| 2023-11-15 19:34:51 +0100 | <ski> | bwe : btw, explicitly naming `n2+1' as (say) `n3' in the postorder case could be a preliminary step |
| 2023-11-15 19:35:33 +0100 | <tango88> | is the `data A = A!Int` grammar itself valid according to the report? |
| 2023-11-15 19:36:05 +0100 | <geekosaur> | yes. but ghc has a lot of extensions including to where ! is valid (BangPatterns) |
| 2023-11-15 19:36:22 +0100 | <tango88> | i see, thanks |
| 2023-11-15 19:36:23 +0100 | <bwe> | ski: I "just" need to swap the numbers for x and l |
| 2023-11-15 19:37:01 +0100 | <geekosaur> | and each extension had its own parsing rules. in 9.x those rules were rationalized, with the result that prior spaces or other non-expression syntax is required for prefixes like ! and ~ (and unary -) |
| 2023-11-15 19:37:29 +0100 | <ski> | % data A = (A)!Int |
| 2023-11-15 19:37:30 +0100 | <yahb2> | <interactive>:19:13: error: Not a data constructor: ‘!’ |
| 2023-11-15 19:38:01 +0100 | <probie> | Is it valid according to the report? `data A = A:!Int` is, but `!` isn't a valid constructor |
| 2023-11-15 19:38:17 +0100 | ski | sometimes wishes to be able to say `(x +*+ y) = ..x..y..' |
| 2023-11-15 19:38:51 +0100 | <geekosaur> | I was under the impression it would parse with A as the constructor since ! couldn't be, then ! would be recognized as a strictness indicator |
| 2023-11-15 19:39:13 +0100 | <geekosaur> | conceivably this is a bug in ghc9.x as a result |
| 2023-11-15 19:39:42 +0100 | <dolio> | :! is a valid constructor name. |
| 2023-11-15 19:39:48 +0100 | <geekosaur> | but ! is not |
| 2023-11-15 19:40:05 +0100 | <geekosaur> | the question being why `data A = A!Int` is trying to parse it as one |
| 2023-11-15 19:40:20 +0100 | <geekosaur> | instead of as `A !Int` |
| 2023-11-15 19:40:40 +0100 | <probie> | Don't mind me, for some reason I thought that strictness annotations were a GHC thing, but the report says I'm silly |
| 2023-11-15 19:41:02 +0100 | <dolio> | Yeah, I'm not sure why that'd parse any different. |
| 2023-11-15 19:41:03 +0100 | <geekosaur> | strictness annotations in `data` are standard. strictness annotations in patterns are an extension |
| 2023-11-15 19:42:01 +0100 | caryhartline | (~caryhartl@168.182.58.169) (Quit: caryhartline) |
| 2023-11-15 19:43:19 +0100 | <probie> | and they've been there since at least Haskell 1.4 |
| 2023-11-15 19:44:01 +0100 | <dolio> | You can't write `A ! Int`, either, even though I think the report says that's fine. |
| 2023-11-15 19:44:02 +0100 | ski | still doesn't really like `@' syntax for type applications |
| 2023-11-15 19:44:46 +0100 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2023-11-15 19:45:51 +0100 | <ski> | (occasionally i'd like to be able to say stuff like `foo_f@(foo f) x = ..foo..f..foo_f..x..') |
| 2023-11-15 19:49:23 +0100 | <bwe> | ski: here we go: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L58-L86 |
| 2023-11-15 19:51:15 +0100 | <ski> | great :) |
| 2023-11-15 19:51:30 +0100 | td_ | (~td@i53870918.versanet.de) (Ping timeout: 268 seconds) |
| 2023-11-15 19:51:34 +0100 | <ski> | (except i'd replace `n2+1' with `n3' in the postorder, so that it's not a dead binding) |
| 2023-11-15 19:51:44 +0100 | <bwe> | ski: I'd ping you another time on that breath-first ordering |
| 2023-11-15 19:51:47 +0100 | ft | (~ft@p508db3bc.dip0.t-ipconnect.de) |
| 2023-11-15 19:51:57 +0100 | <ski> | you're welcome, if i'm around |
| 2023-11-15 19:52:10 +0100 | <bwe> | cool. Yep, replaced that. |
| 2023-11-15 19:52:21 +0100 | <ski> | ok |
| 2023-11-15 19:52:28 +0100 | <ski> | so, onto `State', then ? |
| 2023-11-15 19:52:34 +0100 | <bwe> | Now, I am excited about that, yup. |
| 2023-11-15 19:52:53 +0100 | td_ | (~td@i53870930.versanet.de) |
| 2023-11-15 19:53:11 +0100 | <ski> | any idea where to start, with that ? |
| 2023-11-15 19:54:45 +0100 | <bwe> | ski: we are using that counter everywhere, that's our context. so if we could just track that in the background every time we increment or get the current state... |
| 2023-11-15 19:55:06 +0100 | <ski> | oh, it might also be reasonable (depending on what you're aiming for) to do a wrapper function which initializes the counter at zero (and perhaps not making the version that takes the counter as an input public, possibly defining it (as a "worker") inside a `where' of the "wrapper") |
| 2023-11-15 19:56:05 +0100 | tango88 | (~tango88@45.129.56.151) (Quit: Client closed) |
| 2023-11-15 19:56:06 +0100 | <ski> | one could e.g. call the previous version `enumerateTreeFrom', and the one that starts at zero, `enumerateTree' |
| 2023-11-15 19:56:34 +0100 | <bwe> | any idea how I could integrate all three variants into one? |
| 2023-11-15 19:56:40 +0100 | <ski> | (you could also add `inorder',`preorder',`postorder', or perhaps just `in',`pre',`post' for short, to those names, to differentiate between the different traversal orders) |
| 2023-11-15 19:56:55 +0100 | <ski> | well .. |
| 2023-11-15 19:57:24 +0100 | <ski> | you could, but i'm not sure how helpful it would be here (you'd still have at least some amount of code duplication, i think) |
| 2023-11-15 19:57:47 +0100 | <bwe> | let's do some case here |
| 2023-11-15 19:58:04 +0100 | <ski> | (one approach would be to make `data TraversalOrder = Preorder | Inorder | Postorder', and pass an extra input of type `TraversalOrder') |
| 2023-11-15 19:58:18 +0100 | <bwe> | :) I was just about doing that |
| 2023-11-15 19:58:37 +0100 | <ski> | (but doing worker-wrapper would also be beneficial, in that case) |
| 2023-11-15 19:59:40 +0100 | <ski> | (are you familiar with what i mean by "worker-wrapper" ?) |
| 2023-11-15 20:00:32 +0100 | <bwe> | let me do it and we'll see, ok? |
| 2023-11-15 20:01:01 +0100 | <ski> | sure |
| 2023-11-15 20:03:58 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) |
| 2023-11-15 20:07:27 +0100 | <bwe> | the worker-wrapper would then return only the tree or the state also? |
| 2023-11-15 20:09:38 +0100 | k` | (~user@152.7.255.206) |
| 2023-11-15 20:10:08 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2023-11-15 20:10:43 +0100 | <ski> | well, i guess it's up to your judegment, really |
| 2023-11-15 20:10:55 +0100 | <ski> | perhaps one'd also like to get a count of the number of elements ? |
| 2023-11-15 20:11:03 +0100 | <ski> | or perhaps just labelling is the main focus ? |
| 2023-11-15 20:11:18 +0100 | <ski> | the latter option seems the simpler interface, anyway |
| 2023-11-15 20:11:19 +0100 | <bwe> | updated: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4 -- and proud of the evolved solution! |
| 2023-11-15 20:13:26 +0100 | <bwe> | fast-forward to state: if we had the counter implicitly as the context we work in, we'd just need a get and inc function; then we'd basically factored out the management of the counter (that's what we do with the n1, n2+1 etc). |
| 2023-11-15 20:13:47 +0100 | <bwe> | just an intuition here, might be prematurely, though |
| 2023-11-15 20:14:58 +0100 | <ski> | bwe : right. (btw, it would be possible to factor out the common `Branch' part (after the `in's) from the `case' .. although it's not entirely clear whether it would be worth it). now notice that `order' is passed on recursively into `enumerateTreeFrom', but is never changed |
| 2023-11-15 20:16:19 +0100 | <ski> | "we'd just need a get and inc function; then we'd basically factored out the management of the counter (that's what we do with the n1, n2+1 etc)." -- yes (although it's not uncommon to merge those into a single operation, perhaps called `tick', which both increments and gets the current counter state) |
| 2023-11-15 20:18:03 +0100 | <bwe> | let's wrap Tree a with a State then? |
| 2023-11-15 20:18:26 +0100 | <ski> | sure |
| 2023-11-15 20:18:50 +0100 | <bwe> | Int (Tree a) -> Int (Tree (Int, a)) -- I've dropped the TraversalOrder here |
| 2023-11-15 20:19:08 +0100 | <bwe> | (and yeah, that's not the way we'll do it, sure) |
| 2023-11-15 20:19:12 +0100 | thegeekinside | (~thegeekin@189.141.80.123) (Remote host closed the connection) |
| 2023-11-15 20:19:18 +0100 | <bwe> | but that's the idea for me |
| 2023-11-15 20:19:38 +0100 | <ski> | did you mean to type `State' somewhere in there ? |
| 2023-11-15 20:20:25 +0100 | ski | would also like to see `order' not passed around as an argument to (the locally defined) `enumerateTreeFrom' |
| 2023-11-15 20:20:27 +0100 | <bwe> | Eventually but it clicked here for me: Tree a happens within a context of that counter that is Int. |
| 2023-11-15 20:20:45 +0100 | <ski> | you could say as much |
| 2023-11-15 20:21:01 +0100 | <ski> | well .. at least something like that |
| 2023-11-15 20:21:03 +0100 | <bwe> | that State term confuses me still -- keep it away from me! |
| 2023-11-15 20:21:11 +0100 | <ski> | hehe :) |
| 2023-11-15 20:21:40 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-15 20:21:44 +0100 | <bwe> | so, let's factor out Int and TraversalOrder into State |
| 2023-11-15 20:21:50 +0100 | <ski> | @kind Int (Tree String) |
| 2023-11-15 20:21:51 +0100 | <lambdabot> | error: |
| 2023-11-15 20:21:51 +0100 | <lambdabot> | • Expected kind ‘* -> k0’, but ‘Int’ has kind ‘*’ |
| 2023-11-15 20:21:51 +0100 | <lambdabot> | • In the type ‘Int (Tree String)’ |
| 2023-11-15 20:21:57 +0100 | <bwe> | (Int, Traversalorder) |
| 2023-11-15 20:22:07 +0100 | <ski> | why `Traversalorder' ? |
| 2023-11-15 20:22:44 +0100 | <bwe> | wait |
| 2023-11-15 20:22:49 +0100 | <ski> | (i've been trying to get at this with my comments about worker-wrapper, and the `order' parameter) |
| 2023-11-15 20:22:58 +0100 | <bwe> | I'll put it into the worker-wrapper that is all |
| 2023-11-15 20:24:44 +0100 | <bwe> | ski: that's the way to do it: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L55 |
| 2023-11-15 20:25:07 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Remote host closed the connection) |
| 2023-11-15 20:25:12 +0100 | <bwe> | so, let's put only the counter into the State, because that changes, order doesn't - as you mentioned earlier |
| 2023-11-15 20:25:43 +0100 | danse-nr3 | (~danse@151.43.130.136) (Ping timeout: 268 seconds) |
| 2023-11-15 20:25:53 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection) |
| 2023-11-15 20:26:15 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-11-15 20:26:31 +0100 | <ski> | bwe : exactly, you don't need to pass around an unchanging parameter in a locally defined worker, you can just "grab it frmo the air" out of the wrapper |
| 2023-11-15 20:27:08 +0100 | <mauke> | how closury |
| 2023-11-15 20:27:46 +0100 | <bwe> | ski: so, how do I define the tick? |
| 2023-11-15 20:28:06 +0100 | <ski> | (or, even if you'd pass it on as a parameter, note that `order' is only passed "downwards" into recursive calls. it's not returned from them. it's not "threaded" from one call to the next (like the counter is). so `order' is *not* a piece of state. we say it's an "environment" (compare with environment variables in OS processes, which are inherited "downwards" to children processes)) |
| 2023-11-15 20:28:15 +0100 | danse-nr3 | (~danse@151.43.130.136) |
| 2023-11-15 20:28:54 +0100 | ski | coclosures mauke |
| 2023-11-15 20:29:13 +0100 | <bwe> | ski: before I'd prefer to return only the Tree without the counter |
| 2023-11-15 20:29:15 +0100 | <ski> | bwe : well, what could be a reasonable type signature for `tick', to begin with ? |
| 2023-11-15 20:29:57 +0100 | <ski> | bwe : you can do that, by adapting the initial call to the worker, in the wrapper, adding some postprocessing (and not just the preprocessing of initializing the counter) |
| 2023-11-15 20:30:24 +0100 | <ski> | (my last two comments were unrelated to each other) |
| 2023-11-15 20:31:39 +0100 | <bwe> | tick :: State Int -> (Int, State Int) -- it needs access to some state and returns a new number including a new state |
| 2023-11-15 20:31:39 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2023-11-15 20:32:08 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-11-15 20:32:20 +0100 | <mauke> | ah |
| 2023-11-15 20:32:39 +0100 | <mauke> | that's insufficiently magical :-) |
| 2023-11-15 20:33:04 +0100 | <mauke> | it's also a kind error |
| 2023-11-15 20:33:08 +0100 | <bwe> | but I am not sure whether we actually return the new state, since we want to factor it out, so why return it? |
| 2023-11-15 20:33:09 +0100 | <mauke> | State takes two type parameters |
| 2023-11-15 20:33:52 +0100 | <mauke> | a value of type 'State s a' is a computation that can return a result of type 'a' while making use of state of type 's' |
| 2023-11-15 20:33:57 +0100 | <bwe> | mauke: I am currently in the process of learning State, so please don't assume that I know that it's taking something in :). |
| 2023-11-15 20:34:00 +0100 | dexter2 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Server closed connection) |
| 2023-11-15 20:34:28 +0100 | dexter2 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) |
| 2023-11-15 20:34:38 +0100 | Simikando | (~Simikando@adsl-dyn216.91-127-84.t-com.sk) (Remote host closed the connection) |
| 2023-11-15 20:34:40 +0100 | <ski> | bwe : it may help to realize that `State s a' does not encapsulate a state (version). it represents a state *transformer*, that given a previous state computes a next state (and also a separate "result") |
| 2023-11-15 20:34:53 +0100 | <mauke> | since tick wants to return a result of type Int while making use of some implicit state (also of type Int), it would be tick :: State Int Int |
| 2023-11-15 20:34:56 +0100 | <ski> | er, state *transformation*, i meant to say |
| 2023-11-15 20:35:10 +0100 | <mauke> | or was that a spoiler? |
| 2023-11-15 20:35:29 +0100 | <monochrom> | You should start with the idea of state transition functions, Int -> Int. Then you say you also want an output. That becomes Int -> (a, Int). |
| 2023-11-15 20:35:39 +0100 | <bwe> | ski: so the term State is completely misleading |
| 2023-11-15 20:35:41 +0100 | <ski> | "I am not sure whether we actually return the new state, since we want to factor it out, so why return it" -- we want to abstract it out of sight .. not quite the same as factor it out |
| 2023-11-15 20:36:03 +0100 | <bwe> | ski: abstract it out of sight |
| 2023-11-15 20:36:05 +0100 | <monochrom> | Oh haven't you heard: All meaningful names are misleading. >:) |
| 2023-11-15 20:36:23 +0100 | <monochrom> | Just look at our "data", "type", and "newtype". |
| 2023-11-15 20:36:40 +0100 | <ski> | mauke : yeap :p |
| 2023-11-15 20:36:53 +0100 | <monochrom> | And outside, "RAII", "bus factor", and "test pollution" aren't that great either. |
| 2023-11-15 20:37:30 +0100 | <monochrom> | The first time I heard "bus factor" I thought it was referring to hardware and for example PCI 5 has a higher bus factor than PCI 4. |
| 2023-11-15 20:37:40 +0100 | <ski> | bwe : it's an abbreviation (`State'). yes, without the proper background understanding, i understand how it could easily be taken in the wrong way |
| 2023-11-15 20:38:00 +0100 | <mauke> | .oO( Statefully? ) |
| 2023-11-15 20:38:04 +0100 | <bwe> | ski: who can I blame of naming it so? |
| 2023-11-15 20:38:11 +0100 | <ski> | Wadler, maybe ? |
| 2023-11-15 20:38:19 +0100 | <ski> | (or perhaps Moggi ?) |
| 2023-11-15 20:38:20 +0100 | <monochrom> | Human nature. |
| 2023-11-15 20:38:35 +0100 | <monochrom> | Every human thinks the name they coin makes total sense to everyone else. |
| 2023-11-15 20:38:51 +0100 | <ski> | bwe : btw, you definitely should read Philip Wadlers papers introducing monads as a programming technique |
| 2023-11-15 20:39:14 +0100 | <ski> | (they're quite readable, i'd say) |
| 2023-11-15 20:39:26 +0100 | <monochrom> | The cold hard truth is that names are insider jokes. |
| 2023-11-15 20:40:05 +0100 | <bwe> | ski: so, what's the transition step between tick :: Int -> Int to the State version? I feel it could help if I see them side-by-side. |
| 2023-11-15 20:40:08 +0100 | <k`> | Yeah, adding `ful` to the end might have made it more clear. |
| 2023-11-15 20:40:39 +0100 | <monochrom> | But perhaps Stateful is better for the type class (MonadState). :) |
| 2023-11-15 20:40:44 +0100 | <k`> | Then you could uncreatively name your state dictionary "State" |
| 2023-11-15 20:41:00 +0100 | <k`> | monochrom: True. |
| 2023-11-15 20:41:32 +0100 | <monochrom> | Int->Int is isomorphic to Int->((),Int). |
| 2023-11-15 20:41:50 +0100 | <monochrom> | OK I said I hated the word "isomorphic". :) |
| 2023-11-15 20:41:54 +0100 | <bwe> | iow? |
| 2023-11-15 20:42:49 +0100 | <monochrom> | It is possible that the Wadler papers or lecture notes will help. |
| 2023-11-15 20:43:00 +0100 | <k`> | monochrom: \ x -> (error "Here is some information", x - 1) |
| 2023-11-15 20:43:07 +0100 | <dolio> | I don't think it's misleading. |
| 2023-11-15 20:43:29 +0100 | <mauke> | have we done @unmtl yet? |
| 2023-11-15 20:44:04 +0100 | <ski> | bwe : <https://homepages.inf.ed.ac.uk/wadler/topics/monads.html>. start from the oldest. iirc, "The essence of functional programming","Combining monads","Comprehending monads","Monads for functional programming","Imperative functional programming","How to declare an imperative" are the main important ones (and "Monads and composable continuations" is also quite interesting) |
| 2023-11-15 20:44:27 +0100 | <monochrom> | Actually https://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm is exactly about the state monad. |
| 2023-11-15 20:45:00 +0100 | <ski> | bwe : well, if we start with `tick :: Int -> Int', (focusing just on the state update, ignoring getting the current state), how would you define that ? |
| 2023-11-15 20:46:04 +0100 | <ski> | bwe : sorry, "iow" is short for "in other words" |
| 2023-11-15 20:46:09 +0100 | <bwe> | tick :: State Int => Int -- very cautious try and error |
| 2023-11-15 20:46:24 +0100 | astra | (sid289983@id-289983.hampstead.irccloud.com) (Server closed connection) |
| 2023-11-15 20:46:33 +0100 | <ski> | (i didn't even realize i had used the abbreviation, had to go look for it) |
| 2023-11-15 20:46:33 +0100 | <bwe> | ski: I reasoned that after some time so recycled it by sending it to monochrom |
| 2023-11-15 20:46:45 +0100 | astra | (sid289983@id-289983.hampstead.irccloud.com) |
| 2023-11-15 20:47:05 +0100 | <mauke> | @unmtl State Int => Int |
| 2023-11-15 20:47:05 +0100 | <lambdabot> | State Int => Int |
| 2023-11-15 20:47:10 +0100 | <mauke> | heh |
| 2023-11-15 20:47:26 +0100 | <ski> | mauke : too early for 'unmtl' |
| 2023-11-15 20:47:42 +0100 | <mauke> | or too late, depending on your approach |
| 2023-11-15 20:47:46 +0100 | <ski> | could be |
| 2023-11-15 20:47:50 +0100 | <mauke> | but I just wanted to see what would happen |
| 2023-11-15 20:48:05 +0100 | <mauke> | didn't expect that :-) |
| 2023-11-15 20:48:19 +0100 | <bwe> | ski: the function just returns Int, the context is our State |
| 2023-11-15 20:48:40 +0100 | <bwe> | so from inside the function we access that State we abstracted away |
| 2023-11-15 20:49:00 +0100 | <ski> | bwe : anyway, `=>' suggests some use of type classes. we're not going to use any type class here (except eventually `Monad', and that won't show up in the type signature) |
| 2023-11-15 20:49:13 +0100 | <ski> | so, go back to `tick :: Int -> Int' ? |
| 2023-11-15 20:49:39 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 20:50:01 +0100 | <ski> | monochrom : when's that from ? |
| 2023-11-15 20:50:52 +0100 | <ski> | "so, what's the transition step between tick :: Int -> Int to the State version? I feel it could help if I see them side-by-side." -- yes, i was thinking the same |
| 2023-11-15 20:51:02 +0100 | <ski> | bwe ^ |
| 2023-11-15 20:51:21 +0100 | <k`> | monochrom's hint was `Int -> ((), Int)`. |
| 2023-11-15 20:51:53 +0100 | <ski> | we'll get to it, sooner or later |
| 2023-11-15 20:52:24 +0100 | <Inst> | just curious, bwe, how much of haskell do you know so far, and where are you coming from? |
| 2023-11-15 20:53:42 +0100 | <k`> | @unmtl State i a |
| 2023-11-15 20:53:42 +0100 | <lambdabot> | i -> (a, i) |
| 2023-11-15 20:54:33 +0100 | <bwe> | Inst: I've written quite some; but avoided Monad transformers since. Quite recently I intuitively began using <- assignments in do notation to simplify flow of operations. for example a function that returns Maybe Int. |
| 2023-11-15 20:54:38 +0100 | Square | (~Square@user/square) (Remote host closed the connection) |
| 2023-11-15 20:54:47 +0100 | <k`> | @type (,) () |
| 2023-11-15 20:54:48 +0100 | <lambdabot> | b -> ((), b) |
| 2023-11-15 20:55:00 +0100 | <bwe> | Inst: What was your impression of my Haskell proficiency? |
| 2023-11-15 20:55:33 +0100 | <Inst> | i don't feel qualified to judge, but, first, state doesn't have to be implemented via monad transformers, although it usually is for convenience purposes |
| 2023-11-15 20:55:42 +0100 | kronicma1 | (user24323@neotame.csclub.uwaterloo.ca) (Server closed connection) |
| 2023-11-15 20:56:00 +0100 | kronicma1 | (user39425@neotame.csclub.uwaterloo.ca) |
| 2023-11-15 20:56:03 +0100 | <ski> | yea, we're doing implementation of basic monads, to begin with. then combining multiple effects into the same monad is the plan |
| 2023-11-15 20:56:22 +0100 | <Inst> | second, i've been told that state is usually when you really "get' monads |
| 2023-11-15 20:56:45 +0100 | <ski> | (the goal at the moment is to really understand how `State' and its `Monad' instance works, including how to apply it for stateful problems) |
| 2023-11-15 20:56:52 +0100 | <Inst> | since a lot of people get trapped with the flawed "wrapper" intuition that unfortunately, Maybe and List get you into |
| 2023-11-15 20:57:20 +0100 | <mauke> | s -> ( , s) is a wrapper! |
| 2023-11-15 20:57:38 +0100 | ski | wraps up the picnic |
| 2023-11-15 20:58:03 +0100 | feetwind | (~mike@user/feetwind) |
| 2023-11-15 20:58:23 +0100 | ski | . o O ( `picnic :: Food -> (Satisfaction,Food)' ) |
| 2023-11-15 20:59:07 +0100 | <probie> | `State Food Satisfaction` sounds like an instruction |
| 2023-11-15 20:59:20 +0100 | <ski> | you could state that |
| 2023-11-15 21:00:05 +0100 | <bwe> | ski: do you want to continue this now or prefer of doing it another time? |
| 2023-11-15 21:00:43 +0100 | <k`> | probie: I don't like what that implies about what's happening with the food. I prefer ReaderT for food. |
| 2023-11-15 21:01:25 +0100 | <ski> | it's fine atm, if you feel fresh and clear-headed enough to continue. but perhaps you may already have enough (picnic ?) food for thought to digest (what with the traversal orders, and what happened in `enumerateTree' so far), so to prefer continuing later ? |
| 2023-11-15 21:01:56 +0100 | <Inst> | don't worry, it was a huge pain in the ass for me as well |
| 2023-11-15 21:02:02 +0100 | <ski> | k` : there may be leftovers |
| 2023-11-15 21:02:25 +0100 | <Inst> | i'd rather start with data Proxy a = Proxy and why we say it's a monad :) |
| 2023-11-15 21:02:48 +0100 | <ski> | bwe : see reply above |
| 2023-11-15 21:03:26 +0100 | <bwe> | ski: can we continue a little more? I feel excited to grasp that StateFUL thing |
| 2023-11-15 21:03:38 +0100 | <ski> | sure |
| 2023-11-15 21:03:54 +0100 | <k`> | ski: To deal with leftovers you may need to stream the food. |
| 2023-11-15 21:04:25 +0100 | ski | . o O ( "Throw, throw -- throw your food, gently down the stream." ) |
| 2023-11-15 21:04:40 +0100 | <feetwind> | i saw https://hackage.haskell.org/package/qualified-imports-plugin and was wondering, has anyone made a proposal to actually allow type names to act as qualified modules? so you could actually have `module Data.Text(type Text, module Text(unpack, pack, foldr, foldl, ...))` |
| 2023-11-15 21:05:00 +0100 | <feetwind> | then just have eg `import Data.Text; foo = Text.pack "asdf"` |
| 2023-11-15 21:05:23 +0100 | <k`> | Unfortunately I heard that conveyor belt sushi is going away. |
| 2023-11-15 21:05:45 +0100 | <ski> | bwe : so you desired to compare and contrast two versions of `tick' (and i agree), one "explicit" (like your `enumerateTreeFrom' so far's explicit), and one "implicit", using `State' |
| 2023-11-15 21:06:01 +0100 | <bwe> | right |
| 2023-11-15 21:06:14 +0100 | <ski> | so, should we try the first part ? |
| 2023-11-15 21:06:30 +0100 | <ski> | how to implement `tick :: Int -> Int' ? |
| 2023-11-15 21:06:32 +0100 | <bwe> | yes |
| 2023-11-15 21:07:11 +0100 | <bwe> | tick n = n+1 |
| 2023-11-15 21:07:15 +0100 | <ski> | right |
| 2023-11-15 21:07:20 +0100 | <bwe> | or short tick = (+1) |
| 2023-11-15 21:07:25 +0100 | <ski> | now, that's only handling the update of the counter state |
| 2023-11-15 21:07:36 +0100 | <bwe> | ah1 |
| 2023-11-15 21:07:37 +0100 | <bwe> | ! |
| 2023-11-15 21:07:44 +0100 | <ski> | but, we'd also like to get a "reading" of the state, as a "separate result" |
| 2023-11-15 21:07:54 +0100 | <feetwind> | an OverloadedModules extension to do it would be nice and then i'd never have to write Text.Text or `import Data.Text (Text)` again :') |
| 2023-11-15 21:07:56 +0100 | <ski> | any idea how that could look like ? |
| 2023-11-15 21:08:06 +0100 | <ski> | (you need to change the type signature, too) |
| 2023-11-15 21:08:15 +0100 | <bwe> | (n, n+1) for example |
| 2023-11-15 21:08:23 +0100 | <ski> | yep |
| 2023-11-15 21:08:26 +0100 | <ski> | (signature being ?) |
| 2023-11-15 21:08:29 +0100 | <feetwind> | same vain, has anyone proposed import aliases a la rust/typescript, like import Data.Text.Lazy (Text as LazyText) ? |
| 2023-11-15 21:08:29 +0100 | <bwe> | tick :: Int -> (Int, Int) |
| 2023-11-15 21:08:32 +0100 | ski | nods |
| 2023-11-15 21:08:44 +0100 | <ski> | now, can you recall how `State' was defined ? |
| 2023-11-15 21:09:45 +0100 | <ski> | feetwind : there can be multiple data types declared in a module |
| 2023-11-15 21:10:01 +0100 | <bwe> | s -> (a, s) |
| 2023-11-15 21:10:23 +0100 | <ski> | yea, but what's the full `data' type declaration ? |
| 2023-11-15 21:10:47 +0100 | haritz | (~hrtz@user/haritz) (Server closed connection) |
| 2023-11-15 21:11:04 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2023-11-15 21:11:38 +0100 | <ski> | (it may help to have some things in front of our eyes, in the discussion) |
| 2023-11-15 21:11:58 +0100 | <bwe> | newtype State s a = State (s -> (a, s)) |
| 2023-11-15 21:12:01 +0100 | <ski> | right |
| 2023-11-15 21:12:08 +0100 | <bwe> | chaka |
| 2023-11-15 21:12:42 +0100 | <ski> | now, to more easily refer to the type, and to the data constructor, separately, i'll pretend that this actually was declared as |
| 2023-11-15 21:12:52 +0100 | <ski> | newtype State s a = MkState (s -> (a, s)) |
| 2023-11-15 21:12:55 +0100 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2023-11-15 21:12:55 +0100 | haritz | (~hrtz@user/haritz) |
| 2023-11-15 21:13:17 +0100 | <ski> | anyway, you're right that we should look at the `s -> (a,s)' part now |
| 2023-11-15 21:13:56 +0100 | <bwe> | Int -> (Int, Int) vs. s -> (a,s) |
| 2023-11-15 21:14:05 +0100 | <ski> | this is a function type, getting a state (version) as input, and computing back as result some value (of type `a'), together with a (presumably updated) state as output |
| 2023-11-15 21:14:09 +0100 | <bwe> | tick vs. MkState |
| 2023-11-15 21:14:38 +0100 | <ski> | (for hysterical raisins, the output state part is the latter part of the pair, and the result value is the former part) |
| 2023-11-15 21:14:50 +0100 | <ski> | now, please recall your current definition of `tick' |
| 2023-11-15 21:15:10 +0100 | akegalj | (~akegalj@141-136-147-15.dsl.iskon.hr) (Quit: leaving) |
| 2023-11-15 21:15:17 +0100 | <bwe> | tick :: Int -> (Int, Int) |
| 2023-11-15 21:15:49 +0100 | <ski> | (and the defining equation ?) |
| 2023-11-15 21:16:03 +0100 | <bwe> | tick = (n, n+1) |
| 2023-11-15 21:16:07 +0100 | <ski> | thank you |
| 2023-11-15 21:16:46 +0100 | <ski> | now, perhaps i'm belaboring the point here .. but note that in `(n,n+1)', the `n' (former) part is thus the "result value", while the `n+1' (latter) part is the "updated/output state" |
| 2023-11-15 21:17:10 +0100 | <ski> | (it may not always be so clear, since both have the same type. so it's good to be explicit about what is what) |
| 2023-11-15 21:18:18 +0100 | <ski> | so, yea, we match the concrete type `Int -> (Int,Int)' (the type of `tick') with the type `s -> (a,s)' (which is the representation type of the data type `State s a', the type of what's "contained inside" that) |
| 2023-11-15 21:18:21 +0100 | incertia | (~incertia@209.122.71.127) (Ping timeout: 260 seconds) |
| 2023-11-15 21:18:22 +0100 | <bwe> | the first is the getter, the second the setter? |
| 2023-11-15 21:18:41 +0100 | <bwe> | (while in the State it's flipped order) |
| 2023-11-15 21:18:44 +0100 | <k`> | @t get |
| 2023-11-15 21:18:44 +0100 | <lambdabot> | Maybe you meant: tell thank you thanks thesaurus thx tic-tac-toe ticker time todo todo-add todo-delete type v @ ? . |
| 2023-11-15 21:18:56 +0100 | <k`> | @type get |
| 2023-11-15 21:18:57 +0100 | <lambdabot> | MonadState s m => m s |
| 2023-11-15 21:18:58 +0100 | <ski> | .. not quite .. but something akin to that, i guess |
| 2023-11-15 21:19:17 +0100 | <bwe> | not setter, the state value |
| 2023-11-15 21:19:24 +0100 | <ski> | yes |
| 2023-11-15 21:19:50 +0100 | incertia | (~incertia@209.122.137.252) |
| 2023-11-15 21:19:54 +0100 | <ski> | anyway, matching the types, we see that `s' must be `Int', and `a' happens to be `Int', so `State s a' becomes `State Int Int' |
| 2023-11-15 21:20:28 +0100 | <ski> | so, if we're wrapping `tick' (a state *transformation* function) inside `MkState', we will get something of type `State Int Int' |
| 2023-11-15 21:20:33 +0100 | <ski> | that's clear ? |
| 2023-11-15 21:20:56 +0100 | <bwe> | tick'' :: _ -> State Int Int |
| 2023-11-15 21:21:01 +0100 | <ski> | ("while in the State it's flipped order" -- no. same order in `tick' above, as in `State') |
| 2023-11-15 21:21:07 +0100 | <bwe> | k |
| 2023-11-15 21:21:32 +0100 | <ski> | yea .. except there's now no (*visible* !) argument |
| 2023-11-15 21:21:38 +0100 | <ski> | so there's no `_ -> ' |
| 2023-11-15 21:22:01 +0100 | <feetwind> | ski, sorry not really what i mean |
| 2023-11-15 21:22:14 +0100 | <feetwind> | i think the answers are basically, no :) |
| 2023-11-15 21:22:14 +0100 | <k`> | @type state |
| 2023-11-15 21:22:15 +0100 | <lambdabot> | MonadState s m => (s -> (a, s)) -> m a |
| 2023-11-15 21:22:17 +0100 | <ski> | (you could perhaps call the original version `tick', and the `State' version `tickS', to distinguish them from each other) |
| 2023-11-15 21:23:04 +0100 | <bwe> | ah, we abstracted away the "s ->" part into the StateFUL! |
| 2023-11-15 21:23:11 +0100 | tinwood | (~tinwood@canonical/tinwood) (Server closed connection) |
| 2023-11-15 21:23:24 +0100 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) |
| 2023-11-15 21:23:24 +0100 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) (Changing host) |
| 2023-11-15 21:23:24 +0100 | tinwood | (~tinwood@canonical/tinwood) |
| 2023-11-15 21:23:26 +0100 | <ski> | feetwind : .. ooh, now i think i see what you meant. you kinda wanted to declare a "submodule" as being exported from `Data.Text', is that right ? |
| 2023-11-15 21:23:59 +0100 | johnw_ | (~johnw@69.62.242.138) |
| 2023-11-15 21:24:22 +0100 | <ski> | (the module system in the MLs (SML,OCaml (but not F#)) allows such things, btw) |
| 2023-11-15 21:24:31 +0100 | <ski> | bwe : exactly ! :P |
| 2023-11-15 21:24:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-15 21:24:56 +0100 | johnw | (~johnw@69.62.242.138) (Ping timeout: 245 seconds) |
| 2023-11-15 21:24:56 +0100 | <ski> | bwe : that's part of what i meant by "abstract it out of sight" |
| 2023-11-15 21:25:07 +0100 | fendor | (~fendor@2a02:8388:1640:be00:2528:5dc7:a36e:9b87) (Remote host closed the connection) |
| 2023-11-15 21:25:10 +0100 | <ski> | so .. what's the type signature, now ? |
| 2023-11-15 21:25:24 +0100 | <bwe> | tickS :: State (Int, Int) |
| 2023-11-15 21:25:32 +0100 | <ski> | right |
| 2023-11-15 21:25:38 +0100 | <ski> | and implementation ? |
| 2023-11-15 21:25:42 +0100 | <ski> | er .. sorry |
| 2023-11-15 21:25:52 +0100 | ski | read too quickly |
| 2023-11-15 21:26:02 +0100 | <ski> | it's not `State (Int, Int)' |
| 2023-11-15 21:26:15 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Read error: Connection reset by peer) |
| 2023-11-15 21:26:17 +0100 | doyougnu- | (~doyougnu@45.46.170.68) (Server closed connection) |
| 2023-11-15 21:26:18 +0100 | <feetwind> | yes basically, basically making Data.Text export a submodule that happens to share the name with the type Text -- since that's somewhat idiomatic anyway to do exactly that already like `import Data.Text (Text); import Data.Text qualified as Text` |
| 2023-11-15 21:26:29 +0100 | <bwe> | State (Int Int) |
| 2023-11-15 21:26:34 +0100 | doyougnu | (~doyougnu@45.46.170.68) |
| 2023-11-15 21:26:35 +0100 | Square2 | (~Square4@user/square) |
| 2023-11-15 21:26:38 +0100 | <bwe> | tickS :: State Int Int |
| 2023-11-15 21:26:43 +0100 | <bwe> | finally |
| 2023-11-15 21:27:13 +0100 | <ski> | tick :: Int -> (Int,Int) -- tickS :: State Int Int |
| 2023-11-15 21:27:15 +0100 | <EvanR> | bwe, on "State" being misleading, my running list of commonly used meanings for "state" is pretty long at this point |
| 2023-11-15 21:27:15 +0100 | <ski> | s -> (a ,s ) -- State s a |
| 2023-11-15 21:28:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 21:28:09 +0100 | <EvanR> | I guess haskell could have gone with Stateful for this type constructor |
| 2023-11-15 21:28:12 +0100 | <ski> | right, bwe. the first `Int' is the type of the state (which is both an implicit input and an implicit output). the second `Int' is the type of the result (which is only an output) |
| 2023-11-15 21:28:45 +0100 | <ski> | bwe : so .. how's `tickS' defined ? |
| 2023-11-15 21:29:02 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Remote host closed the connection) |
| 2023-11-15 21:32:42 +0100 | ubert1 | (~Thunderbi@178.165.182.252.wireless.dyn.drei.com) |
| 2023-11-15 21:32:56 +0100 | vilya | (~vilya@user/vilya) (Ping timeout: 268 seconds) |
| 2023-11-15 21:33:07 +0100 | <bwe> | ski: -- looking up how I used State's value with Functor implementation |
| 2023-11-15 21:33:24 +0100 | <ski> | yup |
| 2023-11-15 21:33:27 +0100 | vilya | (~vilya@user/vilya) |
| 2023-11-15 21:33:42 +0100 | ubert | (~Thunderbi@77.119.172.155.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2023-11-15 21:33:42 +0100 | ubert1 | ubert |
| 2023-11-15 21:33:48 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-15 21:34:21 +0100 | <bwe> | tickS = State $ \s0 -> (s0, s0+1) |
| 2023-11-15 21:34:51 +0100 | <bwe> | now I understand my Functor implementation…why there is State $ \s0 |
| 2023-11-15 21:35:42 +0100 | <ski> | right, that `s0' there is also the "hidden state input" |
| 2023-11-15 21:35:43 +0100 | <bwe> | I didn't understand where that s0 is coming from since. Now I get that the s0 is the first s from `s -> (a, s)`, it's the input state value |
| 2023-11-15 21:36:00 +0100 | <ski> | tickS = MkState (\n -> (n,n+1)) -- what i'd write |
| 2023-11-15 21:36:08 +0100 | <ski> | right |
| 2023-11-15 21:37:08 +0100 | <ski> | now .. if you *want* to, you could go on and insert calls to `tick' (not `tickS') in your existing `enumerateTree'/`enumerateTreeFrom' code (the explicit version, not using `State') |
| 2023-11-15 21:37:53 +0100 | <ski> | .. or, you could directly try to make the `State' version, and use `tickS' in that |
| 2023-11-15 21:40:33 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-11-15 21:42:24 +0100 | <bwe> | ski: no, first the tick version |
| 2023-11-15 21:42:43 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-11-15 21:43:16 +0100 | <ski> | ok, so the task then is to identify where to insert `tick', and which parts of the existing code it replaces |
| 2023-11-15 21:43:24 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 246 seconds) |
| 2023-11-15 21:43:25 +0100 | <bwe> | I need to change the existing code so I can make use of (n, n+1) pattern |
| 2023-11-15 21:43:38 +0100 | <ski> | basically, yes |
| 2023-11-15 21:44:22 +0100 | <ski> | you could use `n0',`n1',`n2',`n3' for the numbered versions of the counter, and `n' for the "read out" reading that you're going to use as a label |
| 2023-11-15 21:44:47 +0100 | <idgaen> | that remembers me an example in "Programming in Haskell" by Graham Hutton :) |
| 2023-11-15 21:45:49 +0100 | <ski> | wouldn't be surprised if multiple people have come up with more or less the same example |
| 2023-11-15 21:45:50 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-11-15 21:46:07 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Quit: Leaving) |
| 2023-11-15 21:50:43 +0100 | <bwe> | ski: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L63-L78 -- I've used prime to differentiate the names from each other |
| 2023-11-15 21:51:18 +0100 | <bwe> | ski: could you please confirm whether my change is correct? then I'd continue with State |
| 2023-11-15 21:51:55 +0100 | <idgaen> | i'm just amazed, anyway it's a good exercise |
| 2023-11-15 21:53:01 +0100 | <ski> | looks okay to me |
| 2023-11-15 21:53:05 +0100 | <bwe> | wow |
| 2023-11-15 21:53:28 +0100 | <ski> | oh, sorry, missed you changed `enumerateTree' |
| 2023-11-15 21:53:30 +0100 | <ski> | looking at that now |
| 2023-11-15 21:53:41 +0100 | yangby | (~secret@183.128.111.44) |
| 2023-11-15 21:54:10 +0100 | <bwe> | I wonder whether I should let that return only Tree (Int, a) |
| 2023-11-15 21:54:42 +0100 | <bwe> | (to only put State in enumerateTreeFrom) |
| 2023-11-15 21:54:47 +0100 | <ski> | right, you're not using n' in the `Postorder' case |
| 2023-11-15 21:55:36 +0100 | <bwe> | ski: I don't understand |
| 2023-11-15 21:55:38 +0100 | <ski> | otherwise, it looks okay (except i'd rename n1' to n' in the `Preorder' case, for consistency's sake) |
| 2023-11-15 21:55:53 +0100 | <ski> | let (n1, l') = enumerateTreeFrom n l |
| 2023-11-15 21:56:01 +0100 | <ski> | (n2, r') = enumerateTreeFrom n1 r |
| 2023-11-15 21:56:07 +0100 | <ski> | (n', n3) = tick n2 |
| 2023-11-15 21:56:19 +0100 | <ski> | in (n3, Branch (n2, x) l' r') |
| 2023-11-15 21:56:26 +0100 | <ski> | note that n' is unused |
| 2023-11-15 21:56:33 +0100 | <bwe> | yes |
| 2023-11-15 21:56:56 +0100 | <ski> | in your other two cases, you're using both parts of the pair coming from `tick' |
| 2023-11-15 21:57:07 +0100 | <bwe> | that's right |
| 2023-11-15 21:57:24 +0100 | <ski> | so, you're not being consistent |
| 2023-11-15 21:58:12 +0100 | <bwe> | got it |
| 2023-11-15 21:58:18 +0100 | <ski> | (in the case of `Postorder', the case just above, it so *happens* that n' is equal to n2 .. but that's kinda a happy accident) |
| 2023-11-15 21:58:45 +0100 | <bwe> | ski: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L67-L68 |
| 2023-11-15 21:59:25 +0100 | <ski> | ok, i guess that works, too |
| 2023-11-15 21:59:38 +0100 | <ski> | so, 'tickS' and `State' ? |
| 2023-11-15 21:59:50 +0100 | <bwe> | ooooh... |
| 2023-11-15 21:59:53 +0100 | <EvanR> | your inner enumerateTreeFrom branches on the TraversalOrder every time even though it doesn't change in the course of a call to enumerateTree. It could be turned inside out to only do that check at the beginning |
| 2023-11-15 21:59:58 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) |
| 2023-11-15 22:00:16 +0100 | <bwe> | EvanR: cosmetics? |
| 2023-11-15 22:00:25 +0100 | <ski> | EvanR : yea, i noticed that before, but decided to not focus on that for the time being |
| 2023-11-15 22:01:11 +0100 | <EvanR> | I haven't met a haskell program I could not make cosmetically good xD |
| 2023-11-15 22:01:14 +0100 | <ski> | bwe : well, i guess it's kinda more about efficiency (constant factor) |
| 2023-11-15 22:01:58 +0100 | <ski> | (and yea, aesthetics is important) |
| 2023-11-15 22:02:07 +0100 | <EvanR> | otoh, would ghc fix this problem for you? |
| 2023-11-15 22:02:11 +0100 | <ski> | @quote not.optional |
| 2023-11-15 22:02:12 +0100 | <lambdabot> | O'Keefe says: "Elegance is not optional." |
| 2023-11-15 22:02:56 +0100 | <bwe> | ski: I could replace tick with tickS but I loose the argument now |
| 2023-11-15 22:03:04 +0100 | <bwe> | which is intended |
| 2023-11-15 22:03:22 +0100 | <ski> | you mean it's not as clear how to convert to using `State', now ? |
| 2023-11-15 22:03:28 +0100 | <bwe> | yes |
| 2023-11-15 22:03:32 +0100 | <ski> | right |
| 2023-11-15 22:04:38 +0100 | <ski> | so .. i guess, for the time being, the next step here may be a bit of the "oracle method" / "leap of faith" |
| 2023-11-15 22:05:33 +0100 | <ski> | perhaps you could at least suggest a version of `enumerateTreeFrom's type signature, that's using `State', rather than explicit state-passing/threading style (which is what your existing 'enumerateTreeFrom' is said to use) |
| 2023-11-15 22:05:37 +0100 | <ski> | ? |
| 2023-11-15 22:07:46 +0100 | zetef | (~quassel@95.77.17.251) |
| 2023-11-15 22:07:46 +0100 | <bwe> | I replace the counter value with the StateFUL |
| 2023-11-15 22:08:04 +0100 | <bwe> | enumerateTreeFrom :: State Int Int -> Tree a -> (_, Tree (Int, a)) |
| 2023-11-15 22:09:09 +0100 | <ski> | remember the `State s a' is not the current state value, but the state *transformation* |
| 2023-11-15 22:09:55 +0100 | santiagopim | (~user@90.167.66.131) |
| 2023-11-15 22:10:02 +0100 | <bwe> | so it'd be enumerateTreeFrom :: s -> Tree a -> (Int, Tree (Int, a)) ? |
| 2023-11-15 22:10:22 +0100 | <bwe> | let me go one step back |
| 2023-11-15 22:10:27 +0100 | <ski> | .. it could perhaps be useful here to slightly refactor `enumerateTreeFrom' so that it (like `tick', and like inside `State s a'), the output state is the *second* part of the pair, not the first part |
| 2023-11-15 22:10:58 +0100 | <ski> | (this would also clean up your `let's in the definition, making them look more elegant) |
| 2023-11-15 22:11:07 +0100 | <ski> | @quote not.optional |
| 2023-11-15 22:11:07 +0100 | <lambdabot> | O'Keefe says: "Elegance is not optional." |
| 2023-11-15 22:14:02 +0100 | <EvanR> | States are programs that use a state, are waiting for an initial state before they can run |
| 2023-11-15 22:14:38 +0100 | <int-e> | EvanR: please no |
| 2023-11-15 22:14:45 +0100 | <EvanR> | lol |
| 2023-11-15 22:15:22 +0100 | <EvanR> | map is a function which takes functors xD |
| 2023-11-15 22:15:37 +0100 | <bwe> | ski: https://gist.github.com/benjaminweb/ea91583983f5eceb10549ed25db03ec4#file-monadt-hs-L54-L78 |
| 2023-11-15 22:15:41 +0100 | <int-e> | :t fmap |
| 2023-11-15 22:15:42 +0100 | <lambdabot> | Functor f => (a -> b) -> f a -> f b |
| 2023-11-15 22:15:49 +0100 | caryhartline | (~caryhartl@168.182.58.169) |
| 2023-11-15 22:15:52 +0100 | <EvanR> | er, fmap |
| 2023-11-15 22:15:54 +0100 | caryhartline | (~caryhartl@168.182.58.169) (Client Quit) |
| 2023-11-15 22:16:05 +0100 | <int-e> | EvanR: I'm sort of okay with that because I'm familiar with the dictionary passing implementation |
| 2023-11-15 22:16:22 +0100 | <EvanR> | it's so confused it's right |
| 2023-11-15 22:16:24 +0100 | <int-e> | So it's not confusing types and their values quite as much. |
| 2023-11-15 22:16:30 +0100 | <bwe> | ski: State (s -> (a, s)) |
| 2023-11-15 22:17:03 +0100 | <ski> | bwe : yea, but `enumerateTreeFrom' is (currently) a bit off from that, since the output counter is the first part of the pair in `enumerateTreeFrom |
| 2023-11-15 22:17:05 +0100 | <bwe> | ski: (Tree (Int, a), Int) |
| 2023-11-15 22:17:08 +0100 | <ski> | ', not the second part |
| 2023-11-15 22:17:13 +0100 | <ski> | yesp |
| 2023-11-15 22:17:20 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds) |
| 2023-11-15 22:17:42 +0100 | <ski> | (and with corresponding adaptations/refactoring of the definition of `enumerateTreeFrom') |
| 2023-11-15 22:19:41 +0100 | <bwe> | I am not following here |
| 2023-11-15 22:20:05 +0100 | <ski> | i mean, adapting |
| 2023-11-15 22:20:06 +0100 | <ski> | enumerateTreeFrom :: Int -> Tree a -> (Int, Tree (Int, a)) |
| 2023-11-15 22:20:38 +0100 | <ski> | as you just indicated, you also need to adapt the definition accordingly |
| 2023-11-15 22:20:42 +0100 | <ski> | e.g. |
| 2023-11-15 22:20:46 +0100 | <ski> | (n1, l') = enumerateTreeFrom n l |
| 2023-11-15 22:20:47 +0100 | <ski> | becomes |
| 2023-11-15 22:20:55 +0100 | <ski> | (l', n1) = enumerateTreeFrom n l |
| 2023-11-15 22:21:04 +0100 | <bwe> | oh, pls refresh the gist |
| 2023-11-15 22:21:16 +0100 | <bwe> | rev 15 |
| 2023-11-15 22:21:55 +0100 | <ski> | right |
| 2023-11-15 22:22:09 +0100 | <ski> | now notice how `n1',`n2',`n2' line up vertically, in the `let's |
| 2023-11-15 22:22:24 +0100 | <bwe> | yeah |
| 2023-11-15 22:22:25 +0100 | <ski> | (that's what i mean by "more elegant", here) |
| 2023-11-15 22:22:29 +0100 | <bwe> | true |
| 2023-11-15 22:22:43 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-11-15 22:22:57 +0100 | zetef | (~quassel@95.77.17.251) (Ping timeout: 246 seconds) |
| 2023-11-15 22:23:03 +0100 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Quit: oo_miguel) |
| 2023-11-15 22:23:13 +0100 | <k`> | ski: (you must hate `foldr`) |
| 2023-11-15 22:23:24 +0100 | <ski> | how come ? |
| 2023-11-15 22:23:25 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-15 22:23:30 +0100 | <k`> | @t foldr |
| 2023-11-15 22:23:30 +0100 | <lambdabot> | Maybe you meant: tell thank you thanks thesaurus thx tic-tac-toe ticker time todo todo-add todo-delete type v @ ? . |
| 2023-11-15 22:23:35 +0100 | <k`> | @ty foldr |
| 2023-11-15 22:23:36 +0100 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2023-11-15 22:23:51 +0100 | <EvanR> | @thanks |
| 2023-11-15 22:23:52 +0100 | <lambdabot> | you are welcome |
| 2023-11-15 22:23:58 +0100 | <ski> | you mean as opposed to `flip . foldr' ? |
| 2023-11-15 22:24:02 +0100 | <mauke> | :t y |
| 2023-11-15 22:24:03 +0100 | <lambdabot> | Expr |
| 2023-11-15 22:24:09 +0100 | <bwe> | ski: enumerateTreeFrom :: Int -> Tree a -> State (Tree (Int, a)) Int |
| 2023-11-15 22:24:18 +0100 | <bwe> | it's not finished :) |
| 2023-11-15 22:24:32 +0100 | <bwe> | but look how I've changed the return type |
| 2023-11-15 22:24:38 +0100 | <ski> | bwe, closish :) |
| 2023-11-15 22:24:40 +0100 | <mauke> | why are we taking in two trees? |
| 2023-11-15 22:24:58 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2023-11-15 22:25:11 +0100 | ggVGc | (~ggVGc@a.lowtech.earth) (Server closed connection) |
| 2023-11-15 22:25:23 +0100 | <bwe> | ski: how does the input Int change now? |
| 2023-11-15 22:25:26 +0100 | <k`> | ski: right |
| 2023-11-15 22:25:29 +0100 | <ski> | you agree with (previous version) |
| 2023-11-15 22:25:33 +0100 | ggVGc | (~ggVGc@a.lowtech.earth) |
| 2023-11-15 22:25:35 +0100 | <bwe> | oh, does it disappear? |
| 2023-11-15 22:25:38 +0100 | <ski> | enumerateTreeFrom :: Int -> Tree a -> (Tree (Int,a),Int) |
| 2023-11-15 22:25:39 +0100 | <ski> | yes ? |
| 2023-11-15 22:25:49 +0100 | <bwe> | like we did in the transition from tick to tickS??? |
| 2023-11-15 22:25:52 +0100 | <bwe> | what?? |
| 2023-11-15 22:25:52 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-11-15 22:26:28 +0100 | <ski> | i mean, before switching to `State', i suggested putting the output state last, to conform with `tick' (and also with `State s a' being `s -> (a,s)') |
| 2023-11-15 22:27:09 +0100 | Inst | (~Inst@120.244.192.250) (Ping timeout: 246 seconds) |
| 2023-11-15 22:27:26 +0100 | <bwe> | you mean first |
| 2023-11-15 22:27:38 +0100 | <ski> | no |
| 2023-11-15 22:27:50 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2023-11-15 22:27:54 +0100 | <bwe> | enumerateTreeForm :: Tree a -> Int -> State (Tree (Int, a)) Int ? |
| 2023-11-15 22:28:07 +0100 | <bwe> | argh |
| 2023-11-15 22:28:10 +0100 | <bwe> | hold on |
| 2023-11-15 22:28:16 +0100 | k` | (~user@152.7.255.206) (Remote host closed the connection) |
| 2023-11-15 22:28:21 +0100 | <ski> | (the second (output) `s' in `s -> (a,s)' is the last part of the pair) |
| 2023-11-15 22:29:13 +0100 | <bwe> | enumerateTreeFrom :: Tree a -> Int -> (Tree (Int, a)), Int) |
| 2023-11-15 22:29:25 +0100 | <bwe> | Int -> (Tree (Int, a)), Int) |
| 2023-11-15 22:29:38 +0100 | <bwe> | s -> (Tree (Int, a)), Int) |
| 2023-11-15 22:29:59 +0100 | <bwe> | s -> (a, s) |
| 2023-11-15 22:30:02 +0100 | <ski> | where does the second `s' go, in there ? |
| 2023-11-15 22:30:08 +0100 | <ski> | yah |
| 2023-11-15 22:30:12 +0100 | <int-e> | But the state is the first argument of `State s a` |
| 2023-11-15 22:30:12 +0100 | <EvanR> | fst and snd are so left-to-right-centric, shoulda used car and cdr |
| 2023-11-15 22:30:30 +0100 | <int-e> | So that'll be a bit confusinig at first. |
| 2023-11-15 22:30:38 +0100 | <ski> | EvanR : SML uses `#1' and `#2' |
| 2023-11-15 22:30:44 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-11-15 22:30:54 +0100 | danse-nr3 | (~danse@151.43.130.136) (Ping timeout: 268 seconds) |
| 2023-11-15 22:31:06 +0100 | <mauke> | EvanR: that's unhaskellish |
| 2023-11-15 22:31:18 +0100 | <int-e> | EvanR: so which one is the address and which one is the data? |
| 2023-11-15 22:31:20 +0100 | <mauke> | contentsOfAddressPartOfRegister and contentsOfDataPartOfRegister |
| 2023-11-15 22:31:20 +0100 | <EvanR> | how about #1 and #0, just to make snd feel better xD, yes you're last, but you're also first in a way |
| 2023-11-15 22:31:40 +0100 | <geekosaur> | that looks more like java than haskell |
| 2023-11-15 22:32:10 +0100 | <mauke> | not my fault that haskell decided it wanted to look like java |
| 2023-11-15 22:32:17 +0100 | <int-e> | (The names "car" and "cdr" are so arcane. Though the resulting "caar" naming scheme is kind of cute.) |
| 2023-11-15 22:32:24 +0100 | <ski> | wouldn't the state seem more akin to address stuff ? |
| 2023-11-15 22:32:28 +0100 | <EvanR> | cdda |
| 2023-11-15 22:32:45 +0100 | <mauke> | my other car is a cdr |
| 2023-11-15 22:33:32 +0100 | <EvanR> | car and cdr are too arcane, but Monad is fine |
| 2023-11-15 22:33:36 +0100 | yangby | (~secret@183.128.111.44) (Quit: Go out for a walk and buy a drink.) |
| 2023-11-15 22:33:42 +0100 | <int-e> | EvanR: you do know that "car" stands for "contents of address register", right? |
| 2023-11-15 22:34:04 +0100 | <EvanR> | in the 100th sublevel of my mind yes |
| 2023-11-15 22:34:25 +0100 | <int-e> | I'm okay with arcane names... but I wouldn't pretent that car and cdr are better than fst and snd. |
| 2023-11-15 22:34:31 +0100 | <int-e> | *pretend |
| 2023-11-15 22:34:45 +0100 | <ski> | now i'm wondering whether 680x0 got address vs. data registers from there |
| 2023-11-15 22:34:49 +0100 | <EvanR> | I wasn't being serious |
| 2023-11-15 22:35:02 +0100 | <int-e> | (ouch, ze german is shining srough) |
| 2023-11-15 22:35:24 +0100 | <int-e> | EvanR: really! |
| 2023-11-15 22:36:01 +0100 | <bwe> | ski: so I've got enumerateTreeFrom :: Tree a -> State (Tree (Int, a)) Int |
| 2023-11-15 22:36:06 +0100 | <ski> | iirc, Racket has `first' and `rest' |
| 2023-11-15 22:36:26 +0100 | <ski> | bwe : see what int-e said about `State s a' |
| 2023-11-15 22:37:02 +0100 | <bwe> | ski: got it |
| 2023-11-15 22:37:26 +0100 | <ski> | bwe : but yea, great that you realized that the `Int -> ' gets absorbed/abstracted into `State' :) |
| 2023-11-15 22:38:00 +0100 | <ski> | so .. taking int-e into account, what do you get ? |
| 2023-11-15 22:38:11 +0100 | <bwe> | enumerateTreeFrom :: Tree a -> State Int (Tree (Int, a)) |
| 2023-11-15 22:38:15 +0100 | int-e | feels so used |
| 2023-11-15 22:38:15 +0100 | <ski> | right |
| 2023-11-15 22:38:22 +0100 | <int-e> | (scnr, carry on) |
| 2023-11-15 22:38:42 +0100 | ski | fills int-e's account |
| 2023-11-15 22:38:44 +0100 | <bwe> | ski: so `n` disappears as argument |
| 2023-11-15 22:38:48 +0100 | <ski> | yes |
| 2023-11-15 22:38:59 +0100 | <ski> | we want to hide the state/counter |
| 2023-11-15 22:39:11 +0100 | <bwe> | now enumerateTreeFrom returns State Int (Tree (Int, a)) |
| 2023-11-15 22:39:17 +0100 | <ski> | right |
| 2023-11-15 22:39:25 +0100 | <bwe> | therefore (l', n1) = no longer works |
| 2023-11-15 22:39:47 +0100 | <ski> | so, now you must use either `>>=' or `do' (or, well, `<*>' could also work, i guess ..) |
| 2023-11-15 22:39:53 +0100 | <ski> | correct |
| 2023-11-15 22:40:03 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:30a6:1819:aaf8:7ae3) |
| 2023-11-15 22:40:11 +0100 | <ski> | if you write |
| 2023-11-15 22:40:43 +0100 | <ski> | t <- enumerateTreeFromS l |
| 2023-11-15 22:41:23 +0100 | sabino | (~sabino@user/sabino) (Ping timeout: 268 seconds) |
| 2023-11-15 22:41:28 +0100 | <ski> | inside `do', then `enumerateTreeFromS l' is an `State Int (Tree (Int, a))' (as you said), and so `t' will become a `Tree (Int,a)' (since that's the "result type" part of the `State' .. the `a' in `State s a') |
| 2023-11-15 22:41:34 +0100 | <ski> | you could also write |
| 2023-11-15 22:41:43 +0100 | <ski> | enumerateTreeFromS l >>= \t -> |
| 2023-11-15 22:41:50 +0100 | <ski> | (and not use `do') |
| 2023-11-15 22:42:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:a1fe:14ba:659d:abed) (Ping timeout: 268 seconds) |
| 2023-11-15 22:42:10 +0100 | <ski> | (so, i guess, t here should be renamed to .. what ?) |
| 2023-11-15 22:42:19 +0100 | sabino | (~sabino@user/sabino) |
| 2023-11-15 22:42:40 +0100 | <bwe> | l' |
| 2023-11-15 22:42:50 +0100 | <ski> | yep :b |
| 2023-11-15 22:43:15 +0100 | <ski> | (i said `t' on purpose, to try to make you think about it) |
| 2023-11-15 22:43:19 +0100 | <bwe> | :) |
| 2023-11-15 22:44:00 +0100 | <bwe> | what about the tickS? |
| 2023-11-15 22:44:00 +0100 | <ski> | so, perhaps you've got *some* idea now for how to write at least *some* parts of `enumerateTreeFromS' ? |
| 2023-11-15 22:44:04 +0100 | qqq | (~qqq@92.43.167.61) |
| 2023-11-15 22:44:27 +0100 | <ski> | the input counter state disappears from sight. also the output counter state |
| 2023-11-15 22:44:41 +0100 | <ski> | (l',n1) = enumerateTreeFrom n l |
| 2023-11-15 22:44:46 +0100 | <ski> | became |
| 2023-11-15 22:44:56 +0100 | <ski> | l' <- enumerateTreeFromS l |
| 2023-11-15 22:44:57 +0100 | <ski> | and so |
| 2023-11-15 22:45:11 +0100 | <ski> | (n2',n3) = tick n2 |
| 2023-11-15 22:45:15 +0100 | <ski> | becomes .. what ? |
| 2023-11-15 22:45:22 +0100 | <bwe> | n2' <- tickS |
| 2023-11-15 22:45:27 +0100 | ski | nods |
| 2023-11-15 22:45:47 +0100 | <ski> | then you'll need something to use instead of `in' |
| 2023-11-15 22:46:53 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) |
| 2023-11-15 22:48:11 +0100 | <bwe> | that will be return I suspect |
| 2023-11-15 22:48:19 +0100 | <bwe> | the let becomes do |
| 2023-11-15 22:48:27 +0100 | <ski> | try it ? |
| 2023-11-15 22:48:53 +0100 | <ski> | (you'll also need to do something about the initial call, in the wrapper) |
| 2023-11-15 22:49:35 +0100 | <ski> | it might be helpful to define a helper function, for extracting out the state transformation function inside a `State s a' |
| 2023-11-15 22:50:55 +0100 | <ski> | (otherwise you'll need to use `case' or `let' for this, in `enumerateTree', for the initial invocation of `enumerateTreeFromS' .. well, at least if you want to *keep* the present type signature of `enumerateTree') |
| 2023-11-15 22:51:24 +0100 | <bwe> | ski: |
| 2023-11-15 22:51:54 +0100 | <bwe> | ski: the enumerateTreeFrom part compiles now, let me think of what to do about the enumerateTree |
| 2023-11-15 22:52:28 +0100 | nate4 | (~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 256 seconds) |
| 2023-11-15 22:52:41 +0100 | <bwe> | ski: I need to define it in the State ... |
| 2023-11-15 22:52:51 +0100 | <ski> | "it" referring to ? |
| 2023-11-15 22:53:10 +0100 | <bwe> | the helper function extracting the state transformation function inside State s a |
| 2023-11-15 22:54:11 +0100 | <ski> | yea, the helper/worker, `enumerateTreeFromS', is in `State' |
| 2023-11-15 22:55:09 +0100 | <bwe> | newtype State s a = MkState { runState :: s -> (a,s) } ? |
| 2023-11-15 22:55:51 +0100 | <ski> | sure, that would work |
| 2023-11-15 22:56:06 +0100 | <EvanR> | that's a good looking newtype if I ever seen one |
| 2023-11-15 22:56:11 +0100 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) (Server closed connection) |
| 2023-11-15 22:56:19 +0100 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) |
| 2023-11-15 22:58:53 +0100 | Hooloovoo | (~Hooloovoo@hax0rbana.org) |
| 2023-11-15 22:59:46 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2023-11-15 23:00:13 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-11-15 23:04:01 +0100 | <EvanR> | that field notation was confusing to me at first, since really runState :: State s a -> s -> (a,s), directly contradicting that notation |
| 2023-11-15 23:04:15 +0100 | CiaoSen | (~Jura@2a05:5800:289:5000:2a3a:4dff:fe84:dbd5) |
| 2023-11-15 23:05:16 +0100 | <ski> | yea. imho, SML got the field extraction better |
| 2023-11-15 23:05:29 +0100 | drlkf | (~drlkf@192.184.163.34.bc.googleusercontent.com) (Server closed connection) |
| 2023-11-15 23:05:35 +0100 | <ski> | if `x' is a field, then `#x' is the function that extracts that field |
| 2023-11-15 23:05:52 +0100 | <EvanR> | which I now know we can emulate with enough extensions and stuff |
| 2023-11-15 23:05:53 +0100 | <ski> | (this is one of the warts in Haskell, imho) |
| 2023-11-15 23:05:54 +0100 | drlkf | (~drlkf@192.184.163.34.bc.googleusercontent.com) |
| 2023-11-15 23:06:37 +0100 | <ski> | (and tuples are just records whose field names are consecutive integers counting up .. unfortunately from one, not from zero) |
| 2023-11-15 23:07:18 +0100 | <EvanR> | oh, you can use #1 with (a,b) and (a,b,c)? |
| 2023-11-15 23:07:25 +0100 | <ski> | note that punning of field names is less useful, due to this unfortunate reuse of the same name for the extraction function |
| 2023-11-15 23:07:29 +0100 | <ski> | yes |
| 2023-11-15 23:07:36 +0100 | <EvanR> | wicked |
| 2023-11-15 23:10:21 +0100 | <ski> | (the types are called `a * b' resp. `a * b * c', though (and those are really `{0 : a,1 : b}' resp. `{0 : a,1 : b,2 : c}') .. another misdesign in Haskell, noticable with `DataKinds' and also with attempts to add dependent types. what if i want to define a *type* having a parameter which is a tuple (not a tuple type) of types ?) |
| 2023-11-15 23:11:58 +0100 | <ski> | (having type parameters be records of types would also be handy for certain situations .. if all the types have the same kind you can express it differently, via a GADT indexed by a `data' type enumerating the record fields) |
| 2023-11-15 23:12:20 +0100 | ski | looks at bwe |
| 2023-11-15 23:12:50 +0100 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:30a6:1819:aaf8:7ae3) (Ping timeout: 268 seconds) |
| 2023-11-15 23:13:14 +0100 | <ski> | (well, i should say, if all those types are `data' types over which definition you have control) |
| 2023-11-15 23:13:20 +0100 | <bwe> | ski: hm, I need to initialise the state with 0 |
| 2023-11-15 23:13:25 +0100 | <ski> | right |
| 2023-11-15 23:13:32 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2023-11-15 23:13:41 +0100 | <ski> | so `runState' will extract the state transformation function for you |
| 2023-11-15 23:13:50 +0100 | <ski> | then you just need to pass in the initial state |
| 2023-11-15 23:14:01 +0100 | <bwe> | runState 0 |
| 2023-11-15 23:14:11 +0100 | <ski> | here you get |
| 2023-11-15 23:14:21 +0100 | <ski> | runState :: State s a -> (s -> (a,s)) |
| 2023-11-15 23:14:24 +0100 | <ski> | or, if you prefer |
| 2023-11-15 23:14:28 +0100 | <ski> | runState :: State s a -> s -> (a,s) |
| 2023-11-15 23:16:01 +0100 | <ski> | (so not `runState 0', but .. ?) |
| 2023-11-15 23:16:25 +0100 | Pickchea | (~private@user/pickchea) |
| 2023-11-15 23:17:51 +0100 | <bwe> | MkState 0 |
| 2023-11-15 23:18:04 +0100 | <bwe> | runState (MkState 0) |
| 2023-11-15 23:18:32 +0100 | <bwe> | let me type hole that |
| 2023-11-15 23:18:50 +0100 | <ski> | what's the top invocation that you want to pass of the initial state to ? |
| 2023-11-15 23:19:05 +0100 | <bwe> | runState _ >>= enumerateTreeFrom |
| 2023-11-15 23:19:18 +0100 | <bwe> | Found hole: _ :: State s0 a1 |
| 2023-11-15 23:19:44 +0100 | <ski> | what's the type of `enumerateTreeFromS' ? |
| 2023-11-15 23:20:01 +0100 | <bwe> | Tree a -> State Int (Tree (Int, a)) |
| 2023-11-15 23:20:29 +0100 | <ski> | so, how do you invoke it ? |
| 2023-11-15 23:20:41 +0100 | <ski> | (in `enumerateTree') |
| 2023-11-15 23:21:50 +0100 | <bwe> | I need to put in the abstraction that abstracts away the counter |
| 2023-11-15 23:22:30 +0100 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) |
| 2023-11-15 23:22:49 +0100 | <bwe> | wait |
| 2023-11-15 23:22:57 +0100 | <ski> | well, if `enumerateTreeFromS' is a function (of type `Tree a -> State Int (Tree (Int, a))') you probably should pass it an argument, at least, right ? |
| 2023-11-15 23:24:58 +0100 | michalz | (~michalz@185.246.207.193) (Remote host closed the connection) |
| 2023-11-15 23:25:57 +0100 | <bwe> | I should give it Tree a |
| 2023-11-15 23:26:22 +0100 | <ski> | yes. which tree ? |
| 2023-11-15 23:26:41 +0100 | <bwe> | well the original input |
| 2023-11-15 23:26:44 +0100 | <ski> | yes |
| 2023-11-15 23:27:02 +0100 | <ski> | dunno what you call that .. let's say `t' |
| 2023-11-15 23:27:17 +0100 | <ski> | so, you then have `enumerateTreeFromS t', which has type `State Int (Tree (Int, a))' |
| 2023-11-15 23:27:29 +0100 | <ski> | what do you do know, to *use* this result ? |
| 2023-11-15 23:27:33 +0100 | <ski> | s/know/now/ |
| 2023-11-15 23:28:21 +0100 | <bwe> | enumerateTree order t = runState (enumerateTreeFrom t) 0 |
| 2023-11-15 23:28:23 +0100 | <ski> | well .. you do want to get the labelled tree "out" somehow right ? |
| 2023-11-15 23:28:32 +0100 | <ski> | yep ! |
| 2023-11-15 23:28:50 +0100 | <ski> | sometimes, i'd spell that as |
| 2023-11-15 23:28:56 +0100 | <bwe> | I still don't comprehend that but let me think that through the other day |
| 2023-11-15 23:29:03 +0100 | <ski> | enumerateTree order t = enumerateTreeFrom t `runState` 0 |
| 2023-11-15 23:29:10 +0100 | <ski> | but that's more a matter of taste thing |
| 2023-11-15 23:29:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-15 23:29:30 +0100 | <ski> | `runState' supplies the "hidden state input", giving you back the pair of the result and the hidden state output |
| 2023-11-15 23:29:43 +0100 | <ski> | right |
| 2023-11-15 23:29:57 +0100 | <ski> | bwe : does the code type-check now ? |
| 2023-11-15 23:30:12 +0100 | <bwe> | yup |
| 2023-11-15 23:30:16 +0100 | <ski> | does it work ? |
| 2023-11-15 23:30:26 +0100 | <ski> | (at least for my given example tree, say ?) |
| 2023-11-15 23:32:36 +0100 | qqq | (~qqq@92.43.167.61) (Ping timeout: 246 seconds) |
| 2023-11-15 23:36:09 +0100 | <bwe> | no, it fails with No instance nor default method for class operation pure |
| 2023-11-15 23:37:00 +0100 | <ski> | ah, right. you didn't define `return' |
| 2023-11-15 23:37:19 +0100 | <bwe> | where? |
| 2023-11-15 23:37:30 +0100 | <ski> | (nor `pure' in `Applicative' .. they're the same operation, have different names because of hysterical raisins) |
| 2023-11-15 23:37:32 +0100 | <bwe> | I need to leave now unfortunately |
| 2023-11-15 23:37:51 +0100 | <ski> | in `instance Monad (State s) where ...' |
| 2023-11-15 23:38:16 +0100 | <ski> | `return' is supposed to "do nothing, apart from just giving back the argument as result", btw |
| 2023-11-15 23:38:29 +0100 | <ski> | return :: a -> State s a |
| 2023-11-15 23:38:31 +0100 | <ski> | in your case |
| 2023-11-15 23:38:54 +0100 | <ski> | bwe : yea, i hope this has helped at least some |
| 2023-11-15 23:39:13 +0100 | <bwe> | quite a lot |
| 2023-11-15 23:39:22 +0100 | <bwe> | I enjoyed it very much |
| 2023-11-15 23:39:36 +0100 | <bwe> | ski: thank you very much |
| 2023-11-15 23:39:49 +0100 | qqq | (~qqq@92.43.167.61) |
| 2023-11-15 23:39:54 +0100 | <ski> | yw |
| 2023-11-15 23:39:54 +0100 | <bwe> | ski: care if we continue where we left another time? |
| 2023-11-15 23:39:57 +0100 | ski | bows |
| 2023-11-15 23:40:00 +0100 | <ski> | sure |
| 2023-11-15 23:40:14 +0100 | <bwe> | awesome :) |
| 2023-11-15 23:41:31 +0100 | acidjnk | (~acidjnk@p200300d6e72b9310fd221caae09ed082.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2023-11-15 23:43:52 +0100 | Guest|66 | (~Guest|66@73.110.126.92) |
| 2023-11-15 23:44:36 +0100 | qqq | (~qqq@92.43.167.61) (Ping timeout: 256 seconds) |
| 2023-11-15 23:44:48 +0100 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-11-15 23:45:30 +0100 | qqq | (~qqq@92.43.167.61) |
| 2023-11-15 23:47:45 +0100 | edmundnoble_ | (sid229620@id-229620.helmsley.irccloud.com) (Server closed connection) |
| 2023-11-15 23:47:54 +0100 | edmundnoble_ | (sid229620@id-229620.helmsley.irccloud.com) |
| 2023-11-15 23:49:05 +0100 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2023-11-15 23:49:08 +0100 | Jackneill | (~Jackneill@20014C4E1E1AA200A8C1C5D762EA8C40.dsl.pool.telekom.hu) (Ping timeout: 256 seconds) |
| 2023-11-15 23:49:18 +0100 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
| 2023-11-15 23:49:44 +0100 | Guest|66 | (~Guest|66@73.110.126.92) (Quit: Connection closed) |
| 2023-11-15 23:49:45 +0100 | wroathe | (~wroathe@50.205.197.50) |
| 2023-11-15 23:49:45 +0100 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-11-15 23:49:45 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2023-11-15 23:50:14 +0100 | <dibblego> | Does this function exist anywhere? readerState :: Functor f => ReaderT r f a -> StateT r f a; readerState (ReaderT r) = StateT (\s -> fmap (\a -> (a, s)) (r s)) |
| 2023-11-15 23:51:11 +0100 | <ski> | not that i know (but i've played around with it, and related things, privately, before) |
| 2023-11-15 23:51:21 +0100 | thegeekinside | (~thegeekin@189.180.53.210) |
| 2023-11-15 23:51:55 +0100 | <Axman6> | feels related to local, at least in intent |
| 2023-11-15 23:52:10 +0100 | <ski> | (we have two monads, with one being embeddable inside the other, more or less. we get stuff like `m a -> (a -> n b) -> n b') |
| 2023-11-15 23:52:29 +0100 | <dibblego> | it could half-nicer with something :: MonadState s f => (s -> f a) -> f a |
| 2023-11-15 23:53:55 +0100 | sabino | (~sabino@user/sabino) (Quit: Lambda _ -> x) |
| 2023-11-15 23:54:43 +0100 | <ski> | (`m' can be `Reader rs' and `n' be `State rs'. or `m' can be `Maybe' and `n' be `[]' ..) |
| 2023-11-15 23:55:21 +0100 | <ski> | dibblego : hm, not seeing how `something' is comparable ? |
| 2023-11-15 23:55:37 +0100 | <dibblego> | would just be slightly nicer to write |
| 2023-11-15 23:56:43 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-11-15 23:56:48 +0100 | <ski> | `readerState' copies over the current state as the resulting state. `something' just read the state, no ? |
| 2023-11-15 23:57:08 +0100 | <ski> | (kinda like `asks') |
| 2023-11-15 23:57:38 +0100 | <probie> | :t (&&& returnA) |
| 2023-11-15 23:57:39 +0100 | <lambdabot> | Arrow a => a c' c -> a c' (c, c') |
| 2023-11-15 23:58:13 +0100 | acidjnk | (~acidjnk@p200300d6e72b93446103f524bf4ee276.dip0.t-ipconnect.de) |
| 2023-11-15 23:58:30 +0100 | <ski> | @type sized |
| 2023-11-15 23:58:31 +0100 | <lambdabot> | (Int -> Gen a) -> Gen a |
| 2023-11-15 23:58:37 +0100 | johnw_ | (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in) |