Newest at the top
| 2025-05-04 19:57:46 +0200 | Arpad | (~Arpad@2a02:ab88:38d:4700::b0d5) (Quit: Client closed) |
| 2025-05-04 19:57:29 +0200 | <hellwolf> | Mount my COBOL, fumble thy registers? |
| 2025-05-04 19:57:27 +0200 | geekosaur | already did his time there, tyvm |
| 2025-05-04 19:56:40 +0200 | <hellwolf> | I think if we are all net givers, in that we complain only if we have contributed, probably we will be of a better world. |
| 2025-05-04 19:56:30 +0200 | Googulator77 | (~Googulato@2a01-036d-0106-4a24-1dc7-297e-fae3-e794.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-05-04 19:56:27 +0200 | <monochrom> | Rear Admiral Grass Hopper would like you to jump to COBOL. >:) |
| 2025-05-04 19:55:55 +0200 | <geekosaur> | sounds about right |
| 2025-05-04 19:55:37 +0200 | <int-e> | Let me guess: There's two kinds of languages, those that everybody complains about and those that nobody uses. |
| 2025-05-04 19:55:04 +0200 | <hellwolf> | Sure, Stroustrup said. |
| 2025-05-04 19:54:50 +0200 | <hellwolf> | continuing along your interesting analogy, is it a "grass hopper" a suitable way to describe people jumping languages. |
| 2025-05-04 19:53:55 +0200 | <monochrom> | At some point we just have to say what Stroustrup said. People complain about GHC because it is actually used. |
| 2025-05-04 19:52:58 +0200 | Googulator33 | (~Googulato@2a01-036d-0106-4a24-1dc7-297e-fae3-e794.pool6.digikabel.hu) |
| 2025-05-04 19:49:08 +0200 | <monochrom> | Moreover, the other pasture is always greener. :) |
| 2025-05-04 19:48:53 +0200 | <monochrom> | Yes, it's why. |
| 2025-05-04 19:47:51 +0200 | <int-e> | Hugs has a simpler type system |
| 2025-05-04 19:47:33 +0200 | <hellwolf> | if one is motivated enough by the end goal, these are just minor obstacles :) |
| 2025-05-04 19:46:48 +0200 | <monochrom> | Hugs has better error messages. |
| 2025-05-04 19:43:01 +0200 | <tomsmeding> | it's not as suited for all kinds of proofs :) |
| 2025-05-04 19:42:47 +0200 | <tomsmeding> | there's a rather large set of people that like to use computers to check their work with automated theorem proving |
| 2025-05-04 19:42:23 +0200 | <Pozyomka> | Theorem proving is meant to be done with pen, paper and waste basket anyway. Not with a programming language. |
| 2025-05-04 19:40:57 +0200 | <tomsmeding> | or trying to do too much theorem proving |
| 2025-05-04 19:40:53 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-04 19:37:39 +0200 | <Pozyomka> | The type errors are the most unhelpful when you're trying to be too clever. |
| 2025-05-04 19:36:58 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-05-04 19:36:25 +0200 | <tomsmeding> | sometimes. |
| 2025-05-04 19:36:23 +0200 | <tomsmeding> | I fully agree GHC's error messages are often overwhelming and sometimes (or often, depending on the kind of code you write) unhelpful -- but if you start thinking about how to do better, one tends to quickly realise that sure, one can do better on the particular code you have, but can one do better without overfitting to your code, and without making other cases worse? It's actually not easy, |
| 2025-05-04 19:35:46 +0200 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-05-04 19:35:19 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-05-04 19:34:51 +0200 | <tomsmeding> | e.g. in int-e's example `let False = () in ()`, clearly the error is that Bool is not (), but which of the two is expected, and which of the two is actual? Depends on whether the error comes from the pattern or the right-hand side. And the more type-level shenanigans you do, the more type-equality constraints you get that are not directly attributable to a particular syntactic expression anyway |
| 2025-05-04 19:33:34 +0200 | <tomsmeding> | if there are no such full types, there isn't necessarily any "expected" or "actual" type |
| 2025-05-04 19:33:13 +0200 | <tomsmeding> | (there might be other notes in between the first line and the expected/actual types, so be sure to look further than the top part of the diagnostic) |
| 2025-05-04 19:32:49 +0200 | <tomsmeding> | hellwolf: I think GHC is pretty consistent in giving expected/actual full types if there are any such that make sense |
| 2025-05-04 19:31:21 +0200 | <Pozyomka> | But then, I don't go crazy with type-level programming. Because why would I torture myself that way? |
| 2025-05-04 19:31:02 +0200 | <Pozyomka> | In ML, what I normally do is annotate types in module signatures, but not in modules themselves. The Haskell equivalent would be to annotate only the type signatures of those values that the module exports. I find that this works well in practice. |
| 2025-05-04 19:29:44 +0200 | <hellwolf> | and this time I listened to the Emacs's word correction advice. |
| 2025-05-04 19:29:17 +0200 | <hellwolf> | I do prefer the completely indecipherable code in the end without type signature. But the comments stay there. |
| 2025-05-04 19:28:45 +0200 | <hellwolf> | I have learned that, and started to save those intermediate steps in the comments. |
| 2025-05-04 19:27:01 +0200 | <int-e> | this may break down if you're heavily into type families and other type-level programming |
| 2025-05-04 19:26:36 +0200 | <int-e> | if it's too much you can usually help the compiler and yourself with extra type signatures |
| 2025-05-04 19:25:40 +0200 | <hellwolf> | a good job of being verbose, indeed |
| 2025-05-04 19:24:03 +0200 | <int-e> | IME it does a good job of giving you all the relevant info though the result can be overwhelming. |
| 2025-05-04 19:23:33 +0200 | <int-e> | It's hard because the exact error you get depends on the order in which GHC decides to tackle all the constraints it's juggling while type-checking. |
| 2025-05-04 19:21:35 +0200 | <hellwolf> | :p |
| 2025-05-04 19:21:31 +0200 | <int-e> | *decipher |
| 2025-05-04 19:21:25 +0200 | <hellwolf> | *few more words |
| 2025-05-04 19:21:08 +0200 | <hellwolf> | sounds like low hanging fruits to improve error messages. at least few words wouldn't make it worse. Though, sometimes the message can still be confusing and it takes experience to decypher it. |
| 2025-05-04 19:18:40 +0200 | <int-e> | hellwolf: Okay, so several versions of this exist. One elaborates expected/actual right after the "couldn't match type" (the example is matching the type from an instance implementation with the type class declaraion. Another variant refers to the left-hand and right-hand sides of ~ so the actual/expected distinction makes no sense. There's undoubtedly more scenarios. |
| 2025-05-04 19:15:27 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-05-04 19:12:55 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-05-04 19:11:39 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |