Newest at the top
| 2025-05-04 20:47:13 +0200 | <c_wraith> | fwiw, worry about constant factors too much with Seq is.. well, it's a data structure you already aren't using for its constant factors. |
| 2025-05-04 20:38:23 +0200 | <Pozyomka> | So you can perform step (a) just once, and then step (c) lots of times. Or maybe zero times. Or maybe one time, but only after doing I/O. Or who knows. |
| 2025-05-04 20:37:18 +0200 | <Pozyomka> | It's not as efficient as the lens version. You can think of “adjust” as having three steps: (a) locate the element, (b) perform the update, (c) rebuild the sequence. In the lens version, step (b) produces a functorful of new values, and step (c) is a map over those values. |
| 2025-05-04 20:35:09 +0200 | <[exa]> | Pozyomka: otoh I think they (and many other folks) could solve this quite cheaply by exposing an interface like `getset :: Seq a -> Int -> (a, a -> Seq a)`. Not sure if it isn't there already, somewhere. |
| 2025-05-04 20:33:02 +0200 | <[exa]> | Pozyomka: btw re Data.Sequence and zipper, iirc the structure there is already a kinda 2-sided zipper so I can kinda guess why they wouldn't increase the complexity once more |
| 2025-05-04 20:25:38 +0200 | <mauke> | I like ghc's error messages better than hugs's |
| 2025-05-04 20:18:15 +0200 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2025-05-04 20:15:51 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-05-04 20:12:22 +0200 | mceresa | (~mceresa@user/mceresa) (Ping timeout: 276 seconds) |
| 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. |