Logs: freenode/#xmonad
| 2020-12-16 19:37:33 | × | weechat_2 quits (~mingc@2400:8902::f03c:91ff:feb7:8e82) (*.net *.split) |
| 2020-12-16 19:37:33 | × | arzano quits (~arzano@gentoo/developer/arzano) (*.net *.split) |
| 2020-12-16 19:39:42 | <ElKowar> | hmmmmmm, getting 'GhcException: "could not execute: gcc"' from the eval thingy,.... might that also be related to me not having anything installed on the system level? |
| 2020-12-16 19:39:46 | → | geekosaur joins (42d52137@66.213.33.55) |
| 2020-12-16 19:51:13 | arzano_ | is now known as arzano |
| 2020-12-16 19:51:23 | × | malook quits (~Thunderbi@5.110.184.12) (Quit: malook) |
| 2020-12-16 19:52:46 | × | cfricke quits (~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.0) |
| 2020-12-16 19:53:52 | <geekosaur> | you're going to have all sorts of problems getting XMonad.Prompt.Eval to behave, yes. |
| 2020-12-16 19:54:22 | <geekosaur> | and then you'll find it's not very useful because it can't access or modify the state of the running xmonad, only a copy of it |
| 2020-12-16 19:54:50 | <geekosaur> | (Haskell doesn't have the kind of introspection that would be needed to do what you'd like) |
| 2020-12-16 19:57:41 | <ElKowar> | wait i can't even _read_ the state? oooofff... |
| 2020-12-16 19:58:33 | <geekosaur> | I don't think it pops a copy into the ghci session it instantiates |
| 2020-12-16 19:59:23 | <ElKowar> | hmmm sad |
| 2020-12-16 20:00:09 | <ElKowar> | i would have thought that System.Eval actually does some magic to dynamically link in the code it just compiled and run it directly in the containing application |
| 2020-12-16 20:00:58 | <geekosaur> | as I just said, Haskell doesn't have that level of introspection. (it'd completely break purity, for one) |
| 2020-12-16 20:02:43 | <ElKowar> | i mean, it has unsafePerformIO, haskell isn't super strict about not breaking purity when you very explicitly tell it to |
| 2020-12-16 20:03:38 | <ElKowar> | but yea, i was surprised by it's existance too, so i guess it makes sense that it isn't as powerful as i would have maybe hoped |
| 2020-12-16 20:05:13 | <geekosaur> | oh, surely it'll let you if you're explicit enough, but you get to keep all the pieces when it breaks. and making your window manager dump core is not the best of ideas |
| 2020-12-16 20:05:38 | <geekosaur> | unsafePerformIO being one of the rare ways to convince a Haskell app to segfault |
| 2020-12-16 20:05:50 | × | wonko7 quits (~wonko7@2a01:e35:2ffb:7040:4535:f480:7dff:b3b5) (Ping timeout: 268 seconds) |
| 2020-12-16 20:09:17 | <ElKowar> | fair point i guess :D would have still been fun to play around with, but yea, it _really_ wouldn't fit the haskell way |
| 2020-12-16 20:14:33 | <Liskni_si> | geekosaur: we're speaking about a Haskell app with FFI to Xlib |
| 2020-12-16 20:14:43 | <Liskni_si> | you wish unsafePerformIO was one of the rare ways :-) |
| 2020-12-16 20:14:58 | <geekosaur> | you have a point :) |
| 2020-12-16 20:15:29 | <Liskni_si> | 16181ce6e7 comes to mind |
| 2020-12-16 20:15:46 | <Liskni_si> | (https://github.com/liskin/xmonad-contrib/commit/16181ce6e708f0111cde1cff565fa5eaa93ac3a4 for those without a git clone on hand) |
| 2020-12-16 20:17:00 | <geekosaur> | how about the whole XGetWindowAttributes mess? |
| 2020-12-16 20:17:58 | <Liskni_si> | that didn't segv, but it's still mighty annoying |
| 2020-12-16 20:18:18 | <Liskni_si> | to this days xmonad logs errors from it on every closed window :-( |
| 2020-12-16 20:18:32 | <geekosaur> | at one point it did segv, the cbits deferenced NULL instead of checking for it and producing Nothing |
| 2020-12-16 20:18:41 | <Liskni_si> | oh |
| 2020-12-16 20:19:33 | <geekosaur> | I don't recall what change to the core made it suddenly start happening every time a window closed |
| 2020-12-16 20:20:30 | <Liskni_si> | the one that started all this, I think |
| 2020-12-16 20:22:02 | <Liskni_si> | https://github.com/liskin/xmonad/commit/202e239ea48d56882bb4ad226ad3a4042ebf12bd#diff-923e7c74cfed3b9f19a479a1ff9537c3eed65b799e8739cb7840560d008a76a3R200 |
| 2020-12-16 20:22:02 | <geekosaur> | that one actually happened to us twice, because we fixed it on xmonad/X11 master and then the Arch xmonad maintainer pulled up just the X11 change without the matching xmonad change |
| 2020-12-16 20:22:40 | <geekosaur> | so we had a wave of git crashes, then a few months later a wave of Arch crashes |
| 2020-12-16 20:23:06 | → | wonko7 joins (~wonko7@lns-bzn-55-82-255-183-4.adsl.proxad.net) |
| 2020-12-16 20:23:32 | <geekosaur> | and I yelled a bt about not changing it to a Maybe type at the same time so that kind of thing would be caught |
| 2020-12-16 20:24:29 | <Liskni_si> | yesh, using exceptions for what is a totally expectable exception, ugh. |
| 2020-12-16 20:24:39 | <Liskni_si> | no changing the past, tho |
| 2020-12-16 20:28:38 | <ElKowar> | exceptions in haskell become super confusing in general. i had spent hours trying to understand a crash, bcos i _was_ trying to catch exceptions but, well,... lazyness..... |
| 2020-12-16 20:29:18 | <geekosaur> | I'm still firmly of the opinion that a way should be found to get rid of all synchronous exceptions. like, openFile should produce an error instead of throwing an exception on e.g. file not found |
| 2020-12-16 20:29:51 | <geekosaur> | but this is difficult because mtl is not part of base and can't be, so the obvious candidate (ExceptT) isn't available |
| 2020-12-16 20:30:40 | <Liskni_si> | and then you also have undefined, error, and all the autogenerated errors from nonexhaustive pattern matches and failed irrefutable patterns and whatnot :-/ |
| 2020-12-16 20:31:19 | <Liskni_si> | and the lolz of no safe list indexing being in Prelude/Data.List |
| 2020-12-16 20:31:24 | <ElKowar> | yea, i fear that this isn't a fixable problem without throwing pragmatism out of the window,... it's just abused quite commonly. |
| 2020-12-16 20:31:40 | <ElKowar> | I've been planning to migrate my stuff over to relude for quite a while, i should really just do that _now_ |
| 2020-12-16 20:32:12 | <Liskni_si> | snoyberg's been mentioning this recently in his "Haskell the bad parts" posts lately |
| 2020-12-16 20:33:14 | <ElKowar> | what's that? |
| 2020-12-16 20:34:53 | <Liskni_si> | https://www.snoyman.com/blog/2020/10/haskell-bad-parts-1, https://www.snoyman.com/blog/2020/11/haskell-bad-parts-2, https://www.snoyman.com/blog/2020/12/haskell-bad-parts-3 |
| 2020-12-16 20:36:00 | <ElKowar> | Ahh, nice, thanks! |
| 2020-12-16 20:36:05 | <ElKowar> | i have some reading to do! |
| 2020-12-16 20:37:53 | <Solid> | he's a bit heavy on the rust evangelism though :> |
| 2020-12-16 20:38:01 | <Liskni_si> | I think it's somewhat related to the Haskell Foundation activities |
| 2020-12-16 20:38:13 | <Liskni_si> | like people have high hopes again or something |
| 2020-12-16 20:38:20 | <Liskni_si> | Solid: that was my feeling as well |
| 2020-12-16 20:39:11 | <Liskni_si> | he's arguing for some things that would make Haskell better for production-level code but more difficult for quick hacks |
| 2020-12-16 20:39:39 | <Liskni_si> | as someone who's written a bit of Haskell with cold hands on a mobile phone in the night (puzzle hints), that makes me sad |
| 2020-12-16 20:39:49 | <Liskni_si> | *hunts |
| 2020-12-16 20:39:53 | <ElKowar> | i mean, haskell really isn't the language for quick hacks in general imo. it's just not the intended usecase |
| 2020-12-16 20:40:26 | <Liskni_si> | I mean a different kind of quick hacks |
| 2020-12-16 20:40:41 | <Solid> | anything with a functioning interpreter is a joy to use for quick hacks |
| 2020-12-16 20:40:47 | <Liskni_si> | not the quick hacks you usually use python or perl for |
| 2020-12-16 20:41:16 | <Liskni_si> | but hacking together a project euler solution or advent of code or something like that |
| 2020-12-16 20:41:45 | <ElKowar> | fair, but even there i'd argue that if you're using haskell, you kind of _want_ to be forced to do things correctly.. no? |
| 2020-12-16 20:41:46 | <Liskni_si> | you want the types because it's just a tiny bit bigger than your working memory |
| 2020-12-16 20:42:13 | <Liskni_si> | but you don't want to be bothered with using conduits-like machinery where lazy lists will do |
| 2020-12-16 20:42:36 | <Liskni_si> | (working memory meaning the memory of your brain, not the computer) |
| 2020-12-16 20:42:44 | <ElKowar> | I've been doing AOC in Prolog/curry this year (trying both pretty much for the first time, not actually doing all challenges) and the non-determinism of curry still really fascinates me. It's a very interesting idea to just say "partial functions don't crash, they just don't return a possible value" and then making that the foundation of a lot of the language |
| 2020-12-16 20:43:49 | <ElKowar> | the best possible, but also very very infeasable future would be that we somehow manage to do a type deduction system that can pretty much find arbitrary invariants and variants, and thus provide a dependent type system with next to 0 overhead for the programmer. that would be perfect,... but also very infeasable |
| 2020-12-16 20:44:40 | <Solid> | at that point I would expect my compiler to write the code for me ;) |
| 2020-12-16 20:45:29 | <ElKowar> | i mean, you'd still have to tell it what the code should do. in a sufficiently high level language, that's literally what programming is |
| 2020-12-16 20:45:35 | <ElKowar> | logic programming seems to actually be pretty close to that |
| 2020-12-16 20:45:44 | <ElKowar> | just,... not close enough, and not without a TON of problems |
| 2020-12-16 20:46:14 | <ElKowar> | AOC day 1 in prolog was beautiful tho. it really is just "state the problem" and it then finds the solution for you, without you ever writing any actual logic to find a solution |
| 2020-12-16 20:46:45 | <Solid> | I mean with a type system that advanced you should just be able to write down the type and the compiler will do the rest |
| 2020-12-16 20:46:47 | <ElKowar> | (note that for that problem, problem description and solution algorithm are already very close, but the way u express it in logic programming feels a lot moire fun) |
| 2020-12-16 20:46:53 | <Solid> | idris can already do it for small examples |
| 2020-12-16 20:49:19 | <ElKowar> | coming back to bad parts of haskell: The number one, absolutely indiscussable biggest issue when it comes to actual production code is,.... the record system. everything in haskell is designed in a pretty ergonomic way - until you see the record system. i still can't get over it, after having used purescript for a short while |
| 2020-12-16 20:50:07 | <Solid> | there's always lens |
| 2020-12-16 20:50:16 | <Solid> | which solves this pretty convincingly |
| 2020-12-16 20:50:28 | <Solid> | and RecordDotSyntax (or something) got merged a while ago afaik |
| 2020-12-16 20:52:47 | <ElKowar> | meh, my issue is that the whole idea of accessor functions, the way they are in haskell, just causes TONS of issues, everywhere. not being able to have a record with a field named "name" in a module if i also want to have a function argument be named "name" is just ridiculous. Lens and RecordDotSyntax are nice workarounds, with RecordDotSyntax being an absolute bare minimum of usability,... but the whole system is flawed inherently |
| 2020-12-16 20:54:15 | <ElKowar> | have you tried purescript? The Row-type polymorphism (<- abstract nonsense-ish for "structural typing but fancier") system is genuinely brilliant to work with, it's a ton of fun. They not only solved ALL issues i have with haskells record system, but doing that, created THE nicest bit of type system i have worked with, yet. |
| 2020-12-16 20:55:08 | <Solid> | I have not tried purescript but I remember reading some papers on row-type polymorphism |
| 2020-12-16 20:55:14 | <Solid> | that is indeed *very* cool |
| 2020-12-16 20:55:23 | <ElKowar> | yea |
| 2020-12-16 20:56:09 | <ElKowar> | IIRC they still have accessor functions simmilar to how we do, just that it's `.name` (or was it `_.name`, actually don't remember rn) |
| 2020-12-16 20:56:16 | <ElKowar> | they don't really loose anything, but gain a ton |
| 2020-12-16 20:57:28 | <Solid> | btw, I do like how "row polymorphism" is abstract nonsense for you, but "structural typing" is fine :P |
| 2020-12-16 20:57:33 | <ElKowar> | i mean |
| 2020-12-16 20:57:49 | <ElKowar> | structural typing is a word used in the general field of PLDT |
| 2020-12-16 20:58:09 | <ElKowar> | whereas i have only heard "row polymorphism" in the realm of purescript and similar languages |
| 2020-12-16 20:58:26 | <ElKowar> | like, typescript and go feature structural typing, the word is pretty widely understood |
| 2020-12-16 20:59:42 | <Solid> | I don't know either of these languages; for me row polymorphism sounds more natural :> |
| 2020-12-16 21:00:53 | <Solid> | though abstract nonsense is usually referred to category theory stuff; row polymorphism doesn't really fit into that |
| 2020-12-16 21:01:14 | <ElKowar> | fair i guess xD yea, "abstract nonsense" was definitely more of a joke than anything else xD |
| 2020-12-16 21:01:19 | <Solid> | :) |
| 2020-12-16 21:06:42 | <ElKowar> | on a completely unrelated note: I've been thinking about a possible abstraction over layouts that could allow for hiding some of the background-work, and allow for a more high-level definition of layouts which all support some basics like resizing, maybe even mouse-drag based resizing, etc. Has anyone ever attempted anything like that? The way that layouts are very much "separated" in a sense kind of annoys me,... as in, defining a layout |
| 2020-12-16 21:06:42 | <ElKowar> | may require reimplementing quite a lot stuff, depending on what you want it to support |
All times are in UTC.