Logs: freenode/#haskell
| 2021-04-13 07:54:02 | <opqdonut> | https://hackage.haskell.org/package/network-uri-2.6.4.1/docs/Network-URI.html#v:parseURI |
| 2021-04-13 07:54:45 | <merijn> | I missed the question, vty for what? |
| 2021-04-13 07:55:14 | <merijn> | (i.e., maybe brick is more appropriate?) |
| 2021-04-13 07:55:15 | <opqdonut> | "is there a package that makes it easier to display things in the terminal?" |
| 2021-04-13 07:55:38 | <merijn> | brick :p |
| 2021-04-13 07:55:43 | <merijn> | vty is low level |
| 2021-04-13 07:55:59 | <merijn> | brick is more of "widgets for terminal UI" library |
| 2021-04-13 07:55:59 | <opqdonut> | nice, I hadn't heard of brick |
| 2021-04-13 07:56:13 | <merijn> | opqdonut: It's the successor of the (now deprecated) vty-ui |
| 2021-04-13 07:56:35 | <merijn> | vty is really intended to be a low level terminal interface |
| 2021-04-13 07:59:16 | × | santiacq quits (~santiacq@r186-50-76-54.dialup.adsl.anteldata.net.uy) (Read error: Connection reset by peer) |
| 2021-04-13 08:00:08 | → | santiacq joins (~santiacq@r167-60-229-44.dialup.adsl.anteldata.net.uy) |
| 2021-04-13 08:02:34 | × | sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2021-04-13 08:03:35 | × | Sgeo_ quits (~Sgeo@ool-18b98aa4.dyn.optonline.net) (Read error: Connection reset by peer) |
| 2021-04-13 08:04:48 | → | dhil joins (~dhil@80.208.56.181) |
| 2021-04-13 08:07:20 | → | hendursa1 joins (~weechat@gateway/tor-sasl/hendursaga) |
| 2021-04-13 08:08:52 | <bahamas> | opqdonut, merijn thank you! |
| 2021-04-13 08:08:54 | → | acidjnk_new joins (~acidjnk@p200300d0c72b9561cdce4d77de6ce0bc.dip0.t-ipconnect.de) |
| 2021-04-13 08:09:57 | × | hendursaga quits (~weechat@gateway/tor-sasl/hendursaga) (Ping timeout: 240 seconds) |
| 2021-04-13 08:10:25 | × | fiedlr quits (~fiedlr@83.148.33.254) (Remote host closed the connection) |
| 2021-04-13 08:10:40 | → | fiedlr joins (~fiedlr@83.148.33.254) |
| 2021-04-13 08:13:08 | → | chele joins (~chele@78.128.94.174) |
| 2021-04-13 08:13:14 | → | kiweun joins (~kiweun@2607:fea8:2a62:9600:e029:f384:595c:2c74) |
| 2021-04-13 08:17:57 | × | kiweun quits (~kiweun@2607:fea8:2a62:9600:e029:f384:595c:2c74) (Ping timeout: 258 seconds) |
| 2021-04-13 08:19:41 | × | KeyJoo quits (~KeyJoo@62.176.30.191) (Ping timeout: 260 seconds) |
| 2021-04-13 08:21:39 | → | mikoto-chan joins (~anass@gateway/tor-sasl/mikoto-chan) |
| 2021-04-13 08:21:42 | × | kini quits (~kini@unaffiliated/kini) (Remote host closed the connection) |
| 2021-04-13 08:21:45 | × | malumore_ quits (~malumore@151.62.122.89) (Remote host closed the connection) |
| 2021-04-13 08:22:04 | → | malumore_ joins (~malumore@151.62.122.89) |
| 2021-04-13 08:22:56 | × | todda7 quits (~torstein@athedsl-09242.home.otenet.gr) (Ping timeout: 268 seconds) |
| 2021-04-13 08:22:58 | → | kini joins (~kini@unaffiliated/kini) |
| 2021-04-13 08:24:23 | × | drbean_ quits (~drbean@TC210-63-209-98.static.apol.com.tw) (Ping timeout: 252 seconds) |
| 2021-04-13 08:26:14 | → | jpe90 joins (~user@pool-108-31-85-19.washdc.fios.verizon.net) |
| 2021-04-13 08:31:08 | <jpe90> | hi guys, i'm very new to haskell- could someone help me understand why my implementation of the "zip" list function gives an exception for non-exhaustive patterns? https://rextester.com/SVKB21534 |
| 2021-04-13 08:32:21 | <Arahael> | jpe90: Which pattern does it match if there are zero elements? |
| 2021-04-13 08:32:44 | <Arahael> | jpe90: Remember the three most important numbers: 0, 1, and infinity. |
| 2021-04-13 08:33:06 | <merijn> | jpe90: oof... that call to length is pretty bad |
| 2021-04-13 08:33:33 | <merijn> | That function as written now is gonna be something, like O(n^3) or something |
| 2021-04-13 08:33:57 | → | timCF joins (~i.tkachuk@200-149-20-81.sta.estpak.ee) |
| 2021-04-13 08:34:47 | <merijn> | jpe90: Anyway, you patterns already check that the lists are non-empty, so the length call is redundant |
| 2021-04-13 08:35:12 | → | todda7 joins (~torstein@athedsl-09242.home.otenet.gr) |
| 2021-04-13 08:35:47 | <jpe90> | oh okay I wasn't understanding the pattern mechanism |
| 2021-04-13 08:36:13 | <jpe90> | still wrapping my head around the basics |
| 2021-04-13 08:36:27 | <timCF> | Hello! Can anybody suggest correct way to compose `ExceptT` with other transformers, for example `SqlPersistT` from Persistent/Equeleto package? For example I have SQL procedure of type `SqlPersistT m (Either a b)` but I don't want to do bind+case boilerplate and operate inside `ExceptT` context as well. |
| 2021-04-13 08:37:10 | <Arahael> | jpe90: You have only one pattern - but two guards. |
| 2021-04-13 08:37:19 | <Arahael> | jpe90: And the guards are what's expensive here. |
| 2021-04-13 08:37:53 | <jpe90> | right, and in that pattern i'm implicitly stating that (x:xs) and (y:ys) are non null, is that correct? which is probably a mistake? |
| 2021-04-13 08:37:56 | <merijn> | timCF: The correct way to compose anything with SqlPersistT requires a thorough study of the persistent codebase >.> |
| 2021-04-13 08:37:57 | → | thc202 joins (~thc202@unaffiliated/thc202) |
| 2021-04-13 08:38:02 | <merijn> | jpe90: Not implicitly, explicitly :p |
| 2021-04-13 08:38:16 | <jpe90> | haha got it |
| 2021-04-13 08:38:34 | <merijn> | jpe90: You pattern match on constructors, lists have 2 constructors [] (i.e., empty list) and : (i.e. a first element and remainder) |
| 2021-04-13 08:40:10 | <jpe90> | so i should probably just add pattern matches for empty lists in either positiona nd get rid of the guards |
| 2021-04-13 08:40:19 | <merijn> | jpe90: So your pattern currently only handle the case where both lists are non-empty |
| 2021-04-13 08:40:24 | <merijn> | jpe90: Yeah |
| 2021-04-13 08:40:30 | <timCF> | merijn: let's say for simplicity - it's just some isomorphic generic transformer `trans m (Either a b)`. You are saying there is no true correct way to get rid of `Either` and mix `trans` capabilities with `ExceptT`? |
| 2021-04-13 08:41:00 | <merijn> | jpe90: Side-note: "length" is O(n) (because lists are linked lists and you need to walk the entire thing to find out the length) so you wanna avoid that whenever possible |
| 2021-04-13 08:41:28 | <merijn> | timCF: In general you'd probably want |
| 2021-04-13 08:41:30 | <merijn> | @hackage mmorph |
| 2021-04-13 08:41:30 | <lambdabot> | https://hackage.haskell.org/package/mmorph |
| 2021-04-13 08:41:48 | <merijn> | But I'd be super paranoid about mixing that with SqlPersistT |
| 2021-04-13 08:42:06 | <merijn> | Because that's gonna make reasoning about transactions super hard |
| 2021-04-13 08:42:11 | → | DavidEichmann joins (~david@47.27.93.209.dyn.plus.net) |
| 2021-04-13 08:43:19 | <timCF> | merijn: you mean that in some cases I want to rollback in case of `Left` but in some other cases it make sense to continue transaction? |
| 2021-04-13 08:43:35 | → | Pickchea joins (~private@unaffiliated/pickchea) |
| 2021-04-13 08:43:48 | <jpe90> | merijn: gotcha.. this seems to work and is hopefully better https://rextester.com/KWIHZ83934 |
| 2021-04-13 08:43:58 | <timCF> | merijn: and blindly mixing SqlPersistT with ExceptT will not give me ability to make these decisions? |
| 2021-04-13 08:44:14 | <merijn> | timCF: Well, suppose you end up with "SqlPersistT (ExceptT e m) a" or "ExceptT e (SqlPersistT m) a" do you know what kinda short-circuiting happens when you run them? |
| 2021-04-13 08:44:36 | <merijn> | If you hit Left, will you skip all the remaining queries and then commit? Or will you bail out? Or...? |
| 2021-04-13 08:44:51 | <merijn> | jpe90: Yeah, that looks about right |
| 2021-04-13 08:44:59 | <jpe90> | alright cool thanks guys |
| 2021-04-13 08:45:11 | <Arahael> | merijn: Talking about jpe90's example, I usually organise those patterns the opposite way - but does that have an impact on performance? |
| 2021-04-13 08:45:11 | <merijn> | jpe90: You can make it slightly shorter |
| 2021-04-13 08:45:31 | <jpe90> | oh yeah? how so |
| 2021-04-13 08:45:39 | <merijn> | jpe90: https://paste.tomsmeding.com/McvKOmVR |
| 2021-04-13 08:45:48 | <timCF> | merijn: thanks! |
| 2021-04-13 08:45:59 | <jpe90> | oh i see |
| 2021-04-13 08:46:02 | <merijn> | jpe90: Consider this: When the first case (both non-empty) fails, then at least 1 of the two must be empty |
| 2021-04-13 08:46:19 | <merijn> | And you don't have to care which |
| 2021-04-13 08:46:41 | <jpe90> | right that makes sense |
| 2021-04-13 08:46:57 | <Arahael> | That's also why I typically order them the other way. :) Just wondering if there's a performance implication here, too. |
| 2021-04-13 08:47:19 | <jpe90> | ah so you're saying you like to put failure patterns after success patterns in general |
| 2021-04-13 08:47:40 | × | heatsink quits (~heatsink@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2021-04-13 08:48:01 | <merijn> | jpe90: If you have only 1 failure result, you can write things for the happy path and then handle all the failures at once |
| 2021-04-13 08:48:24 | <merijn> | jpe90: I'm not sure I'd recommend that "in general", it can make sense to handle (some) failures first |
| 2021-04-13 08:48:48 | <merijn> | But patterns are checked "top to bottom", so smart ordering can make code a lot cleaner/simpler |
| 2021-04-13 08:52:36 | × | __minoru__shirae quits (~shiraeesh@109.166.56.189) (Ping timeout: 246 seconds) |
| 2021-04-13 08:54:54 | <ski> | Arahael : yes (and strictness) |
| 2021-04-13 08:55:07 | <Arahael> | ski: Makes sense. |
| 2021-04-13 08:55:51 | <Arahael> | jpe90: Btw, you can enable a compiler option to make any non-total function result in a warning when you compile. |
| 2021-04-13 08:55:59 | <merijn> | Arahael: No you can't |
| 2021-04-13 08:56:00 | <ski> | with the recursive case first, as in merijn's paste, `zip [] _|_' is `[]'. with the recursive case last, it would be `_|_' |
| 2021-04-13 08:56:11 | <Arahael> | jpe90: So that your function should not have to fail at runtime for i to... Oh, you can't, merijn? |
| 2021-04-13 08:56:11 | <merijn> | Arahael: You can make incomplete patterns a warning |
| 2021-04-13 08:56:21 | <Arahael> | Ah - there's a difference? |
| 2021-04-13 08:56:25 | <merijn> | Arahael: I dunno, did you solve the Halting problem? |
| 2021-04-13 08:56:34 | <merijn> | :p |
| 2021-04-13 08:56:50 | <Arahael> | merijn: Ok, so my understanding of what "total" meant is slightly incorrect, then. |
| 2021-04-13 08:57:02 | <merijn> | Arahael: A total function is one that is guaranteed to terminate, so you gotta rule out non-termination to know if something is total :) |
| 2021-04-13 08:57:10 | <Arahael> | Ah, indeed. |
All times are in UTC.