| 2 Mar 2021 |
 Yorick Peterse | Handling if, if_true and if_false already requires the compiler to cheat (more or less), but with iteration that's not feasible (due to how many different ways there are to iterate) | 21:43:26 |
| Yorick Peterse | Seems I'd have to take the Rust route of introducing some sort of closure type that can be called only once, and only allow those to move variables | 21:47:29 |
| Yorick Peterse | But yuck, now we're getting dangerously close to over engineering | 21:47:38 |
| 3 Mar 2021 |
| Yorick Peterse | I think I found a way to make it work without becoming a pain, but this definitely needs some further thinking/research | 16:13:13 |
 codec_abc | Good luck. Seems like a bit tricky to implement. | 16:56:09 |
| Yorick Peterse | Yeah, the basic rule comes down to this: when a closure moves a variable, it must either re-assign that variable or return from the surrounding method | 17:17:15 |
| Yorick Peterse | I thought this would be too extreme, but upon closer inspection I think it won't be an issue | 17:17:42 |
| Yorick Peterse | e.g. when moving in loops you'd already re-assign the variable so you can use it in the next iteration. For conditionals, the compiler already prevented you from using variables moved in an if/else branch | 17:18:15 |
| Yorick Peterse | This generic rule actually makes that last bit easier to implement, though for if I still need a compiler hack (so you can move the same variable in the true and false cases) | 17:19:09 |
| Yorick Peterse | This way I don't need to introduce a one-shot closure (e.g. do once). That wouldn't work anyway: to enforce you can only call them once, you have to move it. But a closure that moves can't return or throw from its surrounding method, as moving it may result in it outliving that method | 17:20:33 |
| Yorick Peterse | that would thus render them more or less useless | 17:20:46 |
| Yorick Peterse | With that said, I'm still looking into decoupling throw and return from the ownership of a closure | 17:21:12 |
| Yorick Peterse | That is, it's fine if a closure uses return and is moved, as long as its called before the surrounding method returns | 17:21:31 |
| Yorick Peterse | Not sure if you can reliably detect that using escape analysis (let alone in the crappy Ruby compiler) | 17:21:56 |
| Yorick Peterse | Either way, we're slowly getting there I think | 17:22:10 |
| 4 Mar 2021 |
|  uzl changed their profile picture. | 23:11:29 |
| 12 Mar 2021 |
| Yorick Peterse | https://gitlab.com/inko-lang/inko/-/merge_requests/120 started an MR for the changes. It's still entirely possible I have to drop this, but so far so good | 00:36:44 |
| Yorick Peterse | it's in the early stages, and I'm mostly using it to keep track of TODOs/discoveries/etc, so I don't forget about those | 00:37:01 |
| 29 Mar 2021 |
 kiti_nomad | 
Download image.png | 02:35:15 |
| kiti_nomad | ？ | 02:35:21 |
| kiti_nomad | 
Download image.png | 02:35:50 |
| Yorick Peterse | kiti_nomad: what exactly are you trying to achieve? | 12:31:18 |
| Yorick Peterse | ah I see the second image now | 12:31:34 |
| Yorick Peterse | aha, you are trying to source a Vim configuration file in bash | 12:32:47 |
| Yorick Peterse | That's not going to work, because, well, vim config files are meant for vim :) | 12:33:45 |
| kiti_nomad | 
Download image.png | 17:41:03 |
| kiti_nomad | 
Download image.png | 17:41:52 |
| kiti_nomad | This is configured in wsl, and the configuration is successful under windows | 17:47:57 |
| Yorick Peterse | kiti_nomad: I can't help you with your Vim setup, though it may look like vim-plug isn't loaded properly. Perhaps this is due to a path difference in Windows vs WSL | 20:55:59 |
| 30 Mar 2021 |
| kiti_nomad | thank you | 02:05:43 |
