Newest at the top
| 2024-11-14 14:05:11 +0100 | <haskellbridge> | <hellwolf> the lie is limited to the extent that, if your program is not total, would the debugger hurt your bottom where you intend to leave it so. |
| 2024-11-14 14:02:26 +0100 | <__monty__> | There's the rub : ) |
| 2024-11-14 13:59:51 +0100 | alphazone | (~alphazone@2.219.56.221) |
| 2024-11-14 13:59:08 +0100 | <kuribas`> | Assuming it doesn't use unsafePerformIO. |
| 2024-11-14 13:58:57 +0100 | <kuribas`> | __monty__: how can it be a lie with "pure" code? |
| 2024-11-14 13:48:41 +0100 | <__monty__> | That would also cause confusion though. Since sometimes referential transparency is a lie. And it's easy to convince yourself that the expressions must surely be evaluating in the order you think they are. |
| 2024-11-14 13:47:50 +0100 | mari73904 | (~mari-este@user/mari-estel) (Ping timeout: 255 seconds) |
| 2024-11-14 13:47:01 +0100 | mari-estel | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-11-14 13:47:00 +0100 | <kuribas`> | As long as the semantics are preserved. |
| 2024-11-14 13:46:40 +0100 | <kuribas`> | I the end, lazyness doesn't specify an order for execution. |
| 2024-11-14 13:46:10 +0100 | <kuribas`> | A more useful pure debugger would allow you to choose which expression to evaluate. |
| 2024-11-14 13:45:55 +0100 | <kuribas`> | The problem is that the GHC debugger follow the imperative model for debugging (stepping through, etc..) |
| 2024-11-14 13:44:51 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:44:19 +0100 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2024-11-14 13:43:13 +0100 | mari73904 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:41:53 +0100 | <hellwolf> | Debug.Trace (trace) |
| 2024-11-14 13:41:35 +0100 | <hellwolf> | Does Trace.trace help? |
| 2024-11-14 13:38:40 +0100 | <mari-estel> | prints or traces are a good way to collect test samples while troubleshooting |
| 2024-11-14 13:38:40 +0100 | <mari-estel> | huh properties help equally with pure and monadic |
| 2024-11-14 13:37:49 +0100 | mari59415 | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2024-11-14 13:36:10 +0100 | <hellwolf> | fwiw, @dminuoso, I had a small example here https://discourse.haskell.org/t/variable-arity-currying-helper/10659 that decorates "let foo' = curry' (MkFn foo)" but that assumes all arguments is "showable". to make it runTrace, you'd need to have a default instance for all types, and then overlapping instance for Show, Num, Functor, etc. |
| 2024-11-14 13:35:34 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:34:38 +0100 | <hellwolf> | exactly, mari59415, it is a problem most applicable to impure code. For pure code, you write properties (which means thinking a lot about what you are writing.) |
| 2024-11-14 13:33:53 +0100 | <hellwolf> | But I find the habit of spending more time in thinking then examining into what happened is a better use of time. Of course, on the contrary, Linus, notoriously, promoted the idea of printf debugging. So I guess the tool influence on how you do troubleshooting. |
| 2024-11-14 13:32:42 +0100 | <mari59415> | no mentions about pure code being amounts easier to test |
| 2024-11-14 13:32:36 +0100 | ChanServ | +v haskellbridge |
| 2024-11-14 13:32:36 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2024-11-14 13:32:28 +0100 | <lortabac> | I don't think we should see lack of observability as an intrinsic property of pure computations |
| 2024-11-14 13:31:51 +0100 | <lortabac> | "Pure code is often cumbersome to debug" *with GHC* |
| 2024-11-14 13:31:46 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2024-11-14 13:28:48 +0100 | <hellwolf> | sorry, typed too slow. I meant to propose a hypothetical |
| 2024-11-14 13:28:32 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-14 13:28:25 +0100 | <hellwolf> | that'd be my ideal way of trace into your pure fn in a principled way. I am entirely sure how feasible/difficult it could be; I did somethings that involve some aspects of such a thing. |
| 2024-11-14 13:28:06 +0100 | <dminuoso> | What is `runTrace` supposed to be here? |
| 2024-11-14 13:27:19 +0100 | <hellwolf> | runTrace your_pure_fn your_trace_filters ...currying your_pure_fn_args... |
| 2024-11-14 13:26:39 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-14 13:26:03 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 252 seconds) |
| 2024-11-14 13:25:23 +0100 | arahael_ | (~arahael@user/arahael) arahael |
| 2024-11-14 13:24:25 +0100 | arahael_ | (~arahael@user/arahael) (Quit: leaving) |
| 2024-11-14 13:23:59 +0100 | mari59415 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 13:22:42 +0100 | <dminuoso> | Consider something like GHC, where large portions work in IO |
| 2024-11-14 13:22:21 +0100 | <dminuoso> | Pure code is often cumbersome to debug |
| 2024-11-14 13:22:02 +0100 | <dminuoso> | hellwolf: Anyway, IO can still be a useful tool, especially if you want any kind of introspectability of whats going on (say logging or debugging) |
| 2024-11-14 13:20:32 +0100 | <dminuoso> | No, those examples I named are both wrong. Mmm. |
| 2024-11-14 13:20:26 +0100 | <dminuoso> | An internal compiler of ours. |
| 2024-11-14 13:20:14 +0100 | <hellwolf> | which code base? |
| 2024-11-14 13:20:06 +0100 | <dminuoso> | Ill have to dig through the commit history to find this one. |
| 2024-11-14 13:19:48 +0100 | <dminuoso> | Yeah I think it was something like `unsafePerformIO (traverse_ (\_ -> newIORef []) xs)` and GHC successfully floated that IORef out |
| 2024-11-14 13:18:46 +0100 | <dminuoso> | I mean actually there was a `traverse_` in there too. |
| 2024-11-14 13:18:15 +0100 | <dminuoso> | (In reality the code was far more sophisticated, so it was neither obvious how or why this happened) |