| 2022-09-24 00:05:08 +0200 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2022-09-24 00:12:30 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-09-24 00:15:54 +0200 | Hafydd | (jc@user/hafydd) |
| 2022-09-24 00:19:06 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-09-24 00:20:55 +0200 | johnjaye | (~pi@173.209.64.74) (Ping timeout: 246 seconds) |
| 2022-09-24 00:22:56 +0200 | johnjaye | (~pi@173.209.64.74) |
| 2022-09-24 00:25:14 +0200 | valzant | (~parsival@209.141.195.79) |
| 2022-09-24 00:26:07 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 00:26:30 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2022-09-24 00:28:06 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 244 seconds) |
| 2022-09-24 00:29:20 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection) |
| 2022-09-24 00:29:43 +0200 | valzant | (~parsival@209.141.195.79) (Ping timeout: 268 seconds) |
| 2022-09-24 00:32:12 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-09-24 00:33:05 +0200 | ober_ | (~ober@71.235.16.183) (Quit: Leaving) |
| 2022-09-24 00:43:34 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-09-24 00:44:53 +0200 | _bo | (~aoeu@196.red-81-43-248.staticip.rima-tde.net) (Remote host closed the connection) |
| 2022-09-24 00:47:30 +0200 | califax | (~califax@user/califx) |
| 2022-09-24 00:54:25 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Remote host closed the connection) |
| 2022-09-24 00:56:01 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 01:00:28 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 246 seconds) |
| 2022-09-24 01:03:28 +0200 | berberman_ | (~berberman@user/berberman) |
| 2022-09-24 01:04:19 +0200 | berberman | (~berberman@user/berberman) (Ping timeout: 246 seconds) |
| 2022-09-24 01:06:13 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-09-24 01:06:38 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-09-24 01:07:55 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-09-24 01:08:17 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) |
| 2022-09-24 01:19:38 +0200 | emmanuelux | (~emmanuelu@2a01cb0000f39300d565fcaab8cd0e44.ipv6.abo.wanadoo.fr) |
| 2022-09-24 01:27:48 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 01:28:47 +0200 | bontaq` | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-09-24 01:29:10 +0200 | edrx | (~Eduardo@2804:56c:d2dc:ac00:dab8:211d:d4eb:fa94) |
| 2022-09-24 01:33:13 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 265 seconds) |
| 2022-09-24 01:41:59 +0200 | thyriaen | (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce) (Quit: Leaving) |
| 2022-09-24 01:46:19 +0200 | beteigeuze | (~Thunderbi@p5090d00a.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-09-24 01:49:21 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-09-24 02:00:04 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2022-09-24 02:01:34 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 02:04:52 +0200 | berberman_ | (~berberman@user/berberman) (Ping timeout: 246 seconds) |
| 2022-09-24 02:04:54 +0200 | berberman | (~berberman@user/berberman) |
| 2022-09-24 02:08:20 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 252 seconds) |
| 2022-09-24 02:08:20 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 02:08:22 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:a8f6:62e0:a0fa:7808) (Ping timeout: 246 seconds) |
| 2022-09-24 02:09:13 +0200 | EashanHatti | (~Thunderbi@c-24-126-44-70.hsd1.wv.comcast.net) () |
| 2022-09-24 02:11:48 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 264 seconds) |
| 2022-09-24 02:14:48 +0200 | son0p | (~ff@2800:e2:f80:867:cac2:6501:5166:e177) (Ping timeout: 264 seconds) |
| 2022-09-24 02:15:46 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2022-09-24 02:16:00 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:3490:26c5:1782:da8c) (Ping timeout: 264 seconds) |
| 2022-09-24 02:17:02 +0200 | TonyStone | (~TonyStone@2603-7080-8607-c36a-61f2-c7b2-cd95-6846.res6.spectrum.com) (Remote host closed the connection) |
| 2022-09-24 02:18:46 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-09-24 02:19:58 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 02:20:20 +0200 | ddellacosta | (~ddellacos@143.244.47.100) |
| 2022-09-24 02:26:15 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-09-24 02:35:39 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) |
| 2022-09-24 02:40:05 +0200 | auri | (~auri@fsf/member/auri) () |
| 2022-09-24 02:45:44 +0200 | Batzy_ | Batzy |
| 2022-09-24 02:48:09 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 258 seconds) |
| 2022-09-24 02:49:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-09-24 02:52:24 +0200 | auri | (~auri@fsf/member/auri) |
| 2022-09-24 02:59:49 +0200 | Guest85 | (~Guest85@45.144.115.145) |
| 2022-09-24 03:00:26 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 03:00:27 +0200 | <Guest85> | | coor == [] = show print |
| 2022-09-24 03:00:27 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 03:00:28 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 03:00:28 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 03:00:29 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 03:00:29 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y (print++[x]) |
| 2022-09-24 03:00:30 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y (print++[y]) |
| 2022-09-24 03:00:30 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 03:00:40 +0200 | <Guest85> | why does this get "Non-exhaustive patterns in function interpreter" |
| 2022-09-24 03:00:42 +0200 | <Guest85> | ? |
| 2022-09-24 03:02:23 +0200 | <geekosaur> | because it doesn't handle an empty list of coordinates |
| 2022-09-24 03:02:31 +0200 | <geekosaur> | (cood:coors) must be nonempty |
| 2022-09-24 03:02:39 +0200 | <geekosaur> | *(coor:coors) |
| 2022-09-24 03:03:40 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 246 seconds) |
| 2022-09-24 03:03:46 +0200 | <dsal> | I think I'd get rid of the explicit recursion there and just use fold. |
| 2022-09-24 03:04:43 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 03:04:46 +0200 | <EvanR> | as is the algorithm will crash when (if) the stream of instructions ends |
| 2022-09-24 03:05:12 +0200 | <EvanR> | if it's supposed to be infinite you could shut it up by using a Stream |
| 2022-09-24 03:05:19 +0200 | <ski> | may be good recursion practice |
| 2022-09-24 03:06:08 +0200 | <Guest85> | I thought that's what I was doing, recursion through the coordinate list |
| 2022-09-24 03:06:13 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 03:06:26 +0200 | <EvanR> | try running it on an empty list |
| 2022-09-24 03:06:30 +0200 | <Guest85> | | (coor:coors) == [] = show print I changed it to that and still get the non-exhaustive patterns error |
| 2022-09-24 03:06:41 +0200 | <dsal> | Yeah, you are. I'd just not have done the recursion explicitly. I think it'd be clearer. |
| 2022-09-24 03:06:43 +0200 | <Guest85> | how would I use fold instead? |
| 2022-09-24 03:06:47 +0200 | <ski> | `coor == []' is testing if the first string is the empty string. not testing if you're fed an empty list of strings |
| 2022-09-24 03:06:50 +0200 | <EvanR> | (coor:coords) == [] is impossible |
| 2022-09-24 03:06:53 +0200 | <dsal> | Guest85: In order to construct (coor:coors) you'd still have to have `coor` and `coors` |
| 2022-09-24 03:06:57 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-09-24 03:06:57 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-09-24 03:06:57 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-24 03:07:09 +0200 | <dsal> | (well, `coors` could be `[]`) |
| 2022-09-24 03:07:28 +0200 | <EvanR> | : and [] are two different constructors |
| 2022-09-24 03:07:34 +0200 | <EvanR> | it's like saying 0 == 1 |
| 2022-09-24 03:08:03 +0200 | <dsal> | Guest85: It'd be good to understand what you've got now. But you basically have three state variables you're keeping and your updating one of them each time you get to a particular string, so `move :: String -> State -> State` |
| 2022-09-24 03:08:17 +0200 | <ski> | > (coor:coords) == [] |
| 2022-09-24 03:08:19 +0200 | <lambdabot> | False |
| 2022-09-24 03:09:15 +0200 | <dsal> | Then you could write `move "left" state = state{x = x - 1}` and then just fold over that. |
| 2022-09-24 03:10:33 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-09-24 03:11:01 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 03:11:04 +0200 | <dsal> | Alternatively, you could just get rid of the guards and write `interpreter' [] _ _ p = show p; interpreter' ("left":xs) x y p = interpreter' (x - 1) y p; ...` -- that might make it clearer. |
| 2022-09-24 03:11:31 +0200 | <dsal> | (er, I didn't recurse there, but something like that) |
| 2022-09-24 03:12:44 +0200 | <dsal> | I just find it easier to think about, build, and test the "how do you do one thing" part and then build something to do the "how do you do many things" on top of that. |
| 2022-09-24 03:13:45 +0200 | ddellacosta | (~ddellacos@143.244.47.100) (Ping timeout: 265 seconds) |
| 2022-09-24 03:15:06 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 03:15:07 +0200 | <Guest85> | | coor == [] = show print |
| 2022-09-24 03:15:07 +0200 | <Guest85> | | coors == [] = show print |
| 2022-09-24 03:15:08 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 03:15:08 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 03:15:09 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 03:15:09 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 03:15:10 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y (print++[x]) |
| 2022-09-24 03:15:10 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y (print++[y]) |
| 2022-09-24 03:15:11 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 03:15:32 +0200 | <ski> | please use more than one defining equation |
| 2022-09-24 03:15:43 +0200 | <ski> | (like dsal suggested) |
| 2022-09-24 03:15:57 +0200 | <Guest85> | rather than guards? |
| 2022-09-24 03:16:00 +0200 | <Guest85> | *Set3a> interpreter' ["up","up","right","right","right","printY","printX","printX","printY"] 0 0 [] |
| 2022-09-24 03:16:01 +0200 | <Guest85> | "[2,3,3]" |
| 2022-09-24 03:16:05 +0200 | <Guest85> | doesn't show the last print |
| 2022-09-24 03:16:34 +0200 | <ski> | you could use guards for the strings, still .. although i think it's better (clearer) to not use guards for those, either |
| 2022-09-24 03:16:39 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-09-24 03:16:57 +0200 | <dsal> | Guest85: You're telling it not to run the last one. |
| 2022-09-24 03:17:00 +0200 | <ski> | "doesn't show the last print" -- because your termination condition is incorrect |
| 2022-09-24 03:18:25 +0200 | <ski> | if you're checking `coors' for being empty, you're not checking whether the input list is empty. you're checking whether its *tail* is empty. so, when you then stop, you're ignoring `coor', which is then the last element |
| 2022-09-24 03:18:34 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 03:18:35 +0200 | qrpnxz | (~qrpnxz@fsf/member/qrpnxz) (Quit: WeeChat 3.5) |
| 2022-09-24 03:19:03 +0200 | <geekosaur> | `coors = []` means stop before the last item. you need to check if the list is empty as opposed to bveing (coor:coors) — by the time you hit that it is too late |
| 2022-09-24 03:19:27 +0200 | <EvanR> | coor:coords doesn't match [] |
| 2022-09-24 03:19:43 +0200 | <ski> | `coor:coors', in this defining equation, is the input list (which is required to be non-empty, because the pattern `coor:coors' only match non-empty lists). `coor' is the current element, and `coors' is the list of elements after the current ones |
| 2022-09-24 03:21:16 +0200 | <ski> | Guest85 : have you defined simpler list recursions ? |
| 2022-09-24 03:22:03 +0200 | <Guest85> | interpreter' [] x y print = [] |
| 2022-09-24 03:22:11 +0200 | <Guest85> | put that as a second defining equation |
| 2022-09-24 03:22:20 +0200 | <ski> | good |
| 2022-09-24 03:22:31 +0200 | <Guest85> | | coor == [] = show print |
| 2022-09-24 03:22:39 +0200 | <Guest85> | kept that as the termination condition |
| 2022-09-24 03:22:45 +0200 | <Guest85> | *Set3a> interpreter' ["up","up","right","right","right","printY","printX","printX","printY"] 0 0 [] |
| 2022-09-24 03:22:46 +0200 | <Guest85> | "" |
| 2022-09-24 03:22:50 +0200 | <ski> | (i'd put it first .. but it doesn't really matter, in this case, except for style/aesthetic reasons) |
| 2022-09-24 03:23:01 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 03:23:34 +0200 | <ski> | well, you're now ignoring your carefully built up "result so far", in that base case |
| 2022-09-24 03:23:37 +0200 | vglfr | (~vglfr@145.224.100.249) (Ping timeout: 246 seconds) |
| 2022-09-24 03:23:39 +0200 | <ski> | namely `print' is ignored |
| 2022-09-24 03:25:07 +0200 | <Guest85> | I'm stumped.. how is it being ignored? |
| 2022-09-24 03:25:19 +0200 | <ski> | your result is literally `[]' |
| 2022-09-24 03:25:25 +0200 | <ski> | `print' is not mentioned in the result |
| 2022-09-24 03:25:39 +0200 | <ski> | so, `print' is getting ignored, in your base case defining equation |
| 2022-09-24 03:26:18 +0200 | <ski> | interpreter' [] x y print = [] |
| 2022-09-24 03:26:19 +0200 | <ski> | ^^ |
| 2022-09-24 03:26:25 +0200 | <ski> | that result |
| 2022-09-24 03:27:38 +0200 | <Guest85> | ok I see that, maybe I can't use guards with this |
| 2022-09-24 03:27:52 +0200 | <ski> | you can. that is unrelated to this issue |
| 2022-09-24 03:28:10 +0200 | ski | wouldn't use guards here |
| 2022-09-24 03:28:13 +0200 | <ski> | but you can, if you want to |
| 2022-09-24 03:28:21 +0200 | Null_A_ | (~null_a@2601:645:8700:ac10:1005:19fc:119b:3387) (Remote host closed the connection) |
| 2022-09-24 03:28:32 +0200 | <monochrom> | I'm going to comment on the higher-level issue. |
| 2022-09-24 03:28:56 +0200 | Null_A | (~null_a@2601:645:8700:ac10:c06c:ee8:e627:7270) |
| 2022-09-24 03:29:26 +0200 | <Guest85> | ok so I made the base case = show print |
| 2022-09-24 03:29:28 +0200 | <Guest85> | works now |
| 2022-09-24 03:29:58 +0200 | <Guest85> | finally lol, thanks for the help |
| 2022-09-24 03:30:01 +0200 | Null_A_ | (~null_a@2601:645:8700:ac10:588d:dcc4:cf71:c2f0) |
| 2022-09-24 03:30:30 +0200 | <ski> | it's also not good to repeatedly add to the end of `print' |
| 2022-09-24 03:30:32 +0200 | <Guest85> | I'll look at the other methods dsal mentioned |
| 2022-09-24 03:30:48 +0200 | <ski> | that will cause quadratic complexity, rather than the expected linear one |
| 2022-09-24 03:31:51 +0200 | <Guest85> | not familiar with that term. is it not optimized this way? |
| 2022-09-24 03:32:03 +0200 | <dsal> | Guest85: your should definitely understand what you've got there in any case |
| 2022-09-24 03:32:35 +0200 | <ski> | the reason is that if you have `(((as ++ bs) ++ cs) ++ ds) ++ es', then the innermost (leftmost) `++' will first traverse `as', making a copy of its cons cells, putting `bs' at the end of that (without traversing `bs') |
| 2022-09-24 03:33:08 +0200 | <ski> | then the next `++' will traverse the result of `as ++ bs'. so, effectively traversing `as' again (well, the copy of `as', but it's the same length), and then also `bs' |
| 2022-09-24 03:33:34 +0200 | jrm | (~jrm@user/jrm) (Read error: Connection reset by peer) |
| 2022-09-24 03:33:36 +0200 | Null_A | (~null_a@2601:645:8700:ac10:c06c:ee8:e627:7270) (Ping timeout: 244 seconds) |
| 2022-09-24 03:33:41 +0200 | <ski> | then, the next `++' will traverse `(as ++ bs) ++ cc', so again (effectively) traversing `as' and `bs', and then also `cs' |
| 2022-09-24 03:33:50 +0200 | jrm | (~jrm@user/jrm) |
| 2022-09-24 03:34:13 +0200 | limberdelt | (~limberdel@gateway/vpn/pia/limberdelt) |
| 2022-09-24 03:34:21 +0200 | <Guest85> | what's a better way of doing it? |
| 2022-09-24 03:34:32 +0200 | <ski> | so .. in the end, you effectively end up traversing `as' four times, `bs' three times, `cs' two times', `ds' one time, and `es' zero times (all of them traversed once again, when the caller traverses the result list) |
| 2022-09-24 03:34:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 03:35:08 +0200 | <ski> | better is to do `as ++ (bs ++ (cs ++ (ds ++ es)))'. right-associated calls to `++', rather than left-associated ones |
| 2022-09-24 03:35:17 +0200 | <ski> | now, how does this relate to your definition ? |
| 2022-09-24 03:35:25 +0200 | jrm | (~jrm@user/jrm) (Read error: Connection reset by peer) |
| 2022-09-24 03:35:25 +0200 | <ski> | well, you have recursive calls like |
| 2022-09-24 03:35:28 +0200 | <Guest85> | what if I did ([x]++print) and reversed the list at the end? |
| 2022-09-24 03:35:33 +0200 | <ski> | interpreter' coors x y (print++[x]) |
| 2022-09-24 03:35:40 +0200 | jrm | (~jrm@user/jrm) |
| 2022-09-24 03:36:21 +0200 | jrm | (~jrm@user/jrm) (Remote host closed the connection) |
| 2022-09-24 03:36:29 +0200 | <ski> | so `print++[x]' becomes the new `print' in the next call, and then may get more things added to the end of it. so you'll end up with `(..(([] ++ [x0]) ++ [x1])..) ++ [xn]' |
| 2022-09-24 03:36:36 +0200 | <ski> | Guest85 : yes, that's one standard solution |
| 2022-09-24 03:37:25 +0200 | ubert1 | (~Thunderbi@91.141.58.249.wireless.dyn.drei.com) |
| 2022-09-24 03:37:40 +0200 | <ski> | in this case, there's also another straightforward solution, that is probably actually (slightly) better (more flexible, possibly a little bit more efficient, although not a huge difference, unlike the associatedness thing) in this case |
| 2022-09-24 03:38:48 +0200 | <ski> | that solution is : instead of collecting your output, keeping it all to yourself until the end, when you publish it .. you simply publish each piece of it at the time you decide it should be part of the output list |
| 2022-09-24 03:39:24 +0200 | ubert | (~Thunderbi@77.119.207.90.wireless.dyn.drei.com) (Ping timeout: 264 seconds) |
| 2022-09-24 03:39:24 +0200 | ubert1 | ubert |
| 2022-09-24 03:40:54 +0200 | <Guest85> | not sure how to accomplish that |
| 2022-09-24 03:41:09 +0200 | <ski> | (this is possible because (a) you're always publishing your list, there's no possible bailing-out at the end, in your code. so you could just as well be publishing as you go; and (b) because you're generating the output numbers in the order you want to have them in the result list (rather than say in reversed order, or in some other permutation of the order)) |
| 2022-09-24 03:41:17 +0200 | <Guest85> | change the print conditionals so they show the x and y values? how would I terminate it then |
| 2022-09-24 03:41:42 +0200 | <ski> | well .. perhaps you could first try to implement your last idea, to see through how it would work |
| 2022-09-24 03:42:03 +0200 | <ski> | it is good practice, because this can often be a useful tactic to apply |
| 2022-09-24 03:42:45 +0200 | <ski> | (it's just that, in this case, i think the alternative i was roughly sketching at, is preferrable) |
| 2022-09-24 03:43:26 +0200 | <Guest85> | I did change it to the right-associated calls with the reverse |
| 2022-09-24 03:43:43 +0200 | <ski> | where/how did you place the `reverse' ? |
| 2022-09-24 03:43:50 +0200 | <Guest85> | interpreter' [] x y print = show print |
| 2022-09-24 03:43:51 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 03:43:51 +0200 | <Guest85> | | coor == [] = show $ reverse print |
| 2022-09-24 03:43:52 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 03:43:52 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 03:43:53 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 03:43:53 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 03:43:54 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y ([x]++print) |
| 2022-09-24 03:43:54 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y ([y]++print) |
| 2022-09-24 03:43:55 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 03:43:59 +0200 | pgray__ | (~pgray@c-24-143-114-36.customer.broadstripe.net) |
| 2022-09-24 03:44:18 +0200 | <ski> | btw (unrelated), try this query : |
| 2022-09-24 03:44:25 +0200 | <ski> | *Set3a> interpreter' ["up","up","right","right","right","","printY","printX","printX","printY"] 0 0 [] |
| 2022-09-24 03:44:43 +0200 | pgray | (~pgray@c-24-143-114-36.customer.broadstripe.net) (Ping timeout: 252 seconds) |
| 2022-09-24 03:44:51 +0200 | <ski> | (also try the original query from above) |
| 2022-09-24 03:45:51 +0200 | crns | (~netcrns@user/crns) (Ping timeout: 268 seconds) |
| 2022-09-24 03:46:11 +0200 | <ski> | (well, i guess possibly a bit related) |
| 2022-09-24 03:46:31 +0200 | ski | idly wonders what comment monochrom is building up to |
| 2022-09-24 03:46:56 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 03:47:00 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-09-24 03:47:13 +0200 | <Guest85> | it trips up with the "" |
| 2022-09-24 03:47:19 +0200 | <Guest85> | *Set3a> interpreter' ["up","up","right","right","right","printY","printX","printX","printY"] 0 0 [] |
| 2022-09-24 03:47:20 +0200 | <Guest85> | "[2,3,3,2]" |
| 2022-09-24 03:47:20 +0200 | <ski> | why ? |
| 2022-09-24 03:47:25 +0200 | <Guest85> | that's correct |
| 2022-09-24 03:47:27 +0200 | crns | (~netcrns@p4ff5e2e3.dip0.t-ipconnect.de) |
| 2022-09-24 03:47:28 +0200 | crns | (~netcrns@p4ff5e2e3.dip0.t-ipconnect.de) (Changing host) |
| 2022-09-24 03:47:28 +0200 | crns | (~netcrns@user/crns) |
| 2022-09-24 03:47:56 +0200 | <ski> | why does the former trip up with the `""' ? |
| 2022-09-24 03:49:34 +0200 | <Guest85> | gets terminated hmm |
| 2022-09-24 03:51:41 +0200 | <Guest85> | fixed it |
| 2022-09-24 03:51:49 +0200 | <Guest85> | | coor == [] && coors == [] = show $ reverse print |
| 2022-09-24 03:52:34 +0200 | <ski> | how many terminating cases do you have ? |
| 2022-09-24 03:52:52 +0200 | <Guest85> | just one |
| 2022-09-24 03:52:54 +0200 | <ski> | no |
| 2022-09-24 03:52:55 +0200 | <Guest85> | interpreter' [] x y print = show print |
| 2022-09-24 03:52:56 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 03:52:56 +0200 | <Guest85> | | coor == [] && coors == [] = show $ reverse print |
| 2022-09-24 03:52:57 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 03:52:57 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 03:52:58 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 03:52:58 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 03:52:59 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y ([x]++print) |
| 2022-09-24 03:52:59 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y ([y]++print) |
| 2022-09-24 03:53:00 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 03:53:06 +0200 | <ski> | that's not just one |
| 2022-09-24 03:53:58 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Remote host closed the connection) |
| 2022-09-24 03:54:14 +0200 | <ski> | (where are the terminating cases ?) |
| 2022-09-24 03:55:12 +0200 | <Guest85> | the first equation and the first guard |
| 2022-09-24 03:55:15 +0200 | <ski> | yes |
| 2022-09-24 03:55:27 +0200 | <ski> | do you need two different terminating cases ? |
| 2022-09-24 03:55:50 +0200 | <Guest85> | if I remove the 1st equation, it gives that non-exhaustive pattern error |
| 2022-09-24 03:55:51 +0200 | <ski> | when is the first one reached ? when is the second one reached ? |
| 2022-09-24 03:56:19 +0200 | <Guest85> | if I provide an empty list |
| 2022-09-24 03:56:31 +0200 | <ski> | first or second ? |
| 2022-09-24 03:56:37 +0200 | <Guest85> | 1st. tho honestly the 1st guard looks like it should catch that too |
| 2022-09-24 03:56:50 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 244 seconds) |
| 2022-09-24 03:57:09 +0200 | <ski> | second defining equation is only used for non-empty lists. first defining equation is only used for empty lists |
| 2022-09-24 03:57:44 +0200 | <ski> | `coor:coors'is a non-empty list. there's no way, if you pass an empty list, it's going to get into that defining equation |
| 2022-09-24 03:58:07 +0200 | <ski> | (similarly, `[]' in the first defining equation is an empty list, won't match if you pass a non-empty list) |
| 2022-09-24 03:58:22 +0200 | <Guest85> | the : makes it non-empty? |
| 2022-09-24 03:58:26 +0200 | <ski> | yes |
| 2022-09-24 03:58:37 +0200 | <Guest85> | ok |
| 2022-09-24 03:58:40 +0200 | <ski> | > null [] |
| 2022-09-24 03:58:41 +0200 | <lambdabot> | True |
| 2022-09-24 03:58:50 +0200 | <ski> | > null (undefined : undefined) |
| 2022-09-24 03:58:51 +0200 | <lambdabot> | False |
| 2022-09-24 03:58:53 +0200 | limberdelt | (~limberdel@gateway/vpn/pia/limberdelt) (Quit: Leaving) |
| 2022-09-24 03:59:06 +0200 | limberdelt | (~limberdel@gateway/vpn/pia/limberdelt) |
| 2022-09-24 03:59:12 +0200 | <ski> | (works with any valid expressions in place of those two `undefined's) |
| 2022-09-24 03:59:41 +0200 | <Guest85> | gotcha |
| 2022-09-24 03:59:46 +0200 | <Guest85> | learning, thanks |
| 2022-09-24 03:59:48 +0200 | <EvanR> | this is puzzling me, I tried to move `reverse .' to the inside of the function on its right, but that changes the behavior https://paste.tomsmeding.com/qSBpMnX0 |
| 2022-09-24 04:01:08 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) |
| 2022-09-24 04:01:29 +0200 | <ski> | EvanR : `unpackChars' is recursive |
| 2022-09-24 04:01:36 +0200 | <ski> | perhaps you meant `f' to be recursive |
| 2022-09-24 04:01:45 +0200 | <EvanR> | lol yes |
| 2022-09-24 04:01:59 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) (Client Quit) |
| 2022-09-24 04:01:59 +0200 | <EvanR> | no help from the compiler there |
| 2022-09-24 04:02:25 +0200 | <ski> | (seeing what you think you wrote, instead of what you actually wrote, i imagine) |
| 2022-09-24 04:03:10 +0200 | <EvanR> | I just refused to read the code because moving `reverse .' over shouldn't change anything |
| 2022-09-24 04:03:15 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:9fc6:bfaf:da6f:bda1) |
| 2022-09-24 04:03:26 +0200 | <EvanR> | and unpackChars was working without it, despite being wrong |
| 2022-09-24 04:03:29 +0200 | <ski> | Guest85 : so, when is the second terminating case reached ? |
| 2022-09-24 04:03:37 +0200 | ski | nods |
| 2022-09-24 04:05:16 +0200 | berberman | (~berberman@user/berberman) (Ping timeout: 246 seconds) |
| 2022-09-24 04:07:25 +0200 | johnjaye | (~pi@173.209.64.74) (Ping timeout: 265 seconds) |
| 2022-09-24 04:08:10 +0200 | <Guest85> | when it has iterated through the entire list and both coor and coors are empty |
| 2022-09-24 04:08:17 +0200 | <ski> | yes |
| 2022-09-24 04:08:28 +0200 | <ski> | when is both `coor' and `coors' empty ? |
| 2022-09-24 04:09:03 +0200 | <Guest85> | it will go through it since it's recursive |
| 2022-09-24 04:09:19 +0200 | <Guest85> | until it reaches the end of the list |
| 2022-09-24 04:09:27 +0200 | <ski> | (perhaps this feels like a somewhat silly question, hard to answer without stating back the same .. but i think thinking about it may help to understand better what your code is doing) |
| 2022-09-24 04:09:31 +0200 | <ski> | no |
| 2022-09-24 04:09:52 +0200 | <ski> | at this point, the current list it is considering is `coor:coors', which is definitely not an empty list |
| 2022-09-24 04:10:21 +0200 | <ski> | it will have passed by some number of previous elements in the list, doing recursive calls on successive tails |
| 2022-09-24 04:10:35 +0200 | <ski> | but when it reaches this case, the current list tail it's looking at is not empty |
| 2022-09-24 04:10:56 +0200 | <ski> | what does the guard terminating condition say ? |
| 2022-09-24 04:11:32 +0200 | <Guest85> | coor and coors are undefined? |
| 2022-09-24 04:11:32 +0200 | <ski> | ("the end of the list" is always an empty list .. just making this clear, if perhaps it wasn't) |
| 2022-09-24 04:11:47 +0200 | <ski> | well, let's look at the guard and corresponding expression |
| 2022-09-24 04:11:58 +0200 | <ski> | | coor == [] && coors == [] = show $ reverse print |
| 2022-09-24 04:12:25 +0200 | <ski> | this triggers when the guard `coor == [] && coors == []' is `True' .. |
| 2022-09-24 04:12:30 +0200 | <ski> | .. which happens exactly when ? |
| 2022-09-24 04:13:49 +0200 | <ski> | (you basically said it before, as part of a longer statement you made) |
| 2022-09-24 04:14:07 +0200 | <Guest85> | that it iterated through it? |
| 2022-09-24 04:14:31 +0200 | <ski> | it has iterated through some number of elements (possibly zero of them), before reaching this point |
| 2022-09-24 04:15:01 +0200 | <ski> | let's say it goes into this terminating case. what must have happened, what must be true, of the current list it's looking at, for it to select this guard ? |
| 2022-09-24 04:15:26 +0200 | <ski> | (hint : it's not that the current list is empty, that's already been ruled out) |
| 2022-09-24 04:16:02 +0200 | <Guest85> | not sure |
| 2022-09-24 04:16:16 +0200 | <Guest85> | I simplified it though by removing that guard and it still works as intended |
| 2022-09-24 04:16:16 +0200 | <Guest85> | interpreter' [] x y print = show $ reverse print |
| 2022-09-24 04:16:17 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 04:16:17 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 04:16:18 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 04:16:18 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 04:16:19 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 04:16:20 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y ([x]++print) |
| 2022-09-24 04:16:20 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y ([y]++print) |
| 2022-09-24 04:16:20 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 04:16:27 +0200 | <ski> | `coor == [] && coors == []' is true when .. |
| 2022-09-24 04:16:38 +0200 | <Guest85> | coor and coors are empty |
| 2022-09-24 04:16:41 +0200 | <ski> | .. <something> and <something> is true |
| 2022-09-24 04:16:42 +0200 | <ski> | yes ! |
| 2022-09-24 04:17:22 +0200 | <ski> | that is, when the current list is `[] : []'. which is the same as `[[]]'. or, since this is a list of `String's, this is also the same as `"" : []' and as `[""]' |
| 2022-09-24 04:17:50 +0200 | <ski> | so, it would *only* select that guard, if the *last* `String' in the list was the empty `String', `""' ! |
| 2022-09-24 04:17:53 +0200 | <ski> | do you see this ? |
| 2022-09-24 04:18:10 +0200 | <dsal> | (slightly confusing since you're using a string as a list here) |
| 2022-09-24 04:18:17 +0200 | ski | nods |
| 2022-09-24 04:18:28 +0200 | <ski> | (`String's in Haskell are lists of `Char'acters) |
| 2022-09-24 04:19:55 +0200 | td_ | (~td@muedsl-82-207-238-210.citykom.de) (Ping timeout: 252 seconds) |
| 2022-09-24 04:20:47 +0200 | ski | looks at Guest85 |
| 2022-09-24 04:21:00 +0200 | <Guest85> | so it's an empty list |
| 2022-09-24 04:21:13 +0200 | <ski> | `[] : []' is not an empty list |
| 2022-09-24 04:21:34 +0200 | <ski> | it's a list containing a single element, which, yes, is an empty list/`String' |
| 2022-09-24 04:21:42 +0200 | td_ | (~td@muedsl-82-207-238-005.citykom.de) |
| 2022-09-24 04:21:54 +0200 | gff_ | (~gff@user/gff) (Ping timeout: 265 seconds) |
| 2022-09-24 04:22:22 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 04:22:25 +0200 | <ski> | and since you're traversing a list, stripping off one element at a time, it'll (eventually) get there, when the original list of `String's *ends* with the last `String' being the empty `String' |
| 2022-09-24 04:22:28 +0200 | <Guest85> | it's an empty list in a list of lists |
| 2022-09-24 04:22:32 +0200 | <ski> | yes |
| 2022-09-24 04:22:42 +0200 | <ski> | so, the guard |
| 2022-09-24 04:22:49 +0200 | <ski> | | coor == [] && coors == [] = show $ reverse print |
| 2022-09-24 04:23:08 +0200 | <ski> | was mostly useless, since you'll probably not call this function often with the last `String' being empty |
| 2022-09-24 04:23:18 +0200 | <ski> | now, consider the previous version of this guard |
| 2022-09-24 04:23:28 +0200 | <ski> | | coor == [] = show $ reverse print |
| 2022-09-24 04:23:30 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-09-24 04:23:30 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-09-24 04:23:30 +0200 | finn_elija | FinnElija |
| 2022-09-24 04:23:39 +0200 | gff_ | (~gff@user/gff) |
| 2022-09-24 04:23:51 +0200 | <ski> | this triggers when the current list, which is `coor:coors', is actually `[]:coors' |
| 2022-09-24 04:24:14 +0200 | <Guest85> | just the head of the list is empty |
| 2022-09-24 04:24:37 +0200 | <ski> | and since we have walked over some number of elements before this, this means that this case will trigger *whenever* we see an empty `String', in *any* position, in the list of `String's |
| 2022-09-24 04:24:48 +0200 | <ski> | which was why my example |
| 2022-09-24 04:24:55 +0200 | <ski> | *Set3a> interpreter' ["up","up","right","right","right","","printY","printX","printX","printY"] 0 0 [] |
| 2022-09-24 04:25:04 +0200 | <ski> | tripped over the `""', terminating too early |
| 2022-09-24 04:25:17 +0200 | <ski> | you see this now ? |
| 2022-09-24 04:25:25 +0200 | <Guest85> | yes |
| 2022-09-24 04:25:28 +0200 | <ski> | ok, good |
| 2022-09-24 04:25:40 +0200 | ftoy | (~fucktoy@S01069050ca4e3573.cg.shawcable.net) |
| 2022-09-24 04:25:42 +0200 | <ftoy> | hello boys |
| 2022-09-24 04:25:42 +0200 | <ski> | now, your last attempted change above, is the correct one |
| 2022-09-24 04:26:00 +0200 | <ski> | we don't need to terminate when we see an empty `String' at the end of the list |
| 2022-09-24 04:26:14 +0200 | <ski> | and we certainly don't need to terminate whenever we see an empty `String' anywhere in the list |
| 2022-09-24 04:26:26 +0200 | <ski> | we would like to terminate when there's no more elements to process |
| 2022-09-24 04:26:33 +0200 | <ski> | which is exactly what the other terminating case |
| 2022-09-24 04:26:38 +0200 | <ski> | interpreter' [] x y print = show $ reverse print |
| 2022-09-24 04:26:39 +0200 | <ski> | does |
| 2022-09-24 04:26:53 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-24 04:27:27 +0200 | <ski> | (we reach this, after handing some number of previous elements, as long as there was no other terminating case that we reached first, stopping us from getting to the very end, and stopping with this case there) |
| 2022-09-24 04:27:33 +0200 | <ski> | hello ftoy |
| 2022-09-24 04:27:48 +0200 | <ski> | (s/handing/handling/) |
| 2022-09-24 04:28:07 +0200 | <ski> | Guest85 : next question. how/where do you call interpreter' in your code ? |
| 2022-09-24 04:28:09 +0200 | <Guest85> | ok thanks ski for the detailed explanation, have a better understanding now |
| 2022-09-24 04:28:26 +0200 | <Guest85> | I call it throughout |
| 2022-09-24 04:28:33 +0200 | <ski> | in many places ? |
| 2022-09-24 04:28:56 +0200 | <ski> | do you always call it like |
| 2022-09-24 04:29:06 +0200 | <ski> | interpreter' <some list here> 0 0 [] |
| 2022-09-24 04:29:06 +0200 | <ski> | ? |
| 2022-09-24 04:29:17 +0200 | <Guest85> | it's going to be a helper function |
| 2022-09-24 04:29:25 +0200 | <ski> | is there any interpreter (without a prime) ? |
| 2022-09-24 04:29:35 +0200 | ski | nods |
| 2022-09-24 04:30:03 +0200 | <ski> | so this helper is only (directly) called from a worker/wrapper function, correct ? |
| 2022-09-24 04:30:11 +0200 | <Guest85> | correct |
| 2022-09-24 04:30:47 +0200 | <ski> | could you show how it is calling the above function ? |
| 2022-09-24 04:31:18 +0200 | <ski> | (i'd like to make a specific point, regarding this, and what you did, above) |
| 2022-09-24 04:31:46 +0200 | <Guest85> | interpreter x = interpreter' x 0 0 [] |
| 2022-09-24 04:31:49 +0200 | <ski> | good |
| 2022-09-24 04:32:11 +0200 | <ftoy> | ski: wow, youre sure smart |
| 2022-09-24 04:32:13 +0200 | <ski> | it's good practice to isolate the initialization of "worker parameters" (accumulators, here), in this way |
| 2022-09-24 04:32:25 +0200 | <ski> | now, i wanted to say : |
| 2022-09-24 04:33:12 +0200 | <ski> | instead of placing your terminating action (finally reversing the list at the end), in the terminating case(s) of the helper/worker, you *could* also have put that in the wrapper |
| 2022-09-24 04:33:30 +0200 | <ski> | (sorry, before i said "worker/wrapper". it's the helper which is the worker. the wrapper is not) |
| 2022-09-24 04:34:29 +0200 | <ski> | in your case, since the `reverse' happens to `print' before you pass it to `show', you'd then also have to move the `show' to the wrapper .. but that would be ok, since noone else is calling interpreter' anyway, so noone relies on it, and not the wrapper, calling `show' |
| 2022-09-24 04:35:19 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 04:35:28 +0200 | <ski> | one reason one might want to do such a thing is in case one actually have multiple terminating conditions (and want to `reverse' in each case). so instead of putting multiple calls to `reverse' into the worker, you just put one into the `wrapper', as "finalization", together with the "initialization" it already does |
| 2022-09-24 04:35:45 +0200 | <ski> | in your case, either works fine, since there's just one terminating case of the worker/helper |
| 2022-09-24 04:35:52 +0200 | <ski> | Guest85 : all clear ? |
| 2022-09-24 04:36:24 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-09-24 04:37:47 +0200 | <ski> | there was one more thing which i wanted to talk about (if you care to hear about it, atm. perhaps you're starting to get tired or overwhelmed, and have enough for the moment to chew on. that'd be fine) |
| 2022-09-24 04:38:22 +0200 | <Guest85> | how would I put the terminating condition in the wrapper if the worker function recurses on interpreter'? |
| 2022-09-24 04:38:37 +0200 | <ski> | you'd have : |
| 2022-09-24 04:38:47 +0200 | <ski> | interpreter x = show (reverse (interpreter' x 0 0 [])) |
| 2022-09-24 04:38:48 +0200 | vglfr | (~vglfr@145.224.100.249) |
| 2022-09-24 04:38:54 +0200 | <ski> | and then, for the helper : |
| 2022-09-24 04:39:03 +0200 | <ski> | interpreter' [] x y print = print |
| 2022-09-24 04:39:09 +0200 | <ski> | (that's all) |
| 2022-09-24 04:39:15 +0200 | <Guest85> | ah ok |
| 2022-09-24 04:40:13 +0200 | <ski> | namely, i mentioned another way to still avoid the left-associated calls to `++' (which yields unreasonable/unexpected inefficiency), but instead of keeping your intended output elements to yourself all until the end (when you always publish/return them), you could public each one of them, as you go |
| 2022-09-24 04:40:39 +0200 | <ski> | if you're up for it, we could talk about this idea for a bit, how it'd work |
| 2022-09-24 04:40:51 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 258 seconds) |
| 2022-09-24 04:40:54 +0200 | <Guest85> | I'm getting a type error and I'm not sure why |
| 2022-09-24 04:40:58 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:9fc6:bfaf:da6f:bda1) (Ping timeout: 246 seconds) |
| 2022-09-24 04:41:03 +0200 | <Guest85> | interpreter :: [String] -> [String] |
| 2022-09-24 04:41:04 +0200 | <Guest85> | interpreter x = interpreter' x 0 0 [] |
| 2022-09-24 04:41:04 +0200 | <Guest85> | interpreter' [] x y print = show $ reverse print |
| 2022-09-24 04:41:05 +0200 | <Guest85> | interpreter' (coor:coors) x y print |
| 2022-09-24 04:41:05 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y print |
| 2022-09-24 04:41:06 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y print |
| 2022-09-24 04:41:06 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) print |
| 2022-09-24 04:41:07 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) print |
| 2022-09-24 04:41:07 +0200 | <Guest85> | | coor == "printX" = interpreter' coors x y ([x]++print) |
| 2022-09-24 04:41:08 +0200 | <Guest85> | | coor == "printY" = interpreter' coors x y ([y]++print) |
| 2022-09-24 04:41:08 +0200 | <Guest85> | | True = interpreter' coors x y print |
| 2022-09-24 04:41:11 +0200 | <Guest85> | Set3a.hs:315:17: error: |
| 2022-09-24 04:41:11 +0200 | <Guest85> | • Couldn't match type ‘Char’ with ‘[Char]’ |
| 2022-09-24 04:41:12 +0200 | <Guest85> | Expected type: [String] |
| 2022-09-24 04:41:12 +0200 | <Guest85> | Actual type: String |
| 2022-09-24 04:41:13 +0200 | <Guest85> | • In the expression: interpreter' x 0 0 [] |
| 2022-09-24 04:41:13 +0200 | <Guest85> | In an equation for ‘interpreter’: |
| 2022-09-24 04:41:14 +0200 | <Guest85> | interpreter x = interpreter' x 0 0 [] |
| 2022-09-24 04:41:14 +0200 | <Guest85> | | |
| 2022-09-24 04:41:15 +0200 | <Guest85> | 315 | interpreter x = interpreter' x 0 0 [] |
| 2022-09-24 04:41:39 +0200 | <dolio> | Don't do that. :þ |
| 2022-09-24 04:41:44 +0200 | <ski> | `show' gives a `String', but you've declared `interpreter' to have result type `[String]' |
| 2022-09-24 04:41:54 +0200 | polykernel[m] | (~polykerne@user/polykernel) |
| 2022-09-24 04:43:08 +0200 | raym | (~raym@user/raym) (Quit: going to travel back home) |
| 2022-09-24 04:43:26 +0200 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 2022-09-24 04:44:02 +0200 | <Guest85> | ah ok I fixed it |
| 2022-09-24 04:44:04 +0200 | <Guest85> | interpreter' [] x y print = map show $ reverse prin |
| 2022-09-24 04:44:12 +0200 | ski | glances sideways |
| 2022-09-24 04:44:21 +0200 | <ski> | .. that's one way to fix the type error |
| 2022-09-24 04:44:47 +0200 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-09-24 04:45:27 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-09-24 04:45:31 +0200 | <Guest85> | how could I do it the other way, publish them as it recurses through the function? |
| 2022-09-24 04:46:01 +0200 | <ski> | well, i could try to illustrate the general idea, with some other functions. sounds okay ? |
| 2022-09-24 04:46:11 +0200 | <Guest85> | ok |
| 2022-09-24 04:47:11 +0200 | <ski> | consider first a quite simple function that traverses an input list, namely "compute the product of all the numbers in the list" |
| 2022-09-24 04:47:22 +0200 | ftoy | (~fucktoy@S01069050ca4e3573.cg.shawcable.net) (Quit: Client closed) |
| 2022-09-24 04:47:31 +0200 | <ski> | product :: [Integer] -> Integer |
| 2022-09-24 04:47:42 +0200 | <ski> | we might start with |
| 2022-09-24 04:47:48 +0200 | <ski> | product ns = ..ns.. |
| 2022-09-24 04:48:11 +0200 | <ski> | (`..ns..' indicating a "hole", code we haven't written yet, but which we imagine will probably need to use `ns') |
| 2022-09-24 04:48:45 +0200 | <ski> | but then we realize that we can't move forward at this point, unless we look at the list, checking if there's at least one number to process there |
| 2022-09-24 04:49:03 +0200 | <ski> | so, the obvious thing to do is to split cases, into empty list, and non-empty list |
| 2022-09-24 04:49:34 +0200 | <ski> | (i'm spelling out intermediate steps that you'd probably only do in your head, if you'd even think about them explicitly, for clarity/emphasis of the process) |
| 2022-09-24 04:49:51 +0200 | <ski> | so, we replace the above tentative defining equation with these two : |
| 2022-09-24 04:49:53 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 04:49:57 +0200 | <ski> | product [ ] = ... |
| 2022-09-24 04:50:07 +0200 | <ski> | product (n:ns) = ..n..ns.. |
| 2022-09-24 04:50:25 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 04:50:55 +0200 | <ski> | now, we might again decide we need to know whether `ns' is empty or not .. after all, we need not just the first number, but all (?) of them, for the product |
| 2022-09-24 04:51:31 +0200 | <ski> | but this is where the magic of recursion steps in and stops you, asking you if you can spot a subproblem that looks like the whole main problem you're trying to solve |
| 2022-09-24 04:52:39 +0200 | <ski> | namely, we were originally trying to compute the product of a list. after determining (in one case), that it has a first element `n', and a list of remaining elements `ns' (which might be empty), we can consider an illustrative example like `product [2,3,5,7]' |
| 2022-09-24 04:52:54 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:3490:26c5:1782:da8c) |
| 2022-09-24 04:52:55 +0200 | <ski> | in that example, `n' will become `2', and `ns' will become `[3,5,7]' |
| 2022-09-24 04:53:09 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-09-24 04:53:10 +0200 | <ski> | and, what we're trying to compute is `2 * 3 * 5 * 7' |
| 2022-09-24 04:53:51 +0200 | <ski> | now, `3 * 5 * 7' is a subproblem of the problem of computing `2 * 3 * 5 * 7', from the input list `[2,3,5,7]' |
| 2022-09-24 04:54:10 +0200 | <ski> | and we already have the sublist `[3,5,7]' of the input list |
| 2022-09-24 04:54:57 +0200 | <ski> | so, the magic of recursion tells us that we can just trust that `product [3,5,7]' (calling recursively on a "smaller" input, one that's "closer" to terminating condition(s) will work correctly, do it's thing, without worrying about it, or how it'll work |
| 2022-09-24 04:55:51 +0200 | <ski> | so, we have `n = 2', and we just assume that for `ns = [3,5,7]', a recursive call `product ns = product [3,5,7]' will compute `3 * 5 * 7' for us |
| 2022-09-24 04:56:39 +0200 | <ski> | now, what's left is to piece together `2' and `3 * 5 * 7' together, to the desired result `2 * 3 * 5 * 7', and express this generally, for any input, not just for this particular example |
| 2022-09-24 04:57:17 +0200 | <ski> | so since `n = 2' and `product ns = 3 * 5 * 7', it seems `n * product ns = 2 * 3 * 5 * 7' should do it |
| 2022-09-24 04:57:38 +0200 | <ski> | so, that's what we put as body of our recursive defining equation. both together now look like : |
| 2022-09-24 04:57:46 +0200 | <ski> | product [ ] = ... |
| 2022-09-24 04:57:59 +0200 | <ski> | product (n:ns) = n * product ns |
| 2022-09-24 04:58:47 +0200 | <Guest85> | I understand how to do those recursive expressions |
| 2022-09-24 04:58:56 +0200 | <Guest85> | how's it apply to the interpreter function? |
| 2022-09-24 04:58:59 +0200 | <ski> | what remains is to finish the base case, the terminating case. after some thought, one may convince oneself that the proper thing to put there is `1', as the product of zero numbers. this will cause the result of out example to be `2 * 3 * 5 * 7 * 1', but that's ok |
| 2022-09-24 04:59:04 +0200 | <Guest85> | other than the recursion |
| 2022-09-24 04:59:11 +0200 | <ski> | we could also, if we wanted to, add a special case for `0' |
| 2022-09-24 04:59:17 +0200 | <ski> | product (0:_ ) = 0 |
| 2022-09-24 04:59:25 +0200 | <ski> | (another, early, terminating case) |
| 2022-09-24 04:59:53 +0200 | <ski> | yea .. i just wanted to spell out the recursive process a bit in detail. i'll omit most of that now |
| 2022-09-24 05:00:35 +0200 | <ski> | note that now `product [2,3,5,7]' generates `2 * (3 * (5 * (7 * 1)))' .. which is right-associated |
| 2022-09-24 05:00:42 +0200 | <ski> | if you look at the expansion |
| 2022-09-24 05:00:50 +0200 | <ski> | product [2,3,5,7] |
| 2022-09-24 05:00:56 +0200 | <ski> | = 2 * product [3,5,7] |
| 2022-09-24 05:01:05 +0200 | <ski> | = 2 * (3 * product [5,7]) |
| 2022-09-24 05:01:12 +0200 | <ski> | = 2 * (3 * (5 * product [7])) |
| 2022-09-24 05:01:22 +0200 | <ski> | = 2 * (3 * (5 * (7 * product []))) |
| 2022-09-24 05:01:26 +0200 | <ski> | = 2 * (3 * (5 * (7 * 1))) |
| 2022-09-24 05:01:27 +0200 | <ski> | = 2 * (3 * (5 * 7)) |
| 2022-09-24 05:01:35 +0200 | <ski> | = 2 * (3 * 35) |
| 2022-09-24 05:01:38 +0200 | <ski> | = 2 * 105 |
| 2022-09-24 05:01:41 +0200 | <ski> | = 210 |
| 2022-09-24 05:01:49 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:3490:26c5:1782:da8c) (Remote host closed the connection) |
| 2022-09-24 05:02:18 +0200 | <ski> | you'll see the stack, the context around the recursive call, growing, until the base case, and then multiplications being done in reverse, on the "way back up" |
| 2022-09-24 05:02:41 +0200 | <Guest85> | hmm |
| 2022-09-24 05:02:43 +0200 | <ski> | .. we might want to avoid needlessly using stack space, when we can reasonably avoid doing so |
| 2022-09-24 05:02:57 +0200 | <ski> | the obvious solution, as you already should know, is to introduce an accumulator parameter |
| 2022-09-24 05:03:14 +0200 | <ski> | product ns = productTimes ns 1 |
| 2022-09-24 05:03:37 +0200 | <ski> | the idea is that `productTimes ns acc' will compute `acc * productTimes ns' |
| 2022-09-24 05:03:45 +0200 | <ski> | er, sorry, `acc * product ns' |
| 2022-09-24 05:04:09 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 05:04:11 +0200 | <ski> | but now we let the helper, `productTimes', do the recursion, and multiplying into the accumulator in each step |
| 2022-09-24 05:04:19 +0200 | <ski> | productTimes [ ] acc = acc |
| 2022-09-24 05:04:36 +0200 | <ski> | productTimes (n:ns) acc = productTimes (acc * n) acc |
| 2022-09-24 05:04:46 +0200 | <ski> | now the same example will reduce as |
| 2022-09-24 05:04:52 +0200 | <ski> | product [2,3,5,7] |
| 2022-09-24 05:05:00 +0200 | <ski> | = productTimes [2,3,5,7] 1 |
| 2022-09-24 05:05:09 +0200 | <ski> | = productTimes [3,5,7] (1 * 2) |
| 2022-09-24 05:05:12 +0200 | <ski> | = productTimes [3,5,7] 2 |
| 2022-09-24 05:05:17 +0200 | <ski> | = productTimes [5,7] (2 * 3) |
| 2022-09-24 05:05:21 +0200 | <ski> | = productTimes [5,7] 6 |
| 2022-09-24 05:05:28 +0200 | <ski> | = productTimes [7] (6 * 5) |
| 2022-09-24 05:05:33 +0200 | <ski> | = productTimes [7] 30 |
| 2022-09-24 05:05:39 +0200 | <ski> | = productTimes [] (30 * 7) |
| 2022-09-24 05:05:42 +0200 | <ski> | = productTimes [] 210 |
| 2022-09-24 05:05:45 +0200 | <ski> | = 210 |
| 2022-09-24 05:06:01 +0200 | <ski> | and you can now see no extra stack space is used, so everything is fine .. |
| 2022-09-24 05:06:03 +0200 | <ski> | .. or is it ? |
| 2022-09-24 05:06:07 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2022-09-24 05:06:10 +0200 | vglfr | (~vglfr@145.224.100.249) (Ping timeout: 246 seconds) |
| 2022-09-24 05:06:45 +0200 | <dolio> | It's is not. |
| 2022-09-24 05:06:51 +0200 | <ski> | (also you can see we're doing the multiplications from the other end of the list, and doing them on the "down", instead of the "up") |
| 2022-09-24 05:06:54 +0200 | <ski> | yes |
| 2022-09-24 05:07:00 +0200 | <ski> | in a strict language, we'd be done here |
| 2022-09-24 05:07:11 +0200 | <ski> | but in a non-strict language, what actually happens here is : |
| 2022-09-24 05:07:20 +0200 | <ski> | product [2,3,5,7] |
| 2022-09-24 05:07:28 +0200 | <ski> | = productTimes [2,3,5,7] 1 |
| 2022-09-24 05:07:33 +0200 | <ski> | = productTimes [3,5,7] (1 * 2) |
| 2022-09-24 05:07:37 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 244 seconds) |
| 2022-09-24 05:07:39 +0200 | <ski> | = productTimes [5,7] ((1 * 2) * 3) |
| 2022-09-24 05:07:45 +0200 | <ski> | = productTimes [7] (((1 * 2) * 3) * 5) |
| 2022-09-24 05:07:51 +0200 | <ski> | = productTimes [] ((((1 * 2) * 3) * 5) * 7) |
| 2022-09-24 05:07:56 +0200 | <ski> | = (((1 * 2) * 3) * 5) * 7 |
| 2022-09-24 05:08:00 +0200 | <ski> | = ((2 * 3) * 5) * 7 |
| 2022-09-24 05:08:04 +0200 | <ski> | = (6 * 5) * 7 |
| 2022-09-24 05:08:08 +0200 | <ski> | = 30 * 7 |
| 2022-09-24 05:08:12 +0200 | <ski> | = 210 |
| 2022-09-24 05:09:25 +0200 | <ski> | so, while we're not building up stack, we *are* building up an unevaluated expression with multiplications, in the accumulator, and only evaluating that (*now* using the stack we didn't use before) at the end, after reaching the base case and returning |
| 2022-09-24 05:09:30 +0200 | <ski> | Guest85 : makes sense ? |
| 2022-09-24 05:09:41 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 244 seconds) |
| 2022-09-24 05:10:09 +0200 | <Guest85> | yeah but isn't that left-associated |
| 2022-09-24 05:10:38 +0200 | <ski> | sure. we're not getting an unreasonable quadratic rather than expected linear complexity here |
| 2022-09-24 05:10:56 +0200 | <ski> | what we *are* getting is an unexpected linear, rather than constant, space complexity |
| 2022-09-24 05:11:47 +0200 | <Guest85> | how is this not building up stack? |
| 2022-09-24 05:11:55 +0200 | <ski> | so, the solution is to actually make sure to evaluate each version of `acc', as we go, rather than only doing it at the end |
| 2022-09-24 05:12:14 +0200 | <ski> | we're not evaluating it, because it might have been that we actually didn't need it at the end |
| 2022-09-24 05:12:20 +0200 | vglfr | (~vglfr@145.224.100.249) |
| 2022-09-24 05:12:38 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-09-24 05:13:04 +0200 | <Guest85> | ok |
| 2022-09-24 05:13:04 +0200 | <ski> | but in this case, we're always needing it at the end. and we'll be needing to evaluate each part of the multiplication expression. so we might as well be doing it directly, as we're adding in each new multiplication |
| 2022-09-24 05:13:16 +0200 | <ski> | one way to do this is to simply add the case |
| 2022-09-24 05:13:29 +0200 | <ski> | productTimes (0:_ ) acc = 0 |
| 2022-09-24 05:13:33 +0200 | <ski> | before the recursive case |
| 2022-09-24 05:13:58 +0200 | <ski> | er, sorry, that's incorrect. we wanted to ensure `acc' was evaluated, not `n' |
| 2022-09-24 05:14:14 +0200 | <ski> | productTimes _ 0 = 0 |
| 2022-09-24 05:14:16 +0200 | <ski> | would work |
| 2022-09-24 05:15:13 +0200 | <ski> | one could also do it in other ways. e.g. replacing the `acc' parameter with `!acc', which will ensure it will be evaluated. one could also call the function `seq' which is for such things |
| 2022-09-24 05:15:55 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 05:16:51 +0200 | <ski> | (btw, i should add that ofter (though not always) the compiler could actually spot that `acc' would be needed in the end, and so making sure to evaluate it as we went directly, without we having to do anything. but that's not a guarantee. if we want guarantee, we probably have to do it ourselves, like above, unless we can predict when the compiler optimizes like this .. which might change between versions, |
| 2022-09-24 05:16:57 +0200 | <ski> | and optimization levels) |
| 2022-09-24 05:17:49 +0200 | <ski> | anyway, the first version of `product' i'd call the direct recursive version. the second version (the fixed one) is the accumulating version, or the tail-recursive version |
| 2022-09-24 05:18:18 +0200 | edrx | (~Eduardo@2804:56c:d2dc:ac00:dab8:211d:d4eb:fa94) (Killed buffer) |
| 2022-09-24 05:18:28 +0200 | <ski> | now consider another function. a function that, given a positive `Integer', will give a list of all its (positive) divisors |
| 2022-09-24 05:19:00 +0200 | <ski> | so `divisors 6' should be `[6,3,2,1]' (let's say it should give them in descending order) |
| 2022-09-24 05:19:26 +0200 | <ski> | Guest85 : ok, so far ? |
| 2022-09-24 05:20:27 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 05:20:49 +0200 | <Guest85> | yeah, I've heard of tail recursion |
| 2022-09-24 05:20:51 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 05:20:55 +0200 | <ski> | good |
| 2022-09-24 05:21:00 +0200 | <Guest85> | not much on strictness tho |
| 2022-09-24 05:21:10 +0200 | <ski> | let's define, as a helper |
| 2022-09-24 05:21:21 +0200 | <ski> | divides :: Integer -> Integer -> Bool |
| 2022-09-24 05:21:31 +0200 | <ski> | d `divides` n = n `mod` d == 0 |
| 2022-09-24 05:21:55 +0200 | xff0x | (~xff0x@2405:6580:b080:900:c9c6:ea14:444b:6072) (Ping timeout: 246 seconds) |
| 2022-09-24 05:22:18 +0200 | <ski> | then for `divisors n', we want to consider all the `Integer's from `n' down to `1', and only include those which actually divides `n' in the output list |
| 2022-09-24 05:22:34 +0200 | <ski> | so, we will need to get that sequence of `Integer's |
| 2022-09-24 05:22:44 +0200 | <ski> | one way to do that is to count down from `n' towards `1' |
| 2022-09-24 05:22:56 +0200 | <ski> | this could be one accumulator parameter, of a helper function |
| 2022-09-24 05:22:59 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2022-09-24 05:23:25 +0200 | <ski> | and, so far, it seems we need no more accumulating parameters, so that gives : |
| 2022-09-24 05:23:36 +0200 | <ski> | divisors :: Integer -> [Integer] |
| 2022-09-24 05:23:49 +0200 | luffy | (~chenqisu1@183.217.203.170) (Max SendQ exceeded) |
| 2022-09-24 05:23:52 +0200 | <ski> | divisors n = divisorsFrom n n |
| 2022-09-24 05:23:55 +0200 | <ski> | where |
| 2022-09-24 05:24:08 +0200 | <ski> | divisorsFrom :: Integer -> Integer -> [Integer] |
| 2022-09-24 05:24:26 +0200 | <ski> | (hiding the helper/worker inside a `where' of the wrapper) |
| 2022-09-24 05:25:07 +0200 | <ski> | let's say the first parameter (for a change) is the counter that we count down. the second is `n', which we'll need to check divisibility with |
| 2022-09-24 05:25:19 +0200 | <ski> | base case is when we've counted down to `1' already |
| 2022-09-24 05:25:27 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 05:25:30 +0200 | <ski> | divisorsFrom 1 n = ..n.. |
| 2022-09-24 05:25:52 +0200 | <ski> | in this case, the only divisor that we have to report is `1' itself, so |
| 2022-09-24 05:25:58 +0200 | <ski> | divisorsFrom 1 _ = [1] |
| 2022-09-24 05:26:14 +0200 | vglfr | (~vglfr@145.224.100.249) (Quit: Quit) |
| 2022-09-24 05:26:19 +0200 | <ski> | next case is when we haven't reached the bottom |
| 2022-09-24 05:26:27 +0200 | vglfr | (~vglfr@145.224.100.249) |
| 2022-09-24 05:26:30 +0200 | <ski> | divisorsFrom i n = ..i..n.. |
| 2022-09-24 05:28:17 +0200 | <ski> | (we could check here that `i' is actually greater (rather than less) than `1'. that would catch the mistake of calling with zero or negative counter. but since the helper is only supposed to be called from the worker, perhaps we don't need to worry ? well, initial value of `i' is `n', and `n' could still be `0' or negative. but if we want to check that, it's better to do it, once, to begin with, in the |
| 2022-09-24 05:28:23 +0200 | <ski> | wrapper, than to do it, every time in the loop, in the worker) |
| 2022-09-24 05:28:47 +0200 | <ski> | but, we do want to check if `i' is a divisor .. actually, let me rename it to `d', for consistency with the definition of `divides' |
| 2022-09-24 05:28:50 +0200 | <ski> | so |
| 2022-09-24 05:28:53 +0200 | luffy | (~chenqisu1@183.217.203.170) (Max SendQ exceeded) |
| 2022-09-24 05:28:56 +0200 | <ski> | divisorsFrom d n |
| 2022-09-24 05:29:25 +0200 | <ski> | | d `divides` n = ..d..n.. |
| 2022-09-24 05:29:45 +0200 | <ski> | | otherwise = ..d..n.. |
| 2022-09-24 05:29:59 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 05:30:26 +0200 | <ski> | in one case, we skip `d', calling recursively on `d-1'. in the other case we emit `d', and call recursive on `d-1' |
| 2022-09-24 05:30:29 +0200 | <ski> | divisorsFrom d n |
| 2022-09-24 05:30:42 +0200 | <ski> | | d `divides` n = d : divisorsFrom (d-1) n |
| 2022-09-24 05:30:51 +0200 | <ski> | | otherwise = divisorsFrom (d-1) n |
| 2022-09-24 05:31:01 +0200 | <ski> | Guest85 : this makes sense ? |
| 2022-09-24 05:31:04 +0200 | frost | (~frost@user/frost) |
| 2022-09-24 05:32:02 +0200 | <Guest85> | yes |
| 2022-09-24 05:32:18 +0200 | <ski> | now, a couple of minor points |
| 2022-09-24 05:32:25 +0200 | <ski> | looking at the base case |
| 2022-09-24 05:32:34 +0200 | <ski> | divisorsFrom 1 _ = [1] |
| 2022-09-24 05:32:48 +0200 | <ski> | we could actually "push back" this to one step lower, if we wanted to : |
| 2022-09-24 05:32:52 +0200 | <ski> | divisorsFrom 0 _ = [] |
| 2022-09-24 05:33:28 +0200 | <ski> | that way the `1' divisor (which will always be a divisor) will be handled the same way, by the same code, that's handling all the other divisors, and added to the result in the same way |
| 2022-09-24 05:33:56 +0200 | <ski> | often, it can be a good thing to try to push back base cases to even simpler cases like this, even ones that might feel "useless" |
| 2022-09-24 05:35:11 +0200 | <ski> | (it can improve modularity of code, not having to make special cases elsewhere, when you do realize you can actually generate such a "useless" call. and it can add to number of useful reasoning and refactoring laws you can apply to your code. this also applies to data type design, not just to recursive functions) |
| 2022-09-24 05:35:17 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 258 seconds) |
| 2022-09-24 05:36:07 +0200 | <Guest85> | nods |
| 2022-09-24 05:36:42 +0200 | <ski> | however, in this case, it doesn't really matter, since `divisorsFrom' is only called from `divisors' anyway, noone will call `divisorsFrom' with `d' being `0', unless we do it ourselves (from `divisors' .. and if we want to handle `0', we actually ought to give a list of all integers, not the empty list .. so `divisorsFrom 0 _ = []' would be incorrect from that standpoint) |
| 2022-09-24 05:37:11 +0200 | <ski> | besides, we also added an extra call to `divides', which we *know* will always succeed |
| 2022-09-24 05:37:25 +0200 | <ski> | so, since there' not really any upside here, and there is a downside, we might not want to do this |
| 2022-09-24 05:37:34 +0200 | <ski> | (but it's a good consideration to have in mind) |
| 2022-09-24 05:37:48 +0200 | <ski> | now, let's do "the same" that we did for `product' |
| 2022-09-24 05:38:10 +0200 | <ski> | namely, instead of having a direct recursive solution, let's make an accumulative / tail-recursive solution |
| 2022-09-24 05:38:26 +0200 | <ski> | oh, actually, there was one other point i wanted to make first |
| 2022-09-24 05:38:44 +0200 | <ski> | there's no need to pass `n' around as a parameter to `divisorsFrom' .. we never change it |
| 2022-09-24 05:39:20 +0200 | <ski> | and since `divisorsFrom' is defined in a `where' attached to the `divisors' defining equation, it can just "grab `n' in the air", from that outer defining equation |
| 2022-09-24 05:39:26 +0200 | <ski> | which gives |
| 2022-09-24 05:39:38 +0200 | <ski> | divisors n = divisorsFrom n |
| 2022-09-24 05:39:43 +0200 | <ski> | where |
| 2022-09-24 05:39:52 +0200 | <ski> | divisorsFrom d |
| 2022-09-24 05:39:56 +0200 | <ski> | | d `divides` n = d : divisorsFrom (d-1) |
| 2022-09-24 05:40:02 +0200 | <ski> | | otherwise = divisorsFrom (d-1) |
| 2022-09-24 05:40:11 +0200 | <ski> | ok, anyway .. |
| 2022-09-24 05:40:57 +0200 | <Guest85> | I think this solution is what you're getting at |
| 2022-09-24 05:40:58 +0200 | <Guest85> | interpreter :: [String] -> [String] |
| 2022-09-24 05:40:58 +0200 | <Guest85> | interpreter commands = go 0 0 commands |
| 2022-09-24 05:40:59 +0200 | <Guest85> | where go x y ("up":commands) = go x (y+1) commands |
| 2022-09-24 05:40:59 +0200 | <Guest85> | go x y ("down":commands) = go x (y-1) commands |
| 2022-09-24 05:41:00 +0200 | <Guest85> | go x y ("left":commands) = go (x-1) y commands |
| 2022-09-24 05:41:00 +0200 | <Guest85> | go x y ("right":commands) = go (x+1) y commands |
| 2022-09-24 05:41:01 +0200 | <Guest85> | go x y ("printX":commands) = show x : go x y commands |
| 2022-09-24 05:41:01 +0200 | <Guest85> | go x y ("printY":commands) = show y : go x y commands |
| 2022-09-24 05:41:02 +0200 | <Guest85> | go x y [] = [] |
| 2022-09-24 05:41:02 +0200 | <Guest85> | go x y (_:commands) = "BAD" : go x y commands |
| 2022-09-24 05:41:08 +0200 | <Guest85> | that uses tail recursion, no? |
| 2022-09-24 05:41:14 +0200 | <ski> | well |
| 2022-09-24 05:41:25 +0200 | <ski> | it's not a purely tail-recursive version, no |
| 2022-09-24 05:41:35 +0200 | <ski> | (although i think you're starting to get where i'm heading) |
| 2022-09-24 05:41:51 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2022-09-24 05:41:54 +0200 | <ski> | that version of `go' has both tail-recursive calls, and non-tail-recursive calls |
| 2022-09-24 05:42:12 +0200 | <ski> | (i should say "non-tail recursive calls", actually) |
| 2022-09-24 05:42:39 +0200 | <ski> | let's go through the motions for `divisors' quickly, and i'll get to the main point |
| 2022-09-24 05:42:43 +0200 | <ski> | we get |
| 2022-09-24 05:42:46 +0200 | <Guest85> | k |
| 2022-09-24 05:43:27 +0200 | <ski> | divisors n = reverse (divisorsFromAppend n []) |
| 2022-09-24 05:43:30 +0200 | <ski> | where |
| 2022-09-24 05:43:51 +0200 | <ski> | divisorsFrom 1 acc = 1 : acc |
| 2022-09-24 05:44:02 +0200 | <ski> | divisorsFrom d acc |
| 2022-09-24 05:44:46 +0200 | <ski> | | d `divides` n = divisorsFromAppend (d-1) (d : acc) |
| 2022-09-24 05:44:51 +0200 | xff0x | (~xff0x@2405:6580:b080:900:87ff:1eaa:6690:ed86) |
| 2022-09-24 05:45:03 +0200 | <ski> | | otherwise = divisorsFromAppend (d-1) acc |
| 2022-09-24 05:45:16 +0200 | <ski> | (sorry, replace `divisorsFrom' with `divisorsFromAppend' there) |
| 2022-09-24 05:45:42 +0200 | <ski> | so, we're adding items in backwards order (adding in front rather than at end to avoid left-nested `++'s), so we need to `reverse' at the end |
| 2022-09-24 05:45:59 +0200 | <ski> | .. or we could just count up from `1' towards `n' instead, and not have to `reverse' |
| 2022-09-24 05:46:15 +0200 | <ski> | anyway, the idea should hopefully be clear |
| 2022-09-24 05:46:30 +0200 | <ski> | now, which is better, the direct or the accumulating version ? |
| 2022-09-24 05:47:30 +0200 | <ski> | note that the accumulating version keeps all the generated items to itself, in `acc', until it reaches the base case, where it releases `1 : acc' as the result that is returned back to `divisors' (and then passed through `reverse' unless we change to count up instead of down) |
| 2022-09-24 05:47:46 +0200 | <Guest85> | depends? |
| 2022-09-24 05:48:21 +0200 | <ski> | while, the *direct* recursive version will actually make the items it's producing available to its caller (including the caller of `divisors') *as* it is progressing through its loop |
| 2022-09-24 05:49:43 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-09-24 05:49:49 +0200 | <ski> | e.g. if you do `takeWhile (> 2) (divisors 6)', then `takeWhile' will skip looking at the rest of the list after the `2' in the result `[6,3,2,1]'. because Haskell is non-strict, this means that the recursive calls that would have produced `[1]' in this case never happens ! |
| 2022-09-24 05:50:00 +0200 | fef | (~thedawn@user/thedawn) (Client Quit) |
| 2022-09-24 05:50:34 +0200 | <ski> | so, `takeWhile' is able to abort our `divisorsFrom' loop, when it pleases, being able to decide after each output element it has been fed whether it cares to look for more or not |
| 2022-09-24 05:50:36 +0200 | <Guest85> | non-strict == lazy? as to why Haskell can work infinite lists |
| 2022-09-24 05:51:12 +0200 | <ski> | but this *can't* happen for the tail-recursive version (because there the recursive calls are not "guarded" by the list constructor `:', which is non-strict) |
| 2022-09-24 05:51:32 +0200 | <ski> | lazy is a particular implementation strategy to realize non-strict evaluation |
| 2022-09-24 05:51:51 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) |
| 2022-09-24 05:51:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 05:51:55 +0200 | <Guest85> | interpreter :: [String] -> [String] |
| 2022-09-24 05:51:55 +0200 | <Guest85> | interpreter x = interpreter' x 0 0 |
| 2022-09-24 05:51:56 +0200 | <Guest85> | interpreter' [] x y = [] |
| 2022-09-24 05:51:56 +0200 | <Guest85> | interpreter' (coor:coors) x y |
| 2022-09-24 05:51:57 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y |
| 2022-09-24 05:51:57 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y |
| 2022-09-24 05:51:58 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) |
| 2022-09-24 05:51:58 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) |
| 2022-09-24 05:51:59 +0200 | <Guest85> | | coor == "printX" = show x : interpreter' coors x y |
| 2022-09-24 05:51:59 +0200 | <Guest85> | | coor == "printY" = show y : interpreter' coors x y |
| 2022-09-24 05:52:00 +0200 | <Guest85> | | True = interpreter' coors x y |
| 2022-09-24 05:52:10 +0200 | <ski> | lazy (aka by-need) in particular means that a computation that is done will cache its result, so that it's not redone |
| 2022-09-24 05:53:09 +0200 | <Guest85> | so for this the direct recursion are here: |
| 2022-09-24 05:53:25 +0200 | <Guest85> | | coor == "printX" = show x : interpreter' coors x y |
| 2022-09-24 05:53:25 +0200 | <Guest85> | | coor == "printY" = show y : interpreter' coors x y |
| 2022-09-24 05:53:33 +0200 | <Guest85> | and the tail recursion here?: |
| 2022-09-24 05:53:36 +0200 | <ski> | Haskell does *not* require an implementation to be lazy (but most of them are. there was some that sometimes did speculative evaluation, passing off some computation that wasn't demanded yet to an idle processor core, in the hope that it will be needed in the future. but this needs to be coupled with a timeout, to not get stuck in an infinite loop. it should still behave as if didn't evaluate it, in case it |
| 2022-09-24 05:53:37 +0200 | <Guest85> | | coor == "left" = interpreter' coors (x-1) y |
| 2022-09-24 05:53:38 +0200 | <Guest85> | | coor == "right" = interpreter' coors (x+1) y |
| 2022-09-24 05:53:38 +0200 | <Guest85> | | coor == "up" = interpreter' coors x (y+1) |
| 2022-09-24 05:53:39 +0200 | <Guest85> | | coor == "down" = interpreter' coors x (y-1) |
| 2022-09-24 05:53:42 +0200 | <ski> | was never needed) |
| 2022-09-24 05:54:07 +0200 | <ski> | well. you can't really do much about those tai-recursions |
| 2022-09-24 05:54:34 +0200 | <ski> | they aren't really problems anyway, you're not building up an accumulator further in them (and you weren't, in your previous accumulating version) |
| 2022-09-24 05:55:13 +0200 | <ski> | it's these last two cases, for `"printX"' and `"printY"', which are the cases where we could apply this improvement, by going from accumulating, to direct (specifically guarded) recursion |
| 2022-09-24 05:56:22 +0200 | <ski> | note that the key difference between `divisors' and `product' is that in the case of `product' we had `n * product ns', and `*' is strict (will need to get value of both operands) (at least for the usual numeric types. you could make non-strict numeric types, where it could be better to use the non-tail recursive version) |
| 2022-09-24 05:56:38 +0200 | <ski> | while for `divisors' we had `d : divisorsFrom (d-1)' |
| 2022-09-24 05:56:43 +0200 | <ski> | `:' is non-strict |
| 2022-09-24 05:57:30 +0200 | <Guest85> | I kind of understand |
| 2022-09-24 05:57:36 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 05:57:43 +0200 | <Guest85> | lost that other solution with fold |
| 2022-09-24 05:57:51 +0200 | <ski> | it stops right there, and returns control to the caller (`takeWhile' in my example above), which can then decide whether it wants to look at (the head `d' and) the tail `divisorsFrom (d-1)' .. only when/if `takeWhile' (or whatever your caller is) looks there, will the recursive call happen |
| 2022-09-24 05:57:54 +0200 | <Guest85> | somebody here had mentioned earlier |
| 2022-09-24 05:58:25 +0200 | <ski> | so, the direct recursive version of `divisors' acts like a "generator", that will present one element at a time to its caller, and the caller can abort |
| 2022-09-24 05:58:57 +0200 | <ski> | while the tail-recursive version is "bulky", not incremental, will always run to the end of its loop, before relinguishing control back to the caller |
| 2022-09-24 05:59:17 +0200 | <Guest85> | so in general tail recursion is sloweR? |
| 2022-09-24 05:59:20 +0200 | <ski> | ok .. i think this was basically what i wanted to cover here |
| 2022-09-24 05:59:28 +0200 | <ski> | it depends |
| 2022-09-24 05:59:37 +0200 | <ski> | sometimes tail-recursion is better |
| 2022-09-24 05:59:39 +0200 | <ski> | sometimes not |
| 2022-09-24 05:59:53 +0200 | <Guest85> | makes sense, thanks for going into such detail |
| 2022-09-24 06:00:02 +0200 | <ski> | in a strict functional language, tail-recursion would more commonly be the best choice |
| 2022-09-24 06:01:13 +0200 | <ski> | (sometimes the direct recursive version, the version you get when analyzing recursively, naïvely, without thinking about tail-recursion or accumulation, would automatically become tail-recursive, accumulative, possibly even without you realizing you're actually doing an accumulator) |
| 2022-09-24 06:02:20 +0200 | <ski> | (also, note that you can have an accumulating argument, without being tail-recursive (e.g. some, or all, recursive calls being non-tail calls). but the reason why people often try to consciously *introduce* accumulators are usually because they want a tail-recursive version) |
| 2022-09-24 06:02:53 +0200 | <ski> | Haskell lists are non-strict. someone said that it's often good to think of them not as a data structure, but as a "loop, waiting to happen" |
| 2022-09-24 06:03:35 +0200 | <ski> | it's this fact, them being non-strict (the data constructor `:' being non-strict), which enables you do to incremental, pieces-at-a-time, rather than bulky, all-at-once, algorithms |
| 2022-09-24 06:04:41 +0200 | <ski> | it's also possible to do such things in strict languages, with explicit delaying recursive calls behind function abstractions (lambdas / thunks) .. but it's a bit more noisy, usually, and there's less support (e.g. from compiler optimizations, and from library functions) for it |
| 2022-09-24 06:05:31 +0200 | <ski> | hence why tail-recursion is commonly more emphasized in strict languages (supporting tail recursion) like SML,Erlang,Scheme,OCaml,F#,Prolog,.. |
| 2022-09-24 06:05:31 +0200 | vglfr | (~vglfr@145.224.100.249) (Read error: Connection reset by peer) |
| 2022-09-24 06:05:51 +0200 | <ski> | but tail-recursion is *still* good to know about, and sometimes use, in Haskell as well |
| 2022-09-24 06:06:25 +0200 | vglfr | (~vglfr@145.224.100.249) |
| 2022-09-24 06:06:55 +0200 | <Guest85> | it's covered in some of the material I'm going through |
| 2022-09-24 06:07:06 +0200 | <Guest85> | I'm doing the Haskell MOOC, that's where I got that problem to solve |
| 2022-09-24 06:07:36 +0200 | <ski> | (it should also be said that tail-recursion, that gives an iterative process, basically a "loop", is sometimes inferior to a non-tail recursive version, for algorithmic reasons. e.g. merge sort and quick sort are better than insertion sort, selection sort, shell sort, even though the former are non-tail recursive, and the latter would be expressed as tail-recursive. this is because of the superior |
| 2022-09-24 06:07:42 +0200 | <ski> | *algorithm* for the former) |
| 2022-09-24 06:07:58 +0200 | <ski> | (and this holds true also in strict languages) |
| 2022-09-24 06:10:18 +0200 | <ski> | Guest85 : i hope it wasn't too painful to read the first part of my exposition, where i went into quite a bit more detail about recursive thinking, and associating reduction traces to different space complexity (stack usage), in a visual way. ime,it's not always that people get to hear about that kind of thing (although maybe you had seen that before). after that, i picked up pace a bit more |
| 2022-09-24 06:11:02 +0200 | <Guest85> | I've seen it broken down before to explain recursion |
| 2022-09-24 06:11:08 +0200 | <ski> | good |
| 2022-09-24 06:11:59 +0200 | <ski> | (in any case, i wanted both the `product' example, and the `divisors' example, to show how in one case tail-recursion was better, while in the other case it wasn't) |
| 2022-09-24 06:13:10 +0200 | <ski> | now, as i already mentioned, i would match on the strings in the "head" (the left-hand-side, the definiens, the thing to be defined, to the left of the `='s), rather than checking equality in guards |
| 2022-09-24 06:13:16 +0200 | <ski> | but that's more of a style thing |
| 2022-09-24 06:14:30 +0200 | <ski> | (also, instead of outputting `"BAD"' as a single item, and then still continuing to process the rest, i might decide to abort the whole process instead .. but one could decide differently here, depending of requirements and other considerations) |
| 2022-09-24 06:15:20 +0200 | <ski> | btw, if you wanted to, you could use `++' instead of `:' .. if you wanted to get a single `String' as result, instead of a list of `String's |
| 2022-09-24 06:15:21 +0200 | <Guest85> | that's what they did in the model solution, I just find guards easier right now |
| 2022-09-24 06:15:26 +0200 | ski | nods |
| 2022-09-24 06:15:31 +0200 | <ski> | then go with that |
| 2022-09-24 06:15:58 +0200 | vglfr | (~vglfr@145.224.100.249) (Ping timeout: 265 seconds) |
| 2022-09-24 06:16:19 +0200 | <ski> | most important is that the code is understandable and as clear as reasonable to the intended reader(s) .. which is you, at this moment |
| 2022-09-24 06:16:22 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 06:17:09 +0200 | <ski> | (one could opt to make it less clear than possible, e.g. to improve efficiency, or perhaps in some cases to improve composability and modularity) |
| 2022-09-24 06:17:45 +0200 | <ski> | Guest85 : anything more you're wondering about ? |
| 2022-09-24 06:18:26 +0200 | <Guest85> | not at the moment, though surely I will in the future |
| 2022-09-24 06:18:34 +0200 | <Guest85> | I'm off to sleep now, thanks again |
| 2022-09-24 06:18:46 +0200 | <ski> | ok, i hope this was fun and edifying |
| 2022-09-24 06:18:52 +0200 | <Guest85> | nods (: |
| 2022-09-24 06:19:01 +0200 | <ski> | (don't forget to have fun when learning ! it helps greatly with learning) |
| 2022-09-24 06:19:30 +0200 | <Guest85> | I'm going to practice a bit with TidalCycles again, that's always fun |
| 2022-09-24 06:19:39 +0200 | <ski> | you're welcome |
| 2022-09-24 06:19:45 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-09-24 06:19:45 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-09-24 06:19:51 +0200 | <Guest85> | night |
| 2022-09-24 06:20:11 +0200 | Guest85 | (~Guest85@45.144.115.145) (Quit: Client closed) |
| 2022-09-24 06:21:50 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-24 06:21:51 +0200 | califax | (~califax@user/califx) |
| 2022-09-24 06:22:26 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2022-09-24 06:23:18 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-24 06:36:12 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 06:45:17 +0200 | limberdelt | (~limberdel@gateway/vpn/pia/limberdelt) (Remote host closed the connection) |
| 2022-09-24 06:49:49 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-09-24 07:02:30 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-09-24 07:02:49 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 2022-09-24 07:03:58 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-09-24 07:04:01 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-09-24 07:08:08 +0200 | kenran | (~kenran@200116b82bfc8c00506b0bf76983b11b.dip.versatel-1u1.de) |
| 2022-09-24 07:15:26 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 07:18:07 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-09-24 07:18:41 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 07:19:52 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 246 seconds) |
| 2022-09-24 07:28:14 +0200 | causal | (~user@50.35.83.177) |
| 2022-09-24 07:30:37 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-09-24 07:34:00 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-09-24 07:35:23 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-09-24 07:35:49 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) (Remote host closed the connection) |
| 2022-09-24 07:36:07 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) |
| 2022-09-24 07:36:40 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-09-24 07:37:27 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2022-09-24 07:45:10 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 07:45:10 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 07:47:50 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 07:48:50 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-09-24 07:49:22 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 07:50:11 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-09-24 07:52:38 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-09-24 07:53:07 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-09-24 07:56:53 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-24 08:04:45 +0200 | bilegeek | (~bilegeek@2600:1008:b042:1805:f458:6de8:d801:df30) |
| 2022-09-24 08:04:53 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-09-24 08:05:09 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-09-24 08:05:21 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-24 08:08:31 +0200 | kenran | (~kenran@200116b82bfc8c00506b0bf76983b11b.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-09-24 08:11:43 +0200 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-09-24 08:11:44 +0200 | jinsun | (~jinsun@user/jinsun) (Killed (molybdenum.libera.chat (Nickname regained by services))) |
| 2022-09-24 08:11:44 +0200 | jinsun__ | jinsun |
| 2022-09-24 08:13:19 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 08:13:43 +0200 | mbuf | (~Shakthi@49.204.135.71) |
| 2022-09-24 08:18:23 +0200 | bontaq` | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2022-09-24 08:18:30 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2022-09-24 08:21:25 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Remote host closed the connection) |
| 2022-09-24 08:21:51 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) |
| 2022-09-24 08:22:38 +0200 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-09-24 08:22:39 +0200 | jinsun | Guest5343 |
| 2022-09-24 08:22:39 +0200 | Guest5343 | (~jinsun@user/jinsun) (Killed (sodium.libera.chat (Nickname regained by services))) |
| 2022-09-24 08:22:39 +0200 | jinsun__ | jinsun |
| 2022-09-24 08:23:13 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 08:23:36 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 08:24:34 +0200 | sympt | (~sympt@user/sympt) (Read error: Connection reset by peer) |
| 2022-09-24 08:26:59 +0200 | edrx | (~Eduardo@2804:56c:d2dc:ac00:dab8:211d:d4eb:fa94) |
| 2022-09-24 08:27:27 +0200 | <edrx> | hi all - in this expression |
| 2022-09-24 08:27:29 +0200 | <edrx> | createProcess (proc "ls" []) { std_out = CreatePipe } |
| 2022-09-24 08:28:05 +0200 | <edrx> | what is, syntactically, the "{ std_out = CreatePipe }"? |
| 2022-09-24 08:28:31 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-24 08:32:46 +0200 | <sm> | edrx: a record update, setting the stdout field of a record type returned by proc |
| 2022-09-24 08:33:09 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 258 seconds) |
| 2022-09-24 08:33:56 +0200 | <sm> | uh, or maybe returned by createProcess |
| 2022-09-24 08:34:28 +0200 | waldo | (~waldo@user/waldo) |
| 2022-09-24 08:35:10 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-09-24 08:36:23 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-09-24 08:39:14 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-09-24 08:39:26 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-24 08:40:12 +0200 | <edrx> | sm: thanks! =) |
| 2022-09-24 08:43:21 +0200 | edrx | (~Eduardo@2804:56c:d2dc:ac00:dab8:211d:d4eb:fa94) (Killed buffer) |
| 2022-09-24 08:49:41 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 08:50:39 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Remote host closed the connection) |
| 2022-09-24 08:52:55 +0200 | MoC | (~moc@user/moc) |
| 2022-09-24 08:59:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-24 09:02:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 09:06:55 +0200 | kimjetwav | (~user@2607:fea8:235e:b600:3a8e:383d:7069:4bec) (Remote host closed the connection) |
| 2022-09-24 09:06:59 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-09-24 09:07:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 09:21:12 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 09:23:59 +0200 | kitty4 | (~kitty@096-039-147-043.res.spectrum.com) (Quit: WeeChat 3.5) |
| 2022-09-24 09:26:26 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 09:26:55 +0200 | luffy | (~chenqisu1@183.217.203.170) (Ping timeout: 246 seconds) |
| 2022-09-24 09:27:17 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-24 09:28:50 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 09:30:46 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 246 seconds) |
| 2022-09-24 09:33:16 +0200 | titibandit | (~titibandi@xdsl-87-78-162-143.nc.de) |
| 2022-09-24 09:35:17 +0200 | king_gs | (~Thunderbi@2806:103e:29:ac5e:a16e:4ac9:a89b:4d) (Quit: king_gs) |
| 2022-09-24 09:36:46 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:27b7:f613:f2be:f46f) |
| 2022-09-24 09:37:59 +0200 | `2jt | (~jtomas@88.17.232.105) |
| 2022-09-24 09:43:17 +0200 | <c_wraith> | sm: returned by proc. record update binds more tightly than function application |
| 2022-09-24 09:43:45 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2022-09-24 09:47:01 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving) |
| 2022-09-24 09:47:58 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 09:50:44 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-09-24 09:53:21 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-09-24 10:04:14 +0200 | bilegeek | (~bilegeek@2600:1008:b042:1805:f458:6de8:d801:df30) (Quit: Leaving) |
| 2022-09-24 10:06:06 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 252 seconds) |
| 2022-09-24 10:07:04 +0200 | titibandit | (~titibandi@xdsl-87-78-162-143.nc.de) (Remote host closed the connection) |
| 2022-09-24 10:23:18 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 10:24:22 +0200 | razetime | (~quassel@117.254.35.116) |
| 2022-09-24 10:26:02 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-09-24 10:26:17 +0200 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2022-09-24 10:28:03 +0200 | luffy | (~chenqisu1@183.217.203.170) (Ping timeout: 252 seconds) |
| 2022-09-24 10:32:49 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 10:33:48 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 10:33:54 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: Lost terminal) |
| 2022-09-24 10:34:32 +0200 | luffy | (~chenqisu1@183.217.203.170) (Max SendQ exceeded) |
| 2022-09-24 10:35:50 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 10:37:43 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-24 10:38:19 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-24 10:39:25 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 252 seconds) |
| 2022-09-24 10:39:47 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 10:40:18 +0200 | luffy | (~chenqisu1@183.217.203.170) (Remote host closed the connection) |
| 2022-09-24 10:40:46 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 10:41:37 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-09-24 10:41:49 +0200 | luffy | (~chenqisu1@183.217.203.170) (Remote host closed the connection) |
| 2022-09-24 10:42:20 +0200 | luffy | (~chenqisu1@183.217.203.170) |
| 2022-09-24 10:43:03 +0200 | MoC | (~moc@user/moc) (Quit: Konversation terminated!) |
| 2022-09-24 10:43:27 +0200 | razetime | (~quassel@117.254.35.116) (Ping timeout: 252 seconds) |
| 2022-09-24 10:43:29 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-09-24 10:44:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 10:44:37 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 246 seconds) |
| 2022-09-24 10:44:47 +0200 | MoC | (~moc@user/moc) |
| 2022-09-24 10:46:51 +0200 | beteigeuze | (~Thunderbi@p5090d00a.dip0.t-ipconnect.de) |
| 2022-09-24 10:51:03 +0200 | acidjnk | (~acidjnk@p200300d6e7137a440dc2598308a8f039.dip0.t-ipconnect.de) |
| 2022-09-24 10:55:36 +0200 | razetime | (~quassel@117.254.35.116) |
| 2022-09-24 10:56:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-09-24 10:57:25 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-09-24 10:57:33 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-24 11:02:37 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-09-24 11:04:06 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-09-24 11:04:50 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 11:08:14 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-09-24 11:13:19 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-09-24 11:17:22 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-09-24 11:20:23 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-09-24 11:22:09 +0200 | vglfr | (~vglfr@145.224.100.100) (Read error: Connection reset by peer) |
| 2022-09-24 11:22:21 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 11:24:15 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) |
| 2022-09-24 11:30:44 +0200 | Logio | (em@kapsi.fi) |
| 2022-09-24 11:32:04 +0200 | razetime | (~quassel@117.254.35.116) (Ping timeout: 265 seconds) |
| 2022-09-24 11:32:19 +0200 | razetime | (~quassel@117.193.1.121) |
| 2022-09-24 11:42:41 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-24 11:42:43 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 246 seconds) |
| 2022-09-24 11:46:30 +0200 | michalz | (~michalz@185.246.207.221) |
| 2022-09-24 11:46:37 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-09-24 11:49:57 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 11:56:21 +0200 | razetime | (~quassel@117.193.1.121) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-24 11:58:57 +0200 | MoC | (~moc@user/moc) (Quit: Konversation terminated!) |
| 2022-09-24 12:01:29 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-09-24 12:02:02 +0200 | kuribas | (~user@ptr-17d51endqa8qjfim10g.18120a2.ip6.access.telenet.be) |
| 2022-09-24 12:12:12 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-09-24 12:14:05 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-09-24 12:17:50 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-09-24 12:17:51 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-24 12:18:03 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 12:20:32 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-09-24 12:22:20 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2022-09-24 12:22:39 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 12:23:37 +0200 | zaquest | (~notzaques@5.130.79.72) (Read error: Connection reset by peer) |
| 2022-09-24 12:24:29 +0200 | thyriaen | (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce) |
| 2022-09-24 12:26:35 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) |
| 2022-09-24 12:27:42 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-09-24 12:32:46 +0200 | mbuf | (~Shakthi@49.204.135.71) (Ping timeout: 246 seconds) |
| 2022-09-24 12:33:24 +0200 | beteigeuze1 | (~Thunderbi@89.187.168.45) |
| 2022-09-24 12:34:16 +0200 | kuribas | (~user@ptr-17d51endqa8qjfim10g.18120a2.ip6.access.telenet.be) (Ping timeout: 260 seconds) |
| 2022-09-24 12:34:52 +0200 | beteigeuze | (~Thunderbi@p5090d00a.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-09-24 12:34:53 +0200 | beteigeuze1 | beteigeuze |
| 2022-09-24 12:35:34 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 12:40:00 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-09-24 12:41:10 +0200 | jargon | (~jargon@184.101.186.15) (Remote host closed the connection) |
| 2022-09-24 12:52:08 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-09-24 13:04:30 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2022-09-24 13:11:34 +0200 | thyriaen | (~thyriaen@2a02:8109:8340:686c:7383:e0e2:ad95:9fce) (Remote host closed the connection) |
| 2022-09-24 13:19:10 +0200 | frost | (~frost@user/frost) (Quit: Ping timeout (120 seconds)) |
| 2022-09-24 13:20:31 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) |
| 2022-09-24 13:29:48 +0200 | fjMSX | (~hypni2p@2.92.213.55) (Ping timeout: 264 seconds) |
| 2022-09-24 13:32:01 +0200 | fjMSX | (~hypni2p@2.92.213.55) |
| 2022-09-24 13:35:00 +0200 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) |
| 2022-09-24 13:36:28 +0200 | `2jt | (~jtomas@88.17.232.105) (Ping timeout: 246 seconds) |
| 2022-09-24 13:39:36 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 13:41:17 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds) |
| 2022-09-24 13:41:22 +0200 | acidjnk | (~acidjnk@p200300d6e7137a440dc2598308a8f039.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-09-24 13:45:49 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-09-24 13:46:29 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-09-24 13:51:25 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 13:55:12 +0200 | MoC | (~moc@user/moc) |
| 2022-09-24 13:58:12 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-09-24 13:58:36 +0200 | MoC | (~moc@user/moc) () |
| 2022-09-24 14:04:13 +0200 | Oiyqlk | (~rscastilh@191-214-26-24.user.veloxzone.com.br) |
| 2022-09-24 14:05:32 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-09-24 14:17:24 +0200 | Oiyqlk | (~rscastilh@191-214-26-24.user.veloxzone.com.br) () |
| 2022-09-24 14:19:10 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
| 2022-09-24 14:21:42 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection) |
| 2022-09-24 14:22:58 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 14:24:34 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2022-09-24 14:27:34 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 246 seconds) |
| 2022-09-24 14:32:50 +0200 | Lycurgus | (~juan@user/Lycurgus) (Ping timeout: 265 seconds) |
| 2022-09-24 14:42:09 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2022-09-24 14:44:42 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-24 14:50:03 +0200 | `2jt | (~jtomas@88.17.232.105) |
| 2022-09-24 14:52:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-24 14:54:34 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 14:59:56 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-24 15:06:53 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Remote host closed the connection) |
| 2022-09-24 15:09:40 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 15:11:48 +0200 | Oiyqlk | (~rscastilh@191-214-26-24.user.veloxzone.com.br) |
| 2022-09-24 15:14:24 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 15:16:13 +0200 | luffy | (~chenqisu1@183.217.203.170) (Ping timeout: 246 seconds) |
| 2022-09-24 15:17:21 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 15:19:52 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-09-24 15:22:01 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-24 15:29:04 +0200 | kenran | (~kenran@200116b82bfc8c00279f08e2bd7a5ad3.dip.versatel-1u1.de) |
| 2022-09-24 15:38:40 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 15:41:58 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 252 seconds) |
| 2022-09-24 15:48:22 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-24 15:52:03 +0200 | Guest13 | (~Guest13@2001:9e8:33f8:8e00:38fe:ac62:3541:d7d4) |
| 2022-09-24 15:55:25 +0200 | <Guest13> | Hi, I always get the error |
| 2022-09-24 15:55:26 +0200 | <Guest13> | error: Variable not in scope: chain :: t0 -> t |
| 2022-09-24 15:55:26 +0200 | <Guest13> | when running the function (Collatz function from a tutorial) |
| 2022-09-24 15:55:27 +0200 | <Guest13> | chain :: (Integral a) => a -> [a] |
| 2022-09-24 15:55:27 +0200 | <Guest13> | chain 1 = [1] |
| 2022-09-24 15:55:28 +0200 | <Guest13> | chain n |
| 2022-09-24 15:55:28 +0200 | <Guest13> | | even n = n:chain (n `div` 2) |
| 2022-09-24 15:55:29 +0200 | <Guest13> | | odd n = n:chain (n*3 + 1) |
| 2022-09-24 15:55:29 +0200 | <Guest13> | never saw the error before, what does it mean? Can anybody help? |
| 2022-09-24 15:56:04 +0200 | <geekosaur> | are you doing this in ghci? |
| 2022-09-24 15:56:17 +0200 | <Guest13> | yes |
| 2022-09-24 15:56:41 +0200 | <Guest13> | made a function in an hs file, loaded it in ghci and tried to run it there |
| 2022-09-24 15:56:42 +0200 | <geekosaur> | the whole thing has to be done in a single group, either on one line or using multiline input with :{ :} |
| 2022-09-24 15:56:51 +0200 | <geekosaur> | it will work better if you put it in a file, though |
| 2022-09-24 15:57:59 +0200 | <Guest13> | thanks for your help |
| 2022-09-24 15:58:43 +0200 | <Guest13> | but what is the meaning of the error? I'm trying to learn and understand Haskell at the moment. |
| 2022-09-24 16:01:27 +0200 | acidjnk | (~acidjnk@p200300d6e7137a44e06f3424b17412c0.dip0.t-ipconnect.de) |
| 2022-09-24 16:01:44 +0200 | vglfr | (~vglfr@145.224.100.100) (Read error: Connection reset by peer) |
| 2022-09-24 16:02:11 +0200 | <geekosaur> | I'd think "Variable not in scope" is pretty obvious; because ghci doesn't group related lines together by itself, it can't find `chain` when it needs it |
| 2022-09-24 16:02:13 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-09-24 16:02:46 +0200 | <geekosaur> | the rest of it is its best guess as the intended type, which it will usually get wrong because it doesn't know enough; you can ignore it for now |
| 2022-09-24 16:03:47 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Remote host closed the connection) |
| 2022-09-24 16:04:03 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 16:05:38 +0200 | <Guest13> | Okay, thanks for your help. It helped to find the bug. I had to save and reload my file in ghci/VSCode. Now it works. I'm just stupid :( |
| 2022-09-24 16:05:47 +0200 | <geekosaur> | ah |
| 2022-09-24 16:06:21 +0200 | <geekosaur> | I haven't used ghci from inside vscode yet, but similar things can happen with emacs; keeping two processes in sync like that is difficult at best |
| 2022-09-24 16:06:21 +0200 | <Guest13> | So there has been no chain function at all (y) |
| 2022-09-24 16:06:42 +0200 | <ski> | `:reload' (or `:r') can be used to reload files in the interactor |
| 2022-09-24 16:06:52 +0200 | <Guest13> | thanks(y) |
| 2022-09-24 16:06:55 +0200 | <geekosaur> | I would guess it sent `n:chain (n `div` 2)` to ghci without the rest of it |
| 2022-09-24 16:06:55 +0200 | <ski> | sounds consistent with the error message, Guest13 |
| 2022-09-24 16:08:04 +0200 | <geekosaur> | hm, no, that would add a Num and Integral constraint to the rather useless type it reported. |
| 2022-09-24 16:08:26 +0200 | Oiyqlk | (~rscastilh@191-214-26-24.user.veloxzone.com.br) () |
| 2022-09-24 16:08:27 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-24 16:08:37 +0200 | <ski> | usually i do changes, save, do `:r' in the interactor, then either investigate errors, starting over, or (possibly) try out example expressions before starting over |
| 2022-09-24 16:09:52 +0200 | <ski> | hm, i guess e.g. `chain n' would do |
| 2022-09-24 16:10:34 +0200 | <Guest13> | *Main> chain 10 |
| 2022-09-24 16:10:35 +0200 | <Guest13> | [10,5,16,8,4,2,1] |
| 2022-09-24 16:10:36 +0200 | <Guest13> | works fine now! |
| 2022-09-24 16:10:36 +0200 | <Guest13> | Thanx again for your help! |
| 2022-09-24 16:11:29 +0200 | <ski> | hm .. one could factor out the common "put input parameter as first element in output list" part, from all the three cases |
| 2022-09-24 16:12:26 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-09-24 16:12:46 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-24 16:15:25 +0200 | vglfr | (~vglfr@145.224.100.100) (Remote host closed the connection) |
| 2022-09-24 16:16:09 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 16:19:49 +0200 | vglfr | (~vglfr@145.224.100.100) (Remote host closed the connection) |
| 2022-09-24 16:20:23 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 16:21:38 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-24 16:22:36 +0200 | vglfr | (~vglfr@145.224.100.100) (Read error: Connection reset by peer) |
| 2022-09-24 16:22:56 +0200 | Guest13 | (~Guest13@2001:9e8:33f8:8e00:38fe:ac62:3541:d7d4) (Quit: Client closed) |
| 2022-09-24 16:23:03 +0200 | Athas_ | (athas@2a01:7c8:aaac:1cf:5a6a:37a5:b994:6597) |
| 2022-09-24 16:23:36 +0200 | odnes | (~odnes@ppp089210198232.access.hol.gr) |
| 2022-09-24 16:23:56 +0200 | Athas | (athas@sigkill.dk) (Ping timeout: 244 seconds) |
| 2022-09-24 16:24:11 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2022-09-24 16:25:11 +0200 | vglfr | (~vglfr@145.224.100.100) |
| 2022-09-24 16:25:52 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
| 2022-09-24 16:28:39 +0200 | Midjak | (~Midjak@82.66.147.146) (Read error: Connection reset by peer) |
| 2022-09-24 16:34:00 +0200 | sagax | (~sagax_nb@user/sagax) (Ping timeout: 264 seconds) |
| 2022-09-24 16:37:14 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 16:40:16 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-09-24 16:40:16 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-09-24 16:40:16 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-24 16:40:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 16:41:37 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 246 seconds) |
| 2022-09-24 16:52:57 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-09-24 16:54:39 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 16:59:17 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 17:00:25 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 17:08:01 +0200 | Athas_ | (athas@2a01:7c8:aaac:1cf:5a6a:37a5:b994:6597) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-09-24 17:09:28 +0200 | Athas | (athas@2a01:7c8:aaac:1cf:5a6a:37a5:b994:6597) |
| 2022-09-24 17:10:24 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-09-24 17:14:41 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-09-24 17:15:38 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-24 17:16:17 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 17:16:48 +0200 | waldo | (~waldo@user/waldo) (Quit: quit) |
| 2022-09-24 17:17:38 +0200 | waldo | (~waldo@user/waldo) |
| 2022-09-24 17:17:46 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-09-24 17:18:46 +0200 | kenran | (~kenran@200116b82bfc8c00279f08e2bd7a5ad3.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-09-24 17:22:26 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 252 seconds) |
| 2022-09-24 17:34:09 +0200 | ddellacosta | (~ddellacos@143.244.47.68) |
| 2022-09-24 17:38:31 +0200 | sagax | (~sagax_nb@user/sagax) |
| 2022-09-24 17:39:39 +0200 | weier | (~z@219.70.204.146) |
| 2022-09-24 17:40:24 +0200 | weier | (~z@219.70.204.146) (Client Quit) |
| 2022-09-24 17:41:28 +0200 | vglfr | (~vglfr@145.224.100.100) (Ping timeout: 246 seconds) |
| 2022-09-24 17:48:37 +0200 | chexum_ | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-24 17:50:26 +0200 | sudden | (~cat@user/sudden) (Ping timeout: 260 seconds) |
| 2022-09-24 17:51:23 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 17:51:54 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 17:52:49 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 258 seconds) |
| 2022-09-24 17:54:12 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-24 17:55:23 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-09-24 17:56:12 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 264 seconds) |
| 2022-09-24 17:56:23 +0200 | odnes | (~odnes@ppp089210198232.access.hol.gr) (Quit: Leaving) |
| 2022-09-24 18:03:00 +0200 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2022-09-24 18:03:49 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-24 18:08:26 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2022-09-24 18:08:45 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 18:14:22 +0200 | ddellacosta | (~ddellacos@143.244.47.68) (Ping timeout: 246 seconds) |
| 2022-09-24 18:18:38 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-24 18:18:56 +0200 | dsrt^ | (~dsrt@173-160-76-137-atlanta.hfc.comcastbusiness.net) |
| 2022-09-24 18:20:28 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-24 18:23:23 +0200 | johnw | (~johnw@2600:1700:cf00:db0:dd60:bc61:a3c9:2dac) |
| 2022-09-24 18:23:58 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 18:26:59 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer) |
| 2022-09-24 18:27:24 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-09-24 18:28:08 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-09-24 18:28:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 265 seconds) |
| 2022-09-24 18:31:31 +0200 | coot | (~coot@213.134.176.158) (Ping timeout: 246 seconds) |
| 2022-09-24 18:31:56 +0200 | khumba | (~khumba@user/khumba) |
| 2022-09-24 18:32:46 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 18:36:08 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-09-24 18:36:13 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-24 18:38:51 +0200 | `2jt | (~jtomas@88.17.232.105) (Ping timeout: 260 seconds) |
| 2022-09-24 18:39:52 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-09-24 18:40:08 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-09-24 18:41:19 +0200 | acidjnk | (~acidjnk@p200300d6e7137a44e06f3424b17412c0.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2022-09-24 18:48:40 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2022-09-24 18:50:50 +0200 | acidjnk | (~acidjnk@p200300d6e7137a459951f5994426b03a.dip0.t-ipconnect.de) |
| 2022-09-24 18:57:46 +0200 | econo | (uid147250@user/econo) |
| 2022-09-24 19:01:23 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-24 19:02:01 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 19:02:33 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-09-24 19:04:16 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Quit: coot) |
| 2022-09-24 19:04:29 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 19:09:05 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Client Quit) |
| 2022-09-24 19:09:12 +0200 | nate2 | (~nate@98.45.169.16) |
| 2022-09-24 19:09:20 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 19:10:25 +0200 | phao | (~phao@200-181-211-177.user3p.brasiltelecom.net.br) |
| 2022-09-24 19:11:30 +0200 | phao | (~phao@200-181-211-177.user3p.brasiltelecom.net.br) (Client Quit) |
| 2022-09-24 19:17:48 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 264 seconds) |
| 2022-09-24 19:19:24 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2022-09-24 19:19:25 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-09-24 19:19:25 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-24 19:20:38 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-09-24 19:23:14 +0200 | <EvanR> | I heard HashMap "is better" for string keys than Map. But, ... doesn't it need to hash the entire string argument, whereas Map only looks at enough string to discriminate enough keys |
| 2022-09-24 19:23:47 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Quit: coot) |
| 2022-09-24 19:24:00 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 19:24:46 +0200 | <hpc> | generally your keys are small and you have many of them |
| 2022-09-24 19:27:07 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-24 19:27:54 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-24 19:28:01 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Client Quit) |
| 2022-09-24 19:28:15 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 19:29:50 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-09-24 19:30:06 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-09-24 19:30:45 +0200 | <c_wraith> | honestly, the way Map approaches Strings (via Ord) isn't great either. |
| 2022-09-24 19:31:08 +0200 | <c_wraith> | You'd really want some sort of trie to avoid repeated comparison of portions that don't matter |
| 2022-09-24 19:31:26 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 19:31:27 +0200 | nate2 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-24 19:31:28 +0200 | sudden | (~cat@user/sudden) |
| 2022-09-24 19:31:29 +0200 | <EvanR> | yeah a trie seems better than either? at least for longer strings |
| 2022-09-24 19:31:41 +0200 | <c_wraith> | well. for when there are a lot of common prefixes |
| 2022-09-24 19:32:33 +0200 | nahcetan | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-24 19:34:03 +0200 | nahcetan | (~nate@98.45.169.16) |
| 2022-09-24 19:41:13 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-09-24 19:42:13 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-09-24 19:44:44 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-09-24 19:46:59 +0200 | raym | (~raym@user/raym) |
| 2022-09-24 19:49:44 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-24 19:50:23 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2022-09-24 19:54:56 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:488:11ee:612d:7b91) |
| 2022-09-24 20:02:23 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2022-09-24 20:02:24 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-09-24 20:02:24 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-24 20:06:21 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 20:09:16 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) |
| 2022-09-24 20:13:13 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-24 20:14:46 +0200 | burnsidesLlama | (~burnsides@119247164140.ctinets.com) (Ping timeout: 246 seconds) |
| 2022-09-24 20:17:25 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-09-24 20:18:54 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-09-24 20:18:58 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2022-09-24 20:22:06 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a459951f5994426b03a.dip0.t-ipconnect.de) |
| 2022-09-24 20:22:24 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Quit: coot) |
| 2022-09-24 20:25:25 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:25:36 +0200 | acidjnk | (~acidjnk@p200300d6e7137a459951f5994426b03a.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-09-24 20:25:39 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Remote host closed the connection) |
| 2022-09-24 20:25:50 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:28:57 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 20:29:06 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-09-24 20:29:07 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Client Quit) |
| 2022-09-24 20:29:57 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:30:07 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Remote host closed the connection) |
| 2022-09-24 20:30:18 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:31:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-24 20:35:04 +0200 | QNX | SystemV |
| 2022-09-24 20:35:17 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Quit: coot) |
| 2022-09-24 20:35:20 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 20:37:46 +0200 | nate3 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-09-24 20:39:28 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:39:44 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Remote host closed the connection) |
| 2022-09-24 20:39:55 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) |
| 2022-09-24 20:40:51 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-09-24 20:51:47 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2022-09-24 20:52:37 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-09-24 21:00:03 +0200 | moonsheep | (~user@user/moonsheep) |
| 2022-09-24 21:00:10 +0200 | moonsheep | (~user@user/moonsheep) () |
| 2022-09-24 21:07:34 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 21:12:41 +0200 | tomgus1 | (~tomgus1@2a02:c7e:4229:d900:dea6:32ff:fe3d:d1a3) (Read error: Connection reset by peer) |
| 2022-09-24 21:12:57 +0200 | tomgus1 | (~tomgus1@2e40cd7e.skybroadband.com) |
| 2022-09-24 21:13:21 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-09-24 21:21:36 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:22:18 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:22:20 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:22:29 +0200 | moonsheep | (~user@user/moonsheep) |
| 2022-09-24 21:24:12 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:24:18 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-09-24 21:26:12 +0200 | <moonsheep> | How should I handle exceptions with mtl-style transformers? I understand the *proper* way to handle exceptions is to use 'bracket' and its siblings, but unfortunately bracket requires you to pass it an IO computation. |
| 2022-09-24 21:26:22 +0200 | <moonsheep> | Is there any reason bracket couldn't take a MonadIO? |
| 2022-09-24 21:27:05 +0200 | <geekosaur> | how does it manufacture a value for a State on failure? |
| 2022-09-24 21:27:08 +0200 | <moonsheep> | And either way, how should I go about handling exceptions inside monad stacks where IO is nested potentially several layers deep? |
| 2022-09-24 21:27:31 +0200 | <moonsheep> | geekosaur: hmm, fair enough |
| 2022-09-24 21:27:50 +0200 | <moonsheep> | What is my best bet then? |
| 2022-09-24 21:28:07 +0200 | <moonsheep> | Add a ton of boilerplate to thread my mtl stack into the bracket? |
| 2022-09-24 21:28:23 +0200 | <[Leary]> | moonsheep: Look into unliftio. It's created to be the answer to this question. |
| 2022-09-24 21:28:34 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:28:53 +0200 | <moonsheep> | Oh interesting, didn't know about it |
| 2022-09-24 21:29:02 +0200 | <moonsheep> | I'll give it a look |
| 2022-09-24 21:29:25 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:30:00 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:30:01 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 21:31:12 +0200 | <moonsheep> | [Leary]: this seems to be exactly what I wanted, thanks! |
| 2022-09-24 21:32:43 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:33:58 +0200 | <johnw> | moonsheep: https://hackage.haskell.org/package/exceptions-0.10.5/docs/Control-Monad-Catch.html#v:bracket |
| 2022-09-24 21:34:19 +0200 | <johnw> | I don't think any MonadIO m is automatically a MonadMask m |
| 2022-09-24 21:34:52 +0200 | `2jt | (~jtomas@88.17.232.105) |
| 2022-09-24 21:34:56 +0200 | <johnw> | but yes, unliftio is a specialization of what MonadBaseControl does |
| 2022-09-24 21:35:32 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:35:55 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:36:57 +0200 | vglfr | (~vglfr@145.224.100.190) (Remote host closed the connection) |
| 2022-09-24 21:37:38 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-09-24 21:37:46 +0200 | tomgus1 | (~tomgus1@2e40cd7e.skybroadband.com) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2022-09-24 21:38:55 +0200 | tomgus1 | (~tomgus1@2a02:c7e:4229:d900:dea6:32ff:fe3d:d1a3) |
| 2022-09-24 21:39:41 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds) |
| 2022-09-24 21:41:20 +0200 | <moonsheep> | johnw: oh thanks, I think I'll go with unliftio though |
| 2022-09-24 21:43:36 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-09-24 21:44:34 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 21:47:26 +0200 | pavonia | (~user@user/siracusa) |
| 2022-09-24 21:48:13 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 246 seconds) |
| 2022-09-24 21:48:32 +0200 | david | (~david@2a01:e34:ec2b:d430:44a:f5ca:9867:d69d) |
| 2022-09-24 21:48:41 +0200 | <david> | Hello ! |
| 2022-09-24 21:48:49 +0200 | <david> | I have a question |
| 2022-09-24 21:49:09 +0200 | <geekosaur> | ask! |
| 2022-09-24 21:49:16 +0200 | <david> | How can you map "* | undefined" to Just * | Nothing ? |
| 2022-09-24 21:49:31 +0200 | <ski> | no |
| 2022-09-24 21:49:34 +0200 | <geekosaur> | you can't treat undefined as a value |
| 2022-09-24 21:49:44 +0200 | <david> | ok |
| 2022-09-24 21:49:52 +0200 | <david> | let me try another way |
| 2022-09-24 21:50:09 +0200 | <ski> | `foo _ Nothing' defines `foo' to map `undefined' to `Nothing', but also everything else to `Nothing' |
| 2022-09-24 21:50:17 +0200 | <david> | I have a read implementation that maps a char to a value |
| 2022-09-24 21:50:42 +0200 | <david> | how could I handl the fact that a given char is not in the acceptable range for this function? |
| 2022-09-24 21:50:52 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:cd27:ded2:4351:8688) |
| 2022-09-24 21:51:03 +0200 | <EvanR> | map char to Maybe value? |
| 2022-09-24 21:51:09 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-09-24 21:51:12 +0200 | <ski> | `foo Something = Just SomethingElse' makes `foo' map `Something' to `Just SomethingElse', but will map `undefined' to `undefined' (or more specifically, map any "undefined value" to an "undefined value") |
| 2022-09-24 21:51:37 +0200 | kenran | (~kenran@200116b82bfc8c0061dac18751f3996d.dip.versatel-1u1.de) |
| 2022-09-24 21:51:49 +0200 | <david> | EvanR: thank you, I will try this. |
| 2022-09-24 21:51:59 +0200 | <ski> | the only way to map `undefined' to something that's not undefined, is to map everything to that not-undefined something |
| 2022-09-24 21:52:12 +0200 | <ski> | otherwise, you'll always map undefined/bottom to undefined/bottom |
| 2022-09-24 21:52:30 +0200 | <david> | ok, crystal clear ski, thanks ! |
| 2022-09-24 21:52:39 +0200 | <ski> | `Maybe Value' or maybe `[Value]' sounds like what you'd want, yea |
| 2022-09-24 21:52:40 +0200 | <EvanR> | as long as you only deal in "defineds" it's a lot simpler xD |
| 2022-09-24 21:53:03 +0200 | <ski> | you shouldn't think of `undefined' as a value which you can handle, recognize |
| 2022-09-24 21:53:21 +0200 | <johnw> | that would indeed be giving it some definition |
| 2022-09-24 21:53:56 +0200 | <ski> | it is unknown whether `head (filter oddPerfectNumber [0 ..])' will give a defined number or not |
| 2022-09-24 21:54:36 +0200 | <EvanR> | so you got your known defineds, known undefineds, and unknown (un)defined |
| 2022-09-24 21:55:37 +0200 | <ski> | you can have computations which you don't know whether they'll terminate. if you build one which you know won't terminate, then Haskell still won't know that (e.g. `last [0 ..]' or `filter odd [0,2 ..]'). Haskell can only try evaluate it, and keep going. "nontermination" is not observable |
| 2022-09-24 21:58:33 +0200 | <ski> | (then Haskell also throws in partiality, like `head []' into the "bottom" or "undefined values", because, well .. they are not giving back proper values to you. these do terminate (in the sense of aborting the computation, rather than giving a result value), but you can't observe this, in "pure Haskell" (you can catch it in `IO', if you really want/need to. but you probably should try to avoid that, if you |
| 2022-09-24 21:58:39 +0200 | <ski> | can. it's better if you can signal such failures in other ways, like `Nothing' or `[]'. using `IO' to catch it indicates a failure to use proper failure-signalling means. sometimes it may be necessary, but it's regrettable)) |
| 2022-09-24 21:59:49 +0200 | <EvanR> | use head only if it won't fail |
| 2022-09-24 21:59:57 +0200 | <EvanR> | and sometimes not even then! |
| 2022-09-24 22:00:42 +0200 | <ski> | to a first approximation, from the point of view of Haskell's semantics, both `head []' (partiality) and `last [0 ..]' (nontermination) are treated as if they're interchangable, nondistinguishable. both are "undefined/bottom 'values'" (in fact, the variable `undefined' is bound to a partial computation (calling `error', i believe), rather than a non-terminating one) |
| 2022-09-24 22:00:53 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-09-24 22:01:21 +0200 | <ski> | in `error "foo" + error "bar"', you can't depend on which of the two reasons for partiality that you'll get, if you catch this in `IO' |
| 2022-09-24 22:02:45 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 22:02:48 +0200 | <ski> | @remember EvanR so you got your known defineds, known undefineds, and unknown (un)defined |
| 2022-09-24 22:02:48 +0200 | <lambdabot> | Done. |
| 2022-09-24 22:03:04 +0200 | <EvanR> | +s |
| 2022-09-24 22:03:34 +0200 | <EvanR> | I'd use correct spelling if I knew the quotation paparazzi showed up |
| 2022-09-24 22:03:42 +0200 | <ski> | @forget EvanR so you got your known defineds, known undefineds, and unknown (un)defined |
| 2022-09-24 22:03:43 +0200 | <lambdabot> | Done. |
| 2022-09-24 22:03:45 +0200 | <ski> | @remember EvanR so you got your known defineds, known undefineds, and unknown (un)defineds |
| 2022-09-24 22:03:46 +0200 | <lambdabot> | Nice! |
| 2022-09-24 22:03:47 +0200 | <EvanR> | lol |
| 2022-09-24 22:03:48 +0200 | <ski> | better ? :) |
| 2022-09-24 22:04:11 +0200 | jnz | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) |
| 2022-09-24 22:04:16 +0200 | jnz | undefined |
| 2022-09-24 22:04:23 +0200 | undefined | jnz |
| 2022-09-24 22:04:37 +0200 | <EvanR> | rumsfeld would have made a great haskeller |
| 2022-09-24 22:04:59 +0200 | ski | . o O ( are there unknown knowns ? 9 |
| 2022-09-24 22:05:42 +0200 | <dolio> | Yeah. That's what Star Wars is all about. |
| 2022-09-24 22:06:27 +0200 | ski | wouldn't know |
| 2022-09-24 22:07:02 +0200 | <byorgey> | dolio, lol |
| 2022-09-24 22:07:23 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 22:08:15 +0200 | coot | (~coot@89-76-160-4.dynamic.chello.pl) (Quit: coot) |
| 2022-09-24 22:09:09 +0200 | jnz | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) (Remote host closed the connection) |
| 2022-09-24 22:09:21 +0200 | <johnw> | hi byorgey! |
| 2022-09-24 22:10:16 +0200 | moonsheep | (~user@user/moonsheep) (ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2022-09-24 22:10:16 +0200 | <byorgey> | hi johnw! |
| 2022-09-24 22:11:27 +0200 | <ski> | david : ooc, what's your `Read' implementation ? |
| 2022-09-24 22:11:39 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 244 seconds) |
| 2022-09-24 22:13:04 +0200 | <ski> | .. i guess you could think of bottoms as being "landmines" or "bear traps" |
| 2022-09-24 22:14:16 +0200 | <ski> | if you don't approach them, you're fine (like the `foo _ = Nothing', calling `foo undefined' doesn't look at `undefined') |
| 2022-09-24 22:14:39 +0200 | <ski> | but if you do investigate them (like `foo Something = Just SomethingElse', where `foo undefined' will try to check if `undefined' is `Something' as so trip over), you either blow up (partiality), or you're stuck (non-termination) |
| 2022-09-24 22:17:08 +0200 | pera | (~pera@user/pera) |
| 2022-09-24 22:17:48 +0200 | jnz | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) |
| 2022-09-24 22:18:29 +0200 | <DigitalKiwi> | https://www.dropbox.com/s/s047emghqja7cc7/2019-07-18%2012.10.53.jpg?dl=0 |
| 2022-09-24 22:19:51 +0200 | jnz44 | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) |
| 2022-09-24 22:20:34 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-09-24 22:20:45 +0200 | <ski> | sounds like someone's been into the Sierpinski space .. or maybe lattices or Boolean algebras |
| 2022-09-24 22:23:57 +0200 | <EvanR> | in haskell there is a bottom but no top. So it's like temperature. Some languages imagine that there's a complete universe of values and define the top. So they have absolute zero and infinite temperature there |
| 2022-09-24 22:24:10 +0200 | <EvanR> | so it's like temperature |
| 2022-09-24 22:26:41 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-09-24 22:27:17 +0200 | <hpc> | some physical objects can temporarily behave like they have negative temperature |
| 2022-09-24 22:27:47 +0200 | <hpc> | i wonder if you can write a negative type |
| 2022-09-24 22:28:25 +0200 | jnz44 | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) (Quit: jnz44) |
| 2022-09-24 22:28:58 +0200 | <byorgey> | hpc: https://dl.acm.org/doi/pdf/10.1145/3434290 |
| 2022-09-24 22:29:11 +0200 | jnz73 | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) |
| 2022-09-24 22:29:13 +0200 | jnz73 | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) (Client Quit) |
| 2022-09-24 22:30:18 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-09-24 22:31:01 +0200 | jgeerds_ | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-09-24 22:31:02 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 22:31:12 +0200 | jnz | (~jnz@81.143.79.83.dynamic.wline.res.cust.swisscom.ch) (Remote host closed the connection) |
| 2022-09-24 22:31:42 +0200 | <EvanR> | negative types reverse time while fractional types reverse space. Got it |
| 2022-09-24 22:32:37 +0200 | <EvanR> | that's some dr strange shit |
| 2022-09-24 22:34:14 +0200 | <Lycurgus> | time is at least a scalar, 'space' is polysemous |
| 2022-09-24 22:34:14 +0200 | `2jt | (~jtomas@88.17.232.105) (Ping timeout: 265 seconds) |
| 2022-09-24 22:34:42 +0200 | Null_A | (~null_a@2601:645:8700:ac10:1005:19fc:119b:3387) |
| 2022-09-24 22:34:47 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-09-24 22:35:02 +0200 | <Lycurgus> | and by scalar I meant a single coherent concept |
| 2022-09-24 22:35:49 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 22:37:38 +0200 | <darkling> | Depends on how fast you're moving. |
| 2022-09-24 22:37:49 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-09-24 22:37:51 +0200 | <Lycurgus> | that time could be reversed is pretty much the shibboleth misextension of a concept or at least coequal with substantive space |
| 2022-09-24 22:38:01 +0200 | Null_A_ | (~null_a@2601:645:8700:ac10:588d:dcc4:cf71:c2f0) (Ping timeout: 244 seconds) |
| 2022-09-24 22:39:02 +0200 | <Lycurgus> | with similar coherence which is why it so worked in mass media production |
| 2022-09-24 22:39:14 +0200 | <Lycurgus> | *it's |
| 2022-09-24 22:39:38 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-09-24 22:40:08 +0200 | dsrt^ | (~dsrt@173-160-76-137-atlanta.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 2022-09-24 22:40:20 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2022-09-24 22:41:55 +0200 | <byorgey> | "negative types reverse time" is of course just a cool-sounding slogan. More accurately, that paper proposes that negative types can be thought of as reversing control flow. |
| 2022-09-24 22:42:15 +0200 | <EvanR> | goto => comefrom |
| 2022-09-24 22:42:45 +0200 | <Lycurgus> | ah |
| 2022-09-24 22:42:58 +0200 | ski | . o O ( "The Two Dualities of Computation: Negative and Fractional Types" by Roshan P. James,Amr Sabry in ~2012 at <https://legacy.cs.indiana.edu/~sabry/papers/rational.pdf> ; "Fractional Types" by Roshan P. James,Zachary Sparks,Jacques Carette,Amr Sabry in ~2013 at <https://legacy.cs.indiana.edu/~sabry/papers/fractionals.pdf> ) |
| 2022-09-24 22:43:09 +0200 | ski | . o O ( <https://mathoverflow.net/questions/100158/negative-objects-in-categories>,<https://golem.ph.utexas.edu/category/2009/08/the_pi_calculus.html>,<https://www.reddit.com/r/haskell/comments/6e7s58/negative_and_fractional_types_in_haskell/>,<https://www.reddit.com/r/haskell/comments/25ujqk/is_there_any_implementation_for_this_paper_about/> ) |
| 2022-09-24 22:43:15 +0200 | ski | . o O ( "Fractional power of units of measures in F#" <https://stackoverflow.com/questions/11333135/fractional-power-of-units-of-measures-in-f> ; "Semi--vector spaces and units of measurement" by Josef Janyška,Marco Modugno,Raffaele Vitolo in 2007-10-05 at <https://arxiv.org/abs/0710.1313v1> ) |
| 2022-09-24 22:47:26 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-09-24 22:47:27 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-09-24 22:47:27 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-24 22:47:38 +0200 | Null_A_ | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) |
| 2022-09-24 22:49:07 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 22:50:56 +0200 | Null_A | (~null_a@2601:645:8700:ac10:1005:19fc:119b:3387) (Ping timeout: 244 seconds) |
| 2022-09-24 22:53:17 +0200 | kenran | (~kenran@200116b82bfc8c0061dac18751f3996d.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-09-24 22:54:14 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-09-24 22:54:21 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 22:54:22 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 22:59:43 +0200 | waldo | (~waldo@user/waldo) (Quit: quit) |
| 2022-09-24 23:01:52 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-09-24 23:02:58 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-09-24 23:04:41 +0200 | Ristovski | (~Ristovski@hellomouse/perf/ristovski) (Ping timeout: 265 seconds) |
| 2022-09-24 23:06:10 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 23:09:53 +0200 | Ristovski | (~Ristovski@hellomouse/perf/ristovski) |
| 2022-09-24 23:13:48 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-09-24 23:14:19 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-09-24 23:24:01 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 265 seconds) |
| 2022-09-24 23:25:00 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a459951f5994426b03a.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-09-24 23:29:00 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 23:30:58 +0200 | <johnw> | is this math spam? :) |
| 2022-09-24 23:31:00 +0200 | ubert | (~Thunderbi@91.141.58.249.wireless.dyn.drei.com) (Ping timeout: 264 seconds) |
| 2022-09-24 23:31:47 +0200 | <darkling> | What other sort do you expect in this channel? |
| 2022-09-24 23:32:27 +0200 | <johnw> | constructions that approximate math until you start taking undefined into account... |
| 2022-09-24 23:33:12 +0200 | <byorgey> | math spam is when you send your proof of the collatz conjecture to 50 different professors. |
| 2022-09-24 23:33:26 +0200 | <monochrom> | Unpopular opinion: It is math that approximates your constructions! |
| 2022-09-24 23:34:10 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-09-24 23:34:11 +0200 | <johnw> | Haskeller: "Hey, list is the free monoid!" Internet: "No, actually it isn't..."; Haskeller: "Hey, Hask is a category!" Internet: "Well, sorry to tell you, but..." ;-) |
| 2022-09-24 23:34:18 +0200 | <monochrom> | More unpopular opinion: Math is a social construct that is constructed to approximate other social constructs! |
| 2022-09-24 23:34:39 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2022-09-24 23:35:27 +0200 | <monochrom> | I would s/Internet/A vocal fringe minority of pedants who happen to be on the Internet/ |
| 2022-09-24 23:35:39 +0200 | <johnw> | Math is a set of axioms that we are thus far the most content with as an illusion of "truth". |
| 2022-09-24 23:36:19 +0200 | <johnw> | now I'm at the edge of math trolling |
| 2022-09-24 23:36:45 +0200 | <johnw> | I will return to writing some Haskell |
| 2022-09-24 23:36:45 +0200 | <monochrom> | In that case, was I at the edge of philosophy-of-math trolling? :) |
| 2022-09-24 23:36:51 +0200 | <johnw> | lol |
| 2022-09-24 23:36:54 +0200 | <dolio> | Yeah, most people get the role of math backwards. |
| 2022-09-24 23:37:35 +0200 | <dolio> | Like when they say that physicists can't do stuff because math says so. |
| 2022-09-24 23:37:37 +0200 | nate3 | (~nate@98.45.169.16) |
| 2022-09-24 23:37:51 +0200 | <dolio> | That means the math isn't correctly capturing what works in physics. |
| 2022-09-24 23:38:01 +0200 | <darkling> | byorgey: 50... then 25, 76, 38, 19, 58, 29, 88, ...? |
| 2022-09-24 23:40:26 +0200 | <c_wraith> | monochrom: trolling? no, that's what people I know with extensive training in math and philosophy say seriously. :P |
| 2022-09-24 23:40:29 +0200 | <dolio> | Or what doesn't work. |
| 2022-09-24 23:40:40 +0200 | <dolio> | Like all that excluded middle nonsense. :þ |
| 2022-09-24 23:40:54 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-09-24 23:41:19 +0200 | <monochrom> | Ugh. Either I'm a wave function or I am not a wave function! |
| 2022-09-24 23:42:07 +0200 | Null_A_ | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) () |
| 2022-09-24 23:42:28 +0200 | <monochrom> | Oddly enough I volunteered to give an undergrad talk on intuitionistic logic and its Kripke semantics! |
| 2022-09-24 23:42:29 +0200 | <darkling> | Are you particular about it, though? |
| 2022-09-24 23:42:43 +0200 | ski | . o O ( "A vocal fringe minority of pedants who happen to be on the Internet" -- isn't that all of us ? ) |
| 2022-09-24 23:42:53 +0200 | <monochrom> | I am not a pedant. |
| 2022-09-24 23:42:59 +0200 | <ski> | clearly you're both a wave function or a particle |
| 2022-09-24 23:43:15 +0200 | <ski> | (linear logic "par") |
| 2022-09-24 23:43:43 +0200 | <ski> | monochrom : hm, and relation to epistemic modal logic ? |
| 2022-09-24 23:44:02 +0200 | <johnw> | see, trolling successful |
| 2022-09-24 23:44:06 +0200 | <monochrom> | I don't know that one, so I won't go that far. |
| 2022-09-24 23:44:18 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-24 23:44:54 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 23:46:36 +0200 | <monochrom> | OTOH I might end up doing that without knowing, when I try to give an intuition of Kripke's idea by "imagine you design an 4X game so you dictate the tech tree of the civ, i.e., the subjective truths of that civ, past present and future". |
| 2022-09-24 23:46:42 +0200 | <DigitalKiwi> | 16:42 monochrom: I am not a pedant. => X |
| 2022-09-24 23:46:45 +0200 | <monochrom> | Speaking of unknown knowns. |
| 2022-09-24 23:46:47 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-24 23:46:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-09-24 23:46:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-24 23:54:44 +0200 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
